En 2026, las ventanas de contexto de 1 a 2 millones de tokens se han convertido en la norma: Claude Sonnet ya tiene 1 millón, Gemini 3 también tiene 1 millón, y el más reciente Gemini 3.1 Ultra ya ha alcanzado los 2 millones. Llama 4 Scout incluso anuncia 10 millones. La conclusión lógica a la que llegan muchos equipos es: ¿por qué complicarse con un pipeline RAG con chunking, base de datos vectorial y re-ranker, si se puede simplemente meter toda la base de conocimientos en el prompt?
Si aún no has entendido completamente en qué se diferencia RAG de un LLM normal, empieza con el artículo LLM vs RAG: ¿cuál es la diferencia y qué elegir?, que proporciona la base que aquí se considera conocida. Este artículo es para aquellos que ya entienden qué es RAG y quieren entender si todavía es necesario en la era de las ventanas de contexto de millones de tokens.
Esto es una trampa. El tamaño del contexto no es magia gratuita. En este artículo, explicaremos por qué la carga de datos "tonta" arquitectónicamente arruina la economía del proyecto, por qué es una cuestión de seguridad, no solo de calidad, y cómo se ve realmente la arquitectura de 2026. Los ejemplos son del servicio RAG real AskYourDocs.
El mito de los modelos "omnívoros"
Cuando Anthropic anunció 1 millón de tokens de contexto para Claude Sonnet, me preparé un té y me pregunté seriamente: ¿vale la pena seguir manteniendo el pipeline RAG en AskYourDocs? Calculé a ojo: un cliente corporativo típico carga 200-400 documentos, lo que equivale a aproximadamente 600-800 mil tokens. Teóricamente, todo cabe en una sola ventana. La tentación no era abstracta, sino muy concreta: deshacerse del chunking, la base de datos vectorial, el re-ranker, y simplemente cargar todo en una sola consulta.
El discurso público sobre este tema lo vi dividido en dos extremos, y ninguno de ellos se correspondía con lo que veía en mi propio proyecto. El primero es el marketing de los proveedores, que leía en los anuncios de modelos y en conferencias técnicas: "el contexto largo reemplaza a RAG, simplemente carga todo en el prompt y la complejidad desaparecerá sola". El segundo es la información desactualizada de 2024, que yo mismo escribí en mis primeros artículos en WebsCraft: el valor de RAG se explicaba exclusivamente como una forma de superar el límite de 4-8K tokens. Pero este límite ya no existe desde hace uno o dos años, y en mi propio proyecto RAG no ha desaparecido ni debería desaparecer, simplemente la razón de su existencia ha cambiado.
Por qué la vieja argumentación ya no funciona: cuando el contexto era pequeño, RAG era la única forma técnica de dar al modelo acceso a conocimiento externo; sin él, el modelo simplemente no vería los documentos del cliente. Ahora el contexto es grande, y la pregunta ha pasado de "¿cabe el documento?" a "¿vale la pena cargarlo allí?". Me convencí de esto con mis propios cálculos: cuando calculé el costo real de cargar toda la base de datos del cliente en cada consulta (esto está más adelante en la sección sobre economía), quedó claro que la pregunta ya no es técnica, sino puramente económica, de velocidad y, lo que resultó ser lo más importante para B2B, una cuestión de seguridad en el acceso a los datos de diferentes clientes.
En resumen: que un modelo sea técnicamente capaz de digerir 1 MB de documento a la vez no significa que arquitectónicamente sea la solución correcta para un sistema de producción con miles de consultas al mes. La posibilidad y la conveniencia son cosas diferentes, y es precisamente esta diferencia la que no entendí de inmediato hasta que calculé las cifras.
La economía de la inferencia: la trampa de los tokens (The Token Trap)
Imaginemos una base de conocimientos corporativa de 5 MB, aproximadamente 1 millón de tokens. Comp
Dónde el contexto largo realmente gana
La honestidad exige admitir: el contexto largo no es siempre la peor opción. Hay escenarios en los que es objetivamente más fuerte que RAG, y silenciar esto significaría repetir el mismo error de marketing unilateral, solo que en la otra dirección.
Escenario
Qué es mejor
Por qué
Análisis profundo de un solo documento (libro, contrato)
la conversación es un flujo secuencial, no un conjunto de hechos discretos; RAG es inadecuado para referencias del tipo "recuerdas que dijiste..." y para mantener el tono de todo el diálogo
Razonamiento de varios pasos, preguntas implícitas
Base de conocimiento dinámica y frecuentemente actualizada
RAG
la actualización del vector lleva segundos, sin recargar el contexto
Análisis de investigación único
Contexto largo
no vale la pena construir un pipeline para una tarea que realizarás una vez
Me convencí de esto por experiencia propia cuando trabajaba en un servicio de chatbot donde el modelo tenía que recordar todo el curso de la conversación: hechos previamente mencionados sobre el usuario, el tono de la comunicación, el contexto de las réplicas anteriores. El intento de mantener esto a través de RAG (recuperación de "hechos" individuales del historial) funcionó peor que simplemente pasar los últimos N mensajes al contexto: la conversación perdía cohesión, el modelo "olvidaba" el carácter de la interacción, que se componía del tono, no de hechos individuales. Para sistemas de diálogo, el contexto de ventana es una herramienta natural y correcta, no un compromiso.
Recomendación: si tu tarea es una fuente grande y unificada (contrato, libro, informe técnico) o el mantenimiento de un diálogo coherente — el contexto largo es más rápido y sencillo. Si tienes una base de datos dinámica con decenas de miles de documentos y un flujo de consultas hacia ella — RAG sigue siendo la elección correcta económica y arquitectónicamente.
Este es un argumento sobre el que casi nadie escribe en las comparaciones de RAG vs Long Context — y es, quizás, el más importante para el enterprise.
Imagina la base de conocimiento corporativa de una empresa: documentos de RR. HH., informes financieros de directores, contratos con clientes. Un gerente de ventas no debería ver las nóminas del departamento de RR. HH. Si subes toda la base de conocimiento a la ventana de contexto de un solo modelo — ¿cómo separas el acceso a nivel de una sola consulta?
Por qué es imposible hacerlo de forma segura a través de la ventana de contexto o el fine-tuning: ambos enfoques "hornean" el conocimiento en el prompt o en los pesos del modelo sin tener idea de quién está haciendo la pregunta. Cualquier intento de delimitar el acceso significaría mantener una instancia separada del modelo o un contexto separado para cada usuario — lo que destruye toda la economía que calculamos en la sección sobre la trampa de tokens.
RAG lo resuelve de forma natural, a nivel de arquitectura, no como un parche: el acceso se controla mediante metadatos en la base vectorial — Seguridad a Nivel de Fila (Row-Level Security). Cada fragmento está marcado con etiquetas de acceso (departamento, rol, cliente), y el modelo físicamente no recibe los fragmentos a los que el usuario no tiene derechos. No es un filtro de salida que se pueda eludir mediante inyección de prompts — es una restricción aún en la etapa de recuperación (retrieval), antes de que el texto llegue al contexto del modelo.
Conclusión práctica: para SaaS B2B que trabaja con documentos de varios clientes simultáneamente, la seguridad multitenant no es una característica opcional, sino la razón por la que RAG es la única arquitectura viable, independientemente del tamaño de la ventana de contexto.
Ejemplo con AskYourDocs: cuando diseñamos la arquitectura, nos enfrentamos precisamente a esta elección: mantener a todos los clientes en una base de datos compartida con aislamiento a través de tenant_id, o desplegar una base de datos separada (y a menudo una instancia separada) para cada cliente. No es una cuestión teórica de un libro de texto, sino una decisión que determina directamente cómo se ve toda la pila.
Arquitectura
Pros
Contras
Multitenant (una BD, tenant_id + RLS)
Infraestructura más barata — una instancia de PostgreSQL atiende a todos los clientes; una migración en lugar de N; más fácil de escalar a cientos de clientes pequeños
La seguridad se basa en que *cada* consulta filtre correctamente por tenant_id — una cláusula WHERE olvidada o un error en la política RLS significa una fuga de datos entre clientes; más difícil satisfacer a los clientes empresariales que contractualmente requieren infraestructura dedicada
Single-tenant (BD / instancia separada por cliente)
Aislamiento físico, no lógico — la fuga de datos entre clientes es arquitectónicamente imposible, incluso si hay un error en el código; más fácil responder a solicitudes GDPR (la eliminación/exportación de datos de un cliente es la eliminación de una BD, no la eliminación selectiva de filas); más fácil ofrecer despliegues autoalojados (self-hosted)
Infraestructura más cara — N clientes = N bases de datos en mantenimiento; las migraciones y actualizaciones deben aplicarse a cada instancia por separado; más difícil de escalar a un gran número de clientes pequeños
Elegimos single-tenant — y los factores decisivos fueron dos, que se derivan directamente de nuestra auditoría. En primer lugar, GDPR: cuando los datos de cada cliente residen físicamente en una base de datos separada, la respuesta a la solicitud "elimina todos nuestros datos" es eliminar una BD, no auditar el código para ver si todas las consultas filtraron correctamente por tenant_id en cada uno de los docenas de lugares de la base de código. En segundo lugar, algunos de nuestros clientes corporativos requieren despliegues autoalojados — sus documentos no deben abandonar su propia infraestructura, y la arquitectura single-tenant se adapta naturalmente a esto, sin capas adicionales de aislamiento.
Si no tienes tales restricciones — por ejemplo, estás construyendo un producto para cientos de clientes pequeños sin requisitos de cumplimiento estrictos — multitenant con tenant_id y Row-Level Security sigue siendo la elección económica correcta: el acceso se filtra por metadatos directamente en la consulta SQL de búsqueda vectorial, antes de que la recuperación comience a calcular la similitud. Simplemente vale la pena entender claramente que este ahorro de infraestructura es un compromiso consciente con la seguridad, no un bono gratuito.
¿De qué consta un buen pipeline RAG?
Todo lo anterior tiene sentido solo si el propio RAG está hecho correctamente. Un RAG deficiente — con chunking primitivo y un vector puro sin palabras clave — desacredita todo el enfoque y da argumentos a los partidarios de "simplemente cargarlo en el contexto". Tres componentes distinguen la calidad de producción del prototipo.
Estrategia de chunking: cortar por estructura, no por caracteres
El error más común es cortar el texto por un número fijo de caracteres, ignorando encabezados, tablas y límites de párrafos. Esto "corta en vivo": rompe la idea a mitad de una oración y destruye el contexto de un chunk. El enfoque correcto tiene en cuenta la estructura del documento. Un análisis detallado de siete estrategias con benchmarks se encuentra en el artículo Chunking en RAG 2026: 7 estrategias para producción.
Búsqueda Híbrida: vectores sin palabras clave son un signo de mal RAG
La búsqueda vectorial pura omite coincidencias exactas — números de pedido, códigos de error, términos exactos — porque la similitud semántica no garantiza la coincidencia léxica. La combinación de BM25 (palabra clave) y búsqueda vectorial cierra esta brecha. Lo analicé en detalle en el ejemplo de mi propio servicio RAG en el artículo Añadí BM25 a mi servicio RAG — y la búsqueda vectorial dejó de perder consultas exactas.
Reranking: una segunda verificación antes de mostrar a la LLM
La búsqueda vectorial devuelve candidatos rápidamente, pero no siempre con precisión. Un reranker — un modelo separado y más ligero (Cross-Encoder) — verifica los mejores resultados antes de pasarlos a la LLM y los ordena por relevancia real. En combinación con la búsqueda híbrida, esto da un aumento medible en la calidad: un análisis completo con cifras de +15–40% — en el artículo Búsqueda Híbrida y Reranking para RAG: +15-40% de calidad.
En resumen: omitir cualquiera de estos tres componentes convierte "RAG" en un empeoramiento costoso y lento de la calidad en comparación con el mismo contexto largo. RAG solo gana cuando se hace correctamente.
La mecánica del enfoque son dos pasos concretos, no una "decisión del modelo abstracto". Paso 1: la consulta y los chunks RAG (como en el RAG normal) se pasan al modelo, pero con una diferencia: el modelo recibe permiso explícito para negarse a responder si considera que la información en los chunks es insuficiente, en lugar de inventar una respuesta plausible. Paso 2: si el modelo se niega — solo entonces la consulta se redirige al contexto completo del documento, y el modelo responde teniendo todo el texto a la vista. Una consulta simple pasará el paso 1 y obtendrá una respuesta rápida y barata. Una consulta compleja "fallará" el paso 1, el modelo dirá honestamente "información insuficiente" — y solo entonces el sistema pagará por un paso más costoso a través del contexto completo.
Por qué funciona en la práctica: las preguntas fácticas simples ("¿cuál es la fecha de firma del contrato?") casi siempre pasan con éxito el paso 1 — RAG lo manejará más rápido y más barato, porque el hecho necesario suele estar en uno o dos chunks. Una pregunta compleja de varios pasos ("¿cómo cambiaron las condiciones del contrato entre tres versiones?") probablemente fallará el paso 1: la respuesta está dispersa por todo el documento, la recuperación extraerá solo una parte de la imagen, y el modelo — si está bien calibrado — lo reconocerá. La palabra "calibrado" aquí es clave: todo el enfoque se basa en la suposición de que el modelo evalúa honestamente su propia incertidumbre, en lugar de fingir confianza donde no la hay. No es una garantía incondicional, sino un mecanismo probabilístico que funciona mejor en modelos más potentes.
Para un sistema de producción, esto significa un patrón de ingeniería concreto: el primer paso es siempre barato (RAG), el segundo paso es una opción de respaldo más cara (contexto completo), que se activa solo para la minoría de consultas donde realmente se necesita. La mayoría del tráfico — hechos simples — nunca toca el camino costoso.
En la práctica, esto significa: la arquitectura de 2026 no es una elección de "RAG o contexto" al inicio del proyecto, sino un nivel de enrutamiento que decide esto para cada consulta por separado, y el precio de esta decisión es solo un paso adicional y barato del modelo a través de los chunks RAG antes de que reconozca "esto no es suficiente".
Pila híbrida 2026: conclusión
La arquitectura ideal hoy en día no es "o/o". Consta de tres capas: un modelo pequeño y rápido, afinado (fine-tuned) para un formato de respuesta específico (fine-tuning para el comportamiento); un pipeline RAG de alta calidad y pulido con búsqueda híbrida y reranker (capa de conocimiento); y un nivel de Auto-enrutamiento (Self-Route) que decide para cada consulta si la recuperación es suficiente o si se necesita contexto completo.
Ninguna de estas tres capas reemplaza a las otras. El fine-tuning sin RAG proporciona un tono consistente pero desactualizado. El RAG sin un buen chunking y búsqueda híbrida da una respuesta rápida pero imprecisa. El contexto largo sin RAG proporciona precisión en un solo documento, y un desastre financiero en miles de consultas a una gran base de datos.
Conclusión principal del artículo: el tamaño de la ventana de contexto de su modelo es una cifra de marketing en una diapositiva de presentación, no una medida de cuán bueno es su sistema de IA. Un millón de tokens no salvará un proyecto donde la recuperación devuelve fragmentos irrelevantes, los documentos no están estructurados o están duplicados, y se puede acceder a datos de terceros mediante un error trivial en una consulta SQL. Las verdaderas métricas de calidad son la precisión de la recuperación (si el sistema encuentra un fragmento realmente relevante, no solo uno similar en vector), la higiene de los datos (si los documentos están estructurados, actualizados, sin duplicados, que es lo que falla en el 80% de las implementaciones de RAG), y la arquitectura de seguridad que rodea todo esto (si es físicamente imposible que un cliente vea los datos de otro, independientemente de los errores en el código).
La ventana de contexto es solo una herramienta más en el conjunto, no un fin en sí misma. Un equipo que elige un modelo con el contexto más grande y considera que las cuestiones de arquitectura están resueltas, probablemente repetirá el camino descrito al principio de este artículo: primero la tentación de "simplemente meter todo en el prompt", luego la factura de tokens que no cuadra, y después, un doloroso regreso a la recuperación, chunking y RLS, solo que bajo la presión de un incidente de producción, y no como una elección arquitectónica consciente al inicio.
Preguntas frecuentes
¿Está RAG obsoleto debido a las largas ventanas de contexto?
No. Las ventanas de contexto resolvieron el problema del límite técnico de tokens, pero no resolvieron el problema del costo, la velocidad y la seguridad del acceso a los datos, y son precisamente estos tres factores los que determinan si RAG se puede utilizar en producción.
¿Qué es más barato: RAG o contexto largo?
RAG es órdenes de magnitud más barato para consultas frecuentes a una gran base de conocimiento; en nuestro cálculo, la diferencia fue de 333 veces. El contexto largo solo puede ser más barato para el análisis único de un documento.
¿Cuándo es mejor usar fine-tuning en lugar de RAG?
El fine-tuning es adecuado cuando se necesita cambiar el comportamiento del modelo: tono, formato, estilo de respuesta. Para hechos operativos que cambian más de una vez por semana, RAG es la única opción práctica.
¿Qué es "lost in the middle"?
Un efecto por el cual el modelo utiliza peor la información ubicada en el medio de un contexto largo en comparación con el principio o el final. RAG mitiga este problema al presentar solo fragmentos relevantes en lugar de todo el conjunto de texto.
¿Se pueden combinar RAG y fine-tuning?
Sí, y este es el patrón de producción más común de 2026: el fine-tuning se encarga del comportamiento y formato estables, RAG se encarga de los hechos actuales en el momento de la consulta.
¿Cómo resuelve RAG el problema del acceso a los datos en entornos empresariales?
A través de la Seguridad a Nivel de Fila (Row-Level Security) a nivel de metadatos de la base de datos vectorial: cada fragmento está marcado con etiquetas de acceso, y el usuario físicamente no recibe información a la que no tiene derecho, la restricción funciona incluso antes de que el texto entre en el contexto del modelo.
¿Qué es Self-Route en los sistemas RAG?
Un enfoque en el que el modelo decide por sí mismo para cada consulta específica si la recuperación (RAG) es suficiente o si se necesita el contexto completo del documento, basándose en la complejidad de la pregunta.
¿Por qué las implementaciones de RAG a menudo fallan?
Según Gartner, hasta el 80% de las implementaciones de RAG en empresas fallan, y la razón principal no es la arquitectura, sino la calidad de los datos que se indexan: duplicados, información obsoleta, falta de estructura.
