Tus datos: RAG y recuperación
El modelo no sabe nada de tus clientes. Y no hace falta que lo aprenda: hace falta que lo tenga delante.
El cliente 118 cambió de régimen en marzo
El sistema de borradores de Marta funciona y a la vez tiene un techo evidente: no sabe absolutamente nada de los 180 clientes del despacho. Cuando el cliente 118 escribe preguntando por su próxima liquidación, el modelo no tiene forma de saber que en marzo cambió de régimen, que arrastra un aplazamiento de 2.400 € y que el año pasado presentó fuera de plazo. La ficha que Marta pega a mano en cada correo tapa un poco el agujero, pero alguien tiene que pegarla, y solo cabe lo que ella recuerde que es relevante.
Hay tres formas de que un modelo hable de lo tuyo y dos son malas ideas:
- Reentrenarlo con tus documentos. Caro, lento, y sobre todo inútil para datos que cambian: si el cliente 118 cambia de régimen otra vez en junio, el modelo seguiría con lo de marzo hasta el siguiente entrenamiento. Los hechos no se meten en los pesos.
- Pegárselo todo en el contexto. Los 4.200 documentos del archivo no caben, y si cupieran costarían una fortuna por consulta y el modelo se perdería en el medio, como vimos en el módulo 1.
- Buscar lo relevante y ponérselo delante. Esta es la buena, se llama generación aumentada por recuperación —RAG, por sus siglas en inglés— y es, con diferencia, la arquitectura más usada en aplicaciones empresariales de IA.
La idea cabe en una frase: convertir una pregunta abierta en una pregunta de comprensión lectora. El modelo deja de tener que saber la respuesta y pasa a tener que encontrarla en unos párrafos que le has puesto delante. Es una tarea muchísimo más fácil, muchísimo más verificable, y ahí es donde este máster empieza a ser útil de verdad.
📋 Guía docente del módulo
Objetivos
- Describir el flujo completo de una arquitectura de recuperación: troceado, representación vectorial, indexación, recuperación, montaje del contexto y generación.
- Comprender qué es un embedding y cómo se mide la similitud entre textos.
- Identificar los cuatro puntos donde falla un sistema de recuperación y qué contramedida corresponde a cada uno.
- Calcular precisión y exhaustividad de un recuperador y elegir el número de fragmentos que se pasan al modelo.
- Decidir entre recuperación y ajuste fino según la naturaleza de lo que se quiere aportar.
Resultados de aprendizaje
- RA1. Estimar el número de fragmentos y el coste de indexar un archivo documental dado.
- RA2. Calcular precisión y exhaustividad a partir de fragmentos recuperados y relevantes, e interpretar el equilibrio entre ambas.
- RA3. Justificar la elección de k comparando el coste de contexto adicional con la reducción de errores.
- RA4. Diseñar el control de acceso de un índice documental con varios clientes, y explicar por qué filtrar después de recuperar es insuficiente.
- RA5. Clasificar un requisito de negocio en "va al contexto" o "va a los pesos" y defender la clasificación.
Bibliografía de referencia
- Lewis, P. et al.: "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS, 2020 — el artículo que da nombre a la arquitectura.
- Karpukhin, V. et al.: "Dense Passage Retrieval for Open-Domain Question Answering", EMNLP, 2020 — recuperación por vectores frente a búsqueda por palabras.
- Robertson, S. y Zaragoza, H.: "The Probabilistic Relevance Framework: BM25 and Beyond", 2009 — la búsqueda léxica clásica, que sigue ganando en más casos de los que se admite.
- Liu, N. F. et al.: "Lost in the Middle: How Language Models Use Long Contexts", TACL, 2024 — por qué meterlo todo en un contexto enorme no sustituye a recuperar bien.
- Manning, C., Raghavan, P. y Schütze, H.: Introduction to Information Retrieval, Cambridge University Press, 2008 — el manual de recuperación de información, gratuito y anterior a toda esta moda.
Carga de trabajo estimada
| Actividad | Horas |
|---|---|
| Lectura y estudio del material | 6 |
| Experimentación con el simulador | 2 |
| Ejercicios (resueltos y por cuenta propia) | 5 |
| Evaluación (quiz de módulo y repaso) | 2 |
| Total | 15 |
El flujo, paso a paso, con los números del despacho
| Paso | Qué pasa | En Bermejo & Asociados |
|---|---|---|
| 1. Trocear | Los documentos se parten en fragmentos manejables | 4.200 documentos → 18.000 fragmentos de unos 500 tokens |
| 2. Representar | Cada fragmento se convierte en un vector que codifica su significado | 18.000 vectores, calculados una sola vez |
| 3. Indexar | Los vectores se guardan en una base de datos que busca por proximidad | Un índice de unos 9 millones de tokens procesados |
| 4. Recuperar | La pregunta se convierte en vector y se buscan los fragmentos más cercanos | k = 6 fragmentos por consulta |
| 5. Montar | Esos fragmentos se pegan al prompt como material de consulta | +3.000 tokens de contexto por correo |
| 6. Generar y citar | El modelo responde y señala de qué fragmento sale cada afirmación | Cada cifra del borrador trae su fragmento de origen |
El paso 6 es el que convierte esto en una herramienta profesional y el que más gente se salta. Sin la obligación de citar, has mejorado la respuesta pero sigues sin poder comprobarla en menos tiempo del que costaría escribirla. Con la cita, la revisión pasa de "leer y juzgar" a "cotejar dos textos", que es una tarea mecánica que hace cualquiera en segundos. Ahí es donde bajan los 2,2 minutos del módulo anterior.
Embeddings: un mapa donde lo que significa parecido cae cerca
Un embedding es una lista de números —cientos o miles— que representa un texto. La propiedad que lo hace útil: los textos que significan cosas parecidas producen vectores que apuntan en direcciones parecidas, aunque no compartan ni una palabra.
Imagínalo como un mapa de muchísimas dimensiones donde cada fragmento del archivo es un punto. "Solicitud de aplazamiento de deuda tributaria" y "petición para pagar a plazos lo que debemos a Hacienda" caen casi encima, pese a no tener léxico común. Esa es exactamente la limitación que la búsqueda por palabras nunca resolvió.
La proximidad se mide con la similitud coseno: el coseno del ángulo entre los dos vectores. Vale 1 si apuntan igual, 0 si son perpendiculares y −1 si son opuestos. Buscar consiste en calcular la pregunta como vector y devolver los k puntos más cercanos.
Lo que los embeddings no hacen, y conviene saberlo
- No entienden la negación. "El gasto es deducible" y "el gasto no es deducible" son vecinos incómodamente cercanos en ese mapa. Es un fallo conocido y no está resuelto.
- Se les dan mal los identificadores. Buscar un NIF concreto o el número de expediente 2024/1187 por similitud semántica es la peor forma posible de buscar. Eso se busca por texto exacto.
- Dependen del modelo con que se calcularon. Si cambias de modelo de embeddings, hay que reindexar los 18.000 fragmentos: los vectores viejos y los nuevos viven en mapas distintos.
De las dos primeras limitaciones sale la práctica estándar del sector: búsqueda híbrida. Se combina el resultado de la búsqueda semántica con el de una búsqueda léxica clásica —BM25, un algoritmo de 1994 que sigue siendo excelente— y se fusionan. La léxica clava los identificadores y las citas exactas; la semántica clava el parecido de sentido. Casi siempre, las dos juntas ganan a cualquiera de las dos por separado, y la que sobra en las demostraciones bonitas es la léxica.
Los cuatro puntos donde se rompe un RAG
Cuando alguien dice "hemos probado RAG y responde mal", en más del 90% de los casos el problema no está donde cree. Estos son los cuatro sospechosos, en orden de frecuencia:
| Punto | Síntoma | Contramedida |
|---|---|---|
| 1. Troceado | La respuesta está partida por la mitad: el importe en un fragmento y a qué se refiere en otro | Trocear por estructura (cláusula, apartado, fila) y no por número de caracteres; solapar los fragmentos un 10-15% |
| 2. Recuperación | El fragmento correcto ni siquiera aparece entre los candidatos | Búsqueda híbrida, reescribir la pregunta antes de buscar, subir k |
| 3. Ordenación | El fragmento correcto está el decimoséptimo de veinte y no entra en el contexto | Recuperar muchos y reordenar con un modelo específico que compara pregunta y fragmento uno a uno |
| 4. Generación | Tenía el fragmento correcto delante y respondió otra cosa | Obligar a citar literalmente; instruir que si la respuesta no está en los fragmentos, se diga |
Diagnosticarlo es sorprendentemente fácil y casi nadie lo hace: coge veinte preguntas reales, anota a mano qué fragmento contiene la respuesta y comprueba en cuántas ese fragmento estaba entre los recuperados. Si estaba en 18 de 20, tu recuperador va bien y el problema está en el paso 4. Si estaba en 9, no toques el prompt: no hay prompt que arregle un fragmento que no llegó.
El troceado es el paso menos glamuroso y el que más resultados da. Partir un documento cada 500 tokens a ciegas garantiza cortar tablas por la mitad y separar un "no" de aquello que niega. Media jornada dedicada a trocear respetando la estructura del documento suele rendir más que semanas cambiando de modelo.
El modelo formal: precisión, exhaustividad y la elección de k
Dos métricas de toda la vida, tomadas de la recuperación de información, y que aquí deciden el coste:
- Precisión = fragmentos relevantes recuperados ÷ fragmentos recuperados. De lo que le he dado al modelo, ¿cuánto servía?
- Exhaustividad (recall) = fragmentos relevantes recuperados ÷ fragmentos relevantes que existen. De lo que servía, ¿cuánto le he dado?
Se mueven en direcciones contrarias con k, el número de fragmentos que recuperas. Con k = 2 la precisión es alta y te dejas cosas fuera; con k = 30 no te dejas nada y le has dado al modelo veintiocho párrafos de ruido en los que perderse.
| k | Exhaustividad | Precisión | Tokens de contexto | Coste por consulta |
|---|---|---|---|---|
| 2 | 33% | 67% | 1.000 | 0,0030 € |
| 6 | 70% | 47% | 3.000 | 0,0090 € |
| 12 | 91% | 30% | 6.000 | 0,0180 € |
| 20 | 98% | 20% | 10.000 | 0,0300 € |
La métrica que de verdad decide es la exhaustividad, y por una razón asimétrica: si el fragmento correcto no llega, no hay nada que el modelo pueda hacer — el error es seguro. Si llegan cinco fragmentos irrelevantes junto al bueno, un modelo decente los ignora. El coste de un falso negativo es catastrófico y el de un falso positivo es unos céntimos. Ante la duda, sube k.
Con dos matices que evitan que eso se convierta en una regla estúpida: subir k tiene rendimientos decrecientes claros (de 12 a 20 ganas 7 puntos de exhaustividad y pagas un 67% más), y a partir de cierto ruido los modelos sí se despistan. El punto razonable suele estar donde la curva se dobla — en la tabla, entre 6 y 12. Y si tienes un reordenador, la respuesta correcta es recuperar 30 y pasar los 8 mejores: te quedas con la exhaustividad de 30 y el coste de contexto de 8.
Un aviso sobre el vocabulario: estas dos métricas son las mismas que en cualquier prueba diagnóstica, y arrastran la misma confusión de siempre. Si te lías, quédate con la versión de andar por casa: exhaustividad es "no se me escapa nada" y precisión es "no me traigo basura".
Los datos van al contexto; el comportamiento, a los pesos
La pregunta "¿RAG o ajuste fino?" está mal planteada, porque resuelven cosas distintas. La regla que sirve:
| Lo que quieres aportar | Herramienta | Ejemplo del despacho |
|---|---|---|
| Hechos que cambian | Recuperación | El régimen del cliente 118, el aplazamiento vigente, la última liquidación |
| Documentos privados y numerosos | Recuperación | Los 4.200 expedientes del archivo |
| Un formato de salida muy específico | Ajuste fino (o ejemplos) | La estructura exacta de las fichas internas del despacho |
| Un estilo o un criterio consistente | Ajuste fino | La manera de escribir de Bermejo & Asociados en 3.000 correos anteriores |
| Una tarea muy repetitiva y acotada, con volumen alto | Ajuste fino de un modelo pequeño | Clasificar las 320 facturas mensuales, si fueran 320.000 |
En una organización pequeña, la respuesta casi siempre es recuperación más ejemplos en el prompt. El ajuste fino exige cientos o miles de ejemplos etiquetados, hay que rehacerlo cuando cambia el modelo base y solo se paga a sí mismo con volumen grande o con un requisito de formato que los ejemplos no consiguen. Marta no va a necesitarlo, y decirlo así ahorra reuniones.
Y un caso donde no hace falta nada de esto, que también conviene decir: si tus documentos son diez y caben en el contexto, mételos y ya está. RAG es una respuesta a la escala y a la privacidad, no un requisito de calidad. Montar una base de datos vectorial para consultar cuatro PDF es el equivalente moderno de montar un almacén para guardar tres cajas.
El punto de seguridad que se olvida siempre
El índice de Bermejo & Asociados contiene documentos de 180 clientes distintos, y varios son competencia entre sí. Si una consulta sobre el cliente 118 recupera un fragmento del cliente 42, el sistema acaba de filtrar información confidencial de un tercero dentro de un correo, con la redacción impecable de siempre.
La regla, y no admite matices: el filtro de permisos se aplica en la consulta al índice, no después. Recuperar veinte fragmentos y descartar luego los que el usuario no puede ver parece equivalente y no lo es, por tres razones: si el descarte falla una vez, se filtra; el fragmento prohibido ha ocupado un hueco que le correspondía a uno legítimo; y en cuanto un fragmento entra en el contexto del modelo, ya no hay forma fiable de quitarlo de la respuesta.
En la práctica esto significa que cada fragmento del índice lleva metadatos —cliente, tipo de documento, fecha, nivel de confidencialidad— y que la consulta filtra por ellos antes de buscar por similitud. Es trabajo aburrido de estructura de datos, no es interesante, y es exactamente lo que separa un prototipo de un sistema que puede tocar datos reales. Volveremos a ello en el módulo 9 con el RGPD delante.
Simulador: el recuperador de Marta
Supongamos que para una consulta típica hay 4 fragmentos del archivo que contienen la respuesta. Mueve k y mira las dos curvas cruzarse: la exhaustividad sube deprisa al principio y se aplana; la precisión cae desde el primer momento. Baja después la calidad del índice —troceado a ciegas, sin búsqueda híbrida— y mira cuánta exhaustividad pierdes con el mismo k: eso es lo que cuesta no haber dedicado media jornada a trocear bien.
Modelo juguete en una parte y exacto en otra. Los tokens y el coste son aritmética limpia: k fragmentos de 500 tokens a 3 € el millón. Las curvas de exhaustividad y precisión salen de una función de saturación con la forma que suelen tener estos sistemas, pero tu índice tendrá la suya y puede ser bastante peor si los documentos son heterogéneos. La forma general —exhaustividad que se dobla pronto, precisión que cae desde el primer fragmento— sí es fiable. El número exacto solo sale de las veinte preguntas etiquetadas a mano.
✍️ Ejercicios resueltos
Ejercicio 1 — Indexar el archivo del despacho. Bermejo & Asociados tiene 4.200 documentos que dan 18.000 fragmentos de 500 tokens. El modelo de embeddings cuesta 0,10 € por millón de tokens. Cada mes entran unos 300 documentos nuevos (1.300 fragmentos). Con k = 6, ¿qué cuesta montarlo y qué cuesta mantenerlo?
Ver solución paso a paso
Paso 1 — Tokens del índice inicial. 18.000 fragmentos × 500 tokens = 9.000.000 tokens.
Paso 2 — Coste de indexar. 9 millones × 0,10 € por millón = 0,90 €. Una vez.
Paso 3 — Mantenimiento del índice. 1.300 fragmentos × 500 = 650.000 tokens al mes × 0,10 €/millón = 0,065 €. Siete céntimos al mes.
Paso 4 — El coste que sí importa: el contexto por consulta. k = 6 fragmentos × 500 tokens = 3.000 tokens extra en cada correo. 3.000 × 3/1.000.000 = 0,009 € por correo × 1.400 = 12,60 € al mes.
Paso 5 — Total. 0,90 € de alta más 12,67 € mensuales. La factura de tokens del proceso pasa de 17,55 € a 30,22 €.
Paso 6 — Lo que compra. Con las fichas reales delante, la tasa de error del borrador baja del 8% al 3%. Con una detección del 60%, los errores que llegan al cliente pasan de 1.400 × 0,08 × 0,4 = 44,8 a 1.400 × 0,03 × 0,4 = 16,8 al mes. Son 28 errores evitados, a 26,15 € de coste esperado cada uno (módulo 3): 732 € al mes.
La lección de gestión: 732 € de beneficio por 12,67 € de coste. Y fíjate en dónde estaba el dinero: no en indexar —eso costó noventa céntimos y es lo que la gente teme— sino en el contexto adicional de cada consulta, que es lo que nadie presupuesta. En cualquier sistema de recuperación, el coste recurrente lo fija k multiplicado por tu volumen, no el tamaño del archivo.
Ejercicio 2 — Elegir k con la cabeza. Con los datos de la tabla del módulo (k = 6: exhaustividad 70%; k = 12: 91%; k = 20: 98%), y sabiendo que cada punto de exhaustividad perdido se traduce aproximadamente en un punto de tasa de error del borrador, ¿qué k elige Marta? Supón 1.400 consultas y 26,15 € de coste esperado por error que llega, con detección del 60%.
Ver solución paso a paso
Paso 1 — Traducir exhaustividad a errores. Si con exhaustividad 100% la tasa de error de fondo fuese del 3%, cada punto que falte añade un punto: k = 6 (70%) → error del 33%; k = 12 (91%) → 12%; k = 20 (98%) → 5%. (Es una simplificación deliberada para poder decidir; la relación real la mediría el módulo 7.)
Paso 2 — Errores que llegan al cliente. Con detección del 60%, llega el 40%: k = 6 → 1.400 × 0,33 × 0,4 = 184,8. k = 12 → 1.400 × 0,12 × 0,4 = 67,2. k = 20 → 1.400 × 0,05 × 0,4 = 28.
Paso 3 — Coste esperado de esos errores. A 26,15 € cada uno: k = 6 → 4.832 €. k = 12 → 1.757 €. k = 20 → 732 €.
Paso 4 — Coste de contexto. k = 6 → 12,60 €. k = 12 → 25,20 €. k = 20 → 42 € al mes.
Paso 5 — Coste total. k = 6: 4.845 €. k = 12: 1.782 €. k = 20: 774 €. Gana k = 20 sin discusión, y pasar de 6 a 20 cuesta 29,40 € al mes y evita 4.071 € de coste esperado.
Paso 6 — El matiz que evita pasarse. Si esto fuera monótono, la respuesta sería k = 200. No lo es: a partir de cierto punto el contexto se llena de ruido, el modelo se despista, la latencia sube y la exhaustividad ya no puede pasar del 100%. Y hay una solución mejor que subir k a lo bruto: recuperar 30 y reordenar para pasar los 8 mejores — exhaustividad de 30 al coste de contexto de 8.
La lección de gestión: el error de bulto en estos sistemas es ahorrar en el sitio equivocado. Elegir k = 6 en vez de k = 20 ahorra 29 € al mes de tokens y cuesta 4.071 € de errores. Cada vez que te enfrentes a una decisión así, pon las dos columnas: lo que ahorras es siempre visible y está en una factura; lo que cuesta está repartido en incidentes que nadie suma. Por eso se equivoca tanta gente en la misma dirección.
Quiz — Tus datos: RAG y recuperación
12 preguntas — se supera con 70% o más.