Imagina que contratas a un becario brillante, con dos carreras y un máster, capaz de hablar con soltura de cualquier tema. El primer día le pides que te ayude a redactar un informe basándose en los protocolos internos de tu servicio. El becario, por mucho que sepa, no ha leído tus protocolos. Le tendrás que dar acceso a ellos. Hay dos formas de hacerlo: o le mandas a memorizarlos durante dos meses como si fuera otro examen, o le instalas en un escritorio un dispositivo con los protocolos incorporados, y le enseñas a buscar lo que necesite cuando lo necesite.
El primer camino, meter tus documentos «dentro» del modelo, se llama fine-tuning. Es caro, lento, exige equipo técnico, hay que rehacerlo cada vez que un protocolo cambia, y los datos quedan fundidos con los pesos del modelo de una forma que no admite borrado selectivo. El segundo camino, mantener tus documentos fuera y enseñarle a consultarlos, se llama RAG, de Retrieval-Augmented Generation: generación aumentada con recuperación. Es lo que va a estar detrás del 90% de las aplicaciones de IA con datos propios que merezca la pena montar en los próximos años.
RAG funciona en dos pasos. Primero, recuperas. Cuando un usuario hace una pregunta, antes de pasársela al modelo, un sistema busca en tu colección de documentos, protocolos, guías, fichas técnicas, lo que sea, los fragmentos que tienen más probabilidad de contener la respuesta. Después, generas. Le entregas al modelo la pregunta original junto con esos fragmentos, y le pides que responda basándose en ellos. La ventaja es directa: el modelo deja de adivinar, y empieza a citar.
El truco está en cómo se hace esa búsqueda inicial, porque no se hace por palabras clave como en Google. Lo que se usa son embeddings. Un embedding es una representación numérica de un fragmento de texto, un vector de varios cientos de números, que captura su significado, no sus letras. Dos textos con palabras distintas pero significado parecido («el paciente presenta hipertensión» y «el enfermo tiene la tensión alta») acaban con embeddings muy cercanos en ese espacio de números. Una búsqueda por embeddings es, en el fondo, una búsqueda por sentido: le pides al sistema que te traiga los fragmentos cuyo embedding se parezca más al embedding de tu pregunta.
Para que esto funcione, los documentos pasan por un proceso previo que se hace una sola vez. Se trocean en fragmentos del tamaño manejable, pongamos, párrafos de 500 palabras o secciones de un protocolo, se calcula el embedding de cada fragmento con un modelo especializado (no es el mismo modelo que después responde), y todos esos embeddings se guardan en una base de datos vectorial. Hay varias: Chroma, Weaviate, Qdrant, pgvector. Cualquiera vale para empezar. La base de datos guarda los vectores junto con el texto original y, cuando llega una pregunta, devuelve los k fragmentos más parecidos en milisegundos.
Lo que hace el RAG genuinamente interesante para entornos sanitarios, y para cualquier entorno donde los datos importan, es lo que no hace. No reentrena el modelo. Tus documentos no acaban incrustados en sus pesos. Se quedan en tu base de datos, bajo tu control. Si mañana tienes que actualizar un protocolo, cambias el documento, recalculas los embeddings de esa parte, y al instante el sistema responde con la versión nueva. Si necesitas borrar datos por una solicitud RGPD de derecho al olvido, los borras de la base. El modelo, al otro lado, sigue siendo el mismo modelo genérico, sin que nada de lo tuyo haya viajado a su entrenamiento.
Hay otra ventaja menos visible pero relevante. Como la respuesta del modelo está construida a partir de fragmentos concretos que el sistema ha recuperado, es trivial mostrarle al usuario de dónde sale cada afirmación. Esto es lo que hacen herramientas como Perplexity o NotebookLM: cuando responden, citan. La trazabilidad, saber exactamente qué documento, qué párrafo, qué línea, es quizá la diferencia más útil entre una IA con RAG bien montado y una IA que «alucina» con confianza.
Por supuesto, no todo son ventajas. RAG introduce sus propios fallos. Si el sistema de recuperación no encuentra el fragmento correcto, el modelo responde basándose en información incompleta, y a veces termina alucinando igual. Si los documentos están mal troceados, un párrafo cortado en medio de una frase clave, los embeddings degradan. Si la base de conocimiento es inconsistente o tiene contradicciones, el modelo amplifica esa confusión. La calidad del RAG depende casi tanto de cómo se preparan y trocean los documentos como del modelo en sí. Existe ya una jerga entera, chunking, reranking, hybrid search, sobre cómo afinar cada paso.
En la práctica, hay dos formas de tocar RAG. Una es la artesanal: instalar una base vectorial, escribir el código que indexa los documentos, conectarlo con un modelo de embeddings y otro de generación. Esto requiere bastante mano técnica, pero da control absoluto y se puede hacer enteramente en local, los datos no salen de tu servidor en ningún momento. La otra es la enchufada: usar herramientas que ya empaquetan todo el flujo, como NotebookLM de Google, AnythingLLM, OpenWebUI con su motor de RAG integrado, o las funcionalidades de RAG embebidas en plataformas como Claude Projects. Estas son cómodas, pero implican que los documentos viajan al proveedor, con todo lo que eso significa para datos sensibles.
RAG no es magia. Es una forma sensata de combinar dos componentes que cada uno hace bien una cosa: una base de datos que sabe encontrar texto por significado, y un modelo de lenguaje que sabe escribir bien con la materia prima que le pongas delante. Lo poco intuitivo es que la mayoría de las aplicaciones de IA «con tus datos» que la industria está vendiendo como revolucionarias, desde chatbots de soporte técnico hasta asistentes de redacción en consultas, son, debajo, esto. RAG con más o menos pulido.
Y a ti, ¿se te ocurre algún corpus de documentos en tu día a día, protocolos, guías, manuales, correos antiguos, que ganaría tener un buscador por significado encima?
