flowchart LR
d["Documentos"] --> ch["Trocear"]
ch --> emb["Vectorizar"]
emb --> idx[("Índice")]
q["Pregunta"] --> emb2["Vectorizar"]
emb2 --> idx
idx --> top["Fragmentos<br/>relevantes"]
top --> ctx["Contexto"]
q --> ctx
ctx --> m["Modelo"]
classDef externo fill:#ececf0,stroke:#868d9c,stroke-width:1.5px,color:#2b2f3a
classDef contexto fill:#d5e6f5,stroke:#3d7cb0,stroke-width:1.5px,color:#12354e
classDef modelo fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
class d,q externo
class ch,emb,emb2,idx,top,ctx contexto
class m modelo
9 Recuperación
Si el modelo no puede saber lo que hay en vuestros documentos, la solución evidente es buscarlo y metérselo en el contexto. Eso es RAG (retrieval augmented generation), formulado ya en 2020 (Lewis et al. 2020) y convertido desde entonces en el patrón más desplegado del sector.
La idea cabe en una frase: antes de responder, busca. Toda la dificultad está en el “busca”.
9.1 El pipeline mínimo
Fuera de línea se trocean los documentos, se convierte cada trozo en un vector con un modelo de embeddings y se guardan en un índice. En línea se vectoriza la pregunta, se buscan los trozos más cercanos y se pegan al prompt.
Montar esto lleva una tarde con cualquier librería. Y ahí está la trampa: la demo siempre funciona. Los problemas aparecen con documentos reales, preguntas reales y usuarios que preguntan cosas que a nadie se le habían ocurrido.
9.2 Dónde falla de verdad
Merece la pena recorrer los fallos por orden de frecuencia, porque el esfuerzo suele invertirse justo al revés.
El troceado. Es la decisión más determinante y la que se toma con más ligereza. Cortar cada 500 caracteres parte tablas por la mitad, separa un titular de su párrafo y deja fragmentos que empiezan con “esto implica que”. Un fragmento debe ser autocontenido: si al leerlo suelto no se entiende, tampoco lo entenderá el modelo. Trocear respetando la estructura del documento (por secciones, por artículos, por celdas de tabla) y arrastrar en cada fragmento una cabecera con su procedencia arregla más problemas que cualquier otra cosa.
Lo semántico no es todo. La búsqueda vectorial encuentra parecidos de significado y es mala con lo literal: referencias de producto, códigos de error, nombres propios raros. Preguntar por “FRA-2026-0087” en un índice puramente vectorial es una lotería. La respuesta estándar es la búsqueda híbrida: combinar el índice vectorial con uno léxico clásico (BM25) y fusionar ambos rankings. Es probablemente la mejor relación entre esfuerzo y mejora de todo el pipeline.
Recuperar mucho. Traer veinte fragmentos “por si acaso” mete diecisiete distractores. Mejor recuperar generosamente y luego reordenar con un modelo específico (reranker), que compara pregunta y fragmento de forma más costosa pero mucho más precisa, para quedarse con los tres o cuatro mejores.
La pregunta del usuario no es una buena consulta. “¿Y eso cómo afecta a lo del año pasado?” no recupera nada útil. Reescribir la consulta con el modelo antes de buscar, resolviendo referencias y expandiendo términos, es barato y rinde.
ImportanteRAG no elimina la alucinación, la acota
Es la expectativa que hay que ajustar cuanto antes. Con los fragmentos correctos delante, el modelo se equivoca mucho menos. Pero si la recuperación falla y le llega contexto irrelevante, el modelo responderá igualmente, y ahora con la autoridad que le da citar un documento.
Dos consecuencias de diseño: hay que instruir explícitamente al modelo para que diga que no lo sabe cuando el contexto no baste (y probar que lo hace), y hay que mostrar siempre la fuente, porque la única defensa real es que la persona pueda comprobarlo.
9.3 Medir la recuperación aparte
Un fallo de un sistema RAG puede estar en la recuperación (no se trajo el fragmento correcto) o en la generación (se trajo y el modelo lo ignoró o lo malinterpretó). Son problemas distintos con soluciones distintas y hay que medirlos por separado.
Para la recuperación basta con lo de siempre en recuperación de información: un conjunto de preguntas con los fragmentos que deberían salir, y medir cuántas veces salen entre los primeros. Es un trabajo tedioso de un par de días que evita meses de conjeturas. Si el fragmento correcto no está entre los recuperados, ningún modelo, por bueno que sea, va a acertar.
| Síntoma | Dónde mirar primero |
|---|---|
| Responde algo de otro documento | Troceado y ranking |
| No encuentra un código o referencia | Falta búsqueda léxica |
| Trae lo correcto pero responde mal | Prompt y orden del contexto |
| Contradice el documento | Fragmento partido por la mitad |
| Va bien en la demo y mal en producción | Las preguntas reales no se parecen a las de prueba |
TipHay un cuaderno que hace exactamente esto
El cuaderno de este capítulo monta el sistema completo sobre la normativa de la secretaría y lo mide con diez preguntas escritas como las escribiría un alumno. Los números que salen son elocuentes: la búsqueda vectorial acierta 6 de 10, la léxica otras 6, y la combinación de ambas 8. Es la misma mejora de la que habla la sección siguiente, pero medida en lugar de afirmada.
De propina enseña dos cosas que cuesta creerse sin verlas. Que al preguntar por el artículo 21 la búsqueda vectorial devuelve el artículo 1. Y que el troceado, sobre el que se escribe muchísimo, apenas mueve la aguja comparado con la búsqueda híbrida, que son cinco líneas de código.
9.4 Las variantes que importan
Sobre el esquema básico hay una fauna considerable de siglas. Tres merecen atención por resolver problemas que el pipeline simple no resuelve:
RAG agéntico. En lugar de recuperar una vez y responder, el modelo decide si buscar, qué buscar, mira lo que ha traído y vuelve a buscar si no le vale. Es la convergencia de este capítulo con la parte de agentes: la recuperación se convierte en una herramienta más. Es la tendencia dominante en 2026 y funciona notablemente mejor en preguntas que requieren cruzar varias fuentes, a cambio de más latencia y más coste.
GraphRAG. Construye un grafo de entidades y relaciones a partir del corpus y navega por él en la recuperación (Edge et al. 2024). Su ventaja se nota en preguntas globales (“cuáles son los temas recurrentes en estas mil reclamaciones”) que la búsqueda por fragmentos no puede responder por construcción, porque la respuesta no está en ningún fragmento. Es caro de construir y de mantener, así que se justifica cuando ese tipo de pregunta es el caso de uso principal.
Contexto largo en lugar de recuperación. Con ventanas de un millón de tokens, si el corpus es pequeño y estable (un manual de producto, una normativa interna), cabe entero y se evita todo el pipeline. Es una opción legítima y a menudo la correcta.
La forma sensata de ver el reparto en 2026: el contexto largo se ha quedado con los corpus pequeños y estables; RAG conserva los grandes, cambiantes y los que exigen citar la fuente.
9.5 La memoria como caso particular
Una conversación larga tiene exactamente el mismo problema: no cabe entera y no todo lo dicho es pertinente ahora. Las estrategias son las de siempre, y suelen combinarse:
- Ventana deslizante: conservar los últimos turnos. Simple y olvida cosas importantes.
- Resumen progresivo: comprimir lo viejo en un resumen que viaja siempre. Barato y pierde detalle.
- Memoria recuperable: guardar los hechos relevantes en un índice y traerlos cuando hagan falta. Es RAG sobre la propia conversación.
En un agente esto deja de ser opcional: cada llamada a una herramienta devuelve texto que se acumula en el contexto, y sin una política de compresión el bucle se estrella contra el límite en pocas vueltas.
AdvertenciaLos permisos no se heredan solos
Un índice vectorial construido volcando “todo el SharePoint” es una fuga de datos esperando a ocurrir: el índice no conserva quién podía ver qué, así que cualquiera con acceso al chat puede acabar leyendo la carpeta de recursos humanos por interpuesta persona.
El filtrado por permisos tiene que aplicarse en la consulta al índice, con los metadatos de cada fragmento y la identidad de quien pregunta. Filtrar después, o pedírselo al modelo en el prompt, no es un control de acceso. Volveremos sobre ello en seguridad.
9.6 El cuaderno
Es el más largo del manual y el que más se parece a un problema real. Su gracia no es montar un RAG, que se hace en veinte líneas, sino medirlo: al final hay una tabla con qué preguntas acierta cada tipo de búsqueda, y en ella se ve que la vectorial y la léxica fallan en cosas distintas y que combinarlas las arregla casi todas. También se ve, sin adornos, que quedan preguntas que no acierta ninguna.
Por el camino guarda los vectores en un índice que es solo un fichero, sin servidor ni cuenta que crear, y se detiene en algo que casi nunca se cuenta: que con los vectores sin normalizar el coseno y el producto escalar ordenan distinto, y uno de los dos se equivoca.
Hasta aquí, el modelo lee. En la siguiente parte empieza a actuar: los agentes.