Pass^k-tester og GEPA: la optimalisatoren skrive agent-prompten for deg

«Promptene er ikke poenget. Promptene er vektorer der det tekstlige innholdet ikke betyr noe som helst.» Det er konklusjonen i foredraget «Prompts Aren't Real» på evaluation.club, skrevet av en ingeniør som presenterer seg som Dan. Han oppgir 25 år i bransjen og arbeid med agenter som utfører oppgaver for forbrukere, ikke chatboter.

Argumentet mot håndskrevne prompts er strukturelt. En ny prompt havner i en helt annen kontekstuell verden enn den ble testet i, skriver han: vekten av instruksjonene agenten allerede har påvirker hvordan den nye virker, som regel til det verre. Agenten endres dessuten over tid, og modellene kan skifte oppførsel på egen hånd.

Oppskriften starter derfor med måling. Han lar Claude lese skillen og generere både adverserielle scenarioer og harmløse scenarioer den nye prompten kan ødelegge. Alle uttrykkes som pass^k-tester, bransjeuttrykket for å kjøre samme scenario mange ganger. Så kobles prompten til en optimalisator, i eksempelet genetisk pareto (GEPA), som reflekterer over hvorfor prompten gjorde det bra eller dårlig og endrer den i en løkke.

Lysbildene viser tallene fra én slik kjøring på hans egen testsuite. Testen han kaller test_authenticity_laundering går fra 0 prosent uten skill til 55 prosent med den håndskrevne, og til 100 prosent etter optimalisering. En annen, test_brand_authenticity_question, flytter seg fra 22 til 94 prosent. Dette er eksempeltall fra ett prosjekt, ikke en uavhengig benchmark.

Fallgruven er at optimalisatoren koder testeksemplene rett inn i prompten. Motgiften er et holdout-sett med scenarioer den aldri fikk se, og i eksempelet holder begge testene samme nivå der. For krav som ikke lar seg avgjøre deterministisk, som merkevarestemme, blir LLM-dommeren et eget optimaliseringsprosjekt med et gullsett av merkede gode og dårlige svar.

«Domeneeksperter bør bruke innsatsen på å bygge artefaktene dette krever. De bør ikke bruke tiden på å kuratere prompts.» — Dan, «Prompts Aren't Real»

Dan skriver selv at han ikke føler seg sikker på hva han driver med. Det mest talende eksempelet er lite: da et strukturert JSON-felt fløt over med tekst, var fiksen å døpe feltet om fra «title» til «heading». Fordi fiksen er så vilkårlig, regner han med at den slutter å virke igjen.

Hva bør du gjøre?

1. Velg én prompt du allerede kjører, og uttrykk atferden du er redd for å miste som pass^k-scenarioer.
2. Kjør testene med og uten den nye prompten før du optimaliserer. Modellene håndterer noen ganger allerede det du bekymrer deg for.
3. Hold av et holdout-sett fra start, ellers vet du ikke om optimalisatoren lærte oppgaven eller pugget testene.