El mapa: 22 conceptos en siete grupos

Un mapa de metro: primero ves toda la red, luego la recorres estación por estación.

Primero, tres bases — por qué la memoria del modelo no basta, qué es RAG y por qué importa el grounding. Después seis grupos, uno por capítulo: chunking, embeddings y búsqueda, calidad de la recuperación, grounding, evaluación y construirlo bien.

Cada concepto siguiente tiene la misma forma: el nombre en inglés (recuérdalo — es el término), una imagen de la vida real, un diagrama y una tarjeta con campos: qué es o problema, cómo funciona o idea, ejemplo, ojo o coste, y relaciones.

Knowledge Cutoff — la memoria del modelo está congelada

Un graduado brillante que leyó toda la biblioteca hace años — pero no los archivos de tu empresa, ni nada impreso desde que se graduó.

Un LLM solo sabe lo que estaba en sus datos de entrenamiento, congelados en una fecha de corte — su knowledge cutoff. No conoce tus documentos, tu producto, el registro de tu cliente ni las noticias de ayer. Pregúntale igual y responderá desde su memoria difusa o inventará algo plausible. RAG existe precisamente para arreglar esto: dejar de depender de lo que el modelo memorizó y entregarle los hechos relevantes en el momento de la pregunta.

RAG — recupera primero, responde después

Un examen a libro abierto — en lugar de confiar en la memoria, primero buscas las páginas relevantes y luego escribes la respuesta con lo que tienes delante.

Este es el patrón Retrieval-Augmented Generation (RAG). Tres pasos: recuperar — tomas la pregunta del usuario y traes los fragmentos más relevantes de tus documentos; aumentar — los pones en el contexto; generar — le pides al modelo que responda a partir de ellos. Ahora la respuesta sale de tus datos reales, no del recuerdo del modelo. Así es como un asistente responde sobre tus documentos, tus políticas, tu base de conocimiento — con precisión y al día.

Grounding — el verdadero premio

Un periodista que debe citar una fuente para cada afirmación escribe muchas menos invenciones que uno que escribe de memoria.

La razón profunda por la que RAG importa es el grounding (anclaje): como la respuesta se saca de texto recuperado, puedes exigir citas y comprobar que cada afirmación está realmente respaldada por una fuente. No borra del todo la alucinación, pero la reduce mucho y hace que lo que se cuela sea detectable. Una respuesta que puedes rastrear hasta un documento es una en la que puedes confiar — y que puedes defender.

Retrieval-first — un sistema de búsqueda con un modelo al final

Un asistente de investigación es tan bueno como el archivo en el que busca — dale una gran biblioteca y un mal índice, y aun así te entregará la carpeta equivocada.

El modelo mental que te ahorra meses: RAG es sobre todo un problema de búsqueda, con un modelo de lenguaje al final para redactar la respuesta. El modelo es la parte fácil y casi resuelta. La parte difícil, la que determina la calidad, es todo lo que decide qué texto llega al modelo — y de eso trata el resto de este curso.

Chunk — la unidad de calidad

Un libro de consulta solo sirve cortado en entradas que se puedan encontrar — un pergamino gigante sin índice o mil recortes sueltos son igual de inútiles para buscar.

No recuperas documentos enteros; recuperas chunks — pasajes de unos cientos de palabras. El proceso de cortarlos es el chunking. Ese chunk es la unidad que ve la búsqueda y que lee el modelo, así que sus límites importan enormemente. Los buenos chunks son autónomos y tratan un solo tema. Si el chunking sale mal, ninguna búsqueda ingeniosa ni modelo listo lo recupera.

Chunk Size — demasiado grande entierra la respuesta, demasiado pequeño pierde el contexto

Dale a alguien un capítulo entero para responder una pregunta de una línea y se hundirá en el ruido; dale una sola frase sin el contexto que la rodea y no sabrá qué significa.

Si el chunk es demasiado grande, cada uno mezcla el hecho relevante con párrafos de texto sin relación — la búsqueda se vuelve difusa y la atención del modelo se diluye. Si es demasiado pequeño, cortas el contexto que daba sentido al hecho. El punto justo contiene una idea coherente con suficiente entorno para sostenerse sola. No existe un chunk size universal; depende de tus documentos y se ajusta midiendo.

Structure-Aware Chunking — corta por significado, no por número de caracteres

Dividir un libro contando caracteres puede partir una frase — o una receta — por la mitad. Dividir por capítulos y secciones mantiene cada pieza entera.

El enfoque ingenuo — fixed-size chunking — corta cada N caracteres, lo que atraviesa frases, tablas e ideas. Mejor es dividir por la estructura natural del documento — títulos, secciones, párrafos — para que cada chunk sea un pensamiento completo. Un poco de solapamiento (overlap) entre chunks vecinos evita que un hecho caiga en la grieta entre dos de ellos. Respeta la forma del documento y la recuperación se vuelve más fácil sin esfuerzo.

Metadata — pon etiquetas a cada chunk

Una ficha de biblioteca no guarda solo el texto — registra el autor, la fecha y la sección, para que puedas filtrar hasta el estante correcto antes incluso de buscar.

Guarda cada chunk con metadatos: documento de origen, título, fecha, sección, permisos. Esto te permite filtrar antes o junto con la búsqueda semántica — solo los documentos de este producto, solo las políticas vigentes, solo lo que este usuario puede ver — y te da la fuente para las citas. Los metadatos son baratos de mantener y convierten un montón plano de texto en algo al que puedes apuntar.

Embedding — el significado se vuelve coordenadas

Un mapa donde cada idea tiene una ubicación, y las cosas que significan algo parecido quedan cerca — "perro" junto a "cachorro", ambos lejos de "declaración de impuestos".

Un embedding es una lista de números — un vector — que representa el significado de un texto, situado en un espacio de muchas dimensiones de modo que los significados parecidos quedan cerca. Conviertes cada chunk en embedding una vez y guardas los vectores. Ahora el "significado" tiene coordenadas, y "encontrar texto relacionado" pasa a ser "encontrar puntos cercanos" — un problema que un ordenador resuelve rápido.

Vector Search — encuentra por similitud, no por palabras clave

Un bibliotecario que encuentra libros por de qué tratan — "cosas como esta" — en lugar de solo buscar el título exacto que dijiste.

En el momento de la pregunta conviertes la pregunta en embedding de la misma manera y buscas en el almacén los chunks cuyos vectores estén más cerca. Esto es la búsqueda vectorial, también llamada búsqueda semántica: encuentra un chunk sobre "política de reembolsos" aunque el usuario preguntara por "recuperar mi dinero", porque los significados están cerca. La búsqueda por palabras clave lo perdería; la búsqueda vectorial está hecha para esto.

Vector Database — el motor de recuperación

Un almacén diseñado para que, dado cualquier artículo, pueda entregarte al instante los cien más parecidos — no leyendo cada estante, sino por cómo está organizado.

Una base de datos vectorial guarda tus embeddings y responde consultas de "lo más cercano a esto" en milisegundos, incluso sobre millones de chunks, usando un índice aproximado (ANN, vecino más cercano aproximado) en lugar de recorrerlo todo. Es el motor de recuperación bajo RAG. No necesitas construirla — pero sí saber que ahí viven tus chunks y cuán rápida y precisa es su búsqueda.

Similar ≠ Relevant — similitud no es lo mismo que relevancia

Dos pasajes pueden tratar del mismo tema y aun así responder preguntas distintas — "cómo cancelar" y "por qué la gente cancela" quedan cerca, pero solo uno es lo que se preguntó.

La búsqueda vectorial devuelve lo que está semánticamente cerca (similar), que normalmente es relevante pero no siempre. Un chunk puede tratar del tema correcto y aun así no contener la respuesta. Esta brecha — cerca en significado frente a realmente útil — es la razón por la que la búsqueda vectorial en bruto es un buen primer paso pero no la última palabra, y por la que existe la siguiente sección.

Garbage In, Confident Garbage Out — entra basura, sale basura con aplomo

Dale a alguien el archivo equivocado y pídele que lo resuma — te dará un resumen impecable de algo totalmente equivocado, sonando completamente seguro.

Una respuesta RAG es tan buena como los chunks que recibió. Recupera los pasajes equivocados y el modelo responde fielmente desde el contexto equivocado, con toda su seguridad habitual. El fallo parece "el modelo se equivoca", pero el error real ocurrió antes, en la recuperación. Así que cuando las respuestas son malas, mira qué se recuperó antes de tocar el prompt o el modelo.

Hybrid Search — combina palabras clave y significado

Un buscador que sabe exactamente qué significan las palabras y otro que encuentra nombres y códigos exactos — juntos atrapan lo que cualquiera de los dos dejaría pasar.

La búsqueda vectorial entiende el significado pero puede fallar con términos exactos — códigos de producto, nombres, jerga poco común. La búsqueda por palabras clave acierta con esos, pero no ve las paráfrasis. La búsqueda híbrida ejecuta ambas y fusiona los resultados, cubriendo los puntos ciegos de cada una. Para la mayoría de los corpus reales, la híbrida supera a cualquiera de las dos por separado, porque las preguntas reales mezclan conceptos con nombres concretos.

Reranking — reordena la lista corta

Un proceso de contratación: una primera pasada barata saca cincuenta currículos plausibles, y luego un revisor cuidadoso los lee con atención y ordena los cinco mejores de verdad.

La búsqueda de primera pasada es rápida pero tosca. Un reranker toma, digamos, los cincuenta mejores candidatos y puntúa cada uno frente a la pregunta con más cuidado, subiendo a lo alto los chunks realmente relevantes. Recupera de forma amplia y luego reordena hasta unos pocos precisos. Esta forma en dos etapas — recall amplio y barato, luego ranking afinado — es una de las mejoras de mayor impacto para un sistema RAG mediocre.

Precision & Recall — tiran en direcciones opuestas

Una red con agujeros grandes solo atrapa los peces grandes pero deja pasar muchos; una red fina lo atrapa todo, incluidas las algas. Ajustas la malla a la pesca que necesitas.

Si recuperas muy pocos chunks, puedes perder el que tiene la respuesta (recall bajo); si recuperas demasiados, entierras la respuesta en texto irrelevante que diluye al modelo y cuesta tokens (precision baja). El número adecuado de chunks (a menudo llamado k) equilibra ambos, y es específico de tus datos y del tipo de pregunta. No lo adivinas — lo mides, que es la siguiente sección.

Context-Only Answering — responder solo desde el texto recuperado

Un testigo al que se le indica declarar solo lo que vio personalmente — no lo que supone, recuerda vagamente u oyó de segunda mano.

Indica al modelo que responda solo a partir de los chunks proporcionados, y que diga que no sabe cuando la respuesta no está ahí. Este es el núcleo del grounding: el texto recuperado es la fuente de verdad permitida, y la memoria del propio modelo queda fuera. No será perfecto — el modelo aún puede desviarse — pero la instrucción más el contexto correcto hacen la mayor parte del trabajo.

Citations — haz que las afirmaciones se puedan comprobar

Un artículo científico con notas al pie permite a cualquier lector rastrear una afirmación hasta su fuente y verificarla — o notar dónde no se sostiene.

Haz que el modelo cite de qué chunk salió cada parte de su respuesta. Las citas hacen dos cosas: permiten al usuario (y a ti) verificar una afirmación contra su fuente, y el simple hecho de anclar cada enunciado en un pasaje recuperado disuade al modelo de alejarse de los hechos. Una respuesta con fuentes rastreables es una que puedes auditar; una respuesta sin fuente es solo una conjetura con aplomo.

Refusal — enséñale a decir no lo sé

El experto en quien más confías es el que dice "eso no está en lo que tengo" en lugar de rellenar el hueco con una conjetura segura de sí misma.

El fallo más peligroso de RAG es responder igualmente cuando la recuperación volvió vacía o desviada. Así que haz del rechazo una salida válida y esperada: si los chunks no contienen la respuesta, el modelo debe decirlo, no improvisar desde la memoria. Un sistema que admite el hueco es mucho más fiable que uno que lo tapa — y además deja ver dónde necesita trabajo tu recuperación.

Grounding reduce la alucinación — no la elimina

Los cinturones de seguridad reducen mucho las muertes, pero aun así conduces con cuidado. Una buena protección no es motivo para dejar de mirar la carretera.

Incluso con chunks perfectos, el modelo puede leer mal, generalizar de más o mezclar un hecho recuperado con su propia memoria. El grounding reduce mucho la alucinación y la hace detectable; no la elimina. Así que sigues verificando — con citas que el usuario pueda comprobar, y con evals que midan la fidelidad. Trata el grounding como un control potente, no como una garantía.

Two stages — mide la recuperación y la generación por separado

Un restaurante con un plato malo tiene dos posibles culpables — los ingredientes entregados o el cocinero. Pruebas primero los ingredientes, o reentrenarás a la persona equivocada.

Una respuesta RAG puede fallar porque la recuperación trajo los chunks equivocados, o porque la generación respondió mal a partir de los chunks correctos. Cada caso necesita un arreglo distinto, así que mídelos por separado: ¿volvieron los chunks correctos? y, dados esos chunks, ¿fue la respuesta fiel y completa? La mayoría de los equipos que "no logran mejorar su RAG" solo puntúan la respuesta final y adivinan a qué mitad culpar.

Retrieval Eval — ¿volvieron los chunks correctos?

Antes de juzgar el ensayo, comprueba que al estudiante siquiera le dieron las páginas de referencia correctas — si no, nada de lo que escribió podía ser correcto.

Evalúa la recuperación por sí sola — esto es una retrieval eval: para un conjunto de preguntas con documentos relevantes conocidos, ¿la búsqueda los devolvió entre los primeros resultados? La proporción de aciertos así se suele llamar recall@k. Esto detecta directamente un mal chunking, una búsqueda débil y la falta de reranking — las causas previas de la mayoría de las malas respuestas. Arregla primero la recuperación, porque ninguna mejora del prompt o del modelo puede rescatar una respuesta construida con los chunks equivocados.

Faithfulness — ¿fue la respuesta fiel a los chunks?

Un verificador de datos lee la respuesta frente a las fuentes citadas y marca cada frase que las fuentes no respaldan realmente.

Cuando la recuperación ya es buena, evalúa la respuesta por su fidelidad (faithfulness): ¿cada afirmación está respaldada por los chunks recuperados, sin nada inventado y sin nada contradicho? Comprueba también que realmente usó lo recuperado y respondió la pregunta. Aquí es donde detectas que el modelo se aparta de un contexto sólido — y es medible, a menudo con otro modelo como evaluador (LLM-as-judge).

Golden Set — construye la evaluación con preguntas reales

Pruebas un puente con los camiones que realmente lo cruzarán, no con los pesos que te resulten cómodos.

Tu conjunto de evaluación — a menudo llamado golden set — debe ser de preguntas reales que hacen los usuarios, incluidas las desordenadas y las fuera de alcance, cada una emparejada con los chunks que deberían recuperarse y una respuesta correcta conocida. Ejecútalo en cada cambio para ver si una nueva estrategia de chunking o un reranker realmente ayudó. Sin esto, estás ajustando RAG por anécdotas — y las anécdotas mienten.

Paste First — no hagas RAG de lo que podrías simplemente pegar

No montas un catálogo de biblioteca para los tres libros que tienes en el escritorio — simplemente los abres.

Si los hechos relevantes son pocos y fijos — unos cuantos documentos, una política corta — simplemente ponlos en el prompt. RAG se gana su complejidad cuando el conocimiento es demasiado grande para el contexto, cambia a menudo o debe filtrarse por usuario. Construir un pipeline de recuperación sobre tres páginas es el equivalente en sobreingeniería a un bucle de agente para una sola llamada. Recurre a él cuando los datos te obliguen.

Index Freshness — datos viejos son datos equivocados

Una guía telefónica solo sirve si se reimprime — los números de hace una década son, con total aplomo, inútilmente erróneos.

La promesa de RAG son hechos al día, lo que significa que tu índice tiene que mantenerse al día. Cuando cambian los documentos de origen, hay que actualizar los chunks y los embeddings — reindexar — o el modelo anclará sus respuestas en texto desactualizado y con aplomo. Planifica la reindexación como parte del sistema, no como una ocurrencia tardía — la frescura es una funcionalidad que hay que mantener, no una propiedad que se obtiene una vez.

Cost & Latency — vigílalos

Cada paso extra del pipeline — embeber, buscar, reordenar, meter contexto, generar — añade un poco de tiempo y un poco de dinero a cada pregunta.

RAG añade etapas, y cada una cuesta latencia y tokens. Recuperar más chunks, reordenar, un contexto mayor — todo mejora la calidad hasta cierto punto y sube la factura todo el camino. Así que ajusta hacia los menos chunks que respondan bien, usa caché donde puedas y recuerda que una gran respuesta demasiado lenta o demasiado cara no es una gran respuesta en producción.

RAG es un peldaño; el modelo sigue siendo un componente

Una buena cocina tiene despensa, pero la despensa no es el cocinero — es una entrada bien organizada para alguien que aún tiene que preparar el plato.

RAG está en la escalera por encima de un prompt simple y por debajo de las herramientas y los agentes: recurre a él cuando el modelo necesita tus hechos, y mantenlo detrás de una interfaz limpia como cualquier dependencia. La recuperación alimenta al modelo; no reemplaza el criterio que rodea al modelo. La misma disciplina de siempre — usa el peldaño más simple que funcione y mantén el modelo intercambiable.

Cómo se conectan los conceptos

Dos turnos en una misma cocina: de noche la preparación — cortar y colocar todo; de día la cocina — encontrar, elegir y servir.

Todo en este curso es una cadena en dos fases. Offline (indexación): los documentos se cortan en chunks con metadatos, se convierten en embeddings y se guardan en una base de datos vectorial — y se reconstruyen cuando los documentos cambian (index freshness). En el momento de la consulta: la búsqueda híbrida encuentra candidatos, el reranking se queda con los mejores, y precision y recall deciden cuántos tomar. Luego el grounding: el modelo responde solo desde el contexto, con citas o un rechazo honesto. Aparte, paste first: si los hechos son pocos, no necesitas la cadena en absoluto. Y las evals — retrieval eval, faithfulness, el golden set — miden cada eslabón.