Grueproblemet i AI-agenter

Grueproblemet stammer fra filosoffen Nelson Goodman og handler om induktion, altså om hvordan vi slutter fra det, vi har set, til det, vi endnu ikke har set. Forestil dig en egenskab, der hedder 'grue'. Noget er grue, hvis det er grønt og observeret før et bestemt tidspunkt - eller blåt og observeret efter det tidspunkt. Hvis alle de emeralder, du nogensinde har set, er grønne, kan du ikke ud fra dine observationer afgøre, om de er 'grønne' eller 'grue'. Begge hypoteser passer perfekt med al din hidtidige erfaring. Først når du støder på en emerald efter skæringspunktet, viser forskellen sig.

Pointen er ubehagelig, men vigtig: perfekt overensstemmelse med fortidige data beviser ikke, at du har fundet den rigtige regel. Du har måske bare fundet en regel, der tilfældigvis også matcher fortiden.

Det er præcis det, der sker, når man træner eller tester en AI-agent på en historisk backlog af sager. Agenten lærer et mønster, der forklarer alle de sager, den har set. Men den kan ikke vide, om den har lært den regel, du håbede på - eller en anden regel, som bare tilfældigvis også passer på alt det, den er blevet vist indtil nu.

Jeg har selv stået med en produktionsversion af netop det problem. En agent, bygget til at klassificere og besvare henvendelser, blev testet mod tre måneders historisk backlog. Den ramte plet på stort set alt. Ingen tvivl, ingen tøven, høj konsistens sag for sag. Det så ud, som om vi havde fundet den rigtige regel.

En naturlig reaktion er at tænke: så skal vi bare have mere data. Men grueproblemet handler ikke om datamængde. Det handler om, at enhver endelig mængde af eksempler er forenelig med flere forskellige, indbyrdes modstridende regler. Du kan aldrig fylde nok historik på til at udelukke alle de alternative regler, som også passer på den historik.

Det betyder ikke, at test er nyttesløst. Det betyder, at test på historiske data kun kan bekræfte, at agenten har fundet *en* regel, der passer på fortiden. Det kan ikke bekræfte, at det er den *rigtige* regel, altså den regel du faktisk ville have valgt, hvis du kunne se ind i fremtiden. Jo mere ensartet backloggen er, desto større er risikoen for, at flere forskellige regler ser identiske ud i testen - og desto mere overbevisende bliver den falske tryghed.

Agenten, jeg nævnte, kørte upåklageligt gennem hele testperioden. Men i den første uge med rigtige, nye sager, som ikke var en del af historikken, begyndte den at fejle på en bestemt kategori af henvendelser. Ikke fordi den var dårligt bygget. Fordi den havde lært en regel, der tilfældigt havde matchet alle de gamle sager - men som ikke generaliserede til den type variation, der først dukkede op i den nye periode.

Det var ikke en teknisk fejl i klassisk forstand. Modellen gjorde præcis det, den var trænet til at gøre. Problemet lå i, at 'perfekt på historikken' og 'korrekt regel' er to forskellige ting, og vi havde - som de fleste - antaget, at de var det samme.

En fejlfri testkørsel beviser, at agenten har fundet en regel, der er konsistent med de data, den er testet på. Det er ikke lidt. Men det beviser ikke, at reglen er holdbar over for ny variation, at den generaliserer til sager, som ligner de gamle på overfladen men adskiller sig i det, der reelt betyder noget, eller at den vil holde, når konteksten ændrer sig, for eksempel en ny type kunde, et nyt produkt eller en ny sæson.

Det er her, jeg som selvstændig AI-konsulent for små og mellemstore virksomheder oftest ser forventningerne skride. En virksomhedsejer ser en imponerende demo eller en perfekt testrapport og går ud fra, at sagen er lukket. Men en demo, der er bygget på historiske data, kan aldrig bevise mere end at reglen har passet indtil nu. Mit mål er at gøre AI brugbar for virksomheder uden et teknisk udgangspunkt, og det starter med at være ærlig om, hvad en god test faktisk viser - og hvad den ikke gør.

Du kan ikke eliminere grueproblemet. Men du kan reducere risikoen for at blive overrasket af det. Nogle konkrete greb er værd at kende, før løsningen går i drift.