Curso exprés · No. 12
RAG es como le entregas a un modelo de lenguaje los hechos con los que debe responder, en lugar de confiar en su memoria difusa. Es el patrón más importante en las apps serias con LLM — y cuando algo sale mal, el modelo casi nunca es el culpable. El trabajo, y la calidad, viven en la recuperación: cómo divides en chunks, indexas, buscas y ordenas el texto que pones frente al modelo.
Solo lo esencial · Una imagen por idea · La recuperación es el trabajo
Un modelo no conoce tus datos, ni nada posterior a su fecha de corte de entrenamiento. RAG es como le das los hechos con los que responder — así que entiende el problema que resuelve antes que la mecánica.
La memoria del modelo es el lugar equivocado para tus hechos
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, congelado en una fecha de corte. 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.
Recupera primero, responde después
Un examen a libro abierto — en lugar de confiar en la memoria, buscas primero las páginas relevantes y luego escribes tu respuesta a partir de lo que tienes delante.
La generación aumentada por recuperación (Retrieval-Augmented Generation) son tres pasos: tomar la pregunta del usuario, traer los chunks más relevantes de tus documentos, ponerlos en el contexto y pedirle 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 docs, tus políticas, tu base de conocimiento — con precisión y al día.
El anclaje es el verdadero premio
Un periodista que debe citar una fuente para cada afirmación escribe muchas menos fabricaciones que uno que escribe de memoria.
La razón profunda por la que RAG importa es el anclaje (grounding): como la respuesta se extrae 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 drásticamente 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.
Es un sistema de recuperación con un modelo al final
Un asistente de investigación es tan bueno como el sistema de archivo que consulta — dale una gran biblioteca y un índice malo, y seguirá entregándote 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 que formula 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 eso es el resto de este curso.
No le preguntes al modelo qué sabe. Recupera los hechos relevantes y pídele que responda a partir de ellos — anclado, actual y citable.
Antes de poder recuperar, divides tus documentos en piezas. Cómo las cortas decide en silencio la calidad de la recuperación — es el paso menos glamoroso y uno de los más importantes.
Recuperas chunks, así que el chunk es la unidad de calidad
Un libro de consulta solo sirve cortado en entradas localizables — un único rollo gigante sin índice, o mil pedazos rotos, son ambos inútiles para buscar cosas.
No recuperas documentos enteros; recuperas chunks — pasajes de unos pocos cientos de palabras. 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 de un solo tema. Si te equivocas con el chunking, ninguna búsqueda ingeniosa ni modelo inteligente lo recupera.
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 vadeará entre ruido; dale una sola frase sin contexto alrededor y no podrá saber 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 hacía significativo el hecho. El punto justo sostiene una idea coherente con suficiente entorno para sostenerse sola. No hay un número universal; depende de tus documentos, y lo ajustas midiendo.
Corta por significado, no por número de caracteres
Dividir un libro contando caracteres puede partir una frase — o una receta — limpiamente por la mitad. Dividir por capítulos y secciones mantiene cada pieza entera.
El enfoque ingenuo trocea cada N caracteres, lo que corta a través de frases, tablas e ideas. Es mejor dividir por la estructura natural del documento — encabezados, secciones, párrafos — para que cada chunk sea un pensamiento completo. Un poco de solapamiento entre chunks adyacentes 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 gratis.
Adjunta metadatos a cada chunk
Una ficha de biblioteca no solo guarda el texto — registra el autor, la fecha y la sección, para que puedas filtrar hasta el estante exacto 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 docs de este producto, solo las políticas vigentes, solo lo que este usuario tiene permitido 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 que puedes apuntar con precisión.
Recuperas chunks, no documentos. Corta por significado, mantén cada uno autónomo y etiquétalo — la calidad del chunking pone el techo a todo lo que viene después.
Para encontrar los chunks que coinciden con una pregunta, buscas por significado, no por coincidencia de palabras. Los embeddings son el truco que hace posible «encuéntrame cosas como esta».
Los embeddings convierten el significado en coordenadas
Un mapa donde cada idea tiene una ubicación, y las cosas que significan algo parecido quedan cerca — «perro» cerca de «cachorro», ambos lejos de «declaración de impuestos».
Un embedding es una lista de números que representa el significado de un fragmento de texto, colocado en un espacio de muchas dimensiones de modo que los significados similares caen cerca unos de otros. Haces el embedding de cada chunk una vez y guardas los vectores. Ahora el «significado» tiene coordenadas, y «encontrar texto relacionado» se convierte en «encontrar puntos cercanos» — un problema que una computadora resuelve rápido.
La búsqueda vectorial encuentra por similitud, no por palabras clave
Un bibliotecario que encuentra libros por lo que tratan — «cosas como esta» — en lugar de solo coincidir con el título exacto que dijiste.
En el momento de la pregunta haces el embedding de la pregunta de la misma manera y luego buscas en el almacén los chunks cuyos vectores estén más cerca de ella. Esto es la búsqueda semántica: encuentra un chunk sobre «política de reembolsos» incluso cuando el usuario preguntó por «recuperar mi dinero», porque los significados quedan cerca. La búsqueda por palabras clave lo pasaría por alto; la búsqueda vectorial está hecha para eso.
La base de datos vectorial es el motor
Un almacén diseñado para que, dado cualquier artículo, pueda entregarte al instante los cien más similares — 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 en lugar de escanearlo todo. Es el motor de recuperación bajo RAG. No necesitas construirla — pero sí necesitas saber que ahí viven tus chunks y qué tan rápida y precisa es su búsqueda.
La similitud no es lo mismo que la relevancia
Dos pasajes pueden tratar el 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, que suele ser relevante pero no siempre. Un chunk puede tratar el tema correcto y aun así no contener la respuesta. Esta brecha — cerca en significado frente a realmente útil — es por la que la búsqueda vectorial cruda es una primera pasada potente pero no la última palabra, y por la que existe la siguiente sección.
Los embeddings le dan coordenadas al significado; la búsqueda vectorial encuentra chunks por similitud. Es potente — y «cerca en significado» no es del todo «responde la pregunta».
Aquí está la lección que arregla la mayoría de los sistemas RAG rotos: cuando las respuestas son malas, la recuperación suele ser la causa. Mete los chunks correctos y un modelo decente hace el resto.
Basura entra, basura segura de sí misma sale
Dale a alguien el archivo equivocado y pídele que lo resuma — te dará un resumen impecable de algo completamente equivocado, sonando totalmente seguro.
Una respuesta de RAG es tan buena como los chunks que se le dieron. Recupera los pasajes equivocados y el modelo responde fielmente desde el contexto equivocado, con toda su confianza habitual. El error parece «el modelo se equivocó», pero el fallo real ocurrió antes, en la recuperación. Así que cuando las respuestas son malas, inspecciona lo que se recuperó antes de tocar el prompt o el modelo.
Combina búsqueda por palabras clave y semántica
Un buscador que sabe exactamente qué significan las palabras, y otro que coincide con nombres y códigos exactos — juntos atrapan lo que cada uno por su cuenta se perdería.
La búsqueda vectorial entiende el significado pero puede tropezar con términos exactos — códigos de producto, nombres, jerga rara. La búsqueda por palabras clave clava esos pero se pierde las paráfrasis. La búsqueda híbrida ejecuta ambas y fusiona los resultados, cubriendo los puntos ciegos de la otra. Para la mayoría de los corpus reales, la híbrida le gana a cualquiera por separado, porque las preguntas reales mezclan conceptos con nombres específicos.
Reordena la lista corta
Un proceso de contratación: una primera pasada barata saca cincuenta currículos plausibles, luego un revisor cuidadoso los lee de cerca y ordena los cinco mejores de verdad.
La búsqueda de primera pasada es rápida pero tosca. Un reordenador (reranker) toma, digamos, los cincuenta mejores candidatos y puntúa cada uno contra la pregunta con más cuidado, empujando los chunks genuinamente relevantes a lo más alto. Recupera ampliamente, luego reordena hasta unos pocos precisos. Esta forma de dos etapas — recuperación amplia y barata, luego orden afilado — es una de las mejoras de mayor palanca para un sistema RAG mediocre.
Precisión y exhaustividad tiran en sentidos opuestos
Una red de agujeros anchos atrapa solo los peces grandes pero deja pasar muchos; una red fina atrapa todo, incluidas las algas. Ajustas la malla a la captura que necesitas.
Recupera muy pocos chunks y podrías perderte el que tiene la respuesta (baja exhaustividad); recupera demasiados y entierras la respuesta en texto irrelevante que diluye al modelo y cuesta tokens (baja precisión). El número correcto de chunks equilibra ambas, y es específico de tus datos y tu tipo de pregunta. No lo adivinas — lo mides, que es la siguiente sección.
La mayoría de las respuestas malas 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.
Una vez que los chunks correctos están en el contexto, el trabajo es hacer que el modelo responda estrictamente a partir de ellos — y demostrar que lo hizo. Esto es lo que convierte la recuperación en una respuesta confiable.
Responde solo a partir del texto recuperado
Un testigo instruido para declarar solo lo que vio personalmente — no lo que supone, recuerda vagamente o escuchó de oídas.
Instruye al modelo a responder solo a partir de los chunks proporcionados, y a decir que no sabe cuando la respuesta no esté ahí. Este es el núcleo del anclaje: el texto recuperado es la fuente de verdad permitida, y la memoria propia del modelo queda fuera de la mesa. No será perfecto — el modelo aún puede desviarse — pero la instrucción más el contexto correcto hacen la mayor parte del trabajo.
Las citas hacen verificables las afirmaciones
Un artículo de investigación con notas al pie permite a cualquier lector rastrear una afirmación hasta su fuente y verificarla — o detectar 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 mero acto 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 segura de sí misma.
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 llenar la laguna con confianza con una conjetura.
El fallo más peligroso de RAG es responder igual cuando la recuperación volvió vacía o fuera de objetivo. Así que haz que negarse a responder sea una salida válida y esperada: si los chunks no contienen la respuesta, el modelo debe decirlo, no improvisar de memoria. Un sistema que admite la laguna es mucho más confiable que uno que la disimula — y revela dónde tu recuperación necesita trabajo.
El anclaje reduce la alucinación — no la termina
Los cinturones de seguridad reducen las muertes drásticamente, pero aun así conduces con cuidado. Una salvaguarda fuerte no es razón para dejar de mirar la carretera.
Incluso con chunks perfectos, el modelo puede malinterpretar, sobregeneralizar o mezclar un hecho recuperado con su propia memoria. El anclaje reduce drásticamente la alucinación y la hace detectable; no la elimina. Así que aún verificas — con citas que el usuario puede comprobar, y con evals que miden la fidelidad. Trata el anclaje como un control potente, no como una garantía.
El anclaje significa que la respuesta viene solo de texto recuperado, con citas que lo prueban — y un honesto «no lo sé» cuando los hechos no están ahí.
RAG tiene dos etapas que fallan de forma distinta, así que las mides por separado. Júntalas y ajustarás la mitad equivocada durante semanas. (El curso de Evals va más a fondo; aquí está la forma específica de RAG.)
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 de RAG puede fallar porque la recuperación trajo los chunks equivocados, o porque la generación respondió mal a partir de los chunks correctos. Estas necesitan arreglos distintos, así que mídelas por separado: ¿volvieron los chunks correctos? y, dados esos chunks, ¿fue la respuesta fiel y completa? La mayoría de los equipos que «no pueden mejorar su RAG» están puntuando solo la respuesta final y adivinando a qué mitad culpar.
Recuperación: ¿volvieron los chunks correctos?
Antes de juzgar el ensayo, comprueba que al estudiante siquiera le entregaron las páginas de referencia correctas — si no, nada de lo que escribió podía estar bien.
Evalúa la recuperación por su cuenta: para un conjunto de preguntas con documentos relevantes conocidos, ¿devolvió la búsqueda esos documentos en los primeros resultados? Esto atrapa el mal chunking, la búsqueda débil y la falta de reordenamiento directamente — las causas anteriores de la mayoría de las respuestas malas. Arregla la recuperación primero, porque ninguna mejora al prompt o al modelo puede rescatar una respuesta construida a partir de los chunks equivocados.
Generación: ¿fue la respuesta fiel a los chunks?
Un verificador de hechos lee la respuesta contra las fuentes citadas y marca cualquier frase que las fuentes no respalden realmente.
Una vez que la recuperación es buena, evalúa la respuesta por su fidelidad: ¿está cada afirmación respaldada por los chunks recuperados, sin nada inventado y sin nada contradicho? Comprueba también que de verdad usó lo que se recuperó y que respondió la pregunta. Aquí es donde atrapas al modelo desviándose del contexto sólido — y es medible, a menudo con otro modelo como evaluador.
Construye el eval a partir de preguntas reales
Pruebas un puente con los camiones que de verdad lo cruzarán, no con los pesos que te resulten cómodos.
Tu conjunto de eval deberían ser preguntas reales que los usuarios hacen, incluidas las desordenadas y las fuera de alcance, cada una emparejada con los chunks que deberían recuperarse y una respuesta conocida como buena. Ejecútalo en cada cambio para ver si una nueva estrategia de chunking o un reordenador de verdad ayudaron. Sin esto, ajustas RAG por anécdota — y las anécdotas mienten.
RAG falla en dos lugares. Mide la recuperación y la generación por separado, arregla la recuperación primero y construye el eval a partir de preguntas reales.
RAG es potente y a menudo se usa de más. La habilidad está en usarlo cuando se gana su lugar, mantener los datos frescos y no pagar por maquinaria que un enfoque más simple se habría ahorrado.
No hagas RAG de lo que podrías simplemente pegar
No construyes un catálogo de biblioteca para los tres libros de tu escritorio — simplemente los abres.
Si los hechos relevantes son pequeños y fijos — unos pocos documentos, una política breve — 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 una tubería de recuperación sobre tres páginas es el equivalente en sobreingeniería de un bucle de agente para una sola llamada. Recúrrele cuando los datos te obliguen.
Datos rancios son datos equivocados
Una guía telefónica solo sirve si se reimprime — los números de la década pasada están equivocados con confianza e inutilidad.
La promesa de RAG son hechos actuales, lo que significa que tu índice tiene que mantenerse al día. Cuando los documentos de origen cambian, los chunks y los embeddings deben actualizarse, o el modelo anclará sus respuestas en texto confiado y desactualizado. Planifica la reindexación como parte del sistema, no como una ocurrencia tardía — la frescura es una característica que tienes que mantener, no una propiedad que obtienes una sola vez.
Vigila el costo y la latencia
Cada paso extra en la tubería — embeber, buscar, reordenar, rellenar el 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, contextos más grandes — todo mejora la calidad hasta cierto punto y sube la factura todo el camino. Así que ajusta para los menos chunks que respondan bien, cachea donde puedas, y recuerda que una gran respuesta que es 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 una 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: recúrrele cuando el modelo necesite tus hechos, y mantenlo detrás de una interfaz limpia como cualquier dependencia. La recuperación alimenta al modelo; no reemplaza el criterio en torno al modelo. La misma disciplina que en todas partes — usa el peldaño más simple que funcione, y mantén el modelo intercambiable.
- ¿De verdad hace falta RAG — o los hechos son lo bastante pequeños y estables para pegarlos en el prompt? - ¿Cómo están divididos en chunks los documentos — por significado, autónomos, con metadatos y un poco de solapamiento? - ¿La recuperación es híbrida y reordenada, o una búsqueda vectorial cruda que nunca mediste? - ¿Responde el modelo solo a partir del texto recuperado, cita fuentes y dice «no lo sé»? - ¿Cuál es el eval de la recuperación, separado de la generación? - ¿Cómo se mantiene fresco el índice, y cuánto cuesta una consulta en tiempo y tokens?
- Las respuestas están equivocadas con confianza, y nunca miraste los chunks que se recuperaron. - Solo búsqueda vectorial cruda — sin respaldo por palabras clave, sin reordenamiento. - 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 los documentos de origen cambiaron.
- Los chunks son semánticos y autónomos, etiquetados con metadatos para filtrar y citar. - La recuperación es híbrida + reordenada, ajustada a los menos chunks que respondan bien. - Las respuestas están ancladas y citadas, con una negativa honesta cuando los hechos no se recuperan. - Mides la recuperación y la generación por separado, y arreglaste la recuperación primero. - El índice tiene un plan de frescura, y RAG está detrás de una interfaz que podrías intercambiar.
RAG es un sistema de búsqueda con un modelo al final. Acierta con los chunks y la respuesta llega — el modelo rara vez fue el problema.