Sådan evaluerer du AI-agenter i produktion: 3-lags systemet vi bruger på live-spor

Sådan evaluerer du AI-agenter i produktion: 3-lags systemet vi bruger på live-spor

Evaluering af AI-agenter i produktion betyder scoring af agentens fulde flertrins-forløb, ikke kun dens endelige svar, på live-trafik: kontrol af hvert ræsonnementstrin, validering af at den kaldte de rigtige værktøjer med de rigtige argumenter, og løbende overvågning af opgavesucces, omkostninger og sikkerhed efter lancering, fordi agenter fejler stille og ikke-deterministisk.

På en kørsel i juni 2026 af vores egen Techsy-indholdspipeline leverede agenten et blogindlæg, der så perfekt ud, og scoren for det endelige output godkendte det. Rent og pænt. Undtagen tre trin tilbage, hvor brief-skaberen havde kaldt det forkerte interne link-opslagværktøj, så halvdelen af cluster-linksene pegede ingen steder hen. At vide, hvordan man evaluerer AI-agenter i produktion, betyder at score hele den vej, en agent tog, ikke kun det svar, den tilfældigvis landede på.

Vigtigste pointer:

• Score hele forløbet, ikke kun det endelige svar: et rigtigt svar via den forkerte vej er stadig en fiasko.
• Valider værktøjskald på tre akser: rigtigt værktøj, rigtige argumenter, rigtigt trin.
• Kør de samme metrics offline og online på live produktionsspor i en kontinuerlig sløjfe.
• Bloker deploy baseret på sikkerhedssårbarheder (jailbreak, PII, misbrug af værktøjer), ikke kun lave nøjagtighedsscorer.

Hvorfor er evaluering af AI-agenter i produktion anderledes end LLM-evaluering?

Evaluering af AI-agenter i produktion er sværere end model-evaluering, fordi en agent tager flere trin, kalder eksterne værktøjer og ændrer reel tilstand, og den gør alt dette ikke-deterministisk. Den samme input kan producere en anden sekvens af værktøjskald fra kørsel til kørsel, så et enkelt forkert trin tidligt i processen kan korruptere alle efterfølgende trin.

Denne guide antager, at du allerede kender til generel LLM-evaluering. Hvis du ikke gør, så start med vores komplette guide til LLM-evaluering, og kom derefter tilbage for at se, hvad der ændrer sig, når modellen bliver til en agent. (Bygger du stadig de agenter, du skal til at bedømme? Vores gennemgang af de bedste AI-agent frameworks dækker laget under.)

Fire ting bryder sammen i det øjeblik, din LLM begynder at handle selvstændigt:

• Flertrins. En supportagent kan søge i en vidensbase, kalde en ordre-API og derefter udkaste et svar. Scorer du kun svaret, er du blind for de to trin, der bestemte det.
• Ikke-deterministisk. Temperatur, opdateringer af modelvægte og værktøjslatens betyder, at den samme anmodning tager en anden vej ved hver kørsel. Din evaluering skal kunne håndtere et bevægeligt mål.
• Tilstandsbevidst. Agenter skriver til databaser, sender e-mails og refunderer ordrer. En forkert handling er ikke en dårlig sætning; det er en bivirkning, du ikke kan tage tilbage.
• Akkumulerende fejl. Et let forkert trin 2 i en 12-trins kørsel forgifter alt nedstrøms, og det endelige svar kan stadig se fint ud.

Galileos rapport fra februar 2026 om "State of Eval Engineering", der undersøgte over 500 praktikere, fandt ud af, at 84,9 % af teamene oplevede en AI-hændelse inden for seks måneder efter lancering. Anthropic's ingeniørteam udtrykker det klart i deres essay om agent-evalueringer: agenter fejler på tværs af trin, værktøjer og intentioner, ikke kun ved det endelige output.

En agent, der returnerer det rigtige svar gennem det forkerte forløb, har ikke bestået. Den har fejlet stille, og den vil fejle højt næste gang, den heldige genopretning ikke sker.

Hvilke metrics betyder egentlig noget for AI-agenter i produktion?

De metrics, der betyder mest for agenter i produktion, går ud over nøjagtighed: opgavesuccesrate, omkostninger pr. succesfuld opgave, latens-percentiler, nøjagtighed af værktøjskald, troværdighed, rate for menneskelig indgriben, drift og sikkerhedsportens godkendelsesrate. Sammen fanger disse ai agent evalueringsmetrics de stille, ikke-deterministiske fejl, som en enkelt output-score overser.

Dette er de otte metrics, vi faktisk holder øje med i vores egne kørsler. Bemærk, hvor få af dem bekymrer sig om, hvor godt det endelige svar læses:

De fleste af disse læner sig op ad en LLM-som-en-dommer (én model scorer en andens output). Det er standardtricket, og det skalerer, men det er støjende: dommeren deler ofte agentens blinde vinkler, så behandle dens scorer som signal, ikke som evangelium. Vi vender tilbage til kalibrering af dommeren i afsnit syv.

Én metric fortjener en særlig omtale. Omkostninger pr. succesfuld opgave er tallet, der overlever en budgetgennemgang. Almindelige omkostninger pr. opgave belønner billige fiaskoer, fordi en agent, der giver op hurtigt og forkert, ser effektiv ud på regnearket.

Hvordan scorer du en agents forløb i stedet for dens endelige svar?

For at score en agents forløb evaluerer du sporet: den ordnede registrering af hvert ræsonnementstrin, værktøjskald og mellemliggende output, som agenten producerede. Span-niveau evaluering scorer hvert individuelt trin (span), så du kan pinpointe præcis det trin, der fejlede, i stedet for kun at lære, at den samlede kørsel gik galt.

Tænk på et spor som en stack trace for ræsonnement. Hvert span er ét trin: en hentning, et værktøjskald, en overlevering til en under-agent. Observability fanger disse spans; evaluering scorer dem. (Ingen sporing endnu? Vores guide til AI-observability dækker overvågningslaget, som scoringen sidder ovenpå, og vores sammenligning af LangGraph, CrewAI og OpenAI Agents SDK viser, hvordan et spor ser ud i hver af dem.)

Hvorfor score hvert span i stedet for slutpunktet? Akkumulerende fejl. Hvis trin 2 henter det forkerte dokument, bygger trin 3 til 12 på garbage, og en heldig final formulering kan stadig slippe forbi en check, der kun ser på outputtet. Span-niveau scoring fortæller dig, at kørslen fejlede ved trin 2, ikke bare at den fejlede et sted.

Her er den framework-agnostiske version først (en almindelig påstand over et spor-objekt), derefter DeepEval-genvejen ved hjælp af dens spor-baserede Task Completion metric:

# Framework-agnostic: did the trajectory reach the goal via valid steps?
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: score the whole multi-step trace for task completion
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

Den framework-agnostiske assert er fin til hårde, deterministiske checks. Task Completion er det, du griber efter, når succes er mere uklar end et lighedstjek: det udtrækker den tilsigtede opgave og det opnåede resultat fra sporet og scorer, hvor godt de passer sammen.

Hvordan validerer du, at en agent kaldte det rigtige værktøj?

For at validere en agents værktøjskald skal du tjekke tre ting separat: værktøjsvalg (valgte den det rigtige værktøj), argumentkorrekthed (sendte den de rigtige parametre og værdier) og eksekveringssti-validitet (kaldte den det værktøj på det rigtige trin i den rigtige rækkefølge). Et bestået endeligt svar med et forkert værktøjskald er en bug, der ikke har vist sig endnu.

Dette er den mest agentspecifikke evaluering, og det er den, næsten ingen dækker i dybden. Evaluering af multi-agent værktøjsbrug opdeles i tre spørgsmål:

1. Valg. Ud af de tilgængelige værktøjer, valgte agenten det korrekte? At kalde ethvert værktøj er ikke det samme som at kalde det rigtige.
2. Argumenter. Sendte den de rigtige parametre? Det rigtige værktøj med en forkert slug eller en malformed dato er stadig en fiasko.
3. Eksekveringssti. Kaldte den det værktøj på det rigtige trin i den rigtige rækkefølge? At refundere før verifikation af ordren er de korrekte værktøjer i den forkerte rækkefølge.

DeepEval's Tool Correctness metric håndterer alle tre: den sammenligner tools_called med expected_tools, kan matche på inputparametre, og med should_consider_ordering=True graderer den også sekvensen.

# Framework-agnostic: right tool, right args, right step
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: score tool selection + arguments, order-aware
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"

Den 0.0 er den præcise fiasko, vi fangede i vores egen pipeline: agenten greb efter sitemap_search, da det forventede værktøj var internal_link_lookup. Det færdige indlæg bestod stadig sin output-score. Værktøjskald-metric'en var det eneste, der flaggede den ødelagte sti.

Hvordan kører du evalueringer online på live produktionsspor?

Online evaluering kører dine metrics mod live produktionsspor i realtid, i stedet for kun mod et testsæt før deploy. Det er det tredje lag i et tre-lags system: offline tests på et gyldent sæt, en pre-deployment QA-port, derefter online evalueringer på live trafik, med produktionsspor kurateret tilbage i datasæt, så sløjfen fortsætter med at forbedre sig.

Offline tests fanger regressioner, før de shipper. Men agenter møder inputs i produktion, som intet gyldent sæt havde forudset, så de samme metrics skal blive ved med at køre efter lancering. Her er den fulde sløjfe, som diagrammet øverst kortlægger:

1. Offline. Kør dine metrics på et gyldent datasæt i CI. Fejlbyg ved regression.
2. Pre-deployment QA-port. Et menneskeligt ejet checkpoint: klarer dette både nøjagtighedsbaren og sikkerhedsbaren (afsnit seks)?
3. Online. Scor live produktionsspor i realtid med de samme metrics.
4. Kurater. Auto-indsamling af rigtige spor (især fiaskoerne) tilbage i dine eval-datasæt.
5. Gen-kør. Dit gyldne sæt vokser fra virkeligheden i stedet for de 20 eksempler, du håndskrev på dag ét.

Opsætning af en online evaluering er den samme instrumentering som sporing, plus en metric-indsamling. Confident AI kører de 50+ scorers fra DeepEval mod live spor, og det er OpenTelemetry-kompatibelt, så LangGraph, CrewAI, OpenAI og Vercel AI SDK eksporterer uden skræddersyede adapters:

# Same metrics you ran in dev, now scoring live production traffic
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
# The collection's metrics now run on every trace, in real time.

Gevinsten er kuraterings-trinnet. Hver reel produktionsfiasko bliver en permanent regressionstest, så din suite stopper med at være et statisk snapshot og begynder at spore, hvad din agent faktisk møder i det vilde.

Port på sikkerhed, ikke kun nøjagtighed

En sikkerhedsport blokerer et deploy baseret på en sårbarhed, ikke kun en lav nøjagtighedsscore. For agenter betyder det adversarial og red-team evalueringer, der undersøger for jailbreaks, misbrug af værktøjer og PII-lækage, kørt både før deploy og online. Et jailbreak er ikke en lav score, du kan gennemsnitte væk. Det er en release-blokering.

Alle konkurrenter behandler sikkerhed som én metric blandt mange. Det er bagvendt for agenter, som kan snakkes til at kalde et rigtigt værktøj mod et rigtigt system. Så adskil portene: en nøjagtighedsport gennemsnitter scorer; en sikkerhedsport er bestå/ikke-bestå baseret på, om nogen adversarial probe kom igennem. Start med at mappe din agents fejlmåder til de frameworks, revisorer allerede genkender:

Kør derefter adversarial evalueringer mod disse kategorier. OWASP's Top 10 for LLM Applications, NIST AI Risk Management Framework og MITRE ATLAS giver dig det fælles sprogbrug; red-teaming giver dig testen. DeepTeam, det open-source red-teaming framework fra samme team bag DeepEval, leverer 120+ sårbarheder på tværs af 8 kategorier og 20+ angrebsvektorer, hver mappede til OWASP, NIST AI RMF og MITRE ATLAS.

En ærlig nuance omkring værktøjer: DeepTeam OSS er den gratis vej og dækker sårbarhedssættet; det administrerede, in-platform red-teaming modul i Confident AI er en Enterprise-tier funktion, ikke noget som $9,99 Starter-planen bundler. Uanset hvad, så integrer red-teaming som en førsteklasses port, ikke en eftertanke, du kører én gang før lancering.

Hvad vi fangede ved at køre dette på vores egen pipeline

Vi kører dette tre-lags system på vores egen multi-agent indholdspipeline: fire agenter (researcher, brief-skaber, indholdsskribent, validator) der giver arbejde videre i en kæde. Ved at integrere DeepEval v4.0.5 i den pipeline over juni og juli 2026, mod vores Confident AI workspace, fangede vi fiaskoen fra introduktionen. Scorer-outputtet så sådan ud:

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.

Indlægget havde allerede bestået sin output-kvalitetsscore. Intet ved den færdige artikel så forkert ud. Kun forløbsevalueringen så det ødelagte trin, præcis den type bug, som et output-only check vinker igennem.

Hvis du følger praktikere på r/LLMDevs, r/MachineLearning eller r/LocalLLaMA, kommer de samme håndfuld klager op konstant, og de stemmer næsten én-til-én overens med det, som tre-lags systemet er bygget til at fange:

• Problemet med "virker mandag, fejler onsdag". Ikke-determinisme får den samme input til at tage en anden vej fra kørsel til kørsel, så teams lærer at ignorere ustabile evalueringer. Span-niveau scoring på live spor slår et større gyldent sæt.
• Træthed af gyldne datasæt. Uger brugt på håndmærkning af en suite, som en enkelt ændring i ræsonnementet gør forældet. Auto-kuratering af produktionsspor slår manuel vedligeholdelse af en statisk fil.
• Mistillid til LLM-dommeren. Det tilbagevendende omkvæd er, at dommeren deler agentens blinde vinkler, hvilket er præcis hvorfor teams holder et menneske i loopet.

Det sidste punkt er det vigtige. Domaineksperter annoterer de outputs, som dommeren er usikker på, og disse labels feedes tilbage i metric-aligning, den samme lukkede sløjfe, vi beskrev i vores Confident AI review og sideløbende med hvordan vi håndterer agent hukommelse. Dommeren skalerer; menneskene holder den ærlig.

Hvilken platform passer til din stack?

Intet enkelt værktøj er rigtigt for alle teams, så match platformen til, hvor du er. Her er hvordan de hovedmuligheder sammenlignes på de fem kapaciteter, denne guide lænede sig op ad, plus hvordan du kommer ind ad døren:

Øverst for enterprise og cross-team use caset er Confident AI. Det dækker hele kvalitetslivscyklussen ét sted (dev-time evals, produktions-observability, adversarial sikkerhed via DeepTeam, en org-wide kvalitetsport), og dens virkelige differentiator er no-code team adgang: ingeniører sætter det op én gang, derefter kører PM'er, QA og domaineksperter fulde eval-cykler selv. Entry er $9,99/bruger/mdr med en free tier. Det er #1 i vores runde op af LLM evalueringsværktøjer og #2 i vores sammenligning af AI observability platforme, så dette er ikke første gang, det topper en liste for os.

Positioneret separat er DeepEval, det førende open-source framework, bygget af samme team, med 50+ scorers og pytest-native testing. Confident AI er platformen; DeepEval er OSS biblioteket, ikke en beskåret version af det. Vælg dette hvis:

• DeepEval: du vil have open-source standarden og lever i Python og pytest.
• Langfuse: du vil have open-source sporing, du kan self-hoste.
• LangSmith: din stack er LangChain og LangGraph end-to-end.
• Arize Phoenix: du vil have OpenTelemetry-native sporing, der er fuldt open-source.
• Braintrust: du vil have all-in-one evals plus eksperimenter med en generøs free tier.
• Promptfoo: du lever i CLI'en og vil have red-teaming i samme værktøj.
• Ragas: din agent er virkelig en RAG-pipeline, og du vil have retrieval-specifikke metrics.
• Galileo: du vil have en administreret hallucinations- og kvalitetsindex out of the box.
• Maxim: du vil have en simulation-og-eval workflow for multi-turn agenter.
• W&B Weave: du er allerede i Weights & Biases og vil have sporing ved siden af dine træningskørsler.

En ærlig begrænsning ved Confident AI: det administrerede red-teaming modul og on-prem deployment er Enterprise-tier, og US/EU data residency er en Team/Enterprise funktion snarere end en universel toggle ved tilmelding. En solo dev, der shipper én agent, kan starte med DeepEval OSS gratis og tilføje platformen, når et helt team skal køre evals.

Ofte Stillede Spørgsmål

Hvad er AI agent evaluering?

AI agent evaluering er praksissen med at score en autonom agents fulde adfærd, ikke kun dens endelige svar. Det måler det flertrins-forløb, de værktøjer den kaldte, opgavesucces, omkostninger, latens og sikkerhed. Fordi agenter handler ikke-deterministisk og ændrer reel tilstand, kører evalueringen kontinuerligt, både i udvikling og på live produktionstrafik.

Hvordan evaluerer du en agents forløb versus dens endelige output?

Final-output evaluering scorer kun det sidste svar. Forløbsevaluering scorer hele sporet: hvert ræsonnementstrin, værktøjskald og mellemliggende resultat. Span-niveau scoring graderer hvert trin, så du kan finde præcis det, der fejlede. En kørsel kan producere et rigtigt svar gennem et ødelagt forløb, hvilket forløbsevaluering fanger, og output-only checks miss'er.

Hvordan validerer du, at en agent kaldte det rigtige værktøj?

Tjek tre ting separat: værktøjsvalg (det rigtige værktøj til opgaven), argumentkorrekthed (de rigtige parametre og værdier) og eksekveringssti-validitet (det rigtige trin og rækkefølge). Frameworks som DeepEval's Tool Correctness metric sammenligner de faktisk kaldte værktøjer med forventede værktøjer, matcher på inputparametre og kan grade kallingsrækkefølge, når du aktiverer det.

Hvilke metrics betyder mest for AI-agenter i produktion?

Opgavesuccesrate og omkostninger pr. succesfuld opgave kommer først, derefter latens-percentiler (p50, p90, p99), nøjagtighed af værktøjskald, troværdighed, rate for menneskelig indgriben, drift og sikkerhedsportens godkendelsesrate. Omkostninger pr. succesfuld opgave betyder mere end rå omkostninger, fordi almindelige omkostninger pr. opgave stille belønner agenter, der fejler hurtigt og billigt.

Hvad er forskellen mellem offline og online agent evals?

Offline evals kører dine metrics mod et fast gyldent datasæt før deploy, normalt i CI, for at fange regressioner. Online evals kører de samme metrics mod live produktionsspor i realtid efter lancering. Du har brug for begge: offline fanger kendte fejlmåder, online fanger de inputs, intet gyldent sæt havde forudset, og feeder dem tilbage i dine datasæt.

Hvor ofte skal du gen-køre agent evalueringer?

Kør offline evals ved hver prompt-, model- eller værktøjsændring, gated i CI. Kør online evals kontinuerligt mod live trafik, da drift og modelvægt-opdateringer degraderer agenter stille mellem deploys. Gen-kurater dit gyldne datasæt, når produktionen fremviser en ny fejlmåde, så suiten tracker virkeligheden i stedet for de eksempler, du skrev på dag ét.

Hvordan fanger du jailbreaks og PII-lækager, før de shipper?

Kør adversarial red-team evals som en pre-deploy port, og hold dem kørende online. Map fejlmåder til OWASP Top 10 for LLMs, NIST AI RMF og MITRE ATLAS, simuler derefter angreb mod hver kategori med et framework som det open-source DeepTeam. Bloker releasen på enhver sårbarhed, der kommer igennem, ikke kun på en lav gennemsnitsscore.

Skal du bygge eller købe en AI agent evalueringsplatform?

Byg med open-source værktøjer (DeepEval til metrics, Promptfoo til CLI testing og red-teaming), når du er en solo dev eller et lille ingeniørteam, der er komfortabelt med kode. Køb en platform som Confident AI, når et helt team har brug for org-wide, no-code adgang, administreret sikkerhedstesting og produktions-observability standardiseret på tværs af projekter. De fleste teams starter OSS og graduerer.

Er LLM-som-en-dommer pålidelig til scoring af agenter?

Det er nyttigt, men støjende. En LLM-dommer skalerer til tusindvis af spor billigt, men den er ikke-deterministisk og deler ofte agentens blinde vinkler, så den kan rubber-stemple et plausibelt-men-forkert svar. Kalibrer den mod menneskelige eller domain-ekspert labels på en prøve, behandle scorer som retningsbestemt signal, og gate high-stakes beslutninger på deterministiske checks, hvor du kan.

3-lags systemet, i ét åndedrag

Score forløbet, ikke kun svaret. Valider værktøjskald på tre akser: rigtigt værktøj, rigtige argumenter, rigtigt trin. Kør de samme metrics offline og online, på live spor, i en sløjfe der kuraterer rigtige fiaskoer tilbage i dine datasæt. Og gate deployet på sikkerhed, ikke kun nøjagtighed.

Start med det lag, der gør mest ondt: hvis du shipper blindt, wire online evals op først; hvis du shipper usikkert, byg sikkerhedsporten først. Byg det med open-source DeepEval og Promptfoo, eller køb en platform som Confident AI, når et helt team har brug for no-code adgang og administreret sikkerhed. Og hvis du hellere vil have ingeniører til at wire hele sløjfen op for dig, så er det den slags ting, vores team gør hver uge.