💬 NLP

Structured Prompt Language: Declarative Context Management for LLMs

Die Arbeit stellt SPL (Structured Prompt Language) vor, eine deklariative, SQL-inspirierte Sprache, die Large Language Models als generative Wissensbanken behandelt und durch integrierte Token-Budgetierung, automatische Optimierung sowie resiliente Agente-Pipelines die Effizienz, Kostentransparenz und Skalierbarkeit von LLM-Anwendungen signifikant verbessert.

Ursprüngliche Autoren: Wen G. Gong

Veröffentlicht 2026-02-26

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Wen G. Gong

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stell dir vor, du bist ein Chef-Koch in einer sehr teuren Küche. Deine Aufgabe ist es, ein Meisterwerk zu kochen (die Antwort einer KI), aber du hast nur eine sehr kleine Schüssel (den "Kontext-Fenster" der KI), um alle Zutaten hineinzuwerfen.

Das Problem bisher: Jeder Koch musste selbst zählen, wie viele Gramm Mehl, wie viele Eier und wie viel Wasser in die Schüssel passen. Wenn es zu viel wurde, musste er wild herumtrödeln, Zutaten wegwerfen oder hoffen, dass es passt. Das war chaotisch, teuer und ineffizient.

SPL (Structured Prompt Language) ist wie eine neue, intelligente Rezept-Sprache, die diesem Chaos ein Ende setzt. Hier ist die Erklärung, wie das funktioniert, ganz einfach und mit ein paar bildhaften Vergleichen:

1. Das Grundprinzip: Vom "Basteln" zum "Planen"

Früher haben Programmierer wie Handwerker gearbeitet: Sie haben Textbausteine aneinandergeklebt und gehofft, dass die KI nicht "verwirrt" wird, weil zu viel Text reinkam.

SPL ist wie ein Bauplan für Architekten.

Du sagst nicht: "Nimm diesen Text, schneide ihn zu, füge jenen hinzu..."
Du sagst: "Ich habe ein Budget von 8.000 'Token' (das ist die Währung für Textlänge). Ich will diese Zutaten (Fragen, Dokumente, Erinnerungen) verwenden. Die KI soll daraus ein Gericht kochen."
Der SPL-Optimierer (ein unsichtbarer Assistent) kümmert sich dann darum, dass alles in die Schüssel passt. Wenn es zu viel ist, schneidet er automatisch die größten Zutaten (z. B. lange Dokumente) etwas kleiner zu, ohne die wichtigen Gewürze (deine Frage) zu verlieren.

2. Die drei magischen Werkzeuge

A. Das "Budget" (Wie viel darf es kosten?)

Stell dir vor, du gehst einkaufen. Früher hast du einfach alles in den Korb geworfen und erst an der Kasse gemerkt, dass du pleite bist.
Mit SPL sagst du vorab: "Ich habe 50 Euro."

SPL berechnet vorher genau: "Okay, für die Milch brauchst du 2 Euro, für das Steak 30 Euro, für den Salat 5 Euro. Das passt!"
Es zeigt dir sogar eine Rechnung vor dem Einkauf (das nennt man EXPLAIN), damit du weißt, ob du dir das Steak leisten kannst oder ob du lieber Hähnchen nimmst.

B. Die "Zutaten-Mischung" (RAG und Gedächtnis)

Eine KI hat zwei Arten von Wissen:

Das auswendig Gelernte: Das, was sie beim Training gelernt hat (wie ein Koch, der Rezepte auswendig kann).
Das aktuelle Wissen: Das, was du ihr heute gibst (wie frische Zutaten, die du mitbringst).

SPL erlaubt dir, beides sauber zu mischen. Du kannst sagen: "Nimm meine alte Einkaufsliste aus dem Kühlschrank (Gedächtnis), suche im Internet nach neuen Rezepten (RAG) und kombiniere das mit deinem Wissen." Alles in einem Satz, ohne dass du manuell kopieren und einfügen musst.

C. Der "Schwarm-Intelligenz"-Effekt (MoM Routing)

Stell dir vor, du willst ein komplexes Gericht kochen, das eine französische Sauce, japanische Sushi und deutsche Wurst erfordert.

Früher: Du hast einen einzigen Koch (ein KI-Modell) genommen und gehofft, dass er in allen drei Küchen gut ist. Das war oft mittelmäßig.
Mit SPL: Du hast einen Küchenchef, der automatisch die richtigen Spezialisten ruft.
- Für die japanische Wurst schickt er den Befehl an einen japanischen Spezial-Koch.
- Für die deutsche Wurst an einen deutschen Spezialisten.
- Am Ende bringt er alles zu dir.
- Das passiert automatisch im Hintergrund. Du musst nicht wissen, welcher Koch der beste ist; SPL entscheidet das für dich.

3. Der "Notfall-Plan" (SPL-flow)

Was passiert, wenn der Lieferant ausfällt?

Früher: Deine Küche steht still.
Mit SPL: Es gibt einen Notfall-Plan. Wenn dein lokaler Lieferant (z. B. ein Computer zu Hause) nicht liefert, schaltet SPL automatisch auf den großen Supermarkt (Cloud) um. Wenn der Supermarkt voll ist, versucht es es später noch einmal. Du als Koch merkst davon nichts; dein Gericht wird trotzdem geliefert.

4. Warum ist das so revolutionär? (Die Analogie zur Datenbank)

Vor 50 Jahren haben Leute Datenbanken programmiert, indem sie komplexe Maschinensteuerungen schrieben. Dann kam SQL (die Sprache für Datenbanken). SQL sagte: "Sag mir, was du willst, nicht wie du es holst."

SPL macht genau das für KI:

Es verwandelt das "Prompt-Engineering" (das mühsame Basteln von Texten) in Query-Engineering (das Planen von Abfragen).
Es macht die KI-Anwendung billiger (weil sie genau weiß, wie viel Text sie braucht).
Es macht sie schneller (weil sie die besten Modelle für die jeweilige Aufgabe wählt).
Es macht sie sicherer (weil man den Plan vorher sehen kann, bevor die KI etwas tut).

Zusammenfassung in einem Satz

SPL ist wie ein intelligenter Butler für deine KI: Er zählt das Geld, packt die Koffer, ruft die richtigen Experten und sorgt dafür, dass alles pünktlich und günstig ankommt, damit du dich nur auf das Ergebnis konzentrieren musst, nicht auf die Logistik.

Es ist der Schritt von "Hoffen und Beten" hin zu "Planen und Optimieren" – genau wie der Übergang von der Handarbeit zur modernen Fabrik.

1. Problemstellung

Die Arbeit adressiert die wachsende Komplexität des Prompt-Engineerings für Large Language Models (LLMs). Ähnlich wie Datenbanken vor der Erfindung von SQL (Structured Query Language) mussten Entwickler bisher imperativen Code schreiben, um Kontextfenster zu verwalten. Dies führt zu mehreren kritischen Problemen:

Manuelle Token-Berechnung: Entwickler müssen mühsam prüfen, ob Prompts in die Kontextfenster passen, oft durch Trial-and-Error.
Fehlende Transparenz: Es gibt keine standardisierte Möglichkeit zu sehen, wie Token-Ressourcen innerhalb eines Prompts verteilt sind.
Ad-hoc-Truncierung: Wenn Kontextlimits überschritten werden, werden oft grobe Abschneidestrategien angewendet, ohne systematische Optimierung.
Vendor Lock-in: Prompt-Code ist häufig an spezifische LLM-APIs gebunden, was Migrationen erschwert.
Mangelnde Komposition: Prompts sind oft monolithisch und schwer modular wiederverwendbar.

Das zentrale Problem ist die Behandlung des Kontextfensters als eine begrenzte Ressource, die effizient über konkurrierende Anforderungen (System-Rolle, RAG-Ergebnisse, Chat-Historie, Benutzerinput) verteilt werden muss.

2. Methodik: Structured Prompt Language (SPL)

Die Autoren stellen SPL (Structured Prompt Language) vor, eine deklariative, SQL-inspirierte Abfragesprache, die LLMs als generative Wissensdatenbanken behandelt.

Kernkonzepte:

Deklarativer Ansatz: Entwickler geben was sie benötigen an (Kontext und Ausgabe), nicht wie es abgerufen wird. Ein automatischer Optimierer übernimmt die Token-Allokation.
Trennung von Retrieval und Synthese:
- SELECT: Sammelt Kontext aus heterogenen Quellen (System-Rolle, externe Daten, RAG, Speicher) unter Einhaltung von Token-Limits.
- GENERATE: Triggert die Synthese der Antwort basierend auf dem gesammelten Kontext.
Token-Budget als First-Class-Concept: Jede Abfrage muss ein explizites WITH BUDGET definieren. Der Optimierer verteilt dieses Budget automatisch auf die Quellen.
EXPLAIN-Mechanismus: Ähnlich wie EXPLAIN ANALYZE in SQL generiert SPL einen Ausführungsplan, der die Token-Zuordnung, Cache-Status und geschätzte Kosten vor der eigentlichen Ausführung anzeigt.
Composability (CTEs): Durch Common Table Expressions (WITH ... AS) können komplexe Prompts aus wiederverwendbaren Bausteinen aufgebaut werden.

Technische Architektur:
SPL folgt einem klassischen Compiler-Pipeline-Design:

Lexer & Parser: Ein handgeschriebener, rekursiver Abstiegsparser (ohne externe Abhängigkeiten wie ANTLR) erzeugt einen AST (Abstract Syntax Tree).
Semantischer Analyzer: Validiert Namen, Budget-Arithmetik und Typen.
Optimizer: Berechnet die optimale Token-Zuweisung. Bei Budgetüberschreitung wird eine proportionale Kompression angewendet (größte Quellen werden zuerst komprimiert, um kleine, feste Einheiten wie System-Rollen zu schützen).
Executor: Führt den Plan aus, nutzt Adapter für verschiedene Anbieter (Ollama, OpenRouter, Claude, etc.) und integriert persistente Speicher (SQLite) und Vektor-Datenbanken (FAISS/ChromaDB).

3. Schlüsselbeiträge und Erweiterungen

Das Paper präsentiert nicht nur die Sprache, sondern ein gesamtes Ökosystem mit fünf wesentlichen Erweiterungen:

Text2SPL: Ein multilingualer Schnittstellen-Modul, das natürliche Sprache (NL) in gültige SPL-Skripte übersetzt. Dies senkt die Einstiegshürde für Nicht-Programmierer.
Mixture-of-Models (MoM) Routing: Ein dynamisches Routing-System (USING MODEL auto), das Teilaufgaben basierend auf dem Inhalt (z. B. Code, Mathematik, CJK-Sprachen) an spezialisierte Modelle zur Laufzeit verteilt.
Logisches Chunking (Declarative Map-Reduce): Eine Strategie für sehr lange Dokumente, die über ein Kontextfenster hinausgehen. Durch die Aufteilung in CTEs (Map-Phase) und eine finale Synthese (Reduce-Phase) wird die Aufmerksamkeitsskomplexität von $O(N^2)$ auf $O(N^2/k)$ reduziert. Dies ermöglicht die Verarbeitung großer Dokumente auf lokaler Hardware mit geringen Kosten.
SPL-flow: Eine resiliente Orchestrierungsschicht für Agenten-Pipelines. Sie bietet eine Three-Tier-Fallback-Strategie (Ollama → OpenRouter → Self-Healing-Retry), die transparent für das Skript funktioniert und Ausfälle abfängt.
BENCHMARK: Ein Syntax-Element (USING MODELS), das parallele Tests mehrerer Modelle ermöglicht. Das System wählt automatisch den „Gewinner" basierend auf Kosten, Latenz und Qualität und persistiert diese Wahl für zukünftige Ausführungen.

4. Ergebnisse und Evaluation

Die Autoren führen fünf Experimente durch, die zeigen, dass SPL bereits vor dem ersten LLM-Aufruf Wert schafft:

Entwicklererfahrung (Developer Experience): Im Vergleich zu imperativem Python-Code (mit manueller Token-Berechnung und Caching) reduziert SPL den Codeumfang (Lines of Code) im Durchschnitt um 65%. Zudem eliminiert es alle manuellen Token-Operationen.
Budget-Optimierung: Der Optimierer skaliert Ressourcen (z. B. RAG-Dokumente) proportional zum Budget, während feste Elemente konstant bleiben. Bei Überlastung wird eine „Graceful Degradation" durch Kompression erreicht.
Kosten-Transparenz: Das EXPLAIN-Feature zeigt eine 68-fache Kostenunterschied zwischen verschiedenen Modell-Tiers (z. B. GPT-4 vs. Claude Haiku) für dieselbe Abfrage an, bevor ein Token verbraucht wird.
Effizienz: Durch logisches Chunking und parallele Ausführung konnte die Wandzeit für die Verarbeitung langer Dokumente um den Faktor 4 reduziert werden, bei gleichzeitiger Senkung der Rechenkosten.
Funktionalität: Alle 20 getesteten Features (Parsing, Budgeting, RAG, Memory, CTEs, Provider-Adapter) funktionierten fehlerfrei.

5. Bedeutung und Ausblick

Die Arbeit stellt einen Paradigmenwechsel dar:

Von Imperativ zu Deklarativ: SPL wandelt Prompt-Engineering von einer ad-hoc, imperativen Praxis in eine strukturierte, optimierbare Disziplin um.
Ressourcen-Management: Sie etabliert das Token-Budget als primäre Optimierungsgröße, ähnlich wie I/O-Kosten in Datenbanken.
Architektonische Hypothese: Die Autoren argumentieren, dass deklariative Orchestrierung und die Aufteilung von Aufgaben auf spezialisierte, kleinere Modelle (MoM) eine effizientere Skalierungsstrategie sein können als das bloße Vergrößern der Kontextfenster monolithischer Modelle.
Zugänglichkeit: Durch die SQL-Ähnlichkeit bietet SPL Dateningenieuren und Analysten einen vertrauten Einstieg in die KI-Entwicklung.

Die Implementierung ist als Open-Source-Pakete (spl-llm, spl-flow) und VS Code-Erweiterung verfügbar und positioniert SPL als eine Plattform, die nicht nur Prompt-Templates verwaltet, sondern die gesamte Lebenszyklus-Orchestrierung von LLM-Anwendungen abstrahiert.