TinyFish détaille l'architecture de recherche à base d'agents pour les agents IA en production
TinyFish, qui fournit une infrastructure web aux agents d'IA, a publié deux guides techniques consacrés aux raisons pour lesquelles un agent de recherche fonctionne en démonstration mais échoue en production : preuves incomplètes, tentatives qui répètent les mêmes actions vouées à l'échec, dépassement des limites de temps et de coût. Le premier guide définit une architecture de recherche agentique, le second tire les leçons de la construction d'un système de recherche approfondie. Le dispositif repose sur quatre primitives web (TinySearch, TinyFetch, TinyBrowser et TinyAgent) et sur une boucle de contrôle en sept phases autour du modèle de base. Une exécution commence par un « contrat de preuves » (champs requis, sources, fraîcheur, règles d'achèvement), puis planifie la récupération en séparant les besoins indépendants des besoins dépendants. Elle choisit ensuite un premier outil, traite les résultats de recherche comme de simples candidats tant que le contenu des pages n'est pas arrivé, évalue les preuves (suffisantes, incomplètes, contradictoires, inaccessibles ou budget épuisé), puis récupère ou escalade. Elle s'achève par un état validé : terminée, incomplète, échouée, annulée ou nécessitant une revue humaine. Sur OpenBenchmarks, TinyFish annonce un taux d'achèvement de 79,0 % sur les tâches de code, avec le coût médian par tâche le plus bas (0,050 dollar) et la plus faible consommation de jetons.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de MarkTechPost. Lire l'article original →
L'enjeu est très concret pour les équipes qui déploient des agents : la fiabilité dépend moins du modèle que de la structure qui l'entoure. Le modèle apporte le raisonnement, tandis que l'application gère l'état, l'exécution des outils, le traitement des preuves, les politiques d'exécution et la validation des sorties. Le guide insiste sur le fait que le choix de l'outil doit suivre le manque d'information et non une échelle fixe : la recherche quand la source est inconnue, la récupération simple quand l'URL est connue et lisible, le navigateur quand des actions sur la page sont nécessaires, l'agent web quand la décision porte sur plusieurs pages. Monter en gamme n'est pas toujours la solution : une requête faible demande une meilleure requête, et des sources contradictoires exigent des preuves plus solides, ce qu'un outil plus lourd ne fournit pas. Les nouvelles tentatives doivent dépendre du type d'échec et rester bornées. Une erreur transitoire peut justifier de répéter la requête, alors qu'une preuve incomplète ou contradictoire impose une approche différente. Les équipes y gagnent des coûts maîtrisés et des échecs lisibles.
Cette architecture s'appuie sur un préprint de février 2026 qui découple le raisonnement de l'exécution grâce à des interfaces d'outils typées, avec des garde-fous stricts : traçage détaillé et plafonds sur les jetons, le temps d'exécution, le coût total et le nombre d'appels d'outils. La deuxième phase répond au problème de « perte en cours de récupération » décrit par ChainRAG (ACL 2025), où des entités clés disparaissent lors de la décomposition de questions à sauts multiples. La sixième s'inspire de Search-R1, qui montre qu'un modèle peut apprendre à générer des requêtes supplémentaires lorsque la récupération précédente est insuffisante : sur sept jeux de données de questions-réponses, sa recherche multi-tours apprise a dépassé les références RAG de 41 % (Qwen2.5-7B) et de 20 % (Qwen2.5-3B). TinyFish en tire une conclusion d'ingénierie : privilégier des boucles de contrôle rigides, des reprises adaptées à chaque type d'échec et un raisonnement unifié plutôt qu'un planificateur autonome distinct.
Pas d'impact direct sur la France/UE