Cómo creamos un modelo de resaltado semántico para la depuración de contextos de la RAG y el ahorro de tokens

El problema: Ruido RAG y desperdicio de tokens

La búsqueda vectorial es una base sólida para los sistemas RAG: asistentes empresariales, agentes de IA, bots de atención al cliente, etc. Encuentra de forma fiable los documentos que importan. Pero la recuperación por sí sola no resuelve el problema del contexto. Incluso los índices bien ajustados devuelven fragmentos que son ampliamente relevantes, mientras que sólo una pequeña fracción de las frases dentro de esos fragmentos responden realmente a la consulta.

En los sistemas de producción, esta brecha aparece de inmediato. Una consulta puede contener docenas de documentos, cada uno de ellos con miles de tokens. Sólo un puñado de frases contiene la señal real; el resto es contexto que sobrecarga el uso de tokens, ralentiza la inferencia y a menudo distrae al LLM. El problema se hace aún más evidente en los flujos de trabajo con agentes, en los que las propias consultas son el resultado de un razonamiento de varios pasos y sólo coinciden con pequeñas partes del texto recuperado.

Esto crea una clara necesidad de un modelo que pueda identificar y resaltar las frases útiles e ignorar el resto: básicamente, el filtrado de relevancia a nivel de frase, o lo que muchos equipos denominan poda de contexto. El objetivo es sencillo: conservar las partes que importan y eliminar el ruido antes de que llegue al LLM.

El resaltado tradicional basado en palabras clave no puede resolver este problema. Por ejemplo, si un usuario pregunta: "¿Cómo puedo mejorar la eficiencia de la ejecución del código Python?", un resaltador de palabras clave seleccionará "Python" y "eficiencia", pero pasará por alto la frase que realmente responde a la pregunta - "Utilizar operaciones vectorizadas NumPy en lugar de bucles"- porque no comparte ninguna palabra clave con la consulta. Lo que necesitamos es comprensión semántica, no coincidencia de cadenas.

Un modelo de resaltado semántico para el filtrado de ruido RAG y la poda de contexto

Para facilitar esta tarea a los creadores de RAG, hemos entrenado y desarrollado un modelo de resaltado semántico que identifica y resalta las frases de los documentos recuperados que están más alineadas semánticamente con la consulta. En la actualidad, el modelo ofrece el rendimiento más avanzado tanto en inglés como en chino y está diseñado para integrarse directamente en los procesos RAG existentes.

Detalles del modelo

• HuggingFace: zilliz/semantic-highlight-bilingual-v1

• Licencia: MIT (para uso comercial)

• Arquitectura: Modelo de sólo codificación de 0,6B basado en BGE-M3 Reranker v2

• Ventana de contexto: 8192 tokens

• Idiomas admitidos: Inglés y chino

Semantic Highlighting proporciona las señales de relevancia necesarias para seleccionar sólo las partes útiles de documentos largos recuperados. En la práctica, este modelo permite:

• Mejorar la interpretabilidad, mostrando qué partes de un documento son realmente importantes.

• una reducción del 70-80% en el coste de los tokens al enviar al LLM sólo las frases resaltadas

• Mejor calidad de respuesta, ya que el modelo ve menos contexto irrelevante.

• Una depuración más sencilla, ya que los ingenieros pueden inspeccionar directamente las coincidencias a nivel de frase.

Resultados de la evaluación: Alcanzar el rendimiento SOTA

Hemos evaluado nuestro modelo de Semantic Highlighting en varios conjuntos de datos en inglés y chino, tanto dentro como fuera del dominio.

Los conjuntos de referencia son los siguientes

• Inglés multi-span QA: multispanqa

• Wikipedia en inglés fuera del dominio: wikitext2

• Control de calidad multi panoramaen chino: multispanqa_zh

• Wikipedia enchino fuera del dominio: wikitext2_zh

Los modelos evaluados incluyen:

• Serie Open Provence

• Serie Provence/XProvence de Naver

• Resaltador semántico de OpenSearch

• Nuestro modelo bilingüe entrenado: zilliz/semantic-highlight-bilingual-v1

En los cuatro conjuntos de datos, nuestro modelo ocupa el primer puesto. Y lo que es más importante, es el único modelo que obtiene buenos resultados tanto en inglés como en chino. Los modelos de la competencia se centran exclusivamente en el inglés o muestran claros descensos de rendimiento con el texto chino.

Cómo creamos este modelo de resaltado semántico

Entrenar un modelo para esta tarea no es lo más difícil; entrenar un buen modelo que resuelva los problemas anteriores y ofrezca un rendimiento cercano al SOTA es lo realmente complicado. Nuestro enfoque se centró en dos aspectos:

• Arquitectura del modelo: utilizar un diseño de sólo codificador para una inferencia rápida.

• Datos de entrenamiento: generar etiquetas de relevancia de alta calidad utilizando LLM con capacidad de razonamiento y escalar la generación de datos con marcos de inferencia locales.

Arquitectura del modelo

Construimos el modelo como una red ligera de sólo codificador que trata la poda de contexto como una tarea de puntuación de relevancia a nivel de token. Este diseño se inspira en Provence, un enfoque de poda de contexto presentado por Naver en el ICLR 2025, que replantea la poda de "elegir el fragmento correcto" a "puntuar cada token". Este planteamiento encaja a la perfección con el resaltado semántico, en el que las señales precisas son esenciales.

Los modelos basados únicamente en codificadores no son la arquitectura más novedosa, pero siguen siendo extremadamente prácticos en este caso: son rápidos, fáciles de escalar y pueden producir puntuaciones de relevancia para todas las posiciones de los tokens en paralelo. Para un sistema RAG de producción, esta ventaja de velocidad es mucho más importante que el uso de un modelo decodificador más grande.

Una vez calculadas las puntuaciones de relevancia a nivel de token, las agregamos a las puntuaciones a nivel de frase. Este paso convierte las señales ruidosas de los tokens en una métrica de relevancia estable e interpretable. Las frases por encima de un umbral configurable se resaltan; todo lo demás se filtra. Se obtiene así un mecanismo sencillo y fiable para seleccionar las frases que realmente son importantes para la consulta.

Proceso de inferencia

En tiempo de ejecución, nuestro modelo de resaltado semántico sigue un proceso sencillo:

1. Entrada: el proceso comienza con una consulta del usuario. Los documentos recuperados se tratan como contexto candidato para la evaluación de la relevancia.

2. Procesamiento del modelo: la consulta y el contexto se concatenan en una única secuencia: [BOS] + Consulta + Contexto

3. Puntuación de tokens: a cada token del contexto se le asigna una puntuación de relevancia entre 0 y 1, que refleja su grado de relación con la consulta.

4. Agregación de frases: las puntuaciones de los tokens se agregan a nivel de frase, normalmente promediando, para obtener una puntuación de relevancia para cada frase.

5. Filtrado por umbral: las frases con puntuaciones superiores a un umbral configurable se resaltan y se conservan, mientras que las frases con puntuaciones bajas se filtran antes de pasar al LLM posterior.

Modelo base: BGE-M3 Reranker v2

Hemos seleccionado BGE-M3 Reranker v2 como modelo base por varias razones:

1. Emplea una arquitectura de codificador adecuada para la puntuación de tokens y frases.

2. Admite varios idiomas con optimización para inglés y chino.

3. Proporciona una ventana de contexto de 8192 tokens adecuada para documentos RAG más largos.

4. Mantiene parámetros de 0,6B, lo suficientemente potentes sin ser pesados desde el punto de vista computacional.

5. Garantiza un conocimiento del mundo suficiente en el modelo base.

6. Se ha entrenado para la reordenación, lo que coincide con las tareas de juicio de relevancia.

Datos de entrenamiento: Anotación LLM con razonamiento

Una vez finalizada la arquitectura del modelo, el siguiente reto era construir un conjunto de datos que realmente entrenara un modelo fiable. Empezamos observando cómo lo hace Open Provence. Su método utiliza conjuntos de datos públicos de control de calidad y un pequeño LLM para etiquetar las frases relevantes. Se adapta bien y es fácil de automatizar, lo que lo convirtió en un buen punto de partida para nosotros.

Pero pronto nos encontramos con el mismo problema que ellos describen: si se pide a un LLM que emita directamente etiquetas a nivel de frase, los resultados no siempre son estables. Algunas etiquetas son correctas, otras son cuestionables, y es difícil limpiar las cosas después. La anotación totalmente manual tampoco era una opción: necesitábamos muchos más datos de los que podíamos etiquetar a mano.

Para mejorar la estabilidad sin sacrificar la escalabilidad, introdujimos un cambio: el LLM debe proporcionar un breve fragmento de razonamiento por cada etiqueta que emita. Cada ejemplo de entrenamiento incluye la consulta, el documento, las frases y una breve explicación de por qué una frase es relevante o irrelevante. Este pequeño ajuste hizo que las anotaciones fueran mucho más coherentes y nos proporcionó algo concreto a lo que remitirnos al validar o depurar el conjunto de datos.

Incluir el razonamiento resultó ser sorprendentemente valioso:

• Mayor calidad de las anotaciones: Escribir el razonamiento funciona como autocomprobación, lo que reduce las etiquetas aleatorias o incoherentes.

• Mejor observabilidad: Podemos ver por qué se ha seleccionado una frase en lugar de tratar la etiqueta como una caja negra.

• Depuración más fácil: Cuando algo parece estar mal, el razonamiento facilita la detección de si el problema es la indicación, el dominio o la lógica de anotación.

• Datos reutilizables: Aunque en el futuro cambiemos a otro modelo de etiquetado, las trazas de razonamiento siguen siendo útiles para reetiquetar o auditar.

El flujo de trabajo de anotación tiene este aspecto:

Qwen3 8B para la anotación

Para la anotación, elegimos Qwen3 8B porque admite de forma nativa un "modo de pensamiento" a través de las salidas, lo que facilita mucho la extracción de trazas de razonamiento coherentes. Los modelos más pequeños no nos proporcionaban etiquetas estables, y los más grandes eran más lentos e innecesariamente caros para este tipo de proceso. Qwen3 8B consiguió el equilibrio perfecto entre calidad, velocidad y coste.

Ejecutamos todas las anotaciones utilizando un servicio vLLM local en lugar de las API de la nube. Esto nos proporcionó un alto rendimiento, un rendimiento predecible y un coste mucho menor: básicamente, intercambiamos tiempo de GPU por tarifas de token de API, que es la mejor opción cuando se generan millones de muestras.

Escala del conjunto de datos

En total, creamos más de 5 millones de muestras de entrenamiento bilingües, divididas a partes iguales entre inglés y chino.

• Fuentes en inglés: MS MARCO, Natural Questions, GooAQ

• Fuentes en chino: DuReader, Wikipedia en chino, mmarco_chinese

Parte del conjunto de datos procede de la reanotación de datos existentes utilizados por proyectos como Open Provence. El resto se generó a partir de corpus sin procesar, creando primero pares de consulta-contexto y etiquetándolos después con nuestro sistema de razonamiento.

Todos los datos de formación anotados están también disponibles en HuggingFace para el desarrollo de la comunidad y como referencia de formación: Conjuntos de datos de Zilliz

Método de entrenamiento

Una vez que la arquitectura del modelo y el conjunto de datos estuvieron listos, entrenamos el modelo en GPUs 8× A100 durante tres épocas, lo que nos llevó aproximadamente 9 horas de principio a fin.

Nota: el entrenamiento sólo se centró en el cabezal de poda, responsable de la tarea de resaltado semántico. No entrenamos el cabezal de reordenación, ya que al centrarnos únicamente en el objetivo de poda obtuvimos mejores resultados en la puntuación de relevancia a nivel de frase.

Estudio de casos reales

Las pruebas comparativas sólo cuentan una parte de la historia, por lo que he aquí un ejemplo real que muestra cómo se comporta el modelo en un caso límite común: cuando el texto recuperado contiene tanto la respuesta correcta como un distractor muy tentador.

Consulta: ¿Quién escribió "La muerte de un ciervo sagrado"?

Contexto (5 frases):

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.

Respuesta correcta: Frase 1 (indica explícitamente "guión de Lanthimos y Efthymis Filippou").

Este ejemplo tiene una trampa: la frase 3 menciona que "Eurípides" escribió la obra original. Pero la pregunta se refiere a "quién escribió la película La matanza de un ciervo sagrado", y la respuesta debería ser los guionistas de la película, no el dramaturgo griego de hace miles de años.

Resultados del modelo

Modelo	¿Encuentra la respuesta correcta?	Predicción
Nuestro modelo	✓	Frases seleccionadas 1 (correcta) y 3
XProvence v1	✗	Sólo seleccionó la frase 3, falló la respuesta correcta
XProvence v2	✗	Sólo seleccionó la frase 3, falló la respuesta correcta

Comparación de puntuaciones de frases clave:

Frase	Nuestro modelo	XProvence v1	XProvence v2
Frase 1 (guión de película, respuesta correcta)	0.915	0.133	0.081
Frase 3 (obra de teatro original, distractor)	0.719	0.947	0.802

Modelos XProvence:

• Se sienten muy atraídos por "Eurípides" y "obra de teatro", y dan a la frase 3 puntuaciones casi perfectas (0,947 y 0,802).

• Ignora por completo la respuesta real (frase 1), con puntuaciones extremadamente bajas (0,133 y 0,081).

• Incluso reduciendo el umbral de 0,5 a 0,2, sigue sin encontrar la respuesta correcta.

Nuestro modelo:

• Atribuye correctamente a la frase 1 la puntuación más alta (0,915)

• Sigue asignando a la frase 3 cierta relevancia (0,719) porque está relacionada con el fondo

• Separa claramente las dos con un margen de ~0,2

Este ejemplo muestra el punto fuerte del modelo: comprender la intención de la consulta en lugar de limitarse a coincidir con palabras clave superficiales. En este contexto, "Who wrote The Killing of a Sacred Deer" se refiere a la película, no a la antigua obra griega. Nuestro modelo lo capta, mientras que otros se distraen con fuertes indicios léxicos.

Pruébelo y díganos qué le parece

Nuestro modelo zilliz/semantic-highlight-bilingual-v1 ya es de código abierto bajo licencia MIT y está listo para su uso. Puede incorporarlo a su proceso RAG, adaptarlo a su propio dominio o crear nuevas herramientas a partir de él. También agradecemos las aportaciones y comentarios de la comunidad.

• Descargar de HuggingFace: zilliz/semantic-highlight-bilingual-v1

• Todos los datos de entrenamiento anotados: https://huggingface.co/zilliz/datasets

Resaltado semántico disponible en Milvus y Zilliz Cloud

El resaltado semántico también está integrado directamente en Milvus y Zilliz Cloud (el Milvus totalmente gestionado), lo que ofrece a los usuarios una visión clara de por qué se ha recuperado cada documento. En lugar de escanear trozos enteros, el usuario ve inmediatamente las frases específicas que se relacionan con su consulta, incluso cuando la redacción no coincide exactamente. Esto hace que la recuperación sea más fácil de entender y mucho más rápida de depurar. Para las canalizaciones RAG, también aclara en qué se espera que se centre el LLM posterior, lo que ayuda con el diseño rápido y las comprobaciones de calidad.

Pruebe gratis Semantic Highlighting en una nube Zilliz totalmente gestionada

Nos encantaría saber cómo le funciona: informes de errores, ideas de mejora o cualquier cosa que descubra al integrarlo en su flujo de trabajo.

Si quieres hablar de cualquier cosa con más detalle, no dudes en unirte a nuestro canal de Discord o reservar una sesión de 20 minutos de Milvus Office Hours. Siempre estamos encantados de charlar con otros constructores e intercambiar notas.

Agradecimientos

Este trabajo se basa en un montón de grandes ideas y contribuciones de código abierto, y queremos destacar los proyectos que hicieron posible este modelo.

• Provence introdujo un marco limpio y práctico para la poda de contexto utilizando modelos de codificador ligeros.

• Open Provence proporcionó una base de código sólida y bien diseñada -conductos de entrenamiento, procesamiento de datos y cabezales de modelos- bajo una licencia permisiva. Nos proporcionó un sólido punto de partida para la experimentación.

Sobre esa base, añadimos varias contribuciones propias:

• Uso del razonamiento LLM para generar etiquetas de relevancia de mayor calidad.

• Creación de casi 5 millones de muestras de entrenamiento bilingües alineadas con cargas de trabajo RAG reales.

• Elección de un modelo base más adecuado para la puntuación de relevancia en contextos largos(BGE-M3 Reranker v2).

• Entrenar sólo el cabezal de poda para especializar el modelo de resaltado semántico.

Agradecemos a los equipos de Provence y Open Provence la publicación abierta de sus trabajos. Sus contribuciones han acelerado considerablemente nuestro desarrollo y han hecho posible este proyecto.