Recuperar un documento responde a «¿qué está escrito?». Un agente que
decide necesita más: saber qué ha pasado, qué se ha decidido, y por qué.
La recuperación es el primer paso, no el conocimiento.
Introducción
Ayer cerramos el knowledge graph como la estructura para el conocimiento
relacional. Y mencionamos, de pasada, su complemento: el RAG, el mecanismo
que recupera conocimiento de documentos. Hoy le toca a él —y con una
corrección importante que se ha colado en todas las conversaciones de IA
empresarial: el RAG no es memoria, y no es conocimiento. Es recuperación.
Y confundirlos explica por qué tantos sistemas «con RAG» fallan en
producción: resolvieron bien la recuperación y no se dieron cuenta de que la
recuperación era la menor de sus necesidades.
El problema
Una aseguradora revisa siniestros con un asistente de IA. El asistente
tiene un RAG impecable: todo el corpus de pólizas, condiciones generales y
procedimientos está indexado, la recuperación es rápida y las citas son
correctas. En la demo, responde bien a «¿qué cubre la póliza de incendio?».
En producción, se cae en las decisiones reales:
- «¿Deberíamos pagar este siniestro?» — El asistente recupera la
condición general que dice que el robo está cubierto «bajo ciertas
condiciones». No sabe que esta póliza concreta tiene un endoso que
excluye el robo parcial, ni que hay un siniestro previo del mismo tipo en
espera. - «¿Es coherente este informe de peritaje?» — Recupera el procedimiento
de peritación, pero no sabe que el perito que firmó está en un proceso
de sanción por un informe anterior. - «¿Qué decidimos en el caso similar de 2024?» — No tiene forma de
saberlo. El RAG recupera documentos, no decisiones pasadas.
El patrón es el mismo: el RAG trae el texto, pero la decisión necesita el
texto + el estado concreto + el historial + las reglas aplicadas. Y
esas cuatro últimas cosas no son documentos: son estado, memoria y
razonamiento.
El concepto
RAG (Retrieval-Augmented Generation) es un mecanismo de recuperación:
antes de generar una respuesta, el sistema recupera información relevante
de una fuente externa (documentos, bases de datos, grafos) y la inyecta en
el contexto del modelo para fundamentar la respuesta.
Desglosemos la cadena, porque en ella están los puntos débiles:
- Indexación. Convertir el corpus en algo recuperable (chunks +
embeddings, o estructura). - Retrieval. Encontrar lo relevante. Variantes:
– Semantic search (similitud de embeddings): bueno para «textos parecidos».
– Keyword/BM25: bueno para términos exactos.
– Hybrid search: combina ambos; es el estándar de facto hoy.
– Graph retrieval: recuperar recorriendo el grafo de conocimiento
(lo que vimos ayer).
– Contextual retrieval: enriquecer cada chunk con contexto antes de
indexar, para que la similitud sea más precisa. - Reranking. Reordenar los resultados recuperados con un modelo de
relevancia antes de inyectarlos. - Inyección en contexto. Poner los fragmentos en la ventana del modelo.
- Generación. El modelo responde sobre ese contexto.
Lo que el RAG no hace:
- No sabe qué ha pasado: recupera lo escrito, no el estado actual.
- No recuerda: no conserva decisiones, conversaciones ni experiencias a lo
largo del tiempo (eso es memoria, mañana). - No contextualiza la decisión: no sabe quién pregunta, qué permisos
tiene, en qué momento del proceso está la tarea (eso es contexto). - No razona sobre reglas: no verifica que la respuesta cumpla las
restricciones del dominio (eso es razonamiento, día 14). - No actúa: no ejecuta nada; solo produce texto.
La pregunta central que este artículo fija para el resto de la serie:
¿Estamos recuperando documentos o recuperando el conocimiento necesario
para tomar una decisión?
Para la primera, el RAG basta. Para la segunda, el RAG es una pieza —una
pieza importante, pero una pieza— de una infraestructura más grande.
Arquitectura
En el diagrama de la serie, el RAG es el mecanismo de recolección junto
al conocimiento:
KNOWLEDGE
↑
┌───────────────────────────────┐
│ KNOWLEDGE GRAPH + RAG │ ← hoy: la recuperación
│ (estructurado) (prosa) │ de ambos mundos
└───────────────────────────────┘
↑
ONTOLOGY + ENTITY RESOLUTION
↑
SEMANTICS / DATA
El RAG no es una capa aparte: es el proceso por el que el conocimiento
(prosa y estructura) llega al agente en el momento de la decisión. Y ese
proceso es el que hoy llamamos, cada vez más, retrieval en sentido
amplio: no «buscar en un vector store», sino «conseguir, con la fuente
correcta, lo que la decisión necesita».
Caso de uso
La aseguradora, con su revisión de siniestros. Descomponemos:
- Problema. El ajustador necesita una recomendación fundamentada sobre
un siniestro complejo (robo parcial con endoso excluyente y siniestro
previo), y hoy tarda días en juntar póliza, endosos, historial y
criterio previo. - Decisión. Recomendar pagar, rechazar o escalar el siniestro, con la
justificación. - Conocimiento necesario. Qué cubre la póliza base; qué excluye el
endoso; si hay siniestro previo del mismo tipo; qué criterio se aplicó en
casos similares; qué umbral de importe obliga a escalar. - Datos. Póliza, endosos, condiciones generales (PDF), el informe de
peritaje, el historial de siniestros del asegurado. - Relaciones. Póliza → tiene → endoso; endoso → excluye → cobertura;
asegurado → tiene → siniestros previos; siniestro → tipo → criterio
histórico. - Contexto. El siniestro es de importe alto (sobre el umbral de
escalamiento); el asegurado es un cliente estratégico; hay una
investigación de fraude abierta sobre el tipo de robo. - Memoria. En 2024 un siniestro similar se resolvió pagando la mitad
por la cláusula de depreciación; la decisión y su justificación están en
el historial de casos. - Razonamiento. Aplicar: la cobertura base cubre el robo, PERO el
endoso excluye el robo parcial → el siniestro cae en la exclusión;
cruzar con el siniestro previo (posible patrón); cruzar con el criterio
histórico (depreciación). - Acción. Recomendar «rechazar la cobertura del robo parcial por
endoso; pagar la parte no excluida con depreciación según criterio
histórico; escalar por importe» con la cadena de justificación. - Infraestructura. RAG sobre póliza+endosos+condiciones (prosa) +
grafo de relaciones póliza→endoso→cobertura (estructurado) + memoria del
caso de 2024 + contexto de importe e investigación + razonamiento que
aplica las reglas. El RAG trajo el texto; las otras capas trajeron la
decisión.
El caso muestra la regla de la serie: la tecnología (RAG, grafo, memoria)
aparece como consecuencia de la necesidad (recomendar una decisión
fundamentada), no como punto de partida.
Trade-offs
- Coste. Un RAG decente (hybrid + reranking + contextual) cuesta más
que un vector store naïve. Y cada mejora de recuperación es un costo
recurrente de operación. - Complejidad. La cadena retrieval→rerank→inject tiene muchos parámetros
(tamaño de chunk, número de resultados, umbral de relevancia) que hay que
sintonizar por dominio. No hay configuración universal. - Latencia. La recuperación híbrida + reranking añade pasos a la
respuesta. Para decisiones en tiempo real hay que precomputar o
cachear. - Calidad de la fuente. El RAG recupera lo que hay; si el corpus tiene
versiones obsoletas o contradicciones, las recupera también. La
desambiguación de versiones es un problema de gobernanza (día 18), no de
recuperación. - Seguridad. Recuperar documentos sensibles exige que los permisos se
apliquen en la recuperación, no solo en la aplicación. Un RAG que no
filtra por permisos es una fuga de datos con cara de asistente. - Limitación honesta: el RAG no resuelve el problema de la
contradicción. Si dos documentos dicen cosas distintas, recuperar ambos
no resuelve cuál es cierto: eso requiere gobernanza (frescura, autoridad
de la fuente) y, a veces, intervención humana.
Implicación para la empresa
Para el CDO, el RAG es la puerta de entrada al conocimiento en prosa, pero
no es el conocimiento: es el mecanismo que lo trae. Y como mecanismo, tiene
un dueño (el equipo de IA) y métricas (precisión de recuperación,
relevancia) que hay que medir.
Para el equipo de IA, la lección es de disciplina: no confundir «el RAG
funciona» (recupera bien) con «el agente decide bien» (aplica bien). Son
métricas distintas, y la segunda es la que vale para el negocio.
Para la alta dirección, el mensaje es de expectativas: un asistente «con
RAG» que responde bien a preguntas sobre documentos no es, todavía, un
sistema que toma decisiones. La distancia entre los dos es el resto de esta
serie.
Conclusión
El RAG es recuperación, no memoria y no conocimiento: trae el texto que la
decisión necesita, pero la decisión además necesita el estado, el historial,
el contexto y las reglas. Hoy hemos desmontado la cadena de recuperación
(indexación, retrieval, reranking, inyección, generación) y hemos fijado la
pregunta que guía el resto de la serie: ¿recuperamos documentos o
recuperamos el conocimiento necesario para decidir?
Y la respuesta apunta a un siguiente paso que hemos ido mencionando: el
agente no solo necesita lo que está escrito, necesita lo que ha
pasado. Y «lo que ha pasado» no es un documento: es memoria.
Siguiente artículo
Mañana: La memoria de un agente empresarial: qué debe recordar una IA.
Veremos las tipologías de memoria (de trabajo, episódica, semántica,
procedural y organizacional) y por qué un agente que no recuerda es un
agente que empieza de cero en cada conversación.
Fuentes
- Lewis, P. et al. (2020). «Retrieval-Augmented Generation for
Knowledge-Intensive NLP Tasks». — Origen del concepto RAG. - Anthropic (2024). «Introducing Contextual Retrieval». — Recuperación
contextual e híbrida; reduce hasta un 67 % las recuperaciones fallidas
(dato reportado por Anthropic en su documentación). - Microsoft Research (2024). GraphRAG. — Retrieval sobre grafos de
conocimiento.
