La recherche agentique est un problème d’exécution

Un article arXiv du 14 mai a testé grep et la recherche vectorielle dans Chronos, Claude Code, Codex et Gemini CLI sur 116 questions LongMemEval. Dans la première expérience de l’article, grep intégré directement au fil de conversation a battu la recherche vectorielle intégrée de la même manière pour chaque paire cadre-modèle. Mais le résultat le plus intéressant était ailleurs, et plus étrange : l’environnement d’exécution modifiait presque autant le résultat que le moteur de recherche lui-même.¹

La qualité de la recherche agentique ne se résume pas à « grep contre vectoriel ». Elle se joue dans tout l’environnement d’exécution : prompt, surface d’outils, ergonomie du shell, formatage des résultats, pression sur le contexte, mode de livraison, comportement de relance et capacité du modèle à refermer la boucle d’outils.

TL;DR

Sen, Kasturi, Lumer, Gulati et Subbiah ont comparé la recherche lexicale et la recherche vectorielle dans un cadre d’agent personnalisé nommé Chronos, ainsi que dans trois cadres CLI natifs de fournisseurs : Claude Code, Codex et Gemini CLI.¹ L’étude utilise un sous-ensemble LongMemEval-S de 116 questions et teste à la fois des résultats d’outils injectés directement dans le fil de conversation et des résultats transmis par fichiers.¹ Dans l’expérience 1, grep intégré au fil surpasse la recherche vectorielle intégrée au fil pour chaque paire cadre-modèle, y compris Codex CLI avec GPT-5.4, à 93,1 % pour grep contre 75,9 % pour le vectoriel.¹ L’article ne prouve pas que grep bat la recherche vectorielle en général ; les auteurs limitent explicitement leur conclusion au cadre de questions-réponses conversationnelles à mémoire longue, où les réponses dépendent souvent de passages littéraux.¹ Pour les concepteurs d’agents, la conclusion utile est plus nette : méthode de récupération, environnement d’exécution de l’agent et mode de livraison des résultats forment un seul système. Il faut les évaluer ensemble.

Points clés

• Pour les concepteurs d’agents : gardez grep comme point de référence sérieux. Les résultats de l’article rendent l’approche « vectoriel par défaut » paresseuse pour les questions-réponses à mémoire longue sur historique de conversation, surtout quand les noms, les dates et les faits utilisateur comptent.¹
• Pour les utilisateurs de Codex et Claude Code : ne traitez pas une CLI de fournisseur comme une enveloppe neutre autour d’une primitive de recherche. L’article rapporte de forts écarts au niveau du cadre d’agent, avec les mêmes données conversationnelles sous-jacentes.¹
• Pour les équipes RAG : documentez le mode de livraison, pas seulement le moteur de récupération. Les résultats intégrés au fil et les résultats par fichiers ont produit des comportements différents, car la livraison par fichier ajoute une tâche d’utilisation d’outil.¹
• Pour les migrations : préservez les comportements d’exécution qui rendent la recherche fiable. Une migration de Claude Code vers Codex doit tester la récupération, la forme des transcriptions et les boucles de vérification avant de déclarer la parité.
• Pour les systèmes riches en citations : les citations finales ne racontent pas toute l’histoire de la preuve. Un autre article sur Agentic GraphRAG soutient que la provenance peut dépendre d’un contexte de graphe visité mais non cité, et pas seulement des nœuds cités.⁴

Qu’a réellement testé l’article sur grep ?

L’article pose une question pratique : lorsqu’un agent LLM doit répondre à des questions sur un long historique de conversation, quelle part de la récupération dépend de la méthode de recherche, et quelle part dépend du système agentique qui l’entoure ?¹

Les auteurs comparent deux familles de récupération :

Ils testent ces moteurs de récupération dans deux classes d’environnement d’exécution :

Ils font aussi varier la façon dont les résultats arrivent au modèle. La livraison intégrée au fil insère les résultats de recherche directement dans la conversation. La livraison programmatique écrit les résultats dans des fichiers, puis demande au modèle de les trouver, de les ouvrir et de les intégrer.¹ Cela ressemble à un détail d’implémentation. Les données montrent que cela fait partie de la tâche.

Pourquoi grep gagne-t-il ici ?

La tâche mesurée favorise la récupération littérale. LongMemEval pose des questions sur de longues conversations multi-sessions. Beaucoup de réponses dépendent de noms, d’expressions temporelles, de faits personnels ou d’énoncés antérieurs exacts. Dans ce contexte, un outil lexical à haute précision peut battre un moteur de récupération sémantique, car la réponse se trouve souvent derrière une chaîne distinctive.¹

Le tableau 1 de l’article montre clairement le motif :

Ce tableau ne dit pas : « supprimez votre base vectorielle ». L’article lui-même met en garde contre cette lecture. Les auteurs expliquent que leur conclusion concerne les questions-réponses conversationnelles à mémoire longue et que la récupération dense ou hybride peut se comporter autrement dans la synthèse scientifique, les documents visuels ou la sémantique du code.¹

La meilleure lecture est la suivante : la recherche exacte mérite une place de premier rang dans tout environnement d’exécution agentique sérieux. Si votre agent peut chercher dans le système de fichiers, lire des logs, inspecter d’anciennes transcriptions ou retrouver un fait utilisateur littéral, la recherche lexicale peut être l’outil le moins coûteux et le plus riche en signal.

L’environnement d’exécution a changé le résultat

La ligne la plus utile de l’article n’est pas « grep a gagné ». C’est l’idée qu’un changement de cadre d’agent peut déplacer le plafond à une échelle comparable à un changement de moteur de récupération.¹

Un exemple : Claude Opus 4.6 avec grep intégré au fil atteint 93,1 % sous Chronos et 76,7 % sous Claude Code.¹ Même famille de modèles, même sous-ensemble de benchmark, environnement d’exécution différent. Autre exemple : Codex CLI avec GPT-5.4 atteint 93,1 % avec grep intégré au fil, mais tombe à 55,2 % quand les résultats grep passent par le chemin programmatique de livraison par fichiers ; le vectoriel programmatique arrive à 67,2 %.¹

Ce n’est pas seulement un résultat de récupération. C’est un résultat d’exécution.

Le modèle ne devait pas seulement trouver des preuves. Il devait comprendre le contrat de l’outil, choisir des termes de recherche, interpréter stdout, décider quand relancer, lire des fichiers quand les résultats n’étaient pas intégrés au fil, puis intégrer les preuves dans une réponse. Chacune de ces étapes appartient à l’environnement d’exécution de l’agent. Si l’une d’elles devient fragile, même un bon moteur de récupération peut produire une réponse faible.

Pourquoi la livraison par fichiers teste l’utilisation des outils

La livraison par fichiers a un intérêt évident. Elle peut réduire la pression sur le contexte en gardant de grands résultats de recherche hors de la transcription immédiate jusqu’à ce que le modèle demande à les lire. Cela devrait aider quand les sorties vectorielles intégrées au fil encombrent la fenêtre.

L’article montre le compromis. Le vectoriel programmatique bat grep programmatique sur plusieurs lignes, ce qui soutient l’argument de la pression sur le contexte.¹ Mais la ligne Codex/GPT-5.4 montre l’autre face : la livraison par fichiers peut transformer une récupération peu coûteuse en flux de travail multi-étapes. L’agent doit trouver l’artefact, l’ouvrir, en extraire les passages utiles et relancer quand la première lecture ne suffit pas.¹

Autrement dit, la livraison programmatique échange de la bande passante de contexte contre une compétence de boucle d’outils. Cet échange ne paie que si l’environnement d’exécution referme la boucle de manière fiable.

C’est crucial dans le travail réel. Un agent local n’échoue pas seulement parce que l’index est mauvais. Il échoue parce que stdout a été mal découpé, parce que le chemin du fichier de résultats était facile à manquer, parce qu’une commande a renvoyé trop de bruit, parce que le prompt cadrait mal la tâche ou parce que le modèle s’est arrêté une lecture trop tôt.

Ce que cela signifie pour une migration vers Codex

Ma propre migration de Claude Code vers Codex s’est concentrée sur le déplacement des contrats opérationnels plutôt que sur la copie d’une arborescence de fichiers. Cet article renforce ce choix.

Si la qualité de recherche dépend de l’environnement d’exécution, alors la qualité d’une migration dépend de plus que « Codex a-t-il un outil de recherche ? » Une migration doit préserver les comportements qui rendent la recherche utile :

• l’agent sait quand utiliser la recherche exacte avant la recherche sémantique ;
• la sortie des commandes reste assez petite pour être lue ;
• les chemins de preuve survivent jusqu’à la réponse finale ;
• les artefacts livrés par fichiers sont faciles à trouver et à inspecter ;
• les recherches ratées déclenchent de meilleures requêtes au lieu de réponses prématurées ;
• l’écriture publique utilise la vérification des sources, pas une récupération plausible.

Cette liste est volontairement publique et générique. Elle ne révèle ni points d’accroche privés, ni prompts privés, ni détails internes de flux de travail local. L’enjeu est le contrat opérationnel : obliger l’agent à prouver ce qu’il a trouvé, pas seulement à paraître sûr de sa recherche.

L’article explique aussi pourquoi une migration peut sembler moins bonne même lorsque toutes les fonctionnalités visibles existent. Claude Code et Codex peuvent tous deux exposer des outils shell. Tous deux peuvent lire des fichiers. Tous deux peuvent chercher. Mais si le formatage des transcriptions, la gestion des résultats par fichiers, le comportement d’arrêt ou les schémas de relance diffèrent, la même primitive de recherche peut produire un travail différent.

Les trois autres signaux vont dans le même sens

Trois autres articles du 14 mai issus de la même veille indiquent le même motif général : la qualité des agents se déplace hors des appels de modèle isolés et vers l’architecture d’exécution.

APWA traite le travail agentique hautement parallèle comme un problème d’exécution distribuée. Les auteurs décomposent les flux de travail en sous-problèmes non interférents que des ressources indépendantes peuvent traiter sans communication croisée, puis évaluent la montée en charge sur des tâches plus grandes où les systèmes antérieurs échouent.² C’est une thèse sur l’environnement d’exécution, pas une astuce de prompt.

MeMo traite la mémoire comme un composant modèle séparé. Il garde le LLM exécutif fixe, encode de nouvelles connaissances dans un modèle mémoire dédié et rapporte une résistance au bruit de récupération ainsi qu’une compatibilité prête à l’emploi avec des LLM open source et propriétaires.³ C’est une thèse sur l’architecture mémoire, pas sur un contexte plus long.

L’article de provenance sur Agentic GraphRAG soutient que les citations finales peuvent être nécessaires mais insuffisantes. Des réponses exactes peuvent dépendre du contexte de parcours non cité, de la structure du graphe et d’entités visitées mais non citées.⁴ C’est une thèse sur la provenance, pas sur le format des citations.

Mettez ces travaux à côté de l’article sur grep, et une forme apparaît :

Le thème commun : l’enveloppe est le produit. L’environnement d’exécution décide si la capacité du modèle devient un travail utile.

Ce que je changerais dans une pile agentique

Commencez par un point de référence simple. Donnez à l’agent une recherche exacte sur les fichiers, logs, transcriptions ou notes qui comptent. Mesurez cela avant d’ajouter de la récupération sémantique.

Testez ensuite quatre combinaisons, pas deux :

Enregistrez la transcription d’outils pour chaque exécution. La réponse finale ne suffit pas. Vous devez savoir si l’agent a cherché les bons termes, ouvert le bon fichier, remarqué le bon passage, relancé après un échec et cité les preuves qui soutenaient réellement la réponse.

Ajoutez la recherche vectorielle quand le domaine exige de retrouver des paraphrases, de faire une synthèse conceptuelle ou de travailler avec des preuves non littérales. Gardez la recherche exacte quand le domaine contient des noms, des ID, des noms de fichiers, des dates, des lignes de log, des sorties de commande, des préférences utilisateur ou des instructions antérieures. Utilisez un routage hybride quand la tâche mélange les deux.

Pour l’écriture publique, rendez le chemin de récupération plus strict. Un article cité devrait transporter les URL des sources, l’alignement entre affirmation et source, ainsi qu’un relevé de ce qui reste non vérifié. Si le système a utilisé un graphe, une couche mémoire ou un chemin intermédiaire de récupération, les citations finales ne devraient pas être la seule trace. L’article sur la provenance le montre pour Agentic GraphRAG, mais la leçon produit est plus générale : la preuve doit expliquer le chemin, pas seulement la destination.⁴

La meilleure question de benchmark

La question faible est :

Quel moteur de récupération est le meilleur ?

La question plus solide est :

Dans cet environnement d’exécution, avec ce modèle, ce corpus, ce mode de livraison et cette politique de relance, quel comportement de recherche produit des réponses vérifiées ?

Cette question prend plus de temps. Elle vous apprend aussi quelque chose d’exploitable.

Le travail agentique attire sans cesse vers des affirmations de composants : meilleur modèle, meilleur moteur de récupération, meilleur prompt, meilleure mémoire, meilleur parallélisme. La réalité opérationnelle pousse dans l’autre sens. Un composant ne compte qu’une fois transformé par l’environnement d’exécution en chemin fiable, de la tâche à la preuve puis à l’action.

C’est cette partie qui mérite d’être migrée.

FAQ

Cet article prouve-t-il que grep bat la recherche vectorielle ?

Non. Les auteurs limitent explicitement le résultat au cadre étudié de questions-réponses conversationnelles à mémoire longue. Ils indiquent que la récupération dense et le routage hybride peuvent se comporter différemment dans les domaines où les preuves sont rarement littérales, notamment la synthèse scientifique, les documents très visuels et la sémantique du code.¹

Pourquoi grep a-t-il obtenu de si bons résultats dans l’expérience ?

Les questions LongMemEval dépendent souvent de passages littéraux issus de conversations passées : noms, dates, faits personnels et formulations exactes. Grep récompense les motifs à haute précision quand l’agent peut deviner un terme distinctif.¹

Pourquoi le cadre d’agent a-t-il compté ?

L’environnement d’exécution contrôle la forme du prompt, les descriptions d’outils, le formatage des transcriptions, le comportement du shell, la construction du contexte, la livraison des résultats et les critères d’arrêt. L’article rapporte de forts écarts de précision entre Chronos, Claude Code, Codex CLI et Gemini CLI, même lorsque les données conversationnelles sous-jacentes restent identiques.¹

Que devraient faire les utilisateurs de Codex avec cela ?

Gardez la recherche exacte comme point de référence, inspectez les transcriptions d’outils et testez la livraison intégrée au fil contre la livraison par fichiers avant de supposer qu’une méthode de récupération est meilleure. La ligne Codex de l’article est utile, mais elle reste un seul cadre de benchmark, un seul type de corpus et une image incomplète de tous les fournisseurs à plus grande échelle.¹

Quel est le lien avec les citations RAG ?

L’article de provenance sur Agentic GraphRAG soutient que les citations finales peuvent étayer une réponse tout en omettant du contexte de récupération qui l’a influencée. Pour les systèmes agentiques, la qualité des citations devrait inclure la provenance du chemin suivi, pas seulement la liste finale des sources citées.⁴

Que doit préserver une migration de Claude Code vers Codex ?

Préservez le comportement opérationnel : quand l’agent cherche, comment il limite la sortie, comment il ouvre les preuves, comment il relance, comment il enregistre les chemins de source et comment il refuse les affirmations non étayées. Ne présumez pas la parité simplement parce que les deux environnements exposent un shell et une commande de recherche.

Références