Το ότι λαμβάνουμε μια απάντηση από ένα μοντέλο AI δεν σημαίνει ακόμη ότι το σύστημα λειτουργεί σωστά. Στο κλασικό λογισμικό μπορούμε συχνά να ελέγξουμε με σαφήνεια αν μια συνάρτηση επέστρεψε το αναμενόμενο αποτέλεσμα. Στα συστήματα AI η απάντηση μπορεί να είναι άρτια, λογική και πειστική, και παρ' όλα αυτά να περιέχει λάθη.
Γι' αυτό, με την ανάπτυξη της AI, εμφανίζεται ένα νέο μηχανικό πρόβλημα: πώς μετράμε συστηματικά την ποιότητα ενός συστήματος του οποίου οι απαντήσεις δεν είναι πάντα ίδιες;
Αυτό ακριβώς είναι ο τομέας του AI evaluation, δηλαδή της αξιολόγησης συστημάτων τεχνητής νοημοσύνης.
Και είναι πολύ ευρύτερος από το να ελέγξουμε αν το chatbot «απαντά καλά».
Το τεστ του κλασικού software και το τεστ AI δεν είναι το ίδιο
Ας φανταστούμε μια απλή συνάρτηση σε μια εφαρμογή.
Ο χρήστης πληκτρολογεί: 2 + 2
Το σύστημα θα πρέπει να επιστρέψει: 4
Αν επιστρέψει 5, έχουμε σαφές σφάλμα.
Μπορούμε να ετοιμάσουμε ένα τεστ: expect(calculate("2 + 2")).toBe(4)
και κάθε φορά θα παίρνουμε καθαρό αποτέλεσμα: το τεστ περνάει ή αποτυγχάνει.
Στα συστήματα AI η κατάσταση είναι διαφορετική.
Ο χρήστης μπορεί να ρωτήσει: «Γράψε μια σύντομη απάντηση για έναν πελάτη που ρωτά για τον χρόνο εκτέλεσης της παραγγελίας.»
Το σύστημα μπορεί να δημιουργήσει αρκετές διαφορετικές απαντήσεις. Όλες μπορεί να είναι γλωσσικά σωστές. Όλες μπορεί να ακούγονται επαγγελματικές. Μία όμως μπορεί να περιέχει λανθασμένο χρόνο, μια άλλη να είναι υπερβολικά μεγάλη, μια τρίτη να παραλείπει σημαντική πληροφορία, και μια τέταρτη να είναι ιδανική.
Άρα δεν αρκεί να ελέγξουμε αν η απάντηση έχει παραχθεί τεχνικά.
Πρέπει να ελέγξουμε, αν πληροί συγκεκριμένα κριτήρια ποιότητας.
Πρώτο πρόβλημα: η καλή απάντηση δεν είναι πάντα αληθινή
Αυτό είναι ένα από τα πιο χαρακτηριστικά γνωρίσματα της generative AI.
Το μοντέλο μπορεί να δημιουργήσει μια απάντηση που ακούγεται εξαιρετικά πειστική, αλλά δεν έχει αντιστοίχιση με τα πηγαία δεδομένα.
Στην περίπτωση ενός συστήματος που χρησιμοποιεί RAG, το πρόβλημα είναι ακόμη πιο ενδιαφέρον. Το σύστημα μπορεί να λάβει ένα ερώτημα, να αναζητήσει μερικά αποσπάσματα τεκμηρίωσης και στη συνέχεια να δημιουργήσει μια απάντηση.
Τότε πρέπει να ελέγξουμε τουλάχιστον τρία πράγματα:
- Βρέθηκαν οι σωστές πληροφορίες; Ο μηχανισμός αναζήτησης ανέκτησε αποσπάσματα που σχετίζονται πραγματικά με το ερώτημα;
- Η απάντηση αξιοποιεί τις πληροφορίες που βρέθηκαν; Το μοντέλο δεν πρόσθεσε κάτι που δεν υπήρχε στις πηγές;
- Η απάντηση όντως απαντά στο ερώτημα; Μπορεί να υπάρχει σωστά λειτουργούσα retrieval, αλλά κακή τελική απάντηση.
Γι' αυτό ακριβώς η αξιολόγηση RAG διαχωρίζει, μεταξύ άλλων, πτυχές όπως η συνάφεια του ανακτηθέντος πλαισίου, η πληρότητα της αναζήτησης, η ορθότητα της απάντησης και η συμφωνία της με τις πηγές.
Αυτό είναι μια σημαντική αλλαγή στον τρόπο που σκεφτόμαστε το testing.
Δεν δοκιμάζουμε πλέον μόνο: ερώτηση → απάντηση
αλλά ολόκληρη την αλυσίδα: ερώτηση → αναζήτηση → πλαίσιο → μοντέλο → απάντηση
Μπορούμε να έχουμε καλό μοντέλο και κακό σύστημα AI
Αυτό είναι κάτι ακόμα που εύκολα ξεχνιέται.
Μια εταιρεία μπορεί να επιλέξει ένα πολύ καλό γλωσσικό μοντέλο και παρ' όλα αυτά να δημιουργήσει ένα αδύναμο προϊόν AI.
Γιατί; Επειδή η ποιότητα του τελικού συστήματος δεν εξαρτάται μόνο από το μοντέλο.
Μετράνε επίσης:
- η ποιότητα των δεδομένων,
- ο τρόπος προετοιμασίας του πλαισίου,
- το prompt,
- ο τρόπος αναζήτησης πληροφοριών,
- οι παράμετροι του μοντέλου,
- τα εργαλεία που διατίθενται στην AI,
- η λογική της εφαρμογής,
- η μνήμη,
- ο τρόπος διαχείρισης σφαλμάτων,
- οι δικλίδες ασφαλείας,
- ο τρόπος αξιολόγησης των απαντήσεων.
Αυτό σημαίνει ότι το ερώτημα: «Ποιο μοντέλο είναι το καλύτερο;»
συχνά είναι λιγότερο χρήσιμο από το: «Ποιο μοντέλο τα καταφέρνει καλύτερα στη συγκεκριμένη περίπτωσή μας;»
Ένα μοντέλο που τα πάει εξαιρετικά στη δημιουργία marketing content δεν χρειάζεται να είναι η καλύτερη λύση για την ταξινόμηση εγγράφων, την ανάλυση δεδομένων ή τη διαχείριση επιχειρησιακών διαδικασιών.
Γι' αυτό η σύγκριση μοντέλων θα πρέπει να γίνεται σε πραγματικές εργασίες που καλείται να εκτελέσει το σύστημα.
Πρώτα πρέπει να δημιουργήσουμε το δικό μας σύνολο τεστ
Δεν μπορεί να γίνει ουσιαστική αξιολόγηση ενός συστήματος AI αν δεν ξέρουμε τι περιμένουμε από αυτό.
Γι' αυτό ένα από τα σημαντικότερα στοιχεία της αξιολόγησης είναι η προετοιμασία ενός dataset test, δηλαδή ενός συνόλου πραγματικών ή αντιπροσωπευτικών περιπτώσεων.
Για παράδειγμα, μια εταιρεία χτίζει AI για το τμήμα εξυπηρέτησης πελατών.
Αντί να ελέγχεται χειροκίνητα μία απάντηση μετά από κάθε αλλαγή του prompt, μπορεί να ετοιμαστεί ένα σύνολο μερικών εκατοντάδων περιπτώσεων:
- απλές ερωτήσεις,
- αμφίσημες ερωτήσεις,
- ερωτήσεις που περιέχουν λανθασμένες παραδοχές,
- ερωτήσεις που απαιτούν αναζήτηση εγγράφου,
- ερωτήσεις σχετικά με εξαιρέσεις,
- ερωτήσεις σχετικά με παράπονα,
- ερωτήσεις που απαιτούν άρνηση,
- ερωτήσεις που περιέχουν δεδομένα τα οποία η AI δεν πρέπει να αποκαλύψει.
Κάθε αλλαγή στο σύστημα μπορεί στη συνέχεια να εκτελεστεί πάνω στο ίδιο σύνολο.
Και ακριβώς εδώ η AI αρχίζει να μοιάζει με το κλασικό software.
Δεν δοκιμάζουμε πλέον μία και μόνο απάντηση. Δοκιμάζουμε τη συμπεριφορά του συστήματος σε ολόκληρο το σύνολο περιπτώσεων.
Το prompt μπορεί επίσης να ελεγχθεί
Το prompt συχνά αντιμετωπίζεται σαν κείμενο που κάποιος έγραψε μία φορά και το άφησε στην παραγωγή.
Στην πραγματικότητα μπορεί να είναι στοιχείο της λογικής της εφαρμογής.
Η αλλαγή μίας πρότασης μπορεί να προκαλέσει:
- βελτίωση της απάντησης σε ένα σενάριο,
- επιδείνωση της απάντησης σε ένα άλλο,
- μεγαλύτερη τάση για άρνηση,
- μεγαλύτερο αριθμό hallucinations,
- πιο μακροσκελείς απαντήσεις,
- υψηλότερο κόστος,
- μεγαλύτερη κατανάλωση tokens.
Γι' αυτό το prompt θα πρέπει να αντιμετωπίζεται όπως ο κώδικας.
Αν αλλάζουμε το prompt, αξίζει να ξέρουμε:
- τι βελτιώθηκε;
- τι χειροτέρεψε;
- υπήρξε παλινδρόμηση;
Γι' αυτό ακριβώς αποκτά ολοένα και μεγαλύτερη σημασία η αυτοματοποιημένη αξιολόγηση και όχι η χειροκίνητη κρίση μερικών ενδεικτικών απαντήσεων.
Η AI μπορεί να περάσει το τεστ και παρ' όλα αυτά να είναι κακό προϊόν
Ας υποθέσουμε ότι ετοιμάσαμε 100 δοκιμαστικές περιπτώσεις.
Το σύστημα απάντησε σωστά στις 95. Το αποτέλεσμα φαίνεται εξαιρετικό. Αλλά τι γίνεται αν οι πέντε λανθασμένες απαντήσεις αφορούν κρίσιμες καταστάσεις;
Αν το chatbot απαντά σε ερωτήσεις για τις ώρες λειτουργίας, πέντε λάθη μπορεί να είναι πρόβλημα.
Αν η AI βοηθά έναν εργαζόμενο να αναλύει οικονομικά, ιατρικά ή νομικά έγγραφα, η σημασία αυτών των λαθών μπορεί να είναι εντελώς διαφορετική.
Γι' αυτό ο απλός μέσος όρος δεν αρκεί.
Χρειαζόμαστε επίσης στάθμιση των περιπτώσεων.
Μπορούμε να θεωρήσουμε ότι:
- μια συνηθισμένη ερώτηση έχει βάρος 1,
- ένα σημαντικό σφάλμα έχει βάρος 5,
- ένα σφάλμα ασφάλειας έχει βάρος 10,
- η αποκάλυψη εμπιστευτικής πληροφορίας έχει βάρος 100.
Τότε το σύστημα δεν παίρνει «95 τοις εκατό». Παίρνουμε μια πολύ πιο χρήσιμη εικόνα του κινδύνου.
Δεν μπορεί να μετρηθεί τα πάντα με έναν μόνο αριθμό
Αυτό είναι ένα από τα σημαντικότερα προβλήματα της αξιολόγησης της AI.
Μπορούμε να έχουμε μερικές μετρικές:
- Accuracy - είναι η απάντηση σωστή;
- Relevance - απαντά στην ερώτηση;
- Faithfulness / groundedness - βασίζεται στις παρεχόμενες πηγές;
- Context precision - είναι τα ανακτημένα αποσπάσματα σχετικά;
- Context recall - βρήκε το σύστημα τις απαραίτητες πληροφορίες;
- Safety - δεν εκτελεί ανεπιθύμητες ενέργειες;
- Latency - πόσο χρόνο περιμένει ο χρήστης;
- Cost - πόσο κοστίζει η εκτέλεση της εργασίας;
Το RAG μπορεί λοιπόν να έχει πολύ καλή ποιότητα απάντησης, αλλά ταυτόχρονα να ανακτά τεράστια ποσότητα συμφραζομένων και να δημιουργεί μη αποδεκτό κόστος.
Ένα άλλο σύστημα μπορεί να είναι πολύ φθηνό και γρήγορο, αλλά να κάνει πάρα πολλά λάθη.
Δεν υπάρχει λοιπόν ένας ενιαίος καθολικός αριθμός που να καθορίζει αν η AI είναι «καλή». Η ποιότητα πρέπει να ορίζεται στο πλαίσιο της συγκεκριμένης χρήσης.
Και τι γίνεται με την αξιολόγηση της AI από άλλη AI;
Εδώ εμφανίζεται ένας ακόμη ενδιαφέρων μηχανισμός.
Ένας από τους τρόπους αυτοματοποίησης της αξιολόγησης είναι η χρήση του μοντέλου ως κριτή, δηλαδή LLM-as-a-judge.
Για παράδειγμα:
Το μοντέλο A παράγει απάντηση.
Το μοντέλο B λαμβάνει την ερώτηση, την απάντηση και συγκεκριμένα κριτήρια.
Στη συνέχεια αξιολογεί:
- ορθότητα,
- συμμόρφωση με τις οδηγίες,
- πληρότητα,
- στυλ,
- ασφάλεια.
Τα σύγχρονα εργαλεία αξιολόγησης επιτρέπουν επίσης να συνδυάζεται αυτή η αξιολόγηση με κλασικές συγκρίσεις κειμένου, δικά τους scripts ή graders βασισμένους σε συγκεκριμένους κανόνες.
Αυτό αυξάνει τεράστια την κλίμακα των δοκιμών. Αλλά δεν σημαίνει ότι ο άνθρωπος παύει να είναι απαραίτητος. Το μοντέλο που αξιολογεί μπορεί επίσης να κάνει λάθος. Γι’ αυτό σε συστήματα μεγαλύτερης επιχειρηματικής σημασίας αξίζει να συνδυάζονται οι αυτοματοποιημένες αξιολογήσεις με περιοδική αξιολόγηση από ειδικούς.
Το μεγαλύτερο πρόβλημα: η παλινδρόμηση
Ας φανταστούμε ένα σύστημα που λειτουργεί πολύ καλά. Η ομάδα αλλάζει το μοντέλο σε μια νεότερη έκδοση. Η νέα έκδοση είναι ταχύτερη και φθηνότερη. Φαίνεται λοιπόν ότι όλα πηγαίνουν προς τη σωστή κατεύθυνση.
Μετά την ανάπτυξη όμως αποδεικνύεται ότι:
- οι απαντήσεις είναι λιγότερο ακριβείς,
- το μοντέλο αρνείται συχνότερα να απαντήσει,
- χρησιμοποιεί χειρότερα την τεκμηρίωση,
- ερμηνεύει διαφορετικά τις οδηγίες,
- σε ορισμένα σενάρια αρχίζει να δίνει λανθασμένες πληροφορίες.
Αυτό ακριβώς είναι η AI regression.
Στο κλασικό λογισμικό γνωρίζουμε την παλινδρόμηση εδώ και χρόνια. Στην AI πρέπει επίσης να την ανιχνεύουμε, αλλά το πρόβλημα είναι δυσκολότερο, επειδή η συμπεριφορά του συστήματος μπορεί να αλλάξει χωρίς κλασικό «σφάλμα». Γι’ αυτό κάθε μεγαλύτερη αλλαγή πρέπει να συγκρίνεται με την προηγούμενη έκδοση.
Μοντέλο.
Prompt.
Embedding.
Retriever.
Τεκμηρίωση.
Λογική του agent.
Παράμετροι.
Κάθε ένα από αυτά τα στοιχεία μπορεί να επηρεάσει το αποτέλεσμα.
Δεν αρκεί να αξιολογήσεις τον agent μόνο από την τελική του απάντηση
Ακόμη πιο δύσκολα γίνονται τα πράγματα στην περίπτωση των AI agents.
Ένα κλασικό chatbot μπορεί να εκτελέσει μία εργασία: ερώτηση → απάντηση.
Ο agent μπορεί να λειτουργεί τελείως διαφορετικά: στόχος → σχέδιο → εργαλείο → αποτέλεσμα → επόμενο βήμα → απόφαση → ενέργεια → απάντηση.
Αν ο agent δεν πέτυχε τον στόχο, θέλουμε να ξέρουμε όχι μόνο ότι έχασε.
Θέλουμε να ξέρουμε: πού έκανε το λάθος;
- Κατάλαβε λάθος την εργασία;
- Επέλεξε λάθος εργαλείο;
- Πέρασε λάθος παράμετρο;
- Ανέκτησε λάθος δεδομένα;
- Πήρε λάθος απόφαση αφού έλαβε το αποτέλεσμα;
- Έκανε πάρα πολλά βήματα;
- Σταμάτησε πολύ νωρίς;
Στην έρευνα για την αξιολόγηση των agents αναλύεται όλο και συχνότερα όχι μόνο το τελικό αποτέλεσμα, αλλά και η ροή της δράσης, η χρήση εργαλείων, ο σχεδιασμός, η μνήμη, η αξιοπιστία και η ασφάλεια.
Αυτό σημαίνει ότι το μέλλον των δοκιμών της AI θα συνδέεται σε μεγάλο βαθμό με την ανάλυση των trace'ów, δηλαδή της πλήρους ροής λειτουργίας του συστήματος.
Η AI χρειάζεται κάτι παρόμοιο με το CI/CD
Αν η AI είναι μέρος του προϊόντος, δεν μπορείς να το δοκιμάζεις μόνο πριν από την πρώτη ανάπτυξη.
Το σύστημα θα αλλάζει.
Το μοντέλο θα αλλάζει.
Το prompt θα αλλάζει.
Η βάση γνώσης θα αλλάζει.
Ο τρόπος αναζήτησης θα αλλάζει.
Η διαμόρφωση θα αλλάζει.
Γι’ αυτό η αξιολόγηση πρέπει να ενταχθεί στη διαδικασία ανάπτυξης.
Το σχήμα μπορεί να είναι το εξής: αλλαγή → δοκιμές → αξιολόγηση → σύγκριση με την προηγούμενη έκδοση → απόφαση για ανάπτυξη
Αν η νέα έκδοση βελτιώνει την ποιότητα σε έναν τομέα, αλλά υπερβαίνει το καθορισμένο όριο σφαλμάτων σε έναν άλλο, το deployment μπορεί να σταματήσει.
Είναι μια πολύ παρόμοια φιλοσοφία με το κλασικό CI/CD, αλλά τα κριτήρια είναι διαφορετικά.
Στην περίπτωση εφαρμογών AI μπορούμε να ελέγχουμε ταυτόχρονα την ποιότητα της απάντησης, την ορθότητα, την ασφάλεια, το κόστος και την καθυστέρηση. Ήδη εμφανίζονται ερευνητικές λύσεις που συνδυάζουν την αξιολόγηση με το observability και τις πύλες ποιότητας στη διαδικασία ανάπτυξης συστημάτων LLM/RAG.
Μπορεί λοιπόν η AI να δοκιμάζεται όπως το κλασικό λογισμικό;
Ναι, αλλά μόνο εν μέρει.
Η κλασική προσέγγιση εξακολουθεί να είναι απαραίτητη.
Δοκιμάζουμε:
- API,
- ενσωματώσεις,
- δικαιώματα,
- επικύρωση δεδομένων,
- σφάλματα,
- timeouts,
- ασφάλεια,
- απόδοση,
- λογική της εφαρμογής.
Αλλά δεν μπορούμε να σταματήσουμε εκεί.
Προστίθεται ένα δεύτερο επίπεδο: αξιολόγηση της συμπεριφοράς της AI.
- Είναι η απάντηση σωστή;
- Είναι σύμφωνη με τις πηγές;
- Το μοντέλο ακολουθεί τις οδηγίες;
- Συμπεριφέρεται σωστά το σύστημα σε απρόβλεπτες καταστάσεις;
- Ο agent επιλέγει τα σωστά εργαλεία;
- Η νέα έκδοση δεν υποβάθμισε την ποιότητα;
- Το κόστος λειτουργίας παραμένει αποδεκτό;
- Λαμβάνει ο χρήστης πραγματικά αξία;
Αυτό δεν είναι πλέον κλασικό unit test.
Το καλύτερο τεστ AI δεν είναι πάντα εργαστηριακό τεστ
Υπάρχει ακόμη ένα πολύ σημαντικό στοιχείο.
Το σύστημα μπορεί να αποδίδει εξαιρετικά σε ένα προετοιμασμένο σύνολο δοκιμών, και παρ’ όλα αυτά να έχει προβλήματα στον πραγματικό κόσμο. Γι’ αυτό αξίζει να παρακολουθούμε και τις πραγματικές αλληλεπιδράσεις. Όχι για να είναι κάθε χρήστης tester. Πρόκειται για το να μπορεί το σύστημα να βελτιώνεται συνεχώς με βάση πραγματικές περιπτώσεις:
- όπου οι χρήστες διορθώνουν την AI,
- όπου ζητούν επανάληψη της απάντησης,
- όπου διακόπτουν τη συνομιλία,
- όπου κλιμακώνουν το θέμα σε άνθρωπο,
- όπου ο agent δεν πετυχαίνει τον στόχο,
- όπου εμφανίζονται ασυνήθιστες ερωτήσεις.
Με αυτόν τον τρόπο δημιουργείται ένας συνεχής βρόχος αξιολόγησης: χρήστης → ενέργεια AI → αποτέλεσμα → ανάλυση → νέο test case → επόμενη έκδοση του συστήματος
Αυτό είναι ένα εντελώς διαφορετικό μοντέλο ανάπτυξης από το μοτίβο «βάλαμε AI και λειτουργεί».
Η AI δεν θα πρέπει να αξιολογείται με το ερώτημα «λειτουργεί;»
Αυτό δεν αρκεί.
Καλύτερα ερωτήματα είναι:
- Πόσο συχνά λειτουργεί σωστά;
- Σε ποιες καταστάσεις κάνει λάθος;
- Πόσο σοβαρά είναι αυτά τα λάθη;
- Είναι η νέα έκδοση καλύτερη από την προηγούμενη;
- Είναι το σύστημα αρκετά ασφαλές;
- Βασίζονται οι απαντήσεις στα σωστά δεδομένα;
- Πόσο κοστίζει η επίτευξη ενός συγκεκριμένου αποτελέσματος;
Μόνο ένα τέτοιο σύνολο ερωτημάτων επιτρέπει να μιλάμε για ένα ώριμο σύστημα AI.
Η σημαντικότερη αλλαγή στη σκέψη
Για χρόνια στην ανάπτυξη λογισμικού ίσχυε ένας απλός κανόνας: ο κώδικας πρέπει να λειτουργεί.
Στα συστήματα AI πρέπει να τον επεκτείνουμε: το σύστημα πρέπει να λειτουργεί καλά, προβλέψιμα και μετρήσιμα.
Αυτή είναι τεράστια διαφορά. Επειδή η AI δεν είναι μια λειτουργία που επιστρέφει πάντα το ίδιο αποτέλεσμα. Είναι ένα πιθανοτικό σύστημα, του οποίου η συμπεριφορά εξαρτάται από το μοντέλο, τα δεδομένα, το πλαίσιο, τις οδηγίες και ολόκληρη την αρχιτεκτονική γύρω του.
Γι’ αυτό η επαγγελματική υλοποίηση AI δεν τελειώνει τη στιγμή που το μοντέλο αρχίζει να απαντά.
Τότε μόλις αρχίζει το ερώτημα: πώς ξέρουμε ότι μπορούμε να το εμπιστευτούμε;
Και ακριβώς σε αυτό το ερώτημα θα πρέπει να απαντά μια καλά σχεδιασμένη αξιολόγηση.
Στο μέλλον, ο έλεγχος συστημάτων AI πιθανότατα θα γίνει τόσο φυσικό στοιχείο της διαδικασίας ανάπτυξης όσο τα unit tests, τα integration tests ή το monitoring. Όχι επειδή η AI είναι «επικίνδυνη εκ φύσεως». Απλώς επειδή ένα σύστημα του οποίου το αποτέλεσμα δεν είναι πάντα ντετερμινιστικό απαιτεί διαφορετικό τρόπο μέτρησης της ποιότητας.
Και όσο περισσότερο η AI περνά από τη δημιουργία κειμένου στην υποστήριξη πραγματικών διαδικασιών, στη χρήση δεδομένων, στο RAG και στην εκτέλεση ενεργειών μέσω agents, τόσο πιο σημαντικό γίνεται όχι μόνο το ερώτημα «μπορεί η AI να το κάνει αυτό;», αλλά και: «μπορούμε να αποδείξουμε ότι το κάνει αρκετά καλά;»
