OpenSearchCon 2026 : pourquoi les agents d’IA ont besoin de plus qu’une base de données vectorielle

OpenSearchCon North America 2026 arrive alors que la « recherche » devient un problème bien plus vaste que la simple recherche de documents similaires. Les agents IA doivent récupérer des preuves, préserver le contexte utile, appeler des outils et expliquer ce qui s’est passé lorsqu’une tâche échoue.

Une base de données vectorielle résout une partie du problème. Un agent sérieux a également besoin d’une récupération précise, de métadonnées, d’actualisation, de mémoire, de traces d’exécution et d’autorisations. La couche de données émergente de l’IA ressemble moins à des « embeddings dans une base de données » qu’à une combinaison de recherche, de mémoire et d’observabilité.

OpenSearchCon 2026 montre ce que devient la recherche

OpenSearchCon North America 2026 se tiendra du 22 au 24 septembre à San José, en Californie.

Le programme comprend toujours la pertinence, Lucene, les opérations de cluster et l’observabilité traditionnelle, mais une grande partie des discussions de 2026 s’étend désormais au RAG, à la récupération hybride, aux performances vectorielles, à MCP et à l’observabilité des agents IA.

Cette orientation correspond à la feuille de route 2026 du projet, qui considère les agents IA comme une nouvelle catégorie d’utilisateurs de la recherche et inclut le contexte agentique, la mémoire, le routage des outils et MCP.

Le changement important n’est pas qu’OpenSearch ait ajouté des fonctionnalités d’IA.

La recherche devient une infrastructure pour les systèmes qui récupèrent des informations, puis agissent à partir de celles-ci.

Un agent IA sérieux a besoin de deux historiques consultables

La plupart des tutoriels sur le RAG se concentrent sur une seule question :

Que doit savoir le modèle ?

Les agents qui s’exécutent sur de longues périodes en introduisent une autre :

Qu’a réellement fait l’agent ?

Le premier améliore les réponses. Le second rend le système diagnosticable.

C’est important, car un message de chat final peut dissimuler un échec du workflow. Un agent peut affirmer qu’une tâche est terminée alors qu’il a récupéré le mauvais contexte, sélectionné le mauvais outil ou n’a jamais effectué l’action attendue.

OpenSearchCon propose une session consacrée précisément à ce problème : Surveiller les travailleurs IA : l’observabilité OpenSearch pour OpenClaw et Hermes-agent.

Le cas d’échec décrit est important, car la solution n’était pas une meilleure transcription de chat. Il s’agissait de télémétrie opérationnelle : invocations du modèle, récupération du contexte et appels d’outils représentés sous forme de traces.

Un agent crée deux types d’historique interrogeable : ce qu’il savait et ce qu’il a fait.

De nombreux échecs du RAG surviennent avant que le LLM ne voie quoi que ce soit

Lorsqu’une réponse RAG est incorrecte, remplacer le modèle de langage est une réaction évidente. Mais ce n’est peut-être pas la bonne couche à corriger.

La session Réparez votre récupération, réparez votre RAG d’OpenSearchCon présente directement cet argument : de nombreux échecs apparemment liés à la génération trouvent leur origine dans la couche de récupération, qui détermine quelles preuves parviennent au modèle.

La règle de débogage est simple :

le modèle ne peut pas raisonner à partir d’éléments de preuve que la récupération n’a jamais placés dans son contexte.

Le RAG en production doit également fournir un résultat à jour, et pas seulement sémantiquement similaire. Un document consacré à la version 2.0 d’un logiciel peut être très proche de la version 4.0 dans l’espace des embeddings tout en fournissant à l’agent la mauvaise procédure.

Les métadonnées utiles à la récupération peuvent donc inclure :

• la version,
• la date de publication,
• le produit ou l’environnement,
• le statut du document,
• l’autorité de la source,
• et les autorisations d’accès.

La qualité de la récupération, c’est la pertinence dans le bon contexte.

La recherche par mots-clés n’a pas perdu face à la recherche vectorielle

L’essor de la recherche vectorielle a encouragé une explication simpliste : la recherche par mots-clés était dépassée et les embeddings la remplaçaient.

La récupération technique rend cette distinction beaucoup moins nette.

Une requête telle que Erreur CUDA 802 sur la RTX 5090 contient à la fois une signification sémantique et des jetons exacts qui ne devraient pas disparaître dans une similarité approximative.

C’est pourquoi OpenSearchCon continue de mettre l’accent sur la récupération hybride. La difficulté ne consiste pas simplement à exécuter ensemble une recherche par mots-clés et une recherche vectorielle ; il faut aussi décider comment normaliser, classer et combiner leurs scores.

Le choix pertinent n’est plus entre mots-clés et vecteurs. Il consiste à déterminer le niveau d’exactitude et de sens sémantique requis par chaque requête.

La recherche vectorielle dispose de son propre budget mémoire

Les discussions sur le matériel d’IA local commencent généralement par la RAM et la VRAM du modèle. Le RAG introduit un autre consommateur de mémoire : la récupération.

Lors d’OpenSearchCon, les discussions sur les sessions de recherche vectorielle abordent de plus en plus souvent la mémoire des graphes, la compression, le rappel, le débit et la latence P99 conjointement. À plus grande échelle d’embedding, la mémoire devient un élément de l’architecture de recherche plutôt qu’un simple détail d’implémentation.

La conséquence pratique est simple :

un serveur RAG local a besoin d’un budget de récupération tout autant que d’un budget de modèle.

« Cette machine peut-elle charger mon modèle ? » ne constitue plus une indication de dimensionnement suffisante lorsque le même hôte sert également à générer les embeddings des documents, à maintenir les index et à exécuter des agents.

Les agents font de l’observabilité une partie de la couche de données

L’observabilité traditionnelle cherche à savoir si une requête a échoué, quel service était lent et ce qu’indiquent les journaux.

Un agent ajoute des appels au modèle, des décisions de récupération et l’exécution d’outils.

Les traces d’agents OpenSearch actuelles utilisent les conventions OpenTelemetry pour représenter les opérations liées à l’agent, au LLM, à la récupération, aux embeddings et aux outils.

Cela permet de poser des questions beaucoup plus précises :

• La récupération a-t-elle pris trop de temps ?
• L’agent a-t-il appelé le même outil à plusieurs reprises ?
• Une boucle de nouvelle tentative a-t-elle augmenté l’utilisation de jetons ?
• Le modèle a-t-il fait un choix valide, mais l’outil a-t-il échoué ?
• Une nouvelle version de l’agent a-t-elle modifié le comportement d’exécution ?

La mémoire persistante crée un problème connexe de cycle de vie. Tout conserver indéfiniment augmente l’utilisation du stockage et permet à d’anciens contextes de rester consultables ; supprimer trop agressivement oblige l’agent à réapprendre sans cesse les informations utiles.

Cela signifie que la mémoire de l’agent nécessite des règles explicites pour :

• ce qui devient une mémoire à long terme,
• ce qui peut expirer,
• ce qui doit figurer dans un historique d’audit,
• et ce qui devrait cesser d’influencer les futures récupérations.

La mémoire de l’agent n’est pas seulement une fonctionnalité de récupération. C’est une politique de cycle de vie des données.

La recherche devient une limite de sécurité lorsque celui qui recherche peut agir

Un humain qui recherche des sauvegardes ayant échoué et un agent qui recherche des sauvegardes ayant échoué présentent des risques différents.

L’humain peut examiner le résultat. L’agent peut utiliser le résultat pour appeler un autre outil.

OpenSearch inclut un serveur MCP qui peut exposer la recherche, PPL, SQL et les informations du cluster aux agents compatibles.

Dès que la récupération fait partie d’une boucle d’action, les autorisations de recherche deviennent une limite des capacités de l’agent.

Trois cas réels d’IA auto-hébergée qui montrent pourquoi la couche de données est importante

La distinction entre l’état du modèle, de la récupération et de l’agent devient plus facile à comprendre dans de véritables systèmes auto-hébergés.

1. Un espace de travail RAG privé possède une charge de données distincte de l’inférence

AnythingLLM est un exemple utile. L’application peut gérer les documents, les embeddings et la recherche, tandis que le modèle de langage s’exécute localement, à distance ou via une API.

Le guide actuel sur le matériel requis pour le RAG d’AnythingLLM explicite cette distinction : l’ingestion des documents, les embeddings locaux, les données vectorielles et le stockage persistant ont leurs propres exigences en ressources, tandis que l’inférence locale du modèle doit être dimensionnée séparément.

C’est précisément l’erreur que la discussion d’OpenSearchCon aide à clarifier.

Un système RAG n’a pas une seule exigence matérielle. Il en a au moins deux :

• la charge de travail du modèle,
• et la charge de travail liée aux connaissances et à la recherche.

À mesure que la collection de documents s’agrandit, l’ingestion, l’indexation, les métadonnées et la sauvegarde peuvent devenir des goulots d’étranglement, même lorsque le modèle de langage ne change pas.

2. Un agent fonctionnant 24 h/24 et 7 j/7 crée un état d’exécution persistant

OpenClaw illustre l’autre aspect du modèle des deux index.

Une passerelle OpenClaw auto-hébergée peut maintenir des conversations persistantes, exécuter des appels d’outils, lancer des tâches planifiées, recevoir des webhooks et coordonner plusieurs workflows d’agents. Le guide de la passerelle privée pour agent IA traite l’agent comme un service toujours actif, plutôt que comme une fenêtre de discussion qui disparaît à la fermeture d’un ordinateur portable.

Cette persistance crée des questions opérationnelles que les conversations ordinaires n’abordent pas :

• Quel outil l’agent a-t-il appelé ?
• Quelle tâche a échoué pendant la nuit ?
• Combien de fois une opération a-t-elle été réessayée ?
• Quel contexte a été chargé avant la décision ?
• L’agent a-t-il signalé la réussite sans avoir terminé l’action ?

C’est pourquoi la session d’observabilité OpenClaw/Hermes d’OpenSearchCon est particulièrement pertinente pour les agents auto-hébergés. Dès que l’agent fonctionne sans surveillance, l’historique d’exécution devient une infrastructure, et non un simple détail de débogage.

3. La mémoire persistante devient partie intégrante de l’architecture de l’espace de travail

Un véritable workflow Hermes présente un troisième modèle. Au lieu de tout placer dans une base de données opaque pour agents, un espace de travail privé pour agent IA peut séparer l’environnement d’exécution de l’agent, la mémoire Markdown lisible par l’humain, l’historique Git, les canaux de communication et le stockage toujours actif.

Cette architecture est utile, car la « mémoire de l’agent » n’est pas nécessairement un magasin vectoriel monolithique.

Différentes informations peuvent nécessiter des règles de cycle de vie différentes :

La meilleure architecture mémoire n’est peut-être pas de « tout conserver pour toujours ». Il s’agit de déterminer quel type d’état représente réellement chaque élément d’information.

Quand l’auto-hébergement d’OpenSearch est-il réellement pertinent ?

Ces exemples ne signifient pas que tous les serveurs d’IA locaux doivent installer OpenSearch.

OpenSearch est lui-même une infrastructure avec état. L’exécuter signifie prendre en charge les index, la mémoire JVM, le stockage persistant, les instantanés, la conservation, les autorisations, les mises à niveau et la récupération.

La pile d’observabilité OpenSearch locale peut être exécutée via Docker Compose, mais les prérequis d’installation officiels requièrent déjà au moins 8 Go de RAM disponible.

Avant de le déployer, posez-vous les questions suivantes :

1. Quelle quantité de données suis-je réellement en train d’indexer ?
2. Ai-je besoin d’associer recherche par mots-clés et recherche sémantique ?
3. La même plateforme de données hébergera-t-elle également les journaux, les traces ou l’état des agents ?
4. Suis-je prêt à exploiter un autre service avec état ?

La question utile n’est pas « puis-je exécuter OpenSearch chez moi ? », mais « ma pile d’IA présente-t-elle une complexité suffisante en matière de recherche et d’observabilité pour le justifier ? »

Dimensionner le serveur d’IA pour plus que le modèle

Lorsque l’IA locale dépasse le cadre d’une interface de chat, la planification matérielle évolue.

Un serveur RAG ou d’agents de plus grande envergure peut avoir besoin de ressources pour :

• l’inférence du modèle,
• les embeddings,
• les index de recherche,
• le stockage des documents,
• les bases de données,
• les environnements d’exécution des agents,
• les journaux et les traces,
• et les sauvegardes.

Le guide actuel de dimensionnement du matériel pour Open WebUI illustre le même principe : la mémoire de l’application, le traitement des documents, les embeddings et le stockage RAG sont distincts des besoins, bien plus importants, en mémoire ou en VRAM d’un LLM local.

Pour les charges de travail qui nécessitent réellement davantage de mémoire système, des jeux de données répartis sur plusieurs disques et l’inférence GPU compatible sur une seule machine, un serveur d’IA local riche en stockage peut regrouper ces couches. Mais le matériel doit être choisi en fonction du modèle, du corpus vectoriel, de la durée de conservation et de la simultanéité réels, plutôt qu’en fonction de l’étiquette « serveur d’IA ».

Davantage de GPU ne résout pas un index de recherche sous-dimensionné, et davantage de stockage ne résout pas un manque de mémoire pour le modèle.

Le serveur d’IA a besoin d’une couche de données, pas seulement d’un modèle plus volumineux

Les discussions sur l’IA locale se concentrent naturellement sur les modèles, car ceux-ci dominent les classements de référence.

Mais les systèmes RAG et les agents fonctionnant sur le long terme accumulent progressivement une autre couche d’infrastructure :

• les documents et les métadonnées,
• les index lexicaux et vectoriels,
• la mémoire de l’agent,
• les intégrations d’outils,
• les journaux et les traces d’exécution,
• les autorisations,
• et les politiques de conservation.

Le modèle génère la réponse. La couche de données détermine quelles preuves lui parviennent, quel contexte est conservé et si quelqu’un peut expliquer ce qui s’est passé lorsque l’agent adopte un comportement inattendu.

C’est l’enjeu plus vaste d’OpenSearchCon 2026.

Les agents d’IA transforment la recherche, qui passe du statut de fonctionnalité à celui d’infrastructure.

Un agent sérieux doit donc pouvoir répondre de manière fiable à deux questions persistantes :

1. Que devrait savoir cet agent à cet instant ?
2. Qu’a réellement fait cet agent ?

Une base de données vectorielle peut aider pour le premier point. Les infrastructures d’agents en production doivent tôt ou tard répondre aux deux.

FAQ

Quand aura lieu OpenSearchCon North America 2026 ?

OpenSearchCon North America 2026 se tiendra du 22 au 24 septembre à San Jose, en Californie. La conférence porte sur la recherche open source, l’observabilité, la récupération vectorielle, le RAG et l’IA agentique.

OpenSearch est-il une base de données vectorielle ?

OpenSearch peut stocker et rechercher des plongements vectoriels, mais sa portée est plus large que celle d’une base de données vectorielle dédiée. Il prend également en charge la recherche lexicale, la récupération hybride, le filtrage par métadonnées, l’analytique et les charges de travail d’observabilité.

OpenSearch est-il adapté au RAG ?

OpenSearch peut être un excellent choix lorsque le RAG nécessite une recherche hybride, un filtrage par métadonnées et par version, une évaluation de la pertinence ou une vaste collection de documents évolutive. Les systèmes RAG personnels plus modestes peuvent être plus faciles à exploiter avec une infrastructure plus légère.

Qu’est-ce que la recherche hybride dans OpenSearch ?

La recherche hybride combine des signaux lexicaux tels que BM25 avec une récupération sémantique ou vectorielle. Elle est particulièrement utile lorsqu’une requête contient à la fois des identifiants techniques exacts et une intention plus large exprimée en langage naturel.

OpenSearch peut-il surveiller les agents d’IA ?

Oui. OpenSearch Agent Traces utilise une télémétrie fondée sur OpenTelemetry pour exposer les appels aux modèles, les récupérations et l’utilisation des outils, ainsi que les informations de latence et de nombre de jetons.

OpenSearch prend-il en charge MCP ?

Oui. OpenSearch fournit des fonctionnalités MCP qui permettent aux agents compatibles d’accéder à la recherche, à PPL, à SQL et à d’autres outils de données. Les autorisations restent importantes, car les informations récupérées peuvent alimenter directement les actions des agents.

Ai-je besoin d’OpenSearch pour un serveur RAG local ?

Pas nécessairement. Une petite collection personnelle de documents peut généralement utiliser une infrastructure de récupération plus simple. OpenSearch devient plus intéressant lorsque le système doit gérer des index volumineux et évolutifs, la recherche hybride, une base de connaissances partagée, l’observabilité ou plusieurs charges de travail d’agents.

De combien de RAM OpenSearch auto-hébergé a-t-il besoin ?

Les besoins dépendent de la taille de l’index, des dimensions des vecteurs, de la charge des requêtes et de la durée de conservation. La pile locale OpenSearch Observability indique actuellement au moins 8 Go de RAM disponible comme prérequis, tandis que les charges de travail impliquant davantage de vecteurs et de télémétrie peuvent en nécessiter beaucoup plus.