Recuperación contextual para RAG: qué oculta la cifra del 67%, cuál es su costo y cuándo falla.

“Los ingresos de la empresa aumentaron un 3% en comparación con el trimestre anterior”. Una base de datos vectorial puede contener miles de oraciones como esa, y cada una de ellas es funcionalmente inútil hasta que se aclara a qué empresa y a qué trimestre se refiere.

El problema no radica en el modelo que escribe la respuesta final, sino en los fragmentos que ingresan al índice sin identidad. Cualquier pipeline RAG construido a partir de documentos, contratos, documentación técnica o código fuente queda vulnerable, ya que esos corpus repiten el mismo patrón lingüístico en decenas de lugares y no brindan al sistema de recuperación la posibilidad de distinguir esas repeticiones.

La solución es económica. Su precio se calcula en dólares por millón de tokens, y se necesita una sola oración generada, escrita una sola vez durante la creación del índice. En las pruebas de Anthropic, dicho prefijo redujo las búsquedas fallidas en hasta un 67%. Esa cifra publicitada oculta cierta estructura, y el caso de uso elegido para mostrarla ha generado desde entonces un contraejemplo. También existen cuatro configuraciones en las que es difícil justificar el gasto.

La idea principal en resumen

Cuando un índice divide los documentos en fragmentos de unos cientos de tokens, algunos fragmentos pierden su tema y su período de tiempo. Frases como “Los ingresos aumentaron un 3%” no mencionan ninguna empresa ni trimestre, y ningún modelo de embedding puede recuperar esa información, ya que no está presente en el texto.

La recuperación contextual resuelve el problema una sola vez, en el momento de la indexación. Se muestra al modelo de lenguaje todo el documento junto con un fragmento, y este escribe un breve prefijo descriptivo de cincuenta a cien tokens que indica de qué trata el fragmento, a quién se refiere y cuándo.

En muchos resúmenes se omite un segundo paso que, en realidad, es el más importante. El texto enriquecido se introduce en el índice vectorial y en el índice BM25, el clasificador léxico que existía antes que las representaciones vectoriales y que busca palabras exactas y no su significado. Por lo tanto, una sola intervención corrige ambas partes del proceso de búsqueda, con un costo único de indexación y no con un costo adicional en cada consulta.

En la evaluación de Anthropic, solo el prefijo de representación vectorial redujo en un 35% las recuperaciones fallidas. El conjunto completo, con BM25 y reclasificación, logró una reducción del 67%. El caché de prompts es lo que mantiene los costos bajos, ya que todo el documento se lee una sola vez y no desde cero para cada fragmento.

La técnica no es universal, y ahí es donde se vuelve interesante. Primero, el mecanismo y el propio prompt.

Un prefijo que le da identidad a un fragmento

La intuición precede a la mecánica. Un fragmento extraído de un documento es como una página arrancada de un álbum, sin encabezado, número de caso ni fecha. Leído de forma aislada, impediría saber de qué empresa proviene el aumento de ingresos o cuándo ocurrió. Un modelo de embedding se enfrenta a la misma situación vacía, solo que no tiene forma de señalarla.

El mecanismo restaura el encabezado faltante. En el momento de indexar, el modelo recibe dos entradas: el documento de origen completo y un fragmento de él, y tiene una única tarea: escribir un breve contexto que sitúe ese fragmento dentro del todo.

El prompt de Anthropic cabe en unas pocas líneas:

<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the
overall document for the purposes of improving search retrieval of the
chunk. Answer only with the succinct context and nothing else.

Al aplicarlo al fragmento de ejemplo, el resultado podría ser: “Este fragmento proviene de un documento presentado ante la SEC sobre el rendimiento de ACME Corp en el segundo trimestre de 2023; los ingresos del trimestre anterior fueron de 314 millones de dólares”. La oración original sobre el crecimiento del 3% aparece justo después. Aproximadamente cien tokens convierten un fragmento aislado en un registro con una clave.

El texto enriquecido se escribe luego en dos índices: uno es el índice de embeddings (Contextual Embeddings) y el otro es el índice de palabras clave (Contextual BM25). Al escribir el nombre completo de ACME dentro de cada fragmento, BM25 puede identificar a la empresa en cualquier página del informe, mientras que antes solo se la mencionaba en la portada.

Tampoco esta fue la primera idea que se probó. Anthropic informó sobre experimentos anteriores con resúmenes genéricos de documentos adjuntos a los fragmentos, los cuales arrojaron “mejoras muy limitadas”, así como con HyDE e indexación basada en resúmenes, que tampoco resultaron muy efectivos (Anthropic, septiembre de 2024). Lo que quedó fue el prefijo.

Lo que diferencia un resumen de un prefijo es su naturaleza mecánica. Un resumen es compartido por todos los fragmentos de un documento, por lo que no puede distinguir entre el fragmento A y el fragmento B dentro del mismo informe anual, mientras que cada prefijo de ubicación se escribe específicamente para su posición en el documento.

Los corpus compuestos por documentos legales, contratos, documentación técnica o bases de código, donde un mismo patrón lingüístico se repite en múltiples lugares, son precisamente donde hoy en día se pierden los fragmentos. Solo el prefijo de incrustación ya permite una reducción del 35% en los errores, y eso solo corresponde al primer nivel.

Una escalera dentro de un número

Con frecuencia, se cita el “67%” como el efecto de una sola técnica. La tabla publicada indica algo diferente, y resulta más adecuado considerarlo como un proceso escalonado que como un único salto.

Los resultados se miden como uno menos el recall@20: es la proporción de consultas cuyo fragmento correcto no se encontró entre los veinte primeros. Anthropic denomina a esto la tasa de fallos y la presenta para bases de código, obras de ficción, artículos de arXiv y publicaciones científicas.

Hay cuatro configuraciones que se construyen unas sobre otras:

• Base de referencia, con embeddings simples aplicados a fragmentos sin procesar: el 5,7% de las consultas falla.
• Solo con embeddings contextuales: el 3,7%, lo que representa una reducción del 35% atribuible únicamente al prefijo.
• Con embeddings contextuales BM25 adicionales: el 2,9%, lo que supone una reducción acumulada del 49%, siendo el índice de palabras clave el factor que aporta la mejora adicional.
• Con reclasificación añadida: el 1,9%, y de aquí proviene la cifra del 67% mencionada, gracias a la etapa final.

Un reclasificador es un segundo modelo que lee conjuntamente la consulta y un fragmento candidato. Es más lento que el primer proceso, pero mucho más preciso. En este caso redujo 150 candidatos a veinte. Las cuatro cifras descritas corresponden a la configuración de embedding más potente de la prueba, Gemini Text 004, y no representan un promedio de los modelos de embedding que probó Anthropic.

El desglose cambia la decisión, no solo la narrativa. Un equipo que ya utiliza búsquedas híbridas y reclasificación en producción debería esperar que la contextualización por sí sola genere un resultado cercano al 35 por ciento en lugar del 67 por ciento, ya que los otros dos niveles ya se pagan. Considerar ese número como un único efecto es un error común, y una buena parte de la reducción se debe a que los componentes estándar de recuperación realizan su función habitual.

Un hilo de Hacker News añade una advertencia importante: nadie publicó cómo rinde el método BM25 puro, sin ninguna contextualización, en esa misma prueba. Sin esa columna, no se puede determinar cuánto del aumento al 49% se debe al contexto en el índice léxico y cuánto a la búsqueda híbrida simple.

Una trampa al citar las cifras

Cualquiera que cite estos resultados también puede caer en una trampa de cálculo. La guía de Anthropic incluye un conjunto de datos más pequeño con nueve bases de código y 248 consultas, evaluadas con otra métrica: Pass@20 pasa del 90% en el escenario de referencia al 97% en el stack completo. Diferente corpus, diferente métrica, por lo que mezclar esas cifras con las anteriores es simplemente un error.

La reducción no es gratuita. Implica costos en el momento de indexar, pero un mecanismo hace que ese costo esté cerca de un dólar en lugar de mil.

¿Por qué un dólar y no mil?

Considere el enfoque ingenuo. Un documento de 8,000 tokens se divide en diez fragmentos. Sin ninguna optimización, cada llamada vuelve a leer todo el documento, por lo que el mismo texto se procesa diez veces para describir diez párrafos diferentes.

Ese perfil de costos fue lo que impidió que esta idea se llevara a cabo durante años. La gente la descartó como un método de fuerza bruta y la rechazó en los presupuestos, mucho antes de que se midiera algún beneficio en términos de calidad.

El caché de prompts modifica los cálculos en un punto clave. El documento se envía una sola vez con un prefijo fijo. La primera solicitud implica un escritura en el caché a un costo aproximadamente 1.25 veces el precio base, mientras que cada solicitud posterior sobre ese mismo documento implica una lectura del caché a un costo de aproximadamente una décima parte del precio base.

Suponiendo tamaños típicos de los fragmentos y documentos, la contextualización cuesta 1,02 dólares una sola vez por cada millón de tokens de texto de origen. Esta cifra se indica junto con los parámetros de entrada: fragmentos de 800 tokens y documentos de 8,000 tokens, cuyos costos rara vez se publican. Esto permite volver a calcular los costos con valores locales en lugar de confiar ciegamente en ellos.

En un ejemplo de libro de recetas que abarcaba 737 fragmentos, casi el 62% de los tokens de entrada provinieron del caché. El costo total disminuyó de aproximadamente 9,20 dólares a unos 2,85 dólares. Un modelo mejor no fue el responsable del ahorro de dos tercios; lo que sí lo fue fue leer el documento solo una vez.

El detalle de ordenación que lo decide todo

Un detalle práctico determina si todo esto se materializa. El caché funciona con coincidencias de prefijos, por lo que todos los fragmentos de un mismo documento deben procesarse uno tras otro para poder reutilizar una sola entrada de caché. El paralelismo entre documentos es aceptable, con un trabajador por documento, pero mezclar fragmentos de varios documentos en una sola cola no es viable. Un pipeline ingenuo típico distribuye los fragmentos en un pool de hilos compartido, lo que hace que el caché se utilice solo ocasionalmente y se pague la tarifa completa.

También cabe una advertencia respecto a la cifra presentada. $1.02 refleja los precios del modelo de 2024 y no es una constante. La próxima generación de ese modelo cuesta cuatro veces más por la misma entrada de datos, por lo que repetir esa cifra hoy sin volver a calcular las cotizaciones resulta en un precio obsoleto.

Desde el punto de vista económico, parece excelente para los documentos que se presentan ante la SEC, que es precisamente el tipo de documento utilizado como ejemplo principal. Sin embargo, alguien que probó ese mismo tipo de documento observó el efecto contrario.

Un ejemplo emblemático que falla en su propia prueba

Aquí comienza la parte que la mayoría de los resúmenes omiten.

La ilustración utilizó un fragmento de un documento presentado ante la SEC, pero la lista de dominios analizados excluye dichos documentos. Menciona bases de código, obras de ficción, arXiv y publicaciones científicas, por lo que los documentos financieros sirven como ejemplo narrativo y no como corpus sometido a pruebas.

Otros llenaron esa laguna y encontraron el resultado opuesto. Los ingenieros de Snowflake (Tarakad, Yu, Samdani, Merrick, marzo de 2025) utilizaron unos 23,000 documentos reales de tipo 10-K y 10-Q como corpus y evaluaron su sistema con aproximadamente 500 consultas escritas a mano.

Enriquecer cada fragmento con un resumen extenso, único y redactado por el modelo, algo que el equipo denominó recuperación contextual, redujo las puntuaciones en 5.8 puntos para un modelo y en 0.4 para el otro. El resultado fue una pérdida, además de un gasto computacional considerablemente mayor.

Cuando los metadatos económicos superan a un modelo caro

El hallazgo más interesante es lo que funcionó en el mismo experimento. Al incluir metadatos a nivel de documento, como el nombre de la empresa, la fecha de presentación y el tipo de formulario, la precisión de las respuestas pasó de alrededor del 50 % al 60 % a un rango del 72 % al 75 %, sin necesidad de utilizar ningún modelo de lenguaje.

Este contraste transmite la lección clave. El problema era real, ya que el fragmento de texto realmente no conocía a su empresa. Sin embargo, la solución más económica superó a la más costosa, porque el nombre de la empresa permanece constante durante todo el proceso de presentación y no se necesita ningún modelo para adjuntarlo.

Esta comparación no constituye una replicación exacta, y eso debe señalarse abiertamente. Snowflake utilizó su propio prompt, modelo de incrustación, tamaño de los fragmentos y método de evaluación, por lo que los resultados no pueden compararse directamente como si provinieran del mismo instrumento. Aun así, involucran el mismo tipo de documento, y por eso son relevantes.

Otros dos resultados atenúan el entusiasmo. Una prueba de referencia para 2026 basada en T²-RAGBench, independiente del estudio de Snowflake, evaluó la contextualización en documentos financieros que contenían tablas. Se observaron mejoras de 2.8 puntos porcentuales en el índice recall@5 con recuperación densa y 2.2 con recuperación híbrida (arXiv). Esta mejora es real y reproducible, pero está lejos de alcanzar el 67%.

Esa misma prueba de referencia, que abarca más de 23,000 consultas en 7,318 documentos, también reveló un hallazgo que debería preocupar a quienes trabajan con informes: la mayoría de los errores restantes se deben a incoherencias en la estructura de las tablas. Un prefijo de texto no sirve de ayuda en este caso, ya que solo permite identificar con precisión aquellos fragmentos que siguen siendo ilegibles.

El segundo punto se refiere al procesamiento computacional. ConTEB (2025) comparó el método de estilo Anthropic con un modelo de embedding entrenado específicamente para ello. El modelo entrenado obtuvo puntuaciones ligeramente más altas en promedio y procesó cada documento aproximadamente cien veces más rápido (arXiv). Las diferencias en calidad son pequeñas, ya que el enfoque basado en prefijos gana rotundamente en algunos conjuntos de datos, como un corpus de seguros, y pierde por poco en otros. Lo que realmente ofrece el modelo entrenado es un menor costo de procesamiento.

También existe un diseño rival. Late Chunking (Jina AI, septiembre de 2024) aborda el mismo problema en una capa inferior al incrustar todo el documento y dividirlo en partes solo después del transformador, sin recurrir a un modelo de lenguaje. Su debilidad estructural es que no se agrega nada al índice de palabras clave, lo que hace que se pierda la mitad de los beneficios que ofrece Contextual BM25.

En la mayoría de los corpus corporativos, esa asimetría, más que la brecha métrica, probablemente es lo que determina la elección. Se trata de una decisión subjetiva, y el punto de referencia ConTEB mencionado no lo evalúa directamente, ya que BM25 no está entre los componentes que analiza.

Una vez que el ejemplo ilustrativo resulta tener un contraejemplo, la pregunta relevante pasa a ser dónde falla la técnica para ser útil y cómo se puede verificar un corpus determinado en cinco minutos.

Cinco minutos de pruebas antes de realizar cualquier gasto

Comience con una prueba y no con una implementación. Tome diez fragmentos aleatorios del índice y lea cada uno por separado. Si es posible determinar de qué trata cada uno y de dónde proviene, esos fragmentos ya contienen contexto, y añadir un prefijo solo incrementaría los tokens sin aportar información adicional.

La prueba no requiere código y dura cinco minutos. También es la única evidencia que se refiere a los datos reales y no a los de otra persona.

Cuatro situaciones documentadas en las que la técnica no es útil:

• Un corpus de menos de doscientos mil tokens. El propio consejo de Anthropic para esa escala es incluir toda la base de conocimientos en el prompt y omitir por completo la recuperación de información. La contextualización está pensada para casos en que el corpus ya no cabe en la ventana de contexto.
• Fragmentos que ya son independientes. Las parejas de Preguntas Frecuentes, las tarjetas de productos y las entradas del diccionario ya expresan por sí mismos su tema, por lo que un prefijo simplemente lo repite.
• Un corpus que cambia con frecuencia. El costo se genera solo una vez si los documentos son estables. Los documentos revisados semanalmente se cobran nuevamente cada semana.
• Tablas e informes financieros. Si lo que falla es la estructura de la tabla y no falta el nombre de la empresa, el fragmento se describe con precisión pero sigue siendo ilegible.

El encuadre cabe en tres líneas. Un corpus pequeño y estable es adecuado para contextos largos con caché. Un corpus grande con fragmentos ambiguos es adecuado para la recuperación contextual. Las entradas cortas y autónomas son adecuadas para búsquedas híbridas simples, sin costo adicional.

El orden de adopción es importante, y es el punto que con mayor frecuencia genera decepciones. La contextualización multiplica el valor de la búsqueda híbrida, pero no la reemplaza. Un equipo que no cuente con BM25 y reclasificación debería incorporarlos primero; omitir ese orden significa adquirir el tercer nivel mientras aún falta el primero.

Calcule el costo antes de la implementación, no después. La fórmula está publicada, se conocen los tamaños de los fragmentos y los documentos, y lo único realmente desconocido es si el proceso realmente accede al caché.

Qué llevar a la revisión del diseño

Volver a la oración inicial. “Los ingresos crecieron un 3%” nunca estuvo mal. Carecía de sujeto. La solución no fue un modelo más inteligente ni una inserción mejor, sino solo un encabezado añadido una vez, en el momento de la indexación.

• Por más potente que sea el modelo de generación de respuestas, un fragmento sin contexto es inútil. La causa es la indexación, no la alucinación.
• Tres intervenciones juntas alcanzan el 67% mencionado, no una sola. El prefijo por sí solo ya representa cerca del treinta y cinco por ciento, y la búsqueda híbrida con reclasificación aporta el resto.
• El caché de prompts hizo que la técnica fuera asequible, no un modelo más potente, y el ahorro desaparece sin un procesamiento documento por documento.
• El tipo de documento utilizado en la ilustración tiene un contraejemplo documentado: en los registros de la SEC, los metadatos de documentos económicos superaron en rendimiento a una llamada a un modelo costoso por fragmento.
• Una verificación de cinco minutos de un índice real supera en importancia a cualquier titular. Lea los diez fragmentos por separado.

En la práctica, esto se resume en tres pasos en orden: realizar la prueba con los diez fragmentos, comprobar si el corpus coincide con uno de los cuatro casos negativos, y solo entonces calcular el costo de indexación con la fórmula publicada. Solo el tercer paso requiere un presupuesto, y los dos primeros determinan si vale la pena solicitar uno.

Hay una advertencia que no se puede evitar. Anthropic publicó el desglose de los resultados en un apéndice, en formato PDF estático y no como conjunto de datos en bruto, y los equipos independientes que intentaron reproducir las cifras señalan esto como un problema de reproducibilidad. También son escasas las evaluaciones directas en corpus de idiomas distintos al inglés. Mientras no se cierren ambas brechas, cada cifra aquí proviene de un entorno específico y no de una ley de la física, y lo que más falta hoy en día son mediciones de rendimiento en corpus de idiomas distintos al inglés.