KI-Codeabruf: Warum Vektor-Embeddings scheitern und dateiweise LLM-Graphen gewinnen

Ein einjähriges Experiment zum Aufbau eines Code-Indexierungssystems für KI-Codierungstools lieferte klare Ergebnisse: Vektor-Embeddings auf Code-Chunks und Tree-Sitter-AST-Parsing haben beide kritische Schwächen, während pro-Datei-LLM-Analysen, gespeichert in einem Neo4j-Graphen mit semantischer Volltextsuche, am besten funktionieren. Die Erkenntnisse decken sich mit aktuellen Arbeiten wie RepoGraph (ICLR 2025) und Code-Craft.

Getestete Ansätze

• Vektor-Embeddings auf Code-Chunks – vollständig verworfen. Eine Funktion namens process() in einem Zahlungsdienst und eine in einer Bildverarbeitungspipeline ergeben ähnliche Embeddings, obwohl sie nichts miteinander zu tun haben. Vektoren glätten Call-Graphen, Vererbung, Importe – alle strukturellen Beziehungen. Die Retrieval-Präzision war inakzeptabel.
• Tree-Sitter-AST-Parsing – präzise und schnell, aber rein strukturell. Es kann sagen, dass eine Funktion existiert und was sie aufruft, aber nicht die Frage beantworten: „Diese Funktion verarbeitet Webhook-Wiederholungen für fehlgeschlagene Stripe-Zahlungen.“ Es versagt, wenn Entwickler Fragen in Geschäftssprache formulieren.
• Pro-Datei-LLM-Analyse → Graph – funktioniert. Jede Datei erhält einen LLM-Aufruf, der purpose, summary und businessContext generiert, gespeichert als Knoten in Neo4j mit Kanten zu Klassen, Funktionen, Schlüsselwörtern und Importen. Das Retrieval verwendet Volltextsuche über diese semantischen Felder anstelle von Vektorähnlichkeit. SHA-256-Diffing beschränkt die Neuindizierung auf geänderte Dateien, wodurch die anfänglichen Kosten überschaubar bleiben.

Benchmarks aus der Literatur

RepoGraph (ICLR 2025) zeigte eine +32,8% Verbesserung bei SWE-bench mit Graph-Ansätzen. Code-Craft erreichte +82% Top-1-Retrieval-Präzision durch Bottom-up-LLM-Zusammenfassungen aus Code-Graphen.

Vergleich mit bestehenden Tools

Das Team veröffentlichte einen direkten Vergleich in comparison.md. Wesentliche Unterschiede:

• Bytebell: Pro-Datei-LLM → purpose + summary + businessContext + Entitäten; Neo4j + MongoDB-Speicher; SHA-256-diff-bewusste Neuindizierung.
• PageIndex: Inhaltsverzeichnis-Baum für lange PDFs/Dokumente; keine codespezifischen Semantiken.
• GitNexus: Tree-Sitter-AST + Community-Erkennung; optionale pro-Symbol-Semantiken; verwendet LadybugDB.
• GraphRAG: Pro-Chunk-LLM-Entitäten + Community-Clustering für allgemeinen Text, nicht für Code.
• Sourcegraph/Cody: LSIF/SCIP-Suchindex; keine pro-Knoten-Semantiken; Bereitstellung als Self-Hosted oder SaaS.
• Augment: Proprietärer semantischer Index mit Embeddings; nur SaaS; kontinuierliche, verwaltete Indizierung.

Open Source

Das System ist Open Source unter github.com/ByteBell/bytebell-oss.