💻 computer science

TICoder: A Repository-Level Code Generation Framework with Test-Driven Planning and Implementation-Aware Reuse

Dieses Paper stellt TICoder vor, ein neuartiges Framework zur Code-Generierung auf Repository-Ebene, das die Leistung großer Sprachmodelle durch die Integration eines testgetriebenen iterativen Planungsmechanismus zur Verhaltenssteuerung sowie einer implementierungswissenden Wiederverwendungsstrategie mit Dual-View-Ähnlichkeit und Dual-Stage-Selektion zur effektiven Nutzung bestehenden Repository-Codes verbessert und so eine durchschnittliche Steigerung von 11,52 % gegenüber dem aktuellen Stand der Technik erzielt.

Ursprüngliche Autoren: Siyu Nan, Yaling Luo, Jian Wang, Neng Zhang, Bing Li

Veröffentlicht 2026-06-09

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Siyu Nan, Yaling Luo, Jian Wang, Neng Zhang, Bing Li

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

Stellen Sie sich vor, Sie sind ein Meisterkoch (die KI), der versucht, ein komplexes Gericht basierend auf einer vagen Bestellung eines Kunden zuzubereiten: „Mach mir etwas mit Pasta.“ Sie haben Zugriff auf eine riesige Bibliothek von Rezeptbüchern (das Code-Repository), aber Sie können immer nur wenige Seiten gleichzeitig lesen.

Die meisten aktuellen KI-Köche versuchen, dieses Problem zu lösen, indem sie nach einem einzelnen Rezept suchen, das nach „Pasta“ klingt, und es einfach kopieren. Dies schlägt jedoch oft fehl, weil der Kunde vielleicht eine bestimmte Art von Pasta möchte oder das Rezept einen entscheidenden Schritt vermisst, wie zum Beispiel „zuerst das Wasser aufsetzen“.

TICoder ist eine neue, intelligentere Art und Weise, der KI-Koch zu helfen. Es fungiert wie ein hoch organisierter Sous-Chef, der nicht nur Rezepte findet, sondern der KI auch hilft, die Mahlzeit zu planen und genau zu lernen, wie sie die Zutaten korrekt verwendet. So funktioniert es, unterteilt in drei einfache Teile:

1. Die „Testgetriebene“ Planung (Der Geschmackstest)

Das Problem: Wenn die KI versucht, die Schritte zur Zubereitung des Gerichts allein aus den vagen Worten des Kunden zu planen, übersieht sie oft die Details. Sie vergisst vielleicht zu prüfen, ob die Pasta glutenfrei ist oder ob die Sauce eine Stunde lang köcheln muss.

Die TICoder-Lösung: Bevor die KI mit dem Kochen beginnt, bittet TICoder um einen „Geschmackstest“ (Testfälle). Dies sind wie spezifische Anweisungen: „Die Sauce muss scharf sein“ oder „Die Pasta muss al dente sein“.

So funktioniert es: Die KI entwirft einen Plan. Dann schaut eine „Richter“-KI (Judge AI) auf den Plan und die Geschmackstests. Wenn der Plan nicht zu den Tests passt (z. B. „Du hast die Schärfe vergessen!“), schickt der Richter ihn zur Verfeinerung zurück.
Das Ergebnis: Die KI durchläuft diesen „Entwurf, Urteil, Korrektur“-Zyklus so lange, bis der Plan perfekt mit dem erwarteten Ergebnis übereinstimmt. Dies stellt sicher, dass die KI genau weiß, was sie bauen muss, bevor sie mit dem Bauen beginnt.

2. Die „Implementierungsorientierte“ Wiederverwendung (Das richtige Werkzeug finden)

Das Problem: Sobald die KI einen Plan hat, muss sie vorhandene Werkzeuge (Funktionen) in der Bibliothek finden, um ihr zu helfen.

Der alte Weg: Die KI sucht nach einem Werkzeug, das nach dem klingt, was sie braucht. Sie findet vielleicht einen „Saucenmacher“, der zwar funktioniert, aber die falsche Hitze verwendet oder Salz hinzufügt, wenn es nicht sollte. Sie schnappt sich das Werkzeug, weiß aber nicht, wie man es richtig benutzt.
Die TICoder-Lösung: TICoder betrachtet das Werkzeug auf zwei Arten:
1. Funktion: Erledigt es den richtigen Job? (z. B. „Ja, es macht eine Sauce.“)
2. Implementierung: Funktioniert es auf die richtige Art? (z. B. „Ja, es köchelt 20 Minuten lang, genau wie wir es brauchen.“)
Das Ergebnis: Es findet das exakte Werkzeug, das sowohl der Aufgabenbeschreibung als auch der spezifischen Art und Weise entspricht, wie es ausgeführt werden muss.

3. Die „Nutzungsmuster“-Auswahl (Lernen aus Beispielen)

Das Problem: Selbst wenn die KI das perfekte Werkzeug gefunden hat, weiß sie vielleicht nicht, wie sie es einbauen soll. Stellen Sie sich vor, Sie finden eine komplexe Espressomaschine, wissen aber nicht, welchen Knopf Sie drücken müssen, um einen Latte statt eines Cappuccinos zu bekommen.

Die TICoder-Lösung: TICoder gibt der KI nicht nur das Werkzeug; es zeigt der KI, wie andere Köche genau dieses Werkzeug in der Vergangenheit verwendet haben.

Es schaut in die Bibliothek, um zu sehen, wie dieses Werkzeug tatsächlich in echten Rezepten verwendet wurde.
Es filtert durch tausende von Beispielen, um die besten und gebräuchlichsten Arten der Verwendung zu finden (Clustering ähnlicher Methoden) und entfernt die verwirrenden oder seltsamen Ausnahmen.
Das Ergebnis: Die KI erhält einen „Spickzettel“, der die 2 oder 3 besten Wege zeigt, das Werkzeug zu benutzen, um sicherzustellen, dass sie beim Zusammenstellen des fertigen Gerichts keinen Fehler macht.

Das Endergebnis

Wenn Sie alle drei Teile zusammenführen:

Planung: Die KI weiß genau, was zu tun ist, weil sie ihre Arbeit gegen „Geschmackstests“ geprüft hat.
Abruf (Retrieval): Sie findet die perfekten Werkzeuge, die sowohl zum Job als auch zur Methode passen.
Wiederverwendung (Reuse): Sie weiß genau, wie sie diese Werkzeuge benutzt, weil sie echte Beispiele studiert hat.

Das Resultat: In den Experimenten des Papers half diese Methode der KI, besser zu kochen (Code zu generieren) als bisherige Methoden. Sie verbesserte die Erfolgsraten um durchschnittlich 11,52 % über verschiedene Arten von Codierungsaufgaben und verschiedene KI-Modelle hinweg. Im Wesentlichen verwandelt TICoder eine verwirrte KI in einen präzisen, gut geplanten und erfahrenen Koch.

Technisches Resümee: TICoder

Problemstellung

Die repository-weite Codegenerierung mittels Large Language Models (LLMs) steht vor erheblichen Herausforderungen aufgrund komplexer Code-Abhängigkeiten und begrenzter Kontextfenster. Während bestehende Ansätze Retrieval-Augmented Generation (RAG) und Planungsmechanismen nutzen, um Funktionen aus einem Repository wiederzuverwenden, identifizieren die Autoren zwei kritische Einschränkungen aktueller State-of-the-Art-Methoden (SOTA):

Mangel an testgesteuerter Verhaltenssteuerung in der Planung: Bestehende planungsbasierte Methoden leiten Implementierungsschritte direkt aus natürlichen Sprachanforderungen (NL) ab. NL-Anforderungen sind jedoch oft vage oder unvollständig, was zu unzuverlässigen Plänen führt. Aktuelle testgesteuerte Generierungsmethoden wenden Testfälle primär während der Codegenerierung oder in der Post-Generierungsphase an, wodurch das Potenzial ungenutzt bleibt, den Planungsprozess selbst zu steuern.
Mangel an code-basierter Implementierungsbewusstsein bei der Wiederverwendung: Bestehende Retrieval-Strategien verlassen sich stark auf die semantische Ähnlichkeit zwischen Implementierungsschritten und Funktionsbeschreibungen. Sie übersehen oft die tatsächliche Implementierungslogik, die im Code eingebettet ist. Zudem werden die abgerufenen Funktionen häufig in Prompts eingefügt, ohne zu verstehen, wie sie innerhalb des Repositorys tatsächlich verwendet werden (Nutzungsmuster), was zu einer ineffektiven Wiederverwendung führt.

Methodik: Das TICoder-Framework

Die Autoren schlagen TICoder vor, ein Framework, das darauf ausgelegt ist, sowohl die Planungs- als auch die Wiederverwendungsphasen der repository-weiten Codegenerierung zu verbessern. Das Framework besteht aus drei Hauptphasen:

1. Testgesteuerte iterative Planung

Anstatt Pläne ausschließlich aus NL-Anforderungen zu generieren, nutzt TICoder Testfälle als Verhaltensspezifikationen, um Implementierungsschritte zu verfeinern. Diese Phase verwendet einen „Judge-and-Reflection“-Mechanismus mit zwei LLM-Rollen:

LLM-as-a-Planner: Erstellt eine initiale Sequenz von Implementierungsschritten basierend auf der Anforderung und den Testfällen, geleitet von Prinzipien wie Klarheit, Bewusstsein für Randbedingungen und expliziten Abhängigkeiten.
LLM-as-a-Judge: Bewertet die generierten Schritte anhand von drei Dimensionen: funktionale Abdeckung/Konsistenz, Unabhängigkeit und Granularität.
Iterative Verfeinerung: Wenn die Schritte die Qualitätsschwellenwerte nicht erfüllen, gibt der Judge Feedback, und der Planner verfeinert die Schritte. Diese Schleife setzt sich fort, bis der Plan zufriedenstellend ist oder ein maximales Iterationslimit erreicht wird.

2. Implementierungsbewusste Codewiederverwendung

Diese Phase konzentriert sich darauf, relevante Aufruferfunktionen (Callee Functions) abzurufen und zu identifizieren, wie diese effektiv zu verwenden sind.

Dual-View Callee Function Retrieval: Um Funktionen abzurufen, berechnet TICoder einen kombinierten Ähnlichkeitswert, der Folgendes kombiniert:
- Funktionale Ähnlichkeit ( $Sim_F$ ): Semantische Ähnlichkeit zwischen dem Implementierungsschritt und der Funktionsbeschreibung.
- Implementierungs-Ähnlichkeit ( $Sim_I$ ): Ähnlichkeit zwischen einer Code-Repräsentation des Implementierungsschritts (generiert durch ein LLM) und dem tatsächlichen Funktionsimplementierungscode.
- Der endgültige Score ist eine gewichtete Summe ( $Sim = \alpha \cdot Sim_F + \beta \cdot Sim_I$ ).
Dual-Stufen-Auswahl von Nutzungsmustern: Um sicherzustellen, dass Funktionen korrekt verwendet werden, wählt TICoder repräsentative Nutzungsmuster aus dem Repository aus:
- Graph-basierte Identifikation: Konstruiert einen Repository Call Graph (RCG), um alle Aufruferfunktionen für eine abgerufene Callee-Funktion zu identifizieren.
- Strukturbasierte Clusterbildung: Gruppiert Aufruferfunktionen basierend auf der Menge der von ihnen aufgerufenen Funktionen (strukturelle Äquivalenz).
- Perplexitäts-basierte Filterung: Innerhalb jedes Clusters wird der relevanteste Aufrufer (niedrigste Perplexität) als Zentrum ausgewählt. Ein globaler Filter rankt diese Zentren dann nach Perplexität, um die Top- $n_p$ Muster auszuwählen, wobei ein Gleichgewicht zwischen Kontextreichhalt und Token-Effizienz gewahrt wird.

3. Verbesserte Codegenerierung

Die abschließende Codegenerierungsphase integriert die verfeinerten Implementierungsschritte, die abgerufenen Callee-Funktionen, die ausgewählten Nutzungsmuster, die Testfälle und die ursprüngliche Anforderung in einen einzigen Prompt, um das LLM zur Generierung des finalen Codes anzuweisen.

Kernbeiträge

Das Paper beansprucht drei primäre Beiträge:

TICoder Framework: Ein neuartiges Framework für die repository-weite Codegenerierung, das testgesteuerte iterative Planung und implementierungsbewusste Codewiederverwendung integriert.
Implementierungsbewusste Wiederverwendungsstrategie: Ein Dual-View-Retrieval-Mechanismus (funktionale + Implementierungs-Ähnlichkeit) und eine Dual-Stage-Selektionsstrategie (Clustering + Perplexitäts-Filterung), um Repository-Funktionen präzise zu identifizieren und wiederzuverwenden.
Umfassende empirische Evaluierung: Umfangreiche Experimente, die zeigen, dass TICoder verschiedene SOTA-Baselines über mehrere LLMs und Benchmarks hinweg übertrifft.

Experimentelle Ergebnisse

Die Autoren evaluierten TICoder auf zwei weit verbreiteten Benchmarks, CoderEval (Python und Java) und DevEval (Python), unter Verwendung von drei Backbone-LLMs: GPT-4o-mini, DeepSeek-V3 und Qwen2.5-Coder-7B.

Gesamtleistung: TICoder übertraf konsistent alle Baselines (einschließlich SimpleRAG, RepoCoder, AllianceCoder und RepoScope). Es erreichte eine durchschnittliche Verbesserung von 11,52 % gegenüber der am besten abschneidenden Baseline.
Statistische Signifikanz: Ein zweiseitiger t-Test bestätigte, dass die Leistungssteigerungen statistisch signifikant waren ( $p < 0,05$ ).
Ablationsstudie: Das Entfernen einer der Schlüsselkomponenten (Planung, Testfälle, iterative Verfeinerung, Dual-View-Retrieval oder Nutzungsmuster) führte zu einer Leistungsverschlechterung, was die Notwendigkeit jedes Moduls validiert.
- Bemerkenswerterweise führte das Entfernen des Planungsmoduls zu einem Rückgang von 6,87 % bei Pass@1.
- Das Entfernen von Testfällen aus der Generierungsphase verursachte einen erheblichen Rückgang von 10,42 %.
Hyperparameter-Sensitivität:
- Iterationen: Die Leistung verbesserte sich generell mit den Iterationen, war jedoch nicht monoton; übermäßige Iterationen konnten Rauschen einführen.
- Ähnlichkeitsgewichte: Funktionale Ähnlichkeit war im Allgemeinen wichtiger, aber die Implementierungs-Ähnlichkeit lieferte signifikante Gewinne, insbesondere für Java.
- Nutzungsmuster: Eine moderate Anzahl an Mustern (z. B. 2) lieferte die besten Ergebnisse; zu wenige einschränkten den Kontext, während zu viele Rauschen einführten.

Bedeutung und Ansprüche

Das Paper behauptet, dass TICoder die spezifischen Einschränkungen früherer planungsbasierter RACG-Ansätze adressiert, indem es Testfälle explizit in die Planungsphase einbezieht und das Retrieval in der tatsächlichen Code-Implementierungslogik begründet. Die Autoren behaupten, dass TICoder durch die Überbrückung der Lücke zwischen natürlichen Sprachanforderungen und ausführbarem Code mittels Verhaltensspezifikationen (Tests) und strukturellem Kontext (Nutzungsmuster) eine präzisere und kontextuell angemessenere Codegenerierung in komplexen Repository-Umgebungen ermöglicht. Die Arbeit hebt hervor, dass erfolgreiche repository-weite Generierung nicht nur das Finden ähnlichen Codes erfordert, sondern das Verständnis darüber, wie dieser Code verhaltensmäßig spezifiziert und strukturell in die bestehende Codebasis integriert ist.