Hvorfor AI-agenter består QA og alligevel fejler i produktion

Kontinuerlig læring bliver til den ingeniørmæssige disciplin for at gøre agenter bedre efter installation, uden at ødelægge det, der allerede fungerer.

En AI-agent kan bestå enhver præ-lanceringsevaluerings-test og alligevel fejle i produktion en uge senere. Det er ikke en modsætning. Evaluerings-sættet afspejler, hvad teamet vidste, de skulle teste før lanceringen. Produktion er, hvor de manglende tilfælde viser sig: underlige formuleringer, manglende kontekst, værktøjskanter, utålmodige brugere, modsætningsfulde politikker og arbejdsgange, som ingen benchmark-designer forestillede sig.

Agenten bliver korrektur af brugerne hele tiden. Den skuffede brugere. Så sluttes sessionen, og loggen gemmes, og den næste bruger møder i væsentlig grad det samme system.

Det er derfor, kontinuerlig læring bliver central for agent-teknik. Det er ikke en funktion af ét produkt. Det er en kategori af metoder til at gøre agenter bedre fra erfaring, samtidig med at det, der allerede fungerer, bevares. Klassisk kontinuerlig læring-forskning definerede problemet som læring over tid uden katastrofalt glemsomhed. Agenter gør dette problem bredere. Det, der ændrer sig, kan være en model, men det kan også være en prompt, et værktøj, en færdighed, en arbejdsgang eller en hukommelse.

Denne forskel er vigtig, fordi de fleste agent-fejl ikke løses ved at nå frem til model-træning først.

Finjusterings-refleksen er for snæver

Når holdene taler om at gøre et AI-system bedre, lyder planen ofte sådan: samle fejl, mærk bedre svar, finjuster modellen. Denne instinkt er forståelig. Overvåget finjustering, Direkte Præference-Optimering, Gruppe Relativ Politik-Optimering, og parameter-effektive metoder som LoRA er nyttige værktøjer, når modellen selv skal ændres.

Men mange produktionsfejl er ikke model-vægt-fejl. De er system-fejl.

Agenten kan afhænge af en forældet hukommelse, springe over en påkrævet bekræftelse, kalde et værktøj med det forkerte argument, eller dirigere en sag gennem den forkerte arbejdsgang. Ofte er problemet ikke grundmodelens evne. Det er konteksten, hukommelsen, værktøjsgrænsefladen eller arbejdsgangen omkring den.

En moderne agent har flere lag. Modellen resonnerer og genererer. Harnessen omkring den definerer prompterne, værktøjerne, færdighederne, koden, dirigeringen og arbejdsgangen. Hukommelsen bærer fakta og lært procedurer over sessioner. Kontinuerlig læring er disciplinen om at bestemme, hvilket lag der skal ændres, hvor lille ændringen kan være, og hvordan man kan verificere, at ændringen virkelig hjalp.

Nogle gange er den rigtige løsning en hukommelsesskrivning. Nogle gange er det en prompt-redigering. Nogle gange er det en værktøjs-indpakning, en dirigering-regel eller en arbejdsgangs-patch. Finjustering skal forblive tilgængelig, men det skal ikke være det første svar på hver fejl.

Benchmark er nyttige, men produktion giver sjældent en

Der er spændende arbejde med at optimere agent-harness selv. Metoder som GEPA, Meta-Harness, og relaterede prompt eller arbejdsgangs-optimerings-tilgange behandler agenten som et system, der kan muteres og testes. De kan foreslå redigeringer af prompter eller andre harness-komponenter, køre kandidater og beholde versionerne, der scorer bedre.

Det er den rigtige retning. Det flytter forbedring ud af den snævre ramme af “opdater vægt” og ind i den bredere ramme af “forbedr agenten”.

Men der er en fælde: disse metoder antager normalt en benchmark. De har brug for en opgave, der kan køres gentagne gange, og en evaluator, der siger, om kandidat A er bedre end kandidat B. Uden det bliver optimering til gætteri med bedre værktøjer.

Det er ikke, hvad de fleste hold har i produktion.

Hvad de har, er logfiler. De har spor, bruger-korrektioner, support-billetter, thumbs-down-hændelser, eskalations-noter og lejlighedsvis ekspert-tilbagemeldinger. Disse signaler er værdifulde, men de er ikke endnu en benchmark. De fortæller dig, noget skete. De fortæller dig ikke automatisk, hvordan du genspiller det, hvad succes skal se ud til, eller hvordan du scorer en foreslået løsning.

Denne lukke er, hvor mange kontinuerlige-læring-bestræbelser stagnere. Holdet har erfaring, men ikke endnu et lærings-miljø.

Logfiler er ikke lektioner

En produktions-log optager en vej gennem en interaktion. En bruger bad om en flyvning. Agenten søgte. Brugeren sagde, datoen var forkert. Det er bevis for en fejl, men det er ikke nok til at lære fra.

Logfilen definerer ikke modfaktisk. Skulle agenten have bedt om bekræftelse? Skulle den have sluttede datoen fra tidligere kontekst? Skulle den have kaldt et andet værktøj? Skulle den have nægtet at fortsætte, indtil usikkerheden var løst? En menneske kan vide svaret efter at have læst sporet, men systemet får ikke den struktur for gratis.

Til kontinuerlig læring kan fungere, skal en rå fejl omdannes til noget, der kan genspilles. Det betyder en opgave, agenten kan møde igen, en bruger eller simulator, der genskaber det relevante mønster, værktøjer, agenten kan kalde, og evaluatore, der definerer succes. Evaluator kan kontrollere det endelige svar, værktøjskald, en politik-grænse, latency, omkostninger eller alle ovenstående.

Dette er den mindre synlige del af arbejdet, men det er den del, der gør forbedring virkelig. Når en fejl bliver til et genspillbart miljø, kan du stille et konkret spørgsmål: gjorde den foreslåede ændring virkelig fikse adfærden?

Uden det skridt er holdene mest patching fra hukommelse.

David Silver og Richard Sutton har beskrevet en kommende æra af erfaring, hvor agenter lærer primært fra interaktion med verden frem for fra statisk menneskelig data. For virksomheds-agenter afhænger denne vision af, at omdanne rodet produktions-erfaring til miljøer, der kan genspilles, scores og genbruges.

Erfaring alene er ikke nok. Den skal gøres testbar.

Regressions-kost er den skjulte pris

Selv når en fejl bliver testbar, er det sværeste stadig tilbage: at fikse den uden at ødelægge noget andet.

Enhver, der har vedligeholdt et komplekst agent, har set dette mønster. Du tilføjer en instruks, så agenten eskalerer aggressive refund-anmodninger. Nu eskalerer den rutinemæssige refunderinger, der skal håndteres hurtigt. Du reducerer værktøjskald i en arbejdsgang. Nu springer en anden arbejdsgang over en påkrævet kontrol. Du retter en forældet hukommelse. Nu overgeneraliserer agenten korrektionen til en anden produktlinje.

Hver patch har mening lokalt. Systemet drifter dog globalt.

Dette er agent-versionen af katastrofalt glemsomhed. I neurale netværk henviser udtrykket normalt til ny træning, der overskriver ældre evner. I agenter er fejlen bredere og ofte sværere at se. Glemsomhed kan ske i prompter, værktøjer, hukommelse, dirigering og arbejdsgang. Det viser sig ikke som en ren metric på en træningskurve, men som en bruger, der siger: “Dette fungerede før”.

Det er derfor, regression-kontrol ikke kan være en sidste gennemgangstrin. Det skal være inde i læringssammenhængen selv.

Målet er ikke blot at maksimere præstation på den nyeste fejl. Målet er at forbedre den nye sag, samtidig med at de gamle sager bevares. Hver løsning, der virker, skal blive en del af agentens voksende hukommelse af, hvad der skal fortsætte med at fungere. I praksis betyder det, at gamle fejl bliver til regressionstest. Agentens historie bliver en begrænsning, ikke blot et arkiv.

Dette er, hvor kontinuerlig læring bliver mere som alvorlig software-teknik end prompt-tænkning. En ændring er ikke god, fordi den lyder bedre. Det er godt, fordi det forbedrer en målt adfærd og ikke regresserer de adfærder, systemet allerede havde erhvervet.

Hvad praktisk kontinuerlig læring kræver

En produktions-klar kontinuerlig læringssammenhæng kræver fire egenskaber.

Først skal fejl være genspillbare. En enkeltstående fejl er en anekdote. Et genspillbart, vurderet miljø er en test. Indtil agenten kan møde det samme mønster igen, kan ingen bevise, at løsningen virkede.

Anden, diagnosen skal være holistisk. Løsningen kan tilhøre modellen, men den kan også tilhøre hukommelsen, prompten, værktøjs-laget eller arbejdsgangen. Den bedste løsning er normalt den mindste varige ændring, der forklarer fejlen.

Tredje, læring skal være livsvarig. Agenten skal ikke forbedre denne uge ved at tavs afslutte sidste uges hårdt-vundne adfærd. Tidligere succeser skal blive begrænsninger under optimering, ikke overraskelser efter installation.

Fjerde, sammenhængen skal være effektiv. Hvis hver forbedring kræver et kvartalsvis gen-træningsprojekt, vil systemet aldrig holde trit med produktionen. Sammenhængen skal prøve billige løsninger først, eskalere kun når nødvendigt og holde verificering tæt på ændringen.

Ingen af disse ting betyder, at agenter skal opdatere sig blindt. Det betyder det modsatte. Forbedring skal blive målbart. Hver ændring skal have en test, en før-og-efter-score og en regressionstjek.

Det er, hvad omdanner kontinuerlig læring fra en vag aspiration til en ingeniørmæssig disciplin.

Agenternes fremtid vil ikke blot blive defineret af større kontekst-vinduer, stærkere grund-modeller eller flere værktøjer. Disse ting vil være vigtige. Men det vigtigste spørgsmål for virksomheder er, hvad der sker efter installationen.

Når agenten fejler i morgen, kan systemet omdanne fejlen til en test? Kan det dirigere løsningen til det rigtige lag? Kan det bevise, at løsningen hjalp? Kan det bevise, at intet andet brød?

Hvis svaret er nej, lærer agenten ikke rigtigt fra produktionen. Det samler risiko.

De agenter, der betyder noget næste, vil gøre noget bedre. De vil akkumulere.