¿Qué es RAG (generación aumentada por recuperación) y cuándo lo necesitas?
RAG le da a un modelo de lenguaje tus documentos en el momento de la pregunta en lugar de integrarlos en los pesos. Así es como funciona el pipeline, por qué la mayoría de los fallos de RAG son fallos de recuperación y cuándo un enfoque más simple gana.
Respuesta rápida
¿Qué es la generación aumentada por recuperación (RAG)?
La generación aumentada por recuperación es un patrón en el que el sistema busca en sus propios documentos pasajes relevantes para una pregunta, introduce esos pasajes en el prompt del modelo y le pide al modelo que responda utilizándolos. Los pesos del modelo nunca cambian; el conocimiento llega como contexto en el momento de la solicitud.
Claves
- RAG es búsqueda más prompting. Si el paso de búsqueda devuelve los pasajes incorrectos, ningún modelo puede rescatar la respuesta.
- La similitud vectorial por sí sola es débil en nombres, códigos y frases exactas; la recuperación híbrida de palabras clave más vectores es la opción práctica por defecto.
- Se actualiza al instante: cambia el documento y la siguiente respuesta cambia. El ajuste fino no puede hacer eso.
- Las citas son el punto. Las respuestas fundamentadas que enlazan al pasaje de origen son auditables de una manera que la generación bruta no lo es.
Un modelo de lenguaje sabe lo que había en sus datos de entrenamiento y nada más. No conoce los términos de su contrato, las cifras del último trimestre ni el informe de incidentes presentado ayer. La generación aumentada por recuperación (RAG) es la forma estándar de cerrar esa brecha sin tener que volver a entrenar nada.
El proceso, de principio a fin
RAG tiene dos fases. La primera ocurre con antelación.
Indexación (offline)
- Recopile los documentos.
- Divídalos en pasajes —típicamente de unos pocos cientos a un par de miles de tokens cada uno.
- Calcule un embedding para cada fragmento: un vector de números que posiciona ese texto en un espacio donde los significados similares se encuentran juntos.
- Almacene los vectores, el texto original y los metadatos (fuente, sección, fecha, permisos) en un índice.
Respuesta (por solicitud)
- Tome la pregunta del usuario y aplíquele el mismo embedding.
- Recupere los fragmentos más cercanos —a menudo combinado con una búsqueda por palabras clave.
- Opcionalmente, reordene los candidatos con un modelo más pequeño que puntúa la relevancia con mayor precisión que la distancia vectorial bruta.
- Ensambla un prompt: instrucciones, los pasajes recuperados, la pregunta.
- Genere la respuesta, con instrucciones para citar de qué pasaje provino cada afirmación.
Esa es toda la idea. La astucia está en el paso de recuperación, no en el paso de generación.
La mayoría de los fallos de RAG son fallos de recuperación
Cuando un sistema RAG da una respuesta incorrecta, el instinto es culpar al modelo. Casi siempre es la búsqueda.
Antes de cambiar nada más, ejecute esta comprobación: tome la pregunta fallida, mire los pasajes que se recuperaron realmente y pregúntese si un humano cuidadoso podría haber respondido correctamente a partir de ellos. Si no, al modelo nunca se le dio una oportunidad.
Causas comunes, aproximadamente en orden de frecuencia:
- Desajuste de vocabulario. El usuario pregunta por "terminación"; el contrato dice "cancelación". La búsqueda vectorial pura maneja esto razonablemente bien; la búsqueda por palabras clave pura no.
- Identificadores exactos. El usuario pregunta por la factura
INV-2024-8871. La búsqueda vectorial es mala en esto —el embedding de un identificador casi no tiene significado. La búsqueda por palabras clave lo encuentra al instante. Este es el argumento más sólido para la recuperación híbrida: ejecute ambas, fusione las clasificaciones. - Malos límites de fragmentos. La definición está en un fragmento, la excepción en el siguiente, y solo se recuperó uno.
- Filtros de metadatos faltantes. La respuesta provino de un documento que el usuario no tiene permitido ver, o de una versión reemplazada. Filtre por permiso y validez antes de la similitud, no después.
- Muy pocos resultados. Recuperar tres fragmentos es eficiente y frágil. Recupere veinte, reordene, mantenga los cinco mejores.
Cuándo RAG es la herramienta equivocada
RAG no es gratis. Añade un índice que mantener, un problema de calidad de recuperación que monitorizar y latencia a cada solicitud. Sáltelo cuando:
- El corpus es pequeño. Si toda su base de conocimientos son 20 páginas, póngala en el prompt del sistema y cáchela.
- La pregunta no trata sobre documentos. Las agregaciones —"¿cuántos pedidos se enviaron tarde el mes pasado?"— pertenecen a SQL. Dele al modelo una herramienta de consulta en lugar de un índice vectorial.
- La tarea es de estilo, no de hechos. Hacer que el modelo escriba con la voz de su empresa es un problema de prompting o de ajuste fino.
También hay un camino intermedio que vale la pena conocer: la recuperación agentiva, donde al modelo se le da una herramienta de búsqueda y emite sus propias consultas, refinándolas después de ver los resultados. Cuesta más solicitudes pero maneja preguntas de varios saltos ("compare las políticas de 2024 y 2025") que una sola pasada de recuperación se pierde.
Cómo hacer que las respuestas sean confiables
Tres prácticas hacen la mayor parte del trabajo:
Exija citas. Pida al modelo que adjunte un identificador de fuente a cada afirmación y que las represente como enlaces. Los usuarios pueden entonces comprobarlo, y usted puede medir con qué frecuencia el pasaje citado realmente apoya la oración.
Permita la negativa. Instruya explícitamente: si los pasajes recuperados no responden a la pregunta, diga que no lo sabe. Sin esto, un modelo servicial llena el vacío con su conocimiento general —que puede ser correcto, incorrecto o sobre una empresa completamente diferente.
Evalúe la recuperación por separado. Construya un conjunto de pares de preguntas y pasajes correctos y rastree la recuperación en k. Este número le dice si la recuperación está mejorando, independientemente de cómo se lean las respuestas. Los equipos que solo miran las respuestas finales ajustan a ciegas.
Cómo se ve lo bueno
Un sistema RAG maduro es aburrido de una manera específica: responde a partir de sus documentos, enlaza a ellos, admite cuando no puede encontrar algo y muestra el mismo comportamiento hoy que mañana. Llegar allí es principalmente ingeniería de búsqueda —chunking, recuperación híbrida, reordenamiento, filtros— con el modelo de lenguaje haciendo el último y más pequeño paso.
Si está eligiendo dónde pasar una semana de trabajo, pásela en la recuperación.
Preguntas frecuentes
- ¿Es RAG mejor que el ajuste fino?
- Resuelven diferentes problemas. RAG suministra hechos que el modelo no tiene; el ajuste fino enseña formato, tono o una habilidad específica. Si tu problema es 'no conoce nuestros datos', usa RAG. Si es 'no responde como queremos', considera el ajuste fino.
- ¿Hace que una ventana de contexto muy grande RAG sea obsoleta?
- Reduce la presión pero no elimina la necesidad. Enviar un corpus completo en cada solicitud es costoso y lento, y la precisión aún sufre con entradas muy largas. La recuperación mantiene cada solicitud pequeña y relevante.
- ¿Por qué mi sistema RAG todavía alucina?
- Generalmente porque la recuperación no devolvió nada útil y el modelo respondió de todos modos. La solución es una instrucción y verificación explícitas: si los pasajes recuperados no contienen la respuesta, dígalo.
- ¿Qué es la fragmentación y por qué es importante?
- Chunking es cómo se dividen los documentos antes de indexarlos. Los fragmentos demasiado pequeños pierden el contexto circundante; los fragmentos demasiado grandes diluyen la coincidencia. Dividir según la estructura del documento —secciones y encabezados— suele ser mejor que dividir por un recuento fijo de caracteres.