La recherche n'est pas morte, elle s'est simplement déplacée

Nous sommes donc passés d'une recherche de contexte à l'aide d'une zone de texte et de l'utilisation des informations (le contexte) renvoyées pour construire les réponses nous-mêmes, à l'utilisation du langage naturel pour dire à un agent ce que nous voulons et lui permettre de rechercher et de compiler automatiquement la réponse pour nous. Nombreux sont ceux qui, dans le monde de la technologie, soulignent ce changement et proclament que "la recherche est morte" (certes, le monde du référencement et des mots publicitaires est en train de changer: les GEO, par exemple), mais la recherche reste absolument essentielle pour les opérations agentiques - elle est simplement réalisée en grande partie à l'abri des regards par le biais d'outils.

Auparavant, les humains étaient les principaux arbitres de la pertinence subjective : chaque utilisateur a ses propres raisons d'effectuer une recherche, et son expérience personnelle influence la précision relative des résultats. Si nous voulons que les agents parviennent à la même conclusion (ou à une meilleure conclusion) que nous, nous devons nous assurer que les informations contextuelles auxquelles ils ont accès sont aussi proches que possible de notre intention subjective. Nous devons concevoir le contexte dans lequel nous fournissons les LLM en fonction de cet objectif !

Générer du contexte avec la recherche hybride

Je vous rappelle que la recherche hybride d'Elastic combine les points forts de la recherche traditionnelle par mot-clé (flexibilité syntaxique, précision des mots-clés et évaluation de la pertinence) avec la compréhension sémantique de la recherche par similarité vectorielle, et offre plusieurs techniques de reclassement. Cette synergie (il n'y a jamais eu d'usage plus vrai de ce mot !) permet d'obtenir des résultats très pertinents, avec des requêtes qui peuvent être beaucoup plus nuancées dans la manière dont elles ciblent le contenu. Il ne s'agit pas seulement d'appliquer la pertinence subjective à l'une des étapes de la recherche ; il s'agit en fait d'inclure la notation de la pertinence dans la première étape de la recherche, ainsi que tous les autres modes à la fois.

Précision supérieure & efficacité

L'utilisation d'une plateforme de données capable de fournir des services de recherche, d'extraction et de reclassement distribués en tant que principal moteur de recherche contextuelle est très judicieuse. Vous pouvez utiliser une syntaxe d'interrogation avancée pour ajouter la composante manquante de l'intention subjective et filtrer le contenu qui pourrait distraire ou brouiller la valeur des informations contextuelles renvoyées. Vous pouvez sélectionner l'une des options syntaxiques individuelles disponibles ou combiner les modalités dans une recherche unique qui cible chaque type de données de la manière qu'elle comprend le mieux, puis les combiner ou les réordonner avec le reranking. Vous pouvez filtrer la réponse pour qu'elle ne contienne que les champs/valeurs que vous souhaitez, en évitant les données superflues. Au service des agents, cette souplesse de ciblage vous permet de créer des outils extrêmement précis dans la manière dont ils récupèrent le contexte.

Raffinement du contexte (agrégations et signaux non liés au contenu)

Les agrégations peuvent être particulièrement utiles pour façonner le contenu d'un outil dans la fenêtre contextuelle. Les agrégations fournissent naturellement des faits numériques sur la forme des données contextuelles renvoyées, ce qui permet aux LLM de raisonner plus facilement et avec plus de précision. Les agrégations pouvant être imbriquées hiérarchiquement, il est facile d'ajouter des détails à plusieurs niveaux pour que le mécanisme d'apprentissage tout au long de la vie génère une compréhension plus nuancée. Les agrégations peuvent également faciliter la gestion de la taille de la fenêtre contextuelle - vous pouvez facilement réduire le résultat d'une requête de 100 000 documents à quelques centaines de tokens d'informations agrégées.

Les signaux non liés au contenu sont les indicateurs inhérents à vos données qui vous donnent une vue d'ensemble de ce que vous regardez ; il s'agit des caractéristiques supplémentaires des résultats, comme la popularité, la fraîcheur, la géolocalisation, les catégories, la diversité des hôtes ou les fourchettes de prix. Ces éléments d'information peuvent être utiles à l'agent pour évaluer l'importance du contexte qu'il a reçu. Quelques exemples simples permettent d'illustrer au mieux ce propos :

• Renforcer le contenu récemment publié et populaire - Imaginez que vous disposiez d'une base de connaissances contenant des articles. Vous souhaitez trouver des articles pertinents par rapport à la requête d'un utilisateur, mais vous voulez également favoriser les articles qui sont récents et qui ont été jugés utiles par d'autres utilisateurs (par exemple, qui ont un nombre élevé de "likes" ). Dans ce scénario, nous pouvons utiliser une recherche hybride pour trouver les articles pertinents, puis les classer en fonction de leur date de publication et de leur popularité.

• Recherche dans le domaine du commerce électronique avec ajustement des ventes et des stocks - Dans le cadre du commerce électronique, vous souhaitez montrer aux clients les produits qui correspondent à leur recherche, mais vous voulez également promouvoir les produits qui se vendent bien et qui sont en stock. Vous pouvez également déclasser les produits dont le stock est faible afin d'éviter la frustration des clients.

• Priorité aux problèmes de haute gravité dans un système de suivi des bogues - Pour une équipe de développement de logiciels, lorsqu'elle recherche des problèmes, il est essentiel de faire apparaître en premier les problèmes de haute gravité, de haute priorité et ceux qui ont été récemment mis à jour. Vous pouvez utiliser des signaux secondaires tels que "criticité" et "le plus discuté" pour pondérer les différents facteurs de manière indépendante, en veillant à ce que les questions les plus critiques et les plus activement discutées soient placées en tête.

Ces exemples de requêtes et d'autres sont disponibles dans la page de contenu Elasticsearch Labs qui les accompagne.

Renforcement de la sécurité

Un avantage essentiel de l'exploitation d'une couche de vitesse alimentée par la recherche telle qu'Elastic pour l'ingénierie contextuelle est son cadre de sécurité intégré. La plateforme d'Elastic garantit que le contexte fourni aux opérations d'IA agentique et générative respecte et protège les informations privées sensibles grâce à un contrôle d'accès granulaire basé sur les rôles (RBAC) et un contrôle d'accès basé sur les attributs (ABAC). Cela signifie que non seulement les requêtes sont traitées avec efficacité, mais aussi que les résultats sont filtrés en fonction des autorisations spécifiques de l'agent ou de l'utilisateur à l'origine de la demande.

Les agents s'exécutent en tant qu'utilisateur authentifié, de sorte que la sécurité est implicitement appliquée par le biais des fonctions de sécurité intégrées à la plateforme :

• Permissions précises : Définissez l'accès au niveau du document, du champ ou même du terme, en veillant à ce que les agents d'intelligence artificielle ne reçoivent que les données qu'ils sont autorisés à consulter.

• Contrôle d'accès basé sur les rôles (RBAC) : Attribuer des rôles aux agents ou aux utilisateurs, en leur donnant accès à des ensembles de données ou à des fonctionnalités spécifiques en fonction des responsabilités qu'ils ont définies.

• Contrôle d'accès basé sur les attributs (ABAC) : Mettre en œuvre des politiques d'accès dynamiques basées sur les attributs des données, de l'utilisateur ou de l'environnement, permettant une sécurité hautement adaptable et consciente du contexte.

• Sécurité au niveau du document (DLS) et sécurité au niveau du champ (FLS) : Ces capacités garantissent que, même au sein d'un document récupéré, seules les parties autorisées sont visibles, empêchant ainsi l'exposition d'informations sensibles.

• Intégration avec la sécurité de l'entreprise : Intégration transparente avec les systèmes de gestion des identités existants (tels que LDAP, SAML, OIDC) afin d'appliquer des politiques de sécurité cohérentes dans l'ensemble de l'entreprise.

En intégrant ces mesures de sécurité directement dans le mécanisme de récupération du contexte, Elastic agit comme un gardien sécurisé, garantissant que les agents d'intelligence artificielle opèrent dans des limites de données définies, empêchant l'exposition de données non autorisées et maintenant la conformité avec les réglementations en matière de confidentialité des données. Cela est primordial pour instaurer la confiance dans les systèmes d'IA agentique qui traitent des informations confidentielles ou exclusives.

En outre, l'utilisation d'une couche de vitesse unifiée sur les sources de données de l'entreprise permet d'alléger les charges de requêtes ad hoc inattendues sur ces référentiels que les outils agentiques créeraient. Vous disposez d'un lieu unique pour tout rechercher en temps quasi réel, et d'un lieu unique pour appliquer les contrôles de sécurité et de gouvernance.

Outils hybrides basés sur la recherche

La plateforme Elastic comporte certaines fonctionnalités de base (et d'autres sont en cours d'élaboration) qui donnent un coup de fouet à l'ingénierie contextuelle. L'essentiel est que la plateforme offre une multitude de moyens de réaliser des choses, avec la flexibilité de s'adapter, de changer et d'étendre les méthodes au fur et à mesure que l'écosystème de l'IA progresse.

Présentation de l'Agent Builder

Elastic Agent Builder est notre première incursion dans le domaine des outils d'intelligence artificielle conçus pour dialoguer avec les données que vous stockez déjà dans Elastic. Agent Builder offre une interface de chat qui permet aux utilisateurs de créer et de gérer leurs propres agents et outils dans Kibana. Il est livré avec des serveurs MCP et A2A intégrés, des API programmatiques et un ensemble d'outils système prédéfinis pour l'interrogation et l'exploration des index Elasticsearch, ainsi que pour la génération de requêtes ES|QL à partir du langage naturel. Agent Builder vous permet de créer des outils personnalisés qui ciblent et sculptent les données contextuelles renvoyées à l'agent par le biais d'une syntaxe de requête ES|QL expressive.

Comment ES|QL effectue-t-il la recherche hybride ? La capacité de base est obtenue par la combinaison du type de champ semantic_text et descommandesFORK/FUSE (FUSE utilise par défaut RRF pour fusionner les résultats de chaque fourchette). Voici un exemple simple de recherche de produit fictif :

La clause EVAL incluse dans chacune des branches FORK de l'exemple ci-dessus n'est pas strictement nécessaire ; elle n'est incluse que pour démontrer comment vous pouvez suivre la modalité de recherche à partir de laquelle un résultat donné a été retourné.

Recherche de modèles

Supposons que vous souhaitiez faire pointer vos propres outils agentiques externes vers votre déploiement Elastic. Au lieu d'ES|QL, vous souhaitez utiliser des extracteurs à plusieurs niveaux ou réutiliser la syntaxe DSL existante que vous avez développée, et vous voulez également pouvoir contrôler les entrées acceptées par la requête, la syntaxe utilisée pour exécuter la recherche et les champs renvoyés dans le résultat. Les modèles de recherche permettent aux utilisateurs de définir des structures prédéfinies pour les modèles de recherche courants, ce qui améliore l'efficacité et la cohérence de la recherche de données. Ceci est particulièrement bénéfique pour les outils agentiques qui interagissent avec les API de recherche, car ils aident à normaliser le code standard et permettent une itération plus rapide de la logique de recherche. Et si vous devez modifier l'un de ces facteurs, il vous suffit de mettre à jour le modèle de recherche et voilà, les changements sont appliqués. Si vous cherchez un exemple de modèles de recherche en action avec des outils agentiques, jetez un coup d'œil au blog d'Elasticsearch Labs "MCP for intelligent search", qui utilise un modèle de recherche derrière un appel d'outil à partir d'un serveur MCP externe.

Flux de travail intégrés (FTW !)

L'une des choses les plus difficiles à gérer dans notre nouveau monde d'IA agentique est la nature non déterministe des agents "raisonnants" semi-autonomes et autodirigés. L'ingénierie contextuelle est une discipline essentielle de l'IA agentique : il s'agit des techniques qui permettent de limiter les conclusions possibles de notre agent à ce que nous connaissons de la vérité de terrain. Même avec une fenêtre contextuelle très précise et pertinente (lorsque nous sortons du domaine des faits numériques), il nous manque toujours cette petite assurance que la réponse de l'agent est entièrement reproductible et fiable.

Lorsque vous soumettez plusieurs fois la même demande à un agent, les réponses peuvent être essentiellement les mêmes, avec juste une petite différence dans la réponse. C'est généralement bien pour les requêtes simples, peut-être à peine perceptible, et nous pouvons essayer de façonner le résultat à l'aide de techniques d'ingénierie contextuelle. Mais plus les tâches que nous demandons à nos agents sont complexes, plus il y a de chances qu'une ou plusieurs sous-tâches introduisent une variance qui modifie légèrement le résultat final. La situation s'aggravera probablement à mesure que nous commencerons à nous appuyer davantage sur les communications entre agents, et ces écarts deviendront cumulatifs. Cela confirme l'idée que les outils avec lesquels nos agents interagissent doivent être très souples et adaptables pour cibler précisément les données contextuelles, et qu'ils doivent répondre dans un format de sortie attendu. Il indique également que pour de nombreux cas d'utilisation, nous avons besoin de diriger les interactions entre l'agent et l'outil - c'est là que les flux de travail entrent en jeu !

Elastic disposera bientôt de flux de travail entièrement personnalisables, intégrés au cœur de la plateforme. Ces flux de travail pourront fonctionner avec des agents et des outils de manière bidirectionnelle, de sorte que les flux de travail pourront appeler des agents et des outils, et que les agents et les outils pourront appeler des flux de travail. L'intégration complète de ces capacités dans la même plateforme d'IA de recherche, où toutes vos données sont stockées, sera un facteur de transformation. Bientôt, très bientôt !

Elastique comme la banque de mémoire unifiée

En tant que plateforme de données distribuées conçue pour la recherche en temps quasi réel, Elastic remplit naturellement les fonctions de mémoire à long terme pour les systèmes d'IA agentique. Avec l'expérience de chat intégrée d'Agent Builder, nous disposons également d'un suivi et d'une gestion de la mémoire à court terme et de l'historique des chats. Et comme toute la plateforme est fondée sur l'API, il est extrêmement facile d'utiliser Elastic comme plateforme pour conserver les résultats contextuels d'un outil (et pouvoir s'y référer ultérieurement) qui pourraient dépasser la fenêtre contextuelle de l'agent ; cette technique est parfois appelée "prise de notes" dans les cercles de l'ingénierie contextuelle.

Le fait de disposer d'une mémoire à court terme et d'une mémoire à long terme sur la même plateforme de recherche présente de nombreux avantages intrinsèques : imaginez que vous puissiez utiliser les historiques de chat et les réponses contextuelles persistantes pour influencer sémantiquement les futures interactions de chat, ou pour effectuer une analyse des menaces, ou pour créer des produits de données persistants générés automatiquement à partir d'appels d'outils fréquemment répétés... Les possibilités sont infinies !

Conclusion

L'émergence de grands modèles de langage a modifié la façon dont nous pouvons faire correspondre le contenu et les méthodes que nous utilisons pour interroger nos données. Nous nous éloignons rapidement de notre monde actuel, où les humains effectuent les recherches, les considérations contextuelles et le raisonnement logique pour répondre à leurs propres questions, pour passer à un monde où ces étapes sont largement automatisées grâce à l'IA agentique. Pour que nous puissions faire confiance aux réponses générées que nous recevons, nous devons avoir l'assurance que l'agent a pris en compte toutes les informations les plus pertinentes (y compris le facteur de la pertinence subjective) pour générer sa réponse. Notre principale méthode pour rendre l'IA agentique digne de confiance consiste à ancrer les outils qui récupèrent un contexte supplémentaire grâce aux techniques de RAG et d'ingénierie contextuelle, mais la manière dont ces outils effectuent la récupération initiale peut être déterminante pour la précision de la réponse.

La plateforme d'IA Elastic Search offre la flexibilité et les avantages de la recherche hybride, ainsi que plusieurs fonctionnalités intégrées qui aident l'IA agentique en termes de précision, de performance et d'évolutivité ; en d'autres termes, Elastic est une plateforme fantastique pour plusieurs aspects de l'ingénierie contextuelle ! En normalisant la recherche de contexte via une plateforme de recherche, nous simplifions les opérations de l'outil agentique sur plusieurs fronts - et comme l'oxymore "ralentir pour aller plus vite", la simplicité au niveau de la couche de génération de contexte signifie une IA agentique plus rapide et plus digne de confiance.

Une nouvelle façon d'interagir avec les données

L'IA générative (genAI) et l'IA agentique agissent différemment de la recherche traditionnelle. Alors que nous commencions à rechercher des informations par une recherche ("laissez-moi chercher cela sur Google..."), l'action initiale de l'IA générique et des agents se fait généralement par le biais d'un langage naturel saisi dans une interface de dialogue en ligne. L'interface de chat est une discussion avec un LLM qui utilise sa compréhension sémantique pour transformer notre question en une réponse distillée, une réponse résumée semblant provenir d'un oracle qui a une connaissance étendue de toutes sortes d'informations. Ce qui fait vraiment la différence, c'est la capacité du LLM à produire des phrases cohérentes et réfléchies qui rassemblent les éléments de connaissance qu'il fait apparaître - même s'ils sont inexacts ou totalement hallucinés, ils ont une certaine véracité.

Cette vieille barre de recherche avec laquelle nous avons été tellement habitués à interagir peut être considérée comme le moteur RAG que nous utilisions lorsque nous étions nous-mêmes l'agent de raisonnement. Aujourd'hui, même les moteurs de recherche Internet transforment notre expérience de recherche lexicale bien connue en aperçus pilotés par l'IA qui répondent à la requête par un résumé des résultats, ce qui permet aux utilisateurs d'éviter de cliquer et d'évaluer eux-mêmes les résultats individuels.

IA générative & RAG

L'IA générative tente d'utiliser sa compréhension sémantique du monde pour analyser l'intention subjective exprimée dans une demande de chat, puis utilise ses capacités d'inférence pour créer une réponse d'expert à la volée. L'interaction générative de l'IA comporte plusieurs parties : elle commence par l'entrée/la requête de l'utilisateur, les conversations précédentes dans la session de chat peuvent être utilisées comme contexte supplémentaire, et l'instruction qui indique au LLM comment raisonner et quelles sont les procédures à suivre pour construire la réponse. Les messages-guides ont évolué, passant d'une simple orientation du type ", "Expliquez-moi cela comme si j'étais un enfant de cinq ans", à des descriptions complètes de la manière de traiter les demandes. Ces décompositions comprennent souvent des sections distinctes décrivant les détails du personnage/rôle de l'IA, le raisonnement avant la génération/le processus de réflexion interne, les critères objectifs, les contraintes, le format de sortie, le public, ainsi que des exemples pour aider à démontrer les résultats attendus.

En plus de la requête de l'utilisateur et de l'invite du système, la génération augmentée de recherche (RAG) fournit des informations contextuelles supplémentaires dans ce que l'on appelle une "fenêtre contextuelle". RAG a été un ajout essentiel à l'architecture ; c'est ce que nous utilisons pour informer le LLM des pièces manquantes dans sa compréhension sémantique du monde.

Les fenêtres contextuelles peuvent être un peu tatillonnes en ce qui concerne le contenu, l'emplacement et la quantité que vous leur donnez. Le contexte sélectionné est bien sûr très important, mais le rapport signal/bruit du contexte fourni est également important, de même que la longueur de la fenêtre.

Trop peu d'informations

Le fait de fournir trop peu d'informations dans une fenêtre de requête, d'invite ou de contexte peut entraîner des hallucinations, car le LLM ne peut pas déterminer avec précision le contexte sémantique correct à partir duquel générer une réponse. La similarité vectorielle de la taille des morceaux de documents pose également des problèmes - une question courte et simple peut ne pas correspondre sémantiquement aux documents riches et détaillés trouvés dans nos bases de connaissances vectorisées. Des techniques d'expansion des requêtes telles que Hypothetical Document Embeddings (HyDE) ont été développées. Elles utilisent les LLM pour générer une réponse hypothétique qui est plus riche et plus expressive que la requête courte. Le danger ici, bien sûr, est que le document hypothétique est lui-même une hallucination qui éloigne encore plus le LLM du contexte correct.

Trop d'informations

Tout comme pour nous, un excès d'informations dans une fenêtre contextuelle peut submerger un MLD et le rendre confus quant aux éléments importants. Le débordement de contexte (ou "pourriture de contexte") affecte la qualité et les performances des opérations d'IA générative ; il a un impact considérable sur le "budget d'attention" du LLM (sa mémoire de travail) et dilue la pertinence parmi de nombreux éléments concurrents. Le concept de "rotation du contexte" comprend également l'observation selon laquelle les LLM ont tendance à avoir un biais de position - ils préfèrent le contenu au début ou à la fin d'une fenêtre contextuelle au contenu de la section centrale.

Informations distrayantes ou contradictoires

Plus la fenêtre contextuelle est grande, plus il y a de chances qu'elle contienne des informations superflues ou contradictoires qui peuvent distraire le LLM de la sélection et du traitement du contexte correct. D'une certaine manière, il s'agit d'un problème d'entrée et de sortie de déchets : le simple fait de déverser un ensemble de résultats de documents dans une fenêtre contextuelle donne au LLM beaucoup d'informations à mâcher (potentiellement trop), mais en fonction de la manière dont le contexte a été sélectionné, il y a une plus grande possibilité que des informations contradictoires ou non pertinentes s'infiltrent dans le système.

IA agentique

Je vous avais dit qu'il y avait beaucoup de terrain à couvrir, mais nous l'avons fait - nous parlons enfin de sujets liés à l'IA agentique ! L'IA agentique est une nouvelle utilisation très intéressante des interfaces de chat LLM qui développe la capacité de l'IA générative (peut-on déjà l'appeler "ancienne" ?) à synthétiser des réponses basées sur ses propres connaissances et sur les informations contextuelles que vous lui fournissez. Au fur et à mesure que l'IA générative gagnait en maturité, nous avons réalisé qu'il existait un certain niveau de tâches et d'automatisation que nous pouvions confier aux LLM, initialement reléguées à des activités fastidieuses à faible risque qui peuvent facilement être vérifiées/validées par un être humain. En peu de temps, ce champ d'application initial s'est élargi : une fenêtre de discussion LLM peut désormais être l'étincelle qui envoie un agent d'intelligence artificielle planifier, exécuter, évaluer et adapter son plan de manière itérative afin d'atteindre l'objectif spécifié. Les agents ont accès au raisonnement de leur LLM, à l'historique des discussions et à la mémoire de pensée (telle qu'elle est), et ils disposent également d'outils spécifiques qu'ils peuvent utiliser à cette fin. Nous voyons aussi maintenant des architectures qui permettent à un agent de haut niveau de fonctionner comme l'orchestrateur de plusieurs sous-agents, chacun avec ses propres chaînes logiques, ses jeux d'instructions, son contexte et ses outils.

Les agents sont le point d'entrée d'un flux de travail essentiellement automatisé : ils sont autodirigés en ce sens qu'ils sont capables de discuter avec un utilisateur et d'utiliser ensuite la "logique" pour déterminer les outils dont ils disposent pour répondre à la question de l'utilisateur. Les outils sont généralement considérés comme passifs par rapport aux agents et construits pour effectuer un seul type de tâche. Les types de tâches qu'un outil pourrait accomplir sont en quelque sorte illimités (ce qui est vraiment passionnant !), mais l'une des principales tâches des outils est de rassembler des informations contextuelles qu'un agent doit prendre en compte lors de l'exécution de son flux de travail.

En tant que technologie, l'IA agentique en est encore à ses balbutiements et est sujette à l'équivalent LLM du trouble déficitaire de l'attention - elle oublie facilement ce qu'on lui a demandé de faire, et part souvent faire d'autres choses qui ne faisaient pas du tout partie du cahier des charges. Sous cette apparente magie, les capacités de "raisonnement" des LLM sont toujours basées sur la prédiction du prochain jeton le plus probable dans une séquence. Pour que le raisonnement (ou, un jour, l'intelligence artificielle générale (AGI)) devienne fiable et digne de confiance, nous devons être en mesure de vérifier que, lorsqu'on leur donne les informations correctes et les plus récentes, ils raisonnent de la manière que nous attendons d'eux (et nous donnent peut-être ce petit plus auquel nous n'aurions pas pensé nous-mêmes). Pour ce faire, les architectures agentiques devront être capables de communiquer clairement (protocoles), de respecter les flux de travail et les contraintes que nous leur imposons (garde-fous), de se rappeler où elles en sont dans une tâche (état), de gérer leur espace mémoire disponible et de valider que leurs réponses sont exactes et répondent aux critères de la tâche.

Parlez-moi dans une langue que je peux comprendre

Comme c'est souvent le cas dans les nouveaux domaines de développement (en particulier dans le monde des LLM), il existait initialement plusieurs approches pour les communications entre agents et outils, mais elles ont rapidement convergé vers le protocole de contexte de modèle (MCP) en tant que norme de facto. La définition du protocole de contexte de modèle est vraiment dans le nom - c'est le protocole qu'un modèle utilise pour demander et recevoir des informations contextuelles. MCP agit comme un adaptateur universel permettant aux agents LLM de se connecter à des outils et à des sources de données externes ; il simplifie et normalise les API de manière à ce que les différents cadres et outils LLM puissent facilement interopérer. Cela fait de MCP une sorte de point de pivot entre la logique d'orchestration et les invites du système données à un agent pour qu'il les exécute de manière autonome au service de ses objectifs, et les opérations envoyées à des outils pour qu'ils les exécutent de manière plus isolée (isolée au moins par rapport à l'agent qui en est à l'origine).

Cet écosystème est tellement nouveau que chaque direction d'expansion semble être une nouvelle frontière. Nous disposons de protocoles similaires pour les interactions entre agents(Agent2Agent (A2A) natch !) ainsi que d'autres projets visant à améliorer la mémoire de raisonnement des agents(ReasoningBank), à sélectionner le meilleur serveur MCP pour le travail à effectuer(RAG-MCP), et à utiliser l'analyse sémantique telle que la classification "zero-shot" et la détection de motifs sur les entrées et les sorties comme garde-fous pour contrôler ce sur quoi un agent est autorisé à opérer.

Vous avez peut-être remarqué que l'intention sous-jacente de chacun de ces projets est d'améliorer la qualité et le contrôle des informations renvoyées à une fenêtre contextuelle agent/genAI ? Alors que l'écosystème de l'IA agentique continue de développer la capacité à mieux traiter ces informations contextuelles (pour les contrôler, les gérer et les exploiter), il sera toujours nécessaire d'extraire les informations contextuelles les plus pertinentes pour que l'agent puisse les mouliner.

Bienvenue dans l'ingénierie contextuelle !

Si vous êtes familier avec les termes de l'IA générative, vous avez probablement entendu parler de "l'ingénierie des messages" - à ce stade, il s'agit presque d'une pseudo-science à part entière. L'ingénierie des invites est utilisée pour trouver les moyens les meilleurs et les plus efficaces de décrire de manière proactive les comportements que vous souhaitez que le MLD utilise pour générer sa réponse. L'"ingénierie du contexte" étend les techniques d'"ingénierie de l'invite" au-delà du côté de l'agent pour couvrir également les sources de contexte et les systèmes disponibles du côté des outils du protocole MCP, et comprend les thèmes généraux de la gestion, du traitement et de la génération du contexte :

• Gestion du contexte - liée au maintien de l'efficacité de l'état et du contexte dans des flux de travail agentiques de longue durée et/ou plus complexes. Planification itérative, suivi et orchestration des tâches et de l'utilisation des outils pour atteindre les objectifs de l'agent. En raison du "budget d'attention" limité dont disposent les agents, la gestion du contexte concerne principalement les techniques qui permettent d'affiner la fenêtre contextuelle afin de capturer à la fois la portée la plus complète et les éléments les plus importants du contexte (sa précision par rapport à son rappel !). Les techniques comprennent la compression, le résumé et la persistance du contexte des étapes précédentes ou des appels d'outils pour faire de la place dans la mémoire de travail pour le contexte supplémentaire des étapes suivantes.

• Traitement du contexte - Les étapes logiques et, espérons-le, essentiellement programmatiques visant à intégrer, normaliser ou affiner le contexte acquis à partir de sources disparates afin que l'agent puisse raisonner sur l'ensemble du contexte d'une manière quelque peu uniforme. Le travail sous-jacent consiste à faire en sorte que le contexte provenant de toutes les sources (invites, RAG, mémoire, etc.) soit consommé par l'agent le plus efficacement possible.

• Génération de contexte - Si le traitement du contexte consiste à rendre le contexte récupéré utilisable par l'agent, alors la génération de contexte donne à l'agent la possibilité de demander et de recevoir ces informations contextuelles supplémentaires à volonté, mais aussi avec des contraintes.

Les différents éphémères des applications de chat du LLM correspondent directement (et parfois de manière redondante) à ces fonctions de haut niveau de l'ingénierie contextuelle :

• Instructions / invite du système - Les invites constituent l'échafaudage de la manière dont l'activité générative (ou agentique) de l'IA orientera sa réflexion vers la réalisation de l'objectif de l'utilisateur. Les messages-guides constituent un contexte à part entière ; il ne s'agit pas seulement d'instructions tonales - ils comprennent aussi souvent une logique d'exécution des tâches et des règles telles que "réfléchir étape par étape" ou "respirer profondément" avant de répondre afin de s'assurer que la réponse répond pleinement à la demande de l'utilisateur. Des tests récents ont montré que les langages de balisage sont très efficaces pour encadrer les différentes parties d'une invite, mais il faut également veiller à calibrer les instructions de manière à ce qu'elles soient à la fois trop vagues et trop spécifiques ; nous voulons donner suffisamment d'instructions pour que le LLM trouve le bon contexte, mais sans être trop prescriptif au point de passer à côté d'idées inattendues.

• Mémoire à court terme (état/historique) - La mémoire à court terme correspond essentiellement aux interactions de la session de chat entre l'utilisateur et le LLM. Ils sont utiles pour affiner le contexte lors des sessions en direct et peuvent être sauvegardés pour être retrouvés et poursuivis ultérieurement.

• Mémoire à long terme - La mémoire à long terme doit être constituée d'informations utiles pour plusieurs sessions. Et il ne s'agit pas seulement de bases de connaissances spécifiques à un domaine auxquelles on accède par le biais de RAG ; des recherches récentes utilisent les résultats de demandes d'IA agentique/générative antérieures pour apprendre et se référer aux interactions agentiques actuelles. Certaines des innovations les plus intéressantes dans le domaine de la mémoire à long terme sont liées à l'ajustement de la manière dont l'état est stocké et relié afin que les agents puissent reprendre là où ils se sont arrêtés.

• Sortie structurée - La cognition nécessite un effort, il n'est donc pas surprenant que même avec des capacités de raisonnement, les LLM (tout comme les humains) veulent dépenser moins d'effort lorsqu'ils pensent, et en l'absence d'une API ou d'un protocole défini, avoir une carte (un schéma) sur la façon de lire les données renvoyées par un appel d'outil est extrêmement utile. L'inclusion de sorties structurées dans le cadre agentique contribue à rendre ces interactions machine-machine plus rapides et plus fiables, en réduisant les besoins d'analyse.

• Outils disponibles - Les outils peuvent faire toutes sortes de choses, de la collecte d'informations supplémentaires (par exemple, en émettant des requêtes RAG vers les référentiels de données de l'entreprise, ou par le biais d'API en ligne) à l'exécution d'actions automatisées au nom de l'agent (comme la réservation d'une chambre d'hôtel sur la base des critères de la demande de l'agent). Les outils peuvent également être des sous-agents disposant de leur propre chaîne de traitement agentique.

• Retrieval Augmented Generation (RAG) - J'aime beaucoup la description de RAG en tant qu'"intégration dynamique des connaissances". Comme décrit précédemment, le RAG est la technique permettant de fournir les informations supplémentaires auxquelles le LLM n'a pas eu accès lors de sa formation, ou bien il s'agit d'une réitération des idées que nous pensons être les plus importantes pour obtenir la bonne réponse - celle qui est la plus pertinente par rapport à notre requête subjective.

Une puissance cosmique phénoménale, un espace de vie minuscule !

L'IA agentique a tant de nouveaux domaines fascinants et passionnants à explorer ! Il y a encore beaucoup de problèmes traditionnels de recherche et de traitement de données à résoudre, mais aussi de toutes nouvelles catégories de défis qui commencent seulement à être exposés à la lumière du jour dans la nouvelle ère des LLM. Bon nombre des problèmes immédiats auxquels nous sommes confrontés aujourd'hui sont liés à l'ingénierie contextuelle, c'est-à-dire au fait de fournir aux MFR les informations contextuelles supplémentaires dont ils ont besoin sans surcharger leur espace de mémoire de travail, qui est limité.

La flexibilité des agents semi-autonomes ayant accès à un ensemble d'outils (et à d'autres agents) donne lieu à tant de nouvelles idées pour la mise en œuvre de l'IA qu'il est difficile d'imaginer les différentes façons dont nous pourrions assembler les pièces du puzzle. La plupart des recherches actuelles s'inscrivent dans le domaine de l'ingénierie contextuelle et se concentrent sur la construction de structures de gestion de la mémoire capables de gérer et de suivre de plus grandes quantités de contexte. En effet, les problèmes de réflexion approfondie que nous voulons vraiment que les LLM résolvent présentent une complexité accrue et des étapes de réflexion plus longues et multiphases, où la mémorisation est extrêmement importante.

Une grande partie de l'expérimentation en cours dans le domaine consiste à essayer de trouver la gestion optimale des tâches et les configurations d'outils pour alimenter la gueule de l'agent. Chaque appel d'outil dans la chaîne de raisonnement d'un agent entraîne un coût cumulatif, à la fois en termes de calcul pour exécuter la fonction de l'outil et d'impact sur la fenêtre contextuelle limitée. Certaines des dernières techniques de gestion du contexte pour les agents LLM ont provoqué des effets en chaîne involontaires tels que l'"effondrement du contexte", où la compression/le résumé du contexte accumulé pour les tâches de longue durée entraîne trop de pertes. Le résultat souhaité est de disposer d'outils qui renvoient un contexte succinct et précis, sans que des informations superflues ne viennent empiéter sur l'espace mémoire précieux de la fenêtre de contexte.

Tant/trop de possibilités

Nous voulons une séparation des tâches avec la possibilité de réutiliser les outils/composants, il est donc tout à fait logique de créer des outils agentiques dédiés pour se connecter à des sources de données spécifiques - chaque outil peut se spécialiser dans l'interrogation d'un type de référentiel, d'un type de flux de données, ou même d'un cas d'utilisation. Mais attention : dans le but de gagner du temps/de l'argent/de prouver que quelque chose est possible, la tentation sera grande d'utiliser les MLD comme outil de fédération... Essayez de ne pas le faire, nous sommes déjà passés par là! La recherche fédérée agit comme un "traducteur universel" qui convertit une requête entrante dans la syntaxe que le référentiel distant comprend, et qui doit ensuite rationaliser les résultats provenant de sources multiples en une réponse cohérente. La fédération en tant que technique fonctionne bien à petite échelle, mais à grande échelle et surtout lorsque les données sont multimodales, la fédération tente de combler des lacunes qui sont tout simplement trop importantes.

Dans le monde agentique, l'agent serait le fédérateur et les outils (par l'intermédiaire de MCP) seraient les connexions définies manuellement vers des ressources disparates. L'utilisation d'outils dédiés pour accéder à des sources de données non connectées peut sembler être une nouvelle façon puissante d'unir dynamiquement différents flux de données sur la base d'une requête, mais l'utilisation d'outils pour poser la même question à plusieurs sources finira probablement par causer plus de problèmes qu'elle n'en résoudra. Chacune de ces sources de données est probablement constituée de différents types de référentiels, chacun ayant ses propres capacités de récupération, de classement et de sécurisation des données qu'il contient. Ces écarts ou "décalages d'impédance" entre les référentiels augmentent bien entendu la charge de traitement. Ils peuvent également introduire des informations ou des signaux contradictoires, où quelque chose d'apparemment inoffensif comme un décalage de notation peut perturber considérablement l'importance accordée à un élément de contexte renvoyé, et affecter la pertinence de la réponse générée en fin de compte.

Le changement de contexte est également difficile pour les ordinateurs

Lorsque vous envoyez un agent en mission, sa première tâche consiste souvent à trouver toutes les données pertinentes auxquelles il a accès. Tout comme pour les humains, si chaque source de données à laquelle l'agent se connecte fournit des réponses dissemblables et désagrégées, il y aura une charge cognitive (mais pas exactement du même type) associée à l'extraction des éléments contextuels saillants du contenu récupéré. Cela prend du temps/du calcul, et chaque petit morceau s'additionne dans la chaîne logique agentique. Cela conduit à la conclusion que, à l'instar de ce qui est discuté pour MCP, la plupart des outils agentiques devraient plutôt se comporter comme des API - des fonctions isolées avec des entrées et des sorties connues, réglées pour répondre aux besoins de différents types d'agents. Ils parviennent beaucoup mieux à relier les points sémantiques, en particulier lorsqu'il s'agit d'une tâche telle que la traduction du langage naturel en syntaxe structurée, lorsqu'ils disposent d'un schéma auquel se référer (RTFM en effet !).

7ème manche !

Nous avons maintenant abordé l'impact des LLM sur la recherche et l'interrogation de données, ainsi que la manière dont la fenêtre de discussion évolue vers l'expérience de l'IA agentique. Mettons les deux sujets ensemble et voyons comment nous pouvons utiliser nos nouvelles capacités de recherche et d'extraction pour améliorer nos résultats en matière d'ingénierie contextuelle. En route pour la troisième partie : la puissance de la recherche hybride dans l'ingénierie contextuelle!

Comme beaucoup d'entre nous, je suis à la fois heureux et étonné du rythme auquel les capacités de l'IA évoluent. Les grands modèles de langage (LLM) et la recherche vectorielle nous ont d'abord lancés dans la révolution sémantique, où nous ne cherchions plus à trouver des choses à l'aide de mots-clés. Ensuite, les LLM nous ont montré de nouvelles façons d'interagir avec nos données, en utilisant des interfaces de chat pour transformer les demandes en langage naturel en réponses qui distillent de vastes bases de connaissances en résumés facilement consommables. Nous avons maintenant (déjà !) ont les prémices d'une logique automatisée pilotée par le LLM sous la forme de flux de travail "d'IA agentique" qui peuvent comprendre sémantiquement une demande entrante, raisonner sur les étapes à suivre, puis choisir parmi les outils disponibles pour exécuter itérativement des actions afin d'atteindre ces objectifs.

La promesse de l'IA agentique nous oblige à évoluer et à ne plus utiliser principalement l'"ingénierie de l'invite" pour façonner nos interactions génératives avec l'IA, mais à nous concentrer sur la manière dont nous pouvons aider les outils agentiques à obtenir les informations supplémentaires les plus pertinentes et les plus efficaces que le LLM doit prendre en compte lorsqu'il génère ses réponses - l'"ingénierie du contexte" est la prochaine frontière. La recherche hybride est de loin le moyen le plus puissant et le plus souple de faire apparaître un contexte pertinent, et la plateforme Search AI d'Elastic ouvre une toute nouvelle voie pour exploiter les données au service de l'ingénierie contextuelle. Dans cet article, nous allons examiner comment les LLM ont changé le monde de la recherche d'informations sous deux angles, puis comment ils peuvent travailler ensemble pour obtenir de meilleurs résultats. Il y a beaucoup de chemin à parcourir...

Partie I : Comment les LLM ont changé la recherche

Commençons par la façon dont les LLM ont changé la façon dont nous accédons à l'information et dont nous la recherchons.

Notre héritage lexical

Nous vivons tous depuis longtemps dans le monde quelque peu limité de la recherche lexicale (plutôt bien, du mieux que nous pouvons). La recherche est le premier outil que nous utilisons lorsque nous faisons des recherches ou que nous commençons un nouveau projet. Jusqu'à récemment, il nous incombait de formuler nos requêtes de manière à ce qu'elles soient comprises par un moteur de recherche lexical. La recherche lexicale repose sur la mise en correspondance d'une certaine forme de termes d'interrogation avec des mots-clés trouvés dans un corpus de documents, que le contenu soit structuré ou non. Pour qu'une recherche lexicale aboutisse à un document, celui-ci doit correspondre à ce mot-clé (ou disposer d'un vocabulaire contrôlé tel qu'une liste de synonymes ou un dictionnaire pour établir le lien conceptuel).

Exemple de requêtelexicale multi-correspondance

Au moins, les moteurs de recherche ont la possibilité de renvoyer les résultats avec un score de pertinence. Les moteurs de recherche offrent une multitude d'options syntaxiques pour cibler efficacement les données indexées et des algorithmes de pertinence intégrés qui évaluent les résultats en fonction de l'intention de la syntaxe de la requête de l'utilisateur. Les moteurs de recherche bénéficient de décennies de progrès dans les algorithmes de classement par pertinence, ce qui en fait une plate-forme efficace de recherche de données capable de fournir des résultats notés et triés en fonction de leur pertinence par rapport à la requête. Les bases de données et autres systèmes qui utilisent SQL comme principale méthode de recherche de données sont ici désavantagés : il n'y a pas de concept de pertinence dans une requête de base de données ; le mieux qu'ils puissent faire est de trier les résultats par ordre alphabétique ou numérique. La bonne nouvelle, c'est que vous obtiendrez tous les résultats (rappel) avec ces mots-clés, mais qu'ils ne seront pas nécessairement dans un ordre utile par rapport à la raison pour laquelle vous les avez demandés (précision). C'est un point important, comme nous le verrons bientôt...

Entrez dans le dragon (sémantique)

Le potentiel des représentations vectorielles de l'information en tant qu'alternative à la recherche par mot-clé fait l'objet de recherches depuis longtemps. Les vecteurs sont très prometteurs parce qu'ils nous permettent de sortir du mode de correspondance par mot-clé uniquement - parce qu'ils sont des représentations numériques des termes et des poids, les vecteurs permettent de rapprocher mathématiquement les concepts sur la base de la compréhension par un modèle linguistique de la manière dont les termes sont liés les uns aux autres dans le domaine d'apprentissage. Le retard pris par la recherche vectorielle générale s'explique par le fait que les modèles étaient essentiellement limités à des domaines spécifiques et qu'ils n'étaient tout simplement pas assez vastes pour comprendre suffisamment les nombreux concepts différents qu'un terme peut représenter dans des contextes différents.

Ce n'est que lorsque les grands modèles de langage (LLM) sont apparus il y a quelques années, avec leur capacité à s'entraîner sur des quantités de données beaucoup plus importantes (en utilisant des transformateurs et de l'attention), que la recherche vectorielle est devenue pratique - la taille et la profondeur des LLM ont finalement permis aux vecteurs de stocker suffisamment de nuances pour qu'ils puissent réellement capturer le sens sémantique. Cette augmentation soudaine de la profondeur de compréhension a permis aux LLM de remplir un grand nombre de fonctions de traitement du langage naturel (NLP) qui étaient auparavant verrouillées, la plus importante étant peut-être la capacité à déduire le terme suivant le plus probable dans une séquence, compte tenu du contexte de ce qui se trouve dans la séquence jusqu'à présent. L'inférence est le processus qui donne à l'IA générative sa capacité quasi humaine à produire du texte. Le texte généré par l'IA s'appuie sur la compréhension qu'a le LLM de la manière dont les termes sont liés dans ses données d'apprentissage et utilise également la formulation de la demande pour désambiguïser les différents contextes dans lesquels les termes peuvent apparaître.

Aussi magique que soit l'IA générative, les LLM présentent des limites qui entraînent des erreurs de qualité et de précision, communément appelées hallucinations. Les hallucinations se produisent lorsque le LLM n'a pas accès aux informations (ou n'est pas guidé vers le bon contexte) pour fonder sa réponse sur la vérité et que, pour être utile, il génère une réponse confiante et plausible qui a été inventée. Cela s'explique en partie par le fait que les LLM apprennent l'usage de la langue dans de vastes domaines d'informations diverses, mais qu'ils doivent cesser leur formation à un moment donné, de sorte que leur compréhension est soumise à un facteur temporel, ce qui signifie que le modèle ne peut savoir que ce qui était exact jusqu'au moment où il a cessé de se former. Un autre facteur d'hallucinations est que le modèle ne connaît généralement pas les données privées (données non disponibles sur l'internet public), ce qui est particulièrement important lorsque ces données contiennent des termes et une nomenclature spécifiques.

Bases de données vectorielles

Les LLM vectorisent le contenu dans l'espace de leur modèle à l'aide d'une technique appelée "text embedding", qui consiste à intégrer ou à cartographier la signification sémantique du contenu dans la vision du monde du modèle sur la base de la formation qu'il a reçue. Quelques étapes sont nécessaires pour préparer et traiter le contenu à intégrer, notamment le découpage en morceaux et la tokenisation (et la tokenisation des sous-mots). Le résultat est généralement un ensemble de vecteurs denses représentant la compréhension par le modèle de la signification de ce morceau de contenu dans son espace vectoriel. Le découpage est un processus inexact qui vise à adapter le contenu aux limites des contraintes de traitement d'un modèle pour générer des encastrements, tout en essayant de regrouper le texte apparenté dans un morceau à l'aide de constructions sémantiques telles que les indicateurs de phrase et de paragraphe.

La nécessité d'un découpage en morceaux peut entraîner une certaine perte sémantique dans un document incorporé, car les morceaux individuels ne sont pas entièrement associés à d'autres morceaux du même document. L'opacité inhérente aux réseaux neuronaux peut aggraver cette perte - un LLM est véritablement une "boîte noire" dans laquelle les connexions entre les termes et les concepts établies au cours de la formation sont non déterministes et ne peuvent être interprétées par les humains. Cela pose des problèmes d'explicabilité, de reproductibilité, de partialité inconsciente et, potentiellement, de perte de confiance et d'exactitude. Néanmoins, la possibilité de relier sémantiquement des idées, de ne pas être lié à des mots-clés spécifiques lors de la recherche, est extrêmement puissante :

Un exemple de requête sémantique

Les bases de données vectorielles ne sont pas des moteurs de recherche, mais des bases de données ! Lorsqu'une recherche de similarité vectorielle est effectuée, les termes de la requête sont encodés pour trouver un ensemble de coordonnées (d'intégration) dans l'espace vectoriel du modèle. Ces coordonnées sont ensuite utilisées comme œil-de-bœuf pour trouver les documents qui sont les "plus proches voisins" de l'œil-de-bœuf - ce qui signifie que le rang d'un document (ou sa place dans les résultats) est déterminé par la distance de similarité calculée entre les coordonnées de ce document et les coordonnées de la requête. Dans quel sens le classement doit-il primer, lequel des contextes possibles est le plus proche de l'intention de l'utilisateur ? L'image à laquelle je me réfère est une scène du film Stargate, où nous avons les six points de coordonnées qui se croisent pour nous indiquer la destination (l'œil-de-bœuf), mais nous ne pouvons pas nous y rendre sans connaître le "7e symbole" - les coordonnées du point de départ représentant l'intention subjective de l'utilisateur. Ainsi, au lieu que le classement relatif des vecteurs soit basé sur une sphère de similarité toujours plus étendue et indifférenciée, en tenant compte de l'intention subjective de la requête par le biais d'une syntaxe expressive et d'une notation de la pertinence, nous pouvons obtenir quelque chose qui ressemble à un cylindre de pertinence subjective graduée.

Les capacités d'inférence d'un LLM peuvent aider à identifier le contexte le plus probable pour la requête, mais le problème est que sans aide, les coordonnées de la requête entrante ne peuvent être déterminées que par la façon dont le modèle a été formé à l'origine.

D'une certaine manière, on pourrait dire que la similarité vectorielle va à l'extrême opposé d'une correspondance stricte par mot-clé - sa force réside dans sa capacité à surmonter les problèmes d'inadéquation des termes, mais presque jusqu'à la faute: Les LLM tendent à unifier des concepts apparentés plutôt qu'à les différencier. La similarité vectorielle améliore notre capacité à faire correspondre le contenu sur le plan sémantique, mais ne garantit pas la précision car elle peut négliger des mots-clés exacts et des détails spécifiques qui ne sont pas suffisamment désambiguïsés par le modèle. La recherche de similarités vectorielles est puissante en soi, mais nous avons besoin de moyens pour corréler les résultats que nous extrayons d'une base de données vectorielle avec les résultats d'autres méthodes d'extraction.

Techniques de repositionnement

C'est le moment de mentionner une technique générale appelée "reranking", qui consiste à réévaluer ou à normaliser les ensembles de résultats en fonction d'un ordre de classement unifié. Le besoin de reclassement peut être dû au fait que les résultats provenant de sources multiples ou de méthodes de recherche ont des mécanismes de classement/évaluation différents (ou aucun, SQL !), ou le reclassement peut être utilisé pour aligner sémantiquement les résultats provenant de sources non sémantiques sur la requête de l'utilisateur. Le reclassement est une opération de deuxième étape, c'est-à-dire un ensemble de résultats qui ont été collectés par une méthode de recherche initiale (c'est-à-dire le SQL, recherche lexicale, recherche vectorielle) sont ensuite réordonnées avec une méthode de notation différente.

Plusieurs approches sont disponibles, notamment Learning-To-Rank (LTR) et Reciprocal Rank Fusion (RRF) - LTR est utile pour capturer les caractéristiques des résultats de recherche (likes, évaluations, clics, etc.) et les utiliser pour noter et améliorer ou biaiser les résultats. RRF est parfait pour fusionner les résultats obtenus à partir de différentes modalités d'interrogation (par ex. les recherches dans les bases de données lexicales et vectorielles) en une seule liste de résultats. Elastic offre également la possibilité d'ajuster les scores à l'aide de méthodes de reclassement linéaire.

L'une des techniques de reclassement les plus efficaces est cependant le reclassement sémantique, qui utilise la compréhension sémantique d'un LLM pour analyser les vecteurs d'intégration de la requête et des résultats, puis appliquer la notation de la pertinence/le reclassement pour déterminer l'ordre final. Le reranking sémantique nécessite une connexion à un modèle de reranking, bien sûr, et Elasticsearch fournit une API d'inférence qui vous permet de créer des points d'extrémité de rerank qui exploitent des modèles intégrés(Elastic Rerank), des modèles tiers importés ou des services hébergés en externe tels que Cohere ou Google Vertex AI. Vous pouvez ensuite effectuer un reclassement grâce à la syntaxe d'abstraction de la requête du récupérateur:

Exemple d'opération de remise en ordre d'un récupérateur en plusieurs étapes

Ça a l'air bien, non ? Nous pouvons effectuer un reclassement sur des résultats provenant de sources disparates et nous rapprocher d'une compréhension sémantique de tous les types de contenu... Le reclassement sémantique peut être coûteux tant sur le plan du calcul que du temps de traitement nécessaire, et pour cette raison, le reclassement sémantique ne peut être effectué que sur un nombre limité de résultats, ce qui signifie que la manière dont ces résultats initiaux sont récupérés est importante.

La méthode de recherche contextuelle est importante

L'intention subjective est un facteur important dans la détermination de l'exactitude d'un résultat, dans l'évaluation de sa pertinence. Sans la possibilité de prendre en compte l'intention de l'utilisateur lors de l'exécution de la requête (telle qu'elle est exprimée par une syntaxe flexible ou par un reclassement de deuxième niveau), nous ne pouvons que sélectionner les contextes existants déjà encodés dans l'espace de modélisation. La façon dont nous abordons généralement ce manque de contexte est par le biais de techniques telles que Retrieval Augment Generation (RAG). La méthode RAG consiste à déplacer les coordonnées de la requête en incluant des termes connexes supplémentaires issus d'une pré-requête de données contextuelles pertinentes. Le moteur qui fournit ce contexte supplémentaire et sa méthode initiale de recherche sont donc d'autant plus importants pour la précision du contexte !

Passons en revue les différentes méthodes de recherche contextuelle et la manière dont elles peuvent aider ou nuire à une opération RAG :

• La recherche hybride sans moteur de recherche manque encore de pertinence subjective. Si la plateforme qui fournit le RAG est principalement basée sur SQL (ce qui inclut la plupart des plateformes de "lac de données"), elle ne dispose pas d'un système de notation de la pertinence au stade de la recherche initiale. De nombreuses plateformes de lac de données proposent leur propre version de la recherche hybride (et non de la recherche), combinant généralement des techniques de reranking telles que le reranking sémantique et le RRF sur leur recherche basée sur SQL et les résultats de la base de données vectorielles. Un simple tri est manifestement insuffisant pour un classement subjectif, mais même lorsqu'il est utilisé comme base pour une opération de reclassement sémantique à la deuxième étape, SQL comme la recherche à la première étape devient un problème lorsque le reclassement sémantique n'est effectué que sur les "k premiers" résultats - sans un moyen de noter les résultats à la recherche, quelle garantie avons-nous que les meilleurs résultats se trouvent effectivement dans les premiers résultats ?

• La similarité vectorielle n'est pas suffisante pour le RAG. Il s'agit en fait d'un ensemble de problèmes combinés - la perte de l'intégration, les méthodes naïves de regroupement, le mode de calcul de la similarité et la composante manquante cruciale de l'intention subjective. L'un des principaux objectifs de RAG est de fonder les interactions génératives de l'IA sur la vérité objective, à la fois pour éviter les hallucinations et pour informer le LLM des informations privées dont il n'a pas eu connaissance au cours de la formation. Nous pouvons utiliser le contexte supplémentaire fourni par le RAG pour contraindre et orienter les MFR à prendre en compte les liens et les détails que nous savons être les plus importants pour répondre à la question posée. Pour ce faire, nous devons utiliser des approches sémantiques et lexicales.

• RAG (grep/regex) basé sur des fichiers. Certains secteurs de l'univers de l'IA agentique préconisent l'utilisation de fenêtres contextuelles considérablement agrandies qui accèdent aux fichiers locaux via grep et regex pour RAG plutôt que des plates-formes de recherche externes. L'idée est qu'en disposant d'une fenêtre contextuelle beaucoup plus large, les LLM seront en mesure d'établir des connexions conceptuelles au sein de leur propre espace de réflexion plutôt que de s'appuyer sur des éléments fragmentés et de multiples méthodes/plateformes de recherche pour collecter des informations pertinentes. S'il est vrai en théorie que le fait de disposer d'un document entier donne une image plus complète que des segments de document, cela ne peut fonctionner que dans des domaines de données restreints (ou, par exemple, lors de la fourniture de fichiers pour le vibecodage), et même dans ce cas, la méthode de recherche initiale est un balayage de tous les documents avec une correspondance par mot-clé uniquement.

La recherche, c'est plus que l'extraction

Les moteurs de recherche sont conçus pour rendre les requêtes aussi rapides et flexibles que possible. En interne, ils utilisent des structures de données spécialisées pour stocker et récupérer différents types de données de manière adaptée à ces types de données. Elasticsearch permet d'optimiser le stockage et l'interrogation de pratiquement tous les types de données, y compris la recherche lexicale non structurée/texte intégral (correspondance, phrase, proximité, correspondance multiple), la correspondance et le filtrage rapides par mot-clé (correspondance exacte), les plages numériques, les dates, les adresses IP, et est très flexible dans la manière dont il stocke les structures de documents (par ex. les documents imbriqués ou aplatis). Elasticsearch est également une base de données vectorielle native capable de stocker et d'interroger des types de vecteurs épars et denses, et nous continuons à explorer des moyens innovants (par exemple, Better Binary Quantization (BBQ) & DiskBBQ) pour maintenir la fidélité de la recherche tout en améliorant la vitesse, l'évolutivité et les coûts associés au contenu vectorisé. La plateforme Elasticsearch offre également une résilience des données et une haute disponibilité intégrées, ainsi que des fonctionnalités de gestion du cycle de vie des données, telles que les instantanés consult ables, qui vous permettent de conserver les données rarement consultées ou les données conservées à long terme sur un stockage objet rentable, tout en conservant une capacité de recherche totale.

La recherche hybride, c'est le meilleur des mondes

Recherche hybride (et pas seulement recherche hybride !) combine les forces de la recherche lexicale traditionnelle avec la compréhension sémantique des LLM et la recherche par similarité vectorielle. Cette synergie permet de cibler des résultats très pertinents au stade de la recherche grâce à l'une des options syntaxiques souples proposées par un moteur de recherche : options syntaxiques axées sur l'intention et évaluation de la pertinence, recherche de données multimodales, filtrage, agrégations et biais. Avec une syntaxe de recherche telle que ES|QL et des extracteurs à plusieurs niveaux, nous pouvons combiner de manière flexible la recherche traditionnelle avec la recherche sémantique, les filtres et plusieurs techniques de reclassement en une seule requête.

L'un des principaux avantages de la recherche hybride est que vos requêtes peuvent utiliser une syntaxe spécialisée pour plusieurs types de données simultanément. Ces différentes syntaxes d'interrogation peuvent être utilisées non seulement pour trouver des résultats, mais aussi comme filtres ou agrégations sur les résultats. Par exemple, l'analyse géospatiale est l'un des types d'interrogation les plus courants qui est fréquemment combiné à d'autres syntaxes. Vous pouvez par exemple demander des résultats dont les coordonnées géographiques se situent à une distance donnée d'un point, ou demander des agrégations de vos résultats par région, ou encore des agrégations pour suivre et alerter sur les mouvements à l'intérieur ou à l'extérieur d'une zone. Avec la recherche hybride, vous avez la possibilité de combiner des syntaxes pour cibler les résultats de la manière la plus précise possible, afin de retrouver le contenu le plus proche de votre contexte.

Intermède

Cette première partie raconte comment la recherche vectorielle a changé la façon dont nous pouvons récupérer des données et prépare le terrain pour les changements que les LLM ont apportés aux mécanismes d'interrogation que nous utilisons pour interagir avec les données. Nous allons faire comme si nous avions dû diviser ce texte en plusieurs parties pour que les LLM puissent le comprendre sans perdre le contexte... ;-) Nous en apprendrons plus sur les raisons de cette importance dans la Partie II : L'IA agentique et le besoin d'ingénierie contextuelle, et dans la Partie III, nous reviendrons à notre discussion sur la recherche hybride.