L'expansion des requêtes a longtemps été une technique privilégiée pour améliorer les systèmes de recherche, bien qu'elle ait été reléguée au second plan depuis l'apparition des embeddings sémantiques. Bien que certains puissent la considérer comme dépassée dans notre contexte actuel de RAG et de recherche par agents, il ne faut pas l'écarter trop vite. Dans cette analyse approfondie, nous verrons comment la combinaison de l'expansion automatique des requêtes avec jina-embeddings-v3 et les LLMs peut améliorer vos performances de recherche et fournir des résultats vraiment pertinents.
tagQu'est-ce que l'expansion des requêtes ?
L'expansion des requêtes a été développée pour les systèmes de recherche qui jugent la pertinence en faisant correspondre les mots des requêtes avec les documents qui les contiennent, comme le tf-idf ou d'autres schémas de "vecteurs épars". Cela présente des limitations évidentes. Les variantes des mots interfèrent avec la correspondance, comme "courir" et "courant", ou "optimiser" vs "optimize". Le prétraitement linguistique peut atténuer certains de ces problèmes, mais pas tous. Les termes techniques, les synonymes et les mots apparentés sont beaucoup plus difficiles à traiter. Par exemple, une requête pour la recherche médicale sur le "coronavirus" n'identifiera pas automatiquement les documents qui parlent de "COVID" ou "SARS-CoV-2", même si ce seraient de très bonnes correspondances.
L'expansion des requêtes a été inventée comme solution.
L'idée est d'ajouter des mots et des phrases supplémentaires aux requêtes pour augmenter la probabilité d'identifier de bonnes correspondances. Ainsi, une requête pour "coronavirus" pourrait se voir ajouter les termes "COVID" et "SARS-CoV-2". Cela peut améliorer considérablement les performances de recherche.

Il n'est pas facile de décider quels termes doivent être ajoutés à une requête, et il y a eu beaucoup de travail sur la façon d'identifier les bons termes et comment les pondérer pour la recherche de type tf-idf. Les approches courantes incluent :
- L'utilisation d'un thésaurus géré manuellement.
- L'extraction de données de grands corpus de textes pour trouver des mots apparentés.
- L'identification d'autres termes utilisés dans des requêtes similaires à partir d'un journal de requêtes.
- L'apprentissage des mots et phrases qui font de bonnes expansions de requêtes à partir du retour des utilisateurs.
Cependant, les modèles d'embedding sémantique sont censés éliminer le besoin d'expansion des requêtes. Les bons embeddings de texte pour "coronavirus", "COVID" et "SARS-CoV-2" devraient être très proches les uns des autres dans l'espace vectoriel d'embedding. Ils devraient naturellement correspondre sans aucune augmentation.
Mais, bien que cela devrait être vrai en théorie, les embeddings réels créés par des modèles réels sont souvent insuffisants. Les mots dans les embeddings peuvent être ambigus et l'ajout de mots à une requête peut l'orienter vers de meilleures correspondances si vous utilisez les bons mots. Par exemple, un embedding pour "éruption cutanée" pourrait identifier des documents sur "agir de manière irréfléchie" et "crème pour la peau" tout en manquant un article de journal médical qui parle de "dermatite". L'ajout de termes pertinents orientera probablement l'embedding loin des correspondances non liées vers de meilleures correspondances.
tagExpansion des requêtes par LLM
Au lieu d'utiliser un thésaurus ou de faire de l'extraction lexicale de données, nous avons examiné l'utilisation d'un LLM pour faire l'expansion des requêtes. Les LLMs présentent quelques avantages potentiels importants :
- Large connaissance lexicale : Comme ils sont entraînés sur des jeux de données vastes et diversifiés, il y a moins de préoccupations concernant la sélection d'un thésaurus approprié ou l'obtention des bonnes données.
- Capacité de jugement : Tous les termes d'expansion proposés ne sont pas nécessairement appropriés à une requête spécifique. Les LLMs ne font peut-être pas des jugements parfaits sur la thématique, mais les alternatives ne peuvent pas vraiment faire de jugements du tout.
- Flexibilité : Vous pouvez ajuster votre prompt aux besoins de la tâche de recherche, tandis que les autres approches sont rigides et peuvent nécessiter beaucoup de travail pour s'adapter à de nouveaux domaines ou sources de données.
Une fois que le LLM a proposé une liste de termes, l'expansion des requêtes pour les embeddings fonctionne de la même manière que les schémas traditionnels d'expansion des requêtes : Nous ajoutons des termes au texte de la requête puis utilisons un modèle d'embedding pour créer un vecteur d'embedding de requête.

Pour que cela fonctionne, vous avez besoin de :
- Accès à un LLM.
- Un modèle de prompt pour solliciter des termes d'expansion du LLM.
- Un modèle d'embedding de texte.
tagTest pratique
Nous avons réalisé quelques expériences pour voir si cette approche ajoute de la valeur à la recherche d'information textuelle. Nos tests ont utilisé :
- Un LLM : Gemini 2.0 Flash de Google.
- Deux modèles d'embedding pour voir si l'expansion des requêtes par LLM se généralise à travers les modèles : jina-embeddings-v3 et
all-MiniLM-L6-v2
. - Un sous-ensemble des benchmarks BEIR pour la recherche d'information.
Nous avons effectué nos expériences dans deux conditions de prompting :
- Utilisation d'un modèle de prompt général pour solliciter des termes d'expansion.
- Utilisation de modèles de prompt spécifiques à la tâche.
Enfin, nous avons écrit nos prompts pour solliciter différents nombres de termes à ajouter : 100, 150 et 250.
Notre code et nos résultats sont disponibles sur GitHub pour reproduction.
tagRésultats
tagUtilisation d'un prompt général
Après quelques essais et erreurs, nous avons trouvé que le prompt suivant fonctionnait suffisamment bien avec Gemini 2.0 Flash :
Please provide additional search keywords and phrases for each of the key aspects of the following queries that make it easier to find the relevant documents (about {size} words per query): {query} Please respond in the following JSON schema: Expansion = {"qid": str, "additional_info": str} Return: list [Expansion]
Ce prompt nous permet de regrouper nos requêtes par lots de 20-50, en donnant un ID à chacune, et en récupérant une chaîne JSON qui relie chaque requête à une liste de termes d'expansion. Si vous utilisez un LLM différent, vous devrez peut-être expérimenter pour trouver un prompt qui lui convient.
Nous avons appliqué cette configuration avec jina-embeddings-v3 en utilisant l'adaptateur de recherche asymétrique. Avec cette approche, les requêtes et les documents sont encodés différemment — en utilisant le même modèle mais différentes extensions LoRA — pour optimiser les embeddings résultants pour la recherche d'information.
Nos résultats sur divers benchmarks BEIR sont dans le tableau ci-dessous. Les scores sont nDCG@10 (Gain Cumulatif Actualisé normalisé sur les dix premiers éléments récupérés).
Benchmark | Sans expansion | 100 termes | 150 termes | 250 termes |
---|---|---|---|---|
SciFact (Tâche de vérification des faits) |
72,74 | 73,39 | 74,16 | 74,33 |
TRECCOVID (Tâche de recherche médicale) |
77,55 | 76,74 | 77,12 | 79,28 |
FiQA (Recherche d'options financières) |
47,34 | 47,76 | 46,03 | 47,34 |
NFCorpus (Recherche d'information médicale) |
36,46 | 40,62 | 39,63 | 39,20 |
Touche2020 (Tâche de recherche d'arguments) |
26,24 | 26,91 | 27,15 | 27,54 |
Nous constatons ici que l'expansion des requêtes a presque toujours amélioré la recherche.
Pour tester la robustesse de cette approche, nous avons répété les mêmes tests avec all-MiniLM-L6-v2
, un modèle beaucoup plus petit qui produit des vecteurs d'embedding plus courts.

Les résultats sont dans le tableau ci-dessous :
Benchmark | Sans Expansion | 100 termes | 150 termes | 250 termes |
---|---|---|---|---|
SciFact (Tâche de vérification des faits) |
64.51 | 68.72 | 66.27 | 68.50 |
TRECCOVID (Tâche de recherche médicale) |
47.25 | 67.90 | 70.18 | 69.60 |
FiQA (Recherche d'options financières) |
36.87 | 33.96 | 32.60 | 31.84 |
NFCorpus (Recherche d'informations médicales) |
31.59 | 33.76 | 33.76 | 33.35 |
Touche2020 (Tâche de recherche d'arguments) |
16.90 | 25.31 | 23.52 | 23.23 |
Nous constatons ici une amélioration encore plus importante des scores de recherche. Dans l'ensemble, le modèle plus petit a davantage profité de l'expansion des requêtes. L'amélioration moyenne sur toutes les tâches est résumée dans le tableau ci-dessous :
Modèle | 100 termes | 150 termes | 250 termes |
---|---|---|---|
jina-embeddings-v3 | +1.02 | +0.75 | +1.48 |
all-MiniLM-L6-v2 |
+6.51 | +5.84 | +5.88 |
La grande différence d'amélioration nette entre les deux modèles est probablement due au fait que all-MiniLM-L6-v2
part d'un niveau de performance plus bas. Les embeddings de requêtes produits par jina-embeddings-v3 en mode de recherche asymétrique sont mieux capables de capturer les relations sémantiques clés, et il y a donc moins de place pour que l'expansion des requêtes ajoute de l'information. Mais ce résultat montre à quel point l'expansion des requêtes peut améliorer les performances des modèles plus compacts qui peuvent être préférables dans certains cas d'utilisation aux grands modèles.
Néanmoins, l'expansion des requêtes a apporté une amélioration significative à la recherche même pour les modèles haute performance comme jina-embeddings-v3, mais ce résultat n'est pas parfaitement cohérent à travers toutes les tâches et conditions.
Pour jina-embeddings-v3, ajouter plus de 100 termes à une requête était contre-productif pour les benchmarks FiQA et NFCorpus. Nous ne pouvons pas dire que plus de termes sont toujours meilleurs, mais les résultats sur les autres benchmarks indiquent que plus de termes sont au moins parfois meilleurs.
Pour all-MiniLM-L6-v2
, ajouter plus de 150 termes était toujours contre-productif, et sur trois tests, ajouter plus de 100 n'améliorait pas les scores. Sur un test (FiQA), l'ajout de même 100 termes a produit des résultats significativement plus bas. Nous pensons que c'est parce que jina-embeddings-v3 fait un meilleur travail pour capturer l'information sémantique dans les textes de requête longs.
Les deux modèles ont montré moins de réponse à l'expansion des requêtes sur les benchmarks FiQA et NFCorpus.
tagUtilisation de prompts spécifiques aux tâches
Le modèle de résultats rapporté ci-dessus suggère que bien que l'expansion des requêtes soit utile, l'utilisation des LLM risque d'ajouter des termes de requête inutiles qui réduisent les performances. Cela pourrait être causé par la nature générique du prompt.
Nous avons pris deux benchmarks — SciFact et FiQA — et créé des prompts plus spécifiques au domaine, comme celui ci-dessous :
Please provide additional search keywords and phrases for each of the key aspects of the following queries that make it easier to find the relevant documents scientific document that supports or rejects the scientific fact in the query field (about {size} words per query): {query} Please respond in the following JSON schema: Expansion = {"qid": str, "additional_info": str} Return: list [Expansion]
Cette approche a amélioré les performances de recherche presque dans tous les cas :
Benchmark | Modèle | Sans Expansion | 100 termes |
150 termes |
250 termes |
---|---|---|---|---|---|
SciFact | jina-embeddings-v3 | 72.74 | 75.85 (+2.46) | 75.07 (+0.91) | 75.13 (+0.80) |
SciFact | all-MiniLM-L6-v2 |
64.51 | 69.12 (+0.40) | 68.10 (+1.83) | 67.83 (-0.67) |
FiQA | jina-embeddings-v3 | 47.34 | 47.77 (+0.01) | 48.20 (+1.99) | 47.75 (+0.41) |
FiQA | all-MiniLM-L6-v2 |
36.87 | 34.71 (+0.75) | 34.68 (+2.08) | 34.50 (+2.66) |
Les scores se sont améliorés dans toutes les conditions sauf l'ajout de 250 termes aux requêtes SciFact avec all-MiniLM-L6-v2
. De plus, cette amélioration n'a pas été suffisante pour faire dépasser à all-MiniLM-L6-v2
sa propre référence sur FiQA.
Pour jina-embeddings-v3, nous voyons que les meilleurs résultats sont venus avec 100 ou 150 termes ajoutés. L'ajout de 250 termes était contre-productif. Cela confirme notre intuition qu'on peut ajouter trop de termes à sa requête, surtout si leur sens commence à s'éloigner de la cible.
tagConsidérations clés dans l'expansion des requêtes
L'expansion des requêtes peut clairement apporter des gains à la recherche basée sur les embeddings, mais s'accompagne de certaines mises en garde :
tagCoût
L'interaction avec un LLM ajoute de la latence et des coûts de calcul à la recherche d'information, et peut ajouter des coûts réels si vous utilisez un LLM commercial. L'amélioration modérée qu'elle apporte peut ne pas justifier la dépense.
tagIngénierie des prompts
Concevoir de bons modèles de prompts est un art empirique et expérimental. Nous ne prétendons pas que ceux que nous avons utilisés pour ce travail sont optimaux ou portables vers d'autres LLM. Nos expériences avec des prompts spécifiques aux tâches montrent que changer vos prompts peut avoir des effets très significatifs sur la qualité du résultat. Les résultats varient aussi considérablement selon les domaines.
Ces incertitudes augmentent le coût de développement et compromettent la maintenabilité. Tout changement du système — changement de LLM, de modèles d'embedding ou de domaine d'information — signifie revérifier et peut-être réimplémenter l'ensemble du processus.
tagAlternatives
Nous voyons ici que l'expansion des requêtes a apporté la plus grande amélioration au modèle d'embedding ayant les performances initiales les plus faibles. L'expansion des requêtes, du moins dans cette expérience, n'a pas été capable de combler l'écart de performance entre all-MiniLM-L6-v2
et jina-embeddings-v3, tandis que jina-embeddings-v3 a vu des améliorations plus modestes grâce à l'expansion des requêtes.
Dans ces circonstances, un utilisateur de all-MiniLM-L6-v2
obtiendrait de meilleurs résultats à moindre coût en adoptant jina-embeddings-v3 plutôt qu'en poursuivant l'expansion des requêtes.
tagDirections futures
Nous avons montré ici que l'expansion des requêtes peut améliorer les embeddings de requêtes, et que les LLM offrent un moyen simple et flexible d'obtenir de bons termes d'expansion de requêtes. Mais les gains relativement modestes suggèrent qu'il y a encore du travail à faire. Nous examinons plusieurs directions pour la recherche future :
- Tester la valeur de l'enrichissement terminologique dans la génération des embeddings de documents.
- Explorer les possibilités d'amélioration des requêtes dans d'autres techniques de recherche IA comme le reclassement.
- Comparer l'expansion des requêtes basée sur les LLM à des sources de termes plus anciennes et moins coûteuses en calcul, comme un thésaurus.
- Entraîner des modèles de langage spécifiquement pour être meilleurs en expansion de requêtes et leur fournir un entraînement plus spécifique au domaine.
- Limiter le nombre de termes ajoutés. 100 peut être trop pour commencer.
- Trouver des moyens d'identifier les termes d'expansion utiles et inutiles. Tout nombre fixe que nous imposons à l'expansion des requêtes ne sera pas parfaitement adapté et si nous pouvions évaluer dynamiquement les termes suggérés et ne garder que les bons, le résultat serait probablement une amélioration des performances.
Il s'agit d'une recherche très préliminaire, et nous sommes optimistes que des techniques comme celle-ci apporteront d'autres améliorations aux produits de base de recherche de Jina AI.