OpenSeeker-v2 : l'open-source casse le monopole des search agents industriels

OpenSeeker-v2 : l'open-source casse le monopole des search agents industriels

🔎 Jusqu'à 10 600 exemples suffisent pour battre les géants

Les agents de recherche profonde étaient considérés comme le dernier bastion des Big Tech. Google, OpenAI, Anthropic : tous ont investi des millions pour entraîner des modèles capables de fouiller le web, croiser des sources et produire des réponses structurées. La recette semblait figée — pré-entraînement massif, puis CPT, SFT, RL — un pipeline industriel hors de portée de la recherche académique.

En mai 2026, une équipe publie OpenSeeker-v2 sur arXiv et pulvérise ce postulat. Leur constat est radical : avec un simple SFT bien ciblé, alimenté par des trajectoires informatives à haute difficulté, un modèle open-source rivalise avec les solutions propriétaires de pointe. Pas besoin de RLHF, pas besoin de milliards de paramètres supplémentaires.

L'implication est claire. Le deep search n'est plus un avantage compétitif lié aux ressources. C'est un problème de qualité de données d'entraînement. Et ça change tout pour l'écosystème open-source.

L'essentiel

• OpenSeeker-v2 est un agent de recherche profonde open-source qui rivalise avec les modèles propriétaires des Big Tech sur les benchmarks de référence.
• Le modèle est entraîné avec seulement 10 600 trajectoires, contre des millions pour les approches industrielles classiques.
• Trois modifications clés expliquent la performance : l'agrandissement des graphes de connaissances, l'expansion du set d'outils, et un filtrage strict par nombre d'étapes.
• La méthode remplace le pipeline lourd (pré-entraînement + CPT + SFT + RL) par un SFT ciblé sur des trajectoires à haute difficulté.
• Les benchmarks couvrent le deep search multi-sources (HotPotQA-style) et les tâches de code-recherche (SWE-bench-style).

Outils recommandés

Ce qu'est réellement un search agent de frontier

Un search agent ne fait pas qu'une requête Google et résume les résultats. Il enchaîne des itérations de recherche, évalue la pertinence de chaque source, identifie les lacunes dans son raisonnement, et relance des recherches ciblées pour combler ces trous.

Concrètement, l'agent suit une trajectoire : il pose une question initiale, récupère des documents, les analyse, décide s'il a assez d'information, ou reformule sa query. Cette boucle peut s'exécuter sur 5, 10, parfois 20 étapes avant de produire une réponse finale.

Les modèles comme GPT-5.5 (score agentic de 98,2) ou Gemini 3 Pro Deep Think (95,4) excellent dans ce type de raisonnement itératif. Mais leur entraînement repose sur des pipelines lourds, inaccessibles hors des labos industriels. OpenSeeker-v2 démontre que ce n'est pas la taille du modèle qui fait la différence, mais la qualité du signal d'apprentissage.

Cette distinction est fondamentale. Elle rapproche les agents de recherche des 5 patterns d'agents IA qui marchent, où la boucle d'observation-réflexion-action prime sur la brute force computationnelle.

La méthode : informative and high-difficulty trajectories

C'est le cœur technique du papier. L'équipe d'OpenSeeker-v2 part d'un constat simple : la plupart des données d'entraînement pour les search agents sont de mauvaise qualité. Soit trop faciles (le modèle trouve la réponse en une étape), soit trop redondantes (des milliers de trajectoires quasi identiques).

Leur approche inverse la logique industrielle. Au lieu de maximiser le volume de données, ils maximisent la difficulté et la richesse informationnelle de chaque trajectoire.

Trajectoires informatives : apprendre à chercher, pas à répondre

Une trajectoire informative ne se juge pas à la réponse finale, mais au chemin parcouru. Le modèle doit apprendre à structurer sa recherche, à identifier les sous-questions, à croiser des sources contradictoires, à revenir en arrière quand une piste est morte.

L'entraînement classique sur des paires question-réponse produit des modèles qui sautent aux conclusions. L'entraînement sur des trajectoires informatives produit des modèles qui savent naviguer dans l'incertitude.

High-difficulty filtering : ne garder que le pire

C'est le low-step filtering, et c'est contre-intuitif. L'équipe filtre les trajectoires pour ne conserver que celles où le modèle a eu le plus de difficulté à trouver la réponse. Si une trajectoire est résolue en 2-3 étapes, elle est éliminée.

Le résultat : le modèle apprend exclusivement à partir de cas complexes, où la stratégie de recherche fait la différence entre le succès et l'échec. C'est l'équivalent de l'entraînement en altitude pour les sportifs — on ne s'améliore pas en répétant ce qu'on sait déjà faire.

Trois leviers de synthèse de données

Pour générer ces trajectoires de qualité, l'équipe a modifié la synthèse de données sur trois axes :

1. Scale du graphe de connaissances : les graphes utilisés pour générer les trajectoires ont été considérablement agrandis, offrant au modèle des chemins de recherche plus longs et plus ramifiés.
2. Expansion du set d'outils : au lieu de se limiter à un moteur de recherche, l'agent dispose d'un ensemble élargi d'outils (calcul, extraction structurée, navigation multi-sources), forçant des stratégies de recherche plus sophistiquées.
3. Filtrage strict : comme expliqué, seules les trajectoires à haute difficulté (nécessitant de nombreuses étapes) sont conservées.

Ces trois modifications, combinées, produisent un dataset de 10 600 trajectoires. Un chiffre dérisoire par rapport aux standards industriels, mais suffisant pour atteindre les performances de frontier.

Les benchmarks : HotPotQA, SWE-bench et au-delà

OpenSeeker-v2 est évalué sur deux familles de benchmarks qui testent des compétences distinctes mais complémentaires pour un search agent.

Deep search multi-sources (HotPotQA-style)

Les benchmarks de type HotPotQA exigent que le modèle croise des informations provenant de plusieurs documents pour répondre à une question. Ce n'est pas une simple recherche factuelle — c'est du raisonnement multi-hop.

Le modèle doit identifier quels faux sont nécessaires, les localiser dans des sources différentes, les combiner logiquement. Sur ces benchmarks, OpenSeeker-v2 surpasse les modèles propriétaires qui ont été entraînés avec des pipelines bien plus lourds.

C'est là que la technique des trajectoires informatives paie le plus. Le modèle a appris à planifier sa recherche en plusieurs étapes, pas à sauter directement à la réponse.

Code-recherche (SWE-bench-style)

La deuxième famille de benchmarks teste la capacité de l'agent à résoudre des problèmes de code en combinant recherche et implémentation. C'est un cas d'usage concret : un développeur signale un bug, l'agent doit chercher dans la documentation, comprendre le contexte, identifier la source du problème, et proposer un fix.

Sur ces tâches SWE-bench-style, OpenSeeker-v2 démontre que l'approche par trajectoires à haute difficulté se généralise au-delà du simple QA. L'agent ne cherche pas seulement de l'information — il cherche avec un objectif d'action.

Pour comprendre comment ce type d'agent s'intègre dans une architecture plus large, voir notre article sur la configuration d'OpenClaw : SOUL, AGENTS et Skills, qui détaille comment structurer un agent avec des compétences de recherche et d'action.

Pourquoi ça remet en cause le pipeline industriel

Le pipeline classique pour entraîner un agent de frontier ressemble à ça : pré-entraînement massif sur le web, puis continual pre-training (CPT) sur des données spécialisées, puis supervised fine-tuning (SFT) sur des démos, enfin reinforcement learning (RL) pour optimiser un reward.

Chaque étape coûte des millions de dollars en compute. Chaque étape nécessite des infrastructures que seules les Big Tech possèdent. C'est ce mur de ressources qui maintenait le monopole.

OpenSeeker-v2 saute les trois premières étapes. Il prend un modèle de base pré-entraîné, et applique un SFT ciblé avec 10 600 trajectoires bien choisies. Résultat : des performances comparables aux modèles entraînés avec le pipeline complet.

Ce n'est pas que le pipeline industriel est inutile. C'est qu'il est mal optimisé. Quand on alimente un SFT avec des données médiocres, le RL devient nécessaire pour corriger les défauts. Quand les données sont excellentes dès le départ, le RL apporte des marginaux.

La leçon pour la communauté open-source est claire : la qualité l'emporte sur la quantité, et la difficulté l'emporte sur la couverture. Ce principe s'applique d'ailleurs au-delà des search agents — il est central dans le débat RAG vs fine-tuning vs agents : choisir la bonne approche en 2026.

10 600 trajectoires : pourquoi ce chiffre est troublant

Dans l'industrie, on parle en millions, en milliards de tokens. Et là, un projet académique arrive avec 10 600 exemples et bat les géants. Ce chiffre mérite qu'on s'y arrête.

La première réaction est le scepticisme. Mais le papier démontre que la distribution de difficulté des trajectoires est le facteur déterminant. Un million de trajectoires faciles n'apprennent rien au modèle qu'il ne sait déjà faire. Dix mille trajectoires difficiles forcent l'agent à développer de nouvelles stratégies.

C'est cohérent avec ce qu'on observe ailleurs en ML. Les curriculum learning, où on entraîne d'abord sur des exemples faciles puis progressivement sur des plus difficiles, montrent depuis longtemps que la distribution d'apprentissage importe autant que le volume.

La différence ici, c'est que l'équipe d'OpenSeeker-v2 a carrément éliminé les exemples faciles. Low-step filtering signifie littéralement : si c'est facile, on ne l'utilise même pas pour s'échauffer. On va directement à l'entraînement en altitude.

Pour la communauté open-source, c'est une excellente nouvelle. Générer 10 600 trajectoires de haute qualité est réalisable avec un budget modeste. Ce n'est pas une question de compute, c'est une question de méthodologie.

Les implications pour l'écosystème open-source

Jusqu'à présent, le deep search était la justification principale des modèles propriétaires. "Vous ne pouvez pas avoir un bon search agent en open-source" était l'argument implicite de chaque Big Tech vendant des accès API à leurs modèles de recherche.

OpenSeeker-v2 détruit cet argument. Et les conséquences vont au-delà du seul cas d'usage du deep search.

Démocratisation des agents avancés

Si 10 600 trajectoires suffisent pour entraîner un search agent de frontier, le même principe peut s'appliquer à d'autres types d'agents. Agents de code, agents d'analyse financière, agents de recherche scientifique — partout où la stratégie de recherche est clé, la méthode des trajectoires à haute difficulté devrait fonctionner.

Cela renforce le mouvement vers des agents IA open-source avec Ollama en local, où n'importe qui peut déployer un agent performant sans dépendre d'une API propriétaire.

Nouveaux critères de choix des LLM pour les agents

Quand l'entraînement spécialisé coûte si peu cher, le choix du modèle de base devient plus important que le pipeline d'après-entraînement. Les meilleurs LLM pour les agents IA ne sont plus ceux qui ont le meilleur entraînement propriétaire, mais ceux qui offrent la meilleure base pour un SFT ciblé.

Dans ce contexte, les modèles comme Kimi K2.6 de Moonshot AI (score agentic de 88,1, self-host) ou GLM-5 de Z.AI (82, self-host) gagnent en attractivité. Ils offrent une base solide, open-source, sur laquelle appliquer la méthode OpenSeeker-v2.

Menace pour les modèles propriétaires de recherche

Les modèles propriétaires comme GPT-5.5 (98,2) et Gemini 3 Pro Deep Think (95,4) restent en tête des classements agentic globaux. Mais leur avantage dans le domaine spécifique du deep search se réduit. Si un modèle open-source égale leurs performances de recherche, la justification du prix premium s'effrite.

C'est particulièrement vrai pour les cas d'usage B2B, où la confidentialité des données pousse à privilégier le self-host. Un search agent open-source performant élimine le compromis entre performance et confidentialité.

Ce que ça nous apprend sur DeerFlow et les agents à long terme

L'approche d'OpenSeeker-v2 éclaire rétrospectivement d'autres projets open-source récents. DeerFlow de ByteDance, par exemple, est un agent open-source conçu pour rechercher, coder et créer sur le long terme.

Le point commun avec OpenSeeker-v2 est l'importance de la stratégie de recherche sur la durée. Un agent qui travaille sur le long terme ne peut pas se permettre de suivre des trajectoires inefficaces. Il doit optimiser chaque étape, exactement comme ce qu'apprend OpenSeeker-v2 à travers ses trajectoires à haute difficulté.

La méthode du low-step filtering est d'ailleurs directement transposable : pour un agent à long terme, on pourrait filtrer les trajectoires d'entraînement pour ne conserver que celles où l'agent a dû reformuler sa stratégie en cours de route. Les cas faciles où tout se passe bien du premier coup n'enseignent rien sur la résilience.

Cette convergence entre les approches de recherche (OpenSeeker-v2) et les approches de création à long terme (DeerFlow) suggère un principe plus général : les agents open-source les plus performants sont ceux qui apprennent de leurs échecs, pas de leurs succès.

Comment utiliser OpenSeeker-v2 concrètement

L'article d'arXiv est un papier de recherche, pas un produit packagé. Mais les implications pratiques sont immédiates pour les développeurs et équipes tech.

En local avec Ollama

Le modèle peut être exécuté en local via Ollama, ce qui permet de tester ses capacités de recherche sans envoyer de données à un tiers. C'est essentiel pour les entreprises qui traitent des données sensibles et ne peuvent pas utiliser les APIs propriétaires.

La configuration requise reste modérée par rapport aux modèles de frontier propriétaires, précisément parce que le modèle n'a pas été gonflé par un pipeline d'entraînement lourd.

Intégration dans un framework d'agents

OpenSeeker-v2 n'est pas un framework complet — c'est un modèle. Pour le transformer en agent autonome, il faut l'intégrer dans un framework comme OpenClaw, qui gère la boucle d'action, les outils, et la persistance de la mémoire.

Les meilleurs agents IA autonomes combinent généralement un modèle de base performant avec une orchestration sophistiquée. OpenSeeker-v2 fournit le premier élément ; le framework fournit le second.

Déploiement en production

Pour un déploiement sérieux, un hébergement adapté est nécessaire. Hostinger offre des solutions abordables pour héberger des agents open-source, avec des performances suffisantes pour des charges de recherche modérées. Le point clé est d'avoir un accès fiable au web et assez de RAM pour charger le modèle.

Les limites qu'il faut garder en tête

Malgré les résultats impressionnants, OpenSeeker-v2 n'est pas un modèle miracle. Plusieurs limites sont importantes à mentionner.

La première est que le modèle est spécialisé. Ses performances exceptionnelles concernent le deep search. Sur des tâches générales de raisonnement, de créativité ou de conversation, il ne surpasse probablement pas les modèles de frontier généralistes comme Claude Opus 4.7 (94,3) ou GPT-5.4 Pro (91,8).

La deuxième limite concerne la génération des trajectoires d'entraînement elles-mêmes. Le papier ne détaille pas entièrement le coût de synthèse des 10 600 trajectoires. Si chaque trajectoire nécessite des dizaines d'appels API à un modèle puissant pour être générée et filtrée, le coût réel n'est pas négligeable — il est juste déplacé de l'entraînement à la préparation des données.

La troisième limite est la dépendance au modèle de base. OpenSeeker-v2 part d'un modèle pré-entraîné existant. Si ce modèle de base a des biais ou des lacunes, le SFT ne les corrigera pas forcément. La méthode améliore la stratégie de recherche, pas les connaissances sous-jacentes.

Enfin, les benchmarks, bien que standards, restent des benchmarks. La performance en laboratoire ne garantit pas la performance en conditions réelles, avec du bruit, des sources unreliable, et des utilisateurs qui posent des questions mal formulées.

❌ Erreurs courantes

Erreur 1 : Confondre volume et qualité de données

L'erreur classique est de penser qu'entraîner un search agent nécessite des millions d'exemples. OpenSeeker-v2 démontre le contraire : 10 600 trajectoires à haute difficulté battent des datasets mille fois plus grands mais mal filtrés. La solution : investir dans le filtrage et la curation, pas dans la collecte brute.

Erreur 2 : Appliquer du RL par réflexe

Quand un search agent ne performe pas bien, l'instinct industriel est d'ajouter une étape de reinforcement learning. Mais si les données de SFT sont de mauvaise qualité, le RL ne fera que polir une stratégie fondamentalement défectueuse. La solution : d'abord améliorer les trajectoires d'entraînement, puis évaluer si le RL apporte encore quelque chose.

Erreur 3 : Ignorer le filtrage par difficulté

Beaucoup d'équipes open-source reproduisent la méthode d'OpenSeeker-v2 mais négligent le low-step filtering. Elles conservent des trajectoires faciles "pour varier le dataset". C'est exactement ce qui dilue le signal d'apprentissage. La solution : être impitoyable sur le filtrage. Si c'est facile, ça n'a pas sa place dans le dataset.

Erreur 4 : Déployer un search agent sans framework

OpenSeeker-v2 est un modèle, pas un produit. L'erreur est de l'utiliser tel quel, sans boucle d'orchestration, sans gestion des outils, sans persistance. La solution : l'intégrer dans un framework d'agents comme OpenClaw qui gère l'infrastructure autour du modèle.

❓ Questions fréquentes

OpenSeeker-v2 remplace-t-il les search agents propriétaires comme Perplexity ou SearchGPT ?

Pas exactement. OpenSeeker-v2 est un modèle de recherche, pas un produit utilisateur final. Les solutions propriétaires incluent une interface, une indexation web en temps réel, et des garanties de disponibilité. OpenSeeker-v2 fournit le moteur de raisonnement, pas le produit complet.

Peut-on réutiliser la méthode pour d'autres types d'agents ?

Oui, c'est même la principale implication du papier. Le principe des trajectoires informatives à haute difficulté est transposable à tout agent dont la performance dépend d'une stratégie itérative : agents de code, agents d'analyse, agents de planification.

Quel modèle de base utiliser avec la méthode OpenSeeker-v2 ?

Le papier ne prescrit pas de modèle spécifique, mais la logique suggère un modèle de base avec de bonnes capacités de raisonnement. Les modèles self-host comme Kimi K2.6 (88,1) ou GLM-5 (82) sont des candidats naturels pour la communauté open-source.

Le low-step filtering ne risque-t-il pas de sur-spécialiser le modèle ?

C'est un risque réel. En ne s'entraînant que sur des cas difficiles, le modèle peut devenir maladroit sur des questions simples. En pratique, les auteurs considèrent que les capacités de base du modèle pré-entraîné couvrent les cas simples — le SFT ne sert qu'à ajouter la capacité de gérer les cas complexes.

10 600 trajectoires, c'est vraiment suffisant pour la production ?

Pour un proof-of-concept académique, oui. Pour un déploiement en production à grande échelle, il faudra probablement plus de données pour couvrir la diversité des cas réels. Le chiffre prouve un principe, pas une limite absolue.

✅ Conclusion

OpenSeeker-v2 démontre que le monopole des Big Tech sur le deep search n'est pas technologique — il est méthodologique. Avec 10 600 trajectoires bien choisies et un SFT ciblé, un projet open-source atteint les performances des modèles entraînés avec des pipelines industriels à millions de dollars. La qualité des données d'apprentissage, et non la quantité de compute, est le véritable levier de performance pour les search agents. Pour les équipes qui veulent construire leurs propres agents de recherche sans dépendre des APIs propriétaires, le message est clair : explorez les frameworks d'agents open-source et appliquez les principes de filtrage par difficulté dès aujourd'hui.