LongSeeker : l'agent de recherche qui bat Tongyi DeepResearch en gérant sa mémoire intelligemment
🔎 Pourquoi les agents de recherche saturent en milieu de session
Les agents de recherche dits "deep research" ont un problème structurel. Plus ils explorent, plus leur contexte explose. Chaque page visitée, chaque clic, chaque extrait ajouté à la fenêtre de contexte finit par polluer la mémoire de travail de l'agent.
Résultat : des réponses incohérentes, des hallucinations en fin de session, et des coûts de calcul qui flambent. C'est un mur invisible que la plupart des utilisateurs ne voient pas, mais qui limite drastiquement la profondeur réelle de ces outils.
Une équipe de chercheurs (Yijun Lu, Rui Ye, Yuwen Du, Jiajun Wang, Songhua Liu, Siheng Chen) vient de publier une solution sur arXiv le 6 mai 2026. LongSeeker propose une approche radicalement différente : au lieu d'accumuler aveuglément, l'agent décide activement ce qu'il garde, résume, isole ou jette.
Le score parle de lui-même : 61.5% sur BrowseComp contre 43.2% pour Tongyi DeepResearch. Soit un bond de +18 points dans un benchmark reconnu pour mesurer la capacité de recherche sur le web ouvert.
L'essentiel
- LongSeeker introduit Context-ReAct, un paradigme avec 5 opérations atomiques pour gérer dynamiquement la mémoire de travail d'un agent de recherche.
- Fine-tuné depuis Qwen3-30B-A3B sur 10 000 trajectoires synthétiques, il atteint 61.5% sur BrowseComp, là où Tongyi DeepResearch plafonne à 43.2%.
- L'opérateur Compress est prouvé expressivement complet : il peut simuler n'importe quelle autre opération de gestion de contexte.
- L'agent ne subit plus la saturation de contexte : il l'orchestre élastiquement, comme un chef d'orchestre qui décide quels instruments jouent à quel moment.
Outils recommandés
| Outil | Usage principal | Prix (mai 2026, vérifiez sur site) | Idéal pour |
|---|---|---|---|
| LongSeeker | Recherche web long-horizon avec gestion élastique du contexte | Open-source (modèle weights) | Chercheurs et développeurs d'agents |
| Qwen3-30B-A3B | Modèle base pour fine-tuning d'agents | Open-source | Projets nécessitant推理 à faible coût |
| DeerFlow de ByteDance | Agent open-source recherche, code et création long terme | Open-source | Projets multi-étapes code + recherche |
Le problème : l'explosion contextuelle tue les agents de recherche
Les agents de recherche actuels fonctionnent sur un principe simple mais fragile. Ils visitent des pages, extraient du contenu, l'ajoutent à leur prompt, et continuent. Ce mécanisme linéaire a une limite dure.
Après une dizaine de pages visitées, le contexte contient des milliers de tokens dont une grande partie est obsolète. Des informations de la page 3 contredisent celles de la page 8. Des détails insignifiants consument des tokens précieux. L'attention du modèle se dilue.
Ce n'est pas un problème de qualité du modèle. C'est un problème architectural. Le framework ReAct standard (Reasoning + Acting) ne prévoit aucun mécanisme pour gérer la mémoire de travail. Il suppose que tout ce qui entre reste utile. C'est faux pour une recherche de plus de 5 minutes.
L'approche classique de RAG vs fine-tuning vs agents montre que les agents sont performants pour les tâches complexes, mais leur scalabilité reste le talon d'Achille. LongSeeker s'attaque précisément à ce point de rupture.
Context-ReAct : les 5 opérations qui changent tout
La proposition centrale de LongSeeker est élégante : ajouter un mécanisme de gestion de contexte directement dans la boucle de raisonnement de l'agent. Au lieu de seulement "Penser → Agir", l'agent peut maintenant "Penser → Agir → Gérer".
Skip : avancer sans charger
L'agent identifie qu'une page ou une section n'est pas pertinente et la passe sans l'ajouter au contexte. Ce n'est pas du simple filtrage par mot-clé : c'est une décision prise après avoir lu le début de la page et évalué sa pertinence par rapport à l'objectif courant.
L'opération Skip réduit drastiquement le bruit. Dans les trajectoires analysées par les chercheurs, jusqu'à 40% des pages visitées par les agents classiques n'apportaient aucune valeur ajoutée.
Compress : résumer sans perdre l'essentiel
C'est l'opération la plus puissante du système. L'agent prend un bloc de contexte existant et le compresse en une version plus courte, en gardant uniquement les informations pertinentes pour la tâche en cours.
Ce qui distingue Compress d'un simple résumé, c'est qu'il est contextuellement motivé. L'agent ne compresse pas de façon générique. Il compresse en fonction de ce qu'il sait qu'il devra utiliser ensuite. Les résultats prouvent que cet opérateur est expressivement complet : il peut simuler n'importe quelle autre opération de gestion de contexte.
Rollback : revenir à un état antérieur
Quand l'agent réalise qu'une piste de recherche est infructueuse, il peut revenir à un snapshot antérieur de son contexte. C'est l'équivalent d'un git reset pour la mémoire de travail.
Cette opération est cruciale pour les recherches exploratoires où l'agent doit tester des hypothèses. Sans Rollback, les fausses pistes polluent définitivement le contexte.
Snippet : isoler un passage précis
Au lieu de garder une page entière dans le contexte, l'agent extrait uniquement le passage pertinent et jette le reste. L'opération Snippet agit comme un scalpel : précise, minimale, efficace.
Delete : supprimer définitivement
L'opération la plus simple mais la plus symbolique. L'agent décide qu'une information n'est plus utile et la supprime purement et simplement du contexte. C'est l'antithèse du "tout garder au cas où" qui caractérise les agents actuels.
Architecture : Qwen3-30B-A3B fine-tuné sur 10 000 trajectoires
LongSeeker n'est pas un modèle from scratch. C'est un fine-tuning de Qwen3-30B-A3B, le modèle de Alibaba avec une architecture MoE (Mixture of Experts) à 30 milliards de paramètres mais seulement 3 milliards actifs par token.
Pourquoi ce choix de base ?
Qwen3-30B-A3B offre un excellent ratio performance/coût. Les 3 milliards de paramètres actifs permettent une inférence rapide, tandis que les 30 milliards totaux garantissent une capacité de raisonnement suffisante pour les tâches de recherche complexes.
C'est un choix pragmatique. Les chercheurs ont préféré optimiser l'orchestration du contexte plutôt que d'augmenter la taille du modèle. L'idée : un agent intelligent avec un bon système de mémoire vaut mieux qu'un agent surdimensionné avec une mémoire saturée.
Les 10 000 trajectoires synthétiques
Le fine-tuning a été réalisé sur 10 000 trajectoires générées synthétiquement. Chaque trajectoire représente une session de recherche complète avec les décisions de gestion de contexte annotées.
La génération de ces trajectoires est un travail non trivial. Il fallait créer des scénarios où les opérations de gestion de contexte sont réellement nécessaires, puis annoter les décisions optimales (quand compresser, quand faire un rollback, etc.).
Cette approche par trajectoires synthétiques rappelle la stratégie utilisée par des agents comme Dexter pour la recherche financière, où la qualité des données d'entraînement détermine directement la qualité du comportement en production.
Résultats : 61.5% vs 43.2% sur BrowseComp
Le benchmark BrowseComp mesure la capacité d'un agent à trouver des informations précises sur le web ouvert. C'est un test difficile car il nécessite de naviguer, de comprendre des pages non structurées, et de synthétiser des informations dispersées.
Comparaison des scores
| Agent | Score BrowseComp | Modèle de base | Gestion de contexte |
|---|---|---|---|
| LongSeeker | 61.5% | Qwen3-30B-A3B | Élastique (Context-ReAct) |
| Tongyi DeepResearch | 43.2% | Non disclosed | Standard |
| OpenSeeker-v2 | ~55%* | Open-source | Hybride |
| Agents ReAct classiques | ~30-35% | Variable | Aucune |
*Estimation basée sur les performances rapportées dans la littérature.
Ce que le score ne dit pas
Le chiffre 61.5% est impressionnant, mais le plus significatif est ailleurs. C'est l'écart de performance qui grandit à mesure que la complexité de la recherche augmente.
Sur les requêtes simples (1-2 pages), LongSeeker et Tongyi DeepResearch sont comparables. La différence apparaît sur les recherches long-horizon nécessitant 10+ pages. Là, Tongyi s'effondre tandis que LongSeeker maintient sa performance grâce à la gestion élastique du contexte.
L'approche de LongSeeker s'inscrit dans une tendance où les agents open-source comme OpenSeeker-v2 cassent le monopole des search agents industriels, non pas en copiant leurs architectures, mais en les innovant différemment.
Le workflow LongSeeker en pratique
Comprendre LongSeeker, c'est comprendre son flux de décision. Voici comment l'agent procède concrètement lors d'une session de recherche.
Étape 1 : Initialisation
L'agent reçoit une requête et planifie une stratégie de recherche. Le contexte est vide, la mémoire de travail est vierge. Jusqu'ici, rien de différent d'un agent classique.
Étape 2 : Exploration avec filtrage
L'agent commence à visiter des pages. Pour chaque page, il évalue en temps réel si le contenu est pertinent. Si non → Skip. Si partiellement pertinent → Snippet pour extraire le passage utile.
C'est ici que le premier gain apparaît. Un agent classique chargerait intégralement chaque page visitée. LongSeeker ne charge que ce qui mérite de l'être.
Étape 3 : Compression périodique
Après quelques pages, le contexte commence à se remplir. L'agent déclenche un Compress : il reprend les blocs de contexte accumulés et les condense, en gardant ce qui est pertinent pour les étapes suivantes de la recherche.
La clé : la compression est orientée objectif. L'agent sait ce qu'il cherche encore, donc il sait ce qu'il peut éliminer.
Étape 4 : Gestion des impasses
Si l'agent s'engage dans une piste qui s'avère infructueuse, il utilise Rollback pour revenir à un état antérieur propre. Puis Delete pour supprimer les informations issues de la fausse piste. Le contexte reste sain.
Étape 5 : Synthèse finale
À la fin de la recherche, le contexte ne contient que des informations pertinentes, compressées et organisées. L'agent peut alors synthétiser sans être pollué par le bruit accumulé pendant des dizaines de pages visitées.
Compress : l'opérateur qui peut tout faire
Parmi les 5 opérations de Context-ReAct, Compress mérite une attention particulière. Les chercheurs ont prouvé formellement que cet opérateur est expressivement complet.
Qu'est-ce que l'expressivité complète ?
En termes simples : Compress peut simuler n'importe laquelle des 4 autres opérations. Un résumé intelligent peut servir de Skip (compresser à rien), de Snippet (compresser en gardant un passage), de Delete (compresser à vide), ou de Rollback (compresser à un état antérieur).
Cette propriété a une implication pratique majeure. Même si l'agent ne maîtrise pas parfaitement toutes les opérations, la seule maîtrise de Compress lui donne un pouvoir de gestion de contexte quasi-total.
Pourquoi garder les 5 opérations alors ?
Si Compress peut tout faire, pourquoi avoir 5 opérations distinctes ? Pour l'efficacité et la lisibilité.
Chaque opération spécialisée est plus efficace que Compress pour son cas d'usage. Skip est plus rapide que Compress pour ignorer une page. Delete est plus propre que Compress pour supprimer. Les opérations spécialisées sont des raccourcis cognitifs pour l'agent.
De plus, décomposer les opérations rend le comportement de l'agent plus interprétable. Quand l'agent fait un Skip, on comprend exactement ce qui se passe. Quand il fait un Compress, l'interprétation est plus floue.
La question de la mémoire dans les agents IA
Le problème que résout LongSeeker n'est pas nouveau. C'est une instance d'un défi plus large : comment gérer la mémoire dans les agents IA.
Mémoire de travail vs mémoire long terme
LongSeeker s'attaque à la mémoire de travail (le contexte dans le prompt). C'est différent de la mémoire long terme (les bases de données vectorielles, les fichiers de log, etc.).
La mémoire de travail a une contrainte dure : la fenêtre de contexte. Même les modèles avec 128k ou 200k tokens finissent par saturer si on y accumule sans discernement. La question n'est pas "combien de tokens peut-on mettre" mais "quels tokens méritent d'y être".
Cette distinction est fondamentale dans la conception d'agents. Comme expliqué dans notre guide sur la mémoire IA, il existe plusieurs couches de mémoire, et chaque couche a ses propres mécanismes optimaux de gestion.
Le parallèle avec la mémoire humaine
Le cerveau humain ne se souvient pas de tout. Il filtre, compresse, oublie activement. Les recherches en sciences cognitives montrent que l'oubli est une fonction, pas un bug.
LongSeeker applique ce principe aux agents : l'oubli sélectif (Delete), la consolidation (Compress), la récupération ciblée (Snippet) sont autant de mécanismes inspirés du fonctionnement cognitif humain.
Implications pour l'écosystème des agents de recherche
LongSeeker n'est pas qu'un paper académique. Il a des implications concrètes pour la façon dont on conçoit les agents de recherche aujourd'hui.
Le mythe du "plus de contexte = meilleure recherche"
L'industrie a pris l'habitude de résoudre les problèmes de mémoire en augmentant la fenêtre de contexte. Gemini avec 1M tokens, Claude avec 200k, les solutions RAG avec des bases immenses. LongSeeker montre que cette approche a une courbe de rendement décroissante.
À partir d'un certain point, ajouter du contexte dégrade la performance. L'attention se dilue, les hallucinations augmentent, les coûts explosent. L'orchestration élastique de LongSeeker suggère que la solution n'est pas "plus de mémoire" mais "meilleure gestion de la mémoire".
Impact sur les coûts d'inférence
Moins de contexte signifie moins de tokens à traiter à chaque étape. Avec Qwen3-30B-A3B et ses 3 milliards de paramètres actifs, combiné à un contexte optimisé, le coût par session de recherche chute significativement.
Les chercheurs ne donnent pas de chiffres précis sur les économies réalisées, mais l'architecture suggère une réduction potentielle de 30 à 50% des tokens traités par session, comparé à un agent ReAct classique avec accumulation linéaire.
Un pattern réutilisable au-delà de la recherche
Context-ReAct n'est pas spécifique à la recherche web. Le pattern d'orchestration élastique du contexte peut s'appliquer à tout agent qui maintient un état sur une longue durée : agents de code, agents de data science, agents de support client.
Des projets comme DeerFlow de ByteDance, qui gèrent des projets sur le long terme, pourraient bénéficier directement de ce pattern. Plus la tâche est longue, plus la gestion de contexte devient critique.
Limites et questions ouvertes
Malgré ses résultats impressionnants, LongSeeker a des limites que les chercheurs reconnaissent honnêtement.
La dépendance au fine-tuning
Les 10 000 trajectoires synthétiques sont à la fois une force et une faiblesse. Une force car elles apprennent à l'agent des comportements sophistiqués de gestion de contexte. Une faiblesse car la qualité du modèle dépend directement de la qualité de ces trajectoires.
Générer des trajectoires de haute qualité est coûteux et difficile à scaler. Si on veut adapter LongSeeker à un nouveau domaine (recherche médicale, juridique, scientifique), il faut générer de nouvelles trajectoires spécifiques.
La question de la généralisation
Les résultats sur BrowseComp sont solides, mais BrowseComp reste un benchmark spécifique. La recherche web grand public est un cas d'usage particulier. La question ouverte : Context-ReAct fonctionne-t-il aussi bien sur des tâches de recherche dans des corpus fermés, des bases de données internes, des environnements d'entreprise ?
Pas de comparaison avec les agents propriétaires
Le papier compare LongSeeker avec Tongyi DeepResearch et des baselines académiques. Il n'y a pas de comparaison directe avec les agents propriétaires comme Gemini Deep Research ou ChatGPT with Deep Research. Ces derniers ont des architectures non publiques et des ressources d'ingénierie bien supérieures.
Le score de 61.5% est excellent pour un agent open-source, mais il ne permet pas de conclure que LongSeeker bat les solutions commerciales sur toutes les métriques.
❌ Erreurs courantes
Erreur 1 : Confondre gestion de contexte et fenêtre de contexte
Ce qui ne va pas : Penser que LongSeeker résout les problèmes en augmentant la taille de la fenêtre de contexte. La solution est architecturale, pas quantitative.
La solution : Comprendre que LongSeeker gère mieux un contexte de taille fixe. Le gain vient de l'orchestration, pas de la taille.
Erreur 2 : Voir Context-ReAct comme un simple système de RAG amélioré
Ce qui ne va pas : Classifier LongSeeker dans la catégorie RAG. C'est un agent avec une boucle de raisonnement qui gère activement sa mémoire, pas un système de récupération passive.
La solution : Le distinguer clairement des approches RAG. LongSeeker prend des décisions métacognitives (que garder, que jeter), ce qui est fondamentalement différent d'un système de retrieval.
Erreur 3 : Ignorer l'importance des trajectoires d'entraînement
Ce qui ne va pas : Se focaliser sur l'architecture Context-ReAct en oubliant que tout repose sur la qualité des 10 000 trajectoires synthétiques.
La solution : Si vous voulez reproduire ou adapter LongSeeker, investissez du temps dans la génération et la validation des trajectoires. L'architecture sans les données ne vaut rien.
Erreur 4 : Déployer LongSeeker sans monitoring des opérations de contexte
Ce qui ne va pas : Utiliser l'agent en production sans suivre quelles opérations (Skip, Compress, Rollback, Snippet, Delete) sont déclenchées et quand.
La solution : Instrumentez le pipeline pour logger chaque opération de gestion de contexte. C'est la clé pour comprendre le comportement de l'agent et le déboguer.
❓ Questions fréquentes
LongSeeker remplace-t-il les systèmes RAG ?
Non. LongSeeker est un agent de recherche web qui gère sa mémoire de travail. Le RAG reste pertinent pour la recherche dans des corpus fermés. Les deux approches sont complémentaires et peuvent coexister dans un pipeline.
Peut-on utiliser LongSeeker avec un autre modèle que Qwen3-30B-A3B ?
En théorie oui, mais les performances dépendront du fine-tuning. Les opérations Context-ReAct sont apprises, pas programmées. Changer de modèle de base implique de régénérer les trajectoires d'entraînement et de refaire le fine-tuning.
L'opérateur Compress est-il vraiment équivalent aux autres opérations ?
En termes d'expressivité formelle, oui. Les chercheurs le prouvent dans le papier. En pratique, les opérations spécialisées sont plus efficaces et interprétables. Compress est un filet de sécurité théorique, pas un remplacement pratique.
BrowseComp est-il un benchmark représentatif ?
BrowseComp est l'un des benchmarks les plus utilisés pour évaluer les agents de recherche web. Il n'est pas parfait, mais il est reconnu par la communauté. Le fait que LongSeeker surpasse Tongyi DeepResearch de +18 points est significatif quelle que soit la critique du benchmark.
Comment générer les trajectoires synthétiques pour un nouveau domaine ?
Le papier ne détaille pas entièrement le processus, mais il implique un agent "enseignant" qui résout des tâches tout en annotant ses décisions de gestion de contexte. Ce processus est coûteux et nécessite un modèle plus puissant comme oracle pour générer les annotations.
✅ Conclusion
LongSeeker démontre que le vrai goulot d'étranglement des agents de recherche n'est pas la taille du modèle ni la fenêtre de contexte, mais l'absence de mécanismes actifs de gestion de la mémoire de travail. Avec Context-ReAct et ses 5 opérations atomiques, il ouvre une voie que l'écosystème va probablement adopter massivement : l'agent qui sait oublier est l'agent qui sait chercher. Le paper complet est disponible sur arXiv.