Cum să evaluezi agenții AI în producție: sistemul pe 3 niveluri pe care îl rulăm pe trace-uri live

Cum să evaluezi agenții AI în producție: sistemul pe 3 straturi pe care îl folosim pe trace-uri live

A evalua agenții AI în producție înseamnă a scoriza întreaga traiectorie în mai mulți pași a agentului, nu doar răspunsul său final, pe trafic live: verificând fiecare pas de raționament, validând că a apelat instrumentele potrivite cu argumentele potrivite și monitorizând continuu succesul sarcinii, costul și siguranța după lansare, deoarece agenții eșuează silențios și nedeterminist.

Într-o rulare din iunie 2026 a propriului nostru pipeline de conținut Techsy, agentul a livrat o postare de blog cu aspect perfect, iar scorul de output final a trecut-o. Curat. Doar că, cu trei pași în urmă, creatorul de brief apelase instrumentul greșit de căutare a linkurilor interne, așa că jumătate dintre linkurile clusterului nu duceau nicăieri. A ști cum să evaluezi agenții AI în producție înseamnă a scoriza întregul parcurs pe care l-a urmat un agent, nu doar răspunsul la care s-a nimerit să ajungă.

Concluzii cheie:

• Scorizează întreaga traiectorie, nu doar răspunsul final: un răspuns corect obținut pe calea greșită tot un eșec este.
• Validează apelurile de instrumente pe trei axe: instrumentul potrivit, argumentele potrivite, pasul potrivit.
• Rulează aceleași metrici offline și online, pe trace-uri de producție live, într-o buclă continuă.
• Condționează deploy-urile de vulnerabilitățile de securitate (jailbreak, PII, utilizare abuzivă a instrumentelor), nu doar de scorurile scăzute de acuratețe.

De ce evaluarea agenților IA în producție diferă de evaluarea LLM?

Evaluarea agenților IA în producție este mai dificilă decât evaluarea modelelor, deoarece un agent parcurge mai mulți pași, apelează instrumente externe și modifică stări reale, făcând toate acestea în mod nedeterminist. Aceeași intrare poate produce o secvență diferită de apeluri de instrumente de la o rulare la alta, astfel încât un singur pas greșit la început poate corupe toți pașii următori.

Acest ghid presupune că cunoști deja evaluarea generală a LLM-urilor. Dacă nu, începe cu ghidul nostru complet de evaluare a LLM-urilor, apoi revino pentru a afla ce se schimbă odată ce modelul devine agent. (Încă mai construiești agenții pe care urmează să îi evaluezi? Prezentarea noastră a celor mai bune framework-uri de agenți IA acoperă stratul de dedesubt.)

Patru lucruri se strică în momentul în care LLM-ul tău începe să acționeze pe cont propriu:

• Multi-pas. Un agent de asistență ar putea căuta într-o bază de cunoștințe, apela un API de comenzi, apoi redacta un răspuns. Dacă evaluezi doar răspunsul, rămâi orb față de cei doi pași care l-au determinat.
• Nedeterminist. Temperatura, actualizările ponderilor modelului și latența instrumentelor fac ca aceeași cerere să urmeze o cale diferită la fiecare rulare. Evaluarea ta trebuie să supraviețuiască unei ținte în mișcare.
• Cu stare. Agenții scriu în baze de date, trimit e-mailuri, rambursează comenzi. O acțiune greșită nu este o propoziție prost formulată, ci un efect secundar pe care nu îl poți anula.
• Cumulativ. Un pas 2 ușor greșit într-o rulare de 12 pași otrăvește tot ce urmează, iar răspunsul final poate părea totuși corect.

Raportul State of Eval Engineering din februarie 2026 al Galileo, bazat pe un sondaj în rândul a peste 500 de practicieni, a constatat că 84,9% dintre echipe se confruntă cu un incident IA în termen de șase luni de la lansare. Echipa de inginerie a Anthropic o spune răspicat în eseul lor despre evaluarea agenților: agenții eșuează la nivelul pașilor, al instrumentelor și al intenției, nu doar la nivelul rezultatului final.

Un agent care returnează răspunsul corect printr-o traiectorie greșită nu a trecut testul. A eșuat în tăcere și va eșua zgomotos data viitoare când recuperarea norocoasă nu se mai întâmplă.

Care sunt metricile care contează cu adevărat pentru agenții AI în producție?

Metricile care contează cel mai mult pentru agenții din producție depășesc acuratețea: rata de succes a sarcinilor, costul per sarcină reușită, percentilele de latență, acuratețea apelurilor de instrumente, fidelitatea, rata de intervenție umană, deriva și rata de trecere a porții de siguranță. Împreună, aceste metrici de evaluare a agenților AI surprind eșecurile silențioase, nedeterministe, pe care un singur scor de output le ratează.

Acestea sunt cele opt metrici pe care le urmărim efectiv în propriile noastre rulări. Observați cât de puține dintre ele țin de cât de bine se citește răspunsul final:

Majoritatea acestora se bazează pe un LLM-ca-judecător (un model care evaluează outputul altuia). Este trucul standard și scalează, dar este zgomotos: judecătorul împărtășește adesea unghiurile oarbe ale agentului, așa că tratați scorurile sale ca semnal, nu ca adevăr absolut. Revenim la calibrarea judecătorului în secțiunea șapte.

O metrică merită o mențiune separată. Costul per sarcină reușită este numărul care supraviețuiește unei revizuiri de buget. Costul simplu per sarcină recompensează eșecurile ieftine, deoarece un agent care renunță rapid și greșit pare eficient în foaia de calcul.

Cum evaluezi traiectoria unui agent în loc de răspunsul său final?

Pentru a evalua traiectoria unui agent, examinezi urma (trace): înregistrarea ordonată a fiecărui pas de raționament, a fiecărui apel de instrument și a fiecărui rezultat intermediar produs de agent. Evaluarea la nivel de span notează fiecare pas individual (span), astfel încât poți identifica exact pasul care a eșuat, în loc să afli doar că execuția per total a mers prost.

Gândește-te la o urmă ca la un stack trace pentru raționament. Fiecare span este un pas: o recuperare (retrieval), un apel de instrument, o predare către un sub-agent. Observabilitatea captează acele span-uri; evaluarea le notează. (Nu ai încă tracing? Ghidul nostru de observabilitate AI acoperă stratul de monitorizare pe care se sprijină notarea, iar comparația noastră dintre LangGraph, CrewAI și OpenAI Agents SDK arată cum arată o urmă în fiecare dintre ele.)

De ce să notezi fiecare span în loc de punctul final? Erori cumulative. Dacă pasul 2 recuperează documentul greșit, pașii 3 până la 12 se construiesc pe date eronate, iar o formulare finală norocoasă poate totuși să treacă de o verificare bazată doar pe rezultat. Notarea la nivel de span îți spune că execuția a eșuat la pasul 2, nu doar că a eșuat undeva.

Iată mai întâi versiunea agnostică față de framework (o aserțiune simplă peste un obiect de tip trace), apoi scurtătura oferită de DeepEval folosind metrica sa bazată pe trace, Task Completion:

# Independent de framework: traiectoria a atins obiectivul prin pași valizi?
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: evaluează întreaga urmărire multi-etapă pentru îndeplinirea sarcinii
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

Assert-ul agnostic față de framework este potrivit pentru verificări stricte, deterministe. Task Completion este soluția la care apelezi când succesul este mai vag decât o verificare de egalitate: acesta extrage sarcina intenționată și rezultatul obținut din urmărire și evaluează cât de bine se potrivesc.

Cum validezi că un agent a apelat instrumentul potrivit?

Pentru a valida apelurile de instrumente ale unui agent, verifică separat trei lucruri: selectarea instrumentului (a ales instrumentul potrivit), corectitudinea argumentelor (a transmis parametrii și valorile corecte) și validitatea traseului de execuție (a apelat acel instrument la pasul potrivit, în ordinea potrivită). Un răspuns final corect, dar cu un apel de instrument greșit, este un bug care încă nu a ieșit la suprafață.

Acesta este, de departe, cel mai specific eval pentru agenți și totodată cel pe care aproape nimeni nu îl tratează în profunzime. Evaluarea utilizării instrumentelor în sistemele multi-agent se desparte în trei întrebări:

1. Selectare. Dintre instrumentele disponibile, agentul l-a ales pe cel corect? A apela orice instrument nu este același lucru cu a-l apela pe cel potrivit.
2. Argumente. A transmis parametrii corecți? Instrumentul potrivit, dar cu un slug greșit sau cu o dată incorect formatată, rămâne tot un eșec.
3. Traseu de execuție. A apelat acel instrument la pasul potrivit, în ordinea potrivită? A emite o rambursare înainte de a verifica comanda înseamnă instrumente corecte, dar într-o secvență greșită.

Metrica Tool Correctness din DeepEval le acoperă pe toate trei: compară tools_called cu expected_tools, poate potrivi după parametrii de intrare, iar cu should_consider_ordering=True evaluează și secvența.

# Independent de framework: instrumentul potrivit, argumentele potrivite, pasul potrivit
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: evaluează selecția instrumentelor + argumentele, ținând cont de ordine
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"

Acel 0.0 este exact eșecul pe care l-am prins în propriul nostru pipeline: agentul a apelat la sitemap_search când instrumentul așteptat era internal_link_lookup. Articolul finalizat a trecut totuși de scorul său de output. Metrica apelurilor de instrumente a fost singurul lucru care a semnalat traseul defect.

Cum rulezi evalurile online, pe trace-uri live din producție?

Evaluarea online îți rulează metricile pe trace-uri live din producție în timp real, în loc să le ruleze doar pe un set de testare înainte de deploy. Este al treilea strat al unui sistem cu trei straturi: teste offline pe un set de referință (golden set), un gate de QA înainte de deploy, apoi evaluri online pe trafic live, cu trace-uri din producție curate înapoi în dataset-uri, astfel încât bucla să se îmbunătățească continuu.

Testele offline detectează regresiile înainte ca acestea să ajungă în producție. Dar agenții întâlnesc în producție inputuri pe care niciun set de referință nu le-a anticipat, așa că aceleași metrici trebuie să continue să ruleze și după lansare. Iată bucla completă pe care o ilustrează diagrama de mai sus:

1. Offline. Rulează-ți metricile pe un dataset de referință în CI. Marchează build-ul ca eșuat în caz de regresie.
2. Gate de QA înainte de deploy. Un checkpoint deținut de un om: trece oare acest lucru de pragul de acuratețe și de pragul de siguranță (secțiunea șase)?
3. Online. Scoring pe trace-uri live din producție în timp real, cu aceleași metrici.
4. Curatare. Colectează automat trace-uri reale (în special eșecurile) înapoi în dataset-urile tale de eval.
5. Re-rulare. Setul tău de referință crește din realitate, în loc să rămână la cele 20 de exemple pe care le-ai scris manual în prima zi.

Conectarea unui eval online folosește aceeași instrumentație ca tracing-ul, plus o colectare de metrici. Confident AI rulează cele peste 50 de scorere din DeepEval pe trace-uri live și este compatibil cu OpenTelemetry, așa că LangGraph, CrewAI, OpenAI și Vercel AI SDK exportă fără adaptoare personalizate:

# Aceleași metrici pe care le-ai rulat în dev, acum evaluează traficul live din producție
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
# Metricile colecției rulează acum pe fiecare urmă, în timp real.

Avantajul este pasul de curate. Fiecare eșec real din producție devine un test de regresie permanent, astfel încât suita ta nu mai este un instantaneu static și începe să urmărească ceea ce întâlnește cu adevărat agentul tău în practică.

Poartă de securitate, nu doar de acuratețe

O poartă de securitate blochează o implementare din cauza unei vulnerabilități, nu doar a unui scor de acuratețe scăzut. Pentru agenți, asta înseamnă evaluări adversariale și de red-team care testează pentru jailbreak-uri, utilizarea abuzivă a instrumentelor și scurgerea de PII, rulate atât înainte de implementare, cât și online. Un jailbreak nu e un scor scăzut pe care îl mediezi. E un blocker de lansare.

Fiecare competitor tratează siguranța ca pe o metrică printre altele. E invers pentru agenți, care pot fi convinși să apeleze un instrument real împotriva unui sistem real. Așa că separă porțile: o poartă de acuratețe mediează scorurile; o poartă de securitate e pass/fail pe întrebarea dacă vreo sondă adversarială a trecut. Începe prin a mapa modurile de eșec ale agentului tău la framework-urile pe care auditorii deja le recunosc:

Apoi rulează evaluări adversariale pe acele categorii. Top 10 OWASP pentru aplicații LLM, NIST AI Risk Management Framework și MITRE ATLAS îți oferă vocabularul comun; red-teaming-ul îți oferă testul. DeepTeam, framework-ul de red-teaming open-source de la aceeași echipă din spatele DeepEval, livrează peste 120 de vulnerabilități în 8 categorii și peste 20 de vectori de atac, fiecare mapat la OWASP, NIST AI RMF și MITRE ATLAS.

O nuanță sinceră despre tooling: DeepTeam OSS e calea gratuită și acoperă setul de vulnerabilități; modulul de red-teaming gestionat, integrat în platforma Confident AI, e o funcționalitate de nivel Enterprise, nu ceva inclus în planul Starter de 9,99 $. Oricum ar fi, integrează red-teaming-ul ca o poartă de prim rang, nu ca o gândire ulterioară pe care o rulezi o dată înainte de lansare.

Ce am detectat când am rulat asta pe propriul nostru pipeline

Rulăm acest sistem în trei straturi pe propriul nostru pipeline de conținut multi-agent: patru agenți (cercetător, creator de brief, redactor de conținut, validator) care își transmit munca de-a lungul unui lanț. Integrarea DeepEval v4.0.5 în acel pipeline pe parcursul lunilor iunie și iulie 2026, raportat la spațiul nostru de lucru Confident AI, este modul în care am detectat eșecul din introducere. Outputul scorerului arăta astfel:

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.

Postarea trecuse deja de scorul său de calitate a outputului. Nimic din articolul finalizat nu părea greșit. Doar evaluarea de traiectorie a detectat pasul defect, exact clasa de bug pe care o verificare bazată exclusiv pe output o lasă să treacă.

Dacă urmărești practicienii pe r/LLMDevs, r/MachineLearning sau r/LocalLLaMA, același set restrâns de plângeri apare constant și se aliniază aproape unu la unu cu ceea ce sistemul în trei straturi este construit să detecteze:

• Problema „funcționează luni, eșuează miercuri". Nedeterminismul face ca același input să urmeze o cale diferită de la o rulare la alta, astfel încât echipele învață să ignore evaluările instabile. Scoringul la nivel de span pe trace-uri live întrece un set golden mai mare.
• Oboseala datasetului golden. Săptămâni întregi petrecute etichetând manual o suită pe care o singură schimbare de raționament o face învechită. Auto-curarea trace-urilor din producție întrece menținerea manuală a unui fișier static.
• Neîncrederea în judecătorul LLM. Refrenul recurent este că judecătorul împărtășește punctele oarbe ale agentului, ceea ce este exact motivul pentru care echipele mențin un om în buclă.

Ultimul punct este cel important. Experții din domeniu adnotează outputurile pentru care judecătorul nu este sigur, iar aceste etichete sunt reintroduse în alinierea metricilor, același circuit închis pe care l-am descris în review-ul nostru despre Confident AI și adiacent modului în care gestionăm memoria agenților. Judecătorul scalează; oamenii îl mențin onest.

Ce platformă se potrivește stack-ului tău?

Niciun instrument unic nu este potrivit pentru fiecare echipă, așa că alege platforma în funcție de punctul în care te afli. Iată cum se compară principalele opțiuni în raport cu cele cinci capacități pe care s-a bazat acest ghid, plus cum poți începe:

În frunte pentru cazul de utilizare enterprise și cross-team se află Confident AI. Acoperă întregul ciclu de viață al calității într-un singur loc (evaluări în timpul dezvoltării, observabilitate în producție, securitate adversarială prin DeepTeam, un quality gate la nivel de organizație), iar adevăratul său element de diferențiere este accesul no-code pentru echipă: inginerii îl configurează o singură dată, apoi PM-ii, QA și experții de domeniu rulează ei înșiși cicluri complete de evaluare. Intrarea este de $9.99/utilizator/lună, cu un nivel gratuit. Este #1 în clasamentul nostru al instrumentelor de evaluare LLM și #2 în comparația noastră a platformelor de observabilitate AI, deci nu este prima dată când ocupă primul loc într-o listă de-a noastră.

Poziționat separat este DeepEval, cel mai important framework open-source, construit de aceeași echipă, cu peste 50 de scoreri și testare nativă pytest. Confident AI este platforma; DeepEval este biblioteca OSS, nu o versiune redusă a acesteia. Alege-l dacă:

• DeepEval: vrei standardul open-source și lucrezi în Python și pytest.
• Langfuse: vrei tracing open-source pe care îl poți găzdui singur.
• LangSmith: stack-ul tău este LangChain și LangGraph de la un capăt la altul.
• Arize Phoenix: vrei tracing nativ OpenTelemetry, complet open-source.
• Braintrust: vrei evaluări all-in-one plus experimente cu un tier gratuit generos.
• Promptfoo: lucrezi în CLI și vrei red-teaming în aceeași unealtă.
• Ragas: agentul tău este de fapt un pipeline RAG și vrei metrici specifice pentru retrieval.
• Galileo: vrei un index de halucinații și calitate gestionat, gata de utilizare.
• Maxim: vrei un flux de lucru bazat pe simulare și evaluare pentru agenți multi-turn.
• W&B Weave: ești deja în Weights & Biases și vrei tracing lângă rulările tale de antrenament.

O limitare sinceră a Confident AI: modulul de red-teaming gestionat și implementarea on-prem sunt la tier-ul Enterprise, iar rezidența datelor în SUA/UE este o funcționalitate Team/Enterprise, nu un comutator universal la înscriere. Un dezvoltator solo care livrează un singur agent poate începe gratuit cu DeepEval OSS și poate adăuga platforma când o întreagă echipă trebuie să ruleze evaluări.

Despre autor

Mert Batur Gurbuz, co-fondator al Techsy.io (Universitatea din Birmingham). Mert Batur Gurbuz este co-fondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri vocale/SDR pentru clienți B2B. El studiază la Universitatea din Birmingham și scrie despre stack-ul de instrumente LLM pe care echipa Techsy îl folosește efectiv în producție. Conectați-vă pe LinkedIn.

Întrebări frecvente

Ce este evaluarea agenților AI?

Evaluarea agenților AI este practica de a nota întregul comportament al unui agent autonom, nu doar răspunsul său final. Aceasta măsoară traiectoria pe mai mulți pași, instrumentele apelate, succesul sarcinii, costul, latența și siguranța. Deoarece agenții acționează nedeterminist și modifică stări reale, evaluarea rulează continuu, atât în dezvoltare, cât și pe traficul real din producție.

Cum evaluezi traiectoria unui agent în raport cu rezultatul său final?

Evaluarea rezultatului final notează doar ultimul răspuns. Evaluarea traiectoriei notează întreaga urmă: fiecare pas de raționament, fiecare apel de instrument și fiecare rezultat intermediar. Notarea la nivel de segment evaluează fiecare pas, astfel încât să poți identifica pasul exact care a eșuat. O rulare poate produce un răspuns corect printr-o traiectorie defectuoasă, lucru pe care evaluarea traiectoriei îl detectează, în timp ce verificările doar pe rezultat îl ratează.

Cum validezi că un agent a apelat instrumentul potrivit?

Verifică separat trei lucruri: selectarea instrumentului (instrumentul potrivit pentru sarcină), corectitudinea argumentelor (parametrii și valorile corecte) și validitatea traseului de execuție (pasul și ordinea corecte). Framework-uri precum metrica Tool Correctness din DeepEval compară instrumentele apelate efectiv cu cele așteptate, potrivesc parametrii de intrare și pot evalua ordinea apelurilor atunci când activezi această opțiune.

Ce metrici contează cel mai mult pentru agenții IA în producție?

Rata de succes a sarcinilor și costul per sarcină reușită vin pe primul loc, apoi percentilele de latență (p50, p90, p99), acuratețea apelurilor de instrumente, fidelitatea, rata intervenției umane, deriva și rata de trecere a porților de siguranță. Costul per sarcină reușită contează mai mult decât costul brut, deoarece costul simplu per sarcină recompensează pe ascuns agenții care eșuează rapid și ieftin.

Care este diferența dintre evaluările offline și cele online ale agenților?

Evaluările offline rulează metricile tale pe un set de date de referință fix, înainte de implementare, de obicei în CI, pentru a detecta regresii. Evaluările online rulează aceleași metrici pe trace-uri de producție reale, în timp real, după lansare. Ai nevoie de ambele: evaluările offline detectează modurile de eșec cunoscute, iar cele online detectează intrările pe care niciun set de referință nu le-a anticipat și le reintroduc în seturile tale de date.

Cât de des ar trebui să re-rulezi evaluările agenților?

Rulează evaluările offline la fiecare modificare a promptului, modelului sau instrumentelor, controlate prin CI. Rulează evaluările online continuu, pe traficul real, deoarece deriva și actualizările ponderilor modelelor degradează agenții în mod silențios între implementări. Re-cură setul de date de referință ori de câte ori mediul de producție relevă un nou mod de eșec, astfel încât suita să reflecte realitatea, nu exemplele pe care le-ai scris în prima zi.

Cum detectezi jailbreak-urile și scurgerile de PII înainte de lansare?

Rulează evaluări adversariale de tip red-team ca poartă de pre-deploy și menține-le active și în producție. Mapează modurile de eșec pe OWASP Top 10 pentru LLM-uri, NIST AI RMF și MITRE ATLAS, apoi simulează atacuri împotriva fiecărei categorii folosind un framework precum DeepTeam (open-source). Blochează lansarea pentru orice vulnerabilitate care trece, nu doar pentru un scor mediu scăzut.

Ar trebui să construiești sau să cumperi o platformă de evaluare a agenților AI?

Construiește cu instrumente open-source (DeepEval pentru metrici, Promptfoo pentru testare CLI și red-teaming) atunci când ești un dezvoltator independent sau o echipă mică de ingineri care se simte confortabil să lucreze în cod. Cumpără o platformă precum Confident AI atunci când o întreagă echipă are nevoie de acces no-code la nivel de organizație, testare de securitate gestionată și observabilitate în producție, standardizate la nivelul tuturor proiectelor. Majoritatea echipelor încep cu OSS și apoi trec la o platformă.

Este LLM-as-a-judge fiabil pentru notarea agenților?

Este util, dar zgomotos. Un judecător LLM poate scala la mii de urme (traces) la costuri reduse, dar este nedeterminist și adesea împărtășește unghiurile oare ale agentului, așa că poate valida un răspuns plauzibil, dar greșit. Calibrați-l în raport cu etichete umane sau ale unor experți din domeniu pe un eșantion, tratați scorurile ca semnale orientative și condiționați deciziile cu miză mare de verificări deterministe ori de câte ori este posibil.

Sistemul pe 3 straturi, pe scurt

Evaluează traiectoria, nu doar răspunsul. Validează apelurile de instrumente pe trei axe: instrumentul potrivit, argumentele potrivite, pasul potrivit. Rulează aceleași metrici offline și online, pe trace-uri live, într-o buclă care reintegrează eșecurile reale în dataset-urile tale. Și condiționează deploy-ul de securitate, nu doar de acuratețe.

Începe cu stratul care doare cel mai tare: dacă livrezi pe orb, conectează mai întâi evaluările online; dacă livrezi nesigur, construiește mai întâi poarta de securitate. Construiește-l cu DeepEval și Promptfoo open-source sau cumpără o platformă precum Confident AI când o echipă întreagă are nevoie de acces no-code și securitate gestionată. Și dacă preferi ca inginerii să conecteze întreaga buclă pentru tine, asta e genul de lucru pe care echipa noastră îl face în fiecare săptămână.