Comment MATCH et TO_TEXT permettent la recherche full-text sur n'importe quelle expression ES|QL

Commençons par une requête qui était impossible dans Elasticsearch 9.4, qui utilise la commande EVAL :

Dans cet exemple, le résumé ne dispose d'aucune configuration de mapping ou d'analyseur. Il n'est pas non plus associé à un index inversé. Il n'existe que le temps de cette requête, mais il est tout de même possible d'effectuer des recherches dessus. Deux ajouts permettent d'y parvenir.

Premièrement, la fonction MATCH accepte désormais n'importe quelle expression comme premier argument, et non plus seulement un champ mappé. Cela inclut les colonnes générées par EVAL ainsi que les résultats de fonctions utilisés directement dans l'expression. Cela englobe également les champs non mappés chargés directement depuis le document d'origine. De plus, tous les types de données habituellement acceptés par MATCH sont compatibles avec ce nouveau cas d'utilisation.

Deuxièmement, la nouvelle fonction TO_TEXT, qui est la première fonction de conversion ES|QL qui produit une sortie de type texte. Jusqu'à présent, les colonnes de texte ne pouvaient provenir que de champs mappés indexés, et toutes les chaînes générées par les expressions ES|QL étaient des valeurs de mots-clés plutôt que de texte. Cette distinction est importante car MATCH traite les deux différemment : les valeurs de texte sont analysées, tandis que les valeurs de mots-clés sont comparées exactement, reproduisant ainsi le mécanisme par lequel une requête MATCH sur un champ de mot-clé indexé est réécrite en requête de terme. TO_TEXT(x) permet d'indiquer à ES|QL de traiter cette chaîne comme du texte intégral.

Cette fonctionnalité est disponible en préversion technique dans Elasticsearch 9.5, et, à ce titre, présente certaines limitations :

• Pour l'instant, elle se limite au filtrage. Une opération MATCH portant sur une expression ne contribue pas encore au score de pertinence ; seuls les matchs sur des champs indexés influencent ce score.

• Les options de requête telles que la tolérance aux erreurs ne sont pas encore prises en charge lors de l'utilisation de MATCH sur une expression.

• Le texte généré à l'exécution est analysé à l'aide de l'analyseur standard. Ce comportement n'est pas encore configurable.

Ces limitations seront résolues prochainement.

Pourquoi utiliser la recherche full-text plutôt que LIKE ou RLIKE dans ES|QL ?

ES|QL disposait déjà de deux méthodes pour rechercher des chaînes de caractères sans index : LIKE (caractères génériques) et RLIKE (expressions régulières). Les deux fonctionnant sur n'importe quelle expression de chaîne, on peut donc se demander ce que MATCH apporte. La réponse est l'analyse, une forme plus avancée de recherche qui utilise des techniques telles que la lemmatisation et les synonymes. Elle intègre également la gestion des mots vides.

LIKE effectue une simple correspondance de sous-chaîne, sans aucune compréhension des mots qui composent la chaîne. Supposons, par exemple, que vous recherchiez des messages de log à propos d'un renard :

La correspondance "Fox spotted near the henhouse" n'est pas détectée en raison de la majuscule, alors que la correspondance "Outfoxed by the competition", qui n'a aucun rapport avec un renard, est détectée. Le système échoue dans les deux cas : faux négatifs liés à la casse et faux positifs dus à des sous-chaînes incluses dans d'autres mots.

Les expressions régulières peuvent résoudre le problème de la casse, mais la gestion des limites de mots devient vite complexe. Quelque chose comme :

Et même là, ce n'est pas encore tout à fait ça. L'expression ne détecte pas le mot "fox" en fin de phrase s'il est suivi d'un point d'exclamation ou d'interrogation, et elle ne tient pas compte des tabulations, des guillemets ou des parenthèses. Chaque correction allonge le pattern, obligeant la personne suivante qui lira la requête à procéder à une ingénierie inverse pour comprendre ce qu'elle fait réellement.

MATCH résout le problème, car il fait passer aussi bien la requête que la valeur par un analyseur qui découpe le texte à l'aide de tokens et le convertit en minuscules, puis compare les termes entre eux :

Cette requête correspondra à des valeurs comme "The quick brown fox" et "FOX spotted near the henhouse", mais pas à "Outfoxed by the competition" ou "FOXTROT protocol enabled", quelle que soit la ponctuation entourant les mots. Bien entendu, tout cela fonctionne également pour les requêtes comportant plusieurs termes, comme MATCH(TO_TEXT(message), "brown fox"), exactement comme on peut s'y attendre.

Des travaux sont en cours pour permettre l'utilisation des 36 analyseurs linguistiques dédiés, avec la prise en charge des langues naturelles sur des données jamais indexées ni mappées.

Cas d'utilisation de la recherche full-text pour des données non indexées et non mappées

Les exemples ci-dessus portaient sur des valeurs calculées à partir de champs mappés. Les cas d'utilisation les plus intéressants de la fonction MATCH d'ES|QL appliquée à des expressions concernent des données qui, auparavant, n'étaient pas du tout interrogeables. Examinons quelques-uns de ces cas.

Comment rechercher des champs non mappés dans ES|QL sans ajouter de mapping

Il arrive parfois que l'on doive exclure un champ de nos mappings, comme une trace de pile détaillée ou une charge utile de requête brute. On peut même omettre un blob à déboguer. L'indexation de l'un de ces éléments consommerait de l'espace disque et de la mémoire pour chaque document, ce qui ne se justifierait pas pour un champ que l'on n'interroge peut-être qu'une fois par trimestre.

Cette décision a toujours été irrévocable, car les champs non mappés étaient totalement invisibles pour les requêtes. Dans Elasticsearch 9.5, vous pouvez utiliser SET unmapped_fields="load" pour permettre à ES|QL de charger directement les champs non mappés depuis le document source en tant que mots-clés. En enveloppant ensuite le résultat dans TO_TEXT, vous pouvez exécuter une recherche full-text sur ces champs :

Ici, stack_trace n'a jamais été mappé. Chaque valeur est récupérée depuis les documents d'origine et analysée à la volée ; la correspondance est établie ligne par ligne. C'est un travail conséquent, qui ne sera jamais aussi rapide qu'une recherche via un index inversé. Toutefois, ce champ que vous n'aviez pas indexé n'est plus impossible à interroger. Vous pouvez ainsi conserver un mapping léger pour les besoins courants tout en étant capable de répondre, le moment venu, à une question qui ne se pose qu'une fois par trimestre.

Recherche full-text sur un champ de mots-clés sans réindexation

Les champs de mots-clés offrent de nombreuses possibilités. Ils permettent une correspondance exacte, des agrégations rapides et le tri des données ; c'est pourquoi tant de champs sont finalement mappés de cette manière. Toutefois, le mapping est défini au moment de l'arrivée des données, et il est fréquent de se retrouver dans une situation où l'on souhaite exploiter ces données différemment de ce qui avait été prévu initialement. Par exemple, le champ product_name a peut-être été mappé en tant que mot-clé parce que les tableaux de bord s'appuyaient sur lui pour des agrégations. Or, après avoir accumulé une année de données produits, un utilisateur peut soudainement vouloir effectuer des recherches au sein même des valeurs de ce champ.

L'ancienne solution consiste à convertir le mapping en texte (ou à ajouter un champ multiple) et à tout réindexer. Cette opération est longue et coûteuse et, bien souvent, les utilisateurs ne veulent pas s'en donner la peine. La nouvelle solution se résume à un seul appel de fonction :

TO_TEXT convertit à la volée les valeurs de mot-clés en texte, permettant ainsi à MATCH de les analyser plutôt que de les comparer de manière exacte. Cela vous permet d'interroger un champ de mot-clé sans avoir à créer de mapping ni à réindexer le document source. Si cette recherche est amenée à devenir une requête courante, l'indexation du champ en tant que texte reste la solution idéale à long terme. Toutefois, TO_TEXT vous permet d'obtenir une réponse immédiate, sans travail supplémentaire.

Recherche sur le même champ dans des index aux mappings différents

ES|QL peut couvrir plusieurs index, et un même champ ne doit pas nécessairement présenter la même structure dans chacun d'eux. Lorsqu'un même champ possède des types différents selon les index, ES|QL le traite comme un type d'union, et une fonction de conversion résout le conflit. Prenons l'exemple d'un champ de message qui est de type texte dans le modèle d'index de cette année, alors qu'il était de type mot-clé dans celui de l'année précédente :

Chaque valeur est analysée au moment de la requête, qu'elle provienne de l'index texte ou de l'index mots-clés. Les valeurs de type mot-clé issues des anciens index sont découpées en tokens et converties en minuscules, tout comme les autres ; ainsi, la recherche "connection reset" permet de trouver "Connection RESET by peer", quel que soit l'index dans lequel la donnée est stockée.

Un autre cas intéressant est celui où un champ est mappé dans un seul index mais également présent (et non mappé) dans l'autre :

Il existe une nuance ici qu'il convient de souligner. Si error_details est mappé dans logs-2026 mais pas dans logs-2025, Elasticsearch ne peut pas déléguer cette requête à Lucene, car les index où le champ n'est pas mappé ne renverraient silencieusement aucun résultat. Au lieu de cela, le planificateur détecte que le champ n'est potentiellement pas mappé et évalue l'intégralité de la clause MATCH ligne par ligne, quelle que soit la provenance des lignes. Vous n'avez pas besoin de savoir à quels index appartient le mapping de ce champ ; la requête répond simplement à la question.

Comment ES|QL analyse le texte au moment de la requête sans index inversé

Lorsque ES|QL planifie une opération MATCH sur une expression, il analyse la chaîne de requête une seule fois, au préalable, pour la transformer en un ensemble de termes. La manière dont chaque ligne est ensuite évaluée dépend du type de l'expression :

Type d'expression

Traitement

Comportement correspondant

texte (via TO_TEXT)

L'analyseur segmente la valeur à l'aide de tokens et la convertit en minuscules

Comparaison token par token ; une ligne correspond si un token correspond à un terme de requête quelconque (sémantique OU)

mot-clé, adresse IP, date, numérique

Aucune analyse ; constante de la requête convertie une seule fois vers le type natif

Comparaison exacte par ligne

Ces deux méthodes contournent entièrement Lucene et évaluent les valeurs ligne par ligne. Le chemin non textuel reproduit exactement le comportement d'une requête de correspondance lorsqu'elle est déléguée à Lucene pour ces types de champs ; la sémantique reste donc cohérente, que la requête utilise un index ou non.

Une recherche via un index inversé s'effectue au moment de l'ingestion et n'interagit jamais avec les documents non correspondants lors de l'exécution de la requête. À l'inverse, une opération MATCH effectuée à l'exécution réalise cette analyse au moment de la requête, pour chaque ligne traitée. La première méthode est rapide car le travail a déjà été accompli en amont, tandis que la seconde offre de la flexibilité, car les données n'ont pas besoin d'avoir été indexées au préalable.

Prochaines évolutions de la recherche full-text dans ES|QL

Tout ce qui est présenté dans cet article constitue la première étape d'une initiative plus vaste visant à permettre à la recherche ES|QL de fonctionner sur n'importe quelles données, et pas seulement sur celles indexées au préalable. Nous travaillons activement à lever les limitations mentionnées précédemment, et la roadmap va encore plus loin :

• Calcul du score. Les correspondances évaluées à l'exécution contribueront au score (_score) ; vous pourrez ainsi effectuer un tri par pertinence, même si les données n'ont jamais été indexées.

• MATCH_PHRASE sur les expressions. Déjà disponible dans Elastic Cloud Serverless et prochainement dans la Suite Elastic version 9.6.

• Analyseurs configurables. Prise en charge des analyseurs pour MATCH et MATCH_PHRASE sur les expressions, permettant l'utilisation d'analyseurs linguistiques, de la lemmatisation et de synonymes au moment de la requête.

• Options de correspondance. Des options telles que la tolérance et l'opérateur pour les correspondances à l'exécution.

• Recherche vectorielle. Génération d'embeddings par ligne et exécution de l'algorithme des k plus proches voisins (kNN) sur des expressions dense_vector évaluées à l'exécution, permettant d'étendre la recherche sémantique aux données non indexées.

Essayez dès aujourd'hui la recherche full-text ES|QL sur les expressions

Vous pouvez essayer la recherche au moment de l'exécution dès maintenant. Elle est disponible dans Elastic Cloud Serverless, où les nouvelles fonctionnalités ES|QL sont déployées en priorité, et proposée en préversion technique dans Elasticsearch 9.5. Commencez par consulter la documentation de référence sur les fonctions de recherche ainsi que les limites actuelles sur la page dédiée aux limitations ES|QL. Cette préversion technique est destinée à recueillir votre avis : si vous effectuez une recherche sur un élément qui n'a jamais été indexé et que le résultat vous surprend – en bien ou en mal –, n'hésitez pas à nous en faire part.

1. Utilisation de l'API _mapping pour récupérer des informations sur les champs

2. Utilisation de l'API _search pour afficher les valeurs des champs

3. Affichage des sous-champs

4. Synthetic _source

5. Champs d'exécution

1. Utilisation de l'API _mapping pour récupérer des informations sur les champs

L'API _mapping vous permet de récupérer la définition du mappage pour un ou plusieurs index. Il s'agit d'informations sur les champs, leurs types de données et d'autres propriétés. Pour récupérer le mappage d'un index spécifique, utilisez la requête suivante :

Par exemple, si vous avez un index nommé my_index, vous pouvez récupérer son mapping avec la requête suivante :

La réponse comprendra la définition du mappage pour l'index, qui contient des informations sur les champs et leurs propriétés.

Il est également possible de récupérer la cartographie d'un champ spécifique. Cela peut s'avérer utile si votre cartographie est assez vaste et que vous souhaitez vous concentrer sur un domaine spécifique. Pour récupérer la correspondance d'un champ spécifique, utilisez la requête suivante :

Vous pouvez également récupérer les correspondances de plusieurs champs en séparant leurs noms par des virgules, comme dans la requête suivante :

2. Utilisation de l'API _search pour afficher les valeurs des champs

Pour afficher les valeurs des champs d'un index Elasticsearch, vous pouvez utiliser l'API _search. L'API _search vous offre plusieurs moyens de contrôler les champs renvoyés ; les deux principaux sont les suivants :

1. _source: Le champ _source contient le corps du document JSON original tel qu'il a été indexé, y compris les modifications apportées par les pipelines d'ingestion ou les étapes de prétraitement. Pour afficher des champs spécifiques du document source, il faut mettre en œuvre le filtrage de la source, comme nous le verrons ci-dessous.

2. fields: Le paramètre fields vous permet d'extraire des champs spécifiques de vos documents lors d'une recherche, sur la base du mappage de l'index. Contrairement à _source, fields peut également renvoyer des valeurs provenant de champs stockés, de valeurs documentaires ou de champs d'exécution sans faire référence à _source, bien que pour les champs standard sans valeurs documentaires ou paramètres stockés, il se réfère à _source. Cela peut apporter de nombreux avantages, notamment en termes de performances, comme nous le verrons ci-dessous.

Utilisation du champ _source

Par défaut, l'API _search renvoie le champ _source, qui contient le document JSON original qui a été indexé. Pour afficher des champs spécifiques, vous pouvez ajouter des filtres dans le paramètre _source de la demande de recherche ; c'est ce qu'on appelle le filtrage à la source.

Voici un exemple de demande de recherche qui renvoie les valeurs des champs title et author pour les documents de l'index my_index:

Dans cet exemple, le paramètre _source spécifie les champs à renvoyer.

Si vous avez besoin d'encore plus de contrôle, vous pouvez utiliser les propriétés includes et excludes de l'objet _source. Par exemple, la requête ci-dessous renvoie le champ de premier niveau title et tous les sous-champs de author à l'exception de author.description.

Dans cet exemple, nous utilisons le modèle author.* pour récupérer tous les sous-champs directs de l'objet author . Nous excluons ensuite explicitement author.description afin que seuls les autres champs relatifs à l'auteur soient renvoyés. Notez que cela n'améliore pas les performances, puisqu'il faut toujours charger et analyser la source JSON, mais cela permet de réduire la taille de la réponse envoyée sur le réseau.

Utilisation du paramètre champs

Vous pouvez utiliser le paramètre fields pour filtrer les champs renvoyés dans la réponse de recherche. L'utilisation de fields par rapport à _source présente plusieurs avantages, notamment

• Amélioration des performances : fields peut renvoyer des valeurs directement à partir de champs stockés ou de valeurs de documents sans avoir à charger l'intégralité du site _source, ce qui réduit la taille de la charge utile de la réponse.

• Sortie formatée : Pour les champs standard, fields peut se référer à _source pour récupérer les valeurs, mais il s'appuie sur le mappage de l'index pour formater correctement la sortie, comme les dates formatées, afin de les rendre cohérentes avec ce qui est utilisé pour les agrégations et les tris.

• Accès aux champs d'exécution : fields peut renvoyer des champs d'exécution qui n'existent pas sur le site original _source.

• D'autres avantages peuvent être trouvés ici.

Par exemple, pour obtenir uniquement les champs title et author dans l'index my_index, vous pouvez utiliser la requête de recherche suivante :

Dans la requête ci-dessus, nous attribuons la valeur false au champ _source afin de ne pas renvoyer le document source. Cela peut réduire considérablement la taille de la charge utile de la réponse, mais n'oubliez pas que cela ne fonctionne que si les champs title et author sont de type keyword , pour lesquels doc_values est activé par défaut. Si le champ n'a pas été activé par doc_values et que _source a été défini sur false, Elasticsearch n'aura aucun moyen de les récupérer et ils seront ignorés dans la réponse.

Il est important de noter que la réponse fields renvoie toujours un tableau de valeurs pour chaque champ, même s'il n'y a qu'une seule valeur. Cela est dû au fait qu'Elasticsearch n'a pas de type de tableau dédié, et que tout champ peut avoir plusieurs valeurs. Pour plus d'informations sur les tableaux dans Elasticsearch, cliquez ici.

Autres moyens d'extraire des champs

Bien que l'extraction de champs à l'aide de _source ou fields soit la méthode recommandée, il existe d'autres méthodes pour des cas d'utilisation spécifiques, comme par exemple :

Champs de valeur du document : Si vous souhaitez éviter _source, vous pouvez effectuer une recherche en utilisant le paramètre docvalue_fields . Doc values stocke les mêmes valeurs de champ que _source mais dans une structure de données sur disque, optimisée pour les tris et les agrégations.

Comme il s'agit d'une valeur distincte des valeurs stockées sur _source, vous pouvez demander des champs spécifiques sans avoir à charger l'ensemble du site _source. Cette option est utile si vous interrogez des documents volumineux, mais que vous n'avez besoin que de quelques petits champs prenant en charge des valeurs de documents. Un autre cas d'utilisation de docvalue_fields est celui où vous souhaitez utiliser un formatage personnalisé pour les champs date et numeric, comme nous le verrons dans l'exemple ci-dessous.

Notez que cela ne fonctionne que pour les champs pour lesquels vous avez activé doc_values ou pour les types de champs pour lesquels cette option est activée par défaut, tels que keyword, date, les types numériques et boolean, et non pour text ou annotated_text.

Dans cet exemple, nous utilisons le paramètre docvalue_fields pour récupérer les champs title, author et published sans charger le document _source complet :

Lorsque cette requête est exécutée, Elasticsearch récupère les valeurs directement à partir de son magasin en colonnes sur disque au lieu de référencer le site _source pour chaque document. Le champ published est retourné avec le format epoch_millis au lieu du format par défaut, grâce au paramètre format fourni dans la requête.

Champs stockés : Si vous avez explicitement marqué des champs spécifiques comme étant stockés dans le mappage, vous pouvez utiliser le paramètre stored_fields pour filtrer ces champs. C'est utile si vous voulez des réponses légères avec seulement ces champs spécifiques ou pour les champs que vous avez délibérément stockés pour les retrouver plus tard. Il est stocké séparément de _source, de sorte que cette méthode est également utile pour éviter de devoir charger _source.

Il est important de noter que cette option est désactivée par défaut et qu'elle n'est généralement pas recommandée. Utilisez plutôt le filtrage des sources pour renvoyer certains sous-ensembles du document source original.

Dans l'exemple de requête ci-dessous, nous utilisons le paramètre stored_fields pour récupérer le champ summary, dont la configuration de mappage d'index est "store”: true.

Lorsque cette requête est exécutée, Elasticsearch vérifie si ce champ a été marqué par ”store”: true, s'il ne le trouve pas, il l'ignore complètement.

3. Affichage des sous-champs

Si votre index contient des sous-champs, vous pouvez utiliser la notation point pour spécifier le chemin d'accès au champ dans le paramètre fields. Notez que les sous-champs sont différents du type de champ imbriqué. Par exemple, si vous avez un sous-champ nommé address.city, vous pouvez l'inclure dans la réponse de recherche comme suit :

Dans cet exemple, la réponse de la recherche comprendra les valeurs des champs title, author et address.city.

4. Synthétique _source

Si vous souhaitez conserver la fonctionnalité de _source tout en économisant de l'espace disque, vous avez la possibilité d'utiliser le site synthétique _source dans votre mappage d'index. Synthetic _source est une fonctionnalité qui permet à Elasticsearch de reconstruire _source à partir de données existantes telles que des champs stockés et des valeurs de documents, même lorsque _source est désactivé. Cela vous permet d'économiser beaucoup d'espace de stockage au prix d'une vitesse légèrement inférieure au moment de l'interrogation, car la reconstruction se fait à la volée. Activez cette fonction en utilisant les valeurs ci-dessous dans vos paramètres d'index :

Parmi les avantages de l'utilisation de la version synthétique de _source , citons : l'affichage complet du document lors de l'utilisation de l'API _search, le filtrage des sources et la compatibilité avec d'autres fonctionnalités et outils tels que Kibana qui s'attendent à ce que _source soit disponible, tout en évitant d'avoir à stocker le document _source dans son intégralité.

5. Champs d'exécution

Les champs d'exécution vous permettent de définir des champs scriptés au moment de la requête ou dans votre mappage d'index sous un bloc d'exécution. Ces champs ne sont jamais indexés, de sorte que l'ajout d'un champ d'exécution n'augmente pas la taille de l'index mais n'apparaîtra jamais dans _source. Les champs d'exécution définis dans le mappage sont persistants et disponibles pour toutes les requêtes, tandis que les champs d'exécution définis au moment de la requête sont temporaires et ne sont disponibles que dans cette requête de recherche.

Le principal avantage de l'utilisation des champs d'exécution est la possibilité d'ajouter des champs aux documents après les avoir ingérés, ce qui simplifie vos décisions en matière de mappage. Les champs d'exécution sont également très utiles pour enrichir vos documents avec des valeurs qui n'existent pas dans le document original mais qui sont générées à l'aide d'un script, comme le formatage d'une chaîne de caractères ou le calcul d'un score.

Il convient également de noter que les champs d'exécution peuvent nuire aux performances, car un script devra être exécuté pour chaque document de l'ensemble des résultats. Pour récupérer un champ d'exécution, vous pouvez également utiliser le paramètre fields de l'API _search.

Conclusion

L'affichage des champs d'un index Elasticsearch peut aller de la simple récupération des valeurs à l'aide du mappage d'index ou de _source, à des méthodes plus avancées utilisant fields, docvalue_fields, ou des champs d'exécution pour un meilleur contrôle et une plus grande efficacité. Il est essentiel de comprendre les compromis entre les différentes méthodes pour optimiser vos expériences de recherche. Qu'il s'agisse d'optimiser les charges utiles, d'enrichir des documents ou d'utiliser le site synthétique _source pour économiser de l'espace de stockage, Elasticsearch vous offre de nombreux outils et fonctionnalités pour trouver les données dont vous avez besoin, de la manière dont vous en avez besoin. Ces techniques peuvent vous aider à comprendre la structure de vos données, à identifier des champs spécifiques et à résoudre des problèmes.

Dans cet article, nous examinerons ces types de champs, quand utiliser chacun d'entre eux et comment ils sont liés à la génération d'encarts et aux stratégies d'utilisation, à la fois lors de l'indexation et de l'interrogation.

Type de vecteur dense

Le type de champ dense_vector dans Elasticsearch est utilisé pour stocker des vecteurs denses, qui sont des représentations numériques de données telles que du texte, des images et de l'audio, où presque toutes les dimensions sont pertinentes... Ces vecteurs sont générés à l'aide de modèles d'intégration fournis par des plateformes telles que OpenAI, Cohere ou Hugging Face, et sont conçus pour capturer la signification sémantique globale des données, même si elles ne partagent pas de termes exacts avec d'autres documents.

Dans Elasticsearch, les vecteurs denses peuvent avoir jusqu'à 4096 dimensions en fonction du modèle utilisé. Par exemple, le modèle all-MiniLM-L6-v2 génère des vecteurs de 384 dimensions, tandis que le modèle text-embedding-ada-002 d'OpenAI produit des vecteurs de 1536 dimensions.

Le champ dense_vector est généralement adopté comme type par défaut pour stocker ce type d'intégration lorsqu'un plus grand contrôle est nécessaire, comme l'utilisation de vecteurs pré-générés, l'application de fonctions de similarité personnalisées ou l'intégration avec des modèles externes.

Quand et pourquoi utiliser le type dense_vector ?

Les vecteurs denses sont excellents pour capturer la similarité sémantique entre des phrases, des paragraphes ou des documents entiers. Ils fonctionnent très bien lorsque l'objectif est de comparer le sens global des textes, même s'ils ne partagent pas les mêmes termes.

Le champ de vecteurs denses est idéal lorsque vous disposez déjà d'un pipeline externe de génération d'incrustations utilisant des modèles fournis par des plateformes telles que OpenAI, Cohere ou Hugging Face et que vous souhaitez uniquement stocker et interroger ces vecteurs manuellement. Ce type de champ offre une grande compatibilité avec les modèles d'intégration et une souplesse totale en matière de génération et d'interrogation, ce qui permet de contrôler la manière dont les vecteurs sont produits, indexés et utilisés lors de la recherche.

En outre, il prend en charge différentes formes de recherche sémantique, avec des requêtes telles que k-NN ou script_score pour les cas où il est nécessaire d'ajuster la logique de classement. Ces possibilités font du vecteur dense un outil idéal pour des applications telles que RAG (Retrieval-Augmented Generation), les systèmes de recommandation et les recherches personnalisées basées sur la similarité.

Enfin, le champ vous permet de personnaliser la logique de pertinence, en utilisant des fonctions telles que cosineSimilarity, dotProduct ou l2norm pour adapter le classement aux besoins de votre cas d'utilisation.

Les vecteurs denses restent la meilleure option pour ceux qui ont besoin de flexibilité, de personnalisation et de compatibilité avec des cas d'utilisation avancés comme ceux mentionnés ci-dessus.

Comment utiliser la requête pour un type de vecteur dense ?

Les recherches sur les champs définis comme dense_vector utilisent la requête des k-voisins les plus proches. Cette requête est chargée de trouver les documents dont le vecteur dense est le plus proche du vecteur de la requête. Vous trouverez ci-dessous un exemple d'application d'une requête k-NN à un champ vectoriel dense :

Outre la requête k-NN, s'il est nécessaire de personnaliser la notation des documents, il est également possible d'utiliser la requête script_score, en la combinant avec des fonctions de comparaison vectorielle telles que cosineSimilarity, dotProduct ou l2norm pour calculer la pertinence d'une manière plus contrôlée. Voir l'exemple :

Si vous souhaitez aller plus loin, je vous recommande d'explorer l'article Comment configurer la recherche vectorielle dans Elasticsearch.

Type de vecteur épars

Le type de champ sparse_vector est utilisé pour stocker des vecteurs épars, qui sont des représentations numériques où la plupart des valeurs sont nulles et où seuls quelques termes ont des poids significatifs. Ce type de vecteur est courant dans les modèles basés sur les termes tels que SPLADE ou ELSER (Elastic Learned Sparse EncodeR).

Quand et pourquoi utiliser un type de vecteur peu dense ?

Les vecteurs épars sont idéaux lorsque vous avez besoin d'une recherche plus précise en termes lexicaux, sans sacrifier l'intelligence sémantique. Ils représentent le texte sous forme de paires jeton/valeur, en ne mettant en évidence que les termes les plus pertinents avec les poids associés, ce qui permet de gagner en clarté, en contrôle et en efficacité.

Ce type de champ est particulièrement utile lorsque vous générez des vecteurs basés sur des termes, comme dans les modèles ELSER ou SPLADE, qui attribuent des poids différents à chaque mot en fonction de son importance relative dans le texte.

Pour les cas où vous souhaitez contrôler l'influence de mots spécifiques dans la requête, les types de vecteurs épars vous permettent d'ajuster manuellement le poids des termes afin d'optimiser le classement des résultats.

Parmi les principaux avantages, citons la transparence de la recherche, puisqu'il est possible de comprendre clairement pourquoi un document a été jugé pertinent, et l'efficacité du stockage, puisque seuls les jetons dont la valeur n'est pas nulle sont enregistrés, contrairement aux vecteurs denses qui stockent toutes les dimensions.

En outre, les vecteurs épars sont le complément idéal des stratégies de recherche hybrides et peuvent même être combinés avec des vecteurs denses pour associer la précision lexicale à la compréhension sémantique.

Comment utiliser l'interrogation pour le type de vecteur épars ?

La requête sparse_vector vous permet de rechercher des documents sur la base d'un vecteur de requête au format jeton/valeur. Vous trouverez ci-dessous un exemple de requête :

Si vous préférez utiliser un modèle formé, il est possible d'utiliser un point final d'inférence qui transforme automatiquement le texte de la requête en un vecteur peu dense :

Pour approfondir ce sujet, je vous suggère de lire Understanding sparse vector embeddings with trained ML models (Comprendre les encastrements de vecteurs épars avec des modèles ML formés).

Type de texte sémantique

Le type de champ semantic_text est le moyen le plus simple et le plus direct d'utiliser la recherche sémantique dans Elasticsearch. Il gère automatiquement la génération de l'intégration, à la fois au moment de l'indexation et de l'interrogation, par le biais d'un point final d'inférence. Cela signifie que vous n'avez pas à vous soucier de générer ou de stocker des vecteurs manuellement.

Quand et pourquoi utiliser le texte sémantique ?

Le champ semantic_text est idéal pour ceux qui veulent commencer avec un minimum d'effort technique et sans avoir à manipuler les vecteurs manuellement. Ce champ automatise des étapes telles que la génération de l'encastrement et le mappage de la recherche vectorielle, ce qui rend l'installation plus rapide et plus pratique.

Vous devriez envisager d'utiliser semantic_text si vous appréciez la simplicité et l'abstraction, car il élimine la complexité de la configuration manuelle des mappings, de la génération d'embedding et des pipelines d'ingestion. Il suffit de sélectionner le modèle d'inférence et Elasticsearch s'occupe du reste.

Parmi les principaux avantages, citons la génération automatique de l'intégration, effectuée à la fois pendant l'indexation et l'interrogation, et le mappage prêt à l'emploi, qui est préconfiguré pour prendre en charge le modèle d'inférence sélectionné.

En outre, le champ offre une prise en charge native du découpage automatique des textes longs (text chunking), ce qui permet de diviser les textes volumineux en passages plus petits, chacun ayant sa propre intégration, ce qui améliore la précision de la recherche. La productivité s'en trouve grandement améliorée, en particulier pour les équipes qui souhaitent fournir rapidement de la valeur ajoutée sans avoir à s'occuper de l'ingénierie sous-jacente de la recherche sémantique.

Cependant, bien que semantic_text offre rapidité et simplicité, cette approche présente certaines limites. Il permet d'utiliser des modèles standard du marché, pour autant qu'ils soient disponibles en tant que points de terminaison d'inférence dans Elasticsearch. Cependant, il ne prend pas en charge les encastrements générés de l'extérieur, comme c'est le cas avec le champ dense_vector.

Si vous avez besoin de plus de contrôle sur la manière dont les vecteurs sont générés, si vous souhaitez utiliser vos propres incorporations ou si vous devez combiner plusieurs champs pour des stratégies avancées, les champs dense_vector et sparse_vector offrent la flexibilité nécessaire pour des scénarios plus personnalisés ou spécifiques à un domaine.

Comment utiliser la requête pour le type de texte sémantique ?

Avant semantic_text, il était nécessaire d'utiliser une requête différente selon le type d'intégration (dense ou éparse). Une requête sparse_vector a été utilisée pour les champs peu denses, tandis que les champs dense_vector ont nécessité des requêtes KNN.

Avec le type de texte sémantique, la recherche est effectuée à l'aide de la requête sémantique, qui génère automatiquement le vecteur de la requête et le compare avec les enchâssements des documents indexés. Le type semantic_text vous permet de définir un point final d'inférence pour intégrer la requête, mais si aucun n'est spécifié, le même point final que celui utilisé lors de l'indexation sera appliqué à la requête.

Pour en savoir plus, je vous propose de lire l'article Elasticsearch new semantic_text mapping : Simplifier la recherche sémantique.

Conclusion

Lors du choix de la méthode de mappage des embeddings dans Elasticsearch, il est essentiel de comprendre comment vous souhaitez générer les vecteurs et quel est le niveau de contrôle dont vous avez besoin sur ceux-ci. Si vous recherchez la simplicité, le champ de texte sémantique permet une recherche sémantique automatique et évolutive, ce qui le rend idéal pour de nombreux cas d'utilisation initiaux. Lorsqu'un contrôle plus poussé, des performances plus fines ou une intégration avec des modèles personnalisés sont nécessaires, les champs de vecteurs denses et de vecteurs clairsemés offrent la flexibilité nécessaire.

Le type de champ idéal dépend de votre cas d'utilisation, de l'infrastructure disponible et de la maturité de votre pile d'apprentissage automatique. Plus important encore, Elastic offre les outils nécessaires pour construire des systèmes de recherche modernes et hautement adaptables.

Références

• Type de champ texte sémantique

• Type de champ vectoriel épars

• Type de champ vectoriel dense

• Requête sémantique

• Requête sur les vecteurs épars

• Recherche kNN

• Nouveau mappage semantic_text d'Elasticsearch : Simplifier la recherche sémantique

• Comprendre les encastrements de vecteurs épars à l'aide de modèles ML entraînés