Lad os være ærlige. De fleste “smarte” prompt-tricks dør, når de rammer produktion. GEPA-tutorialen fra MarkTechPost er en sjælden undtagelse. Den viser trin for trin, hvordan man starter fra en svag seed-prompt, bygger et lille deterministisk benchmark, designer en struktureret evaluator, kører refleksive forbedringsloops og måler på et hold-out sæt. Ikke research-fluff. Kode.
I tutorialen bruges GEPA som refleksivt prompt-evolutionsframework til at forbedre løsningen af aritmetiske word problems. Der installeres GEPA og LiteLLM, sættes OpenAI-nøgler, og konfigureres to adskilte modeller: en opgavemodel og en refleksionsmodel. Der er sat et hårdt loft for metrik-kald: 100. Fokus er kontrol og reproducerbarhed. Det er forfriskende konkret (kilde 1769, afsnittet “Installing GEPA and LiteLLM…” med TASK_LM = “openai/gpt-4o-mini”, REFLECTION_LM = “openai/gpt-4.1”, MAX_METRIC_CALLS = 100).
GEPA i tutorialen kort fortalt
Workflowet starter bevidst svagt med en simpel seed-prompt. Derefter bygges et deterministisk datasæt af aritmetiske problemer, hvor facit genereres programmatisk, så fejl kan måles entydigt. Evaluatoren er struktureret – ikke løs tekst – og feedbacken er handlingsorienteret: hvorfor fejlede kandidaten, og hvad skal ændres. GEPA itererer derefter på baggrund af den feedback.
Der bruges en multi-komponent prompt, hvor både “instructions” og “output format rules” udvikler sig i takt. Til sidst sammenlignes baseline og den optimerede prompt på et hold-out sæt. Træning og test holdes adskilt, selvom “træning” her er prompt-evolution og ikke parameterlæring (kilde 1769).
Hvorfor den refleksive tilgang virker
Struktur skaber stabilitet. Når evalueringen har klare kriterier, og feedbacken peger på konkrete rettelser, undgår man tilfældige forbedringer fra iteration til iteration. I aritmetiske opgaver er evalueringskriteriet skarpt: er facit korrekt, og er formatet fulgt. Det reducerer støj og gør det muligt for refleksionsmodellen at samle pålidelige mønstre – fx “forklar først, regn bagefter” eller “afslut med kun tal”.
Vores erfaring er, at multi-komponent-prompten hjælper, fordi formateringsregler ofte glider i praksis. Når output-formatet er en førstegangsborger i prompten, ikke en parentes, får man færre problemer downstream. Små ting – dyre, hvis de mangler i produktion.
Konfiguration i praksis betyder noget
Tutorialens konfiguration er tydelig: GEPA + LiteLLM installeres via pip, OpenAI-nøglen sættes via miljøvariabel, og modellerne defineres som TASK_LM = “openai/gpt-4o-mini” og REFLECTION_LM = “openai/gpt-4.1”. MAX_METRIC_CALLS = 100 lægger et hårdt låg på evaluator-kørslerne (kilde 1769, samme kodeblok). Det styrer både omkostninger og risiko for overfitting.
Praktisk betyder adskilte modeller, at latency og pris kan balanceres: opgavemodellen kan være billigere og hurtigere, mens refleksionsmodellen kan være stærkere men dyrere. Ifølge vores interne test gav det lavere driftspris, men langsommere refleksionsrunder. Et fornuftigt kompromis i hverdagen, hvor man sjældent optimerer kontinuerligt, men kører batches.
Hold-out validering er ikke pynt
Tutorialen slutter med at sammenligne baseline og optimeret prompt på et hold-out sæt. Det er nødvendigt for at undgå, at GEPA “lærer” træningssættet udenad. For aritmetik er metrikkerne typisk simple: nøjagtighed, format-overholdelse og eventuelt konsistens i forklaringer. Supplér med stabilitet over flere runs: kør tre gentagelser og mål varians. Hvis gevinsten kollapser fra 12 til 1 procentpoint, er den ikke reel.
Én detalje, som tutorialen ikke dækker, er økonomien pr. metrik-kald og faktiske token-forbrug. Mål det i PoC, ellers ved ingen, om 100 metrik-kald koster 30 kroner eller 3000 i jeres domæne.
Fra notebook til pipeline
Opskriften er CI/CD-egnet. Læg benchmark-data og evaluator-logik i repo, kør GEPA-optimering bag en feature branch, og mål mod hold-out ved hver PR. Sæt gates: hvis nøjagtighed ikke når baseline + margin, så blokér merge. Vi har en anonymiseret pipeline, hvor evaluator-tests kører i GitHub Actions og skriver resultater til et lille SQLite-artefakt. Kedsommeligt. Virker.
Observabilitet er også et krav. Gem kandidat-prompt, evaluator-feedback, modelnavne, seed og versionsstempel i hvert run. Når noget bryder, spørger produktchefen “hvorfor”. Uden audit-log er svaret et skuldertræk. Det holder ikke i produktion.
Budget og metrik-disciplin
MAX_METRIC_CALLS = 100 i tutorialen er en klog start. Sæt et loft i PoC, fx 50–200 afhængigt af datasæt, og hold jer til det. Det forhindrer, at evolutionen overfitter via mængden af evalueringsfeedback – og holder økonomien i kort snor. Sæt budgettet som miljøvariabel i pipeline, så det ikke kan omgås lokalt.
Vi fordeler ofte metrik-kald i runder: fx 4 runder af 25 og tidligt stop, hvis forbedringen flader ud. Lavpraktisk, men det redder aftener.
Hvornår GEPA ikke er magi
Risikoscenarierne er konkrete. Domæner med høj semantisk variation, utydelige facit eller svag ground truth er svære. En kreativ kunde-e-mail med halve krav bliver ikke tydeligere, fordi du har en elegant evaluator. VentureBeats analyse af agentisk AI rammer netop det: outputmængden stiger, men kravafklaring, ansvar og operationalisering bliver flaskehalse. Menneskelig review vokser som opgave, ikke det modsatte (kilde 1771).
Vi har set det i en anonymiseret Snilld-case: efter at vi gjorde prompten konsistent, steg gennemløbet, men produktteamet brugte mere tid på at godkende grænsetilfælde. Gevinsten var der, men arbejdet flyttede sig. Ikke gratis.
Evaluator-design i virkeligheden
Tutorialen viser struktureret feedback, men går ikke i dybden med granularitet i fejltyper. I praksis anbefaler vi tre felter i evaluatorskemaet: “Correctness” med bool + facit; “Format compliance” med bool + korte noter; “Error category” med faste labels som arithmetic, format, reasoning-leap. Det skærper refleksions-feedbacken og gør dashboards læsbare.
Og ja, brug et større datasæt end 12 træningseksempler, hvis jeres domæne varierer. Tutorialens 18 i alt er fint til demo; i PoC sigt mod 50–100 og 200+ før bred produktion, især hvis opgaverne er mere frie end regnestykker (kilde 1769 bekræfter 18-størrelsen i kodeeksemplet; skalering er vores anbefaling, ikke en påstand om tutorialen).
Opsætning trin for trin fra tutorial til drift
Installér gepa og litellm. Sæt OPENAI_API_KEY som miljøvariabel. Konfigurer TASK_LM og REFLECTION_LM adskilt, gerne som i tutorialens kodeblok med “openai/gpt-4o-mini” og “openai/gpt-4.1” samt MAX_METRIC_CALLS = 100. Kopiér idéen med et deterministisk datasæt – brug faste seeds, programmatisk facit og en simpel split i træning/validering. Start med en svag seed-prompt, så forbedringer er målbare.
Byg evaluatoren som et lille bibliotek med faste felter. Gør feedbacken handlingsorienteret. Integrér den i test-suiten. Når baseline er målt, kør 2–4 evolution-runder. Stop, når gevinsten flader ud, eller budgettet rammes. Valider på hold-out. Først derefter rør produktion.
CI/CD og governance uden snørkler
Sådan kobles det ind i pipeline: Ved hver commit trigges unit-tests og evaluator-tests på et deterministisk seed. Artifakter gemmes med kandidat-prompt, fejltyper og metrikker. Release-gates kræver, at den optimerede prompt outperformer baseline på hold-out med fx +5 procentpoint, ingen regression på format og budget-overholdelse. Ellers no-go.
Governance er kedeligt men nødvendigt. Udpeg roller: en prompt-ansvarlig, en evaluator-ejer og en produktansvarlig, der godkender nye prompts. Log alle ændringer med årsag og før/efter-målinger. VentureBeat peger rigtigt på, at accountability ikke forsvinder med mere AI. Den stiger. Gør det synligt fra dag ét (kilde 1771).
Hvad vi lærte i en anonymiseret case
Vi lavede en hurtig PoC på økonomiske tekster. Seed-prompten var bevidst fattig, evaluator stram. Første run gav bedre nøjagtighed, men flere format-fejl. Overraskende, men logisk. Vi strammede formatreglerne i den multi-komponente prompt – og anden runde stabiliserede både facit og format. Det gode: refleksionsfeedbacken fandt en fejltype, vi overså. Bivirkningen: tiden pr. iteration var længere end forventet, fordi reflektionsmodellen var dyrere og langsommere end opgavemodellen. Småt, men relevant i drift.
Efter tre runder stod vi med færre manuelle rettelser i QA, mere forudsigelige outputs og ro i maven. Ikke perfekt. Men ikke længere lotteri. Ifølge vores interne log faldt variansen på hold-out over tre runs. Tallene holder vi for os selv; mønsteret er tydeligt.
Modargumenter og alternativer
“Kan vi ikke bare tage flere data eller finetune en lille model?” Jo, i nogle domæner er det svaret. Finetuning kan give højere loft, og human-in-the-loop med god annotering kan også trække. Men GEPA-lignende refleksiv optimering er et godt første skridt – billigt, gennemsigtigt og let at rulle tilbage. Det komplementerer finetuning: brug GEPA til at spidse retningslinjer og outputformater til, før I brænder dem ind i en finetunet model.
En anden indvending er, at “aritmetik er for let”. Fair. Men metoden kan overføres til skemaudfyldning, ekstraktion og simple beslutningstræer. Når ground truth er klar, virker strukturen.
Huller i rapporteringen vi ville lukke i en PoC
Tutorialen siger ikke, hvad 100 metrik-kald koster i tokens og penge. Mål det. Den siger heller ikke meget om latency og throughput pr. iteration. Tidsmål det i jeres setup. Endelig er det uklart, hvor granulær evaluatorens fejltyper bør være. Brug et simpelt schema som foreslået ovenfor og justér.
Skalerbarhed fra de 18 eksempler i koden til jeres domæne er heller ikke givet. Test på et bredere hold-out, og gentag med andre seeds. Læg governance ovenpå fra start – tutorialen dækker ikke audit-logning af prompt-ændringer; gør det til en P0 i produktion (kilde 1769).
Vores anbefaling næste uge
Saml et lille team i tre dage: Dag 1–2 designer I benchmark og evaluator; dag 3 kører I første GEPA-runde og måler baseline vs. kandidat. De næste fire uger bygger I CI-integration, sætter MAX_METRIC_CALLS som miljøvariabel, udpeger roller og ruller små forbedringer ind bag feature flags. Tag en ML-ingeniør, en prompt-ansvarlig og en produktperson med.
Succes måles på tre ting: bedre nøjagtighed på hold-out, lavere varians over gentagne runs og færre manuelle rettelser i QA. Når de tre peger samme vej, har I fat i noget.
- Kilder og validering
- Tutorialen dokumenterer GEPA-workflowet inkl. multi-komponent prompts, struktureret evaluator, hold-out validering og konfiguration med TASK_LM = “openai/gpt-4o-mini”, REFLECTION_LM = “openai/gpt-4.1”, MAX_METRIC_CALLS = 100. Se “Installing GEPA and LiteLLM…” og datasætsblokken med 18 problemer (kilde 1769).
- Vores vurderinger om drift, CI/CD og stabilitet bygger på Snillds interne erfaringer og skal ses som redaktionel baggrund, ikke ekstern dokumentation (kilde 1770).
- Risikoperspektivet om agentisk output og menneskelig review som flaskehals er underbygget af VentureBeat-analysen (kilde 1771).
