RAG vs modelos de contexto largo: cuándo meter todo en el prompt y cuándo usar recuperación

Meter todos sus documentos directamente en el prompt de un modelo de contexto largo funciona para consultas puntuales sobre un corpus pequeño y estable. Para bases de conocimiento que crecen, que se consultan muchas veces al día o que necesitan citar la fuente exacta, la recuperación (RAG) sale más barata, más rápida y más precisa. La elección correcta depende del volumen de preguntas, del tamaño del corpus y de si necesita trazabilidad.

Qué es un modelo de contexto largo y qué cambia realmente

Un modelo de contexto largo es un modelo de lenguaje capaz de aceptar ventanas de entrada muy grandes, desde 128.000 hasta más de un millón de tokens según el proveedor. En la práctica, eso significa que puede leer de una vez varios cientos de páginas de documentos (contratos, manuales, actas) sin necesidad de dividirlos ni de indexarlos previamente. El atractivo es evidente: nada que preparar, nada que mantener, se pega todo el texto en el prompt y se pregunta.

Pero «caber en la ventana» no es lo mismo que «usarse bien». Varios estudios sobre comportamiento de modelos de contexto largo muestran el fenómeno conocido como lost in the middle: la información situada al principio o al final del contexto se recupera con más fiabilidad que la que está en medio de un bloque de texto muy largo. Cuantos más tokens hay delante del modelo, más fácil es que pase por alto el párrafo exacto que contiene la respuesta, aunque técnicamente estuviera dentro de la ventana.

Qué es RAG y en qué se diferencia

RAG (retrieval augmented generation) no manda todo el corpus al modelo. Primero divide los documentos en fragmentos (chunks), los indexa para búsqueda híbrida (texto completo más expansión semántica) y, cuando llega una pregunta, recupera solo los 5-15 fragmentos más relevantes antes de generar la respuesta. El modelo nunca «ve» el documento entero, ve exactamente lo que necesita para responder esa pregunta concreta. Si quiere entender el mecanismo paso a paso, lo explicamos con un ejemplo real en cómo funciona RAG paso a paso.

La diferencia de fondo es esta: el contexto largo resuelve el problema metiendo más texto en cada llamada al modelo. RAG lo resuelve filtrando antes de llamar al modelo. Uno escala con el tamaño de la ventana, el otro escala con la calidad del índice de búsqueda.

La comparativa de coste: qué paga realmente cada pregunta

El coste de una llamada a un modelo depende sobre todo de los tokens de entrada, y ahí está la diferencia práctica. Si su base documental tiene 2.000 páginas (del orden de 800.000-1.000.000 de tokens) y la envía entera en cada pregunta, está pagando esos tokens de entrada en cada una de las consultas, aunque la pregunta solo necesite tres párrafos concretos. Con RAG, cada pregunta solo mueve los tokens de los fragmentos recuperados, normalmente entre 1.000 y 4.000 tokens.

La clave está en que el coste del contexto largo crece con el tamaño del corpus, mientras que el coste de RAG crece con el número de preguntas, no con el tamaño de la base. Si su conocimiento documental va a seguir creciendo (y casi siempre crece), el enfoque de contexto largo se vuelve cada vez más caro con el tiempo, mientras que RAG se mantiene plano. Puede profundizar en qué componentes forman el coste real de una base vectorial en precio de una base de datos vectorial: qué paga realmente.

Cuándo meter todo el contexto gana

El contexto largo no es mala idea en todos los casos. Tiene sentido cuando:

• El corpus es pequeño y estable: un único contrato, un informe, una tanda de actas de una reunión que no va a cambiar.
• La tarea requiere razonar sobre el documento completo de forma secuencial, por ejemplo resumir un contrato de 80 páginas de principio a fin o detectar inconsistencias entre cláusulas repartidas por todo el texto.
• El volumen de preguntas es bajo: una consulta puntual, no un servicio que recibe cientos de preguntas al día.
• No hay necesidad de escalar a varios documentos o usuarios distintos consultando a la vez.

En estos escenarios, montar una base de conocimiento, indexarla y mantenerla sería sobreingeniería. Pegar el documento en el prompt de una conversación es más rápido de implementar y, para un uso ocasional, también más barato en términos absolutos.

Cuándo RAG gana

RAG se vuelve la opción correcta en cuanto aparece alguna de estas condiciones:

• El corpus es grande o crece con el tiempo: manuales técnicos, normativa, histórico de tickets de soporte, documentación de producto.
• Hay muchas preguntas repetidas al día, de distintos usuarios o agentes, y el coste por pregunta importa.
• Necesita citar la fuente exacta (número de página, cláusula, artículo) para que el usuario pueda verificar la respuesta, algo esencial en sectores regulados. Lo tratamos en detalle en cómo verificar una respuesta de IA con sus fuentes citadas.
• Varios documentos de distinta naturaleza conviven en la misma base y hay que decidir, pregunta a pregunta, cuáles son relevantes.
• Quiere exponer esa base a varios canales a la vez: un chat web, una API para su aplicación y un servidor MCP para que Claude, Cursor o ChatGPT consulten los mismos documentos sin duplicar el trabajo.

Además, la recuperación bien hecha reduce las alucinaciones porque el modelo trabaja sobre un puñado de fragmentos verificables en lugar de tener que localizar la aguja en un pajar de cientos de miles de tokens. Si ese es su objetivo principal, conviene leer cómo reducir las alucinaciones de la IA con respuestas basadas en fuentes.

Por qué el contexto largo pierde precisión aunque todo quepa en la ventana

Que un modelo acepte un millón de tokens no significa que los procese todos con la misma atención. El fenómeno lost in the middle hace que, cuanto más texto irrelevante rodea al dato correcto, más probable es que el modelo lo pase por alto o lo mezcle con información de otra parte del documento. Esto es especialmente problemático en documentos largos con estructura repetitiva, como pliegos de condiciones, convenios colectivos o manuales técnicos donde varias secciones tratan temas parecidos con matices distintos.

RAG ataca este problema desde el origen: en lugar de confiar en que el modelo encuentre el párrafo correcto entre un millón de tokens, se lo entrega ya filtrado. Para que ese filtrado funcione bien, la calidad de la búsqueda importa tanto como la del modelo. Una búsqueda solo semántica puede fallar con referencias exactas (números de artículo, códigos de producto, nombres propios), por eso conviene combinar palabras clave y vectores, como explicamos en búsqueda híbrida: por qué combinar palabras clave y vectores gana a cualquiera de las dos por separado. La forma en que se trocean los documentos también influye directamente en la precisión final, un tema que desarrollamos en estrategias de chunking para RAG.

El enfoque híbrido: lo mejor de ambos mundos

En la práctica, muchos equipos no eligen uno u otro de forma exclusiva. Usan RAG para recuperar los fragmentos relevantes y luego dejan que el modelo trabaje con un contexto moderado (unos pocos miles de tokens) en lugar de la ventana completa. Esto combina la precisión de la recuperación con la capacidad de razonamiento del modelo sobre un conjunto acotado de información, sin pagar por procesar el corpus entero en cada pregunta.

Este es, de hecho, el diseño que siguen la mayoría de plataformas de RAG as a service: extraen, trocean e indexan los documentos una vez, y luego sirven solo lo necesario en cada consulta, ya sea desde una web, una API o un servidor MCP. Si quiere comparar distintas opciones del mercado antes de decidirse, repasamos varias en plataformas de RAG as a service: comparativa.

En Kopik, este enfoque está integrado de serie: sube sus documentos (PDF, Word, texto o Markdown), el sistema los trocea e indexa para búsqueda híbrida, y cada pregunta recibe una respuesta con pasajes citados, sin que usted tenga que gestionar ventanas de contexto ni preocuparse de cuánto crece el corpus. Puede crear una base privada solo para su equipo o publicarla en el catálogo y cobrar por pregunta, quedándose con el 70 % del precio que fije.

Resumen: la tabla de decisión

• Corpus pequeño y estable, pocas preguntas → contexto largo, sin indexación previa.
• Corpus grande o que crece, muchas preguntas repetidas → RAG, coste plano por pregunta.
• Necesita citar página o artículo exacto → RAG, con pasajes verificables.
• Varios canales de consulta (web, API, MCP) sobre el mismo conocimiento → RAG, una sola base sirve a todos.
• Tarea de razonamiento secuencial sobre un único documento completo → contexto largo, sin perder cohesión.

Si después de este análisis le queda claro que su caso es de volumen o de trazabilidad, el siguiente paso natural es explorar el catálogo de bases de conocimiento para ver ejemplos ya montados, o revisar la documentación de API y MCP si quiere integrar la recuperación directamente en su aplicación o en su editor de código.