Grep contre embeddings dans les agents de code

Un outil de recherche grossier entre les mains de quelqu'un qui essaie dix fois vaut mieux qu'un outil fin utilisé une seule fois. Cela suffit à expliquer un fait contre-intuitif pour qui vient du RAG : les agents de code travaillent très bien avec grep, un listing de fichiers et rien d'autre.

L'agent cherche RateLimit, ne trouve rien, essaie throttle, tombe sur un middleware, lit le fichier, y voit un nom de service, cherche ses usages. Cinq tours, aucune infrastructure, et il a trouvé le code ainsi que la manière dont il est appelé. Un index vectoriel aurait répondu en un appel, peut-être juste, peut-être avec la version du fichier d'avant votre dernier commit.

Pourquoi la persévérance suffit, sur du code

Plusieurs propriétés du code rendent la recherche lexicale itérative étonnamment forte.

Le code est son propre vocabulaire. Dans un corpus documentaire, la même idée s'écrit de vingt façons, et c'est pour cela qu'on a besoin d'embeddings. Dans une base de code, un concept porte un nom (une classe, une fonction, une constante), répété à l'identique partout où le concept est utilisé. Une fois le nom trouvé, grep donne une exhaustivité que la similarité ne donnera jamais, avec tous les appelants et pas seulement les dix plus ressemblants.

Chaque résultat enseigne la requête suivante. L'agent mène une enquête plus qu'il ne lance une recherche. Un import, un nom de namespace, une convention de nommage aperçue dans un fichier lui donnent le terme exact du tour suivant, et la boucle transforme une recherche à faible rappel en parcours guidé.

Le résultat est vérifiable. Une ligne de grep est un fait : ce fichier contient cette chaîne à cette ligne. Un résultat vectoriel est une proximité, ce fragment ressemblant à votre question à 0,81. L'agent peut raisonner sur une absence de résultat lexical, alors qu'il ne peut rien conclure d'un score.