Retrieval-augmented generation (RAG) es el patrón donde una herramienta de AI busca en un conjunto de documentos antes de responder, y luego escribe su respuesta a partir de los pasajes que encontró en vez de a partir de lo que el modelo absorbió durante el entrenamiento. Entra una pregunta, un paso de búsqueda devuelve un puñado de pasajes que califica como relevantes, esos pasajes se pegan en el prompt del modelo, y el modelo responde sobre ellos. Le importa al comprador porque RAG es la maquinaria debajo de casi toda afirmación de un proveedor sobre estar “fundamentado”, “citar sus fuentes” o “entrenado con tus datos” — y cuál de esas tres quiere decir realmente el proveedor cambia lo que tienes que probar antes de firmar.
RAG no es entrenamiento. Tus documentos nunca entran en los pesos del modelo; se leen en el momento de la pregunta y se descartan después. Un proveedor que dice “el modelo aprende tus contratos” está describiendo RAG de forma imprecisa o está haciendo algo que merece una pregunta directa sobre dónde termina tu data. RAG tampoco arregla las alucinaciones, y no es una propiedad del modelo en absoluto — es una tubería envuelta alrededor de un modelo que por lo demás queda intacto. Dos productos que corren el modelo idéntico se comportan de forma completamente distinta según qué tan bien esa tubería encuentra las cosas.
Las dos mitades, y solo una está en la demo
Todo sistema RAG tiene una mitad de recuperación — indexar el corpus, cortarlo en fragmentos, buscar, ordenar lo que vuelve — y una mitad de generación, donde el modelo escribe prosa a partir de lo que la primera mitad le entregó.
Las demos de los proveedores ejercitan la mitad de generación. Esa es la parte que se ve impresionante, y no es donde empiezan los errores. Cuando el paso de recuperación falla, el modelo no sabe que falló: escribe una respuesta fluida y bien citada a partir de los tres pasajes equivocados y no reporta problema alguno. El modelo no puede decirte que el pasaje que necesitaba nunca le fue entregado. Ese solo hecho debería rediseñar la forma en que corres un piloto, porque significa que probar la calidad de las respuestas en preguntas que la herramienta contesta bien no te dice casi nada.
”Fundamentado” es una afirmación sobre la tubería, no sobre la exactitud
La evidencia pública más fuerte viene del derecho, donde las afirmaciones fueron más ruidosas y alguien las midió. El RegLab de Stanford corrió una evaluación preregistrada de las herramientas de investigación legal basadas en RAG que venden LexisNexis y Thomson Reuters — Lexis+ AI, Westlaw AI-Assisted Research y Ask Practical Law AI — y encontró que alucinan entre el 17% y el 33% de las veces. LexisNexis había promocionado citas enlazadas “libres de alucinaciones”; Thomson Reuters decía que sus herramientas evitan las alucinaciones apoyándose en contenido confiable. Ambas afirmaciones estaban sobredimensionadas. La lectura honesta no es que RAG fracasó: esas herramientas sí le ganaron a GPT-4 de propósito general en las mismas preguntas. La lectura es que la recuperación sobre un corpus curado baja la tasa de error y nunca la lleva a cero, así que “fundamentado” describe una arquitectura, no una garantía.
De ahí salen dos formas de falla, y no son igual de peligrosas. Una es una respuesta abiertamente equivocada, que un experto del dominio detecta. La otra es una respuesta mal fundamentada — el contenido está mal pero lleva una cita real adjunta, apuntando a un documento real que no dice lo que la respuesta afirma. Esa sobrevive a la revisión, porque la cita es exactamente la señal que un revisor apurado usa para decidir que la respuesta ya fue verificada.
Preguntas diagnósticas para un proveedor
Están ordenadas de modo que las dos primeras hagan la mayor parte del trabajo.
- Muéstrame una pregunta que la herramienta responde mal, y dime si la causa fue la recuperación o la generación. Un proveedor que nunca caracterizó sus propias fallas de recuperación no evaluó el sistema, solo la demo.
- ¿Una cita apunta a un pasaje o a un documento? Las citas a nivel de documento son imposibles de verificar a volumen real — nadie lee un MSA de 60 páginas para confirmar una frase. La cita a nivel de pasaje o de cláusula es lo que abarata la revisión lo suficiente como para que ocurra de verdad.
- ¿Qué hace cuando la respuesta no está en el corpus? Los dos comportamientos son “no tengo eso” y una caída silenciosa al conocimiento general del modelo base. El segundo es por donde entra la tontería con tono seguro, y rara vez aparece en una página de precios.
- ¿Los permisos se aplican en la recuperación o después de la generación? La respuesta correcta es en la recuperación: al modelo solo se le muestran documentos que el usuario que pregunta ya tiene derecho a ver. Glean construyó su indexación alrededor de la recuperación recortada por permisos exactamente por esto. Filtrar la respuesta después de que el modelo leyó un documento restringido no es control de acceso, es tachar con fuga.
- ¿Cuánto tiempo pasa desde que cambia un documento hasta que la versión nueva es la que responde? Minutos, cada hora o cada noche son todas defendibles. No saberlo, no.
- ¿Puedo ver lo que se recuperó, no solo lo que se escribió? Sin ese panel, no puedes depurar una respuesta equivocada, y su equipo de soporte tampoco.
¿Una ventana de contexto más grande vuelve innecesario a RAG?
No, y los proveedores que venden ventanas de contexto de un millón de tokens no afirman que sí. Tres cosas mantienen la recuperación dentro de la arquitectura: un corpus de decenas de miles de documentos no cabe en ninguna ventana de contexto del mercado; el costo de entrada escala con los tokens, así que empujar toda una base de conocimiento por el modelo en cada pregunta se cobra por pregunta; y un corpus que cambia cada hora sale más barato reindexarlo que reenviarlo.
Lo que cambió hacia 2026 es la mezcla. El patrón que funciona es recuperar y luego razonar — traer una porción generosa de material relevante en vez de los tres fragmentos más ajustados posibles, y dejar que un modelo de contexto largo trabaje sobre todo eso. Eso relaja la precisión exigida al paso de recuperación sin eliminarlo. Trata cualquier pitch construido sobre “nuestra ventana de contexto es tan grande que no necesitamos recuperación” como una afirmación sobre el tamaño de tu corpus que no terminaron de pensar.
Errores comunes
Correr el piloto sobre el corpus del proveedor. Una demo afinada durante meses sobre un conjunto de documentos de muestra te dice qué tan buena es su muestra.
Protección: Aporta tus propios documentos y escribe entre 30 y 50 preguntas reales antes de la primera demo. Incluye 5 cuyas respuestas estén deliberadamente ausentes del corpus, y califica el comportamiento de rechazo en esas como un ítem aprobado/reprobado.
Leer una cita como verificación. La cita es justamente lo que hace que una respuesta mal fundamentada parezca revisada.
Protección: Durante el piloto, abre el pasaje citado sobre una muestra fija — 20 respuestas por semana alcanzan — y sigue la tasa de mal fundamentadas por separado de la tasa de equivocadas. Una herramienta con 5% de equivocadas y 15% de mal fundamentadas es peor para tu equipo que una con 15% de equivocadas y 2% de mal fundamentadas.
Asumir que los permisos se heredan de los sistemas de origen. La indexación por conectores copia contenido; si copió también la lista de control de acceso es una pregunta aparte con una respuesta aparte por cada conector.
Protección: Durante el piloto, corre las mismas tres consultas sensibles como dos usuarios de niveles de permiso distintos y compara los resultados. Hazlo por conector, no una sola vez para el producto.
Dejar que el corpus se pudra después del arranque. La calidad de recuperación decae a medida que se acumulan políticas superadas, contratos vencidos y playbooks viejos, porque el paso de búsqueda no tiene forma de saber cuál versión es la vigente.
Protección: Nombra a un responsable del corpus antes del lanzamiento y dale un mandato de borrado, no solo de carga. Vuelve a probar cada trimestre con un documento editado esa misma mañana y con un documento que debería haber sido eliminado.
Relacionado
- El MCP server explicado — la otra forma en que una herramienta de AI llega a tus sistemas: llamarlos en vivo en vez de buscar en un índice copiado
- AI agent para ops — dónde se ubica la recuperación dentro de un agente que además ejecuta acciones, y las pruebas de autonomía que la acompañan
- AI agent vs RPA — la decisión de compra vecina, y por qué las fallas de agentes son invisibles para el monitoreo de uptime
- Glean y Hebbia — búsqueda empresarial horizontal frente a extracción estructurada sobre un corpus grande, dos respuestas distintas al mismo problema de recuperación
- Gestión del Conocimiento Legal — la disciplina de propiedad del corpus que decide si algo de esto funciona en un equipo legal