# Arregla la recuperación antes de culpar al modelo Curso exprés sobre RAG y grounding. 22 conceptos — knowledge cutoff, RAG, grounding, chunking, metadatos, embeddings, búsqueda vectorial, búsqueda híbrida, reranking, precisión y recall, citas, rechazo honesto, fidelidad, golden sets, frescura del índice y más — cada uno con su nombre en inglés, un diagrama, un ejemplo y una tarjeta. La idea central: en RAG el modelo rara vez es el problema — tu recuperación sí. Al final, una hoja de referencia de una página con todos los conceptos. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~35 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/rag-and-grounding-express --- ## 1. Por qué existe RAG Un modelo no conoce tus datos, ni nada posterior a su fecha de corte de entrenamiento. RAG es la forma de darle los hechos con los que responder — así que entiende el problema que resuelve antes que la mecánica. ### 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_. _Diagram: Las bases arriba, seis grupos debajo — los capítulos 2–7 los siguen._ ### 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. _Diagram: Lo que viene después del corte, o está dentro de tu empresa, el modelo nunca lo ha visto._ #### Knowledge Cutoff (fecha de corte de entrenamiento) - **Qué es:** El modelo solo conoce sus datos de entrenamiento, congelados en una fecha. - **Ejemplo:** No conoce tus documentos, el registro de un cliente ni las noticias de ayer. - **Ojo:** El modelo no se calla cuando no sabe — responde desde una memoria difusa o inventa. - **Relaciones:** **RAG** cierra esta brecha: los hechos llegan 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. _Diagram: Los tres pasos de RAG: recuperar fragmentos, añadirlos al contexto, generar la respuesta._ #### Retrieval-Augmented Generation (RAG) - **Problema:** El modelo no conoce tus datos ni nada posterior a su fecha de corte. - **Idea:** Encontrar los trozos relevantes de tus documentos y hacer que el modelo responda a partir de ellos. - **Ejemplo:** Un asistente de soporte responde sobre la política de reembolsos con el artículo vigente de la base de conocimiento. - **Coste:** Todo un sistema de búsqueda: chunking, un índice, frescura, evaluación. - **Cuándo usarlo:** El conocimiento es grande, cambia a menudo o depende del usuario. - **Relaciones:** Existe para el **grounding**; se construye sobre **chunking**, **embeddings** y **búsqueda vectorial**. ### 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. _Diagram: Cada afirmación tiene una fuente. Una afirmación sin ella destaca de inmediato._ #### Grounding - **Qué es:** La respuesta se apoya en texto recuperado, no en la memoria del modelo. - **Cómo funciona:** Cada afirmación se puede rastrear hasta un fragmento concreto y comprobar. - **Ejemplo:** "Los reembolsos tardan 14 días [1]", donde [1] es un párrafo de la política de reembolsos. - **Ojo:** Reduce mucho la alucinación, pero no la lleva a cero. - **Relaciones:** Se logra con **responder solo desde el contexto**, **citas** y **rechazo**; se mide con la **fidelidad**. ### 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. _Diagram: Chunking, embedding, búsqueda y ranking son la parte difícil. El modelo solo redacta la respuesta._ > **La pregunta de encuadre:** "¿Esta respuesta viene de hechos que recuperé y puedo citar — o de la memoria congelada y difusa del modelo?" > No le preguntes al modelo lo que sabe. Recupera los hechos relevantes y pídele que responda a partir de ellos — con anclaje, al día y con citas. ## 2. Chunking Antes de poder recuperar, divides tus documentos en trozos. Cómo los cortes decide en silencio la calidad de la recuperación — es el paso menos vistoso y uno de los más importantes. ### 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. _Diagram: Un documento se corta en chunks. La búsqueda ve chunks, el modelo lee chunks — no documentos._ #### Chunk (pasaje) - **Qué es:** Un pasaje de unos cientos de palabras — la unidad de búsqueda y de lectura. - **Cómo funciona:** Los documentos se dividen de antemano; la búsqueda devuelve chunks y el modelo responde a partir de ellos. - **Tamaño:** Muy grande entierra la respuesta, muy pequeño pierde el contexto. El número se encuentra midiendo. - **Ojo:** Un mal chunking no lo rescata ni la búsqueda ni el modelo. - **Relaciones:** Se corta con **structure-aware chunking**, se etiqueta con **metadatos**, se convierte en un **embedding**. ### 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. _Diagram: La barra de color es el hecho que necesitas. A la izquierda se ahoga en ruido; a la derecha perdió su contexto._ ### 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. _Diagram: Arriba: corta cada N caracteres. Abajo: corta por secciones, con un pequeño solapamiento en las uniones._ #### Structure-Aware Chunking (semantic chunking, solapamiento (overlap)) - **Problema:** Dividir por número de caracteres parte frases y tablas por la mitad. - **Idea:** Dividir por títulos, secciones y párrafos, con un pequeño solapamiento. - **Ejemplo:** Toda la sección "Plazos de reembolso" se convierte en un solo chunk. - **Coste:** Hay que interpretar el formato del documento: Markdown, HTML, PDF. - **Relaciones:** Mejora cada **chunk** y todo lo que viene después. ### 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. _Diagram: Los metadatos te dan dos cosas: un filtro antes de buscar y una fuente para la cita._ #### Metadata (metadatos del chunk) - **Problema:** Un montón plano de texto: no puedes acotar la búsqueda y no tienes nada que citar. - **Idea:** Guardar con cada chunk su fuente, título, fecha, sección y permisos. - **Ejemplo:** Buscar solo en las políticas vigentes que este usuario puede ver. - **Coste:** Casi nada — unos pocos campos por chunk. - **Relaciones:** Da a la **búsqueda vectorial** un filtro y a las **citas** una fuente. > **La pregunta del chunking:** "¿Cada chunk se sostiene solo como una idea coherente — con suficiente contexto para entenderse y suficientes metadatos para filtrarse y citarse?" > Recuperas chunks, no documentos. Corta por significado, mantén cada uno autónomo y etiquétalo — la calidad del chunking limita todo lo que viene después. ## 3. Embeddings y búsqueda vectorial Para encontrar los chunks que responden a una pregunta, buscas por significado, no por coincidencia de palabras. Los embeddings son el truco que hace posible "encuéntrame cosas parecidas a esto". ### 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. _Diagram: Chunk → modelo de embeddings → vector. Una vez por chunk, y luego al almacén._ #### Embedding (vector) - **Qué es:** Una lista de números que representa el significado de un texto. - **Cómo funciona:** Un modelo de embeddings produce coordenadas; significado parecido significa puntos cercanos. - **Ejemplo:** "Perro" y "cachorro" quedan cerca; ambos lejos de "declaración de impuestos". - **Relaciones:** Hace posible la **búsqueda vectorial**; los vectores viven en una **base de datos vectorial**. ### 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. _Diagram: La pregunta y el chunk de reembolsos no comparten palabras — pero en el espacio de significado están uno al lado del otro._ #### Vector Search (búsqueda semántica) - **Qué es:** Encontrar los chunks cuyos vectores están más cerca del vector de la pregunta. - **Cómo funciona:** La pregunta se convierte en embedding con el mismo modelo, y luego se buscan los puntos más cercanos. - **Ejemplo:** "Recuperar mi dinero" encuentra la sección "Política de reembolsos". - **Ojo:** Falla con códigos y nombres exactos; cerca no siempre es útil. - **Relaciones:** Funciona sobre una **base de datos vectorial**; se completa con **búsqueda híbrida** y **reranking**. ### 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. _Diagram: Una base de datos vectorial no recorre todo: el índice aproximado va directo a los más cercanos._ #### Vector Database (vector store, ANN index) - **Qué es:** Un almacén de vectores con búsqueda rápida del vecino más cercano. - **Cómo funciona:** Un índice aproximado (ANN) en lugar de un recorrido completo. - **Ejemplo:** Millones de chunks — y los más cercanos a la pregunta en milisegundos. - **Ojo:** No la construyes, pero debes saber cuán rápida y precisa es su búsqueda. - **Relaciones:** Guarda **embeddings**; la **búsqueda vectorial** corre sobre ella. ### 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. _Diagram: Ambos chunks están cerca de la pregunta. Solo uno contiene la respuesta._ #### Similar ≠ Relevant (similitud vs relevancia) - **Qué es:** Un chunk cercano en significado no necesariamente contiene la respuesta. - **Ejemplo:** "Cómo cancelar" y "por qué la gente cancela" quedan cerca; solo el primero responde. - **Ojo:** La búsqueda vectorial en bruto confunde cercanía con utilidad. - **Relaciones:** Se arregla con **reranking**; se mide con la **retrieval eval**. > **La pregunta de la búsqueda:** "¿Estoy buscando por el significado de la pregunta — o solo espero que el usuario escriba las mismas palabras clave que usaron mis documentos?" > Los embeddings dan coordenadas al significado; la búsqueda vectorial encuentra chunks por similitud. Es potente — y "cerca en significado" no es exactamente "responde a la pregunta". ## 4. La recuperación lo es todo Esta es la lección que arregla la mayoría de los sistemas RAG rotos: cuando las respuestas son malas, la causa suele ser la recuperación. Mete los chunks correctos y un modelo decente hace el resto. ### 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.** _Diagram: El error se ve en la respuesta pero nació en la recuperación. Mira primero los chunks._ ### 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. _Diagram: Dos búsquedas en paralelo: una atrapa los códigos exactos, la otra las reformulaciones. Los resultados se fusionan._ #### Hybrid Search (keyword + vector) - **Problema:** La búsqueda vectorial falla con códigos y nombres exactos; la de palabras clave no ve las paráfrasis. - **Idea:** Ejecutar ambas búsquedas y fusionar los resultados. - **Ejemplo:** "Error SKU-4471 en la devolución" — la búsqueda por palabras clave encuentra el código, la vectorial el significado. - **Coste:** Dos índices y la lógica de fusión. - **Cuándo usarlo:** Casi siempre, con corpus reales. - **Relaciones:** El primer paso amplio antes del **reranking**. ### 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. _Diagram: Etapa 1 — reunir rápido 50 candidatos. Etapa 2 — elegir con cuidado los mejores 5._ #### Reranking (two-stage retrieval) - **Problema:** La primera pasada es rápida pero tosca: el chunk correcto puede estar en el puesto 30. - **Idea:** Tomar los 50 primeros y puntuar con cuidado cada candidato frente a la pregunta. - **Ejemplo:** De 50 chunks recuperados, el reranker se queda con los 5 más útiles. - **Coste:** Un paso extra — algo de latencia y dinero en cada pregunta. - **Cuándo usarlo:** Cuando el RAG es mediocre — una de las mejoras más fuertes. - **Relaciones:** Arregla **similar ≠ relevant**; viene después de la **búsqueda híbrida**. ### 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. _Diagram: Muy pocos chunks — se pierde la respuesta. Demasiados — se ahoga. El punto medio se encuentra midiendo._ #### Precision & Recall (top-k) - **Qué es:** Recall — si volvió el chunk correcto; precision — cuánta basura vino con él. - **Cómo funciona:** Un k mayor sube el recall y baja la precision, y al revés. - **Ejemplo:** k = 2 pierde la respuesta; k = 40 la entierra y gasta tokens. - **Ojo:** No puedes adivinar el k correcto — lo mides con tus propios datos. - **Relaciones:** Se mide con la **retrieval eval**; condiciona el **coste y la latencia**. > **La pregunta de la recuperación:** "Cuando una respuesta está mal, ¿miré de verdad qué chunks se recuperaron — o supuse que era el modelo y empecé a retocar el prompt?" > La mayoría de las malas respuestas de RAG son mala recuperación. Combina palabras clave y semántica, reordena la lista corta y revisa los chunks antes de culpar al modelo. ## 5. Grounding y citas Una vez que los chunks correctos están en el contexto, el trabajo es lograr que el modelo responda estrictamente a partir de ellos — y demostrar que lo hizo. Eso convierte la recuperación en una respuesta digna de confianza. ### 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. _Diagram: Los chunks son la fuente permitida. La memoria del modelo no._ #### Context-Only Answering (responder desde el contexto) - **Problema:** El modelo mezcla los hechos recuperados con su propia memoria. - **Idea:** Una instrucción: responde solo a partir de los chunks dados; si no, di "no lo sé". - **Ejemplo:** "Responde solo con los fragmentos de abajo. Si la respuesta no está ahí, dilo." - **Coste:** No es perfecto: el modelo aún puede desviarse. - **Relaciones:** El núcleo del **grounding**; se comprueba con **citas** y **fidelidad**. ### 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. _Diagram: Cada frase de la respuesta apunta a su fuente — puedes abrirla y comprobar._ #### Citations (atribución de fuentes) - **Problema:** Una respuesta sin fuente no se puede comprobar — es una conjetura con aplomo. - **Idea:** El modelo dice de qué chunk salió cada afirmación. - **Ejemplo:** "Los reembolsos tardan 14 días [1]", donde [1] es refund-policy.md, sección "Plazos." - **Coste:** Cada chunk necesita metadatos con su fuente. - **Relaciones:** Se apoyan en los **metadatos**; hacen comprobable el **grounding**. ### 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. _Diagram: Ambas ramas son salidas correctas. Solo una cosa está mal: inventar la respuesta de memoria._ #### Refusal (un “no lo sé” honesto) - **Problema:** La recuperación volvió desviada y el modelo responde igualmente. - **Idea:** "Eso no está en mis fuentes" es una respuesta normal y esperada. - **Ejemplo:** Una pregunta fuera de la base de conocimiento → "Los documentos no cubren esto." - **Coste:** A veces el usuario no recibe respuesta — pero nunca una inventada. - **Relaciones:** Parte del **grounding**; los rechazos revelan huecos en la 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. > **La pregunta del grounding:** "¿Se puede rastrear cada afirmación de esta respuesta hasta un chunk recuperado — y el sistema dice 'no lo sé' cuando los hechos no están?" > Grounding significa que la respuesta sale solo del texto recuperado, con citas que lo demuestran — y un "no lo sé" honesto cuando los hechos no están. ## 6. Evaluar RAG RAG tiene dos etapas que fallan de forma distinta, así que las mides por separado. Si las mezclas, pasarás semanas ajustando la mitad equivocada. (El curso de Evals profundiza; aquí va la forma específica de RAG.) ### 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. _Diagram: Cada etapa tiene su propio medidor — y su propio arreglo._ ### 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. _Diagram: El documento correcto para la pregunta es conocido. Si cae entre los k primeros, la prueba pasa._ #### Retrieval Eval (recall@k) - **Problema:** La respuesta final no te dice si la culpa fue de la búsqueda. - **Idea:** Preguntas con documentos correctos conocidos: ¿volvieron entre los k primeros? - **Ejemplo:** De 50 preguntas reales, el documento correcto está entre los 5 primeros en 41. - **Qué detecta:** Mal chunking, búsqueda débil, falta de reranking. - **Relaciones:** Mide **precision & recall**; arréglala antes que la **fidelidad**. ### 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**). _Diagram: El evaluador revisa cada frase contra los chunks y marca lo que ellos no respaldan._ #### Faithfulness (groundedness) - **Qué es:** Cada afirmación de la respuesta está respaldada por los chunks recuperados. - **Cómo funciona:** Un evaluador — a menudo otro modelo — compara las frases con los chunks. - **Ejemplo:** Dos frases están respaldadas, la tercera no: se marca. - **Ojo:** Una respuesta fiel a los chunks aún tiene que responder la pregunta. - **Relaciones:** Mide el **grounding**; tiene sentido tras una buena **retrieval eval**. ### 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. _Diagram: Una tabla de preguntas reales con chunks y respuestas esperados — se ejecuta en cada cambio._ #### Golden Set (conjunto de evaluación (eval set)) - **Problema:** Ajustar por anécdotas: "parece que ahora va mejor." - **Idea:** Preguntas reales + los chunks que deberían volver + una respuesta correcta conocida. - **Ejemplo:** Una pregunta desordenada, una parafraseada y una fuera de alcance que espera "no lo sé." - **Coste:** Tiempo para construir y mantener el conjunto. - **Relaciones:** Alimenta tanto la **retrieval eval** como la **fidelidad**. > **La pregunta de la evaluación:** "Cuando una respuesta está mal, ¿puedo decir si la recuperación falló con el chunk o si el modelo se equivocó — o estoy adivinando?" > RAG falla en dos sitios. Mide recuperación y generación por separado, arregla primero la recuperación y construye la evaluación con preguntas reales. ## 7. Construirlo bien RAG es potente y a menudo se usa de más. La habilidad está en usarlo cuando se lo gana, mantener los datos frescos y no pagar por una maquinaria que un enfoque más simple habría evitado. ### 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. _Diagram: Pequeño y estable — pégalo en el prompt. Grande, cambiante o por usuario — RAG._ #### Paste First (context stuffing) - **Problema:** Se construye un pipeline de recuperación donde no hace falta. - **Idea:** Los hechos pequeños y estables van directo al prompt. - **Ejemplo:** Una política de dos páginas va en el prompt, sin índice. - **Cuándo usar RAG:** El conocimiento no cabe en el contexto, cambia a menudo o se filtra por usuario. - **Relaciones:** El peldaño más bajo de la escalera; **RAG** es el siguiente. ### 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. _Diagram: Arriba: los documentos cambian y el índice se reconstruye. Abajo: sin plan, y las respuestas se quedan viejas._ #### Index Freshness (reindexación) - **Problema:** Los documentos cambiaron pero el índice no — las respuestas están desactualizadas con aplomo. - **Idea:** Volver a dividir y a generar embeddings de los documentos cambiados, según un plan. - **Ejemplo:** Se actualiza la política — sus chunks se reconstruyen el mismo día. - **Coste:** Un pipeline de reindexación que hay que mantener. - **Relaciones:** Mantiene el **grounding** al día; afecta a **chunks** y **embeddings**. ### 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. _Diagram: Cada etapa añade tiempo y dinero — y cada pregunta lo paga._ #### Cost & Latency - **Qué es:** Cada etapa de RAG añade tiempo y tokens a cada pregunta. - **Cómo funciona:** Más chunks, reranking, contexto mayor — mejor calidad hasta cierto punto, siempre más caro. - **Ejemplo:** Bajar k de 20 a 5 tras el reranking — misma respuesta, factura menor. - **Ojo:** Una gran respuesta demasiado lenta o cara no es grande en producción. - **Relaciones:** Tira en contra de **precision & recall** y del **reranking**. ### 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. _Diagram: Prompt simple → RAG → herramientas y agentes. Sube solo cuando la tarea te obligue._ ### 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. _Diagram: Arriba: la indexación. En medio: el camino de una pregunta. Abajo: las evals que miden toda la cadena._ #### Antes de lanzar una función con RAG - **¿Hace falta RAG siquiera** — o los hechos son lo bastante pequeños y estables para pegarlos en el prompt? - **¿Cómo se dividen los documentos** — por significado, autónomos, con metadatos y un poco de solapamiento? - **¿La recuperación es híbrida y con reranking**, o una búsqueda vectorial en bruto que nunca mediste? - **¿El modelo responde solo desde el texto recuperado**, cita fuentes y dice "no lo sé"? - **¿Cuál es la eval** de la recuperación, separada de la generación? - **¿Cómo se mantiene fresco el índice**, y cuánto cuesta una consulta en tiempo y tokens? #### Señales de que el problema es la recuperación - Las respuestas son **erróneas con aplomo**, y nunca miraste los chunks que se recuperaron. - Solo **búsqueda vectorial en bruto** — sin respaldo por palabras clave, sin reranking. - Chunks divididos **por número de caracteres**, cortando frases y tablas. - Estás **retocando el prompt y el modelo** para arreglar lo que en realidad es un fallo de recuperación. - El índice no se ha **reconstruido** desde que cambiaron los documentos de origen. #### Señales de que lo construiste bien - Los chunks son **semánticos y autónomos**, etiquetados con metadatos para filtrar y citar. - La recuperación es **híbrida + reranking**, ajustada a los menos chunks que respondan bien. - Las respuestas están **ancladas y con citas**, con un rechazo honesto cuando los hechos no se recuperan. - Mides **recuperación y generación por separado**, y arreglaste primero la recuperación. - El índice tiene un **plan de frescura**, y RAG está detrás de una interfaz que podrías cambiar. ## Hoja de referencia: los 22 conceptos ### Bases - **Knowledge Cutoff** (fecha de corte de entrenamiento): El modelo solo conoce los datos de entrenamiento hasta una fecha — no tus documentos. - **RAG** (Retrieval-Augmented Generation): Recuperar los chunks relevantes, ponerlos en el contexto y responder a partir de ellos. - **Grounding** (responder desde fuentes): La respuesta se apoya en texto recuperado, y se puede comprobar. ### Chunking - **Chunk** (pasaje): Un pasaje de unos cientos de palabras — la unidad de búsqueda; el tamaño se ajusta midiendo. - **Structure-Aware Chunking** (dividir por estructura): Dividir por títulos y párrafos, con un pequeño solapamiento. - **Metadata** (etiquetas del chunk): Fuente, fecha, sección, permisos — para filtrar y citar. ### Embeddings y búsqueda - **Embedding** (vector): Un vector — las coordenadas del significado de un texto. - **Vector Search** (búsqueda semántica): Encontrar los chunks más cercanos a la pregunta en significado. - **Vector Database** (ANN index): Guarda vectores y encuentra los más cercanos en milisegundos. - **Similar ≠ Relevant** (similitud vs relevancia): Un chunk cercano en significado no necesariamente contiene la respuesta. ### Calidad de la recuperación - **Hybrid Search** (keyword + vector): Buscar por palabras y por significado a la vez, y fusionar los resultados. - **Reranking** (two-stage retrieval): Reunir candidatos de forma amplia y luego elegir con cuidado los mejores. - **Precision & Recall** (top-k): Muy pocos chunks — se pierde la respuesta; demasiados — se ahoga. Mide k. ### Grounding - **Context-Only Answering** (responder desde el contexto): Responder solo desde los chunks recuperados, nunca desde la memoria del modelo. - **Citations** (atribución de fuentes): Cada afirmación apunta a su chunk y se puede comprobar. - **Refusal** (“no lo sé”): No hay respuesta en los chunks — decirlo con honestidad en lugar de inventar. ### Evaluación - **Retrieval Eval** (recall@k): ¿Volvieron los chunks correctos entre los k primeros? Arregla esto primero. - **Faithfulness** (groundedness): Cada afirmación de la respuesta está respaldada por los chunks. - **Golden Set** (eval set): Preguntas reales con chunks y respuestas esperados — se ejecuta en cada cambio. ### Construirlo bien - **Paste First** (context stuffing): Unos pocos hechos estables — usa el prompt, no RAG. - **Index Freshness** (reindexación): Los documentos cambiaron — reindexa, o las respuestas se quedan viejas. - **Cost & Latency** (tiempo y tokens): Cada etapa cuesta tiempo y tokens; toma el k más pequeño que responda bien. > RAG es un sistema de búsqueda con un modelo al final. Acierta con los chunks y la respuesta llega sola — el modelo rara vez era el problema. Fin del curso exprés · 7 capítulos · 22 conceptos Lo siguiente es la práctica: construye el RAG real más pequeño sobre un puñado de tus propios documentos — chunking por estructura, embeddings, búsqueda, y que el modelo responda con citas y un "no lo sé" honesto. Luego, antes de ajustar nada, escribe diez preguntas reales y revisa qué se recupera. Pero mantén una idea por encima de las demás: cuando la respuesta está mal, mira primero los chunks. En RAG, el modelo rara vez es el problema — tu recuperación sí, y esa es la mitad que controlas.