RAG, explicado de forma interactiva

¿Cómo funciona un pipeline de RAG, paso a paso?

Un sistema de RAG tiene dos mitades que corren en momentos distintos. La primera es la indexación, y pasa antes de que alguien pregunte nada. Traes los documentos, cortas cada uno en chunks (trozos) de unos cientos de tokens, pasas cada chunk por un modelo de embeddings que convierte texto en una lista de números, y guardas esos números junto al texto original en un índice que se puede buscar. Aquí nadie le está enseñando nada al modelo. Estás armando una biblioteca con un buen catálogo.

La segunda mitad corre cuando llega una pregunta. La pregunta se convierte en números con el mismo modelo de embeddings, se busca en el índice los pasajes cuyos números quedan más cerca, y vuelven los mejores, normalmente entre cinco y veinte. Un paso opcional de reranking los reordena con más cuidado. Y luego viene el paso del que habla el nombre: la aumentación. Los pasajes elegidos se pegan en el prompt arriba de la pregunta, con una instrucción del tipo 'responde usando solo el texto de abajo, y di qué pasaje usaste'. El modelo genera su respuesta a partir de eso.

Fíjate en lo que nunca ocurre: ningún peso cambia, no arranca ningún entrenamiento, nada del modelo es distinto de una pregunta a la siguiente. RAG es plomería alrededor de un modelo congelado. La lección interactiva de este sitio te deja mover la manivela tú, lanzando una consulta, viendo qué pasajes vuelven y viendo cómo cambia la respuesta cuando se cuela un pasaje equivocado en el context.

• Ingesta: reúne los documentos, quita el formato, guarda títulos y fechas como metadatos.
• Chunking: córtalos en pasajes recuperables, típicamente de unos cientos de tokens con algo de solapamiento.
• Embeddings e índice: guarda cada chunk como vector más su texto, para poder buscarlo por significado.
• Retrieval: convierte la pregunta en embedding, trae los chunks más cercanos y, si quieres, reordénalos.
• Aumentación y generación: pega los ganadores en el prompt y pide una respuesta anclada y citada.

¿Por qué los productos usan RAG en vez de reentrenar el modelo?

Reentrenar mete la información dentro de los pesos, y los pesos son un archivador terrible. Un entrenamiento cuesta dinero real y toma tiempo, así que tu conocimiento siempre es tan viejo como la última corrida. No puedes señalar de dónde salió una respuesta, porque el dato queda embadurnado entre miles de millones de números y no guardado en ningún lugar. No puedes borrar un dato concreto de forma confiable cuando un cliente te lo pide. Y no puedes darle acceso distinto a dos empleados, porque el modelo que aprendió un documento lo aprendió para todos.

El retrieval arregla esas cuatro cosas dejando los documentos fuera del modelo. Publicar una política corregida es una edición y una reindexación, no un entrenamiento, y la siguiente pregunta ya la usa. La respuesta puede citar el pasaje que utilizó, que es lo que la vuelve auditable. Borrar un documento lo saca del índice. Y como el retrieval es una búsqueda que tú controlas, puedes filtrarla por permisos antes, así cada usuario solo recibe pasajes que tiene derecho a ver.

Nada de esto vuelve inútil al fine-tuning. El fine-tuning es cómo cambias el comportamiento: un tono de voz propio, un formato de salida estricto, un vocabulario del dominio, una forma de negarse. Conocimiento y comportamiento son problemas distintos, y muchos sistemas serios hacen los dos, ajustando la manera con fine-tuning y recuperando el contenido con RAG.

¿Qué es el retrieval, en realidad?

La respuesta por defecto en 2026 es la búsqueda por embeddings, también llamada densa o semántica. Un modelo de embeddings lee un chunk de texto y devuelve una lista larga de números que codifica su significado, así que los pasajes que hablan de cosas parecidas caen cerca en ese espacio numérico. Buscar es convertir la pregunta en embedding y preguntar qué vectores guardados están más cerca, normalmente por similitud de cosenos. La ganancia es que 'cuántos días libres me tocan' puede encontrar un pasaje titulado 'derecho a vacaciones anuales' aunque no compartan ni una palabra. Una base de datos vectorial es solo un almacén hecho para que esa búsqueda de vecinos cercanos sea rápida sobre millones de chunks.

La búsqueda por significado tiene un punto ciego: las cadenas exactas. Números de parte, códigos de error, IDs de factura, apellidos y jerga rara son justo donde los embeddings mezclan cosas. La vieja puntuación por palabras clave, casi siempre BM25, es excelente exactamente en eso. Por eso los sistemas maduros usan retrieval híbrido, los dos métodos a la vez, y fusionan las dos listas ordenadas. Las comparaciones publicadas reportan de forma consistente una mejora real de la combinación y no de cada mitad por separado. Un análisis de un benchmark de e-commerce de 2026 reportó alrededor de 91% de recall en los diez primeros resultados con búsqueda híbrida, contra cerca de 78% con solo embeddings y 65% con solo palabras clave, con una mejora de un dígito parecida en las métricas de ranking. Toma las cifras exactas como ilustrativas de la dirección, no como constantes universales.

La última pieza común es el reranking. Un reranker, típicamente un cross-encoder, lee juntos la pregunta y un pasaje candidato y puntúa el par en serio, en vez de comparar dos vectores independientes. Eso es mucho más preciso y demasiado lento para correrlo sobre todo el corpus, así que el patrón estándar es un retrieval barato de cincuenta a cien candidatos y después un reranking hasta los cinco que de verdad vas a pegar. Suele ser lo de mayor valor que puedes añadirle a un pipeline mediocre.

¿Dónde se rompe RAG, y por qué casi siempre es el retrieval?

El generador solo puede trabajar con lo que le pasaron, así que el retrieval pone el techo de la calidad. Si el pasaje que tiene la respuesta nunca volvió, ninguna redacción del prompt te salva: el modelo responderá con sus propios patrones generales, en el mismo tono seguro que usa cuando acierta. Por eso el primer movimiento al depurar una respuesta mala de RAG nunca es editar el prompt. Es mirar los pasajes que de verdad se recuperaron y preguntarse si una persona atenta habría podido responder con ellos.

Los modos de fallo son aburridamente mecánicos, y eso es buena noticia, porque los problemas mecánicos tienen arreglo. Casi todos vienen de cómo se cortaron los documentos y de qué se perdió al entrar.

Un fallo merece mención aparte porque no es un retrieval fallido: las fuentes en conflicto. Cuando el índice tiene la política del año pasado y la de este año, el retrieval devuelve las dos encantado, y el modelo elige una sin forma de saber cuál está vigente. Fechas en los metadatos, deduplicación e instrucciones para preferir la fuente más nueva son las respuestas prácticas. Recuerda también que el texto recuperado es entrada no confiable. Si alguien más puede editar un documento, ese documento puede llevar instrucciones dirigidas a tu modelo, y por eso los datos de anclaje nunca deben tratarse como una parte confiable del prompt.

• Respuestas partidas: el dato queda en el límite entre dos chunks, así que ninguno convence por sí solo.
• Chunks enormes: un chunk largo cubre cinco temas, así que su vector coincide débilmente con todo y fuerte con nada.
• Tablas aplanadas: una tabla convertida en texto corrido pierde la relación entre encabezados y valores, una causa muy citada de fallos silenciosos en empresas.
• Contexto ausente: un chunk dice 'esto no aplica en ese caso' sin señal de qué documento o sección venía.
• Brecha de vocabulario: los usuarios preguntan con sus palabras, los documentos usan jerga interna, y la búsqueda por embeddings sola nunca cruza ese puente.
• Índice viejo: el documento se actualizó, el índice no, y el sistema cita con total seguridad un párrafo borrado.

¿Sigue teniendo sentido RAG con ventanas de contexto de un millón de tokens?

Las ventanas de contexto se volvieron enormes de verdad. Para 2026 un millón de tokens es lo normal en la frontera, algunos modelos anuncian más, y eso sí mató la razón más débil para usar RAG, que era que los documentos simplemente no cabían. Si toda tu base de conocimiento son un par de manuales y cambia poco, pegarlos y saltarte la infraestructura hoy es una decisión sensata, y el prompt caching abarata repetirlos.

Lo que el tamaño no arregló es el costo, la latencia y la precisión a escala. Pagas tokens de entrada en cada pregunta, así que un prompt de un millón de tokens sale órdenes de magnitud más caro por respuesta que unos pocos pasajes recuperados, y es notablemente más lento hasta la primera palabra. La precisión también decae con datos enterrados en el medio de una entrada muy larga, un efecto bien documentado, así que más contexto no es automáticamente más correcto. Y muchos corpus reales, un wiki de empresa, un archivo de soporte, un monorepo de código, llegan a cientos de millones de tokens, que no caben en ninguna ventana.

Así que el encuadre honesto de 2026 no es RAG contra contexto largo, es RAG alimentando al contexto largo. El retrieval reduce un corpus gigante a una porción generosa y relevante, y la ventana grande te permite ser menos quirúrgico: puedes permitirte cincuenta pasajes en vez de cinco, lo que perdona bastante ranking imperfecto. Y conservas lo que una ventana nunca te dio, el filtrado por permisos de cada usuario, las citas y un índice que puedes actualizar esta tarde.

¿Cómo saben los equipos si su RAG funciona?

La costumbre útil es puntuar las dos mitades por separado, porque fallan por razones distintas y solo una se arregla con prompting. Del lado del retrieval, el context recall pregunta si el pasaje que contiene la respuesta se recuperó siquiera, y el context precision pregunta cuánto texto irrelevante vino de arrastre. Del lado de la generación, la groundedness, muchas veces llamada faithfulness, pregunta si cada afirmación de la respuesta está de verdad respaldada por el texto recuperado, y la answer relevancy pregunta si la respuesta atendió la pregunta que se hizo.

En la práctica eso se convierte en un set de evals pequeño y poco glamoroso. Junta entre cincuenta y un par de cientos de preguntas reales, anota qué pasaje fuente debería responder cada una, y mide primero el recall en los k primeros resultados. La calidad del retrieval es el techo, así que ajustar el prompt mientras el recall está mal es trabajo tirado. Cuando el retrieval está sano, la groundedness se suele puntuar pidiéndole a otro modelo que revise cada afirmación contra los pasajes, con revisión humana por muestreo para mantener honesto al juez. Frameworks abiertos como RAGAS, DeepEval, TruLens y Arize Phoenix ya empaquetan estas métricas para que no armes el andamiaje tú.

Y luego está la parte que solo enseña producción. Registra los chunks recuperados junto a cada respuesta, para que un reclamo se pueda rastrear en vez de discutir. Mide con qué frecuencia no se encontró nada bueno, porque esa tasa es tu verdadero hueco de contenido. Y deja que el sistema diga que no sabe cuando los pasajes no sostienen una respuesta. Una negativa honesta es barata. Una respuesta fluida, bien citada y equivocada es lo que erosiona la confianza en todo el producto.

Lo que la gente entiende mal

Dónde lo ves en productos reales

Preguntas frecuentes

Explicadores relacionados

Más en Construir encima, y confiar en ello