Hvorfor AI-agenter består QA og likevel feiler i produksjon

Kontinuerlig læring blir en ingeniørdisiplin for å forbedre agenter etter utrulling, uten å bryte det som allerede fungerer.

En AI-agent kan bestå hver pre-lanseringseval og likevel feile i produksjon en uke senere. Dette er ikke en motsigelse. Eval-settet reflekterer hva teamet visste å teste før lansering. Produksjon er der de manglende casene viser seg: merkelige formuleringer, manglende kontekst, verktøykantfall, utålmodige brukere, motstridende politikker og arbeidsflyter ingen benchmarkdesigner forestilte seg.

Agenten blir korrigert av brukerne hele tiden. Den skuffer brukerne. Deretter avsluttes sesjonen, loggen lagres, og neste bruker møter i praksis samme system.

Dette er hvorfor kontinuerlig læring blir sentral i agentteknikk. Det er ikke en funksjon i ett enkelt produkt. Det er en kategori metoder for å gjøre agenter bedre fra erfaringer samtidig som det som allerede fungerer, blir bevart. Klassisk kontinuerlig læringforskning rammet problemet som læring over tid uten katastrofalt glemming. Agenter gjør dette problemet bredere. Det som endrer seg, kan være en modell, men det kan også være en prompt, et verktøy, en ferdighet, en arbeidsflyt eller minne.

Denne distinksjonen er viktig, fordi de fleste agentfeil ikke løses ved å nå først etter modelltrening.

Feinjusteringsrefleksen er for smal

Når team diskuterer hvordan de kan gjøre et AI-system bedre, høres planen ofte slik ut: samle feil, merke bedre svar, finjustere modellen. Den instinktet er forståelig. Overvåket finjustering, Direkte Preferanseoptimering, Gruppe Relativ Politikkoptimering, og parameter-effektive metoder som LoRA, er nyttige verktøy når modellen selv må endres.

Men mange produksjonsfeil er ikke modellvektfeil. De er systemfeil.

Agenten kan være avhengig av utdatert minne, hoppe over en nødvendig bekreftelse, ringe et verktøy med feil argument, eller sende en sak gjennom feil arbeidsflyt. Ofte er problemet ikke modellens evne. Det er konteksten, minnet, verktøygrensesnittet eller arbeidsflyten rundt den.

En moderne agent har flere lag. Modellen resonerer og genererer. Harnessen rundt den definerer promptene, verktøyene, ferdighetene, koden, routingen og arbeidsflyten. Minnet bærer fakta og lærte prosedyrer over sesjoner. Kontinuerlig læring er disiplinen om å bestemme hvilket lag som må endres, hvor lite endringen kan være, og hvordan å verifisere at endringen faktisk hjalp.

Noen ganger er riktig fikse et minneskriv. Noen ganger er det en promptredigering. Noen ganger er det et verktøywrapper, en routingregel eller en arbeidsflytpatch. Finjustering bør forbli tilgjengelig, men det bør ikke være første svaret på hver feil.

Benchmark er nyttige, men produksjon sjelden gir deg en

Det er spennende arbeid på å optimalisere agentharnessen selv. Metoder som GEPA, Meta-Harness, og relaterte prompt- eller arbeidsflytopptimeringsmetoder behandler agenten som et system som kan muteres og testes. De kan foreslå redigeringer av prompter eller andre harnesskomponenter, kjøre kandidater og beholde versjonene som scorer bedre.

Dette er riktig retning. Det flytter forbedring ut av det smale rammen “oppdater vektene” og inn i den bredere rammen “forbedre agenten”.

Men det er en hake: disse metodene forutsetter vanligvis en benchmark. De trenger en oppgave som kan kjøres gjentakende og en evaluator som sier om kandidat A er bedre enn kandidat B. Uten det, blir optimalisering til å gjette med bedre verktøy.

Dette er ikke hva de fleste team har i produksjon.

Hva de har, er logger. De har spor, brukerkorreksjoner, støttesaker, tummened-hendelser, eskalasjonsnotater og sjeldne eksperttilbakemeldinger. Disse signalene er verdifulle, men de er ikke ennå en benchmark. De forteller deg noe skjedde. De forteller ikke automatisk hvordan du skal gjenta det, hva suksess skal se ut som, eller hvordan du skal score en foreslått fikse.

Denne gapet er der mange kontinuerlig-læringsforsøk stopper. Teamet har erfaring, men ikke ennå et læringsmiljø.

Logger er ikke lærdommer

En produksjonslogg registrerer én vei gjennom en interaksjon. En bruker ba om en flyreise. Agenten søkte. Brukeren sa datoen var feil. Dette er bevis på en feil, men det er ikke nok til å lære fra.

Loggen definerer ikke motfaktisk. Burde agenten ha bedt om bekreftelse? Burde den ha antatt datoen fra tidligere kontekst? Burde den ha ringt et annet verktøy? Burde den ha nektet å fortsette før usikkerheten var løst? En menneske kan vite svaret etter å ha lest sporet, men systemet får ikke denne strukturen gratis.

For kontinuerlig læring å fungere, må en rå feil bli omgjort til noe som kan gjentas. Dette betyr en oppgave agenten kan møte igjen, en bruker eller simulator som gjenskaper det relevante mønsteret, verktøy agenten kan ringe, og evalueringer som definerer suksess. Evaluator kan sjekke sluttsvar, verktøykall, en politikkgrense, latens, kostnad eller alle ovenfor.

Dette er den mindre synlige delen av arbeidet, men det er den delen som gjør forbedring reell. Når en feil blir et gjentakbart miljø, kan du stille en konkrete spørsmål: fikset den foreslåtte endringen faktisk feilen?

Uten denne steget, er teamene hovedsakelig å fikse fra minne.

David Silver og Richard Sutton har beskrevet en kommende æra av erfaring, hvor agenter lærer primært fra interaksjon med verden snarere enn fra statiske menneskelige data. For bedriftsagenter avhenger denne visjonen av å omdanne ustrukturert produksjons erfaring til miljøer som kan gjentas, scores og gjenbrukes.

Erfaring alene er ikke nok. Den må gjøres testbar.

Regress er den skjulte kostnaden

Selv når en feil blir testbar, forblir den hardeste delen: å fikse den uten å bryte noe annet.

Hver som har vedlikeholdt et komplekst agent har sett dette mønsteret. Du legger til en instruksjon så agenten eskalerer aggressive refund forespørsler. Nå eskalerer den også vanlige refunder som bør håndteres raskt. Du reduserer verktøykall i en arbeidsflyt. Nå hopper en annen arbeidsflyt over en nødvendig sjekking. Du fikser et utdatert minne. Nå overgeneraliserer agenten fikset til en annen produktlinje.

Hver fikse har mening lokalt. Systemet drifter likevel globalt.

Dette er agentversjonen av katastrofalt glemming. I neurale nettverk henviser uttrykket vanligvis til ny trening som overskriver eldre evner. I agenter er feilen bredere og ofte hardest å se. Glemming kan skje i prompter, verktøy, minne, routing og arbeidsflyt. Det viser seg ikke som en ren metrik på en treningkurve, men som en bruker som sier: “Dette fungerte tidligere”.

Derfor kan ikke regresskontroll være en siste gjennomgangstrinn. Den må være inne i læringsløkken selv.

Målet er ikke bare å maksimere ytelse på den nyeste feilen. Målet er å forbedre den nye saken samtidig som du bevare gamle. Hver fikse som fungerer, bør bli en del av agentens voksende minne over hva som må fortsette å fungere. I praksis betyr det at gamle feil blir regressjonstester. Agentens historie blir en begrensning, ikke bare et arkiv.

Dette er hvor kontinuerlig læring blir mer som alvorlig programvareutvikling enn prompttinkering. En endring er ikke god fordi den høres bedre ut. Den er god fordi den forbedrer et målt atferd og ikke forverrer de atferdene systemet allerede hadde tjent.

Hva praktisk kontinuerlig læring krever

En produksjonsklar kontinuerlig læringsløkke trenger fire egenskaper.

Først, feil må være gjentakbare. En engangsfeil er en anekdote. Et gjentakbart, gradert miljø er en test. Før agenten kan møte samme mønsteret igjen, kan ingen bevise at fikset fungerte.

Andre, diagnose må være helhetlig. Fikset kan tilhøre modellen, men det kan også tilhøre minnet, prompten, verktøylaget eller arbeidsflyten. Den beste fikset er vanligvis den minste varige endringen som forklarer feilen.

Tredje, læring må være livslang. Agenten bør ikke forbedre denne uken ved å stille stille undo sist ukes hardt-vunnet atferd. Tidligere suksesser bør bli begrensninger under optimering, ikke overraskelser etter utrulling.

Fjerde, løkken må være effektiv. Hvis hver forbedring krever et kvartalsvis re-treningprosjekt, vil systemet aldri holde tritt med produksjon. Løkken må prøve billige fikser først, eskalere bare når nødvendig, og holde verifikasjon nær endringen.

Ingen av dette betyr at agenter skal oppdatere seg blindt. Det betyr motsatt. Forbedring bør bli målbart. Hver endring bør ha en test, en før-og-etter-score og en regressjonskontroll.

Dette er hva gjør kontinuerlig læring fra en vag aspirasjon til en ingeniørdisiplin.

Fremtiden for agenter vil ikke bli definert bare av større kontekstvinduer, sterkere basismodeller eller flere verktøy. Disse vil være viktig. Men det viktigste spørsmålet for bedrifter er hva som skjer etter utrulling.

Når agenten feiler i morgen, kan systemet omdanne feilen til en test? Kan det sende fikset til riktig lag? Kan det bevise at fikset hjalp? Kan det bevise at ingenting annet brøt?

Hvis svaret er nei, lærer agenten ikke virkelig fra produksjon. Den akkumulerer risiko.

Agentene som betyr noe neste, vil gjøre noe bedre. De vil kumulere.