Cuándo pasar todo el contexto y cuándo introducir RAG

La pregunta útil no es cómo montar RAG primero. La pregunta útil es cuánto conocimiento necesita el modelo para resolver una tarea, y si ese conocimiento cabe completo en el contexto con un costo razonable.

Si la respuesta es sí, recuperar antes de tiempo te compra complejidad, latencia y trabajo de depuración. Si la respuesta es no, entonces la recuperación deja de ser un adorno y se vuelve una forma de selección. Esa frontera no depende de una moda. Depende del tamaño del corpus, del número de pasos de tu pipeline, de cuánto puedes inspeccionar cuando algo sale mal y del orden en que presentas el contexto.

Empieza por CAG cuando el contexto ya se conoce

CAG —contexto aumentado sin recuperación— sirve cuando el conocimiento necesario es acotado y estable. En ese caso, pasarlo entero en el prompt resulta más barato, más rápido y mucho más fácil de depurar que montar un pipeline de recuperación. La regla práctica es directa: si el contexto que necesitas ya está identificado y cabe, pásalo completo; si todavía tienes que escoger qué entra, entonces sí necesitas recuperar.[9][11]

Ese criterio puede convivir dentro del mismo sistema. Hay tareas donde el contexto es el propio estado del trabajo: checkpoints, pasos completados y errores. Si todo eso cabe, no hace falta buscar nada. También hay tareas donde el corpus crece con cada fuente nueva y el sistema tiene que elegir fragmentos para escribir. Ahí sí aparece RAG —generación aumentada por recuperación—, porque el problema ya no es recordar lo conocido sino seleccionar entre demasiadas opciones.[11][12]

Un caso cercano es la memoria conversacional. Guardar todo el historial y reenviarlo en cada vuelta es la forma más cara de recordar. Además, tampoco es la más eficaz cuando la información importante queda enterrada a la mitad del contexto. En una conversación de diagnóstico, sirve más reenviar el estado del run —qué pasos terminaron, qué checkpoint existe y cuál fue el error— que la transcripción completa de mensajes.[12][96]

La frontera aparece por tamaño, atención y dinero

El tamaño del corpus es el límite más visible. Si trabajas con unas cuantas piezas conocidas, todavía puedes meter todo en la ventana. Si el corpus son decenas de documentos hoy y cientos mañana, dejar de seleccionar ya no es realista. Mandarlos por lotes no evita el problema. Sólo reintroduce una recuperación peor, sin un criterio claro para escoger.[10]

El segundo límite es la atención del modelo. Un contexto grande no garantiza que el modelo use bien lo que lleva dentro. En las notas se cita el resultado de “Lost in the Middle”: el rendimiento cae cuando la información relevante queda en medio de un contexto largo, y sube cuando aparece al principio o al final. Eso cambia la decisión técnica. Recuperar no sirve sólo porque el corpus ya no cabe. Sirve también porque un contexto corto con lo importante bien colocado puede rendir mejor que una ventana enorme llena de material correcto pero mal ordenado.[10]

El tercer límite es el dinero. Cada token de entrada se cobra en cada llamada. Si tu sistema hace una sola llamada, quizá mandar mucho contexto todavía sea defendible. Si tu flujo ya es un pipeline de siete pasos, reenviar todo el corpus en cada etapa multiplica el gasto por siete. En un bucle agéntico, además, el contexto se arrastra vuelta tras vuelta, y la octava llamada cuesta más que la primera porque arrastra siete rondas previas de observaciones.[10][96]

Ese es el argumento más fuerte contra la alternativa de “recuperar siempre” o “mandar siempre todo”. Recuperar siempre añade una parte del sistema que luego tienes que construir, medir y depurar. Mandar siempre todo te cobra más conforme crecen los pasos. Ninguna de las dos decisiones se justifica antes de que el corpus deje de caber o de que la selección empiece a mejorar la calidad de forma visible.[9][48]

Cuando sí recuperas, el contexto se diseña

En cuanto introduces RAG, deja de bastar con “traer documentos”. La recuperación se vuelve el cuello de botella de la calidad. Si entran fragmentos malos al prompt, el modelo final redacta basura con buena prosa. Por eso conviene medir la recuperación por separado de la generación y poder inspeccionar exactamente qué fragmentos llegaron a cada etapa.[1]

Aquí entra una decisión que suele esconderse como detalle técnico: qué entra al contexto, en qué orden y con qué formato. Eso es una decisión de producto. El orden importa porque la atención del modelo no es uniforme. La cantidad importa porque el presupuesto no es infinito. El formato importa porque un bloque sin estructura se lee peor que una lista con etiquetas.[11]

Un conjunto de reglas concretas ayuda más que una intuición vaga:

1. Pon lo más importante al principio y al final del prompt.
2. Define un presupuesto fijo por etapa, en lugar de mandar “todo lo que quepa”.
3. Etiqueta cada fragmento con su identificador para poder citarlo y auditar después si realmente se usó el material recibido.[11]

En un pipeline real, esa idea se tradujo así: el analista recibe hasta doce fragmentos y el escritor hasta seis. Esos topes viven en configuración para moverlos midiendo, no discutiendo. La lección transferible es clara: cada etapa tiene un trabajo distinto y necesita su propio presupuesto. No conviene heredar el mismo volumen de contexto para todos los pasos sólo por comodidad.[11]

Cuando el orden del procedimiento ya se conoce, tampoco hace falta delegarlo a un agente. Una cadena fija resuelve mejor los pasos que ya decidiste: analizar, estructurar, escribir, ensamblar. Darle al modelo la decisión del orden añade llamadas, imprevisibilidad y costo para resolver algo que no estaba roto. La autonomía conviene cuando el problema difícil es decidir el procedimiento mismo, como en un diagnóstico donde todavía no sabes qué falló ni qué acción sigue.[49][87]

Qué sí puedes decidir hoy, y qué no cubren estos materiales

Con estos fragmentos sí puedes tomar varias decisiones iniciales.

Si tu tarea usa un contexto conocido y acotado, empieza sin recuperación. Si tu corpus crece, si tienes que elegir entre muchas fuentes o si reenviar todo en cada paso dispara el costo, introduce RAG. Cuando lo hagas, no empieces por “más contexto”. Empieza por selección, orden y presupuesto por etapa.[11][10]

También puedes evitar un error común de depuración. Si no puedes ver qué fragmentos entraron al prompt, no estás depurando. Estás adivinando. Un banco de pruebas que enseñe cada etapa de la recuperación vale más que una métrica agregada, porque la calidad depende casi por completo de los fragmentos recuperados.[1]

Hay decisiones de diseño mencionadas en el corpus que conviene tratar con precisión. La generación de piezas usa búsqueda híbrida y reordenado. Eso sí está afirmado. Lo que no está aquí es una implementación reproducible del índice, del almacenamiento o del ranking. Tampoco hay material suficiente para enseñar cómo fragmentar documentos, cómo fusionar listas de recuperación o cómo configurar un reordenador paso a paso. Si necesitas esa parte, hace falta otro artículo con fuentes que sí describan el mecanismo.[11][1]

Para arrancar en tu proyecto, el orden razonable es este:

1. Lista las tareas de tu sistema y separa cuáles usan contexto conocido del propio proceso y cuáles deben elegir entre fuentes cambiantes.
2. Para cada tarea, mide cuántas llamadas hace el pipeline y estima el costo de reenviar el contexto completo en cada etapa.[10]
3. Si el conocimiento cabe y es estable, pásalo entero y conserva sólo la memoria útil, no el historial completo.[9][12]
4. Si necesitas recuperación, fija un presupuesto por etapa y define el orden del contexto de forma explícita.[11]
5. Prepara una forma de inspeccionar los fragmentos recuperados antes de optimizar la generación final.[1]

Con eso ya puedes responder la pregunta central con criterio propio. RAG entra cuando seleccionar deja de ser opcional. Antes de ese punto, CAG suele ser la solución más barata de operar y la más fácil de entender cuando algo falla.