Saltar al contenido
Empieza un proyecto
Capítulo 03 · 13 min

La recuperación bien hecha

La generación aumentada por recuperación (RAG) es el patrón más útil y de menor riesgo de la IA aplicada, y el que con más frecuencia se construye mal. La versión ingenua luce de maravilla en una demo y fracasa en producción por un puñado de razones predecibles. Este capítulo trata de esas razones y sus arreglos.

“No obligues al modelo a memorizar la biblioteca. Dale las tres páginas que necesita, abiertas en el párrafo correcto.”

Qué es realmente el RAG

El RAG separa lo que el sistema sabe de lo que el sistema dice. El conocimiento vive en un índice que controlas y puedes actualizar cada hora. El modelo solo aporta el lenguaje y el razonamiento sobre lo que le pongas delante. Cuando llega una pregunta, buscas en el índice, recuperas los pasajes más relevantes y los colocas en el prompt como contexto.

RAG: retrieval-augmented generation pipelineA pipeline from left to right: a user query is sent to a search system, which finds the most relevant chunks from a document store. Those chunks are added to the prompt and sent to the LLM, which produces an answer grounded in the retrieved context.userquerysearchvector + BM25top chunksfrom your docspromptquery + contextLLManswerINDEXthe model answers from context, not from memory
El modelo responde a partir de los fragmentos recuperados, no de sus datos de entrenamiento. Actualizas el índice, nunca el modelo.

Esta es la respuesta correcta a casi todos los problemas de «chatea con nuestros documentos», «asistente de soporte» o «conocimiento interno». Es más barato que el fine-tuning, actualizable en tiempo real y, sobre todo, auditable: puedes mostrar exactamente de qué fuente vino la respuesta.

El pipeline ingenuo, y por qué se rompe

La versión de demo: divide cada documento en fragmentos fijos de 500 tokens, haz embedding de cada uno, guárdalos en una base de datos vectorial, haz embedding de la consulta, toma los cinco fragmentos más cercanos y mételos en el prompt. Funciona en unas FAQ ordenadas y se desmorona en conjuntos de documentos reales. Aquí es donde:

  • Mal troceado: la respuesta queda repartida entre dos fragmentos, así que ninguno basta por sí solo.
  • Fallo de recuperación: el pasaje relevante no aparece en los primeros resultados porque la consulta y el documento usan palabras distintas.
  • Modelo de embedding equivocado: tu dominio (legal, médico, jerga interna) no está bien representado, así que los vectores «similares» no lo son de verdad.
  • Contexto ignorado: el modelo tiene el pasaje correcto pero responde igualmente desde sus datos de entrenamiento.
  • Índice obsoleto: el documento cambió; el índice no.

El patrón que llega a producción: híbrido + reordenar + citar

Tres añadidos arreglan la mayoría de los RAG en producción. Primero, la búsqueda híbrida: combina la similitud vectorial con la búsqueda por palabras clave a la antigua (BM25). La búsqueda vectorial capta el significado; la búsqueda por palabras clave capta los términos exactos (códigos de error, nombres, referencias) que los vectores difuminan. Ejecuta ambas y fusiona los resultados.

Segundo, el reordenamiento. Recupera con una red amplia (cincuenta candidatos), luego puntúalos con un reordenador más preciso (y más caro), y quédate solo con los cinco mejores para el prompt. Obtienes la cobertura de una búsqueda amplia con la precisión de una minuciosa.

Retrieve wide, then re-rank to a fewThree shrinking boxes from left to right: retrieve a wide net of 50 candidates, re-rank them with a more precise model, then keep only the top 5 to put in the prompt. Recall first, precision second.retrieve widetop 50re-rankcross-encoderkeep besttop 5
Lanza una red amplia para la cobertura, luego reordena para la precisión. El modelo solo ve los pocos pasajes con más probabilidad de contener la respuesta.

Tercero, las citas. Haz que el modelo cite el id del fragmento que usó para cada afirmación. Esto vuelve auditable la respuesta, te permite mostrar las fuentes en la interfaz y reduce, de forma medible, que el modelo se aleje del texto recuperado.

Cuándo la recuperación es la herramienta equivocada

El RAG responde a preguntas cuya respuesta está escrita en algún sitio. No ayuda con preguntas que requieren razonar sobre todo el corpus («¿cuáles son los tres grandes temas de estos 10 000 tickets?») ni con el cálculo («¿cuál es nuestro tiempo medio de resolución?»). Esas requieren agregación, analítica o herramientas (que se ven en el siguiente capítulo), no recuperación.

Retrieval versus reasoningA 2-by-2 quadrant. The horizontal axis goes from retrieval-heavy to reasoning-heavy. The vertical axis goes from easy to hard. Tasks like "name a capital" and "summarise this article" sit in the easy retrieval corner; long-horizon planning sits in the hard reasoning corner.HARD ↑EASY← RETRIEVALREASONING →name a capitalsummarise this articlesolve this puzzlelong-horizon planwrite a function
La recuperación brilla en «encuentra el pasaje que responde a esto». Se atasca en cuanto la tarea se desplaza hacia razonar sobre todo a la vez.

Una línea por cada uno

  • El RAG separa lo que el sistema sabe (el índice) de lo que dice (el modelo). Actualiza el índice, no el modelo.
  • El RAG ingenuo se rompe por el troceado, los fallos de recuperación, los embeddings equivocados, el contexto ignorado y los datos obsoletos; todo invisible sin evaluaciones.
  • El patrón que llega a producción: búsqueda híbrida + reordenar + citas.
  • El RAG responde a «encuentra el pasaje», no a «razona sobre todo» ni «calcula un número»; esos necesitan herramientas.

Adónde ir ahora

La recuperación bien hecha · Cursos de IA · SDEN