εφαρμογές ΤΝ

Εφαρμογές ΤΝ: τι πρέπει να οριστεί πριν από την υλοποίηση

Οι εφαρμογές ΤΝ, δηλαδή εφαρμογές τεχνητής νοημοσύνης (Artificial Intelligence), αποδίδουν όταν λύνουν ένα συγκεκριμένο πρόβλημα με ελεγχόμενο τρόπο. Πριν ξεκινήσει η κατασκευή, χρειάζεται να οριστούν ο χρήστης, η εργασία που πρέπει να ολοκληρώνεται, τα διαθέσιμα δεδομένα, το αποδεκτό αποτέλεσμα και η στιγμή που παρεμβαίνει άνθρωπος. Η ασαφής απαίτηση «θέλουμε τεχνητή νοημοσύνη στο σύστημα» δεν αρκεί για σωστή κοστολόγηση, ασφάλεια ή δοκιμές. Μια σύντομη απογραφή διαδικασιών μπορεί να αποτρέψει πολύ περισσότερο κόστος από ένα βιαστικό τεχνικό πρωτότυπο.

Ορίστε πρώτα το πρόβλημα, όχι το εργαλείο

Μια ομάδα μπορεί να θέλει να κατηγοριοποιεί μηνύματα πελατών, να βρίσκει πληροφορίες σε εγχειρίδια ή να προτείνει απαντήσεις σε υπαλλήλους. Πρόκειται για διαφορετικά έργα, παρότι όλα μπορούν να αξιοποιήσουν την ίδια τεχνολογική οικογένεια. Στην πρώτη περίπτωση μετρά η σωστή ταξινόμηση, στη δεύτερη η ακρίβεια της ανακτημένης πηγής και στην τρίτη η χρησιμότητα της πρότασης χωρίς παραπλάνηση. Η περιγραφή οφείλει να διατυπώνεται ως παρατηρήσιμο αποτέλεσμα.

Αν η πραγματική δυσκολία είναι ότι τα δεδομένα είναι ασύνδετα ή ελλιπή, η προτεραιότητα μπορεί να είναι η οργάνωσή τους και όχι ένα νέο μοντέλο. Το λογισμικό δεν μπορεί να γνωρίζει κάτι που δεν υπάρχει στις πηγές του. Γι' αυτό η συζήτηση ξεκινά από πέντε πραγματικά παραδείγματα καθημερινής εργασίας και όχι από μια γενική παρουσίαση δυνατοτήτων.

Ακριβές εύρος λειτουργιών και μη λειτουργιών

Το κείμενο απαιτήσεων πρέπει να ξεχωρίζει τι θα κάνει η εφαρμογή και τι δεν θα επιτρέπεται να κάνει. Ένας βοηθός ενημέρωσης, για παράδειγμα, μπορεί να ανακτά δημοσιευμένες οδηγίες, αλλά να μην επιτρέπεται να ακυρώνει παραγγελίες. Ένα εργαλείο σύνταξης προσχεδίων μπορεί να προτείνει κείμενο χωρίς να το δημοσιεύει αυτομάτως. Τα όρια αποτρέπουν την ακούσια μετατροπή της υποστήριξης σε μη εξουσιοδοτημένη λήψη αποφάσεων.

Καταγράψτε επίσης γλώσσες, μορφές αρχείων, επιτρεπόμενους χρήστες, ωράρια, συνήθεις εξαιρέσεις και απαιτήσεις προσβασιμότητας. Η πρόβλεψη για κινητά δεν είναι μια αισθητική σημείωση· μπορεί να αλλάξει τη ροή έγκρισης και τη μορφή των απαντήσεων. Η ομάδα χρειάζεται ενιαίο, ελέγξιμο ορισμό της λειτουργίας πριν προσφέρει τεχνικές λύσεις.

Ποιότητα και προέλευση δεδομένων

Κάθε λειτουργία χρειάζεται προσδιορισμένες πηγές αλήθειας. Σε εσωτερική αναζήτηση πρέπει να είναι γνωστό ποιος ενημερώνει τα έγγραφα, πώς ξεχωρίζει η τελευταία έκδοση και αν υπάρχουν αρχεία που δεν πρέπει να ανακτηθούν από όλους. Για ανάλυση εισερχόμενων αιτημάτων πρέπει να εντοπιστούν οι πραγματικές κατηγορίες και ο τρόπος χειρισμού ασαφών περιπτώσεων. Τα παρωχημένα δεδομένα δημιουργούν πειστικές αλλά λάθος απαντήσεις.

Πριν από παραγωγική σύνδεση, χρησιμοποιούμε μικρό δείγμα με τυπικές και δύσκολες περιπτώσεις. Σημειώνουμε ελλείψεις, διπλότυπα και ασυμβατότητες. Δεν πρέπει να τοποθετούνται προσωπικά ή εμπιστευτικά δεδομένα σε δοκιμαστικά εργαλεία χωρίς κατάλληλο έλεγχο σκοπού, πρόσβασης και συμφωνιών.

Αρχιτεκτονική: αυτόνομη απάντηση ή ενέργεια;

Υπάρχει μεγάλη διαφορά ανάμεσα σε σύστημα που απαντά με πληροφορίες και σε σύστημα που δρα. Η ανάκτηση από μια εγκεκριμένη βάση γνώσης μπορεί να ελεγχθεί με παραπομπές. Η εκτέλεση ενέργειας, όπως η αλλαγή μιας κράτησης, απαιτεί ταυτοποίηση, δικαιώματα, επαλήθευση παραμέτρων, προστασία από επανάληψη και ίχνος ενεργειών. Οι δύο λειτουργίες χρειάζονται διαφορετική αξιολόγηση κινδύνου.

Για κάθε ενέργεια ορίζεται τι είναι αναστρέψιμο, ποιος εγκρίνει και τι γίνεται αν αποτύχει το επόμενο σύστημα. Η λειτουργία πρέπει να παρουσιάζει κατανοητή αποτυχία αντί να υπόσχεται ότι ολοκλήρωσε μια πράξη που δεν επιβεβαιώθηκε. Εάν υπάρχουν τρίτα συστήματα, προδιαγράφεται η συμπεριφορά σε διακοπή σύνδεσης και σε ασυμφωνία δεδομένων.

Ρόλοι και εγκρίσεις

Η παραγωγική χρήση αφορά περισσότερους από έναν προγραμματιστές. Χρειάζεται ιδιοκτήτης της επιχειρησιακής ανάγκης, υπεύθυνος δεδομένων, τεχνικός υπεύθυνος, άτομο που εγκρίνει το τελικό αποτέλεσμα και εκπρόσωποι των ανθρώπων που θα χρησιμοποιήσουν τη λειτουργία. Η ευθύνη για την ορθότητα του περιεχομένου δεν πρέπει να αποδοθεί απλώς στον κατασκευαστή του μοντέλου.

Συμφωνήστε από την αρχή ποιος μπορεί να προσθέτει πηγές, να αλλάζει προτροπές, να ανακαλεί πρόσβαση και να επαναφέρει προηγούμενη έκδοση. Ένα εργαλείο που δουλεύει στο δοκιμαστικό περιβάλλον μπορεί να αποτύχει στην πράξη επειδή δεν έχει οριστεί ο υπεύθυνος συντήρησης της γνώσης.

Λίστα απαιτήσεων πριν από ανάθεση

• Ποια ακριβής εργασία θα επιλύεται και ποια αποτελέσματα είναι εκτός ορίων;
• Ποιοι χρήστες έχουν πρόσβαση και ποιες εγκρίσεις απαιτούνται;
• Από ποιες πηγές προέρχεται η γνώση και πότε ανανεώνεται;
• Πώς χειρίζεται η εφαρμογή άγνωστες, αμφίσημες ή συγκρουόμενες πληροφορίες;
• Ποιες λειτουργίες ενεργούν σε άλλα συστήματα και πώς αναιρούνται;
• Τι καταγράφεται για ασφάλεια, αξιολόγηση και διερεύνηση σφάλματος;
• Ποια δοκιμή οδηγεί σε αποδοχή και ποιος την υπογράφει;
• Πώς αποσύρεται η λειτουργία χωρίς να διακοπεί η βασική υπηρεσία;

Η λίστα είναι παραδοτέο απαιτήσεων και όχι διαφημιστική περιγραφή. Για τεχνική επέκταση σε διαφορετικές κατηγορίες λογισμικού, δείτε τις εφαρμογές τεχνητής νοημοσύνης και τον σχεδιασμό εξατομικευμένων εφαρμογών.

Δοκιμές με πραγματικά σενάρια αποδοχής

Μια επίδειξη με εύκολα ερωτήματα δεν αποδεικνύει αξιοπιστία. Η ομάδα χρειάζεται σύνολο ελέγχων που περιλαμβάνει αναμενόμενη απάντηση, αποδεκτές εναλλακτικές και λόγο απόρριψης. Οι περιπτώσεις πρέπει να περιλαμβάνουν ελλιπή δεδομένα, αμφισημία, λανθασμένο αίτημα, μη εξουσιοδοτημένο χρήστη και προσωρινή αδυναμία πρόσβασης στις πηγές. Μετράμε ξεχωριστά την ακρίβεια πληροφορίας, την ολοκλήρωση εργασίας και την αποτελεσματικότητα ανθρώπινης παρέμβασης.

Η τελική αποδοχή γίνεται με πραγματικούς χρήστες και προκαθορισμένα κριτήρια. Όταν μια απάντηση φαίνεται σωστή αλλά δεν στηρίζεται στα δεδομένα, σημειώνεται ως αποτυχία. Καλύτερα το σύστημα να παραδέχεται αβεβαιότητα παρά να επινοεί λεπτομέρειες που θα περάσουν απαρατήρητες.

Κόστος λειτουργίας και εξαρτήσεις

Στην εκτίμηση πόρων περιλαμβάνονται όχι μόνο η αρχική κατασκευή, αλλά και η χρήση υπολογιστικών υπηρεσιών, η ενημέρωση γνώσης, η ανθρώπινη επιθεώρηση, η παρακολούθηση σφαλμάτων και η διαχείριση αλλαγών. Μια λειτουργία με μικρό κόστος κατασκευής μπορεί να απαιτεί καθημερινή επαλήθευση, ενώ μια απλούστερη αυτοματοποίηση ίσως είναι οικονομικότερη και πιο αξιόπιστη. Χρειάζεται εκτίμηση βάσει σεναρίων χρήσης και όχι αυθαίρετη πρόβλεψη.

Ζητήστε επίσης σχέδιο αποχώρησης από προμηθευτή, εξαγωγή δεδομένων και δυνατότητα προσωρινής λειτουργίας χωρίς το έξυπνο υποσύστημα. Η εξάρτηση από εξωτερική υπηρεσία είναι διαχειρίσιμη όταν είναι καταγεγραμμένη και υπάρχουν λογικές εναλλακτικές.

Τρόπος παράδοσης και πραγματικό δικαίωμα ελέγχου

Η σύμβαση υλοποίησης χρειάζεται να εξηγεί ποια αρχεία και δικαιώματα παραδίδονται, ποιος ελέγχει τη διαμόρφωση των λειτουργιών και πώς μεταφέρονται τα δεδομένα αν αλλάξει ο συνεργάτης. Ιδιαίτερη προσοχή θέλουν οι προσωπικές προσαρμογές: μια εφαρμογή μπορεί να βασίζεται σε εξωτερική υπηρεσία, αλλά οι κανόνες της επιχείρησης, οι εγκεκριμένες πηγές και τα ιστορικά αξιολόγησης χρειάζονται σαφή ιδιοκτησιακή και συμβατική αντιμετώπιση.

Ζητήστε παραδείγματα όλων των καταστάσεων που θα παραλάβει ο υπεύθυνος λειτουργίας: επιτυχές αίτημα, αδυναμία απάντησης, απόρριψη μη εξουσιοδοτημένης ενέργειας και αναφορά σφάλματος. Ένα πακέτο που προσφέρει μόνο στιγμιότυπα όμορφων απαντήσεων δεν αποτελεί επαρκή παράδοση. Οι υπεύθυνοι πρέπει να μπορούν να εξηγήσουν στον νέο χειριστή γιατί μια απόφαση λήφθηκε και τι επιτρέπεται να αλλάξει.

Ασφάλεια, λογοδοσία και εκκίνηση

Πριν από τη διάθεση εξετάζονται εισαγωγή κακόβουλων οδηγιών μέσω δεδομένων, διαρροή εμπιστευτικού περιεχομένου, λανθασμένες ενέργειες και καταχρηστική χρήση. Η πρόσβαση στις πηγές δεν πρέπει να διευρύνεται επειδή ένα εργαλείο μπορεί να διαβάζει πολλά αρχεία. Χρειάζονται όρια, καταγραφές που δεν αποθηκεύουν αδικαιολόγητα ευαίσθητα στοιχεία και σαφής διαδικασία αναφοράς προβλημάτων.

Η πρώτη έκδοση είναι προτιμότερο να λειτουργήσει σε περιορισμένο, αντιπροσωπευτικό περιβάλλον. Συγκρίνουμε αποτελέσματα με την ανθρώπινη διαδικασία, διορθώνουμε τα επαναλαμβανόμενα σφάλματα και μόνο τότε επεκτείνουμε το πεδίο. Επιτυχία είναι η ασφαλής επίλυση προβλήματος με μετρήσιμη αξία, όχι η απλή εμφάνιση μιας εντυπωσιακής συνομιλίας.