RAG en producción: patrones y antipatrones después de un año de uso real
Retrieval-Augmented Generation resuelve el problema de alucinaciones y conocimiento desactualizado en LLMs. Pero implementarlo bien en producción es más difícil de lo que sugieren los tutoriales.
RAG (Retrieval-Augmented Generation) es hoy el patrón más común para darle a un LLM acceso a conocimiento específico de una organización sin hacer fine-tuning. La idea es simple: en lugar de responder solo con lo que sabe el modelo, primero se recuperan documentos relevantes y se incluyen en el contexto de la consulta. En la práctica, la brecha entre un prototipo que funciona en demo y un sistema que funciona en producción con usuarios reales es considerable.
El antipatrón más común: chunk size fijo para todo
El primer error que cometen casi todos los equipos es dividir sus documentos en chunks de tamaño fijo —512 tokens, 1024 tokens— y olvidarse del tema. El resultado es que los chunks rompen unidades semánticas naturales: una tabla queda partida a la mitad, un párrafo de conclusiones está separado de las premisas que lo justifican, y la recuperación devuelve fragmentos que no tienen sentido sin el contexto anterior.
El patrón correcto es chunking semántico: dividir por párrafos, secciones o unidades lógicas del documento, y usar overlapping para que los chunks adyacentes compartan contexto. Para documentos técnicos o legales con estructura clara, respetar los headers y secciones del documento como fronteras naturales mejora significativamente la calidad del retrieval.
El problema del retrieval irrelevante
El segundo antipatrón: asumir que similaridad vectorial es suficiente para encontrar los documentos correctos. Los embeddings son buenos capturando similitud semántica general, pero fallan en búsquedas que requieren coincidencia exacta de términos técnicos, nombres propios o códigos específicos.
La solución es hybrid search: combinar búsqueda vectorial (densa) con búsqueda por keyword (BM25 o similar). Elasticsearch, Weaviate y pgvector (con extensión de búsqueda de texto) permiten implementar esto. En la mayoría de casos de producción evaluados, hybrid search mejora el recall entre un 15% y un 30% respecto a búsqueda vectorial pura.
Evaluación: el paso que nadie hace
El antipatrón más costoso es poner un sistema RAG en producción sin una suite de evaluación. Sin métricas, no sabes si un cambio en el tamaño de chunks, en el modelo de embeddings o en el prompt del sistema mejoró o empeoró la calidad de las respuestas.
Las métricas estándar para RAG son:
- Faithfulness: ¿la respuesta está basada en los documentos recuperados, o el modelo está alucinando?
- Answer relevance: ¿la respuesta responde realmente la pregunta?
- Context precision: de los chunks recuperados, ¿qué porcentaje era realmente necesario?
Frameworks como RAGAS automatizan el cálculo de estas métricas usando un LLM como juez. No es perfecto, pero es infinitamente mejor que evaluar manualmente o no evaluar.
Lo que sí funciona
El patrón más efectivo que hemos visto en equipos con RAG maduro: re-ranking en dos fases. Primero se recuperan más candidatos de lo necesario (top-20), y luego un modelo de re-ranking más pequeño (como Cohere Rerank o un cross-encoder local) ordena esos candidatos por relevancia real antes de pasarlos al LLM. El costo computacional es bajo y la mejora en calidad es notoria.
Para documentos estructurados (PDFs técnicos, manuales), combinar el texto con los metadatos del documento en el chunk —fecha, sección, tipo de documento— permite filtrar en la búsqueda antes de calcular similaridad, reduciendo ruido y latencia.