Comment nous avons construit un modèle de mise en évidence sémantique pour l'élagage du contexte RAG et la sauvegarde des tokens

Le problème : Le bruit des RAG et le gaspillage de jetons

Larecherche vectorielle est une base solide pour les systèmes RAG (assistants d’entreprise, agents d’intelligence artificielle, robots d’assistance à la clientèle, etc. Elle permet de trouver de manière fiable les documents importants. Mais la recherche vectorielle ne résout pas à elle seule le problème du contexte. Même les index bien réglés renvoient des morceaux qui sont largement pertinents, alors que seule une petite fraction des phrases à l’intérieur de ces morceaux répond réellement à la requête.

Dans les systèmes de production, cette lacune apparaît immédiatement. Une seule requête peut donner lieu à des dizaines de documents, chacun contenant des milliers de tokens. Seule une poignée de phrases contient le signal réel ; le reste est un contexte qui gonfle l'utilisation des jetons, ralentit l'inférence et distrait souvent le LLM. Le problème devient encore plus évident dans les flux de travail des agents, où les requêtes elles-mêmes sont le résultat d'un raisonnement en plusieurs étapes et ne correspondent qu'à de petites parties du texte récupéré.

Il en résulte un besoin évident d'un modèle capable d'identifier et de mettre en évidence les phrases utiles et d'ignorer le reste - essentiellementun filtrage de la pertinence au niveau de la phrase, ou ce que de nombreuses équipes appellent l'élagage du contexte. L'objectif est simple : conserver les parties importantes et éliminer le bruit avant qu'il n'atteigne le LLM.

La mise en évidence traditionnelle par mot-clé ne peut pas résoudre ce problème. Par exemple, si un utilisateur demande "Comment améliorer l'efficacité de l'exécution du code Python ?", un surligneur de mots-clés repérera "Python" et "efficacité", mais ne verra pas la phrase qui répond réellement à la question - "Utiliser les opérations vectorisées NumPy au lieu des boucles" - parce qu'elle ne partage aucun mot-clé avec la requête. Ce dont nous avons besoin, c'est d'une compréhension sémantique, et non d'une correspondance de chaînes de caractères.

Un modèle de mise en évidence sémantique pour le filtrage du bruit et l'élagage du contexte dans RAG

Pour faciliter la tâche des concepteurs de RAG, nous avons formé et mis à disposition un modèle de mise en évidence sémantique qui identifie et met en évidence les phrases des documents récupérés qui sont les plus sémantiquement alignées avec la requête. Le modèle fournit actuellement des performances de pointe en anglais et en chinois et est conçu pour s'intégrer directement dans les pipelines RAG existants.

Détails du modèle

• Référence : zilliz/semantic-highlight-bilingual-v1

• Licence : MIT (commerciale et conviviale)

• Architecture : 0.6B encoder-only model based on BGE-M3 Reranker v2

• Fenêtre de contexte : 8192 tokens

• Langues supportées : anglais et chinois

La mise en évidence sémantique fournit les signaux de pertinence nécessaires pour sélectionner uniquement les parties utiles des longs documents récupérés. En pratique, ce modèle permet

• une meilleure interprétabilité, en montrant quelles parties d'un document sont réellement importantes

• une réduction de 70 à 80 % du coût des jetons en n'envoyant que les phrases mises en évidence au LLM

• une meilleure qualité de réponse, puisque le modèle voit moins de contexte non pertinent

• un débogage plus facile, car les ingénieurs peuvent inspecter directement les correspondances au niveau de la phrase.

Résultats de l'évaluation : Atteindre la performance SOTA

Nous avons évalué notre modèle de surlignage sémantique sur plusieurs ensembles de données couvrant à la fois l'anglais et le chinois, dans des conditions in-domain et out-of-domain.

Les ensembles de référence sont les suivants

• Anglais multi-span QA : multispanqa

• Wikipedia en anglais hors domaine : wikitext2

• AQ chinoise à travées multiples : multispanqa_zh

• Wikipédia en chinois hors domaine : wikitext2_zh

Les modèles évalués sont les suivants

• la série Open Provence

• Série Provence/XProvence de Naver

• L'outil de mise en valeur sémantique d'OpenSearch

• Notre modèle bilingue entraîné : zilliz/semantic-highlight-bilingual-v1

Dans les quatre ensembles de données, notre modèle obtient le meilleur classement. Plus important encore, c'est le seul modèle qui obtient de bons résultats à la fois en anglais et en chinois. Les modèles concurrents se concentrent exclusivement sur l'anglais ou affichent des performances nettement inférieures sur les textes chinois.

Comment nous avons construit ce modèle de mise en évidence sémantique

La formation d'un modèle pour cette tâche n'est pas la partie la plus difficile ; la formation d'un bon modèle qui gère les problèmes antérieurs et fournit des performances proches de celles de la SOTA est là où le vrai travail se produit. Notre approche s'est concentrée sur deux points :

• Architecture du modèle : utilisation d'un encodeur uniquement pour une inférence rapide.

• Données d'entraînement : générer des étiquettes de pertinence de haute qualité en utilisant des LLM capables de raisonnement et mettre à l'échelle la génération de données avec des cadres d'inférence locaux.

Architecture du modèle

Nous avons construit le modèle comme un réseau léger d'encodeur seul qui traite l'élagage du contexte comme une tâche d'évaluation de la pertinence au niveau du jeton. Cette conception s'inspire de Provence, une approche d'élagage du contexte présentée par Naver à l'ICLR 2025, qui recadre l'élagage de "choisir le bon morceau" à "noter chaque jeton". Ce cadre s'aligne naturellement sur la mise en évidence sémantique, où des signaux fins sont essentiels.

Les modèles à encodeur seul ne constituent pas l'architecture la plus récente, mais ils restent extrêmement pratiques dans ce domaine : ils sont rapides, faciles à mettre à l'échelle et peuvent produire des scores de pertinence pour toutes les positions des mots en parallèle. Pour un système RAG de production, cet avantage en termes de vitesse est bien plus important que l'utilisation d'un modèle de décodeur plus grand.

Une fois que nous avons calculé les scores de pertinence au niveau du jeton, nous les agrégeons pour obtenir des scores au niveau de la phrase. Cette étape permet de transformer les signaux de jetons bruyants en une mesure de pertinence stable et interprétable. Les phrases dépassant un seuil configurable sont mises en évidence ; toutes les autres sont filtrées. On obtient ainsi un mécanisme simple et fiable de sélection des phrases qui ont réellement de l'importance pour la requête.

Processus d'inférence

Au moment de l'exécution, notre modèle de mise en évidence sémantique suit un pipeline simple :

1. Entrée - Le processus commence par une requête de l'utilisateur. Les documents récupérés sont traités comme des contextes candidats pour l'évaluation de la pertinence.

2. Traitement du modèle - La requête et le contexte sont concaténés en une seule séquence : [BOS] + Requête + Contexte

3. Évaluation des jetons - Chaque jeton du contexte se voit attribuer un score de pertinence compris entre 0 et 1, reflétant l'importance de son lien avec la requête.

4. Agrégation des phrases - Les scores des jetons sont agrégés au niveau de la phrase, généralement en calculant une moyenne, afin de produire un score de pertinence pour chaque phrase.

5. Filtrage par seuil - Les phrases dont le score est supérieur à un seuil configurable sont mises en évidence et conservées, tandis que les phrases à faible score sont filtrées avant d'être transmises au LLM en aval.

Modèle de base : BGE-M3 Reranker v2

Nous avons choisi le BGE-M3 Reranker v2 comme modèle de base pour plusieurs raisons :

1. Il utilise une architecture d'encodeur adaptée à l'évaluation des jetons et des phrases.

2. Prise en charge de plusieurs langues avec optimisation pour l'anglais et le chinois

3. Fournit une fenêtre contextuelle de 8192 jetons appropriée pour les documents RAG plus longs.

4. Maintient 0,6 milliard de paramètres - suffisamment fort sans être lourd en termes de calcul.

5. Assure une connaissance suffisante du monde dans le modèle de base

6. Entraîné pour le reranking, qui s'aligne étroitement sur les tâches de jugement de pertinence.

Données de formation : Annotation LLM avec raisonnement

Une fois l'architecture du modèle finalisée, le défi suivant consistait à construire un ensemble de données permettant d'entraîner un modèle fiable. Nous avons commencé par étudier la façon dont Open Provence gère cela. Leur approche utilise des ensembles de données publics d'assurance qualité et un petit LLM pour étiqueter les phrases pertinentes. Elle s'adapte bien et est facile à automatiser, ce qui en fait une bonne base de référence pour nous.

Mais nous avons rapidement rencontré le même problème qu'ils décrivent : si vous demandez à un LLM de produire directement des étiquettes au niveau de la phrase, les résultats ne sont pas toujours stables. Certaines étiquettes sont correctes, d'autres sont douteuses, et il est difficile de nettoyer les choses par la suite. L'annotation entièrement manuelle n'était pas non plus une option - nous avions besoin de beaucoup plus de données que nous ne pourrions jamais étiqueter à la main.

Pour améliorer la stabilité sans sacrifier l'évolutivité, nous avons fait un changement : le LLM doit fournir un court extrait de raisonnement pour chaque étiquette qu'il produit. Chaque exemple d'entraînement comprend la requête, le document, la portée des phrases et une brève explication de la pertinence ou de la non-pertinence d'une phrase. Ce petit ajustement a rendu les annotations beaucoup plus cohérentes et nous a donné quelque chose de concret à référencer lors de la validation ou du débogage de l'ensemble de données.

L'inclusion du raisonnement s'est avérée étonnamment précieuse :

• Une meilleure qualité d'annotation : L'écriture du raisonnement fonctionne comme un autocontrôle, ce qui réduit les étiquettes aléatoires ou incohérentes.

• Meilleure observabilité : Nous pouvons voir pourquoi une phrase a été sélectionnée au lieu de traiter l'étiquette comme une boîte noire.

• Débogage plus facile : Lorsque quelque chose ne semble pas correct, le raisonnement permet de déterminer facilement si le problème vient de l'invite, du domaine ou de la logique d'annotation.

• Données réutilisables : Même si nous adoptons un modèle d'étiquetage différent à l'avenir, les traces de raisonnement restent utiles pour le réétiquetage ou l'audit.

Le flux de travail d'annotation se présente comme suit :

Qwen3 8B pour l'annotation

Pour l'annotation, nous avons choisi Qwen3 8B parce qu'il prend nativement en charge un "mode de réflexion" via les sorties, ce qui facilite grandement l'extraction de traces de raisonnement cohérentes. Les modèles plus petits ne nous donnaient pas d'étiquettes stables, et les modèles plus grands étaient plus lents et inutilement coûteux pour ce type de pipeline. Qwen3 8B a trouvé le bon équilibre entre la qualité, la vitesse et le coût.

Nous avons exécuté toutes les annotations à l'aide d'un service vLLM local plutôt que d'API dans le nuage. Cela nous a permis d'obtenir un débit élevé, des performances prévisibles et un coût beaucoup plus faible, en échangeant du temps de GPU contre des jetons d'API, ce qui est plus avantageux lorsque l'on génère des millions d'échantillons.

Échelle des ensembles de données

Au total, nous avons créé plus de 5 millions d'échantillons de formation bilingues, répartis à peu près équitablement entre l'anglais et le chinois.

• Sources anglaises : MS MARCO, Natural Questions, GooAQ

• Sources chinoises : DuReader, Wikipedia chinois, mmarco_chinese

Une partie du jeu de données provient de la réannotation de données existantes utilisées par des projets comme Open Provence. Le reste a été généré à partir de corpus bruts en créant d'abord des paires requête-contexte et en les étiquetant ensuite avec notre pipeline basé sur le raisonnement.

Toutes les données d'entraînement annotées sont également disponibles sur HuggingFace pour le développement de la communauté et les références d'entraînement : Jeux de données Zilliz

Méthode de formation

Une fois l'architecture du modèle et le jeu de données prêts, nous avons entraîné le modèle sur 8× A100 GPU pour trois époques, ce qui a pris environ 9 heures de bout en bout.

Remarque : l'entraînement n'a porté que sur la tête d'élagage, qui est responsable de la tâche de mise en évidence sémantique. Nous n'avons pas entraîné la tête Rerank, car le fait de se concentrer uniquement sur l'objectif d'élagage a permis d'obtenir de meilleurs résultats pour l'évaluation de la pertinence au niveau des phrases.

Étude de cas en situation réelle

Voici donc un exemple réel qui montre comment le modèle se comporte dans un cas limite courant : lorsque le texte extrait contient à la fois la bonne réponse et un distracteur très tentant.

Requête : Qui a écrit L'assassinat d'un cerf sacré ?

Contexte (5 phrases) :

1\. The Killing of a Sacred Deer is a 2017 psychological horror film directed by Yorgos Lanthimos,
with a screenplay by Lanthimos and Efthymis Filippou.
2. The film stars Colin Farrell, Nicole Kidman, Barry Keoghan, Raffey Cassidy,
Sunny Suljic, Alicia Silverstone, and Bill Camp.
3. The story is based on the ancient Greek playwright Euripides’ play Iphigenia in Aulis.
4. The film tells the story of a cardiac surgeon (Farrell) who secretly
befriends a teenager (Keoghan) connected to his past.
5. He introduces the boy to his family, who then mysteriously fall ill.

Réponse correcte : Phrase 1 (indique explicitement "scénario de Lanthimos et Efthymis Filippou")

Cet exemple comporte un piège : la phrase 3 mentionne qu'"Euripide" a écrit la pièce originale. Mais la question demande "qui a écrit le film The Killing of a Sacred Deer", et la réponse devrait être les scénaristes du film, et non le dramaturge grec d'il y a des milliers d'années.

Résultats du modèle

Modèle	Trouve la bonne réponse ?	Prédiction
Notre modèle	✓	Phrases sélectionnées 1 (correcte) et 3
XProvence v1	✗	N'a sélectionné que la phrase 3, n'a pas trouvé la bonne réponse
XProvence v2	✗	Seule la phrase 3 a été sélectionnée, la réponse correcte n'a pas été trouvée

Comparaison des scores des phrases clés :

Phrase	Notre modèle	XProvence v1	XProvence v2
Phrase 1 (scénario de film, réponse correcte)	0.915	0.133	0.081
Phrase 3 (pièce de théâtre originale, distracteur)	0.719	0.947	0.802

Modèles XProvence :

• Fortement attiré par "Euripide" et "pièce", donnant à la phrase 3 des scores presque parfaits (0.947 et 0.802)

• Ignore complètement la réponse réelle (phrase 1), donnant des scores extrêmement bas (0.133 et 0.081)

• Même en abaissant le seuil de 0,5 à 0,2, il ne parvient toujours pas à trouver la bonne réponse.

Notre modèle :

• attribue correctement à la phrase 1 le score le plus élevé (0,915)

• Attribue toujours une certaine pertinence à la phrase 3 (0.719) parce qu'elle est liée à l'arrière-plan

• sépare clairement les deux phrases avec une marge d'environ 0,2

Cet exemple illustre la force principale du modèle : comprendre l'intention de la requête plutôt que de se contenter de faire correspondre des mots-clés de surface. Dans ce contexte, "Qui a écrit L'assassinat d'un cerf sacré" fait référence au film, et non à la pièce de théâtre grecque. Notre modèle s'en rend compte, alors que d'autres se laissent distraire par des indices lexicaux forts.

Essayez-le et dites-nous ce que vous en pensez

Notre modèle zilliz/semantic-highlight-bilingual-v1 est désormais entièrement ouvert sous la licence MIT et prêt à être utilisé en production. Vous pouvez l'intégrer dans votre pipeline RAG, l'adapter à votre propre domaine ou créer de nouveaux outils à partir de ce modèle. Les contributions et les commentaires de la communauté sont les bienvenus.

• Téléchargement depuis HuggingFace: zilliz/semantic-highlight-bilingual-v1

• Toutes les données d'entraînement annotées : https://huggingface.co/zilliz/datasets

La mise en évidence sémantique disponible dans Milvus et Zilliz Cloud

La mise en évidence sémantique est également intégrée directement dans Milvus et Zilliz Cloud (Milvus entièrement géré), ce qui permet aux utilisateurs d'avoir une vision claire de la raison pour laquelle chaque document a été récupéré. Au lieu d'analyser des morceaux entiers, vous voyez immédiatement les phrases spécifiques qui se rapportent à votre requête, même si le libellé ne correspond pas exactement. La recherche est ainsi plus facile à comprendre et plus rapide à déboguer. Pour les pipelines RAG, cela clarifie également ce sur quoi le LLM en aval est censé se concentrer, ce qui aide à la conception rapide et aux contrôles de qualité.

Essayez gratuitement le Semantic Highlighting dans un Cloud Zilliz entièrement géré.

Nous aimerions savoir comment cela fonctionne pour vous - rapports de bogues, idées d'amélioration, ou tout ce que vous découvrez en l'intégrant dans votre flux de travail.

Si vous souhaitez discuter plus en détail, n'hésitez pas à rejoindre notre canal Discord ou à réserver une session Milvus Office Hours de 20 minutes. Nous sommes toujours heureux de discuter avec d'autres constructeurs et d'échanger des notes.

Remerciements

Ce travail s'appuie sur un grand nombre d'idées géniales et de contributions open-source, et nous tenons à souligner les projets qui ont rendu ce modèle possible.

• Provence a introduit un cadre propre et pratique pour l'élagage de contexte en utilisant des modèles d'encodeurs légers.

• Open Provence a fourni une base de code solide et bien conçue - pipelines de formation, traitement des données et têtes de modèle - sous une licence permissive. Cela nous a donné un point de départ solide pour l'expérimentation.

Au-dessus de cette base, nous avons ajouté plusieurs contributions de notre cru :

• Utilisation du raisonnement LLM pour générer des étiquettes de pertinence de meilleure qualité

• Création de près de 5 millions d' échantillons de formation bilingues alignés sur les charges de travail réelles de RAG

• Choix d'un modèle de base mieux adapté à l'évaluation de la pertinence du contexte long(BGE-M3 Reranker v2)

• Entraînement de la tête d'élagage pour spécialiser le modèle pour la mise en évidence sémantique.

Nous sommes reconnaissants aux équipes de Provence et d'Open Provence d'avoir publié leur travail ouvertement. Leurs contributions ont considérablement accéléré notre développement et rendu ce projet possible.