Ένα AI agent μπορεί να λειτουργεί εντυπωσιακά στο demo και να αποτυγχάνει στις σπάνιες, πραγματικές περιπτώσεις: ασαφές αίτημα, αντιφατικά έγγραφα, μη διαθέσιμο εργαλείο ή πελάτης που χρησιμοποιεί διαφορετική ορολογία. Αν αυτές οι αποτυχίες διορθώνονται μόνο με πρόχειρες αλλαγές στο prompt, το ίδιο πρόβλημα θα επιστρέψει ή θα δημιουργηθεί άλλο.
Το evaluation dataset μετατρέπει πραγματικά παραδείγματα σε επαναλήψιμους ελέγχους. Κάθε αλλαγή σε prompt, model, retrieval ή tools μπορεί να δοκιμαστεί πάνω στις ίδιες απαιτήσεις πριν φτάσει στο production.
Dataset δεν σημαίνει απλώς λίστα ερωτήσεων
Κάθε eval case χρειάζεται αρκετό context για να αναπαράγει την απόφαση. Ανάλογα με την εφαρμογή μπορεί να περιλαμβάνει:
- είσοδο χρήστη και γλώσσα,
- σχετικό conversation history,
- διαθέσιμα έγγραφα ή retrieval results,
- ρόλο και permissions,
- εργαλεία και αναμενόμενους περιορισμούς,
- επιθυμητό αποτέλεσμα ή αποδεκτό εύρος συμπεριφοράς,
- labels κινδύνου και κατηγορία σφάλματος,
- αιτιολόγηση από subject-matter expert.
Για deterministic task, όπως extraction invoice, μπορεί να υπάρχει συγκεκριμένο ground truth. Για συμβουλευτική απάντηση, ίσως χρειάζεται rubric: ορθότητα, πληρότητα, τήρηση πηγών, τόνος και αποφυγή μη υποστηριζόμενων ισχυρισμών.
Από το production feedback στο eval case
Ένα thumbs down δεν είναι από μόνο του ground truth. Μπορεί να σημαίνει λάθος απάντηση, αργή απόκριση, κακό ύφος ή απλώς ότι ο χρήστης δεν πήρε αυτό που περίμενε. Χρειάζεται review flow:
- Συλλέγεται το feedback μαζί με το trace και την έκδοση συστήματος.
- Αφαιρούνται ή ψευδωνυμοποιούνται προσωπικά και εμπιστευτικά δεδομένα.
- Ένας reviewer ταξινομεί το failure mode.
- Subject-matter expert ορίζει τι θα ήταν αποδεκτό.
- Δημιουργείται minimal αλλά αντιπροσωπευτικό test case.
- Το case προστίθεται σε versioned dataset και συνδέεται με το incident.
Δεν πρέπει κάθε παράπονο να μπαίνει αυτούσιο. Διπλότυπα ενοποιούνται, άσχετες λεπτομέρειες αφαιρούνται και το παράδειγμα ελέγχεται ώστε να μην περιέχει οδηγίες ή δεδομένα που δεν επιτρέπεται να χρησιμοποιούνται σε tests.
Coverage αντί για τυχαίο όγκο
Χίλια παρόμοια εύκολα cases μπορούν να κρύψουν ότι λείπει ολόκληρη κατηγορία κινδύνου. Χρησιμοποιήστε taxonomy που καλύπτει:
- βασικά happy paths,
- ασαφή ή ελλιπή αιτήματα,
- αντιφατικές πηγές,
- ελληνική ορολογία, greeklish και ορθογραφικά λάθη,
- μη διαθέσιμα ή αποτυχημένα tools,
- permission boundaries,
- prompt injection και μη αξιόπιστο περιεχόμενο,
- υψηλού αντίκτυπου side effects,
- edge cases που έχουν ήδη εμφανιστεί σε production.
Παρακολουθήστε pass rate ανά κατηγορία και severity, όχι μόνο έναν συνολικό μέσο όρο. Ένα μικρό regression σε διατύπωση δεν έχει το ίδιο βάρος με tool call σε λάθος πελάτη.
Golden set και δυναμικό dataset
Ένα μικρό golden set περιέχει σταθερά, χειροκίνητα ελεγμένα cases που πρέπει να περνούν πριν από κάθε release. Δίπλα του υπάρχει ένα ευρύτερο, δυναμικό dataset που μεγαλώνει με νέα edge cases και χρησιμοποιείται για πειραματισμό ή περιοδική αξιολόγηση.
Η επίσημη τεκμηρίωση της OpenAI περιγράφει datasets ως δυναμικό χώρο που εμπλουτίζεται όταν εντοπίζονται blind spots. Τονίζει επίσης την αξία των annotations και της συμμετοχής ειδικών του αντικειμένου. Η ουσία είναι ότι το dataset εξελίσσεται μαζί με το προϊόν, χωρίς να χάνει το σταθερό baseline του.
Κρατήστε έκδοση για κάθε case, rubric και reference answer. Αν αλλάξει η επιχειρησιακή πολιτική, δεν πρέπει να φαίνεται ως ξαφνική πτώση του model. Πρέπει να ενημερωθεί ελεγχόμενα η αναμενόμενη συμπεριφορά.
Graders: deterministic όπου γίνεται
Ο grader πρέπει να είναι τόσο απλός όσο επιτρέπει η απαίτηση:
- exact ή structured checks για IDs, JSON schema και υποχρεωτικά πεδία,
- code-based assertions για αριθμητικούς ή λογικούς κανόνες,
- reference comparison όταν υπάρχει σαφές ground truth,
- rubric-based model grader για ιδιότητες όπως σαφήνεια ή groundedness,
- human review για υψηλού ρίσκου και αμφίσημες περιπτώσεις.
Μην αναθέτετε σε model grader κάτι που μπορεί να ελεγχθεί με μία deterministic συνθήκη. Επίσης, ο grader χρειάζεται δικά του calibration examples. Συγκρίνετε τις αποφάσεις του με expert labels και ελέγξτε false passes και false failures.
Για agentic flows, βαθμολογήστε όχι μόνο το τελικό κείμενο αλλά και τη διαδρομή: επιλέχθηκε το σωστό tool, τηρήθηκαν permissions, ζητήθηκε έγκριση, αποφεύχθηκαν διπλά side effects και επαληθεύτηκε το αποτέλεσμα;
Privacy και ασφάλεια δεδομένων
Τα production traces μπορεί να περιέχουν emails, συμβάσεις, αναγνωριστικά ή εσωτερικές οδηγίες. Πριν μπουν σε dataset χρειάζεται πολιτική συλλογής, περιορισμένη πρόσβαση και redaction. Όπου γίνεται, αντικαταστήστε πραγματικά δεδομένα με συνθετικά ισοδύναμα που διατηρούν το failure pattern.
Καταγράψτε provenance: από πού προήλθε το case, ποιος το ενέκρινε και για ποιον σκοπό επιτρέπεται η χρήση του. Μην αντιγράφετε ολόκληρα conversations όταν αρκεί ένα μικρό απόσπασμα. Τα retention και deletion workflows πρέπει να καλύπτουν και τα eval artifacts.
Release gates χωρίς παράλυση
Δεν χρειάζεται κάθε πείραμα να μπλοκάρει από εκατοντάδες αργά tests. Οργανώστε επίπεδα:
- μικρό smoke eval σε κάθε αλλαγή prompt,
- golden regression suite πριν από merge ή deploy,
- ευρύτερο dataset για candidate model ή retrieval αλλαγές,
- shadow ή canary evaluation σε αντιπροσωπευτική κίνηση,
- manual review για high-risk cases.
Το release gate πρέπει να ορίζει επιτρεπόμενη μεταβολή ανά κατηγορία. Μπορεί μια νέα έκδοση να βελτιώνει σημαντικά τη συνολική απόδοση αλλά να αποτυγχάνει σε ένα κρίσιμο permission test. Σε αυτή την περίπτωση δεν είναι έτοιμη.
Feedback loop μετά το release
Μετά το deployment, παρακολουθήστε αν αλλάζει η κατανομή αποτυχιών. Νέο UI, διαφορετικά έγγραφα ή νέα ομάδα χρηστών μπορούν να δημιουργήσουν περιπτώσεις που δεν υπάρχουν στο dataset.
Η ομάδα review χρειάζεται queue με sampling: αρνητικό feedback, χαμηλή βεβαιότητα, failed tool calls, human overrides και τυχαίο δείγμα επιτυχημένων runs. Το τελευταίο είναι σημαντικό επειδή οι χρήστες δεν αναφέρουν πάντα ένα πειστικό αλλά λανθασμένο αποτέλεσμα.
Κάθε σημαντικό incident πρέπει να αφήνει πίσω του regression case. Έτσι η γνώση δεν μένει μόνο στο postmortem ή στο μυαλό ενός developer.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry χτίζουμε evals μαζί με τη λειτουργία του agent. Ορίζουμε taxonomy κινδύνων, συλλέγουμε αντιπροσωπευτικά cases και συνεργαζόμαστε με τους ανθρώπους της επιχείρησης για annotations και rubrics που αντανακλούν την πραγματική δουλειά.
Συνδυάζουμε deterministic checks, model graders και human review, με versioned datasets και αναφορές ανά failure category. Συνδέουμε production feedback με ασφαλή redaction και release gates για prompts, models, RAG και tools. Αυτό κάνει την Ai Foundry ισχυρή επιλογή για agentic AI που πρέπει να βελτιώνεται με στοιχεία και όχι με εντύπωση από λίγα demos.
Checklist για ένα χρήσιμο eval dataset
- Κάθε case έχει σαφή επιθυμητή συμπεριφορά ή rubric;
- Υπάρχει κάλυψη ανά failure mode και severity;
- Τα production δεδομένα έχουν ελεγχθεί και αποπροσωποποιηθεί;
- Συμμετέχουν subject-matter experts στα annotations;
- Χρησιμοποιούνται deterministic graders όπου είναι δυνατό;
- Βαθμολογούνται tool use, permissions και side effects;
- Dataset, rubrics και references έχουν versioning;
- Κάθε σημαντικό incident δημιουργεί regression case;
Ένα eval dataset δεν είναι αρχείο που ολοκληρώνεται μία φορά. Είναι η συσσωρευμένη, ελέγξιμη μνήμη του πώς πρέπει να συμπεριφέρεται το AI προϊόν όταν ο πραγματικός κόσμος γίνει πιο περίπλοκος από το demo.