{"notes":[{"id":"retrieval-augmented-generation/deep-agentic-search","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Deep Agentic Search","subtitle":"Le jeu du téléphone","author":"Z. Yuan","paperDate":"2026-08-02","publishedOn":"2026-09-27","paperTitle":"Deep Agentic Search for Repository-Level Code Question Answering: An Empirical Study","paperUrl":"https://arxiv.org/abs/2608.01507","bibliography":{"title":"Deep Agentic Search for Repository-Level Code Question Answering: An Empirical Study","authors":["Amirkia Rafiei Oskooei","Bora Ilci","Alperen Kayim","Mehmet Egemen Uzun","Berat Can","Kaan Emre Kara","Ozan Orhan","Mehmet S. Aktas"],"url":"https://arxiv.org/abs/2608.01507","pdfUrl":"https://arxiv.org/pdf/2608.01507v1","codeUrl":null,"preprint":{"id":"2608.01507","submittedOn":"2026-08-02","url":"https://arxiv.org/abs/2608.01507"},"publication":null,"citation":"@misc{retrievalaugmentedgenerationdeepagenticsearch2026,\n  title = {{Deep Agentic Search for Repository-Level Code Question Answering: An Empirical Study}},\n  author = {Amirkia Rafiei Oskooei and Bora Ilci and Alperen Kayim and Mehmet Egemen Uzun and Berat Can and Kaan Emre Kara and Ozan Orhan and Mehmet S. Aktas},\n  year = {2026},\n  eprint = {2608.01507},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2608.01507}\n}\n","citationPath":"/content/papers/citations/retrieval-augmented-generation/deep-agentic-search.1f8bfd9bac55.bib"},"thumbnail":{"src":"/content/papers/assets/61ecd2fcf8409a060dc66b99123841b7e1bceff328c5f1ee011397bb73773c74.png","width":944,"height":427},"locale":"fr","path":"/content/papers/fr/retrieval-augmented-generation/deep-agentic-search.dd140c517f6d.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"deux-architectures","text":"Deux architectures","depth":3},{"id":"détails-dimplémentation","text":"Détails d'implémentation","depth":3},{"id":"modèles-données-et-notation","text":"Modèles, données et notation","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"précision--semantic-gagne-avec-chaque-modèle","text":"Précision : Semantic gagne avec chaque modèle","depth":3},{"id":"coût--la-dépense-supplémentaire-naméliore-pas-les-scores","text":"Coût : la dépense supplémentaire n'améliore pas les scores","depth":3},{"id":"lessentiel-du-travail-de-deep-reste-hors-de-la-vue-du-principal","text":"L'essentiel du travail de Deep reste hors de la vue du principal","depth":3},{"id":"analyse-des-échecs--le-passage-de-relais-est-fragile","text":"Analyse des échecs : le passage de relais est fragile","depth":3},{"id":"le-périmètre-défini-par-les-auteurs","text":"Le périmètre défini par les auteurs","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"Avant de répondre à « Où cette fonctionnalité est-elle implémentée ? », les agents de programmation actuels envoient souvent un petit assistant en reconnaissance.\n\nL'agent principal ne parcourt pas lui-même les fichiers. Il confie l'exploration à un **sous-agent** : lister les dossiers, lancer grep, lire des fichiers et poursuivre la piste. Ce sous-agent travaille dans un contexte indépendant, puis renvoie seulement ses conclusions organisées. Le contexte principal reste propre, avec un résultat concis.\n\nCette architecture porte le nom de **Deep Agentic Search**, parfois décrite comme une recherche grep exécutée par un sous-agent. L'article indique que des agents comme Claude Code, Codex et Antigravity l'ont rapidement adoptée.\n\nMais répond-elle vraiment plus juste ?\n\nCette étude empirique de l'université technique Yildiz, à Istanbul, et d'Intellica, entreprise d'informatique décisionnelle, a été publiée sur arXiv en août 2026. Les auteurs la comparent sur les mêmes questions de code à une approche plus classique : construire à l'avance un index vectoriel et laisser l'agent l'interroger directement.\n\nLe résultat surprend : 65,2 % de réussite pour l'approche classique, contre 46,2 % pour Deep Agentic Search, qui coûte en outre plus de deux fois plus cher par réponse réussie.\n\n\n> [!TIP]\n> \n> **Pourquoi confier la recherche à un sous-agent ?**\n> \n> Cette conception vise la **pollution du contexte**, souvent appelée *context rot*. À force de chercher et de lire, l'agent accumule du code et des résultats sans rapport, ce qui peut dégrader ses décisions.\n> \n> Confier cette exploration désordonnée à un sous-agent et ne transmettre qu'une synthèse au principal est considéré comme une bonne pratique d'**ingénierie du contexte**. L'article vérifie son effet concret sur la précision des réponses.\n\n\n## Définir le problème\n\nLes auteurs posent trois questions :\n\n1. **Précision** : quelle approche répond le mieux aux questions portant sur tout un dépôt ?\n2. **Coût** : combien coûte chacune, et la dépense supplémentaire améliore-t-elle les réponses ?\n3. **Comportements et échecs** : comment fonctionnent-elles et comment échouent-elles ?\n\n## Résoudre le problème\n\n### Deux architectures\n\n[![Deux paradigmes : en haut, un agent ReAct récupère des fragments dans un index vectoriel préconstruit ; en bas, Deep Agent délègue sans index l'exploration à un sous-agent doté d'un contexte indépendant](/content/papers/assets/44afeaa4b2a8e82e998b7d93f70c43ca555a0c6588ac386081af2aedc5612536.png)](/content/papers/assets/44afeaa4b2a8e82e998b7d93f70c43ca555a0c6588ac386081af2aedc5612536.png)\n\n*Fig. 1 de l'article, extraite de la [**page 2 du PDF v1**](https://arxiv.org/pdf/2608.01507v1#page=2). (a) Recherche sémantique avec un agent ReAct ; (b) Deep Agentic Search avec un Deep Agent.*\n\n**En haut, (a) : Semantic search.** Le dépôt est découpé, encodé en vecteurs et stocké à l'avance dans une base vectorielle. À réception de la question, l'agent ReAct produit une requête vectorielle, récupère les fragments de code pertinents, puis rédige lui-même la réponse.\n\n**En bas, (b) : Deep Agentic search.** Aucun index. Deep Agent reçoit la question et envoie un Explorer Subagent dans le dépôt. Dans la figure, celui-ci dit « Not here » dans un premier dossier, puis « Found it! » dans un autre. Il renvoie ses résultats au principal, qui répond.\n\nLes flèches en pointillés des deux côtés portent la mention « Waiting » : pendant l'attente, l'agent principal n'a pas de vue directe sur ce que fait réellement le sous-agent.\n\n### Détails d'implémentation\n\nLes deux architectures sont construites avec LangChain.\n\n**Semantic search** utilise l'agent ReAct de LangChain avec seulement les trois outils du protocole SWE-QA d'origine : consulter la structure du dépôt, effectuer une recherche vectorielle et lire un fichier. Il n'a ni shell, ni écriture de fichiers, ni outil de planification.\n\nLa configuration de l'index figure en annexe :\n\n- Découpage adapté au code avec `RecursiveCharacterTextSplitter`, par blocs de 500 tokens avec 50 tokens de recouvrement.\n- Embeddings OpenAI `text-embedding-3-small`, de dimension 1 536.\n- Une base Chroma par dépôt, similarité cosinus et dix blocs récupérés par recherche.\n\n**Deep Agentic search** utilise le framework Deep Agents de LangChain avec ses outils par défaut : liste de tâches `write_todos`, délégation `task`, `grep`, `ls`, `glob` et lecture de fichiers. Principal et sous-agent utilisent le même modèle.\n\n\n> [!NOTE]\n> \n> **La comparaison est-elle équitable avec des outils différents ?**\n> \n> Les auteurs répondent explicitement : ces outils font partie de la définition des deux paradigmes. Ajouter planification et sous-agents à ReAct le transforme en Deep Agent. Retirer ces outils à Deep Agent et lui donner un index vectoriel le ramène à ReAct.\n> \n> La comparaison porte donc sur deux paradigmes complets. Pour isoler un seul facteur, il faudrait une autre expérience d'ablation. Ici, tout le reste est fixé : 15 dépôts, 720 questions, quatre modèles, le même juge et la même grille. Chaque modèle est comparé à lui-même.\n\n\nIl faut donc lire les résultats au niveau des architectures complètes. Semantic peut aussi lire les fichiers et consulter leur structure ; Deep se distingue notamment par la planification et la délégation à des sous-agents. Réduire la comparaison à « vecteurs contre grep » ferait perdre ces différences.\n\n### Modèles, données et notation\n\n**Quatre modèles** sont évalués : Gemini 2.5 Flash, Gemini 2.5 Pro, Gemini 3 Flash et Qwen3-235B, modèle à poids ouverts d'un autre fournisseur. Croisés avec deux architectures, ils donnent huit conditions. La température est fixée à 0, avec 900 secondes et 80 étapes au maximum par question. Tout dépassement compte comme un échec, sans nouvelle exécution.\n\n**Les données viennent de SWE-QA**, une évaluation de questions-réponses à l'échelle du dépôt. Les auteurs utilisent 15 dépôts Python avec 48 questions chacun, soit 720 questions. Douze dépôts viennent de SWE-bench et trois du plus récent SWE-bench-Live. Leur taille va d'environ 13 000 à plus de 800 000 lignes. Les questions se répartissent à peu près également entre What, Why, Where et How.\n\n**Le juge est Claude Sonnet 4.6**, d'un fournisseur différent de tous les modèles testés. Il note les cinq dimensions de SWE-QA : correction, exhaustivité, pertinence, clarté et raisonnement, pour un score total de 0 à 100. À partir de 70, le résultat est Pass ; de 50 à moins de 70, Partial ; sous 50, Fail.\n\nPour vérifier ce juge, trois ingénieurs logiciels ayant au moins deux ans d'expérience et ne faisant pas partie des auteurs notent à l'aveugle 800 réponses. Leur accord inter-évaluateurs atteint un κ de Fleiss de 0,81. L'accord entre leur majorité et le juge LLM donne un κ de Cohen de 0,74, avec 5,2 points d'écart absolu moyen. L'accord est un peu plus faible pour Deep — κ de 0,69, contre 0,78 pour Semantic —, ce que les auteurs relient à des réponses plus longues et complexes.\n\n## Discussion\n\n### Précision : Semantic gagne avec chaque modèle\n\n| Modèle | Pass (S) | Pass (D) | Écart | Par réponse réussie (S) | Par réponse réussie (D) |\n| --- | ---: | ---: | ---: | ---: | ---: |\n| Gemini 2.5 Flash | 48,4 % | 42,8 % | 5,6 | $0.213 | $0.436 |\n| Gemini 2.5 Pro | 54,2 % | 44,2 % | 10,0 | $1.048 | $1.526 |\n| Gemini 3 Flash | 89,3 % | 39,7 % | 49,6 | $0.179 | $0.858 |\n| Qwen3-235B | 68,8 % | 58,2 % | 10,6 | $0.012 | $0.291 |\n\n*D'après les Tables 3 et 4. S désigne Semantic, D Deep ; les écarts sont en points de pourcentage. Les deux dernières colonnes donnent le coût par réponse réussie en dollars américains, calculé à partir des tokens mesurés et d'une grille tarifaire unique retenue par l'article.*\n\nLe taux de Pass est supérieur pour Semantic avec les quatre modèles. Leurs moyennes sont :\n\n$$\n\\frac{48.4+54.2+89.3+68.8}{4}\\approx65.2\\%,\\qquad\n\\frac{42.8+44.2+39.7+58.2}{4}\\approx46.2\\%\n$$\n\nC'est l'origine des 65,2 % contre 46,2 % du résumé. Les taux de Fail valent 21,9 % contre 34,4 % : Deep produit aussi davantage d'échecs complets, au-delà d'un simple déplacement de Pass vers Partial.\n\nL'ampleur de l'écart varie pourtant beaucoup. Gemini 2.5 Flash ne perd que 5,6 points, Gemini 3 Flash en perd 49,6. Les tests appariés des quatre modèles restent significatifs après correction des comparaisons multiples, mais la taille d'effet, mesurée par le δ de Cliff, n'est que d'environ 0,14 pour les deux Gemini 2.5 et 0,24 pour Qwen3-235B. Seul le 0,76 de Gemini 3 Flash correspond à un grand effet. Les auteurs restent mesurés : la direction est constante, l'effet modeste sur Gemini 2.5 et grand uniquement sur Gemini 3 Flash.\n\nLe seuil Pass de 70 favoriserait-il Semantic par hasard ? Les auteurs le font varier de 50 à 90. Semantic reste devant pour chaque modèle et chaque seuil, avec au minimum 3,8 points d'écart.\n\n### Coût : la dépense supplémentaire n'améliore pas les scores\n\nDeep consomme davantage de tokens d'entrée avec tous les modèles. Le plus grand écart concerne Qwen3-235B : environ 34 000 tokens par question pour Semantic, contre 761 000 pour Deep, soit 22 fois plus.\n\nLe coût agrégé par réponse réussie pour les quatre modèles atteint 0,32 dollar contre 0,74 : Deep coûte environ 2,3 fois plus cher.\n\nLes auteurs étudient aussi le lien entre score et dépense par question. Pour les tokens d'entrée comme pour les appels d'outils, les pentes ajustées sont plates ou descendantes dans les deux architectures : **les dépenses plus élevées ne s'accompagnent pas de meilleurs scores**. Ils rappellent qu'il s'agit d'une corrélation : les questions difficiles demandent aussi plus d'exploration et entraînent plus souvent des erreurs.\n\nLa latence n'a pas de gagnant constant. Deep est plus rapide avec les deux Gemini 2.5 ; Semantic l'est avec Gemini 3 Flash et Qwen3-235B. Les auteurs la jugent trop dépendante de l'environnement d'exécution pour en tirer une conclusion.\n\nLe surcoût de Deep augmente-t-il avec la taille du dépôt ? Les 15 dépôts ne montrent aucun lien significatif, mais les auteurs reconnaissent que l'échantillon est trop petit pour trancher.\n\n### L'essentiel du travail de Deep reste hors de la vue du principal\n\nEn incluant les sous-agents, la plupart des outils utilisés par Deep restent ordinaires : lecture de fichiers, 41,6 %, puis recherche textuelle, 29,1 %. Viennent ensuite listes de tâches, listes de dossiers et délégations.\n\nMais chaque délégation ouvre toute une exploration. Sur 2 878 exécutions de Deep, 2 395 délèguent au moins une fois. Chaque exécution délègue 2,1 fois en moyenne, et chaque sous-agent effectue environ dix appels. Au total, **68,8 % des appels d'outils se déroulent dans les sous-agents**, sans visibilité directe du principal.\n\nGemini 3 Flash illustre bien l'écart : 8,6 appels d'outils par question en moyenne avec Semantic, contre 44,6 avec Deep.\n\n### Analyse des échecs : le passage de relais est fragile\n\nLes auteurs classent toutes les traces Fail selon deux axes indépendants : le **mécanisme d'échec**, c'est-à-dire sa cause, et le **symptôme de la réponse**, c'est-à-dire la forme de l'erreur. Claude Sonnet 4.6 réalise cette classification. Deux auteurs annotent manuellement 400 traces pour la vérifier : leur accord atteint κ = 0,78 pour les mécanismes et 0,86 pour les symptômes. Leur consensus et la classification automatique donnent 0,82.\n\n[![Répartition des mécanismes d'échec : Semantic échoue surtout à récupérer ou localiser les preuves ; Deep Agentic échoue surtout dans la coordination](/content/papers/assets/61ecd2fcf8409a060dc66b99123841b7e1bceff328c5f1ee011397bb73773c74.png)](/content/papers/assets/61ecd2fcf8409a060dc66b99123841b7e1bceff328c5f1ee011397bb73773c74.png)\n\n*Fig. 19 de l'article, extraite de la [**page 27 du PDF v1**](https://arxiv.org/pdf/2608.01507v1#page=27). Semantic en bleu à gauche, Deep Agentic en orange à droite ; les pourcentages sont calculés dans les échecs de chaque architecture.*\n\nLes 1 621 échecs se répartissent en 631 pour Semantic et 990 pour Deep. Leurs modes d'échec sont très différents.\n\n**Semantic échoue surtout à trouver.** En bas à gauche, les erreurs de recherche ou de localisation représentent 53,6 % : malgré 12,6 appels d'outils en moyenne, le bon fichier reste introuvable. Dans 18,1 % des cas, l'agent répond avec assurance après avoir trop peu lu ; dans 17,1 %, il trouve le bon fichier mais le comprend mal.\n\n**Deep échoue surtout dans le passage de relais.** La barre orange du haut, **rupture de coordination**, représente 41,8 % : l'échange entre principal et sous-agent ne produit pas de résultat exploitable ou ne permet pas de l'intégrer. Ce mécanisme exige des sous-agents ; il est donc absent de Semantic.\n\nLe plus gênant est son caractère généralement **silencieux**. Dans 91 % des ruptures de coordination, l'agent livre tout de même une réponse fluide et assurée, sans signe visible d'incident.\n\nParmi les échecs de Deep, 13,5 % correspondent aussi à des boucles dont il ne sort pas. Au total, 24,2 % de ses échecs ne produisent aucune réponse, contre 12,7 % pour Semantic.\n\nLes auteurs concluent que Deep Agentic Search ajoute **un nouveau mode d'échec**, particulièrement difficile à détecter dans la sortie, aux difficultés déjà présentes.\n\n### Le périmètre défini par les auteurs\n\nL'article précise soigneusement son domaine d'application.\n\n**Premièrement, chaque question est indépendante, unique et en lecture seule.** L'intérêt des sous-agents est notamment de préserver le contexte principal dans de longues sessions portant sur plusieurs tâches. Ici, chaque question ouvre une nouvelle conversation : cet avantage n'a pas l'occasion de se traduire en précision. Les auteurs disent explicitement que leur protocole ne permet pas de savoir si l'équilibre changerait sur de longues sessions.\n\n**Deuxièmement, Semantic suppose une indexation préalable possible.** Un système de fichiers trop vaste, trop changeant ou trop désordonné peut imposer une exploration en direct. Un index reflète un instant précis du dépôt. Si les branches évoluent constamment, il faut l'actualiser continuellement sous peine de réponses subtilement périmées. Encoder les 15 dépôts coûte moins d'un dollar, selon les auteurs ; le vrai coût réside dans la détection des changements, l'invalidation et la reconstruction. Les instantanés fixes de l'expérience constituent justement un cas favorable à l'indexation.\n\n**Troisièmement, chaque paradigme n'utilise qu'un harness.** Prompt système, synthèse des sous-agents et budget d'étapes influencent tous les résultats. Les auteurs ne comparent pas d'autres frameworks Deep Agent et limitent les écarts mesurés aux implémentations étudiées.\n\nEnfin, l'évaluation se limite à SWE-QA, au Python et à quatre modèles. Ces dépôts populaires ont probablement figuré dans les données d'entraînement des modèles.\n\n## Conclusion\n\nDans le cadre de cet article — **dépôts Python fixes et indexables, avec une question indépendante en lecture seule à chaque fois** :\n\n1. **Semantic search est plus précis.** Son taux de Pass dépasse celui de Deep avec les quatre modèles : 65,2 % contre 46,2 % en moyenne, pour des écarts allant de 5,6 à 49,6 points.\n2. **Semantic search coûte aussi moins cher.** Le coût moyen par réponse réussie est de 0,32 contre 0,74 dollar. Les tokens supplémentaires de Deep ne lui donnent pas de meilleurs scores.\n3. **Le principal échec de Deep vient des relais.** La coordination entre principal et sous-agent explique 41,8 % de ses échecs. Dans 91 % de ces cas, la sortie reste fluide, assurée et fausse.\n\nLe conseil des auteurs est pratique : pour des questions en lecture seule sur un dépôt indexable, commencer par un agent doté d'une recherche indexée. Réserver l'orchestration plus lourde de sous-agents aux besoins que la précision sur une question isolée ne mesure pas : préserver le contexte d'une longue session, explorer un environnement non indexable, écrire ou exécuter du code. Une suite raisonnable serait un routeur : utiliser normalement l'index sémantique économique, et déléguer seulement quand le besoin apparaît.\n\nDéléguer nettoie effectivement le contexte du principal. Mais quand la conclusion revient, il n'a pas davantage de visibilité sur sa justesse.\n","imageSizes":{"/content/papers/assets/44afeaa4b2a8e82e998b7d93f70c43ca555a0c6588ac386081af2aedc5612536.png":{"width":1258,"height":1083},"/content/papers/assets/61ecd2fcf8409a060dc66b99123841b7e1bceff328c5f1ee011397bb73773c74.png":{"width":944,"height":427}}}