Qué separa un RAG de demo de uno que funciona en producción

Un prototipo de RAG se construye en una tarde. Un RAG que una empresa pueda usar para tomar decisiones requiere resolver problemas que la demo nunca muestra, porque en la demo las preguntas las elige quien construyó el sistema.

El cuello de botella es la recuperación

Cuando una respuesta es mala, el reflejo es cambiar el modelo o el prompt. En la mayoría de los casos el modelo nunca recibió el fragmento correcto. Si el recuperador falla, ningún modelo lo compensa.

• El tamaño del fragmento importa más que el modelo de embeddings: cortar a ciegas cada N caracteres parte tablas, cláusulas y encabezados.
• La búsqueda vectorial sola pierde coincidencias exactas. Combinarla con búsqueda por palabra clave suele mejorar más que cualquier ajuste de prompt.
• Los metadatos son parte del índice: fecha, área, tipo de documento y vigencia permiten filtrar antes de rankear.

Sin evaluación no hay mejora

Es necesario un conjunto de preguntas reales con su respuesta esperada, definido junto al área que va a usar el sistema. Sin eso, cada ajuste es una impresión y no una medición, y el proyecto se estanca en opiniones.

Si no puedes decir si la versión de hoy es mejor que la de la semana pasada, no estás iterando: estás cambiando cosas.

Trazabilidad como requisito, no como extra

En un contexto empresarial, una respuesta sin fuente es inutilizable. Quien la recibe necesita poder verificarla antes de actuar. Citar el documento y el fragmento exacto convierte al sistema en una herramienta de consulta en lugar de una caja negra.

Los permisos son parte del recuperador

Si el índice contiene documentos con distintos niveles de acceso, el filtro por permisos debe aplicarse en la recuperación, antes de que el contenido llegue al modelo. Filtrar después es tarde: el contenido ya salió.

Nada de esto es exótico. Es el trabajo de ingeniería que hace la diferencia entre un piloto que impresiona en una reunión y un sistema que sigue en uso seis meses después.