Prompt-chaining: complexe taken opknippen in stappen

Wanneer je Large Language Models (LLM's) inzet voor geavanceerde workflows, merk je al snel dat monolitische prompts hun grenzen bereiken. Als je in één enkele prompt vraagt om code te genereren, unit tests te schrijven, documentatie op te stellen én te controleren op beveiligingsfouten, neemt de kans op hallucinaties, vergeten instructies en suboptimale kwaliteit drastisch toe. De oplossing hiervoor is prompt-chaining: het opdelen van een complex doel in opeenvolgende, behapbare submensen.

Waarom prompt-chaining?

Prompt-chaining brengt structuur en voorspelbaarheid in AI-toepassingen. In plaats van te leunen op 'hoop' dat het model in één keer het perfecte eindresultaat produceert, dwing je modulariteit af:

• Beperkte context window belasting: Elk model in de keten krijgt exact de context en instructies die nodig zijn voor die specifieke stap, zonder ruis van overbodige randzaken.
• Gerichte optimalisatie: Als stap 2 faalt, hoef je niet het hele systeem aan te passen. Je finetunet enkel de prompt van die specifieke stap.
• Hogere betrouwbaarheid: Kleinere taken hebben een significant lager foutpercentage bij moderne LLM's dan gigantische multi-task prompts.

Output-naار-input koppelen

Het hart van prompt-chaining is de datastroom. De output van Stap N dient als gecontroleerde input voor Stap N+1. Dit kan handmatig in een chatomgeving, maar schittert pas echt in programmatische pipelines (zoals Python-scripts of orchestratie-tools).

Om te zorgen dat het model in de volgende stap direct kan werken met de aangeleverde data, is het cruciaal om te werken met gestructureerde formaten zoals JSON of duidelijke Markdown-secties tussen de stappen.

Foutafhandeling tussen stappen

In een keten kan er altijd iets misgaan: een model retourneert onvolledige code, vergeet een JSON-veld of produceert ongeldige syntax. Robuuste prompt-ketens bouwen daarom validatiechecks in:

• Validatiestappen (Validators): Voeg tussen cruciale stappen een deterministische check (of een snelle, goedkope LLM-check) toe die verifieert of de output voldoet aan vooraf ingestelde schema's.
• Fallback-mechanismen: Als de validatie faalt, stuur je de output mét de specifieke foutmelding terug naar de prompt om automatisch een correctie uit te voeren voordat de keten doorloopt naar de volgende fase.

Concreet Nederlands voorbeeld: Van ruwe notitie naar technische backlog

Stel, je wilt rommelige meeting-notities omzetten in kant-en-klare gebruikersverhalen (user stories) voor je development-team, inclusief technische acceptatiecriteria. Dit kun je opknippen in een keten van drie stappen:

Stap 1: Extractie van kernfuncties

Doel: Ruwe tekst filteren en alle expliciete en impliciete functionaliteiten isoleren.

Systeem: Je bent een nauwkeurige analist. Filter alle functionele wensen uit de onderstaande notulen.
Input: "[Ruwe meeting-notities over een nieuwe gebruikerslogin...]"
Output: Een gestructureerde lijst van ruwe feature-eisen.

Stap 2: Genereren van User Stories (Gherkin-syntax)

Doel: De gefilterde eisen omzetten naar professionele user stories met acceptatiecriteria.

Systeem: Ontvang de lijst met feature-eisen uit de vorige stap. Schrijf voor elke eis een user story in de vorm van 'Als [rol], wil ik [functionaliteit], zodat [waarde]', inclusief Given-When-Then acceptatiecriteria.
Input: [Output van Stap 1]
Output: Markdown-document met formele user stories.

Stap 3: Technische risico- en security-check

Doel: De gegenereerde stories controleren op mogelijke security-lekken (zoals OWASP Top 10) of technische bottlenecks.

Systeem: Controleer de onderstaande user stories kritisch op security-risico's, ontbrekende validaties en performance-knelpunten. Voeg beveiligingstaken toe waar nodig.
Input: [Output van Stap 2]
Output: Definitieve, goedgekeurde backlog-items met security-notities.