Una IA que responde con tus documentos: la técnica RAG, paso a paso

Prueba a preguntar a un asistente de IA genérico cuál es tu procedimiento interno de devoluciones, o qué dice la última versión de un pliego de condiciones: no puede saberlo, porque nunca ha visto esos documentos. En el mejor de los casos lo reconoce; en el peor, se inventa una respuesta verosímil.

La técnica que resuelve el problema se llama RAG, de retrieval-augmented generation: generación aumentada por recuperación de información. Antes de responder, el sistema busca en tus documentos los fragmentos pertinentes y se los entrega al modelo de lenguaje (el LLM, el motor de herramientas como ChatGPT, Claude o Gemini) junto con la pregunta. El modelo no tiene que “recordar” nada: lee, en el momento, las páginas adecuadas.

Veamos cómo funciona paso a paso, por qué suele convenir más que reentrenar un modelo y qué separa un prototipo que luce en una demo de un sistema en el que las personas pueden confiar cada día.

Cómo funciona, paso a paso

El trabajo se divide en dos fases: la preparación de los documentos, que se hace una vez y luego se mantiene al día, y la respuesta, que se produce con cada pregunta.

1. Recopilación: PDF, páginas de wiki, manuales, tickets, correos. Se extrae el texto y se guardan los metadatos útiles: título, fecha, versión, quién puede leerlo.
2. División en fragmentos (chunking): cada documento se corta en porciones de unos pocos párrafos, lo bastante pequeñas para ser precisas y lo bastante grandes para tener sentido por sí solas.
3. Embeddings: un modelo específico convierte cada fragmento en un vector, una larga secuencia de números que representa su significado. Los textos que hablan de lo mismo tienen vectores cercanos, aunque usen palabras distintas.
4. Almacenamiento: vectores, texto y metadatos van a una base de datos vectorial como Milvus, diseñada para encontrar rápidamente los elementos más parecidos, incluso entre millones de registros.
5. Recuperación: cuando llega una pregunta, también se convierte en vector y la base de datos devuelve los fragmentos más cercanos, es decir, los más pertinentes.
6. Respuesta: el modelo de lenguaje recibe la pregunta y los fragmentos encontrados, con la instrucción de responder solo a partir de ellos. Como cada fragmento lleva consigo su documento de origen, la respuesta puede citar las fuentes y quien la lee puede comprobarlas.

¿Por qué no “enseñar” los documentos al modelo?

La primera alternativa que viene a la cabeza es el fine-tuning, es decir, reentrenar un modelo con los propios documentos. Para el conocimiento de la empresa, en la mayoría de los casos RAG es la mejor opción:

• Actualización: un documento nuevo o corregido entra en el índice en pocos minutos, mientras que un modelo reentrenado habría que volver a entrenarlo.
• Fuentes: RAG muestra de dónde sale la respuesta; un modelo que ha “aprendido” un contenido no sabe decir dónde lo leyó.
• Permisos: se puede filtrar qué recuperar según quién pregunta. Una información absorbida por el modelo, en cambio, no se puede ocultar a un usuario.
• Coste y libertad: no hay que pagar ningún entrenamiento y se puede cambiar de modelo de lenguaje sin rehacer el trabajo sobre los documentos.

El fine-tuning sigue siendo útil para otras cosas: enseñar un estilo, un formato de respuesta o una tarea muy concreta. Cuando hace falta, las dos técnicas se combinan.

Qué decide la calidad de las respuestas

Lo que llama la atención es el modelo, pero la calidad se decide casi toda antes, en la preparación y en la recuperación. Estos son los factores que hay que cuidar:

• Documentos en orden: versiones obsoletas, duplicados y PDF escaneados sin texto producen respuestas viejas, contradictorias o vacías. A menudo el primer trabajo es hacer limpieza.
• División con criterio: partir una tabla por la mitad o separar un título de su párrafo empeora la recuperación. Conviene seguir la estructura del documento (secciones, títulos, listas), no solo el número de caracteres.
• Recuperación bien ajustada: combinar la búsqueda por significado con la búsqueda por palabras clave (búsqueda híbrida) ayuda con códigos, siglas y nombres propios; un segundo paso que reordena los resultados (reranking) elige mejor los fragmentos que se pasan al modelo.
• Permisos respetados: el sistema debe aplicar los mismos derechos de acceso que los documentos originales. El filtro se hace en la recuperación, no se confía a las instrucciones del modelo.
• Índice al día: cuando un documento cambia o se elimina, el índice debe seguirlo con un proceso automático, no a mano.
• Evaluación con preguntas reales: hace falta una lista de preguntas recogidas entre quienes usarán el sistema, con las respuestas esperadas. Se mide si la recuperación encuentra los fragmentos correctos y si la respuesta es correcta y fiel a las fuentes, y la prueba se repite con cada cambio.

Las herramientas habituales

Un sistema RAG se construye con pocas piezas, y para cada una existen componentes open source y servicios gestionados:

• Orquestación: frameworks como LangChain conectan los pasos (carga, división, recuperación, llamada al modelo) y permiten sustituir un componente sin reescribir el resto.
• Base de datos vectorial: Milvus es open source y se puede instalar en servidores propios o usar como servicio gestionado.
• Modelos de embeddings: en Hugging Face hay muchos, también multilingües, para ejecutar en casa; OpenAI y Google también los ofrecen a través de sus API.
• Modelo de lenguaje: OpenAI, Claude de Anthropic o Gemini de Google a través de sus API, o un modelo que se ejecuta en tus servidores, por ejemplo con Ollama. La elección depende de la confidencialidad, la calidad y los costes, y es el tema de nuestro artículo sobre modelos en casa o en la nube.

Una nota práctica: si cambias el modelo de embeddings, hay que recalcular los vectores de todos los documentos. El modelo de lenguaje, en cambio, se puede sustituir sin tocar el índice.

Por dónde empezar

Un primer proyecto debería tener un alcance pequeño y claro: un conjunto de documentos con un responsable, un grupo de usuarios que hoy pierde tiempo buscando y una lista de preguntas de prueba. Con esos tres elementos se construye un piloto, se mide y se decide si ampliarlo. Indexar todo el archivo de la empresa desde el primer día, en cambio, es la forma más rápida de obtener respuestas mediocres.

Si tienes manuales, procedimientos, contratos o tickets que a las personas les cuesta consultar, podemos empezar juntos con un piloto de alcance reducido y medirlo con tus preguntas reales. Escríbenos y lo hablamos.