Αν δεν μπορείς να βάλεις έναν αριθμό στο αν μια αλλαγή έκανε τον agent σου καλύτερο ή χειρότερο, δεν τον μηχανικοποιείς, μαντεύεις με επιπλέον βήματα. Ο πιο συχνός λόγος που τα agent projects κολλάνε δεν είναι ένα αδύναμο μοντέλο, είναι η απουσία ενός eval harness. Χωρίς αυτό, κάθε αλλαγή prompt, αλλαγή εργαλείου και αλλαγή μοντέλου αξιολογείται από κάποιον που κοιτάζει μερικά outputs και δηλώνει ότι "φαίνεται καλύτερο", που είναι ο τρόπος να κυκλοφορήσεις μια οπισθοδρόμηση και να το μάθεις από έναν χρήστη. Ο πίνακας βαθμολογίας πρέπει να υπάρχει πριν τον agent, γιατί δεν μπορείς να βελτιώσεις ό,τι δεν μπορείς να βαθμολογήσεις.

Το reframing: ένα σετ evals είναι το test suite σου για πιθανοκρατικό κώδικα. Δεν θα κάνες refactor μια υπηρεσία χωρίς tests και δεν θα την κυκλοφορούσες με βάση το ότι φαίνεται εντάξει. Ένας agent είναι πιο δύσκολο να αιτιολογηθεί από εκείνη την υπηρεσία, όχι λιγότερο, οπότε χρειάζεται τον πίνακα βαθμολογίας περισσότερο, όχι λιγότερο.

Χτίσε το harness πριν τον agent

Ένα eval harness δεν είναι εντυπωσιακό και είναι μικρό στην αρχή: ένα σετ αντιπροσωπευτικών εισόδων, έναν ορισμό ενός καλού output για κάθε μία, και έναν τρόπο να τρέξεις το τρέχον σύστημα απέναντι σε όλα και να πάρεις βαθμολογία. Είκοσι έως πενήντα πραγματικά παραδείγματα, αντλημένα από πραγματική ή αναμενόμενη κίνηση, νικούν χίλια συνθετικά. Το νόημα είναι ένας σταθερός χάρακας, ώστε το "βελτιώσαμε τον agent" να γίνει ένας ισχυρισμός που μπορείς να ελέγξεις αντί για συναίσθημα.

Μόλις υπάρξει, η ροή εργασίας αντιστρέφεται. Κάθε αλλαγή, νέο prompt, νέο εργαλείο, νέο μοντέλο, τρέχει πρώτα απέναντι στο harness. Μια αλλαγή που ανεβάζει τη βαθμολογία κυκλοφορεί, μια αλλαγή που την κατεβάζει όχι, ανεξάρτητα από το πόσο έξυπνη φαινόταν. Στο Bedrock, το Model Evaluation σου δίνει μια managed διαδρομή για αυτό, με αυτόματες μετρικές και ανθρώπινη αναθεώρηση, και έγινε γενικά διαθέσιμο πολύ πριν χρειαστεί εδώ. Το εργαλείο έχει λιγότερη σημασία από την πειθαρχία: βαθμολόγησε, μετά αποφάσισε.

LLM-as-a-judge, και πού σου λέει ψέματα

Η βαθμολόγηση ανοιχτών outputs με το χέρι δεν κλιμακώνεται, οπότε η τυπική κίνηση είναι να χρησιμοποιήσεις ένα μοντέλο ως κριτή: δώσε σε ένα ισχυρό μοντέλο την είσοδο, το output του agent και έναν οδηγό βαθμολόγησης, και ζήτησέ του να βαθμολογήσει. Το Bedrock Model Evaluation υποστηρίζει ακριβώς αυτό. Είναι γνήσια χρήσιμο και είναι επίσης ένας κρίκος που μπορεί να λαθεύει, κάτι που οι ομάδες ξεχνούν τη στιγμή που αρχίζει να παράγει τακτοποιημένους αριθμούς.

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

  • Προκατάληψη θέσης και φλυαρίας. Οι κριτές τείνουν να προτιμούν την πρώτη επιλογή που δείχνεται και την πιο μακριά, πιο σίγουρη απάντηση, ανεξάρτητα από ορθότητα. Τυχαιοποίησε τη σειρά και έλεγξε το μήκος.
  • Αυτο-προτίμηση. Ένας κριτής από την ίδια οικογένεια μοντέλων μπορεί να βαθμολογεί ψηλότερα τα outputs από τη δική του οικογένεια. Όπου έχει σημασία, χρησιμοποίησε κριτή από διαφορετική οικογένεια από το μοντέλο υπό δοκιμή.
  • Ολίσθηση οδηγού βαθμολόγησης. Ένας ασαφής οδηγός ("είναι καλή αυτή η απάντηση") παράγει ασαφείς, ασταθείς βαθμολογίες. Ένας συγκεκριμένος οδηγός ("η απάντηση παραπέμπει στην ενότητα πολιτικής, και είναι σωστή η ενότητα που παραπέμπει") παράγει βαθμολογίες που μπορείς να αξιοποιήσεις.
  • Σίγουρη συμφωνία με λάθος απάντηση. Αν η είσοδος περιέχει μια ψευδή προϋπόθεση, ο κριτής μπορεί να ανταμείψει ένα output που συμφωνεί μαζί της. Συμπεριέλαβε αντιπαραθετικές περιπτώσεις όπου η σωστή συμπεριφορά είναι να αρνηθεί ή να διορθώσει.

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

Βαθμολόγησε τη διαδρομή, όχι μόνο την απάντηση

Για agents συγκεκριμένα, η τελική απάντηση είναι μόνο το μισό από αυτό που σε ενδιαφέρει. Ένας agent μπορεί να παράγει σωστή απάντηση με λάθος διαδρομή: καλώντας ένα εργαλείο που δεν έπρεπε, ξοδεύοντας δέκα βήματα σε μια εργασία δύο βημάτων, ή διαρρέοντας δεδομένα σε ένα log στην πορεία. Αξιολόγησε τη διαδρομή όσο και το output. Χρησιμοποίησε τα αναμενόμενα εργαλεία; Έμεινε μέσα στις επιτρεπόμενες ενέργειές του; Ολοκλήρωσε σε λογικό αριθμό βημάτων; Ένας agent που παίρνει τη σωστή απάντηση ενώ καλεί ένα delete API που δεν έπρεπε ποτέ να αγγίξει έχει αποτύχει το eval, ό,τι κι αν λέει το τελικό κείμενο.

Το συμπέρασμα

Η σειρά δεν είναι διαπραγματεύσιμη: πρώτα το eval harness, μετά ο agent. Το harness είναι ένα μικρό, σταθερό σετ πραγματικών εισόδων με ορισμένα καλά outputs και μια επαναλήψιμη βαθμολογία, και μετατρέπει κάθε αλλαγή από απλή εντύπωση σε μετρημένη απόφαση. Χρησιμοποίησε έναν LLM-as-a-judge για να κλιμακώσεις τη βαθμολόγηση, αλλά αντιμετώπισέ τον ως κρίκο που μπορεί να λαθεύει: έλεγξε τις προκαταλήψεις του, δώσε του συγκεκριμένο οδηγό βαθμολόγησης, και βαθμονόμησέ τον απέναντι σε ανθρώπινες ετικέτες. Βαθμολόγησε τη διαδρομή, όχι μόνο το αποτέλεσμα. Δεν μπορείς να κυκλοφορήσεις ό,τι δεν μπορείς να βαθμολογήσεις, και οι ομάδες που κυκλοφορούν αξιόπιστους agents είναι αυτές που χτίσανε τον πίνακα βαθμολογίας πριν χτίσουν τον παίκτη.

Διάβασε αυτό στη συνέχεια

  • Bedrock Agents vs Rolling Your Own Loop, για την επιλογή του orchestration που το harness είναι εκεί για να κρατά έντιμο.
  • Structured Output Beats Clever Parsing, για το πώς κάνεις τα outputs ελέγξιμα από μηχανή ώστε ένα eval να μπορεί να τα βαθμολογήσει χωρίς μαντεψιά.

Για την πλευρά πλατφόρμας της ενσωμάτωσης evals σε ένα pipeline παράδοσης, οι σημειώσεις πεδίου cloud βρίσκονται στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.