DSPy: Broze Prompt Engineering Vervangen door Gecompileerde LLM-Pipelines

Ik loop steeds tegen dezelfde muur aan wanneer ik nadenk over financiële AI-pipelines: je kunt iets bouwen dat prachtig werkt op je testgevallen, en het vervolgens stilletjes uit elkaar zien vallen wanneer een leverancier zijn factuurformaat wijzigt of er een nieuw type transactie verschijnt. De broosheid zit bijna altijd in de prompts — handmatig opgestelde strings die niemand wil aanraken. DSPy, geïntroduceerd door Khattab et al. aan Stanford en gepubliceerd op ICLR 2024, stelt een fundamenteel andere manier voor om LLM-pipelines te bouwen die serieuze aandacht verdient van iedereen die boekhoudkundig werk probeert te automatiseren.

Het paper

DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines (Khattab, Singhvi, Maheshwari et al., ICLR 2024) herformuleert de constructie van LLM-pipelines als een programmeerprobleem in plaats van een prompt-engineeringprobleem. De kernobservatie is dat moderne LLM-applicaties doorgaans worden gebouwd als verzamelingen hardgecodeerde prompt-strings — wat de auteurs "prompt-templates" noemen — aan elkaar gelijmd met Python-besturingsstructuren. Wanneer het model verandert, of de taakverdeling verschuift, moet iemand die strings handmatig herschrijven.

DSPy vervangt prompt-templates door twee abstracties: signatures (signaturen) en modules. Een signatuur is een getypeerde, declaratieve specificatie van wat een LM-aanroep moet doen, compact geschreven als question -> answer of met expliciete veldbeschrijvingen in een Python-class. Een module verpakt een signatuur met een redeneerstrategie — ChainOfThought, ReAct, ProgramOfThought, MultiChainComparison, enzovoort. De cruciale toevoeging is een compiler (het paper noemt het een teleprompter) die een DSPy-programma, een kleine gelabelde dataset en een validatiemetriek neemt, en vervolgens automatisch few-shot demonstraties genereert, daaruit kiest en prompts produceert die geoptimaliseerd zijn voor die metriek. De compiler heeft geen labels nodig bij elke tussenstap — het kan demonstraties bootstrappen door een "teacher"-programma uit te voeren op ongelabelde invoer en sporen te filteren die resulteren in correcte einduitvoer.

Belangrijkste ideeën

• Signaturen ontkoppelen intentie van implementatie. Het schrijven van question, context -> answer is genoeg voor DSPy om te weten hoe de onderliggende LM-aanroep geconstrueerd, aangeroepen en geoptimaliseerd moet worden. De ontwikkelaar schrijft nooit een prompt-string.
• Compilatie is metriek-gestuurde bootstrapping. De BootstrapFewShot-optimizer voert het programma uit op trainingsinvoer, verzamelt invoer-uitvoer-sporen waar de pipeline slaagt, en gebruikt deze als demonstraties — geen menselijke annotatie van tussenliggende redeneerstappen vereist.
• Compiler ontsluit kleine modellen. Op GSM8K (wiskundige woordproblemen) scoort de standaard Llama2-13b 9,4% met zero-shot prompting. Na DSPy-compilatie met reflectie- en ensemble-modules bereikt het 46,9%. T5-Large (770M parameters), een model dat de meeste mensen afschreven voor complex redeneren, behaalt 39,3% exacte overeenkomst op HotPotQA met gebruik van slechts 200 gelabelde voorbeelden.
• Expert-prompts zijn niet het plafond. Op GSM8K bereikt GPT-3.5 met standaard few-shot prompting 25,2%. Door experts gemaakte chain-of-thought brengt dat naar ongeveer 72–73%. De gecompileerde reflectie-en-ensemble-pipeline van DSPy tilt dit naar 81,6% — zonder dat er een mens prompts schrijft.
• Programma's zijn samenstelbaar. Een multi-hop retrieval QA-pipeline in DSPy is ongeveer 12 regels Python. Het equivalent in LangChain, zo merken de auteurs op, bevat 50 strings van meer dan 1000 tekens aan handmatige prompt-inhoud.
• Drie compilatiestadia. De optimizer werkt als: kandidaatgeneratie (bootstrapping van sporen), parameteroptimalisatie (random search of Optuna over hyperparameters), en hogere-orde optimalisatie (ensembles, dynamische besturingsstructuren).

Wat standhoudt — en wat niet

De empirische resultaten zijn reëel en substantieel. Van 9,4% naar 46,9% gaan op GSM8K met Llama2-13b, terwijl er slechts een handvol gelabelde trainingsvoorbeelden wordt gebruikt, is niet incrementeel — het is het soort kloof dat kleine, goedkope modellen levensvatbaar maakt voor taken die voorheen GPT-4 vereisten. De architectuur is ook oprecht elegant: signaturen zijn gemakkelijk te lezen, modules zijn samenstelbaar, en de abstractie voelt niet lek voor de gedemonstreerde taken.

De beperkingen zijn echter reëel, hoewel het paper ze niet in een specifieke sectie bespreekt. De belangrijkste: de compiler is slechts zo goed als je metriek. Als je validatiemetriek onnauwkeurig is of niet overeenkomt met de werkelijke taakkwaliteit — wat in de praktijk extreem vaak voorkomt — zal de optimizer slimme manieren vinden om deze te maximaliseren terwijl hij faalt in wat je werkelijk belangrijk vindt. In een gestructureerd domein als de boekhouding zou je een metriek kunnen definiëren als "de journaalpost is in balans", maar een gebalanceerde boeking kan nog steeds volledig verkeerde grootboekrekeningen bevatten. De auteurs weten dat dit probleem bestaat, maar laten het over aan de verantwoordelijkheid van de ontwikkelaar.

Een tweede beperking: compilatie vereist nog steeds wat gelabelde data. Het paper beweert dat je slechts 10 voorbeelden kunt gebruiken met BootstrapFewShot, en dat alleen invoerwaarden nodig zijn (geen tussenlabels). Dat is waar in het beste geval, maar in de praktijk neemt de betrouwbaarheid van bootstrapping af wanneer het startprogramma geen enkel trainingsvoorbeeld kan oplossen. Als je pipeline voor financiële agenten een baseline-nauwkeurigheid van bijna nul heeft — wat gebruikelijk is wanneer je iets nieuws bouwt — kan de compilatie vastlopen.

Ten derde, en subtieler: DSPy optimaliseert prompts en demonstraties, maar het optimaliseert de programmastructuur zelf niet. Als je modules aan elkaar hebt gekoppeld op een manier die fundamenteel fout is voor de taak, zal de compiler je niet helpen. Het ontwerp van het programma blijft de taak van de ontwikkelaar.

Waarom dit belangrijk is voor financiële AI

Het probleem van de broosheid van prompts is misschien wel de grootste praktische hindernis voor het in productie nemen van financiële AI-agenten. Een pipeline die transacties categoriseert door omschrijvingen te koppelen aan rekeningen, zal degraderen telkens wanneer de gegevens van de leverancier van formaat veranderen, wanneer er een nieuwe uitgavencategorie verschijnt, of wanneer het rekeningschema wordt bijgewerkt. Met DSPy definieer je de taak abstract (transaction_description, chart_of_accounts -> account_code, confidence) en laat je de compiler de optimale demonstraties uitzoeken telkens wanneer de distributie verschuift.

Specifiek voor Beancount zie ik een pipeline voor me die gestructureerd is als drie aaneengeschakelde DSPy-modules: één die gestructureerde transactiegegevens extraheert uit ruwe bank-exports, één die de best passende rekening zoekt in het bestaande rekeningschema van het grootboek, en één die de resulterende journaalpost valideert tegen de beperkingen van het dubbel boekhouden. Elke module krijgt zijn eigen signatuur; het hele programma wordt gecompileerd tegen een metriek die zowel de boekhoudkundige correctheid als de naleving van het formaat controleert. Het probleem van de metriek-kwaliteit weegt hier het zwaarst — je hebt een metriek nodig die foutieve rekeningen vangt, niet alleen ongebalanceerde boekingen — maar dat is een oplosbaar technisch probleem.

De diepere implicatie: DSPy verschuift het werk van "betere prompts schrijven" naar "betere metrieken schrijven en kleine gelabelde datasets verzamelen." Dat is een veel duurzamere technische praktijk voor een financieel systeem in productie dat mee moet evolueren met veranderingen in regelgeving, structuren van rekeningschema's en transactieformaten.

Wat nu te lezen

• OPRO: Large Language Models as Optimizers (Yang et al., arXiv:2309.03409) — De aanpak van Google DeepMind voor prompt-optimalisatie via iteratieve, door LM gegenereerde verfijning; een nuttig tegenwicht voor de bootstrapping-aanpak van DSPy.
• TextGrad: Automatic "Differentiation" via Text (Yuksekgonul et al., arXiv:2406.07496) — formuleert optimalisatie als backpropagation via tekstuele feedback in plaats van metriek-gestuurde bootstrapping; toont sterke resultaten op het gebied van codering en wetenschappelijke taken waar de aanpak van DSPy zwakker is.
• DSPy Assertions: Computational Constraints for Self-Refining Language Model Pipelines (Singhvi et al., arXiv:2312.13382) — voegt harde en zachte beperkingen toe aan DSPy-programma's, waardoor pipelines zichzelf kunnen corrigeren wanneer de uitvoer domeinregels overtreedt; direct relevant voor het afdwingen van boekhoudkundige invarianten.