SPL: Orchestrating Workflows with Declarative Deterministic-Probabilistic Composition
Dit artikel introduceert SPL (Structured Prompt Language), een declaratief framework dat deterministische en probabilistische computatie binnen één enkele specificatie verenigt om model-agnostische workflow-orchestratie mogelijk te maken, waarbij door middel van uitgebreide experimenten wordt aangetoond dat de solver-gebaseerde aanpak een significant hogere door machines geverifieerde correctheid bereikt in vergelijking met niet-geverifieerde, enkel op LLM gebaseerde outputs.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je een super-slimme robotassistent probeert te bouien die je kan helpen met je huiswerk. Op dit moment is het bouwen van deze assistenten alsoals het proberen te bouwen van een auto waarbij de motor, het stuur en de GPS door verschillende bedrijven zijn gemaakt, verschillende talen spreken en aan elkaar geplakt moeten worden met rommelige, op maat gemaakte tape. Je moet een programmeerwizard zijn om ze met elkaar te laten praten.
Het paper introduceert SPL (Structured Prompt Language), wat als een universele afstandsbediening is die eindelijk de "creatieve" kant van de robot en de "reken" kant van de robot samen laat werken in één enkel, schoon instructieboekje.
De Twee Breinen: De Dromer en de Rekenaar
Het paper betoogt dat huidige AI-tools vastzitten in één modus. Ze zijn ofwel Dromers (LLM's) die geweldig zijn in het schrijven van verhalen, het raden van antwoorden en chatten, maar die soms feiten verzinnen of fouten maken in de wiskunde. Of ze zijn Rekenaars (zoals SymPy of SageMath) die perfect zijn in wiskunde en logica, maar geen grapjes kunnen begrijpen of een verhaal kunnen schrijven.
De auteurs zeggen: "Waarom niet beide?" Ze stellen een systeem voor waarbij de Dromer (Systeem 1) het probleem ontleedt en uitlegt, terwijl de Rekenaar (Systeem 2) het eigenlijke zware werk doet en het werk controleert.
De Grote Twist: Het paper voert expliciet argumenten aan tegen het idee dat de AI "snel" of "langzaam" moet zijn om de één of de ander te zijn. Het gaat niet over snelheid; het gaat over hoe ze denken. Een rekenaar kan traag zijn als hij een supermoeilijk bewijs levert, en een dromer kan snel zijn als hij gewoon wat gokt. De sleutel is weten welk brein voor welke taak wordt gebruikt.
De "Ontwerp Eén Keer, Zet Overal In" Magie
Dit is het coolste deel: Met SPL schrijf je je instructies één keer in een speciaal .spl-bestand. Je hoeft de code niet te herschrijven als je wilt dat het draait op je laptop, in de cloud, of op een gigantisch supercomputer-grid.
Denk aan een recept. Je schrijft het recept één keer. Of je nu kookt op een klein kampeerfornuis (je laptop), in een luxe keuken (de cloud), of in een enorme industriële fabriek (een gedistribueerd grid), het recept blijft hetzelfde. Je vertelt het systeem alleen waar het moet koken wanneer je het start. Het paper noemt dit DODA (Design Once, Deploy Anywhere).
De "Verifier Ladder" (Verificatie-ladder)
Hoe weten we of de wiskunde klopt? Het paper introduceert een "Verifier Ladder" met drie sporten:
- Sport 1 (SymPy): Goed voor basis algebra en calculus. Het is snel en eenvoudig.
- Sport 2 (SageMath): Voor moeilijker werk zoals getaltheorie en meetkunde.
- Sport 3 (Lean 4): De ultieme eindbaas. Dit is voor formele bewijzen die door een computer worden gecontroleerd om 100% wiskundig waar te zijn, zoals een juridisch contract voor wiskunde.
Het paper laat zien dat je een workflow kunt schrijven die eerst Sport 1 probeert. Als dat faalt, klimt het systeem automatisch naar Sport 2, en als dat faalt, naar Sport 3. Je hoeft niet de "als dit faalt, probeer dat"-code te schrijven; de taal handelt het voor je af.
Het Experiment: Wat Er Eigenlijk Gebeurde
De auteurs hebben niet alleen geraden; ze hebben een enorme experiment uitgevoerd. Ze testten 10 verschillende AI-modellen op 20 verschillende wiskundeproblemen (variërend van makkelijk tot expertniveau) en draaiden elke test 3 keer. Dat zijn in totaal 1.200 runs.
Ze vergeleken twee manieren om de problemen op te lossen:
- De "Alleen LLM"-arm: De AI raadt alleen en schrijft het antwoord op.
- De "Solver"-arm: De AI breekt het probleem af, stuurt de wiskunde naar de Rekenaar, krijgt het geverifieerde antwoord terug, en schrijft dan de uitleg.
De Resultaten:
- Het Goede Nieuws: De Solver-arm was ongelooflijk nauwkeurig. Voor de beste modellen, zoals
gemma4:e2b, kregen ze 93% van de antwoorden goed wanneer deze door de rekenaar werden geverifieerd. Zelfssonnet-4-6kreeg 85% goed. - De Catch: De "Alleen LLM"-arm kon bijna altijd een antwoord produceren (bijna 100% van de tijd), maar het was niet geverifieerd. De Solver-arm bewees dat alleen omdat een AI iets zegt, betekent dat het nog niet waar is.
- De Bottleneck: De belangrijkste reden waarom de Solver-arm faalde, was niet dat de AI de wiskunde niet kon (de Rekenaar deed dat immers!), maar omdat de AI de vormgeving (formatting) niet correct uitvoerde. De AI moest de wiskunde in een zeer specifieke code-achtige format schrijven (
expr|op) zodat de Rekenaar het kon begrijpen. Als de AI de vormgeving verpestte, weigerde de Rekenaar het. - De Verrassing: Een klein, open-source model genaamd
gemma4:e2b(dat veel kleiner is dan de gigantische, dure modellen) presteerde eigenlijk beter dan sommige van de enorme modellen bij het volgen van de regels. Dit suggereert dat voor deze specifieke taak, een goede "format-vertaler" zijn belangrijker is dan een gigantisch, superintelligent brein.
Wat het Paper NIET Zegt
Het paper is heel duidelijk over wat het niet doet:
- Het beweert niet dat AI-modellen nu perfect zijn in wiskunde op zichzelf. Sterker nog, het experiment liet zien dat zonder de Rekenaar, de modellen gewoon aan het gokken zijn.
- Het zegt niet dat "denkende" modellen (modellen die lang de tijd nemen om te "denken" voordat ze antwoorden) beter zijn. Sterker nog, het paper sloot sommige "denkende" modellen uit omdat ze te veel tijd besteedden aan nadenken en de ruimte opgebruikten voordat ze de specifieke code-format konden schrijven die de Rekenaar nodig had.
- Het claimt niet dat dit elk probleem oplost. Het experiment was specifief gericht op symbolische wiskunde. De auteurs suggereren dat het ook zou kunnen werken voor andere zaken zoals het controleren van code of het valideren van data, maar ze hebben dat nog niet bewezen.
De Kern van het Verhaal
Het paper bewijst dat door het "creatieve" deel van AI te scheiden van het "wiskundige" deel, en een computer de wiskunde te laten controleren, we veel betrouwbaardere resultaten krijgen. Het beste deel? Je hoeft geen programmeergenie te zijn om dit te doen. Je schrijft simpelweg het plan één keer, en het systeem regelt de rest, of je het nu draait op je laptop of op een supercomputer.
De auteurs maten dit met 1.200 runs en ontdekten dat hoewel de "Solver"-arm iets langzamer is (het kost een paar extra seconden om het werk te controleren), het een "misschien goed" antwoord verandert in een "door machine geverifieerd" antwoord. Voor de beste modellen kost deze verificatie bijna geen extra tijd, wat bewijst dat deze twee-modi-aanpak een praktische manier is om slimme, veiligere AI-assistenten te bouwen.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.