Slik evaluerer du AI-agenter i produksjon: 3-lagssystemet vi bruker på live spor

Slik evaluerer du AI-agenter i produksjon: 3-lagssystemet vi bruker på live spor

Å evaluere AI-agenter i produksjon betyr å score agentens fulle, flerstegs handlingsforløp — ikke bare det endelige svaret — på ekte trafikk: sjekke hvert resonnementsteg, validere at riktig verktøy ble kalt med riktige argumenter, og kontinuerlig overvåke oppgavesuksess, kostnad og sikkerhet etter lansering, fordi agenter feiler stille og ikke-deterministisk.

I en kjøring av vår egen Techsy-innholdspipeline i juni 2026 leverte agenten et blogginnlegg som så perfekt ut, og sluttresultat-scoren godkjente det. Rent og pent. Bortsett fra at brief-creator-agenten, tre steg tidligere, hadde kalt feil verktøy for internt lenke-oppslag, så halvparten av klyngelenkene pekte i tomme luften. Å vite hvordan man evaluerer AI-agenter i produksjon handler om å score hele veien agenten tok, ikke bare svaret den til slutt landet på.

Viktigste poenger:

• Score hele handlingsforløpet, ikke bare sluttsvaret: et riktig svar via feil vei er fortsatt en feil.
• Valider verktøykall på tre akser: riktig verktøy, riktige argumenter, riktig steg.
• Kjør de samme metrikkene offline og online, på live produksjonsspor, i en kontinuerlig løkke.
• Blokker utrulling ved sikkerhetssårbarheter (jailbreak, PII, verktøymisbruk), ikke bare ved lave nøyaktighetsscorer.

Hvorfor er evaluering av AI-agenter i produksjon annerledes enn LLM-evaluering?

Å evaluere AI-agenter i produksjon er vanskeligere enn modellevaluering fordi en agent tar flere steg, kaller eksterne verktøy og endrer reell tilstand — og gjør alt dette ikke-deterministisk. Samme input kan gi en annen rekkefølge av verktøykall fra kjøring til kjøring, så ett galt steg tidlig kan ødelegge alle stegene etter det.

Denne guiden forutsetter at du allerede kan generell LLM-evaluering. Hvis ikke, start med vår komplette guide til LLM-evaluering, og kom tilbake for det som endrer seg når modellen blir en agent. (Bygger du fortsatt agentene du skal vurdere? Vår gjennomgang av de beste AI-agentrammeverkene dekker laget under.)

Fire ting går i stykker i det øyeblikket LLM-en din begynner å handle på egen hånd:

• Flere steg. En support-agent kan søke i en kunnskapsbase, kalle en ordre-API og deretter utforme et svar. Scorer du bare svaret, er du blind for de to stegene som bestemte det.
• Ikke-deterministisk. Temperatur, oppdaterte modellvekter og verktøylatens gjør at samme forespørsel tar en annen vei hver gang. Evalen din må tåle et bevegelig mål.
• Tilstandsbærende. Agenter skriver til databaser, sender e-poster, refunderer bestillinger. En feil handling er ikke en dårlig setning — det er en sideeffekt du ikke kan reversere.
• Kumulativ. Et litt feil steg 2 i en 12-stegs kjøring forgifter alt nedstrøms, og sluttsvaret kan likevel se helt fint ut.

Galileos «State of Eval Engineering»-rapport fra februar 2026, som undersøkte 500+ praktikere, fant at 84,9% av teamene opplevde en AI-hendelse innen seks måneder etter lansering. Anthropics ingeniørteam sier det rett ut i sitt essay om agent-evals: agenter feiler på tvers av steg, verktøy og intensjon — ikke bare i sluttresultatet.

En agent som returnerer riktig svar via feil handlingsforløp, har ikke bestått. Den har feilet stille, og den vil feile høylytt neste gang den heldige redningen uteblir.

Hvilke metrikker betyr faktisk noe for AI-agenter i produksjon?

Metrikkene som betyr mest for agenter i produksjon, går utover nøyaktighet: oppgavesuksessrate, kostnad per vellykket oppgave, latens-persentiler, verktøykall-nøyaktighet, faktatroskap, menneskelig-intervensjonsrate, drift og sikkerhetsgate-bestått-rate. Sammen fanger disse ai-agent-evalueringsmetrikkene de stille, ikke-deterministiske feilene en enkelt utdata-score går glipp av.

Dette er de åtte metrikkene vi faktisk følger med på i våre egne kjøringer. Legg merke til hvor få av dem som bryr seg om sluttsvaret leser godt:

De fleste av disse støtter seg på en LLM-as-a-judge (én modell som scorer en annens utdata). Det er standardtriksen, og den skalerer, men den er støyete: dommeren deler ofte agentens blindsoner, så behandle scorene som et signal, ikke en fasit. Vi kommer tilbake til kalibrering av dommeren i avsnitt syv.

Én metrikk fortjener en ekstra kommentar. Kostnad per vellykket oppgave er tallet som overlever en budsjettgjennomgang. Ren kostnad per oppgave premierer billige feil, fordi en agent som gir opp raskt og feil, ser effektiv ut i regnearket.

Hvordan scorer du en agents handlingsforløp i stedet for bare sluttsvaret?

For å score en agents handlingsforløp, evaluerer du sporet: den ordnede loggen over hvert resonnementsteg, verktøykall og mellomliggende utdata agenten produserte. Span-nivå-evaluering scorer hvert enkelt steg (span), slik at du kan peke ut nøyaktig hvilket som feilet, i stedet for bare å konstatere at hele kjøringen gikk galt.

Tenk på et spor som en stack trace for resonnement. Hver span er ett steg: en henting, et verktøykall, en overlevering til en underagent. Observabilitet fanger disse spanene; evaluering scorer dem. (Har du ikke sporing ennå? Vår guide til AI-observabilitet dekker overvåkingslaget som scoringen bygger på, og vår sammenligning av LangGraph, CrewAI og OpenAI Agents SDK viser hvordan et spor ser ut i hver av dem.)

Hvorfor score hver span i stedet for bare endepunktet? Kumulative feil. Hvis steg 2 henter feil dokument, bygger steg 3 til 12 videre på søppel, og en heldig sluttformulering kan likevel snike seg forbi en sjekk som bare ser på utdata. Span-nivå-scoring forteller deg at kjøringen feilet på steg 2 — ikke bare at den feilet et sted.

Her er den rammeverk-agnostiske versjonen først (en enkel assert over et trace-objekt), så DeepEval-snarveien med dens sporbaserte Task Completion-metrikk:

# Rammeverk-agnostisk: nådde handlingsforløpet målet via gyldige steg?
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 hele det flerstegs sporet for oppgavefullføring
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

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

Den rammeverk-agnostiske asserten er fin for harde, deterministiske sjekker. Task Completion er det du griper til når suksess er mer diffust enn en likhetssjekk: den henter ut den tiltenkte oppgaven og det oppnådde resultatet fra sporet, og scorer hvor godt de stemmer overens.

Hvordan validerer du at en agent kalte riktig verktøy?

For å validere en agents verktøykall, sjekk tre ting separat: verktøyvalg (valgte den riktig verktøy), argumentkorrekthet (sendte den riktige parametere og verdier), og gyldighet i utførelsesrekkefølgen (kalte den verktøyet på riktig steg, i riktig rekkefølge). Et bestått sluttsvar med feil verktøykall er en bug som ennå ikke har vist seg.

Dette er den mest agent-spesifikke evalen som finnes, og den nesten ingen dekker i dybden. Evaluering av verktøybruk i multi-agent-systemer deler seg i tre spørsmål:

1. Valg. Av verktøyene som var tilgjengelige, valgte agenten det riktige? Å kalle et verktøy er ikke det samme som å kalle det riktige.
2. Argumenter. Sendte den riktige parametere? Riktig verktøy med feil slug eller en feilformatert dato er fortsatt en feil.
3. Utførelsesrekkefølge. Kalte den verktøyet på riktig steg, i riktig rekkefølge? Å refundere før bestillingen er verifisert er de riktige verktøyene i feil rekkefølge.

DeepEvals Tool Correctness-metrikk håndterer alle tre: den sammenligner tools_called mot expected_tools, kan matche på inndataparametere, og med should_consider_ordering=True vurderer den også rekkefølgen.

# Rammeverk-agnostisk: riktig verktøy, riktige argumenter, riktig steg
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 verktøyvalg + argumenter, rekkefølge-bevisst
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-en er nøyaktig den feilen vi fanget i vår egen pipeline: agenten grep etter sitemap_search når det forventede verktøyet var internal_link_lookup. Det ferdige innlegget besto likevel sin utdata-score. Verktøykall-metrikken var det eneste som flagget den ødelagte veien.

Hvordan kjører du evalueringer online, på live produksjonsspor?

Online-evaluering kjører metrikkene dine mot live produksjonsspor i sanntid, i stedet for bare mot et testsett før utrulling. Det er det tredje laget i et 3-lagssystem: offline-tester på et gyllent datasett, en QA-gate før utrulling, deretter online-evalueringer på live trafikk, med produksjonsspor som kureres tilbake inn i datasettene slik at løkken fortsetter å bli bedre.

Offline-tester fanger regresjoner før de lanseres. Men agenter møter input i produksjon som ingen gyllent datasett forutså, så de samme metrikkene må fortsette å kjøre etter lansering. Her er hele løkken diagrammet øverst kartlegger:

1. Offline. Kjør metrikkene dine på et gyllent datasett i CI. Feil bygget ved en regresjon.
2. QA-gate før utrulling. Et menneskestyrt sjekkpunkt: klarer dette både nøyaktighetsgrensen og sikkerhetsgrensen (avsnitt seks)?
3. Online. Score live produksjonsspor i sanntid med de samme metrikkene.
4. Kurer. Samle automatisk inn ekte spor (spesielt feilene) tilbake i evaluerings-datasettene dine.
5. Kjør på nytt. Det gyllne datasettet ditt vokser fra virkeligheten i stedet for de 20 eksemplene du skrev for hånd på dag én.

Å koble opp en online-evaluering er samme instrumentering som sporing, pluss en metrikk-samling. Confident AI kjører 50+ scorere fra DeepEval mot live spor, og er OpenTelemetry-kompatibel, så LangGraph, CrewAI, OpenAI og Vercel AI SDK eksporterer uten skreddersydde adaptere:

# Samme metrikker du kjørte i dev, som nå scorer live produksjonstrafikk
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)  # din live agent
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# Samlingens metrikker kjører nå på hvert spor, i sanntid.

Gevinsten er kurerings-steget. Hver ekte produksjonsfeil blir en permanent regresjonstest, slik at testsuiten din slutter å være et statisk øyeblikksbilde og begynner å spore det agenten din faktisk møter i den virkelige verden.

Sperr på sikkerhet, ikke bare nøyaktighet

En sikkerhetsgate blokkerer en utrulling ved en sårbarhet, ikke bare ved en lav nøyaktighetsscore. For agenter betyr det adversarielle og red-team-evalueringer som tester for jailbreaks, verktøymisbruk og PII-lekkasje, kjørt både før utrulling og online. Et jailbreak er ikke en lav score du kan gjennomsnittsberegne bort. Det er en lanseringsstopper.

Alle konkurrenter behandler sikkerhet som én metrikk blant mange. Det er baklengs for agenter, som kan overtales til å kalle et reelt verktøy mot et reelt system. Så separer gatene: en nøyaktighetsgate gjennomsnittsberegner scorer; en sikkerhetsgate er bestått/ikke-bestått basert på om noen adversarielle forsøk kom gjennom. Start med å kartlegge agentens feilmodus mot rammeverkene revisorer allerede kjenner igjen:

Kjør deretter adversarielle evalueringer mot disse kategoriene. OWASPs Top 10 for LLM-applikasjoner, NISTs AI Risk Management Framework og MITRE ATLAS gir deg det felles begrepsapparatet; red-teaming gir deg testen. DeepTeam, det åpen kildekode-baserte red-teaming-rammeverket fra samme team som står bak DeepEval, leverer 120+ sårbarheter fordelt på 8 kategorier og 20+ angrepsvektorer, hver kartlagt mot OWASP, NIST AI RMF og MITRE ATLAS.

Én ærlig nyanse om verktøyene: DeepTeam OSS er den gratis veien og dekker sårbarhetssettet; den administrerte red-teaming-modulen i Confident AI-plattformen er en Enterprise-funksjon, ikke noe $9.99-Starter-planen inkluderer. Uansett hvilken vei du velger, koble red-teaming inn som en førsteklasses gate — ikke noe du kjører én gang før lansering som en ettertanke.

Hva vi fanget da vi kjørte dette på vår egen pipeline

Vi kjører dette 3-lagssystemet på vår egen multi-agent-innholdspipeline: fire agenter (researcher, brief-creator, content-writer, validator) som sender arbeidet videre i en kjede. Ved å koble DeepEval v4.0.5 inn i den pipelinen gjennom juni og juli 2026, mot vårt Confident AI-arbeidsområde, fanget vi feilen fra innledningen. Scorer-utdataen så slik ut:

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.

Innlegget hadde allerede bestått sin utdata-kvalitetsscore. Ingenting ved den ferdige artikkelen så galt ut. Bare trajectory-evalen så det ødelagte steget — nøyaktig den typen bug en sjekk som bare ser på utdata, vinker gjennom.

Følger du praktikere på r/LLMDevs, r/MachineLearning eller r/LocalLLaMA, dukker den samme håndfullen klager opp hele tiden, og de stemmer nesten på kornet overens med det 3-lagssystemet er bygget for å fange:

• Funker-mandag-feiler-onsdag-problemet. Ikke-determinisme gjør at samme input tar en annen vei fra kjøring til kjøring, så team lærer seg å ignorere ustabile evals. Span-nivå-scoring på live spor slår et større gyllent datasett.
• Gyllent-datasett-utmattelse. Uker brukt på å håndmerke en suite som én enkelt endring i resonnementet gjør utdatert. Automatisk kurering av produksjonsspor slår å vedlikeholde en statisk fil for hånd.
• Mistillit til LLM-dommeren. Det tilbakevendende refrenget er at dommeren deler agentens blindsoner, som er nøyaktig hvorfor team holder et menneske i løkken.

Det siste punktet er det viktige. Fageksperter annoterer utdataene dommeren er usikker på, og disse merkelappene mates tilbake inn i metrikk-kalibreringen — samme lukkede løkke vi beskrev i vår Confident AI-anmeldelse og beslektet med hvordan vi håndterer agent-hukommelse. Dommeren skalerer; menneskene holder den ærlig.

Hvilken plattform passer stacken din?

Ikke ett eneste verktøy passer for alle team, så match plattformen til der du er. Her er hvordan hovedalternativene sammenlignes på de fem egenskapene denne guiden har støttet seg på, pluss hvordan du kommer i gang:

Øverst for enterprise- og team-på-tvers-bruk står Confident AI. Den dekker hele kvalitetslivssyklusen på ett sted (dev-time-evalueringer, produksjonsobservabilitet, adversariell sikkerhet via DeepTeam, en organisasjonsomfattende kvalitetsgate), og den reelle differensiatoren er no-code team-tilgang: ingeniører kobler det opp én gang, så kjører PM-er, QA og fageksperter fulle evalueringssykluser selv. Inngang koster $9.99/bruker/mnd med et gratis nivå. Den er nr. 1 i vår oversikt over LLM-evalueringsverktøy og nr. 2 i vår sammenligning av AI-observabilitetsplattformer, så dette er ikke første gang den topper en liste for oss.

Plassert separat er DeepEval, det ledende åpen kildekode-rammeverket, bygget av samme team, med 50+ scorere og pytest-nativ testing. Confident AI er plattformen; DeepEval er OSS-biblioteket, ikke en nedstrippet versjon av den. Velg dette hvis:

• DeepEval: du vil ha åpen kildekode-standarden og lever i Python og pytest.
• Langfuse: du vil ha åpen kildekode-sporing du kan selvhoste.
• LangSmith: stacken din er LangChain og LangGraph fra ende til ende.
• Arize Phoenix: du vil ha OpenTelemetry-nativ sporing som er fullstendig åpen kildekode.
• Braintrust: du vil ha alt-i-ett-evalueringer pluss eksperimenter med et generøst gratis nivå.
• Promptfoo: du lever i CLI-en og vil ha red-teaming i samme verktøy.
• Ragas: agenten din er egentlig en RAG-pipeline, og du vil ha hente-spesifikke metrikker.
• Galileo: du vil ha en administrert hallusinasjons- og kvalitetsindeks rett ut av boksen.
• Maxim: du vil ha en simulering-og-eval-arbeidsflyt for multi-turn-agenter.
• W&B Weave: du er allerede i Weights & Biases og vil ha sporing ved siden av treningskjøringene dine.

Én ærlig begrensning ved Confident AI: den administrerte red-teaming-modulen og on-prem-utrulling er Enterprise-funksjoner, og US/EU-databeliggenhet er en Team/Enterprise-funksjon snarere enn en universell bryter ved registrering. En solo-utvikler som lanserer én agent, kan starte gratis med DeepEval OSS og legge til plattformen når et helt team trenger å kjøre evalueringer.

Ofte stilte spørsmål

Hva er AI-agent-evaluering?

AI-agent-evaluering er praksisen med å score en autonom agents fulle atferd, ikke bare det endelige svaret. Den måler det flerstegs handlingsforløpet, verktøyene den kalte, oppgavesuksess, kostnad, latens og sikkerhet. Fordi agenter handler ikke-deterministisk og endrer reell tilstand, kjører evalueringen kontinuerlig — under utvikling og på live produksjonstrafikk.

Hvordan evaluerer du en agents handlingsforløp versus sluttresultatet?

Sluttresultat-evaluering scorer bare det siste svaret. Trajectory-evaluering scorer hele sporet: hvert resonnementsteg, verktøykall og mellomresultat. Span-nivå-scoring vurderer hvert steg, slik at du kan finne nøyaktig hvilket som feilet. En kjøring kan gi et riktig svar via et ødelagt handlingsforløp, noe trajectory-evaluering fanger opp og sjekker som bare ser på utdata går glipp av.

Hvordan validerer du at en agent kalte riktig verktøy?

Sjekk tre ting separat: verktøyvalg (riktig verktøy for oppgaven), argumentkorrekthet (riktige parametere og verdier), og gyldighet i utførelsesrekkefølgen (riktig steg og rekkefølge). Rammeverk som DeepEvals Tool Correctness-metrikk sammenligner verktøyene som faktisk ble kalt mot forventede verktøy, matcher på inndataparametere, og kan vurdere kallrekkefølgen når du slår det på.

Hvilke metrikker betyr mest for AI-agenter i produksjon?

Oppgavesuksessrate og kostnad per vellykket oppgave kommer først, deretter latens-persentiler (p50, p90, p99), verktøykall-nøyaktighet, faktatroskap, menneskelig-intervensjonsrate, drift og sikkerhetsgate-bestått-rate. Kostnad per vellykket oppgave betyr mer enn ren kostnad, fordi ren kostnad per oppgave stille premierer agenter som feiler raskt og billig.

Hva er forskjellen mellom offline- og online-agent-evalueringer?

Offline-evalueringer kjører metrikkene dine mot et fast gyllent datasett før utrulling, vanligvis i CI, for å fange regresjoner. Online-evalueringer kjører de samme metrikkene mot live produksjonsspor i sanntid, etter lansering. Du trenger begge: offline fanger kjente feilmodus, online fanger inputen ingen gyllent datasett forutså, og mater dem tilbake inn i datasettene dine.

Hvor ofte bør du kjøre agent-evalueringer på nytt?

Kjør offline-evalueringer ved hver prompt-, modell- eller verktøyendring, gatet i CI. Kjør online-evalueringer kontinuerlig mot live trafikk, siden drift og oppdaterte modellvekter forringer agenter stille mellom utrullinger. Kurer det gyllne datasettet ditt på nytt hver gang produksjonen avdekker en ny feilmodus, slik at testsuiten sporer virkeligheten i stedet for eksemplene du skrev på dag én.

Hvordan fanger du jailbreaks og PII-lekkasjer før de lanseres?

Kjør adversarielle red-team-evalueringer som en gate før utrulling, og hold dem kjørende online. Kartlegg feilmodus mot OWASP Top 10 for LLM-er, NIST AI RMF og MITRE ATLAS, og simuler deretter angrep mot hver kategori med et rammeverk som det åpen kildekode-baserte DeepTeam. Blokker lanseringen ved enhver sårbarhet som slipper gjennom, ikke bare ved en lav gjennomsnittsscore.

Bør du bygge eller kjøpe en AI-agent-evalueringsplattform?

Bygg med åpen kildekode-verktøy (DeepEval for metrikker, Promptfoo for CLI-testing og red-teaming) når du er en solo-utvikler eller et lite ingeniørteam som er komfortabel med kode. Kjøp en plattform som Confident AI når et helt team trenger organisasjonsomfattende no-code-tilgang, administrert sikkerhetstesting og produksjonsobservabilitet standardisert på tvers av prosjekter. De fleste team starter med OSS og bygger seg videre derfra.

Er LLM-as-a-judge pålitelig for å score agenter?

Den er nyttig, men støyete. En LLM-dommer skalerer til tusenvis av spor billig, men den er ikke-deterministisk og deler ofte agentens blindsoner, så den kan stemple gjennom et plausibelt-men-feil svar. Kalibrer den mot menneske- eller fagekspert-merkelapper på et utvalg, behandle scorene som et retningssignal, og la høyrisikobeslutninger styres av deterministiske sjekker der du kan.

3-lagssystemet, kort fortalt

Score handlingsforløpet, ikke bare svaret. Valider verktøykall på tre akser: riktig verktøy, riktige argumenter, riktig steg. Kjør de samme metrikkene offline og online, på live spor, i en løkke som kurerer ekte feil tilbake inn i datasettene dine. Og sperr utrullingen på sikkerhet, ikke bare nøyaktighet.

Start med laget som svir mest: lanserer du blindt, koble opp online-evalueringer først; lanserer du usikkert, bygg sikkerhetsgaten først. Bygg det med de åpen kildekode-baserte verktøyene DeepEval og Promptfoo, eller kjøp en plattform som Confident AI når et helt team trenger no-code-tilgang og administrert sikkerhet. Og vil du heller ha ingeniører til å koble opp hele løkken for deg, er det akkurat den typen ting teamet vårt gjør hver eneste uke.