Un auteur de Habr a monté une recherche agentique sur des modèles open source et testé où elle casse

Habr a publié l'analyse d'une expérience que beaucoup d'équipes reproduisent aujourd'hui : une recherche agentique sur des modèles ouverts, à la place d'un service clé en main du type Deep Research. L'auteur précise d'emblée sa motivation : économiser sur l'abonnement ne l'intéresse pas. Il veut déterminer le stack technologique minimal dont un agent a besoin pour trouver une information précise, citer une source vérifiable et ne pas inventer de lien. L'annonce ne contient aucun chiffre. Le coût des exécutions et les défaillances concrètes sont renvoyés au texte complet ; nous nous appuyons donc ici uniquement sur la problématique annoncée.

Quel problème l'auteur cherche à résoudre

Le titre promet trois choses : qui l'agent a trouvé, combien il a dépensé et où tout a cassé. C'est un bon cadre de test. Une recherche agentique se met facilement en scène sur un exemple réussi, mais se mesure difficilement de façon honnête. La tâche « retrouver une personne ou un fait précis » n'a pas été choisie au hasard. Elle admet une réponse de référence, ce qui permet de distinguer une vraie trouvaille d'une invention plausible.

L'exigence d'un « contrôle sur les sources » mérite une mention à part. Les agents commerciaux parcourent le web seuls, et l'utilisateur ne voit que le rapport final. Dans un système monté soi-même, on peut restreindre les domaines, journaliser chaque requête et conserver la page d'où provient la citation.

De quoi se compose habituellement un tel stack

Dans son annonce, l'auteur ne détaille pas les composants. Ce qui suit est donc le schéma général utilisé pour construire ce type de systèmes, et non la description de sa propre architecture.

• Couche de recherche : un métamoteur ou une API de résultats qui renvoie une liste d'URL.
• Chargeur de pages : récupère le HTML, le nettoie pour obtenir un texte lisible et gère le JavaScript et les blocages.
• Planificateur : un LLM ouvert qui découpe la question en sous-requêtes et décide quand s'arrêter.
• Extracteur : tire de la page le fait recherché, accompagné de la citation mot pour mot.
• Vérificateur : contrôle que l'URL existe et que la citation figure bien sur la page.

Le dernier élément répond à la question centrale de l'auteur. Un lien inventé apparaît quand le modèle construit sa réponse de mémoire plutôt qu'à partir du document chargé. Si chaque URL de la réponse passe par un contrôle « page ouverte, citation trouvée », l'hallucination de lien cesse d'être une erreur invisible et devient un résultat rejeté.

Où ces systèmes cassent habituellement

Le titre le dit explicitement : quelque chose a cassé. Les points de défaillance typiques d'une recherche agentique sont bien connus, et l'auteur en décrit probablement une partie.

Premier point : la qualité des résultats de recherche. Si la couche de recherche n'a pas renvoyé la page voulue, même un modèle puissant ne l'inventera pas et ne la trouvera pas. Deuxième point : les longues chaînes d'étapes. Les petits modèles ouverts tiennent moins bien un plan sur des dizaines d'appels d'outils et ont tendance à tourner en boucle ou à clore la recherche trop tôt. Troisième point : le contexte. Les pages brutes saturent vite la fenêtre, et les tokens consommés pour la lecture déterminent directement le coût. Quatrième point : les homonymes et les données périmées. L'agent peut recoller avec assurance des faits concernant des personnes différentes.

Comment appliquer cette approche en pratique

Si vous construisez un système similaire, reprenez de l'énoncé de l'auteur ses critères d'évaluation, pas son architecture. Constituez un jeu de questions dont les réponses sont connues et calculez plusieurs métriques :

• la part des réponses avec un lien fonctionnel ;
• la part des réponses dont la citation figure mot pour mot sur la page ;
• le coût d'une réponse réussie, et non d'un lancement ;
• le nombre d'étapes avant l'arrêt et la part des exécutions bouclées.

Le coût d'une réponse réussie compte plus que le prix d'un lancement. Un modèle bon marché qui échoue une fois sur deux peut revenir plus cher qu'un modèle coûteux. Pour comparer votre stack aux résultats de l'auteur, il faut ses chiffres réels, et ils ne figurent que dans l'article complet sur Habr.