Présentation de l’étude

Une série d’expériences a comparé deux mécanismes de récupération de code pour des agents de programmation : la recherche lexicale grep et la navigation sémantique fournie par le protocole LSP. Trois modèles Claude (Opus 4.8, Sonnet 4.6, Haiku 4.5) ont été testés sur plusieurs dépôts Python et TypeScript, avec des scénarios de localisation simple et de complétude de références. L’évaluation s’est concentrée sur le taux de succès, la précision, le rappel et la consommation de tokens, en ne comptant les tokens que lorsque la tâche était terminée avec succès.

Comparaison des performances selon les tâches

Sur les tâches de localisation de code, les modèles ont choisi l’outil sémantique entre 0 % et 6 % du temps lorsqu’ils disposaient à la fois de grep et de LSP. Imposer un parcours « sémantique‑en‑premier » a fait chuter le taux de réussite de 100 % à 89 %. En revanche, pour les tâches de complétude de références (trouver tous les appelants), le recours à LSP a été sélectionné 45 % à 57 % du temps. LSP a atteint une précision de 1,00 contre 0,76 pour grep, mais le rappel est resté proche de 0,66 pour les deux approches, indiquant que la limite provenait davantage de l’effort de l’agent que de la capacité de récupération.

Le gain de précision de LSP s’est accompagné d’une utilisation plus élevée de tokens pour les modèles les plus puissants, contredisant l’idée que la sémantique réduirait systématiquement la charge tokenique.

Influence du format de réponse et du bruit du dépôt

Initialement, les outils LSP ne renvoyaient que la localisation (chemin, ligne, colonne). Grep, lui, renvoyait immédiatement la ligne complète : 

src/auth.ts:42: return validateToken(token)
. En modifiant le backend LSP pour inclure le texte source inline, le taux de succès (Pass@1) sur les renommages de fichiers est passé de 0,67 à 0,83, tandis que le nombre moyen de lectures de fichiers supplémentaires est tombé de 15,2 à 3,2 par épisode. Cette amélioration montre que la forme du contexte retourné influence directement l’efficacité de l’agent.

Le niveau de « bruit lexical » du dépôt a également modifié les résultats. Sur un dépôt TypeScript propre, LSP a consommé 16 % de tokens supplémentaires sans gain de F1. Sur un dépôt bruité, LSP a amélioré le F1 de 0,246 tout en réduisant la consommation tokenique de 12 %. Ainsi, le facteur déterminant n’est pas la présence de types statiques, mais la proportion de correspondances non pertinentes que grep doit filtrer.

Implications pour la conception d’outils d’agents

Ces observations soulignent deux axes de conception. Premièrement, la « familiarité d’interface » : les modèles semblent privilégier les actions qu’ils ont rencontrées durant l’entraînement, notamment les boucles prompt‑outil‑résultat lisible. Deuxièmement, le format de sortie doit être directement exploitable, sinon chaque résultat sémantiquement correct impose des étapes supplémentaires (ouverture de fichier, extraction du texte), ce qui pénalise le flux de travail.

En pratique, un harness d’agent efficace doit définir clairement les schémas d’entrée, le type de données retournées et les actions post‑traitement attendues. Ignorer ces aspects conduit à des comportements où un outil plus précis (LSP) est sous‑utilisé au profit d’un outil plus simple mais immédiatement exploitable (grep).