Contexto Aumentado con Recuperación

Contexto largo vs recuperación: ¿Todavía necesitamos RAG?

Las ventanas de contexto han crecido de 1,024 tokens (GPT-2, 2019) a más de 1 millón de tokens (Gemini 1.5 Pro, 2024). Si un modelo puede ingerir una base de código completa o un libro entero de una sola vez, ¿para qué molestarse con un pipeline de recuperación en absoluto? ¿No podemos simplemente volcar todo en el contexto y dejar que el modelo lo resuelva?

El caso a favor del contexto largo solo es convincente en la superficie. El pipeline es más simple: sin fragmentación, sin embeddings, sin índice, sin errores de recuperación. El modelo ve todo, así que no puede perder un pasaje relevante porque un recuperador falló en traerlo. Y no hay pérdida de información por los límites de fragmentación — el modelo tiene el documento completo con todas las referencias cruzadas intactas.

Pero incluso 1 millón de tokens tiene límites. Un millón de tokens es aproximadamente 750,000 palabras — un libro largo, pero una fracción minúscula de una base de conocimiento corporativa (que puede contener millones de documentos), un archivo legal o todo internet. Más allá de la escala, hay tres problemas prácticos. Primero, el costo : procesar 1M de tokens a través de las capas de atención de un transformer es caro. Como cubrimos en el artículo 1, el costo de atención escala como $O(n^2)$, así que procesar 1M de tokens cuesta aproximadamente $1{,}000{,}000^2 = 10^{12}$ puntuaciones de atención por cabeza por capa. Segundo, la latencia : llenar una ventana de contexto de 1M de tokens toma de segundos a minutos, mientras que una búsqueda de recuperación toma milisegundos. Tercero, la calidad : as we saw with the "Lost in the Middle" phenomenon (article 1), models struggle to attend uniformly across very long contexts. Relevant information buried at position 500,000 may be effectively invisible.

La recuperación resuelve los tres. En lugar de procesar todo el corpus, recuperamos solo los 5-20 pasajes más relevantes (quizás 2,000-10,000 tokens en total) y los colocamos en el contexto. El modelo procesa un contexto pequeño y enfocado en lugar de uno masivo y sin foco. El costo cae por órdenes de magnitud, la latencia es mínima, y cada token que el modelo ve es probablemente relevante.

La respuesta práctica, confirmada empíricamente, es que se complementan mutuamente . (Xu et al., 2024) studied this directly in "Retrieval meets Long Context Large Language Models" and found that retrieval-augmented generation consistently improves performance even when the model has a long enough context window to fit all the documents. Long context handles memoria de trabajo — la conversación hasta ahora, el documento que estás analizando, el código que estás editando. La recuperación maneja la biblioteca — el vasto corpus de conocimiento que podrías necesitar consultar pero nunca cargarías completamente en la memoria de trabajo.

Atención aumentada con recuperación

El RAG tradicional antepone documentos recuperados al prompt: el recuperador encuentra fragmentos relevantes, los concatenamos en el contexto, y el modelo genera una respuesta condicionada en ese prompt aumentado. Esto funciona, pero consume tokens de la ventana de contexto. Si recuperamos 10 pasajes de 500 tokens cada uno, son 5,000 tokens de presupuesto de contexto gastados antes de que aparezca la pregunta del usuario. ¿Qué pasaría si pudiéramos integrar la recuperación directamente en el mecanismo de atención mismo?

Esa es la idea detrás de RETRO (Retrieval-Enhanced Transformer), introducido por (Borgeaud et al., 2022) . En lugar de anteponer texto recuperado a la entrada, RETRO recupera fragmentos relevantes de una base de datos externa y los inyecta en el modelo mediante capas de atención cruzada intercaladas cada pocos bloques de transformer. Los fragmentos recuperados nunca entran en la ventana de contexto principal — se atienden a través de un camino separado.

Así es como funciona la arquitectura. La secuencia de entrada se divide en fragmentos de $m$ tokens (típicamente $m = 64$). Para cada fragmento, un codificador BERT congelado calcula una representación, y una búsqueda de $k$-vecinos más cercanos recupera los $k$ fragmentos más similares de una base de datos precalculada. Cada fragmento recuperado es codificado por una pila de codificadores (the "retrieval encoder"), producing key-value pairs. Then, every few layers in the main transformer, a atención cruzada por fragmentos (CCA) permite que cada fragmento de entrada atienda a sus vecinos recuperados correspondientes:

where $H \in \mathbb{R}^{m imes d}$ is the hidden state for one input chunk (the $m$ tokens in that chunk) and $E \in \mathbb{R}^{(k \cdot r) imes d}$ contains the encoded representations of all $k$ retrieved neighbours (each of length $r$ tokens). The queries come from the input chunk; the keys and values come from the retrieved chunks. This means each input token attends only to its chunk's retrieved neighbours, not to the entire database.

Let's check the dimensions. $H \, W_Q$ has shape $m imes d_k$, and $(E \, W_K)^T$ has shape $d_k imes (k \cdot r)$. Their product is $m imes (k \cdot r)$ — each of the $m$ input tokens produces a score against each of the $k \cdot r$ retrieved tokens. With $m = 64$, $k = 2$ neighbours, and $r = 64$ tokens per neighbour, the attention matrix is $64 imes 128 = 8{,}192$ entries. Compare that to standard self-attention over a 1M-token sequence: $10^{12}$ entries. The cross-attention cost is negligible.

La idea clave es la escala. La base de datos de RETRO en el artículo original contenía 1.75 billones de tokens (el dataset MassiveText de DeepMind). Eso es aproximadamente 10,000 veces más grande que la ventana de contexto más grande disponible hoy. El modelo accede a este conocimiento a un costo proporcional al número de fragmentos recuperados, no al tamaño de la base de datos. Un modelo RETRO de 7.5B parámetros igualó el rendimiento de un modelo 25x más grande (175B parámetros) en ciertos benchmarks intensivos en conocimiento — efectivamente intercambió parámetros por recuperación.

¿Cómo difiere esto de Memorizing Transformers (artículo 4)? Memorizing Transformers recupera del propio contexto pasado del modelo — tokens anteriores de la misma secuencia que han salido de la ventana de atención local. RETRO recupera de una base de datos externa de documentos pre-indexados que pueden no tener nada que ver con la entrada actual. Memorizing Transformers extiende la memoria del modelo sobre lo que ya ha visto; RETRO le da al modelo acceso a conocimiento que nunca ha visto en el contexto actual.

Cuándo recuperar vs cuándo extender el contexto

Dado que el contexto largo y la recuperación son complementarios, ¿cuándo deberías usar cada uno? La decisión depende de la naturaleza del conocimiento, la tarea y las restricciones de costo. Aquí hay un marco práctico.

• Base de conocimiento estática (documentos de empresa, manuales, archivos legales) — usa recuperación. El corpus es demasiado grande para cualquier ventana de contexto, y el subconjunto relevante cambia por consulta. Un pipeline de dense retrieval con reranking extrae los 5-20 pasajes correctos por consulta de millones de documentos.
• Conversación de múltiples turnos — usa contexto largo. El historial de conversación ES el contexto. Quieres que el modelo recuerde todo lo dicho hasta ahora, y el historial típicamente está bien dentro de los límites de la ventana de contexto (la mayoría de las conversaciones tienen menos de 10K tokens).
• Análisis de documentos (leer un PDF de 100 páginas y responder preguntas) — usa contexto largo si cabe, recuperación si no. Un PDF de 100 páginas es aproximadamente 40,000 tokens, bien dentro de una ventana de 128K. Un archivo regulatorio de 10,000 páginas no lo es.
• Información en tiempo real — usa recuperación. Los pesos del modelo están congelados en el momento del entrenamiento y su ventana de contexto comienza vacía en cada sesión. Las noticias de hoy, los precios de acciones en vivo o los datos climáticos actuales deben recuperarse de fuentes externas.

The enfoque híbrido combina ambos: recuperar los fragmentos más relevantes de un corpus grande, colocarlos en la ventana de contexto largo junto con la consulta del usuario y el historial de conversación, y dejar que el modelo atienda a todo. Esto te da la precisión de la recuperación (encontrar la aguja correcta) con la comprensión del contexto largo (entender la aguja en contexto). La mayoría de los sistemas de producción hoy usan exactamente este patrón.

La diferencia de costo es sustancial. Comparemos procesar 100,000 tokens de contexto sin procesar (meter un corpus en la ventana) versus recuperar 5 pasajes relevantes de 500 tokens cada uno (2,500 tokens en total).

import json, js

# Compare cost of long-context vs retrieval-augmented approach
# Using d_k=128, H=32 heads as representative config

d_k = 128
H = 32

scenarios = [
    ("Long context (100K tokens)", 100_000),
    ("Retrieved context (5 x 500 tokens)", 2_500),
]

rows = []
for label, n in scenarios:
    # Attention scores per head per layer
    attn_scores = n * n
    # Attention FLOPs per layer (all heads): 2 * H * n^2 * d_k
    attn_flops = 2 * H * (n ** 2) * d_k

    if attn_scores >= 1e12:
        scores_str = f"{attn_scores / 1e12:.1f} T"
    elif attn_scores >= 1e9:
        scores_str = f"{attn_scores / 1e9:.1f} B"
    elif attn_scores >= 1e6:
        scores_str = f"{attn_scores / 1e6:.1f} M"
    else:
        scores_str = f"{attn_scores / 1e3:.1f} K"

    if attn_flops >= 1e15:
        flops_str = f"{attn_flops / 1e15:.1f} PetaFLOPs"
    elif attn_flops >= 1e12:
        flops_str = f"{attn_flops / 1e12:.1f} TeraFLOPs"
    elif attn_flops >= 1e9:
        flops_str = f"{attn_flops / 1e9:.1f} GigaFLOPs"
    else:
        flops_str = f"{attn_flops / 1e6:.1f} MegaFLOPs"

    rows.append([label, f"{n:,}", scores_str, flops_str])

# Compute the ratio
ratio = (100_000 ** 2) / (2_500 ** 2)

js.window.py_table_data = json.dumps({
    "headers": ["Approach", "Tokens (n)", "Attn Scores (n\u00b2)", "Attn FLOPs/layer"],
    "rows": rows
})

print(f"Attention cost ratio: {ratio:,.0f}x")
print(f"The long-context approach computes {ratio:,.0f} times more attention scores")
print(f"per head per layer than the retrieval approach.")
print()
print("The retrieval approach also adds a search step (~10ms for ANN lookup),")
print("but this is negligible compared to the attention savings.")

Los números son contundentes: 10 mil millones de puntuaciones de atención versus 6.25 millones — una reducción de 1,600x . In practice, the savings are even larger because the retrieval approach also reduces KV cache memory (linear in $n$: $100{,}000 imes c$ vs $2{,}500 imes c$, a 40x reduction), prefill latency, and API costs (most providers charge per token). The trade-off is that retrieval might miss relevant information that a full-context approach would have seen — but as we've discussed, full-context models have their own recall problems ("Lost in the Middle"), so this trade-off is less severe than it first appears.

Auto-recuperación: Modelos que deciden cuándo buscar

El RAG estándar siempre recupera. Cada consulta, independientemente de la dificultad, activa una búsqueda en la base de datos. Pero a veces el modelo ya sabe la respuesta — "¿Cuál es la capital de Francia?" no necesita un paso de recuperación. La recuperación innecesaria añade latencia (el tiempo de búsqueda más codificación), puede introducir ruido (pasajes irrelevantes que confunden al modelo) y desperdicia cómputo. ¿Qué pasaría si el modelo mismo pudiera decidir cuándo se necesita recuperación?

(Asai et al., 2024) introduced Self-RAG (Self-Reflective Retrieval-Augmented Generation), un marco donde el modelo aprende a generar tokens de reflexión especiales que controlan el proceso de recuperación y generación. El modelo no solo genera texto — genera metadatos sobre si necesita ayuda.

Self-RAG usa cuatro tipos de tokens de reflexión:

• [Retrieve]: ¿debería el modelo recuperar conocimiento externo para este segmento? Valores: sí, no, o continuar (seguir generando sin recuperación).
• [IsRel]: ¿es el pasaje recuperado relevante para la consulta? Valores: relevante o irrelevante. Si es irrelevante, el pasaje se descarta.
• [IsSup]: ¿está la respuesta generada respaldada por el pasaje recuperado? Valores: totalmente respaldada, parcialmente respaldada o no respaldada.
• [IsUse]: ¿es la respuesta general útil? Una verificación final de calidad sobre la generación completa.

El flujo funciona así. El modelo comienza a generar una respuesta. En cada límite de segmento, emite un token [Retrieve]. Si el valor es "sí", el sistema pausa la generación, recupera pasajes relevantes, y el modelo evalúa cada uno con [IsRel]. Para pasajes relevantes, el modelo continúa generando condicionado en ellos, luego se autoevalúa con [IsSup] para verificar si su salida está realmente fundamentada en la evidencia. Esto crea un ciclo de generar-recuperar-criticar que se ejecuta solo cuando es necesario.

Un enfoque relacionado es Corrective RAG (CRAG) , que toma un ángulo ligeramente diferente: siempre recupera, pero luego evalúa si la recuperación fue útil antes de incorporarla. Si los documentos recuperados se consideran irrelevantes, CRAG recurre a búsqueda web o genera sin contexto de recuperación. Si son ambiguos, refina la consulta y recupera de nuevo. La innovación clave es el evaluador de recuperación — un modelo ligero que puntúa documentos recuperados por relevancia antes de que lleguen al generador.

La tendencia más amplia aquí es significativa: los modelos se están volviendo conscientes de la recuperación . En lugar de tratar la recuperación como un paso de preprocesamiento fijo (siempre recuperar, siempre usar lo que se obtiene), el modelo mismo decide cuándo recuperar, si la recuperación es útil, y cuánto confiar en la evidencia recuperada versus su propio conocimiento paramétrico. Esto mueve a RAG de un pipeline rígido a un sistema adaptativo donde la recuperación es una herramienta entre muchas que el modelo puede invocar según sea necesario.

import json, js

# Simplified illustration of Self-RAG decision flow
# Shows how different query types trigger different retrieval decisions

queries = [
    ("What is the capital of France?", "no",
     "Model knows this from training — no retrieval needed"),
    ("What were Q3 2025 revenue figures for Acme Corp?", "yes",
     "Specific, time-sensitive fact — retrieval required"),
    ("Explain how gradient descent works", "no",
     "General knowledge well-covered in training data"),
    ("What did the CEO say in yesterday's earnings call?", "yes",
     "Real-time information — must retrieve"),
]

print("Self-RAG [Retrieve] Decision Examples")

table_rows = []
for query, decision, reason in queries:
    action = "RETRIEVE" if decision == "yes" else "GENERATE"
    table_rows.append([query, action, reason])

js.window.py_table_data = json.dumps({
    "headers": ["Query", "Decision", "Reason"],
    "rows": table_rows
})

La convergencia de RAG y contexto largo

Estamos presenciando una convergencia entre lo que alguna vez fueron dos paradigmas separados. El contexto largo y la recuperación ya no son enfoques competidores — se están fusionando en sistemas unificados que difuminan la frontera entre "lo que está en el contexto" y "lo que se recupera".

Esta convergencia está ocurriendo en varios frentes. Primero, modelos de contexto largo que también recuperan . Gemini puede buscar en la web a mitad de conversación, mezclando sin problemas su contexto existente (historial de conversación, documentos subidos) con información recién recuperada. El usuario no distingue entre "el modelo leyó esto en su contexto" y "el modelo acaba de buscar esto" — y cada vez más, el modelo mismo tampoco lo hace.

Segundo, sistemas RAG que aprovechan modelos de contexto largo . El RAG tradicional recuperaba 3-5 pasajes cortos porque los modelos más antiguos tenían ventanas de contexto limitadas. Con ventanas de 128K+, los sistemas RAG ahora recuperan 20-50 pasajes y dejan que el modelo de contexto largo los procese todos, reduciendo la probabilidad de que el error de ranking del recuperador cause que el sistema pierda la respuesta correcta. El recuperador ya no necesita ser perfecto — solo necesita incluir el pasaje correcto en algún lugar de un conjunto generoso de candidatos, y la atención de contexto largo del modelo maneja el resto.

Tercero, los transformers con memoria aumentada (article 4) blur the line between context and retrieval entirely. Memorizing Transformers store past key-value pairs in an external memory and retrieve them via $k$-nearest-neighbour lookup during attention. Is that "extending the context window" or "retrieval"? It's both — the mechanism is retrieval (approximate nearest-neighbour search), but what's being retrieved is the model's own prior context (past key-value states), making it feel like a longer context window. RETRO goes further: it retrieves from an external database of 1.75 trillion tokens, making retrieval indistinguishable from having a truly enormous context.

La trayectoria sugiere un futuro donde la distinción entre "longitud de contexto" y "recuperación" se disuelve. El modelo accederá sin problemas a la información ya sea que esté en la conversación actual (contexto a corto plazo), en un buffer de memoria comprimida (memoria a mediano plazo, como en Titans o Infini-Attention), o en una base de datos externa (conocimiento a largo plazo, como en RETRO o RAG). El usuario simplemente hace una pregunta, y el sistema enruta a la fuente de conocimiento correcta — atención local para contexto reciente, consulta de memoria para contexto anterior, recuperación de base de datos para conocimiento externo — todo dentro de un solo paso hacia adelante.

Esta convergencia resuelve lo que parecía una tensión fundamental. El contexto largo le da al modelo amplitud (puede ver mucha información a la vez), mientras que la recuperación le da profundidad (puede acceder a la información correcta de un corpus arbitrariamente grande). Combinados, el modelo obtiene ambos — un amplio contexto de trabajo aumentado por recuperación dirigida de una base de conocimiento que puede ser órdenes de magnitud más grande que cualquier ventana de contexto.

El artículo final de esta serie examina cómo los modelos de producción combinan todos estos enfoques — codificaciones de posición (artículo 2), patrones de atención eficientes (artículo 3), memoria externa (artículo 4) y contexto aumentado con recuperación (este artículo) — en los sistemas de contexto largo desplegados a escala hoy.

Quiz

Pon a prueba tu comprensión de cómo interactúan la recuperación y el contexto largo.