💬 NLP

Structured Prompt Language: Declarative Context Management for LLMs

Dit artikel introduceert SPL (Structured Prompt Language), een declaratieve, SQL-geïnspireerde taal die LLM's als generatieve kennisbanken behandelt en middelenbeheer, query-optimatie, RAG-integratie en veerkrachtige agentische workflows verenigt in één raamwerk dat prompt-boilerplate met 65% vermindert en kostenefficiënte uitvoering op verschillende modellen mogelijk maakt zonder code-aanpassingen.

Oorspronkelijke auteurs: Wen G. Gong

Gepubliceerd 2026-02-26

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Wen G. Gong

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 reusachtige, slimme kok hebt (de Large Language Model of LLM) die voor je kan koken. Deze kok is ongelooflijk getalenteerd, maar heeft een heel groot probleem: zijn keukentafel is klein.

In de wereld van AI noemen we die tafel het "contextvenster". Hoe meer ingrediënten (tekst, informatie, vragen) je op die tafel legt, hoe beter de kok kan koken. Maar als de tafel vol zit, moet je iets weggooien.

Vroeger (en nu nog vaak) deden programmeurs dit zo: ze liepen met een meetlint door de keuken, telden handmatig hoeveel ruimte elk ingrediënt innam, en gooiden er soms willekeurig wat af als de tafel vol raakte. Dat was stressvol, duur (want je betaalt per woord dat de kok leest) en leidde vaak tot rommelige maaltijden.

SPL (Structured Prompt Language) is de oplossing. Het is als het menu-systeem van een restaurant dat de kok vertelt wat hij moet koken, terwijl het systeem zelf zorgt voor de ruimteplanning op de tafel.

Hier is hoe het werkt, vertaald naar alledaagse taal:

1. De "Budget" is je Tafelruimte

Stel je voor dat je een diner boekt met een vast budget (bijvoorbeeld 8.000 woorden).

Vroeger: Je schreef een recept op een briefje en hoopte maar dat het paste.
Met SPL: Je zegt tegen het systeem: "Ik heb 8.000 woorden ruimte."
Het systeem (de "optimiser") kijkt dan: "Oké, voor de system-instructie heb je 20 woorden nodig, voor je vraag 200, en voor de recepten die je uit de bibliotheek haalt (RAG) heb je 3.000 nodig."
Als het totaal te groot wordt, knijpt het systeem automatisch de grootste stukken in (zoals een koffer die je dicht moet duwen) zodat alles past, zonder dat jij hoeft te rekenen.

2. De "EXPLAIN" Functie: De Keukenplaat

In SQL (de taal voor databases) kun je een commando geven om te zien hoe een query wordt uitgevoerd. SPL heeft iets vergelijkbaars: EXPLAIN.

Voor SPL: Je vraagt: "Laat me zien wat er gaat gebeuren voordat je het echt doet."
Het resultaat: Het toont je een plaatje van je tafel: "Hier ligt 30% van je ruimte voor de recepten, hier 25% voor je vraag, en hier 28% is nog leeg als buffer."
Waarom is dit cool? Je ziet direct dat je te veel geld (of ruimte) uitgeeft aan de verkeerde dingen. Je kunt dan zeggen: "Ah, ik gebruik te veel ruimte voor die oude chatgeschiedenis, ik haal die eruit." Je betaalt dus niet voor niets.

3. De "Scheiding van Taken": Kiezen vs. Koken

SPL maakt een duidelijke scheiding, net als in een goed restaurant:

SELECT (Kiezen): Dit is het verzamelen van ingrediënten. Je haalt recepten uit de bibliotheek, pakt je eigen notities en vraagt de kok wat hij al weet.
GENERATE (Koken): Dit is het daadwerkelijke koken. Pas als alle ingrediënten op de tafel liggen, begint de kok met het maken van het gerecht.
Dit zorgt ervoor dat je niet per ongeluk te veel ingrediënten op de tafel gooit voordat je begint met koken.

4. De "Magische Chef" (MoM Routing)

Stel je voor dat je een heel complex gerecht wilt maken: een Aziatisch gerecht, een Duits gerecht en een wiskundig probleem.

Vroeger: Je gaf alles aan één kok, die misschien niet goed in alle drie de specialiteiten was.
Met SPL: Het systeem is slim genoeg om te zeggen: "Deel dit op! De Aziatische onderdelen gaan naar de specialist in Aziatische keuken, de Duitse naar de Duitse specialist, en de wiskunde naar de wiskundige."
Dit gebeurt automatisch. Je schrijft maar één recept, en het systeem zorgt dat de juiste "chef" het juiste stukje kookt.

5. De "Magische Koffer" (Logische Chunking)

Wat als je een heel dik boek wilt samenvatten, maar je tafel is te klein?

Vroeger: Je moest het boek in stukken snijden en één voor één laten lezen, wat heel veel werk was.
Met SPL: Je zegt: "Deel dit boek in 4 stukken." Het systeem stuurt die stukken parallel naar vier kleine koks (of één kok die snel wisselt). Ze maken elk een samenvatting, en aan het einde wordt die samenvatting weer samengevoegd tot één groot gerecht.
Dit is veel sneller en goedkoper, alsof je een grote pizza in vier stukken snijdt en die tegelijk in de oven schuift in plaats van één gigantische pizza die nooit past.

6. De "Veilige Achterdeur" (SPL-flow)

Soms is de hoofdingang van het restaurant (de server) bezet of gesloten.

SPL-flow is als een slimme conciërge. Als de hoofdingang (bijv. een dure cloud-dienst) niet werkt, probeert hij automatisch de achterdeur (een lokale computer bij jou thuis) of een andere ingang. Jij als gast (de programmeur) merkt hier niets van; je maaltijd komt gewoon op tijd.

Waarom is dit belangrijk voor jou?

Voor programmeurs en bedrijfseigenaren betekent dit:

Minder gedoe: Je hoeft niet meer handmatig te tellen hoeveel woorden je gebruikt.
Besparen: Je ziet precies hoeveel het kost voordat je het doet, en kunt kiezen voor een goedkopere "kok" als dat kan.
Betrouwbaarheid: Het werkt op elke computer, of je nu een dure server hebt of een simpele laptop.
Voor iedereen: Als je ooit SQL (de taal voor databases) hebt gebruikt, voelt dit als een tweede natuur. Het is gewoon een nieuwe manier om te vragen om informatie, maar dan voor de slimste AI's van nu.

Kortom: SPL maakt van het chaotische "probeer-en-fout" van AI-programmeren een gestructureerd, voorspelbaar en slim proces, net als het overstappen van handmatig boodschappen doen naar het gebruik van een slim boodschappenlijstje dat automatisch de juiste winkels bezoekt.

Titel: Structured Prompt Language (SPL): Declaratief Contextbeheer voor LLM's

Auteur: Wen G. Gong
Datum: 22 februari 2026

1. Het Probleem: De Contextvenster-uitdaging

De opkomst van Large Language Models (LLM's) heeft een fundamenteel probleem in software-engineering blootgelegd: het beheer van het contextvenster. Dit is een beperkte hulpbron (token-budget) die bepaalt welke informatie een model kan verwerken.

Huidige praktijken in prompt engineering lijken sterk op database-programmering voordat SQL werd geïntroduceerd:

Imperatief en handmatig: Ontwikkelaars schrijven code (Python/JS) om strings te concateneren, tokens handmatig te tellen en heuristische truncatiestrategieën toe te passen.
Gebrek aan zichtbaarheid: Er is geen standaard manier om te inspecteren hoe tokens worden toegewezen over verschillende onderdelen van een prompt.
Geen optimalisatie: Er is geen automatische planner die beslist welke contextbronnen (RAG, geheugen, gebruikersinput) prioriteit krijgen of hoe ze moeten worden gecomprimeerd bij een overschrijding van het budget.
Vendor lock-in: Prompt-code is vaak gekoppeld aan specifieke API's, wat migratie bemoeilijkt.
Geen compositie: Prompts zijn monolithisch en moeilijk te hergebruiken, in tegenstelling tot SQL's Common Table Expressions (CTE's).

2. Methodologie: SPL als Declaratieve Query-taal

De kerninnovatie van het paper is het behandelen van een LLM niet als een simpele tekst-naar-tekst functie, maar als een generatieve kennisbank. SPL (Structured Prompt Language) is een declaratieve taal die geïnspireerd is op SQL en deze principes toepast op LLM-contextbeheer.

Kernprincipes:

Scheiding van Retrieval en Synthese: In tegenstelling tot SQL (waar SELECT zowel haalt als produceert), splitst SPL dit op:
- SELECT: Verzamelt context uit heterogene bronnen (systeemrollen, RAG, geheugen, gebruikersinput) binnen een token-budget.
- GENERATE: Triggert de synthese van nieuwe inhoud op basis van de verzamelde context.
Token Budget als Eerste-klasse Concept: Elke query moet een expliciet WITH BUDGET specificeren. De compiler (optimizer) is verantwoordelijk voor het toewijzen van dit budget over de bronnen.
Automatische Optimalisatie: Een ingebouwde optimizer berekent de token-toewijzing. Als de totale vraag het budget overschrijdt, past de optimizer proportionele compressie toe (grootste bronnen worden eerst ingekort) in plaats van ruwe truncatie.
EXPLAIN Mechanisme: Net als in SQL biedt SPL EXPLAIN een uitvoeringsplan dat toont hoe tokens worden verdeeld, de geschatte kosten, cache-status en compressie-ratio's, voordat de query daadwerkelijk wordt uitgevoerd.

Architectuur:
De SPL-engine volgt een klassieke compiler-pijplijn:

Lexer & Parser: Een handgeschreven, recursieve parser (geen externe afhankelijkheden) die de SPL-code omzet in een Abstract Syntax Tree (AST).
Semantic Analyzer: Valideert namen, budgetberekeningen en typegebruik.
Optimizer: Genereert een uitvoeringsplan met token-toewijzingen en een kostenmodel.
Executor: Voert het plan uit via adapterinterfaces voor LLM's (Ollama, OpenRouter, Anthropic, etc.), RAG (FAISS/ChromaDB) en persistentie (SQLite).

3. Belangrijkste Bijdragen

Het paper introduceert vijf uitbreidingen die SPL van een prototype naar een volledig platform tillen:

Text2SPL: Een multilinguale interface die natuurlijke taal (NL) vertaalt naar geldige SPL-scripts via een LLM, met automatische validatie en retry-mechanismen.
Mixture-of-Models (MoM) Routing: Een runtime-strategie die elke PROMPT-clausule automatisch doorstuurt naar een gespecialiseerd model (bijv. Qwen voor CJK-talen, DeepSeek voor code, Claude voor redenering) op basis van sleutelwoorden in de query.
Logische Chunking (Declaratieve Map-Reduce): Een strategie voor documenten die groter zijn dan het contextvenster. Door gebruik te maken van CTE's, wordt een groot document opgesplitst in chunks die parallel worden verwerkt (Map) en vervolgens samengevoegd (Reduce). Dit verlaagt de aandachtskosten van $O(N^2)$ naar $O(N^2/k)$ , waarbij $k$ het aantal chunks is.
SPL-flow: Een veerkrachtige agentische orkestratielaag met een drie-traps fallback-strategie:
- Primair: Ollama (lokaal, gratis, privé).
- Fallback: OpenRouter/Cloud (bij fouten).
- Self-healing: Exponentiële backoff en retry.
  Dit werkt volledig transparant voor de .spl script.
BENCHMARK: Een syntaxis voor parallelle vergelijking van meerdere modellen op dezelfde query, met automatische selectie van de "winnaar" op basis van kosten, latentie of kwaliteit, en persistente opslag van de beste configuratie.

4. Resultaten en Evaluatie

De auteurs evalueren SPL via vijf experimenten zonder daadwerkelijke LLM-API-calls (alleen parser/optimizer):

Ontwikkelaarservaring: SPL reduceert het aantal regels code (LoC) met gemiddeld 65% vergeleken met imperatieve Python-implementaties. Het elimineert alle handmatige token-teloperaties.
Budget-Optimalisatie: De optimizer toont een "graceful degradation" bij budgetoverschrijding. Bij een vraag die 4x het budget is, worden alle bronnen proportioneel ingekort, waarbij kleine, vaste elementen (zoals systeemrollen) intact blijven.
Kostenzichtbaarheid: EXPLAIN toont een kostenverschil van 68x tussen dure modellen (bijv. GPT-4) en goedkope modellen (bijv. Claude Haiku) voor dezelfde query, zichtbaar vóór uitvoering.
Logische Chunking: Een experiment met een lang document toonde aan dat het splitsen in 4 chunks de wall-time verlaagde met een factor 4 (bij parallelle uitvoering) en de totale aandachtskosten aanzienlijk verlaagde.
Compatibiliteit: De engine werkt identiek op lokale hardware (Ollama, gratis) en in de cloud (OpenRouter), zonder wijziging in de script-code.

5. Betekenis en Implicaties

SPL biedt een fundamentele verschuiving in hoe we LLM-applicaties bouwen:

Van Imperatief naar Declaratief: Het verplaatst de complexiteit van prompt-engineering (hoe te bouwen) naar query-engineering (wat nodig is). Ontwikkelaars declareren het budget en de bronnen; de optimizer regelt de uitvoering.
Schalingsparadigma: Door "Logische Chunking" en "Mixture-of-Models" te combineren, suggereert het paper dat we niet hoeven te wachten op modellen met oneindige contextvensters. In plaats daarvan kunnen we complexe taken declaratief opsplitsen en distribueren over kleinere, gespecialiseerde modellen, wat leidt tot lagere kosten en minder rekenkracht.
Toegankelijkheid: Voor de miljoenen data-engineers en analisten die al SQL beheersen, biedt SPL een natuurlijke overgang naar GenAI. Het concept van "SELECT over tabellen" wordt "SELECT over contextbronnen".
Veiligheid en Transparantie: De declaratieve structuur en de EXPLAIN-functionaliteit bieden een nieuw niveau van auditbaarheid en controle over token-gebruik en kosten, wat essentieel is voor enterprise-adoptie.

Conclusie:
SPL transformeert prompt engineering van een ad-hoc, handmatige discipline naar een gestructureerde, optimaliseerbare wetenschap. Door token-budgetten als een beperkte hulpbron te behandelen en SQL-achtige principes toe te passen, biedt SPL een schaalbaar, kostenefficiënt en provider-onafhankelijk framework voor de volgende generatie LLM-toepassingen. De broncode is beschikbaar als open-source pakketten (spl-llm, spl-flow).