Análisis: el contexto extenso no acabó con la recuperación, sino que cambió su función
Las ventanas de un millón de tokens hicieron técnicamente posible «ponerlo todo en el prompt». Sin embargo, la precisión, la latencia y el coste desaconsejan hacerlo. Una regla práctica para decidir cuándo recuperar información, cuándo incluirla toda y cuándo combinar ambas estrategias.
Respuesta rápida
¿Hacen innecesaria la RAG las grandes ventanas de contexto?
No, pero cambian su función. Llenar una ventana muy grande reduce la precisión cuando la información está oculta en la parte central, multiplica la latencia y el coste de cada solicitud y dificulta determinar de qué fuente procede una respuesta. La recuperación sigue siendo la opción predeterminada adecuada para corpus grandes o cambiantes, para cualquier tarea que requiera citas o control de acceso y para procesos de gran volumen sensibles al coste. Ahora, el contexto extenso se aprovecha mejor para razonar sobre documentos completos, como memoria de trabajo de los agentes durante una tarea y como segunda etapa después de que la recuperación haya acotado el campo.
Claves
- La capacidad de contexto no equivale a su aprovechamiento. Los modelos recuperan información de forma fiable al principio y al final de una ventana extensa, pero con menor fiabilidad en la parte central.
- El coste y la latencia dependen de lo que realmente se envía, no de lo que admite la ventana. Un paso de recuperación que reduzca 200.000 tokens a 4.000 se amortiza en cada solicitud.
- La recuperación se sustenta en tres propiedades que el contexto extenso no puede ofrecer: citas, actualización y control de acceso por usuario.
- La arquitectura actual más sólida no obliga a elegir entre una opción u otra. Primero se recupera información para acotar el conjunto y, después, se proporciona al modelo un contexto amplio sobre esa selección.
- Si las respuestas son incorrectas porque nunca se recuperó el documento adecuado, evaluar el modelo supone medir el componente equivocado.
Cada vez que una ventana de contexto se agranda en un orden de magnitud, circula la misma afirmación: la recuperación era un parche para ventanas pequeñas, ahora las ventanas son grandes, así que la recuperación ha terminado. Basta con meter los documentos en el prompt y dejar que el modelo se las arregle.
La afirmación no es absurda. Hoy es genuinamente posible colocar en una sola solicitud todo un repositorio de código, un año de correo electrónico o una pila de contratos. La razón por la que la mayoría de los sistemas en producción siguen recuperando información no es la inercia. Es que capacidad y uso son cosas distintas, y que tres de las propiedades de la recuperación no tienen nada que ver con el tamaño de la ventana.
La capacidad no es el uso
Un modelo que acepta un millón de tokens aceptará un millón de tokens. Que los use de manera uniforme es una cuestión empírica distinta, y la respuesta ha sido consistente desde que se caracterizó por primera vez el fenómeno: la memoria es más fuerte al principio y al final de una entrada larga, y más débil en el medio.
La consecuencia práctica resulta incómoda. Dónde cae un documento dentro del prompt afecta a si el modelo lo utiliza, independientemente de lo relevante que sea ese documento. Un sistema que concatena cincuenta documentos en un orden arbitrario ha introducido una variable de calidad que nadie está monitorizando y que cambiará la próxima vez que cambie el orden de concatenación.
La tranquilidad habitual llega de un resultado tipo «aguja en el pajar»: una frase distintiva colocada en una ventana grande y encontrada de forma fiable. Esa prueba es mucho más fácil de lo que parece. Encontrar una cadena inusual es una tarea de coincidencia léxica. Las preguntas reales exigen agregar información de varios pasajes, notar que dos de ellos se contradicen o determinar que la respuesta está ausente. Los bancos de pruebas diseñados para exigir ese nivel de dificultad muestran, de forma consistente, un contexto de trabajo efectivo muy por debajo de la capacidad anunciada.
La aritmética que nadie quiere hacer
El coste y la latencia escalan con lo que envías, no con lo que te permiten enviar.
Pensemos en un asistente de soporte que atiende diez mil preguntas al día contra una base de conocimiento de 200.000 tokens. Meter toda la base en cada solicitud supone dos mil millones de tokens de entrada al día. A cualquier precio de vanguardia actual, esa es una partida de gasto que se nota. Recuperar cuatro mil tokens relevantes por pregunta supone cuarenta millones: un factor de cincuenta, aplicado a cada solicitud, para siempre.
La latencia sigue la misma curva. El tiempo hasta el primer token crece con la longitud de la entrada, y un widget de soporte donde la respuesta empieza a aparecer en 900 milisegundos es un producto distinto de uno que tarda ocho segundos, con independencia de la calidad de la respuesta.
La caché de prompts complica esto de un modo que conviene precisar, porque es el argumento más sólido a favor de meterlo todo en el prompt. Cuando un prefijo largo es idéntico en muchas solicitudes, la caché puede reducir su coste en un múltiplo considerable y recortar la latencia de forma significativa. Si tu corpus es realmente compartido y estable —un manual de producto fijo, un código legal fijo—, esto cambia el cálculo y está infrautilizado. Pero la caché no sirve de nada cuando el contenido extenso difiere según el usuario o la solicitud, que es lo que describe a la mayoría de los despliegues empresariales, donde precisamente cada usuario puede ver documentos distintos.
Las tres propiedades que tiene la recuperación y el contexto no
Esta es la parte del argumento que no cambia por mucho que crezcan las ventanas.
Atribución. Un pasaje recuperado tiene una identidad antes de que el modelo lo vea siquiera: un identificador de documento, una URL, una página, una revisión. Cuando el modelo lo cita, la cita se puede verificar mecánicamente. El texto volcado en una ventana no tiene esa identidad, y pedirle a un modelo que cite a partir de una masa indiferenciada produce referencias difíciles de comprobar y fáciles de inventar. Para cualquier aplicación en la que una respuesta equivocada necesite una fuente rastreable —legal, médica, financiera, de cumplimiento normativo—, esto por sí solo zanja el diseño.
Actualidad. Los corpus cambian. Un índice de recuperación se actualiza escribiendo filas nuevas; un prompt saturado de contenido se actualiza reconstruyendo y reenviando toda la carga útil. Cuando tu base de conocimiento cambia cada hora, uno de estos procesos es una tarea de fondo y el otro es un impuesto que se paga en cada solicitud.
Control de acceso. Este es el que, calladamente, decide la mayoría de las arquitecturas empresariales. Distintos usuarios tienen permiso para ver distintos documentos. En un sistema de recuperación, los permisos son un filtro aplicado en el momento de la consulta, antes de que ningún texto llegue al modelo: una frontera de autorización ordinaria y auditable. En un sistema que lo mete todo en el prompt, la decisión sobre permisos tiene que tomarse al ensamblar la carga útil, y cualquier error significa que el documento confidencial de un usuario acaba dentro del prompt de otro. Una vez que está en la ventana, ningún control posterior puede hacer que deje de haberse visto.
En qué es realmente mejor el contexto largo
El error simétrico sería concluir que la recuperación siempre gana. Las ventanas grandes son decisivamente mejores para un conjunto de tareas específico y cada vez mayor.
Razonamiento sobre el artefacto completo. Resumir un contrato entero, rastrear un error a lo largo de un repositorio de código, comparar dos documentos largos cláusula por cláusula. Fragmentar el texto destruye activamente la estructura de la que dependen estas tareas. Si la pregunta trata sobre la forma del conjunto, la recuperación te entrega fragmentos de un argumento que necesitabas intacto.
Memoria de trabajo del agente. Un agente que lleva cuarenta pasos dentro de una tarea arrastra su propio historial: resultados de herramientas, razonamientos intermedios, archivos que ha leído. Ese es contexto acumulado dentro de la sesión, y ningún índice de recuperación lo tiene. Las ventanas más grandes amplían directamente cuánto puede trabajar un agente antes de que sus decisiones anteriores necesiten comprimirse.
Lecturas de bajo volumen y alto riesgo. Cuando una tarea se ejecuta apenas unas decenas de veces al día y acertar importa más que el coste por llamada, la sencillez de meterlo todo en el prompt vale la pena. No todos los sistemas necesitan un índice.
La arquitectura que realmente gana
Planteado como una disyuntiva, esto es un falso dilema. El patrón más sólido en la actualidad usa ambas cosas, en secuencia.
Recuperar de forma amplia y luego leer con generosidad. Usa la recuperación para reducir un corpus grande a un conjunto de candidatos, pero donde un sistema más antiguo habría pasado tres fragmentos de 500 tokens, pasa veinte documentos completos. La recuperación hace el trabajo para el que es buena, que es seleccionar bajo control de acceso y con la atribución intacta. El contexto largo hace el trabajo para el que es bueno, que es razonar sobre el material sin fragmentación artificial.
Esto invierte una suposición incrustada en mucho código antiguo de RAG: que los fragmentos deben ser pequeños porque la ventana escasea. La ventana ya no escasea. Fragmenta pensando en la calidad de la recuperación, no en el presupuesto de la ventana: recupera con la granularidad que haga preciso el emparejamiento y luego amplía cada resultado a su sección o documento completo antes de meterlo en el prompt.
Dos prácticas más pequeñas importan más de lo que solían. Ordena de forma deliberada: dado el efecto de posición, los pasajes con mayor puntuación deberían situarse en los extremos del contexto ensamblado y no en el medio. Y etiqueta cada pasaje con su identificador de fuente dentro del prompt, para que la citación siga siendo mecánica y no una petición de buena fe al modelo.
Evaluar el componente correcto
Un hábito de diagnóstico evita la mayor parte del esfuerzo desperdiciado aquí. Cuando una respuesta es incorrecta, determina si el documento necesario estaba en el contexto siquiera.
Si no lo estaba, la etapa de recuperación falló y ningún cambio de modelo lo va a arreglar. Si estaba presente y el modelo aun así se equivocó, es un problema de generación, y entonces sí se vuelve relevante la cuestión del tamaño de la ventana, el orden y la estructura del prompt. Los sistemas que solo miden la calidad de extremo a extremo no pueden distinguir estos dos casos, y los equipos que los usan tienden a pasarse meses cambiando de modelo para arreglar un índice roto.
En resumen: el contexto largo eliminó la restricción que hacía obligatoria la recuperación, y dejó intactas todas las demás razones para recuperar. La mayoría de los sistemas en producción conservarán ambas cosas, y el trabajo de diseño interesante se ha desplazado de si conviene recuperar a cuánto entregarle al modelo una vez que ya lo has recuperado.
Preguntas frecuentes
- ¿Qué significa «perdido en el medio»?
- Es el patrón observado según el cual los modelos recuerdan con mayor fiabilidad la información situada al principio o al final de una entrada extensa que la ubicada en la parte central. Esto significa que la posición de un documento en el prompt influye en que el modelo lo utilice o no, con independencia de su relevancia.
- ¿Basta una prueba de búsqueda de una aguja en un pajar para confiar en una ventana extensa?
- No. Encontrar una única frase distintiva insertada deliberadamente es una tarea mucho más sencilla que reunir, comparar o razonar a partir de numerosos pasajes dispersos por la misma ventana, que es lo que exigen las preguntas reales.
- ¿Cuándo conviene incluir el documento completo?
- Cuando el corpus es pequeño y estable, cuando la pregunta requiere realmente el documento entero y cuando el volumen es lo bastante bajo como para que el coste por solicitud carezca de importancia. La revisión de contratos, el análisis de una única base de código y las lecturas exhaustivas puntuales cumplen estos criterios.
- ¿El almacenamiento en caché de prompts elimina el argumento del coste?
- Lo reduce de forma considerable cuando se reutiliza un prefijo estable en numerosas solicitudes, una optimización real y poco aprovechada. No resulta útil cuando el contenido voluminoso cambia según el usuario o la solicitud, ni resuelve los problemas de precisión o atribución.
- ¿Cómo funcionan las citas sin recuperación?
- Son mucho menos fiables. Pedir a un modelo que cite a partir de una gran cantidad de texto sin etiquetar dentro de su ventana genera referencias difíciles de verificar de forma automatizada. La recuperación asigna una identidad a cada pasaje antes de que el modelo lo procese, lo que permite comprobar las citas.