De la demo a producción: una guía práctica para sistemas RAG

La generación aumentada por recuperación (RAG) es la forma más rápida de hacer útil un modelo de lenguaje sobre tus propios datos: recupera documentos relevantes, los coloca en el prompt y deja que el modelo responda con contexto fundamentado. La demo es genuinamente fácil. El sistema de producción es donde vive la ingeniería.

Esto es en lo que nos centramos cuando llevamos un prototipo de RAG a algo que puedes poner frente a clientes.

La calidad de la recuperación lo es todo

Si se recuperan los fragmentos equivocados, ninguna ingeniería de prompts salva la respuesta. La mayoría de las mejoras ocurren antes de que el modelo se llame siquiera:

• Fragmentación (chunking): divide por fronteras semánticas, no por recuentos arbitrarios de tokens. Preserva encabezados y estructura.
• Búsqueda híbrida: combina similitud vectorial densa con búsqueda por palabra clave (BM25); cada una capta lo que la otra pierde.
• Reordenación (re-ranking): recupera de forma amplia y luego usa un cross-encoder para reordenar los mejores candidatos antes de que lleguen al prompt.

Mide la recuperación por sí sola, con un conjunto etiquetado de preguntas y los pasajes que deberían responderlas. Si el recall de recuperación es bajo, arréglalo primero.

Fundamenta cada respuesta y demuéstralo

El RAG en producción necesita mostrar su trabajo. Devolvemos citas con cada respuesta y, cuando el riesgo es alto, añadimos un paso de verificación que contrasta la afirmación generada con el pasaje recuperado. Si el modelo no puede sostener una afirmación desde el contexto, debe decirlo; una respuesta equivocada pero segura es peor que un “no lo sé”.

Trátalo como un sistema, no como un prompt

Las partes que hacen fiable a RAG son poco glamorosas:

• Arnés de evaluación: un conjunto automatizado de preguntas con comportamiento esperado, ejecutado en cada cambio.
• Observabilidad: registra la consulta, los fragmentos recuperados y la respuesta final para poder depurar fallos reales.
• Guardrails: validación de entrada, filtrado de salida y límites de tasa.
• Caché y control de costes: los embeddings y las completions se acumulan rápido a escala.

Dónde se atascan los equipos

El modo de fallo más común no es el modelo; es enviar la demo y asumir que aguantará. El drift se instala a medida que los documentos cambian, las preguntas se vuelven más adversarias y los casos límite se acumulan. Los equipos que triunfan tratan la calidad de la recuperación como una métrica que monitorizan, no como una casilla que marcan una vez.

Construye el arnés de evaluación antes de construir la funcionalidad, y cada mejora a partir de ahí se vuelve medible en lugar de anecdótica.