FocusLM
Todos los artículos

RAG frente a contexto largo: ¿cuál deberías usar realmente?

22 de julio de 20267 min de lectura

En cuanto un modelo puede leer un millón de tokens en un solo prompt, resulta tentador declarar muerta la recuperación: dáselo todo y ya está. Un estudio riguroso dice que la respuesta es más interesante que eso.

TL;DR

  • Con recursos suficientes, dar el documento entero a un modelo de contexto largo suele superar a la recuperación en calidad de respuesta.
  • La recuperación (RAG) es muchísimo más barata porque envía muchos menos tokens.
  • Un enrutador sencillo que manda las preguntas fáciles a RAG y las difíciles al contexto largo recupera casi toda la calidad a una fracción del coste.

Dos formas de dar contexto a un modelo

Hay dos grandes estrategias para fundamentar una respuesta en tu material. La generación aumentada por recuperación (RAG) busca en tus datos, extrae los pocos fragmentos más relevantes y coloca solo esos en el prompt. El contexto largo se salta la recuperación y mete el documento entero (o muchos documentos) directamente en la ventana. A medida que las ventanas superaron los cien mil tokens, la gente empezó a preguntarse si RAG seguía compensando toda esa infraestructura.

Lo que muestra la investigación

En Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach, investigadores de Google DeepMind enfrentaron los dos enfoques cara a cara en los tres modelos de contexto largo más potentes disponibles en aquel momento — Gemini-1.5-Pro, GPT-4o y GPT-3.5-Turbo— sobre una batería de conjuntos de datos de QA de documentos largos tomados de benchmarks consolidados. Para cada pregunta compararon dos configuraciones: dar el documento entero al modelo (contexto largo) frente a recuperar los k fragmentos más relevantes y darle solo esos (RAG).

Su hallazgo principal: cuando el modelo es potente y puedes permitirte darle todo, el contexto largo produce de forma consistente mejores respuestas que RAG en promedio. La recuperación a veces deja fuera justo el fragmento que contenía la respuesta; poner el documento completo en la ventana elimina ese modo de fallo. Pero los dos enfoques también estaban muy correlacionados: en la gran mayoría de las preguntas devolvían la misma respuesta, un hecho que los autores acabarían aprovechando.

La trampa es el coste. El contexto largo implica pagar por procesar decenas o cientos de miles de tokens en cada una de las consultas, incluso cuando la respuesta cabía en un solo párrafo.

RAG, en cambio, envía solo un puñado de pasajes recuperados, así que es mucho más barato por consulta. El estudio lo plantea como un verdadero compromiso más que como un ganador: el contexto largo compra calidad, RAG compra eficiencia.

RAGContexto largoEnrutadorcoste por consulta →calidad de la respuesta →
El compromiso cualitativo: el contexto largo lidera en calidad, RAG en coste, y un enrutador apunta a la esquina superior izquierda. Las posiciones son ilustrativas.

El híbrido: enruta, no elijas

Esa correlación es la oportunidad. Los autores proponen Self-Route, una tubería de dos pasos que deja que el propio modelo decida, consulta a consulta, qué camino tomar:

  1. Primero RAG, con una vía de escape. Se le dan al modelo los fragmentos recuperados y se le pide que responda o declare la pregunta «irresoluble» a partir de lo que se le mostró, sin adivinar.
  2. Escala solo lo irresoluble. Las preguntas que el modelo marca como irresolubles se vuelven a ejecutar con el documento completo en la ventana; todo lo demás conserva la respuesta barata de RAG.

Como RAG y el contexto largo ya coinciden en la mayoría de las preguntas, solo una minoría llega al camino caro. El resultado es una calidad de respuesta cercana a la de usar siempre contexto largo, a un coste cercano al de usar siempre RAG.

La pregunta correcta rara vez es «¿RAG o contexto largo?»: es «¿cuál necesita esta consulta en concreto?».

Lo que significa para ti

De aquí se derivan dos cosas para cualquiera que construya sobre un LLM. Primero, una ventana de contexto más grande no vuelve inútil la recuperación: cambia cuándo recurres a ella. Segundo, la opción por defecto inteligente no es «volcarlo todo siempre», sino «mantener el material organizado para que el sistema pueda extraer la porción adecuada, y pagar por el conjunto completo solo cuando una pregunta lo necesita de verdad».

Dónde encaja FocusLM

FocusLM guarda tu material como una memoria estructurada en lugar de un único prompt que no para de crecer. Esa estructura es lo que hace posible el camino barato: la mayoría de las preguntas se responden a partir de los pocos archivos relevantes y citados, y el contexto más amplio está ahí cuando una pregunta lo necesita de verdad; la misma lógica de enrutar en lugar de elegir, aplicada a una memoria que crece contigo.

Lecturas relacionadas