Iterativ förfining med exempel

Ett effektivt few-shot-exempel består av en kombination av indata och den exakta utdata du vill få tillbaka. Utdata måste följa det verkliga schemat eller den verkliga struktur som du kommer att använda i produktion – samma fält, samma skiftläge och samma struktur.

Nedan visar varje exempel en inmatad kommentar tillsammans med den exakta bedömningen. Modellen lär sig gränsdragningen: flagga endast verkliga motsägelser, inte anmärkningar på stil.

Exempel och uttryckliga kriterier kompletterar varandra; de ersätter inte varandra. Kriterier anger regeln, medan exempel kalibrerar den gråzon som regeln inte helt kan fånga i löptext.

Ett vanligt misstag av arkitekter är att hälla in exempel utan någon styrande instruktion. Då överanpassar modellen sig till ytligheten i exemplen. Börja alltid med ett tydligt kriterium – "flagga endast när X motsäger Y" – och låt sedan 2–4 exempel precisera var X och Y flyter ihop.

En tumregel: om du inte kan formulera kriteriet i en enda mening är uppgiften fortfarande otillräckligt specificerad, och fler exempel kommer inte att lösa det.

Iterativ förfining är testdriven. Innan du finjusterar prompten ska du sammanställa en liten märkt uppsättning representativa indata med korrekta utdata. Detta är din ground truth – varje ändring av prompten bedöms mot den, inte utifrån en magkänsla.

Håll testsetet åtskilt från dina few-shot-exempel. Om du finjusterar på samma fall som du lär ut med memorerar du i stället för att generalisera.

Förfiningsloopen är mekanisk och repeterbar:

• Kör prompten på varje testfall
• Jämför resultatet med den förväntade etiketten
• Undersök felen – vilken gräns missade modellen?
• Lägg till eller skärp ett exempel (eller ett kriterium) som riktar in sig på felet
• Kör om hela uppsättningen och kontrollera att inget försämrades

Ändra en sak per iteration. Om du gör flera ändringar samtidigt blir det omöjligt att veta vilken justering som hjälpte eller stjälpte.

Automatisera jämförelsen så att iterationerna går snabbt. Ett litet harness kör varje fall, poängsätter det och skriver ut missarna. Med strukturerad utdata kan du jämföra fält direkt i stället för att tolka löptext.

Observera tool_choice nedan: genom att tvinga fram ett verktygsanrop säkerställer du att modellen alltid returnerar schema-giltig JSON, så att din poängsättning aldrig fastnar på fritext.

När du hittar ett misslyckat fall frågar du dig: vilken tvetydighet orsakade det? Lägg sedan till ett exempel som ligger precis på den gränsen – inte ett slumpmässigt nytt fall. Ett skarpt exempel per feltillstånd generaliserar mycket bättre än tio generiska exempel.

Anta att modellen felaktigt flaggade en kommentar som parafraserade koden. Då skulle du lägga till ett parat exempel som visar parafras = ingen motsägelse. Modellen uppdaterar sin interna gränsdragning, och hela klassen av liknande missar försvinner.

Motstå frestelsen att fortsätta stapla exempel på varandra. Efter ungefär fyra per tvetydighet sväller kontexten och risken för lost-in-the-middle ökar, vilket innebär att modellen ägnar mitten av en lång prompt för lite uppmärksamhet.

Vissa fel gäller format eller struktur, inte resonemang – exempelvis ett felaktigt fält, en felaktig aritmetisk totalsumma eller en saknad hakparentes. För dessa är retry-with-feedback lösningen: skicka tillbaka den ursprungliga indatan, den felaktiga utdatan och det exakta valideringsfelet.

En viktig begränsning är att nytt försök hjälper när modellen kan producera rätt svar men råkade göra fel. Det hjälper inte när den information som krävs helt enkelt saknas i källan – inga nya försök kan hitta på data som inte finns.

När exemplen har format beteendet låser du strukturen med ett JSON Schema via verktygsanvändning. Det eliminerar syntaxfel och tvingar fram obligatoriska fält. En princip är viktigast: markera ett fält som obligatoriskt endast om det alltid finns.

Gör aldrig ett fält obligatoriskt om det kan saknas – modellen kommer att fabricera ett värde för att uppfylla schemat. För valfria eller öppna data använder du en enum med värdet "other" samt ett fritextfält för detaljer. Då förblir kontraktet utbyggbart utan att modellen tvingas hallucinera.

Innan du litar på den förfinade prompten ska du validera den med en oberoende, ny instans – inte samma session som skapade utdatan. En självgranskning i samma session är partisk: upphovet behåller sitt eget resonemang och kommer inte att ifrågasätta sig självt.

Lita inte heller enbart på ett sammanlagt resultat. En rubrik som 97 % träffsäkerhet kan dölja ett fält eller en indatatyp som fungerar mycket dåligt. Använd stratifierat urval och konfidens på fältnivå, kalibrerat mot ett märkt valideringsset, innan du automatiserar. Förfiningen är inte klar när genomsnittet ser bra ut – den är klar när varje delmängd klarar gränsen.

Viktiga slutsatser:

• Exempel slår adjektiv. Uttryckliga kriterier tillsammans med 2–4 riktade exempel presterar bättre än vaga instruktioner som ”var mer exakt”.
• Modellen generaliserar från few-shot-exempel – de fungerar bäst för konsistens, gränsfall, utdataformat och minskad hallucination.
• Arbeta testdrivet: skapa en märkt uppsättning, poängsätt den, lägg till ett gränsexempel per feltillstånd, kör om och ändra en sak i taget.
• Retry-with-feedback åtgärdar formatfel (skicka ursprunglig indata + felaktig utdata + exakt felmeddelande) – inte data som saknas i källan.
• Lås strukturen med ett JSON Schema; gör endast alltid närvarande fält obligatoriska; använd enum + ”other” + detaljer för utbyggbarhet.
• Validera oberoende: granskning med en ny instans är bättre än självgranskning i samma session, och stratifierade kontroller på fältnivå är bättre än enbart sammanlagd träffsäkerhet.