Récupération de code IA : graphes LLM vs embeddings vectoriels

Une expérience d'un an visant à construire un système d'indexation de code pour les outils de codage IA a donné des résultats clairs : les embeddings vectoriels sur les morceaux de code et l'analyse AST de Tree-sitter présentent tous deux des défauts critiques, tandis que l'analyse par fichier via LLM stockée dans un graphe Neo4j avec recherche plein texte sémantique fonctionne le mieux. Ces résultats font écho à des articles récents comme RepoGraph (ICLR 2025) et Code-Craft.

Approches testées

Embeddings vectoriels sur morceaux de code – totalement écartés. Une fonction nommée process() dans un service de paiement et une autre dans un pipeline d'images génèrent des vecteurs similaires, bien qu'elles n'aient rien à voir entre elles. Les vecteurs aplatissent les graphes d'appels, l'héritage, les imports — toutes les relations structurelles. La précision du rappel était inacceptable.
Analyse AST Tree-sitter – précise et rapide, mais uniquement structurelle. Elle peut dire qu'une fonction existe et ce qu'elle appelle, mais ne peut pas répondre à la question « cette fonction gère les réessais de webhook pour les paiements Stripe échoués ». Elle est insuffisante lorsque les développeurs posent des questions en langage métier.
Analyse par fichier via LLM → graphe – fonctionne. Chaque fichier reçoit un appel LLM générant purpose, summary et businessContext, stockés comme nœuds dans Neo4j avec des arêtes vers les classes, fonctions, mots-clés et imports. La recherche utilise la recherche plein texte sur ces champs sémantiques au lieu de la similarité vectorielle. Le diff SHA-256 limite la réindexation aux fichiers modifiés, rendant le coût initial gérable.

Benchmarks issus de la littérature

RepoGraph (ICLR 2025) a montré une amélioration de +32,8 % sur SWE-bench avec des approches par graphe. Code-Craft a atteint +82 % de précision de rappel de premier rang en utilisant des résumés LLM ascendants à partir de graphes de code.

Comparaison avec les outils existants

L'équipe a publié une comparaison côte à côte dans comparison.md. Principales différences :

Bytebell : LLM par fichier → purpose + summary + businessContext + entités ; stockage Neo4j + MongoDB ; réindexation consciente des différences SHA-256.
PageIndex : arbre de raisonnement TOC pour longs PDFs/docs ; pas de sémantique spécifique au code.
GitNexus : AST Tree-sitter + détection de communautés ; sémantique optionnelle par symbole ; utilise LadybugDB.
GraphRAG : entités LLM par morceau + clustering communautaire pour texte général, pas de code.
Sourcegraph/Cody : index de recherche LSIF/SCIP ; pas de sémantique par nœud ; déploiement auto-hébergé ou SaaS.
Augment : index sémantique propriétaire avec embeddings ; SaaS uniquement ; indexation continue gérée.