⏱️ Tiempo de lectura estimado: 7 minutos

RAG para devs: cuándo un LLM necesita memoria real

Te ha pasado, estoy seguro. Le preguntas algo a tu chatbot basado en GPT-4 sobre la documentación interna de tu empresa y te responde con una confianza absoluta... algo completamente inventado. O peor: algo que fue verdad hace dos años pero que ya no aplica. Eso no es un bug del modelo, es un problema de diseño. Y ahí es donde entra RAG.

Retrieval-Augmented Generation suena a paper académico, pero la idea es brutalmente simple: en lugar de que el LLM intente recordar todo desde su entrenamiento, le das contexto relevante justo antes de que responda. Como pasarle los apuntes antes del examen, en lugar de pedirle que recuerde todo lo que estudió hace seis meses.

Llevo un tiempo trabajando con esto en proyectos reales, y hay mucho ruido alrededor del tema. Así que voy a contarte lo que realmente importa.

Cuándo RAG tiene sentido (y cuándo no)

Esta es la pregunta que nadie hace antes de implementar, y luego se arrepienten.

RAG tiene sentido cuando tu caso de uso depende de información que cambia, que es específica de tu dominio, o que el modelo simplemente no puede saber porque no estaba en sus datos de entrenamiento. Documentación interna, bases de conocimiento de soporte, contratos legales actualizados, historiales de tickets... todo eso es territorio RAG.

Ahora bien, si lo que quieres es que el modelo razone mejor, escriba código más limpio o sea más creativo, RAG no te va a ayudar mucho. Ahí el problema es otro: el prompt, el modelo, o los dos.

El error más común que veo es usar RAG como solución por defecto para cualquier problema con LLMs. "El modelo alucina" → RAG. "El modelo no sabe de mi empresa" → RAG. "El modelo me responde mal" → RAG. No. RAG es una herramienta específica para un problema específico: falta de contexto factual actualizado.

El pipeline básico que funciona

Sin entrar en frameworks todavía, la lógica es esta:

Parece sencillo. Y en un prototipo lo es. El infierno empieza cuando intentas que funcione bien en producción.

Los tres problemas reales que nadie menciona en los tutoriales

He visto pipelines de RAG que en demo se ven perfectos y en producción son un desastre. Casi siempre por las mismas razones.

El chunking importa más de lo que crees. Cómo divides tus documentos en fragmentos es probablemente la decisión más crítica de todo el sistema. Si los chunks son muy pequeños, pierdes contexto. Si son muy grandes, metes ruido y el modelo se confunde. No hay una respuesta universal, pero en mi experiencia, chunks de 300-500 tokens con un overlap del 10-15% es un buen punto de partida para documentación técnica. Para contratos legales o textos narrativos, necesitas más contexto por chunk.

La recuperación semántica no es perfecta. Los embeddings capturan similitud conceptual, no exactitud factual. Si un usuario pregunta "¿cuál es el límite de rate del endpoint /users?" y tienes un documento que habla de "restricciones de frecuencia en la API de usuarios", puede que lo encuentres... o puede que no. Ojo que para casos donde la precisión exacta importa, vale la pena combinar búsqueda semántica con búsqueda por palabras clave (BM25, por ejemplo). Eso se llama hybrid search y marca una diferencia notable.

El prompt de síntesis es tan importante como la recuperación. Puedes tener los mejores chunks del mundo y aun así obtener respuestas mediocres si el prompt que le das al LLM con ese contexto está mal construido. El modelo necesita instrucciones claras: usa solo la información del contexto, si no sabes di que no sabes, no inventes. Sin esas instrucciones explícitas, el modelo mezclará el contexto que le diste con lo que ya sabe de su entrenamiento, y ahí es donde aparecen las alucinaciones más peligrosas: las que suenan verdaderas.

Herramientas que vale la pena conocer hoy

El ecosistema se mueve rápido, pero hay algunas opciones que han demostrado ser sólidas.

Para bases de datos vectoriales: Qdrant y Weaviate son mis favoritas para proyectos serios. Chroma está bien para prototipos locales. Si ya usas PostgreSQL, pgvector es una opción que simplifica mucho la arquitectura.

Para el pipeline completo, LangChain tiene de todo pero puede ser demasiado abstracto y difícil de debuggear. LlamaIndex está más enfocado en RAG y en mi experiencia es más predecible. Si prefieres control total, construir el pipeline desde cero con las APIs directas de OpenAI o Anthropic más una base vectorial no es tan complicado como parece, y entiendes exactamente qué está pasando en cada paso.

Evaluar tu RAG: el paso que todos saltan

Esto es lo que separa un RAG que "más o menos funciona" de uno que realmente funciona: la evaluación sistemática.

Necesitas medir dos cosas por separado: la calidad de la recuperación (¿estás encontrando los chunks correctos?) y la calidad de la generación (¿el modelo está usando bien el contexto que le diste?). Si mezclas todo en una sola métrica, no sabrás dónde está el problema cuando las cosas fallen.

Herramientas como RAGAS o TruLens te ayudan a automatizar esto. No son perfectas, pero son infinitamente mejores que evaluar manualmente o, peor, no evaluar.

El punto es que RAG no es un producto terminado que instalas y funciona. Es un sistema que necesita mantenimiento, observabilidad y mejora continua. Si lo tratas como un feature más que deployeas y olvidas, vas a tener problemas.

Antes de irte

Si llevas un tiempo intentando que tu sistema RAG funcione bien y sientes que estás persiguiendo un problema que se mueve cada vez que crees haberlo resuelto, no estás solo. Construir RAG en producción tiene una curva de aprendizaje real que los tutoriales de YouTube no muestran. Cada dataset, cada caso de uso, cada modelo tiene sus propias particularidades, y eso requiere experimentación honesta, no copiar una arquitectura de un blog y esperar que funcione igual.

Empieza con el problema más pequeño que puedas resolver con RAG, mídelo bien, y construye desde ahí. Las arquitecturas elegantes se consiguen iterando, no diseñando todo de una vez.