Glance: un modelo de 9B selecciona por sí solo los párrafos para RAG y supera a un reranker

Un pipeline RAG convencional mantiene dos modelos en memoria. Primero, un reranker ordena los párrafos que devuelve el buscador; después, un generador lee los mejores y escribe la respuesta. Los investigadores del proyecto airun-ai proponen Glance: el propio generador puntúa los párrafos y no hace falta un reranker aparte. A un modelo congelado de 9000 millones de parámetros le añadieron un adaptador LoRA (un pequeño conjunto de pesos ajustados) y un «cabezal puntero» de 256 dimensiones. Cada una de estas capas adicionales de «habilidad» ocupa aproximadamente 0,1 GiB. De momento los resultados son preliminares: se probaron dos datasets de búsqueda, un dataset de preguntas y respuestas y una sola familia de modelos.

Una pasada en lugar de veinte

Un cross-encoder clásico (por ejemplo, bge-reranker-v2-m3) codifica cada par «consulta — párrafo» por separado. Con 20 candidatos, son 20 pasadas. Glance funciona de otra manera.

• El modelo lee una sola vez todos los candidatos y guarda una caché interna (prefill).
• De esa caché parten sondas cortas, de unos 30 tokens cada una: «¿Contiene el párrafo N información que responda a la consulta?»
• Las sondas no se ven entre sí, pero cada una ve todos los párrafos y puede compararlos.
• El cabezal puntero convierte el estado del modelo en la sonda en una puntuación de relevancia. No se genera texto.

También existe la variante Glance-Activated. En ella, el adaptador se activa solo en los tokens de las sondas, los párrafos se codifican con los pesos base y la respuesta continúa desde la caché original. En el modo principal, los párrafos seleccionados (unos 1,5 mil tokens) se vuelven a leer con el adaptador desactivado.

El modelo base, MiMo-V2.6-Distill-Qwen-9B de Xiaomi, es híbrido: alterna capas de atención lineal Gated DeltaNet y de atención convencional en proporción 3:1. Las capas lineales tienen un único estado secuencial, por lo que las cachés de párrafos individuales no se pueden unir en un orden arbitrario. Los autores optaron por ramificar copiando desde el final del contexto común, y este método es exacto.

Qué muestran las mediciones

La evaluación usa nDCG@10: cuanto más arriba, entre los diez primeros, están los documentos relevantes, más se acerca el valor a 1. Los rerankers ordenaron el top 20 de BM25 (búsqueda textual clásica).

• Sin entrenamiento con datos de búsqueda, el adaptador logró en SciFact (afirmaciones científicas) 0,715, frente a 0,729 de veinte llamadas independientes al mismo modelo. Además, fue 3,6 veces más rápido. El cross-encoder obtiene en SciFact 0,721.
• En NFCorpus (textos médicos), ese mismo modo dio 0,341 frente a 0,326 del cross-encoder. Los autores suponen que ayuda la comparación de los párrafos entre sí.
• Tras 39 minutos de entrenamiento en MS MARCO (4000 consultas, una GPU B200, pico de 21 GiB), el resultado subió a 0,741 en SciFact y 0,345 en NFCorpus. La ventaja sobre el cross-encoder fue de 0,020 y 0,019. No se comprobó la significancia estadística en estos datasets, y los autores consideran orientativa cualquier diferencia inferior a 0,02.

En HotpotQA (preguntas cuya respuesta exige reunir hechos de dos párrafos) se tomaron 300 preguntas con 10 párrafos cada una. El cross-encoder encontró con más frecuencia los párrafos necesarios: el recall en el top 2 fue de 0,863 frente a 0,762. Sin embargo, las respuestas basadas en la selección de Glance resultaron mejores: F1 de 0,718 frente a 0,683 con el adaptador sin entrenar, aunque esa diferencia no es estadísticamente significativa.

En el resumen del trabajo se declara para la versión ajustada una mejora de +0,045 F1. Si el adaptador se deja activado también durante la respuesta, el F1 sube a 0,757, que queda 0,032 por debajo del techo con los dos párrafos de referencia. Las respuestas se acortan (2,5 palabras frente a 3,1), lo que encaja mejor con el formato de HotpotQA.

Dónde choca el método con su techo

La principal ventaja aparece con listas largas de candidatos. El adaptador ajustado sigue mejorando hasta 200 candidatos (43,4 mil tokens): su nDCG@10 es de 0,717 frente a 0,659 del cross-encoder en las mismas 100 consultas de SciFact. Con 100 candidatos la diferencia es de 0,060 y el tiempo es de 1,05 s por consulta. El adaptador sin entrenar se degrada con tamaños grandes, y con 65 mil tokens la calidad cae hasta 0,505.

El precio es este:

• La memoria crece más deprisa que la longitud del contexto, de 15 a 56 GiB, porque cada sonda copia la caché de atención.
• 200 candidatos no caben en una sola llamada, por lo que se procesan por lotes, y eso lleva 15,8 s por consulta.
• Agrupar varias consultas en una sola llamada no acelera el trabajo: el rendimiento cae de 2,87 a 1,57 consultas por segundo.
• El cross-encoder sigue siendo mucho más rápido: 31–60 ms por consulta frente a unos 410–420 ms de Glance entrenado en B200.

Los autores proponen una caché de bloques compartida y sin copias, que haría lineal el consumo de memoria y permitiría pasar a contextos de en torno a 128 mil tokens.

A quién le puede servir

La principal ventaja de Glance está en la memoria. Si el servidor ya tiene un modelo grande para generar respuestas, no hace falta mantener un segundo reranker: basta con cambiar de adaptador bajo demanda. Las salidas coinciden con las que produce cada modelo cargado por separado. En sistemas donde importa más una latencia de decenas de milisegundos, un cross-encoder especializado sigue siendo la opción más rentable. En cambio, si hay que ordenar cientos de candidatos o elegir el contexto que el generador realmente utiliza, merece la pena probar este enfoque. Los adaptadores y el código están en Hugging Face, en el repositorio airun-ai/GlanceRAG-MiMo-9B-Reranker.