RAG o contexto largo: la respuesta correcta es 'depende', y aquí está de qué

Cuando las ventanas de contexto empezaron a medirse en millones de tokens, apareció un argumento seductor: si cabe todo, ¿para qué montar una arquitectura de recuperación?

La evidencia publicada desde entonces no respalda esa conclusión. Tampoco respalda la contraria.

Lo que dice la investigación

El benchmark LaRA, presentado en ICML, evaluó 2.326 casos de prueba en cuatro tipos de tarea de pregunta-respuesta y tres tipos de contexto largo sobre once modelos. Su conclusión se titula, sin rodeos, “no hay bala de plata”: la elección óptima depende de la interacción entre capacidad del modelo, longitud del contexto, tipo de tarea y características de la recuperación.

En el terreno empresarial, EnterpriseRAG-Bench señala un hueco relevante: los conjuntos de datos existentes se centran en fuentes web o públicas, y no había un banco de pruebas ampliamente adoptado que reflejase conocimiento interno de empresa. Que es exactamente donde opera la mayoría de proyectos reales.

Cuándo gana el contexto largo

• El corpus es pequeño y estable. Un contrato, un pliego, un manual. Si cabe entero y no cambia cada día, meterlo en contexto es más simple y suele dar mejor resultado.
• La pregunta exige mirar todo a la vez. “¿Hay contradicciones entre estas cláusulas?” no se responde recuperando tres fragmentos.
• Estás prototipando. Montar RAG antes de saber si el caso de uso funciona es optimización prematura.

Cuándo gana la recuperación

• El corpus es grande o crece. Miles de documentos, o documentos nuevos cada día.
• El coste importa. Pasar un millón de tokens en cada consulta es caro aunque el precio por token haya caído. Recuperar cinco fragmentos, no.
• Necesitas citar la fuente. RAG te da la trazabilidad de qué documento respaldó la respuesta. El contexto largo, mucho menos.
• Hay control de acceso. Si distintos usuarios pueden ver distintos documentos, la recuperación filtra antes de generar. Con todo en contexto, el filtrado es un problema.

Ese último punto se subestima constantemente y es el que suele decidir la arquitectura en empresas con datos sensibles.

El error habitual

Montar RAG como si fuera un producto cerrado: trocear, vectorizar, buscar por similitud y listo. Cuando la calidad no llega, el equipo cambia de modelo. Casi nunca es el modelo.

Los sitios donde se pierde calidad, por orden de frecuencia:

1. El troceado rompe el significado. Cortar cada 500 tokens parte tablas, listas y cláusulas por la mitad.
2. La búsqueda por similitud no encuentra lo correcto. La similitud semántica falla con nombres propios, códigos y referencias. Combinar búsqueda léxica y vectorial arregla más de lo que parece.
3. Se recupera poco o demasiado. Ambas cosas degradan; y cuál es el número bueno sólo lo dice tu evaluación.
4. No se reordena. Un reranker sobre los candidatos suele dar más mejora que cambiar de modelo generador.

Lo que recomendamos

Empieza metiendo el documento en contexto y mide. Si funciona y el coste aguanta, ya has terminado — y te has ahorrado una arquitectura.

Cuando el corpus crezca, el coste apriete o aparezca el control de acceso, monta recuperación. Para entonces tendrás algo que la mayoría no tiene al empezar: un set de evaluación que te dirá si el cambio mejoró de verdad las cosas.

Fuentes

• LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs — No Silver Bullet for LC or RAG Routing (ICML)
• EnterpriseRAG-Bench: A RAG Benchmark for Company-Internal Knowledge — arXiv
• Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach — arXiv
• LongBench v2: Towards Deeper Understanding and Reasoning on Realistic Long-context Multitasks — arXiv