Die meisten Nutzer verlängern ihre Prompts, wenn die Antwort nicht passt. Noch ein Beispiel, noch eine Regel, noch ein Absatz Kontext. Das klingt erstmal vernünftig. Nur wird die KI dabei nicht zuverlässig besser, sondern teurer, langsamer und manchmal sogar schlechter. Prompt Kompression dreht den Reflex um. Sie wirft aus einem Prompt raus, was ohnehin niemand braucht, und behält das, worauf es ankommt.
Das ist kein Nischenthema für API-Nerds. Wer mit RAG arbeitet, lange Dokumente hochlädt oder einen Agenten laufen lässt, der sich seine halbe Chathistorie merkt, schleppt in jedem Aufruf tausende Token mit, die keinen Beitrag leisten. Genau da setzt die Technik an.
Inhaltsverzeichnis
Was Prompt Kompression im Kern ist
Sprache ist redundant. Füllwörter, höfliche Floskeln, dreimal dasselbe in anderen Worten. Ein Mensch überliest das, ein Sprachmodell zahlt dafür. Denn ein Modell rechnet nicht in Wörtern, sondern in Token, und jedes Token kostet Rechenzeit und Geld. Die Idee dahinter ist schlicht. Man schrumpft den Prompt, bevor er beim teuren Modell ankommt, ohne dass die Bedeutung verloren geht.
Prompt Kompression verkleinert einen Prompt vor dem Absenden an die KI, indem sie überflüssige Token entfernt oder den Inhalt verdichtet. Die semantische Aussage bleibt erhalten, die Antwortqualität möglichst auch. Ziel sind niedrigere Kosten, kürzere Wartezeiten und weniger Ballast im Kontextfenster.
Fachleute unterscheiden zwei Wege. Der eine kürzt sichtbaren Text, streicht also einzelne Wörter oder ganze Sätze heraus oder formuliert sie knapper. Das Ergebnis bleibt lesbar und funktioniert mit jeder KI, auch mit Claude, ChatGPT oder Gemini, weil am Ende ganz normaler Text herauskommt. Der andere Weg verpackt den Prompt in dichte Zahlenvektoren, die direkt in die inneren Schichten des Modells gehen. Damit sind extreme Kompressionsraten möglich, aber es geht nur bei offenen Modellen, deren Innenleben man anfassen kann. Für den Alltag zählt fast immer der erste Weg.
Wie funktioniert Prompt Kompression technisch?
Die bekannteste Werkzeugfamilie kommt aus der Forschungsabteilung von Microsoft und heißt LLMLingua. Das Prinzip ist fast schon frech einfach. Ein kleines, billiges Sprachmodell liest den Prompt und schätzt für jedes Wort, wie überraschend es an dieser Stelle ist. Ein Artikel wie »der« vor einem Substantiv ist hochgradig vorhersehbar und trägt kaum Information. Solche Wörter fliegen zuerst. Ein Eigenname, eine Zahl, ein Fachbegriff dagegen ist überraschend und bleibt.
Das ursprüngliche LLMLingua erreicht damit laut Microsoft Research bis zu 20-fache Kompression bei geringem Qualitätsverlust. Der Nachfolger LongLLMLingua wurde für lange Kontexte gebaut und meldet, gemessen auf gängigen Frage-Antwort-Benchmarks, sogar eine Leistungssteigerung von 17,1 Prozent bei vierfacher Kompression. Das ist der Punkt, an dem viele stutzen. Weniger Input, bessere Antwort? Dazu gleich mehr.
Die perplexitätsbasierte Methode hat einen Haken. Sie liest von links nach rechts und arbeitet Token für Token, das dauert. Die zweite Generation, LLMLingua-2, formuliert die Aufgabe deshalb um. Statt Überraschung zu messen, entscheidet ein kleines Klassifikationsmodell für jedes Wort schlicht behalten oder verwerfen. Trainiert wurde es, indem GPT-4 massenhaft Texte vorkomprimiert hat und das kleine Modell aus diesen Beispielen gelernt hat. Das Ergebnis läuft laut Microsoft drei- bis sechsmal schneller als das Original und verkraftet fremde Themengebiete besser.
Daneben gibt es Verfahren, die nicht an einzelnen Wörtern herumschneiden, sondern an ganzen Sätzen oder Absätzen. Das hat einen angenehmen Nebeneffekt. Der komprimierte Prompt bleibt grammatisch sauber und für Menschen lesbar, weil keine zerhackten Wortfragmente übrig bleiben. Wer den Prompt hinterher noch prüfen muss, etwa aus Compliance-Gründen, fährt damit besser.
| Verfahren | Ebene | Stärke | Typische Rate |
|---|---|---|---|
| LLMLingua | einzelne Token | präzise Budgetierung | 2x bis 20x |
| LLMLingua-2 | Token, Klassifikation | sehr schnell | 2x bis 5x |
| LongLLMLingua | Token und Dokument | gegen Lost in the Middle | 4x bis 10x |
| Satzbasiert | ganze Sätze | bleibt lesbar | 2x bis 5x |
Warum weniger Kontext bessere Antworten liefern kann
Es klingt widersinnig, ist aber gut belegt. Sprachmodelle lesen lange Prompts nicht gleichmäßig. Sie achten stark auf den Anfang und das Ende und verlieren die Mitte aus dem Blick. Dieser Effekt heißt Lost in the Middle. Steht die entscheidende Information mittendrin, sinkt die Trefferquote merklich. Wer den Kontext von Rauschen befreit, schützt die wichtigen Fakten davor, in dieser toten Zone zu versinken.
Man kennt das Phänomen aus der Praxis. Lädt man ein 200-seitiges PDF hoch und fragt nach einem Detail auf Seite 90, kommt öfter Unsinn heraus, als einem lieb ist. Nicht weil das Modell zu dumm wäre, sondern weil die relevante Stelle im Lärm untergeht. Kompression ist hier weniger Sparmaßnahme als Qualitätswerkzeug. Sie räumt auf, damit das Modell sieht, worauf es ankommt. Wer tiefer wissen will, warum lange Eingaben nicht automatisch bessere Ergebnisse bringen, findet das im Artikel über lange Prompts ausführlicher.
Was Prompt Kompression konkret spart
Kommen wir zum Geld, denn hier wird es greifbar. Wer eine KI über die API nutzt, zahlt streng pro Token. Jedes Token weniger im Input ist bare Münze. Ein Kontext, der von 10.000 auf 2.000 Token schrumpft, kostet im Input nur noch ein Fünftel. Rechnet ein Unternehmen monatlich mit Milliarden Token über ein Spitzenmodell, bewegen sich die Rechnungen im sechsstelligen Bereich, und dieselbe fünffache Kompression drückt den Eingabeanteil ebenso. Aus 100 Prozent Kosten werden 20 bis 25 Prozent, das ist die 75- bis 80-Prozent-Marke, die diesem Artikel den Titel gibt. Vorausgesetzt, der Input macht den Großteil der Rechnung aus, was bei langen Dokumenten und RAG die Regel ist.
Für Einzelnutzer mit Abo klingt das erst mal fern. Aber das Prinzip greift auch dort, nur in kleinerem Maßstab. Wer seinen eigenen Kontext schlank hält, kommt mit seinem Nachrichtenlimit weiter. Die handfesten Tricks dafür stehen im Artikel über teure Token sparen. Prompt Kompression ist gewissermaßen die automatisierte, industrielle Variante desselben Gedankens.
Der zweite Gewinn ist Zeit. Ein kürzerer Prompt bedeutet eine kürzere Vorlaufphase, in der das Modell den Input verarbeitet, bevor das erste Wort der Antwort erscheint. Bei langen Eingaben ab etwa 5.000 Token macht sich das spürbar bemerkbar, selbst wenn das Komprimieren selbst kurz Rechenzeit kostet. Dazu kommt ein Effekt, den vor allem Betreiber schätzen. Wer die Prompts kürzt, braucht weniger Grafikspeicher fürs Modell und kann Aufgaben womöglich auf günstigerer Hardware laufen lassen.
| ohne Kompression | mit 4x bis 5x | |
|---|---|---|
| Input-Kosten | 100 Prozent | 20 bis 25 Prozent |
| Grafikspeicher | skaliert mit Länge | bis zu 75 Prozent weniger |
| Fakten in der Mitte | Trefferquote sackt ab | stabiler, teils besser |
| Wartezeit bei langem Input | hoch | spürbar kürzer |
Wo Leute das tatsächlich einsetzen
Der häufigste Fall sind Suchsysteme, die Antworten aus einer Dokumentensammlung ziehen, also RAG. Die Suche liefert oft mehr Textschnipsel zurück als nötig, viele davon halb passend. Komprimiert man diese Schnipsel, bevor sie ans große Modell gehen, passen mehr Quellen gleichzeitig ins Kontextfenster, ohne es zu sprengen. LLMLingua ist genau deshalb in die verbreiteten Baukästen LangChain und LlamaIndex eingebaut.
Ein zweites Feld sind Meeting-Protokolle. Ein einstündiges Gespräch ergibt ein monströs langes, unstrukturiertes Transkript. Bevor eine KI daraus Beschlüsse und Aufgaben zieht, wird es verdichtet. Das spart nicht nur Kosten, sondern hält die Antwortzeit im Rahmen.
Am interessantesten wird es bei autonomen KI-Agenten. Die arbeiten in Schleifen, und bei jedem Durchlauf hängt sich der Agent seinen letzten Schritt, jeden Werkzeugaufruf und jede Fehlermeldung an den Prompt. Die Historie wächst und wächst. Ohne Gegenmaßnahme läuft so ein Agent irgendwann gegen die Wand seines Kontextfensters. Die übliche Lösung ist eine Mischung. Ein kleineres Modell fasst die älteren Schritte regelmäßig zusammen, während die letzten paar Schritte im Originalwortlaut erhalten bleiben.
Prompt Kompression in Python aufrufen
Für alle, die es selbst ausprobieren wollen, hier das Grundgerüst. Man lädt das schnelle LLMLingua-2-Modell, wirft einen Text hinein und gibt an, auf welchen Bruchteil komprimiert werden soll. Über eine Liste geschützter Ausdrücke stellt man sicher, dass wichtige Namen oder Zahlen unangetastet bleiben.
from llmlingua import PromptCompressor
compressor = PromptCompressor(
model_name="microsoft/llmlingua-2-xlm-roberta-large-meetingbank",
use_llmlingua2=True
)
original_prompt = """
Sehr geehrte Damen und Herren, wir moechten Sie hiermit darueber informieren,
dass der Kunde Max Mustermann am 24. Mai 2026 eine Support-Anfrage bezueglich
seiner instabilen Internetverbindung gestellt hat. Die Verbindung bricht seit
nunmehr drei Tagen kontinuierlich ab.
"""
result = compressor.compress_prompt(
original_prompt,
rate=0.33,
force_tokens=["Max Mustermann", "24. Mai 2026"]
)
print(result["compressed_prompt"])
print(result["origin_tokens"], "->", result["compressed_tokens"])
In eine RAG-Pipeline hängt man das nicht als separaten Schritt ein, sondern als Zwischenschicht, die die Suchergebnisse abfängt und verdichtet, bevor sie ans Antwortmodell gehen. In LlamaIndex heißt dieser Baustein LongLLMLinguaPostprocessor, in LangChain der ContextualCompressionRetriever. Beide sind wenige Zeilen Konfiguration, die Dokumentation der jeweiligen Frameworks führt durch den Rest.
Die Fehler, die man leicht macht
Prompt Kompression ist kein Schalter, den man umlegt und vergisst. Drei Fallen tauchen immer wieder auf, und alle drei kosten am Ende mehr, als sie sparen.
- Alles über einen Kamm scheren. Fließtext verträgt starke Kürzung. Code, Formeln, JSON oder verschachtelte Tabellen nicht. Schon kleine Eingriffe können dort die Syntax zerlegen und die ganze Verarbeitung kippen. Kritische Abschnitte müssen von der Kompression ausgenommen werden, Zahlen und Eigennamen grundsätzlich geschützt.
- Am Cache vorbeiarbeiten. Die großen Anbieter speichern identische Prompt-Anfänge zwischen und geben Rabatt, wenn dieselbe Passage erneut kommt, das sogenannte Prompt Caching. Wer seinen statischen System-Prompt bei jeder Anfrage frisch komprimiert, erzeugt jedes Mal ein leicht anderes Ergebnis und entwertet damit den Cache. Dann zahlt man doppelt, für die Kompression und für den verlorenen Rabatt. Komprimiert wird nur der variable Teil, nie der feste Rahmen.
- Nicht nachmessen. Kompression glättet feine Nuancen. Das Modell antwortet dann womöglich glatt und selbstsicher, unterschlägt aber ein geschäftskritisches Detail. Solche stillen Fehler merkt man erst, wenn man gezielt danach sucht. Vor dem Ernstfall gehört ein Testdatensatz her, auf dem man verschiedene Kompressionsraten durchprobiert und schaut, wo die Genauigkeit zu bröckeln beginnt.
Die dritte Falle ist die tückischste, weil sie unsichtbar bleibt. Eine falsche Antwort erkennt man. Eine richtige Antwort, der ein entscheidender Satz fehlt, sieht aus wie eine gute Antwort. Deshalb der nüchterne Rat, den man bei jeder Optimierung an KI-Systemen geben kann. Komprimieren ja, aber nur so weit, wie eine Messung es deckt.
Vom akademischen Randthema hat sich Prompt Kompression zu einem festen Baustein im Umgang mit langen Kontexten entwickelt. Für den einzelnen Nutzer bleibt sie meist unsichtbar, sie steckt in den Werkzeugen, nicht im Chatfenster. Wer aber selbst Anwendungen baut, kommt an ihr kaum vorbei. Nicht als Kür, sondern weil sich große KI-Anwendungen sonst schlicht nicht wirtschaftlich betreiben lassen. (lk)
Quellen
- Microsoft Research, LLMLingua Series (Kompressionsraten, Geschwindigkeit, Framework-Integration)
- Pan et al., LLMLingua-2, Data Distillation for Task-Agnostic Prompt Compression
- microsoft/LLMLingua auf GitHub (Code, Beispiele, RAG-Integration)
