💻 computer science

BLAgent: Agentic RAG for File-Level Bug Localization

BLAgent ist ein neuartiges agentic Retrieval-Augmented Generation-Framework, das die Fehlerlokalisierung auf Dateiebene durch code-struktur-bewusste Kodierung, dual-perspektivische Query-Transformation und eine zweiphasige agentic Neuordnung verbessert und dabei auf SWE-bench Lite einen State-of-the-Art-Ergebnis bei gleichzeitiger erheblicher Kostensenkung und Steigerung des Erfolgs nachgelagerter automatischer Programmkorrekturen erzielt.

Ursprüngliche Autoren: Md Afif Al Mamun, Gias Uddin

Veröffentlicht 2026-05-19

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Md Afif Al Mamun, Gias Uddin

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

Das große Problem: Eine Nadel im Heuhaufen finden

Stellen Sie sich vor, Sie sind ein Mechaniker (ein Softwareentwickler), der versucht, ein kaputtes Auto zu reparieren. Ein Kunde gibt Ihnen eine Beschwerde: „Das Auto macht ein seltsames Geräusch, wenn ich links abbiege."

In der Welt der Software ist diese Beschwerde ein Bug-Report (Fehlerbericht). Das Auto ist ein riesiges Code-Repository mit Millionen von Codezeilen (das Heu). Die spezifische Codezeile, die das Geräusch verursacht, ist die Nadel.

Lange Zeit hatten KI-Tools, die versuchten, diese Bugs zu beheben, Schwierigkeiten, weil sie die Nadel nicht zuerst finden konnten. Wenn die KI den falschen Teil des Motors (die falsche Datei) errät, versucht sie, das Falsche zu reparieren, und das Auto ist immer noch kaputt. Dies nennt man Bug-Localization (Fehlerlokalisierung).

Die Lösung: BLAgent (Der Super-Detektiv)

Die Autoren haben ein neues System namens BLAgent entwickelt. Stellen Sie es sich als einen Super-Detektiv vor, der nicht nur rät, sondern einen intelligenten, schrittweisen Untersuchungsprozess nutzt, um die genaue Datei zu finden, die repariert werden muss, bevor er versucht, sie zu reparieren.

BLAgent verwendet eine Technik namens Agentic RAG (Retrieval-Augmented Generation). Auf Deutsch bedeutet dies, dass die KI nicht einfach eine Antwort „halluziniert"; sie geht in eine Bibliothek (das Code-Repository), findet die richtigen Bücher (Code-Dateien), liest sie und denkt dann über die Antwort nach.

Hier ist, wie BLAgent funktioniert, aufgeteilt in drei einfache Schritte:

1. Die Bibliothek organisieren (Smart Chunking)

Stellen Sie sich vor, Ihre Bibliothek ist ein Chaos. Bücher sind in zwei Hälften gerissen und Seiten sind zufällig zusammengeklebt. Wenn Sie den Bibliothekar nach einem Buch über „Motoren" fragen, könnte er Ihnen eine Seite geben, auf der „Motor" steht, die aber eigentlich aus einem Kochbuch stammt.

Der alte Weg: Traditionelle KI teilt Code in zufällige Textblöcke auf, wie wenn man eine Buchseite für Seite zerreißt.
Der BLAgent-Weg: BLAgent verwendet eine strukturelle Karte (genannt AST). Es weiß, dass eine „Funktion" oder eine „Klasse" wie ein komplettes Kapitel ist. Es schneidet den Code nur am Ende dieser Kapitel durch.
Das Geheimnis: Es stempelt zudem den Dateipfad (die Adresse des Buches) auf jede Seite. Wenn der Bug-Report einen spezifischen Ordnernamen erwähnt, kann BLAgent diese Adresse sofort mit dem richtigen Buch abgleichen.

2. Bessere Fragen stellen (Dual-Perspective Queries)

Stellen Sie sich vor, Sie bitten einen Bibliothekar um Hilfe.

Schlechte Frage: „Mein Auto ist kaputt." (Zu vage).
Die Strategie von BLAgent: Es stellt zwei verschiedene Fragen, um die besten Ergebnisse zu erzielen:
1. Die strukturelle Frage: „Welche Datei enthält die Funktion turn_signal?" (Sucht nach spezifischen Namen und Code-Strukturen).
2. Die verhaltensbezogene Frage: „Welche Datei behandelt die Situation, in der das Auto beim Abbiegen ein Geräusch macht?" (Sucht nach Symptomen und Verhalten).

Indem es beide fragt, wirft BLAgent ein breiteres Netz und stellt sicher, dass es die richtige Datei nicht verpasst, nur weil der Bug-Report andere Wörter verwendet hat als der Code.

3. Die Ermittlungen des Detektivs (Agentic Reranking)

Dies ist der wichtigste Teil. Die Bibliothek gibt BLAgent eine Liste der 15 wahrscheinlichsten Bücher (Dateien). Aber welche ist wirklich der Übeltäter?

Alte KI: Nimmt das erste Buch auf der Liste und versucht, es zu reparieren.
BLAgent (Der Agent): Es agiert wie ein Detektiv. Es liest nicht nur das Cover, sondern öffnet die Bücher und betrachtet das Gerüst (das Inhaltsverzeichnis und die Kapitelüberschriften) der Top-Kandidaten.
- Es fragt sich: „Passt die Struktur dieser Datei zum Verbrechen?"
- Es weist jeder Datei eine Punktzahl (0 bis 10) zu.
- Dann liest es für die Top-Verdächtigen den tatsächlichen Text der relevanten Abschnitte, um eine endgültige, evidenzbasierte Entscheidung zu treffen.

Diese „begrenzte Schlussfolgerung" bedeutet, dass der Detektiv nur die wahrscheinlichsten Verdächtigen untersucht und Zeit sowie Geld spart, anstatt die ganze Bibliothek zu durchsuchen.

Warum das wichtig ist: Die Reparaturwerkstatt

Das Papier testete BLAgent an einem berühmten Benchmark namens SWE-bench (eine Sammlung von realen Software-Bugs).

Das Ergebnis: BLAgent fand in 78 % bis 86 % der Fälle die richtige Datei zur Reparatur (abhängig vom verwendeten KI-Modell).
Der Vergleich: Bisherige Methoden fanden die richtige Datei seltener.
Die Kosten: BLAgent ist 18-mal günstiger als die bisher beste Methode. Die alten Methoden waren wie die Einstellung eines Teams von 100 Leuten, die die Bibliothek durchsuchen; BLAgent ist wie die Einstellung eines sehr klugen Detektivs mit einer Karte.

Die Auswirkung auf die Fehlerbehebung:
Als BLAgent in ein automatisches Reparatur-System eingesteckt wurde, reparierte das System 20 % mehr Bugs als zuvor.

Analogie: Wenn Sie einem Mechaniker das falsche Motorteil geben, kann er das Auto nicht reparieren. Wenn Sie ihm das richtige Teil geben (genaue Lokalisierung), kann er es reparieren. BLAgent stellt sicher, dass der Mechaniker das richtige Teil erhält.

Was das Papier nicht sagt

Es behauptet nicht, jeden Bug zu beheben. In etwa 14 % der Fälle war die richtige Datei so versteckt oder der Bug-Report so vage, dass selbst BLAgent sie nicht in der Top-Liste finden konnte.
Es behauptet nicht, ein Zauberstab für alle Software zu sein. Es funktioniert am besten bei Python-Projekten (wie denen im Test) und ist auf die Qualität des Bug-Reports angewiesen.
Es sagt nicht, dass das Finden der Datei der einzige Schritt ist. Sobald die Datei gefunden ist, muss die KI den eigentlichen Code-Fix schreiben, was immer noch scheitern kann. Aber das Finden der Datei ist die größte Hürde.

Zusammenfassung

BLAgent ist eine intelligentere Art für KI, kaputten Code zu finden. Anstatt zufällig zu raten, organisiert es die Code-Bibliothek besser, stellt intelligentere Fragen und nutzt einen „Detektiv"-Schritt, um die Beweise zu überprüfen, bevor es einen Zug macht. Dies macht es viel schneller, günstiger und genauer beim Finden der Ursache von Software-Bugs.

Technische Zusammenfassung: BLAgent: Agentic RAG für die Fehlerlokalisierung auf Dateiebene

Problemstellung

Die Fehlerlokalisierung bleibt ein kritischer Engpass in der Softwarewartung, insbesondere für nachgelagerte Aufgaben wie Ursachenanalyse, Triage und automatisierte Programmkorrektur (APR). Obwohl Systeme zur Fehlerkorrektur auf Basis von Large Language Models (LLMs) Fortschritte erzielt haben, wird ihre Wirksamkeit grundlegend durch die Qualität der Lokalisierung auf Dateiebene begrenzt. In hierarchischen Pipelines führen ungenaue Dateiauswahlen zu Fehlern in nachfolgenden Stufen (z. B. Lokalisierung auf Anweisungsebene oder Generierung von Patches), was häufig zum Scheitern der Korrektur führt.

Bestehende Retrieval-Augmented Generation (RAG)-Ansätze für Code verlassen sich oft auf statisches Retrieval und naive textbasierte Chunking-Verfahren, wodurch sie die strukturellen Komplexitäten von Code oder die für die genaue Identifizierung fehlerhafter Dateien erforderliche Schlussfolgerung nicht erfassen können. Darüber hinaus fehlt rein auf Embeddings basierenden Methoden die Fähigkeit zur logischen Schlussfolgerung, um die funktionale Relevanz zu bewerten, während bestehende agentenbasierte Ansätze häufig ungebundene graphbasierte Traversierung einsetzen, was prohibitiv hohe Rechenkosten verursacht.

Methodik: BLAgent-Framework

Die Autoren schlagen BLAgent vor, ein neuartiges agentic RAG-Framework, das für die Fehlerlokalisierung auf Dateiebene entwickelt wurde. Das System integriert drei Kernkomponenten, um Genauigkeit und Kosten in Einklang zu bringen:

1. Repository-Codierung mit Pfad-augmentierter, AST-basierter Chunking

Anstelle einer naiven Textaufteilung setzt BLAgent CodeSplitter ein, um Quelldateien basierend auf Abstract Syntax Tree (AST)-Grenzen (z. B. Funktionen, Klassen, logische Blöcke) zu segmentieren. Dies gewährleistet die semantische Erhaltung und verhindert die Fragmentierung von Codekonstrukten.

Pfadaugmentierung: Jeder Code-Chunk wird mit seinem relativen Dateipfad versehen (z. B. src/utils/math.py). Dies schafft einen direkten Alignierungs-Kanal zwischen pfadähnlichen Signalen in Fehlerberichten (z. B. Stacktraces, Modulreferenzen) und den Code-Chunks, wodurch Vokabular-Unterschiede zwischen natürlichen Sprachbeschreibungen und Code-Identifikatoren adressiert werden.

2. Dual-Perspektive-Abfrage-Transformation

Um die semantische Lücke zwischen Fehlerberichten und Code zu überbrücken, zerlegt BLAgent jeden Fehlerbericht mithilfe von LLMs in zwei komplementäre Abfragen:

Strukturelle Transformation ( $T_0$ ): Konzentriert sich auf statische, syntaktische Aspekte und extrahiert Identifikatoren, Module, Funktionsnamen und den Kontext von Stacktraces.
Verhaltensbasierte Transformation ( $T_1$ ): Konzentriert sich auf das Laufzeitverhalten und erfasst beobachtete Symptome, erwartete versus tatsächliche Ausgaben sowie auslösende Bedingungen.
Beide Abfragen werden unabhängig voneinander verwendet, um Kandidatendateien aus einer Vektordatenbank abzurufen. Die resultierenden Kandidatensätze werden zusammengeführt (dedupliziert), um einen kompakten Pool (begrenzt auf 15 Dateien) für den Agenten zu bilden.

3. Zwei-Phasen-Agentisches Reranking

BLAgent führt eine begrenzte Schlussfolgerung über den abgerufenen Kandidatensatz durch einen Zwei-Phasen-Prozess durch:

Phase 1: Skelett-basierte Agenten-Bewertung (SAS): Ein ReAct-basierter Agent untersucht iterativ die strukturellen Skelette (Klassen, Funktionssignaturen, Docstrings) der Kandidatendateien. Er weist Relevanzwerte (0–10) basierend auf Hypothesen darüber zu, welche Dateien geändert werden müssen. Diese Phase arbeitet effizient innerhalb der Kontextgrenzen, indem sie die vollständige Verarbeitung des Quellcodes vermeidet.
Phase 2: Evidenz-verankertes Reranking (EAR): Um Gleichstände aufzulösen und die Relevanz auf Implementierungsebene zu verifizieren, durchlaufen die Top- $M$ (auf 5 festgelegt) Dateien aus Phase 1 eine Single-Shot-Inferenz. Der Kontext wird so bereinigt, dass er nur die globale Struktur der Datei und die vollständige Implementierung der vom Retriever hervorgehobenen Methoden enthält. Das LLM führt eine endgültige Rangfolge basierend auf dieser fundierten Evidenz durch.

Hauptbeiträge

Agentic RAG für die Lokalisierung: BLAgent stellt ein Rahmenwerk für begrenzte Schlussfolgerung vor, das Retrieval mit iterativer, werkzeuggestützter Schlussfolgerung integriert und die hohen Kosten ungebundener Graph-Traversierung vermeidet.
AST-bewusstes, pfadaugmentiertes Chunking: Die Arbeit zeigt, dass die Erhaltung syntaktischer Grenzen und die Augmentierung von Chunks mit Dateipfaden die Retrieval-Recall-Rate im Vergleich zu Standard-Text-basiertem oder Code-bewusstem Chunking erheblich verbessert.
Dual-Perspektive-Abfragen: Das Framework zeigt, dass die Zerlegung von Fehlerberichten in strukturelle und verhaltensbasierte Abfragen komplementäre Retrieval-Signale liefert und die Recall-Rate des initialen Kandidatenpools verbessert.
Kosteneffizientes Design: Durch die Begrenzung der Schlussfolgerung auf einen kompakten, durch Retrieval gefilterten Kandidatensatz und die Verwendung von Codeskeletten erreicht BLAgent eine hohe Genauigkeit bei deutlich geringerem Token-Verbrauch und API-Kosten im Vergleich zu graphbasierten agentenbasierten Baselines.

Experimentelle Ergebnisse

Das Framework wurde am SWE-bench-Lite-Datensatz (300 reale Python-Fehler) evaluiert.

Lokalisierungs-Genauigkeit:
- Mit einem Open-Source-Modell (GPT-OSS-120B) erreichte BLAgent eine Top-1-Genauigkeit von 78,6 % und einen MRR von 0,851.
- Mit einem Closed-Source-Modell (Claude-4.6-Sonnet) erreichte es eine Top-1-Genauigkeit von 86,7 % und einen MRR von 0,900.
- Diese Ergebnisse übertreffen State-of-the-Art-Baselines, einschließlich LocAgent (ein graphbasierter agentenbasierter Ansatz) und Agentless (ein APR-Framework mit Lokalisierung), oft mit signifikanten Margen.
Kosteneffizienz: BLAgent ist über 18-mal günstiger als die stärkste Baseline (LocAgent), wenn dasselbe Closed-Source-Modell verwendet wird. Es schloss alle 300 Instanzen für insgesamt ca. 27 USD ab, während LocAgent ein Budget von 300 USD bereits nach nur 182 Instanzen erschöpfte.
Auswirkung auf die automatische Programmkorrektur (APR): Bei der Integration in das Agentless-APR-Framework verbesserte BLAgent die End-to-End-Lösungsrate für Probleme um über 20 % (von 27,6 % auf 34,0 % mit Mehrheitsvoting).
Generalisierbarkeit: Die Architektur wurde erfolgreich auf die Lokalisierung auf Funktionsebene mit einer einzigen Prompt-Modifikation erweitert und erzielte State-of-the-Art-Ergebnisse ohne strukturelle Änderungen an der Pipeline.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass BLAgent einen neuen State-of-the-Art für die Fehlerlokalisierung auf Dateiebene etabliert, indem es Retrieval und agentenbasierte Schlussfolgerung effektiv kombiniert. Ihre primäre Bedeutung liegt in der Demonstration, dass:

Lokalisierung ein entscheidender Faktor ist: Eine genaue Lokalisierung auf Dateiebene führt direkt zu messbaren Gewinnen beim Erfolg der End-to-End-automatisierten Korrektur.
Begrenzte Schlussfolgerung ungebundener Traversierung überlegen ist: Agentenbasierte Schlussfolgerung, die auf einen hochwertigen, durch Retrieval gefilterten Kandidatensatz beschränkt ist, übertrifft komplexe graphbasierte Ansätze sowohl in der Genauigkeit als auch in den Kosten.
Die Retrieval-Qualität die Leistung begrenzt: Die Wirksamkeit der agentenbasierten Pipeline wird grundlegend durch die Recall-Rate des initialen dichten Retriever begrenzt; daher sind Verbesserungen beim Chunking und bei der Abfrage-Transformation entscheidend.
Kosteneffiziente Skalierbarkeit: Hochleistungs-Lokalisierung kann mit Open-Source-Modellen und effizientem Kontextmanagement (Skelette) erreicht werden, was fortschrittliche Fehlerlokalisierung ohne die prohibitiven Kosten proprietärer Modelle oder Graph-Traversierung zugänglich macht.

Die Autoren schließen, dass zwar eine präzise Lokalisierung notwendig, aber nicht ausreichend für eine perfekte Korrektur ist, da nachgelagerte Fehler (Lokalisierung auf Funktions-/Anweisungsebene und Generierung von Patches) weiterhin signifikante Engpässe darstellen. BLAgent bietet jedoch eine robuste, kosteneffiziente Grundlage zur Bewältigung der vorgelagerten Lokalisierungs-Herausforderung in der LLM-basierten Softwarewartung.