RAG explicado sin humo: cuándo sirve y cuándo es la herramienta equivocada

RAG (retrieval-augmented generation, generación aumentada por recuperación) es, en su forma más simple, una idea sin misterio: antes de pedirle una respuesta al modelo, buscas la información relevante en tus propios documentos y se la agregas al prompt como contexto. El modelo no 'aprende' esa información, solo la usa para responder esa consulta puntual.

Existe porque un LLM entrenado no conoce tus datos privados ni lo que pasó después de su fecha de corte de entrenamiento, y reentrenar o afinar un modelo cada vez que cambia un documento es lento y caro para la mayoría de los casos de negocio. RAG resuelve eso sin tocar el modelo: solo cambia qué información se le entrega en el momento de la consulta.

La arquitectura mínima tiene una secuencia clara: los documentos se dividen en fragmentos manejables (chunking), cada fragmento se convierte en un vector numérico (embedding) que representa su significado, esos vectores se guardan en una base de datos vectorial, y cuando llega una consulta se convierte también en vector y se buscan los fragmentos más similares para pasárselos al modelo como contexto.

RAG ayuda de verdad cuando se cumplen algunas condiciones: la información cambia con frecuencia y no tiene sentido reentrenar nada; hace falta trazabilidad, es decir, poder mostrar de qué documento salió cada afirmación; y el volumen de información es demasiado grande para caber directo en la ventana de contexto del modelo en cada consulta.

RAG es la herramienta equivocada cuando el conjunto de datos es chico y cabe perfectamente en el contexto sin recuperación — ahí agregar un sistema de búsqueda solo suma complejidad y puntos de falla sin beneficio real. También lo es cuando la tarea necesita una respuesta exacta y estructurada que una consulta a una base de datos tradicional resuelve mejor: 'pedidos de julio con monto mayor a $500.000' es una consulta SQL, no una búsqueda semántica.

RAG no hace que el modelo 'sepa' algo. Hace que le pases el dato correcto en el momento correcto. Si el dato que le pasas está mal o desactualizado, el modelo lo repite con la misma seguridad que si estuviera bien.

El error más común al implementar RAG no está en la arquitectura, está en el corpus: documentos contradictorios entre sí, información desactualizada que nadie eliminó del índice, fragmentos cortados a la mitad de una idea por un chunking descuidado. RAG bien construido sobre datos desordenados produce respuestas seguras y mal fundamentadas — el mismo problema que quería resolver, con un paso más en el medio.