Prompt engineering in productie: hoe test ik wijzigingen?
Automatische vertaling
Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.
Definieer welke uitvoer correct is, verzamel representatieve gevallen en vergelijk één wijziging aan de prompt met een vaste referentie. Verbeter de instructie, de voorbeelden of de aangeleverde context op basis van de waargenomen fout. Houd een testset apart om te controleren of de wijziging ook werkt buiten de voorbeelden waarmee je haar hebt ontworpen.
Een prompt in productie moet omgaan met ontbrekende, dubbelzinnige en ongeldige invoer, naast gewone verzoeken.
Maak van fouten testgevallen
Stel dat een model velden uit facturen haalt. Neem gewone facturen, ontbrekende waarden, onbekende indelingen, tegenstrijdige datums en documenten die geen facturen zijn op. Definieer hoe het systeem elk geval moet afhandelen voordat je de prompt aanpast.
| Fout | Te vergelijken wijziging | Controle |
|---|---|---|
| Verplicht veld ontbreekt | Verduidelijk het veld en voeg een relevant voorbeeld toe | Het veld is aanwezig wanneer de bron het ondersteunt |
| Waarde verzonnen | Leg het gedrag bij ontbrekende waarden vast en lever bewijs | Veld zonder onderbouwing blijft leeg |
| Antwoord kan niet worden geparseerd | Gebruik een ondersteund uitvoerschema | Parser accepteert het volledige antwoord |
| Correcte waarde uit de verkeerde bron | Behoud de identiteit van de bron in de context | Waarde hoort bij het opgevraagde document |
Uitvoer die door een schema wordt beperkt, kan syntaxisfouten verhelpen. De documentatie van vLLM over structured outputs beschrijft de ondersteunde uitvoerbeperkingen. Een geldig JSON-object kan nog steeds een verkeerde datum of een ongefundeerde bewering bevatten, dus valideer de waarden apart.
Houd de vergelijking interpreteerbaar
Houd de versie van het model, de decoderingsinstellingen, de brongegevens, de definities van hulpmiddelen en de uitvoerlimieten gelijk tijdens het testen van de wijziging aan de prompt. Leg kwaliteit, foutcategorieën, tokens en latency vast. Herhaal niet-deterministische gevallen vaak genoeg om te zien of de verbetering aanhoudt.
Few-shot-voorbeelden moeten de werkelijke variatie dekken, inclusief ontbrekende of dubbelzinnige invoer. Voeg ze toe voor een gemeten probleem, in plaats van aan te nemen dat meer voorbeelden altijd helpen. Ook de positie in de context kan uitmaken: Lost in the Middle vond verschillen in het gebruik van bewijs tussen posities bij de geteste models en taken.
Gebruik expliciete stappen wanneer ze een fout eenvoudiger te isoleren maken, maar neem de extra aanroepen en interfaces mee in de vergelijking. Dwing rechten en andere verplichte toepassingsregels af in code; een systeembericht alleen kan ze niet garanderen.
Het gedeelte over prompts in productie in de LLM Engineering Guide legt de belangrijkste technieken en hun beperkingen uit.