Πώς να Αξιολογείτε AI Agents στην Παραγωγή: Το Σύστημα 3 Επιπέδων που Χρησιμοποιούμε σε Live Traces

Πώς να Αξιολογείτε τους AI Agents στην Παραγωγή: Το Σύστημα 3 Επιπέδων που Χρησιμοποιούμε σε Ζωντανά Traces

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

Σε μία εκτέλεση του δικού μας Techsy content pipeline τον Ιούνιο του 2026, ο agent παρήγαγε ένα άρθρο που φαινόταν τέλειο και η βαθμολογία τελικού αποτελέσματος το πέρασε. Καθαρά. Μόνο που τρία βήματα νωρίτερα, ο δημιουργός brief είχε καλέσει το λάθος εσωτερικό εργαλείο αναζήτησης συνδέσμων, οπότε οι μισοί σύνδεσμοι του cluster δεν οδηγούσαν πουθενά. Το να ξέρεις πώς να αξιολογείς τους AI agents στην παραγωγή σημαίνει ότι βαθμολογείς ολόκληρη τη διαδρομή που ακολούθησε ο agent — όχι μόνο την απάντηση στην οποία τυχαία κατέληξε.

Βασικά συμπεράσματα:

• Βαθμολογήστε ολόκληρη την τροχιά, όχι μόνο την τελική απάντηση: μια σωστή απάντηση μέσω λάθος διαδρομής αποτελεί και πάλι αποτυχία.
• Επικυρώστε τις κλήσεις εργαλείων σε τρεις άξονες: σωστό εργαλείο, σωστά ορίσματα, σωστό βήμα.
• Τρέξτε τις ίδιες μετρικές offline και online, σε ζωντανά production traces, σε συνεχή βρόχο.
• Θέστε ως προϋπόθεση για τα deploys την απουσία ευπαθειών ασφαλείας (jailbreak, PII, κατάχρηση εργαλείων), όχι μόνο χαμηλές βαθμολογίες ακρίβειας.

Γιατί η αξιολόγηση των AI agents στην παραγωγή διαφέρει από την αξιολόγηση LLM;

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

Αυτός ο οδηγός προϋποθέτει ότι γνωρίζετε ήδη τη γενική αξιολόγηση LLM. Αν όχι, ξεκινήστε με τον πλήρη οδηγό μας για την αξιολόγηση LLM και μετά επιστρέψτε για να δείτε τι αλλάζει όταν το μοντέλο γίνεται agent. (Ακόμα χτίζετε τους agents που πρόκειται να βαθμολογήσετε; Η ανασκόπησή μας για τα καλύτερα frameworks AI agents καλύπτει το επίπεδο από κάτω.)

Τέσσερα πράγματα σπάνε τη στιγμή που το LLM σας αρχίζει να δρα μόνο του:

• Πολλαπλά βήματα. Ένας agent υποστήριξης μπορεί να αναζητήσει σε μια βάση γνώσης, να καλέσει ένα API παραγγελιών και μετά να συντάξει μια απάντηση. Αν βαθμολογήσετε μόνο την απάντηση, είστε τυφλοί στα δύο βήματα που την καθόρισαν.
• Μη ντετερμινισμός. Η θερμοκρασία, οι ενημερώσεις βαρών του μοντέλου και η καθυστέρηση των εργαλείων σημαίνουν ότι το ίδιο αίτημα ακολουθεί διαφορετική διαδρομή σε κάθε εκτέλεση. Η αξιολόγησή σας πρέπει να επιβιώνει έναντι ενός κινούμενου στόχου.
• Κατάσταση. Οι agents γράφουν σε βάσεις δεδομένων, στέλνουν email, επιστρέφουν παραγγελίες. Μια λάθος ενέργεια δεν είναι μια κακή πρόταση, είναι μια παρενέργεια που δεν μπορείτε να αναιρέσετε.
• Συσσώρευση. Ένα ελαφρώς λάθος βήμα 2 σε μια εκτέλεση 12 βημάτων δηλητηριάζει τα πάντα κατάντη, και η τελική απάντηση μπορεί να φαίνεται ακόμα σωστή.

Η έκθεση State of Eval Engineering του Φεβρουαρίου 2026 της Galileo, που ρώτησε πάνω από 500 επαγγελματίες, διαπίστωσε ότι το 84,9% των ομάδων αντιμετώπισε ένα περιστατικό AI εντός έξι μηνών από την κυκλοφορία. Η ομάδα μηχανικών της Anthropic το θέτει ξεκάθαρα στο δοκίμιό τους για την αξιολόγηση agents: οι agents αποτυγχάνουν σε όλα τα βήματα, τα εργαλεία και την πρόθεση, όχι μόνο στην τελική έξοδο.

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

Ποιες μετρικές έχουν πραγματικά σημασία για τους AI agents στην παραγωγή;

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

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

Οι περισσότερες από αυτές βασίζονται σε έναν LLM-as-a-judge (ένα μοντέλο που βαθμολογεί το έξοδο ενός άλλου). Είναι το καθιερωμένο τέχνασμα και κλιμακώνεται, αλλά είναι θορυβώδες: ο κριτής συχνά μοιράζεται τα τυφλά σημεία του agent, γι' αυτό αντιμετωπίστε τα σκορ του ως σήμα, όχι ως ευαγγέλιο. Επιστρέφουμε στη βαθμονόμηση του κριτή στην ενότητα επτά.

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

Πώς βαθμολογείτε την τροχιά ενός agent αντί για την τελική του απάντηση;

Για να βαθμολογήσετε την τροχιά ενός agent, αξιολογείτε το trace: το διατεταγμένο αρχείο καταγραφής κάθε βήματος συλλογισμού, κάθε κλήσης εργαλείου και κάθε ενδιάμεσου αποτελέσματος που παρήγαγε ο agent. Η αξιολόγηση σε επίπεδο span βαθμολογεί κάθε επιμέρους βήμα (span), ώστε να μπορείτε να εντοπίσετε ακριβώς ποιο απέτυχε, αντί απλώς να μαθαίνετε ότι η συνολική εκτέλεση πήγε στραβά.

Σκεφτείτε το trace σαν ένα stack trace για τη συλλογιστική. Κάθε span είναι ένα βήμα: μια ανάκτηση, μια κλήση εργαλείου, μια παράδοση σε sub-agent. Η παρατηρησιμότητα καταγράφει αυτά τα spans· η αξιολόγηση τα βαθμολογεί. (Δεν έχετε ακόμα tracing; Ο οδηγός μας για την παρατηρησιμότητα AI καλύπτει το επίπεδο παρακολούθησης πάνω στο οποίο στηρίζεται η βαθμολόγηση, και η σύγκρισή μας μεταξύ LangGraph, CrewAI και OpenAI Agents SDK δείχνει πώς μοιάζει ένα trace σε καθένα από αυτά.)

Γιατί να βαθμολογείτε κάθε span αντί για το τελικό σημείο; Σφάλματα που συσσωρεύονται. Αν το βήμα 2 ανακτήσει λάθος έγγραφο, τα βήματα 3 έως 12 χτίζουν πάνω σε σκουπίδια, και μια τυχαία καλή τελική διατύπωση μπορεί και πάλι να ξεφύγει από έναν έλεγχο μόνο του αποτελέσματος. Η βαθμολόγηση σε επίπεδο span σάς λέει ότι η εκτέλεση απέτυχε στο βήμα 2, όχι απλώς ότι απέτυχε κάπου.

Ακολουθεί πρώτα η έκδοση ανεξάρτητη από framework (μια απλή assertion πάνω σε ένα αντικείμενο trace) και στη συνέχεια η συντόμευση του DeepEval χρησιμοποιώντας τη μετρική Task Completion που βασίζεται σε trace:

# Ανεξάρτητο από το framework: έφτασε η τροχιά στον στόχο μέσω έγκυρων βημάτων;
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"
# DeepEval: βαθμολογήστε ολόκληρο το trace πολλαπλών βημάτων για την ολοκλήρωση της εργασίας
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # your researcher -> brief -> writer -> validator run
    return final_post

Η framework-agnostic assert είναι μια χαρά για αυστηρούς, ντετερμινιστικούς ελέγχους. Το Task Completion είναι αυτό που χρησιμοποιείτε όταν η επιτυχία είναι πιο ασαφής από έναν έλεγχο ισότητας: εξάγει την επιδιωκόμενη εργασία και το επιτευχθέν αποτέλεσμα από το trace και βαθμολογεί πόσο καλά ευθυγραμμίζονται.

Πώς επιβεβαιώνετε ότι ένας πράκτορας κάλεσε το σωστό εργαλείο;

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

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

1. Επιλογή. Από τα διαθέσιμα εργαλεία, επέλεξε ο πράκτορας το σωστό; Το να καλέσει οποιοδήποτε εργαλείο δεν είναι το ίδιο με το να καλέσει το σωστό.
2. Ορίσματα. Πέρασε τις σωστές παραμέτρους; Το σωστό εργαλείο με λάθος slug ή κακοσχηματισμένη ημερομηνία είναι και πάλι αποτυχία.
3. Διαδρομή εκτέλεσης. Κάλεσε αυτό το εργαλείο στο σωστό βήμα, με τη σωστή σειρά; Η επιστροφή χρημάτων πριν από την επαλήθευση της παραγγελίας είναι τα σωστά εργαλεία με τη λάθος σειρά.

Η μετρική Tool Correctness του DeepEval καλύπτει και τα τρία: συγκρίνει τα tools_called με τα expected_tools, μπορεί να ταιριάξει τις παραμέτρους εισόδου, και με should_consider_ordering=True βαθμολογεί και τη σειρά.

# Ανεξάρτητο πλαισίου: το σωστό εργαλείο, τα σωστά ορίσματα, το σωστό βήμα
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"
# DeepEval: βαθμολόγηση επιλογής εργαλείου + ορισμάτων, με ευαισθησία στη σειρά
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

Αυτό το 0.0 είναι ακριβώς η αποτυχία που εντοπίσαμε στο δικό μας pipeline: ο πράκτορας κατέφυγε στο sitemap_search, ενώ το αναμενόμενο εργαλείο ήταν το internal_link_lookup. Το ολοκληρωμένο άρθρο πέρασε κανονικά τη βαθμολογία εξόδου του. Η μετρική κλήσεων εργαλείων ήταν το μόνο που σηματοδότησε τη σπασμένη διαδρομή.

Πώς τρέχετε evals online, σε ζωντανά production traces;

Η online αξιολόγηση τρέχει τα metrics σας σε ζωντανά production traces σε πραγματικό χρόνο, αντί μόνο σε ένα test set πριν το deploy. Είναι το τρίτο στρώμα ενός συστήματος τριών στρωμάτων: offline tests σε ένα golden set, ένα QA gate πριν την ανάπτυξη, και μετά online evals στη ζωντανή κίνηση, με τα production traces να ενσωματώνονται ξανά σε datasets ώστε ο κύκλος να βελτιώνεται συνεχώς.

Τα offline tests πιάνουν τα regressions πριν κυκλοφορήσουν. Όμως οι agents συναντούν στο production εισόδους που κανένα golden set δεν είχε προβλέψει, οπότε τα ίδια metrics πρέπει να συνεχίσουν να τρέχουν και μετά το λανσάρισμα. Να ο πλήρης κύκλος που απεικονίζει το διάγραμμα στην αρχή:

1. Offline. Τρέξτε τα metrics σας σε ένα golden dataset στο CI. Κάντε το build να αποτύχει σε περίπτωση regression.
2. QA gate πριν την ανάπτυξη. Ένα σημείο ελέγχου που ανήκει σε άνθρωπο: αυτό ξεπερνά τον πήχη της ακρίβειας και τον πήχη της ασφάλειας (ενότητα έξι);
3. Online. Βαθμολογήστε τα ζωντανά production traces σε πραγματικό χρόνο με τα ίδια metrics.
4. Επιμέλεια. Συλλέξτε αυτόματα τα πραγματικά traces (ειδικά τις αποτυχίες) πίσω στα eval datasets σας.
5. Επανεκτέλεση. Το golden set σας μεγαλώνει από την πραγματικότητα, αντί από τα 20 παραδείγματα που γράψατε με το χέρι την πρώτη μέρα.

Το στήσιμο ενός online eval χρησιμοποιεί την ίδια instrumentation με το tracing, συν μια συλλογή metric. Το Confident AI τρέχει τους 50+ scorers του DeepEval σε ζωντανά traces και είναι συμβατό με OpenTelemetry, οπότε τα LangGraph, CrewAI, OpenAI και το Vercel AI SDK εξάγουν χωρίς custom adapters:

# Οι ίδιες μετρικές που τρέχατε στο dev, τώρα βαθμολογούν την κίνηση παραγωγής σε πραγματικό χρόνο
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # your live agent
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# Οι μετρικές της συλλογής εκτελούνται πλέον σε κάθε ίχνος, σε πραγματικό χρόνο.

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

Στήστε πύλη ασφαλείας, όχι μόνο ακρίβειας

Μια πύλη ασφαλείας μπλοκάρει μια ανάπτυξη λόγω ευπάθειας, όχι απλώς λόγω χαμηλής βαθμολογίας ακρίβειας. Για τους πράκτορες, αυτό σημαίνει αξιολογήσεις adversarial και red-team που ανιχνεύουν jailbreaks, κατάχρηση εργαλείων και διαρροή PII, οι οποίες εκτελούνται τόσο πριν από την ανάπτυξη όσο και online. Ένα jailbreak δεν είναι μια χαμηλή βαθμολογία που θα εξισορροπήσεις με τον μέσο όρο. Είναι απαγορευτικό κυκλοφορίας.

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

Στη συνέχεια, εκτελέστε adversarial αξιολογήσεις έναντι αυτών των κατηγοριών. Η Κορυφαία 10άδα του OWASP για Εφαρμογές LLM, το Πλαίσιο Διαχείρισης Κινδύνου AI του NIST και το MITRE ATLAS σάς δίνουν το κοινό λεξιλόγιο· το red-teaming σάς δίνει το τεστ. Το DeepTeam, το open-source πλαίσιο red-teaming από την ίδια ομάδα πίσω από το DeepEval, περιλαμβάνει 120+ ευπάθειες σε 8 κατηγορίες και 20+ διανύσματα επίθεσης, καθεμία αντιστοιχισμένη σε OWASP, NIST AI RMF και MITRE ATLAS.

Μια ειλικρινής απόχρωση σχετικά με τα εργαλεία: το DeepTeam OSS είναι η δωρεάν διαδρομή και καλύπτει το σύνολο ευπαθειών· η διαχειριζόμενη, εντός πλατφόρμας λειτουργική μονάδα red-teaming στο Confident AI είναι δυνατότητα επιπέδου Enterprise, όχι κάτι που περιλαμβάνει το πακέτο Starter των $9,99. Όπως και να έχει, ενσωματώστε το red-teaming ως πύλη πρώτης κατηγορίας, όχι ως μια μεταγενέστερη σκέψη που τρέχετε μία φορά πριν από την κυκλοφορία.

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

Τρέχουμε αυτό το σύστημα τριών επιπέδων στον δικό μας αγωγό περιεχομένου πολλαπλών πρακτόρων: τέσσερις πράκτορες (ερευνητής, δημιουργός περίληψης, συγγραφέας περιεχομένου, επικυρωτής) που παραδίδουν τη δουλειά κατά μήκος μιας αλυσίδας. Συνδέοντας το DeepEval v4.0.5 σε αυτόν τον αγωγό, τον Ιούνιο και τον Ιούλιο του 2026, απέναντι στον χώρο εργασίας μας στο Confident AI, είναι ο τρόπος με τον οποίο εντοπίσαμε την αποτυχία από την εισαγωγή. Η έξοδος του βαθμολογητή έμοιαζε κάπως έτσι:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

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

Αν ακολουθείτε επαγγελματίες στο r/LLMDevs, r/MachineLearning ή r/LocalLLaMA, η ίδια χούφτα παραπόνων εμφανίζεται συνεχώς, και ευθυγραμμίζονται σχεδόν ένα προς ένα με αυτό που το σύστημα τριών επιπέδων είναι φτιαγμένο να εντοπίζει:

• Το πρόβλημα «δουλεύει τη Δευτέρα, χαλάει την Τετάρτη». Ο μη ντετερμινισμός κάνει την ίδια είσοδο να ακολουθεί διαφορετική διαδρομή από εκτέλεση σε εκτέλεση, οπότε οι ομάδες μαθαίνουν να αγνοούν τις ασταθείς αξιολογήσεις. Η βαθμολόγηση σε επίπεδο τμήματος σε ζωντανές ιχνηλατήσεις υπερτερεί ενός μεγαλύτερου χρυσού συνόλου.
• Η κούραση του χρυσού συνόλου δεδομένων. Εβδομάδες που ξοδεύονται στη χειροκίνητη επισήμανση μιας σουίτας, την οποία μια και μόνη αλλαγή συλλογιστικής καθιστά απαρχαιωμένη. Η αυτόματη επιμέλεια ιχνηλατήσεων παραγωγής υπερτερεί της χειροκίνητης συντήρησης ενός στατικού αρχείου.
• Η δυσπιστία απέναντι στον κριτή LLM. Η επαναλαμβανόμενη επωδός είναι ότι ο κριτής μοιράζεται τα τυφλά σημεία του πράκτορα, και αυτός είναι ακριβώς ο λόγος που οι ομάδες διατηρούν έναν άνθρωπο στον βρόχο.

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

Ποια πλατφόρμα ταιριάζει στο stack σας;

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

Στην κορυφή για την περίπτωση χρήσης enterprise και δια-ομαδικής συνεργασίας βρίσκεται το Confident AI. Καλύπτει τον πλήρη κύκλο ζωής ποιότητας σε ένα μέρος (αξιολογήσεις κατά την ανάπτυξη, παρατηρησιμότητα παραγωγής, adversarial ασφάλεια μέσω του DeepTeam, πύλη ποιότητας σε επίπεδο οργανισμού), και το πραγματικό του διαφοροποιητικό στοιχείο είναι η πρόσβαση της ομάδας χωρίς κώδικα (no-code): οι μηχανικοί το συνδέουν μία φορά και μετά οι PMs, η ομάδα QA και οι ειδικοί του τομέα εκτελούν μόνοι τους πλήρεις κύκλους αξιολογήσεων. Η είσοδος ξεκινά από $9,99/χρήστη/μήνα με δωρεάν πλάνο. Είναι #1 στη συλλογή μας με εργαλεία αξιολόγησης LLM και #2 στη σύγκρισή μας για πλατφόρμες παρατηρησιμότητας AI, οπότε δεν είναι η πρώτη φορά που κορυφώνει μια λίστα μας.

Ξεχωριστά τοποθετείται το DeepEval, το κορυφαίο framework ανοιχτού κώδικα, φτιαγμένο από την ίδια ομάδα, με 50+ scorers και testing εγγενές στο pytest. Το Confident AI είναι η πλατφόρμα· το DeepEval είναι η βιβλιοθήκη OSS, όχι μια περιορισμένη εκδοχή της. Επιλέξτε το αν:

• DeepEval: θέλεις το ανοιχτού κώδικα πρότυπο και δουλεύεις σε Python και pytest.
• Langfuse: θέλεις open-source tracing που μπορείς να κάνεις self-host.
• LangSmith: το stack σου είναι LangChain και LangGraph από άκρη σε άκρη.
• Arize Phoenix: θέλεις OpenTelemetry-native tracing που είναι πλήρως ανοιχτού κώδικα.
• Braintrust: θέλεις all-in-one evals μαζί με experiments και γενναιόδωρο δωρεάν πλάνο.
• Promptfoo: ζεις στο CLI και θέλεις red-teaming στο ίδιο εργαλείο.
• Ragas: ο agent σου είναι ουσιαστικά ένα RAG pipeline και θέλεις μετρικές ειδικά για retrieval.
• Galileo: θέλεις managed hallucination και quality index έτοιμο από το κουτί.
• Maxim: θέλεις ένα workflow προσομοίωσης και αξιολόγησης για multi-turn agents.
• W&B Weave: είσαι ήδη στο Weights & Biases και θέλεις tracing δίπλα στα training runs σου.

Ένας ειλικρινής περιορισμός του Confident AI: η managed red-teaming μονάδα και η on-prem εγκατάσταση είναι διαθέσιμα μόνο στο πλάνο Enterprise, ενώ η επιλογή διαμονής δεδομένων σε ΗΠΑ/ΕΕ είναι δυνατότητα του πλάνου Team/Enterprise και όχι καθολική επιλογή κατά την εγγραφή. Ένας solo dev που κυκλοφορεί έναν agent μπορεί να ξεκινήσει δωρεάν με το DeepEval OSS και να προσθέσει την πλατφόρμα όταν ολόκληρη η ομάδα χρειάζεται να τρέχει evals.

Σχετικά με τον συγγραφέα

Mert Batur Gurbuz, Συνιδρυτής στο Techsy.io (University of Birmingham). Ο Mert Batur Gurbuz είναι Συνιδρυτής του Techsy.io, όπου η ομάδα υλοποιεί AI agents, συστήματα αυτοματισμού και voice/SDR pipelines για B2B πελάτες. Σπουδάζει στο University of Birmingham και γράφει για το LLM tooling stack που η ομάδα της Techsy χρησιμοποιεί πραγματικά στην παραγωγή. Συνδεθείτε στο LinkedIn.

Συχνές Ερωτήσεις

Τι είναι η αξιολόγηση AI agents;

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

Πώς αξιολογείτε την τροχιά ενός πράκτορα σε σχέση με το τελικό του αποτέλεσμα;

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

Πώς επιβεβαιώνετε ότι ένας agent κάλεσε το σωστό εργαλείο;

Ελέγξτε τρία πράγματα ξεχωριστά: την επιλογή εργαλείου (το κατάλληλο εργαλείο για την εργασία), την ορθότητα των ορισμάτων (οι σωστές παράμετροι και τιμές) και την εγκυρότητα της διαδρομής εκτέλεσης (το σωστό βήμα και η σωστή σειρά). Frameworks όπως η μετρική Tool Correctness του DeepEval συγκρίνουν τα εργαλεία που καλούνται στην πραγματικότητα με τα αναμενόμενα εργαλεία, ελέγχουν την αντιστοιχία στις παραμέτρους εισόδου και μπορούν να βαθμολογήσουν τη σειρά των κλήσεων όταν το ενεργοποιήσετε.

Ποιες μετρικές έχουν τη μεγαλύτερη σημασία για τους AI agents στην παραγωγή;

Πρώτα έρχονται το ποσοστό επιτυχίας εργασιών και το κόστος ανά επιτυχημένη εργασία, και μετά τα εκατοστημόρια καθυστέρησης (p50, p90, p99), η ακρίβεια κλήσεων εργαλείων, η πιστότητα, το ποσοστό ανθρώπινης παρέμβασης, η απόκλιση (drift) και το ποσοστό επιτυχίας δικλίδων ασφαλείας. Το κόστος ανά επιτυχημένη εργασία έχει μεγαλύτερη σημασία από το ακατέργαστο κόστος, επειδή το απλό κόστος ανά εργασία επιβραβεύει σιωπηλά τους agents που αποτυγχάνουν γρήγορα και φθηνά.

Ποια είναι η διαφορά μεταξύ offline και online αξιολογήσεων agent;

Οι offline αξιολογήσεις εκτελούν τις μετρικές σας σε ένα σταθερό golden dataset πριν την κυκλοφορία, συνήθως μέσα στο CI, ώστε να εντοπίζουν παλινδρομήσεις. Οι online αξιολογήσεις εκτελούν τις ίδιες μετρικές σε πραγματικά production traces σε πραγματικό χρόνο, μετά την κυκλοφορία. Χρειάζεστε και τις δύο: οι offline εντοπίζουν γνωστούς τύπους αποτυχιών, ενώ οι online εντοπίζουν τα inputs που κανένα golden dataset δεν προέβλεψε και τα τροφοδοτούν πίσω στα datasets σας.

Πόσο συχνά πρέπει να επανεκτελείτε τις αξιολογήσεις των agent;

Εκτελείτε offline αξιολογήσεις σε κάθε αλλαγή prompt, μοντέλου ή εργαλείου, με gating στο CI. Εκτελείτε online αξιολογήσεις συνεχώς στην ζωντανή κίνηση, καθώς η παρέκκλιση (drift) και οι ενημερώσεις βαρών του μοντέλου υποβαθμίζουν αθόρυβα τους agent μεταξύ των deploy. Επαναξιολογήστε και ανανεώστε το golden dataset σας κάθε φορά που η παραγωγή φέρνει στην επιφάνεια ένα νέο μοτίβο αποτυχίας, ώστε η σουίτα να αντικατοπτρίζει την πραγματικότητα και όχι τα παραδείγματα που γράψατε την πρώτη μέρα.

Πώς εντοπίζετε jailbreaks και διαρροές PII πριν κυκλοφορήσουν;

Τρέξτε αντιπαραθετικές αξιολογήσεις red-team ως πύλη πριν την ανάπτυξη και συνεχίστε να τις εκτελείτε online. Αντιστοιχίστε τις μορφές αποτυχίας στο OWASP Top 10 για LLMs, στο NIST AI RMF και στο MITRE ATLAS, και στη συνέχεια προσομοιώστε επιθέσεις ενάντια σε κάθε κατηγορία με ένα framework όπως το ανοιχτού κώδικα DeepTeam. Αποκλείστε την κυκλοφορία για οποιαδήποτε ευπάθεια περάσει, όχι απλώς για μια χαμηλή μέση βαθμολογία.

Θα πρέπει να φτιάξετε ή να αγοράσετε μια πλατφόρμα αξιολόγησης AI agent;

Φτιάξτε τη με εργαλεία ανοιχτού κώδικα (DeepEval για μετρικές, Promptfoo για δοκιμές CLI και red-teaming) όταν είστε μεμονωμένος developer ή μικρή ομάδα μηχανικής που δουλεύει άνετα με κώδικα. Αγοράστε μια πλατφόρμα όπως η Confident AI όταν ολόκληρη η ομάδα χρειάζεται πρόσβαση χωρίς κώδικα σε επίπεδο οργανισμού, διαχειριζόμενες δοκιμές ασφαλείας και τυποποιημένη παρατηρησιμότητα παραγωγής σε όλα τα έργα. Οι περισσότερες ομάδες ξεκινούν με OSS και στη συνέχεια κάνουν το επόμενο βήμα.

Είναι το LLM-as-a-judge αξιόπιστο για τη βαθμολόγηση των agents;

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

Το σύστημα τριών επιπέδων, με μια ανάσα

Βαθμολογήστε την τροχιά, όχι μόνο την απάντηση. Επικυρώστε τις κλήσεις εργαλείων σε τρεις άξονες: σωστό εργαλείο, σωστά ορίσματα, σωστό βήμα. Τρέξτε τις ίδιες μετρικές offline και online, σε ζωντανά traces, σε έναν βρόχο που επανεισάγει πραγματικές αποτυχίες στα σύνολα δεδομένων σας. Και θέστε την ασφάλεια ως προϋπόθεση για το deploy, όχι μόνο την ακρίβεια.

Ξεκινήστε από όποιο επίπεδο πονάει περισσότερο: αν κάνετε deploy στα τυφλά, στήστε πρώτα τα online evals· αν κάνετε μη ασφαλή deploy, φτιάξτε πρώτα την πύλη ασφαλείας. Στήστε το με τα open source DeepEval και Promptfoo, ή αγοράστε μια πλατφόρμα όπως το Confident AI όταν ολόκληρη η ομάδα χρειάζεται πρόσβαση χωρίς κώδικα και διαχειριζόμενη ασφάλεια. Και αν προτιμάτε να στήσουν οι μηχανικοί ολόκληρο τον βρόχο για εσάς, αυτό ακριβώς είναι κάτι που η ομάδα μας κάνει κάθε εβδομάδα.