Idée principale

Un moteur de recherche vectoriel branché sur un dépôt de code répond bien à « où est écrite la règle qui refuse la modification d'un élément annulé ? ». Il ramène les fragments les plus proches de la question, y compris ceux qui n'en emploient aucun mot, et il le fait aussi bien dans une grande masse documentaire que dans un dépôt volumineux.

Il retrouve. Il ne voyage pas. Or la question suivante est presque toujours une question de voisinage : quel module appelle celui-ci, quelle autre règle porte sur le même objet, quel événement déclenche celui qu'on vient de lire, quel écran expose ce comportement. Le moteur n'y répond pas, et ce n'est pas un défaut de réglage : sa métrique est la proximité de sens entre un fragment et la question posée, jamais la relation entre deux éléments du corpus.

Deux capacités couvrent ce déplacement, et elles ne se ressemblent pas. Un graphe sémantique relie explicitement les concepts, les modules et les événements, et permet de passer d'un nœud à ses voisins déclarés. Le parcours du système de fichiers — lister le répertoire où le fragment a été trouvé, ouvrir les fichiers adjacents, lire la structure locale — est plus rustique et souvent plus efficace, parce que l'arborescence porte déjà une partie de la relation sans que personne ait eu à la déclarer.

Un dispositif construit sur la seule recherche donne donc des réponses exactes sur ce qu'on a su demander, et muettes sur ce qui se trouvait juste à côté.

Pourquoi c'est important

Cela explique un échec courant : brancher un modèle sur un dépôt Git avec un index vectoriel et constater que les réponses restent superficielles. Le problème n'est pas la qualité de la recherche, c'est qu'une seule des deux capacités est présente.

Cela donne aussi un critère d'évaluation qui ne porte pas sur le premier résultat. Un dispositif d'interrogation ne se juge pas sur la pertinence du fragment qu'il ramène, mais sur ce qu'il sait faire ensuite : atteindre ce que celui qui pose la question ignorait devoir demander.

Nuances et limites

La distinction n'est pas une hiérarchie. Sur un corpus petit ou très homogène, retrouver suffit : les voisins sont dans le même fichier, et le déplacement se fait à la lecture.

Et circuler ne remplace jamais retrouver. Un graphe sans point d'entrée ne sert à rien ; c'est la recherche qui fournit le nœud de départ, et une mauvaise entrée fait explorer un voisinage sans rapport avec la question.

Les deux capacités ne vieillissent pas de la même façon, enfin. Une arborescence de fichiers est toujours à jour puisqu'elle est le dépôt ; un graphe de relations déclarées est un artefact de plus, qui diverge dès que le code bouge sans que le graphe soit reconstruit.

Questions ouvertes

• Qu'est-ce qui détermine le point d'arrêt d'un parcours de voisinage — combien de sauts avant que le contexte ramené cesse d'éclairer la question et commence à la noyer ?
• Sur un dépôt qui change tous les jours, à quel moment reconstruire un graphe de relations coûte-t-il plus que ce qu'il fait gagner face à un simple parcours de répertoires ?