Technisches Resümee: SWE-Pruner Pro

Problemstellung

Coding-Agenten, die in Multi-Turn-Umgebungen operieren, akkumulieren im Verlauf ihrer Interaktion mit Codebasen umfangreiche Tool-Outputs (z. B. cat, grep, ls, Python-Ausführungsprotokolle). Diese Outputs enthalten oft erhebliche Redundanzen, die den Großteil des pro Trajektorie verfügbaren Token-Budgets verbrauchen und eine Degradation des Langkontextes auslösen. Bestehende Lösungen zur Kontext-Pruning fallen in zwei Kategorien:

1. Allgemeine Kompression: Methoden wie LLMLingua2 oder Selective Context bewerten Token basierend auf festen Metriken (z. B. Perplexität, syntaktische Struktur). Diese versagen dabei, sich an den sich entwickelnden Aufgabenfokus des Agenten anzupassen.
2. Aufgabenspezifisches Pruning: Vorherige Arbeiten wie SWE-Pruner bedingen das Pruning an die Intention des Agenten, erfordern jedoch ein externes Scoring-Modell und eine explizite „Goal-Hint“-Abfrage, die der Agent in jedem Turn generieren muss. Dies führt zu zusätzlichem Overhead und Latenz.

Beide Ansätze behandeln das Pruning-Signal als eine externe Größe, die rekonstruiert werden muss, und ignorieren dabei die Tatsache, dass das Backbone-Modell des Agenten den Tool-Output bereits verarbeitet und wahrscheinlich Relevanzinformationen innerhalb seiner internen Repräsentationen kodiert hat.

Methodik: SWE-Pruner Pro

SWE-Pruner Pro schlägt vor, das Pruning-Signal direkt aus den internen Hidden States des Agenten-Backbones zu lesen, wodurch externe Scoring-Modelle oder explizite „Goal-Hint“-Abfragen überflüssig werden. Die Methode operiert direkt innerhalb der Inferenzschleife des Agenten.

Kernmechanismus

1. Nutzung interner Repräsentationen: Wenn der Agent eine Tool-Antwort ($r_t$) liest, führt das eingefrorene Backbone ein Standard-Prefill durch und generiert die Last-Layer-Hidden-States ($h_i$) für jeden Token. SWE-Pruner Pro koppelt einen leichtgewichtigen Pruning-Head an diese bestehenden Zustände.
2. Architektur des Pruning-Heads:
   • Längenbewusstes Embedding: Ein gelerntes Embedding $e(N)$, das auf die Gesamtzahl der Zeilen $N$ der Antwort konditioniert ist, wird zu jedem Hidden State additiv hinzugefügt (Broadcast-Addition). Dies ermöglicht es dem Modell, seine Pruning-Strategie basierend auf der Antwortlänge anzupassen (z. B. konservativer bei kurzen Ausgaben, bei denen jede Zeile kritisch ist).
   • Nicht-linearer Klassifikator: Ein kleines Feed-Forward-Netzwerk (LayerNorm + zwei Linear-GELU-Dropout-Blöcke) bildet die augmentierten Hidden States auf ein Keep-or-Prune-Logit ab. Diese Nichtlinearität ist notwendig, um die Überlappung im Repräsentationsraum aufzulösen, die in linearen Probing-Experimenten beobachtet wurde.
   • Entscheidungsaggregation: Token-Level-Logits werden mittels Mehrheitsentscheidung innerhalb jeder Zeile aggregiert, um eine binäre Keep/Prune-Entscheidung für die gesamte Zeile zu treffen.
3. Trainingsstrategie:
   • Daten: Der Head wird auf 22.609 Multi-Turn-Trajektorien trainiert, die von Claude Sonnet 4.6 mit pro-Zeilen Keep/Prune-Labels annotiert wurden.
   • Loss-Funktion: Die Autoren verwenden einen pro-Sample balancierten Focal Loss. Im Gegensatz zum Standard-Focal-Loss, der global balanciert, berechnet dieser Ansatz den Loss separat für „Keep“- und „Prune“-Token innerhalb jedes Samples und mittelt sie mit gleichem Gewicht. Dies stellt sicher, dass Samples mit extremen Keep-Raten (z. B. nur 3 % der Zeilen behalten) gleichermaßen zum Zielwert beitragen, was ein Overfitting an die durchschnittliche Keep-Rate (~30 %) verhindert.
4. Inferenz-Integration: Der Head läuft „in-server“ während der Prefill-Phase. Er nutzt die für den Tool-Response generierten Hidden States wieder und fügt lediglich einen einzigen Forward-Pass des kleinen Heads hinzu. Die geprunte Antwort ($\tilde{r}_t$) ersetzt die Rohantwort im Kontext für den nächsten Turn, während die Generierung des aktuellen Turns weiterhin auf die vollständige Rohantwort zugreift.

Wichtige Beiträge

1. Signalentdeckung: Die Arbeit zeigt, dass die internen Repräsentationen eines Agent-Backbones bereits die Zeilen-Relevanz von Tool-Outputs kodieren. Ein einfacher linearer Probe erreicht einen AUC von 0,83, was beweist, dass das „Keep-or-Prune“-Signal ohne externe Rekonstruktion existiert.
2. Architektur: Einführung von SWE-Pruner Pro, einem leichtgewichtigen Head, der ein längenbewusstes Embedding und einen pro-Sample balancierten Focal Loss nutzt, um präzise Pruning-Entscheidungen direkt aus den eingefrorenen Zuständen des Backbones zu treffen.
3. Effizienz: Die Methode vermeidet zusätzliche Modellaufrufe und explizite „Goal-Hint“-Abfragen, was einen begrenzten Inferenz-Overhead verursacht, während gleichzeitig eine signifikante Reduktion der Tokens erreicht wird.

Experimentelle Ergebnisse

Die Methode wurde auf zwei Open-Weight-Backbones (MiMo-V2-Flash und Qwen3-Coder-Next) über vier Multi-Turn-Benchmarks evaluiert: SWE-Bench Verified, SWE-QA, SWE-QA-Pro und Oolong.

• Token-Einsparungen: SWE-Pruner Pro ist die einzige der sieben evaluierten Methoden, die den End-to-End-Tokenverbrauch in jeder Einstellung reduziert.
  • Bis zu 39 % Reduktion bei SWE-QA-Pro (Qwen3-Coder-Next).
  • 30 % Reduktion beim Langkontext-Benchmark Oolong (MiMo-V2-Flash).
  • Im Gegensatz dazu erhöhten andere Methoden (z. B. LLMLingua2) den Tokenverbrauch bei Langkontext-Aufgaben teilweise um bis zu 190 %.
• Aufgabenqualität:
  • SWE-QA/Pro: Hält die Aufgabenqualität innerhalb eines engen Bandes der ungeprunten Baseline (z. B. Änderung des Scores um +0,02 bei SWE-QA).
  • Oolong: Verbessert die Genauigkeit um +2,2 Punkte bei MiMo-V2-Flash.
  • SWE-Bench Verified: Auf MiMo-V2-Flash verbessert es die Resolve-Rate um +3,8 %, während es die Input-Tokens im Vergleich zur ungeprunten Baseline um 7,4 % reduziert. Auf Qwen3-Coder-Next erzielt es die größte Reduktion der Input-Tokens (-13,5 %) bei der geringsten Degradation der Resolve-Rate (-1,2 %).
• Latenz: Der In-Server-Head fügt der gesamten Generierungszeit etwa 15,0 % aggregierte Wandzeit hinzu – ein Preis, der durch die reduzierte Kontextgröße für nachfolgende Turns kompensiert wird.

Bedeutung und Ansprüche

Die Arbeit behauptet, dass das für das Kontext-Pruning erforderliche „Relevanzurteil“ kein externes Signal ist, das durch zusätzliche Abfragen oder Modelle hervorgerufen werden muss, sondern bereits in den Repräsentationen vorhanden ist, die das Backbone während des passiven Lesens einer Beobachtung bildet.

• Paradigmenwechsel: Anstatt das Pruning um den Agenten herum zu bauen (was externe Modelle oder explizite Abfragen erfordert), liest SWE-Pruner Pro einfach das Signal, das der Agent bereits gebildet hat.
• Praktische Auswirkungen: Dieser Ansatz löst den Qualitäts-Kompression-Trade-off, der in früheren Arbeiten beobachtet wurde, und ermöglicht aggressives Pruning (bis zu 39 % Token-Ersparnis) ohne Verschlechterung der Performance – in einigen Fällen sogar mit einer Verbesserung durch die Milderung der Langkontext-Degradation.
• Generalisierbarkeit: Obwohl die Evaluierung auf Python-zentrierten Coding-Aufgaben erfolgte, ist die Pipeline sprachagnostisch und hat gezeigt, dass sie sowohl Token-Einsparungen als auch die Qualität bei natürlichen Sprach-Langkontext-Aufgaben (Oolong) bewahrt, was darauf hindeutet, dass das Paradigma auf andere Domänen übertragbar ist.

Die Autoren kommen zu dem Schluss, dass für Coding-Agenten der effizienteste Weg des Kontextmanagements darin besteht, den internen Zustand des Backbones selbst zu nutzen, um die Latenz und Komplexität externer Scoring-Mechanismen zu vermeiden.