JetBrains sur la création d'un pipeline RAG pour la recherche sémantique de code : analyse syntaxique, découpage, vectorisation

JetBrains a publié la première partie d'un journal de développement sur la construction d'Air Context, leur plateforme de recherche sémantique de code, un pipeline RAG qui fournit aux agents LLM « des preuves précises et citables issues de véritables dépôts plutôt que ce que grep remonte par hasard ». Rédigée par Adam Malek et Ashot Kazaryan, la partie 1 couvre l'analyse syntaxique, le découpage et la vectorisation.

Pourquoi la recherche sémantique plutôt que grep

L'article soutient que la recherche par mots-clés et grep échouent car ils exigent que l'agent connaisse le texte exact à l'avance. L'exemple concret : « un agent cherchant où les jetons de session sont rafraîchis ne peut pas compter sur le fait que le code contienne aimablement le mot 'refresh' ». Pour raisonner sur des domaines abstraits, l'agent doit rechercher par le sens. Le RAG indexe le code source d'une manière qui capture la sémantique, puis permet à l'agent de récupérer les éléments pertinents à la demande via une recherche en texte libre.

Analyse syntaxique et découpage

L'analyse syntaxique/découpage est l'étape de prétraitement, et JetBrains la qualifie de « souvent négligée ». Les dépôts de production contiennent des milliers de fichiers s'étendant sur des centaines ou des milliers de lignes chacun, et les agents gonflent davantage les bases de code en étant des « écrivains prolifiques ». Les fichiers peuvent contenir de nombreuses classes, champs et méthodes avec des degrés de relation variables.

Les mauvaises approches, selon l'article :

• Embedding du fichier entier — même si vous pouviez faire tenir le fichier dans le modèle d'embedding, la recherche renverrait le fichier entier, ce qui irait à l'encontre de l'objectif de trouver une fonction, un symbole ou un extrait spécifique.
• Embedding par ligne — les lignes individuelles sont « sémantiquement insignifiantes sans le contexte environnant ». Un nom de fonction ou un commentaire générique « ne mérite pas un embedding et produira un résultat de récupération erroné », surchargeant l'agent avec des micro-résultats insignifiants.

L'objectif est des unités correctement délimitées : le flux d'exploration de l'agent vise principalement à trouver une fonction, un symbole ou un extrait de code spécifique, donc les limites de découpage doivent s'aligner sur ces unités (le « fin AST d'analyse syntaxique et de découpage », selon l'expression de l'article).

Ce qui suit

Ceci est la partie 1 d'une série. Les auteurs indiquent qu'ils couvriront chaque étape, du prétraitement au stockage et à l'intégration de l'agent, y compris les « faux pas » qu'ils ont commis. L'article s'arrête au milieu d'une phrase avant de détailler les spécificités de l'étape de vectorisation, alors attendez-vous à une suite sur la façon dont les morceaux sont transformés en une représentation d'embedding.

À qui cela s'adresse

Aux développeurs qui construisent la récupération pour les agents de codage sur de grandes bases de code, ou à toute personne évaluant les stratégies de découpage pour le RAG de code.