Technisches Resümee: Reduzierung des Token-Verbrauchs von State-in-Context-Agenten mittels Minifizierung

Problemstellung

Large Language Models (LLMs) werden zunehmend als Reasoning-Engines für Software-Engineering (SE)-Agenten eingesetzt, insbesondere für Repository-Ebene-Aufgaben, wie sie im SWE-bench-Benchmark vorkommen. In diesen Workflows müssen Agenten große Codebasen abrufen und darüber schlussfolgern, was zu einer rasant wachsenden Kontextgröße und einem hohen Token-Verbrauch führt. Da der Token-Verbrauch direkt mit den Betriebskosten korreliert und zu Leistungsdegradierungen aufgrund von Kontextbeschränkungen führen kann, ist eine effektive Reduzierung der Kontextgröße bei gleichzeitiger Beibehaltung relevanter Informationen entscheidend.

Jüngste Arbeiten von Jiang et al. führten „State-in-Context“-Agenten ein, die die Architektur vereinfachen, indem sie eine komprimierte Version des gesamten Umgebungszustands in einen einzigen Prompt einspeisen, anstatt den Zustand inkrementell über Tool-Aufrufe zu rekonstruieren. Eine Analyse dieser Agenten zeigt jedoch, dass der Großteil des Token-Verbrauchs während des Reparatur-Schritts auftritt, in dem der Quellcode den Prompt dominiert. Konkret werden über 90 % der Tokens im Reparatur-Prompt durch Quellcode verbraucht, während natürliche Sprachinstruktionen und das Ranking von Dateien weniger als 10 % ausmachen. Dieses Paper adressiert die Herausforderung, diesen Token-Verbrauch zu reduzieren, ohne prohibitive Performance-Verluste zu erleiden.

Methodik

Replikation und Baseline

Die Autoren führten zunächst eine unabhängige Replikation und Erweiterung des DirectSolve State-in-Context-Agenten durch. Da kein öffentliches Artefakt verfügbar war, implementierten sie eine Clean-Room-Version basierend auf den ursprünglichen Spezifikationen. Der Workflow umfasst drei Schritte:

1. Ranking: Ein LLM rankt Repository-Dateien basierend auf ihrer Relevanz zu einer Problembeschreibung unter Verwendung von nur Dateipfaden.
2. Aggregation: Die am höchsten gerankten Dateien werden zu einem Kontext aggregiert, bis ein vordefiniertes Token-Budget erreicht ist (in dieser Studie auf 100.000 Tokens begrenzt, um einen fairen Vergleich zwischen Modellen zu gewährleisten).
3. Reparatur: Ein LLM generiert ein Patch im SEARCH/REPLACE-Format basierend auf dem aggregierten Kontext.

Die Autoren evaluierten diese Baseline auf dem SWE-bench Verified Benchmark mit GPT-5-mini und erreichten eine Pass@1-Rate von 50,0 %, was konsistent mit dem ursprünglichen Bericht von 50,8 % unter Verwendung von Gemini-2.5-Pro ist.

Minifizierungsstrategie

Um den Token-Verbrauch zu senken, wandten die Autoren eine Reihe von Code-Minifizierungstechniken auf die Quelldateien an, bevor diese dem LLM für die Reparatur übergeben wurden. Diese Transformationen sind darauf ausgelegt, nicht essenzielle lexikalische Elemente zu entfernen oder zu verkürzen, während die Programmsemantik erhalten bleibt. Die spezifischen Techniken umfassen:

• Entfernung von Whitespace bei Zeilen/Operatoren: Eliminierung von Leerzeilen und Entfernung von Whitespace um Operatoren (z. B. wird a + b zu a+b).
• Entfernung von Kommentaren/Docstrings: Strippen von Kommentaren und Docstrings, die zur Laufzeit ignoriert werden.
• Dedentation: Reduzierung der Einrückungsebenen (z. B. von 4 Leerzeichen auf 2), während die Konsistenz innerhalb von Blöcken gewahrt bleibt. Um zu verhindern, dass das LLM aufgrund von Einrückungs-Mismatch ungültige Patches generiert, weist das System das Modell an, SEARCH/REPLACE-Blöcke mit einem festen 4-Leerzeichen-Einrückungsstil auszugeben, unabhängig vom Eingabeformat.
• Identifier-Verkürzung: Ersetzen von Variablen-, Funktions- und Klassennamen durch kürzere Aliase. Dies wurde in zwei Modi getestet:
  • Nicht-semantik-erhaltend: Direkter Ersatz ohne Kontext.
  • Semantik-erhaltend: Umbenennung von Identifikatoren und Voranstellen einer Mapping-Tabelle an den Prompt, damit das LLM die ursprünglichen Namen rekonstruieren kann.
• Import-Manipulation: Zusammenführen aller Imports in eine einzige synthetische Datei oder deren vollständiges Entfernen.

Diese Transformationen wurden in die Reparatur-Pipeline integriert. Nach der Patch-Generierung wurden die Identifier-Mappings rückgängig gemacht, und ein Verfahren, das gegenüber Whitespace- und Kommentar-Unterschieden tolerant ist, wurde verwendet, um die Patches auf das ursprüngliche Repository anzuwenden.

Zentrale Beiträge

1. Unabhängige Replikation: Eine Clean-Room-Reimplementierung des DirectSolve State-in-Context-Agenten, die zeigt, dass ein Single-Call, Tool-freier Agent mit einem leistungsfähigen Modell (GPT-5-mini) eine kompetitive Performance (50 % Pass@1) auf SWE-bench Verified erreichen kann.
2. Token-Allokations-Analyse: Eine empirische Analyse, die zeigt, dass der Quellcode im Reparatur-Prompt der dominante Faktor im Token-Verbrauch ist und natürliche Sprachinstruktionen sowie Ranking-Prompts übertrifft.
3. Minifizierungs-Framework: Der Vorschlag und die Integration eines Satzes leichtgewichtiger, semantik-erhaltender Code-Minifizierungstransformationen, die speziell auf Python-Quellcode innerhalb des State-in-Context-Reparatur-Workflows zugeschnitten sind.
4. Empirische Evaluierung: Eine systematische Evaluierung auf SWE-bench Verified, die zeigt, dass Minifizierung den durchschnittlichen Input-Token-Verbrauch um etwa 42 % reduziert, bei einem Rückgang der Lösungsrate um 12 Prozentpunkte (von 50,0 % auf 38,0 %).
5. Ablation und Fehleranalyse: Detaillierte Studien, die einzelne Transformationen und gestapelte Kombinationen isolieren und deren spezifische Trade-offs quantifizieren. Die Autoren stellten fest, dass während die meisten Transformationen moderate Performance-Verluste verursachen, die „Dedent“-Transformation zu einem signifikanten Abfall der Lösungsrate führt, bedingt durch die Generierung syntaktisch ungültiger Patches (Einrückungsfehler).

Ergebnisse

• Effizienz vs. Effektivität: Die primäre Erkenntnis ist ein klarer Trade-off. Minifizierung reduziert die durchschnittlichen Input-Tokens von ~90.535 auf ~52.776 (eine Reduktion um 42 %). Dies führt zu einer absoluten Verringerung der Lösungsrate um 12 %.
• Kostenauswirkungen: Da Input-Tokens etwa 93 % der Kosten der Reparaturphase ausmachen, übersetzt sich die Reduzierung der Tokens direkt in signifikante Kosteneinsparungen.
• Spezifika der Transformationen:
  • Das Entfernen von Docstrings und Kommentaren lieferte die größten Token-Reduktionen bei relativ geringen Performance-Einbußen (Lösungsraten blieben über 40 %).
  • Die „Dedent“-Transformation war der primäre Ausreißer und verursachte einen Abfall der Lösungsrate auf 27–36 %, abhängig vom Modell und der Stapelkonfiguration. Die Fehleranalyse deutete darauf hin, dass dies darauf zurückzuführen war, dass das LLM die erforderte 4-Leerzeichen-Einrückung in der Ausgabe nicht wiederherstellte, was zu IndentationError im generierten Code führte.
  • Das Stapeln mehrerer Transformationen (ohsne Dedent) reduzierte konsistent die Kosten bei gleichzeitiger Beibehaltung einer Performance nahe der Baseline.
• Generalisierbarkeit: Die Trends erwiesen sich als stabil über verschiedene Repositories und Schwierigkeitsgrade der Issues hinweg, was darauf hindeutet, dass der Ansatz gut über verschiedene Bedingungen hinweg generalisiert.

Bedeutung

Das Paper behauptet, dass leichtgewichtige Quellcode-Transformationen einen vielversprechenden Weg zu kosteneffizienteren Software-Engineering-Agenten bieten. Durch den Nachweis, dass ein erheblicher Teil der Baseline-Performance beibehalten werden kann, während fast 50 % der Tokens eingespart werden, legt die Arbeit nahe, dass aggressive Kontextkompression für Aufgaben auf Repository-Ebene praktikabel ist. Die Autoren betonen, dass ihre Ergebnisse einen expliziten Trade-off zwischen Effizienz und Effektivität aufzeigen und eine datengestützte Basis für die Auswahl von Transformationsstrategien basierend auf spezifischen Kosten- und Leistungsanforderungen bieten. Die vollständige Implementierung wird zur Unterstützung weiterer Forschung in diesem Bereich öffentlich zugänglich gemacht.