Distractores en RAG: por qué subir k compra competidores, no respuestas

Imagina un retriever que devuelve diez chunks para una pregunta. Exactamente uno contiene la respuesta. Piensa un momento en qué son los otros nueve. Su naturaleza la dicta el propio ranking: de todo el corpus, son los pasajes más cercanos a la pregunta que aun así no la responden.

Aquí no hay nada roto. El retriever hizo exactamente lo que se le pidió. Esos nueve chunks no son ruido que se coló, son su producto.

Las cifras de abajo proceden de mediciones publicadas por otras personas, y cada una lleva su fuente. El argumento que las une es una tesis sobre RAG en producción: subir k casi nunca compra respuestas. Compra competidores para la respuesta, y esos son los tokens más caros que pueden entrar en una ventana de contexto.

Un nombre para lo que se entrega

El informe Context Rot de Chroma, publicado el 14 de julio de 2025, hace una distinción que gran parte de lo que se escribe sobre recuperación ignora. El contenido irrelevante no tiene nada que ver con la pregunta. Un distractor está relacionado con el tema, pero no la responde.

Los dos se comportan de forma muy distinta. En dieciocho modelos, un solo distractor ya bajaba la precisión frente a una línea base con solo la aguja. Con cuatro distractores el daño se acumulaba, y el efecto crecía a medida que las entradas se alargaban. En una combinación de pajar y aguja, dos de los cuatro distractores escritos a mano aparecían en respuestas alucinadas mucho más a menudo que los otros dos. Las familias de modelos también se separaron: los modelos Claude tendían a abstenerse ante la ambigüedad, mientras que los GPT tendían a responder con seguridad y equivocarse.

Ahora compara esa definición con una lista ordenada de diez resultados. Las posiciones dos a diez encajan exactamente en ella, y están ordenadas de forma que las más convincentes quedan más arriba.

De ahí se deduce algo: unos embeddings mejores lo empeoran. Todo el propósito de un retriever mejorado es acercar los pasajes a la pregunta. Para la posición uno, ese es el objetivo. Para las otras nueve, significa que cada casi-acierto es más afilado que cualquier cosa que habría sacado el modelo del año pasado. El gasto se va en la calidad de los distractores y se etiqueta como recall.

El arreglo habitual repite el error una capa más arriba. Un reranker cross-encoder juzga la relevancia con más cuidado que la primera pasada, pero lo que puntúa sigue siendo relevancia, y un pasaje puede estar de lleno en el tema sin contener respuesta alguna. Reordenar nueve casi-aciertos no los elimina. Solo lo hace otra pregunta: ¿el pasaje responde, en lugar de simplemente coincidir?

La mitad oculta del coste

Hay un segundo cargo que nunca aparece en la factura.

Con una ventana sin enfocar, una sola llamada tiene que hacer dos trabajos: encontrar el pasaje relevante y luego razonar sobre él. La recuperación se ha mudado en silencio al interior del modelo, donde no se puede registrar, ajustar ni ver cómo falla, y donde compite por la misma atención que el razonamiento por el que de verdad se pagó.

Chroma le puso precio a esa brecha. En sus ejecuciones de LongMemEval, cada pregunta entró dos veces. Una versión usaba la entrada completa, con una media de 113.000 tokens. La otra, una versión enfocada de 300 tokens de media, con solo el pasaje relevante. Todas las familias de modelos rindieron peor con la entrada completa. Los modelos Claude mostraron la mayor brecha, sobre todo porque se negaban a responder en cuanto la cosa se volvía ambigua.

Misma pregunta, mismo modelo, la respuesta presente en ambas ventanas. Lo único que cambió fue lo que rodeaba a la respuesta.

Una ventana más grande no lo arregla

Anthropic publicó en septiembre de 2025 un artículo sobre context engineering que explica la causa arquitectónica. En un transformer, cada token mira a todos los demás, lo que crea n² vínculos por pares para n tokens, y el control del modelo sobre esos vínculos se debilita a medida que n crece. Lo que queda es un presupuesto de atención limitado, así que el contexto extra rinde cada vez menos.

Ese deterioro es una pendiente y no un precipicio, y por eso mismo pasa desapercibido. Nada lanza un error. La precisión simplemente se va escapando.

Los datos de Chroma señalan dónde la pérdida es más pronunciada. Los dieciocho modelos rindieron mejor con texto barajado hasta no tener sentido que con texto en su orden natural. Otro patrón: cuanto menos se parecía la redacción de una pregunta a la del pasaje que la respondía, más rápido caía la precisión al alargarse las entradas, aunque esos mismos pares funcionaban bien con entradas cortas.

La lectura práctica es incómoda. Un corpus bien organizado no ayuda, y los usuarios más perjudicados por las ventanas largas son los que preguntan con su propio vocabulario y no con el de la documentación.

Cuatro tipos de tokens y cómo falla cada uno

Tipo	Ejemplos	Cómo falla
Estáticos	Prompt de sistema, archivos de reglas, definiciones de herramientas	Se envían en cada turno, así que el precio escala con el número de turnos. Diluyen.
Recuperados	Chunks obtenidos para cada consulta	Se facturan por cada recuperación. Traen casi-aciertos.
Acumulados	Historial del chat, salidas de herramientas	Crecen en una sola dirección. Fallan tarde, a menudo varios turnos después del envenenamiento.
Externalizados	Notas, archivos, resúmenes de subagentes	Baratos de mantener. Se quedan obsoletos sin avisar.

La documentación de las bases de datos vectoriales presenta la fila de los recuperados como un problema de recall y nunca calcula el coste de las otras tres. Los equipos ajustan la recuperación con intensidad mientras el preámbulo se sigue multiplicando sin que nadie lo vea.

Repetir con contexto enfocado

Un único experimento permite distinguir un defecto de contexto de un defecto del modelo, y no requiere infraestructura nueva.

Saca treinta casos fallidos de producción. Para cada uno, monta a mano el contexto más pequeño que contenga la respuesta y nada más. Luego lanza la misma pregunta contra ambas versiones. El camino normal es así:

chunks = index.query(question, k=10)   # one may answer, the rest merely resemble
prompt = SYSTEM + "\n\n".join(c.text for c in chunks) + question

Y el bucle de comparación, así:

for case in failing_cases:
    full = assemble_context(case.question)
    focused = case.gold_passage
    log(case.id, ask(full), ask(focused))  # the gap is your context tax

Compara las dos columnas. Si la versión enfocada acierta donde la completa falla, ninguna mejora de modelo va a ayudar.

Después, instrumenta la contabilidad. Registra los tokens de cada turno en cuatro cubos: estáticos, recuperados, resultados de herramientas e historial. Luego mira el reparto en el turno en que la calidad se desploma. Muy pocos equipos han visto alguna vez esa cifra para su propio agente, y lo que más suele sorprender es la parte estática.

Las cuentas de una sesión de soporte

Las cifras de Chroma son la referencia. A partir de aquí, son cálculos sencillos.

Piensa en un agente de soporte con un preámbulo de 6.000 tokens, una sesión mediana de doce turnos y recuperación top-8 de unos 700 tokens por chunk.

A lo largo de la sesión, el preámbulo supone 72.000 tokens facturados con información que nunca varía. La recuperación aporta 5.600 por turno, es decir, 67.200 en total. De ellos, siete de cada ocho chunks se eligieron por parecerse a la pregunta y no por responderla. La suma ronda los 59.000 tokens de distracción fabricada, repetidos en cada sesión y con cada usuario.

Compáralo con un prompt enfocado de unos 300 tokens, que puntuó mejor que la entrada de 113.000 tokens con exactamente las mismas preguntas. El gasto es solo la mitad del daño. Esos tokens también hunden la precisión.

Cambios para empezar

Trata cada token como un asiento que necesita licencia.

El contexto estático tiene que justificar su lugar cambiando el comportamiento en cada turno en el que está, y está en todos. Lo que rige una tarea de cada cincuenta va en una skill que se carga cuando se activa, no en el preámbulo siempre presente.

El contexto recuperado tiene que justificar su lugar siendo capaz de responder. Así que ordena según si un chunk contiene la respuesta, no por similitud, y sigue bajando k hasta que la repetición deje de mostrar mejoras. Un método barato es una segunda pasada que enseña cada candidato a un modelo pequeño con una sola pregunta de sí o no, si el pasaje contiene la respuesta, y descarta todos los no. Eso suele eliminar la mayor parte de lo recuperado.

Cada token se factura en cada turno y tira del mismo presupuesto de atención. Por eso preguntar si un documento es relevante es la prueba equivocada. Lo que importa es si compensa lo que desplaza.