Los conjuntos de eval mienten porque los usuarios reales no escriben como tu conjunto de eval
Tus consultas de benchmark probablemente fueron generadas a partir de tu documentación. Dividiste una guía de soporte, la incrustaste, luego escribiste consultas que reflejan la estructura y el lenguaje de esos fragmentos. El modelo lo clava. Recall en 5 es 0.92. Despliegas.
Luego en el día tres de producción, un usuario escribe 'compré esto el martes pasado y se rompió ¿puedo recuperar mi dinero?' y tu sistema recupera tres fragmentos no relacionados sobre cobertura de garantía antes de encontrar la sección de política de reembolso. El LLM alucina una tarifa de reposición que no existe. El usuario se enoja. Recibes un mensaje de Slack a las 2am.
El problema no es tu estrategia de chunking o tu modelo de embedding. Es cambio de distribución. Las consultas de eval sintéticas son limpias, específicas y léxicamente cercanas a los documentos fuente. Los usuarios reales escriben fragmentos, pronombres, errores ortográficos y preguntas que enredan múltiples intenciones. Una consulta como 'política de reembolso' no es nada como 'compré esto el martes pasado y se rompió ¿puedo recuperar mi dinero?', pero ambas deberían recuperar el mismo fragmento. Tu recall de 0.9 en el conjunto de eval estaba midiendo el rendimiento en una distribución que no existe en producción.
Lo peor: esta brecha es casi invisible hasta que miras tus logs. Una puntuación de eval de 0.9 puede enmascarar una tasa de recall de 0.35 en el mundo real, y no lo sabrás hasta que los clientes te lo digan.
Los cuatro modos de fallo que vemos en cada auditoría de RAG de producción
Cuando auditamos un sistema RAG que falla, encontramos los mismos patrones una y otra vez. Conocerlos te ayuda a detectar los fallos antes de que se cascadeen.
- Desajuste de embedding. Tus embeddings de consulta provienen de un modelo entrenado en consultas cortas y estructuradas (como benchmarks MTEB). Tus embeddings de documento provienen de un modelo entrenado en texto más largo y desordenado. La métrica de distancia entre ellos es ruidosa. Una consulta de producción en un dialecto o estilo ligeramente diferente aterriza en una región diferente del espacio vectorial de la que esperarías.
- Fallos de límites de fragmentos. La respuesta abarca dos fragmentos. Ningún fragmento por sí solo obtiene una puntuación lo suficientemente alta para ser recuperado. El LLM ve contexto parcial, adivina el resto, y suena seguro al respecto.
- Índice obsoleto. Los documentos fueron actualizados en tu CMS la semana pasada. Los embeddings no fueron recomputados. Los usuarios obtienen contexto obsoleto, el LLM lo contradice con su conocimiento de entrenamiento, e información conflictiva es alucinada como hecho.
- Perdido en el medio. Recuperas 10 fragmentos por similitud semántica, pero la respuesta está en el fragmento 7. Los LLMs basados en Transformer luchan con contexto que no está en las primeras o últimas posiciones. El modelo ve el fragmento correcto pero lo ignora a favor de fragmentos más ruidosos en los bordes.
- Bugs de filtro de metadatos. Tu filtro de tenant_id está silenciosamente desajustado entre el pipeline de indexación y la ruta de consulta. Un usuario obtiene cero resultados, el sistema devuelve una lista de contexto vacía, y el LLM alucina una respuesta útil en lugar de decir 'No tengo esa información.'
Cada uno de estos es un modo de fallo separado. Cada uno produce degradación silenciosa hasta que los usuarios lo notan. La mayoría de los sistemas RAG de producción tienen al menos dos de estos ejecutándose simultáneamente.
Instrumenta la recuperación antes de instrumentar el LLM
No puedes diagnosticar lo que no mides. Comienza registrando el paso de recuperación independientemente de la generación, para que puedas ver qué parte está fallando.
Registra por solicitud: la consulta original, IDs de fragmentos recuperados, puntuaciones de similitud y puntuaciones de rerank si estás usando un reranker. Etiqueta cada generación con si el contexto recuperado realmente contenía la respuesta — usa un LLM-como-juez en una muestra de solicitudes para detectar cuándo la recuperación es correcta pero la generación está alucinando. Rastrea distribuciones de puntuación a lo largo del tiempo. Una puntuación de similitud media decreciente es tu señal de alerta temprana para obsolescencia del índice o cambio de distribución de consultas.
Presupuestos de latencia separados: las consultas de embedding deberían ser ~50ms, búsqueda vectorial ~100ms, reranking ~200ms, generación de LLM 1–3 segundos. Si tu latencia de recuperación se está filtrando en el presupuesto de generación, estás quemando tiempo de espera del usuario en búsqueda cuando la respuesta es débil de todas formas.
Monitorea el costo cuidadosamente. Un reranker de cross-encoder duplica tu costo de recuperación. Contrólalo: solo rerank los 20 resultados principales, o solo en consultas con baja confianza de embedding. El costo de las operaciones que no monitoreas tiende a aparecer después como el costo de las personas que se van — mide los costos de recuperación explícitamente para que puedas intercambiar precisión por eficiencia con intención, no por accidente.
Construye un conjunto de eval a partir de tus logs de producción, no de tu imaginación
Cierra la brecha eval/producción fundamentando tus evals en tráfico real. Semanalmente, muestrea 200–500 consultas de tus logs, estratificadas por intención (preguntas de soporte, búsquedas de productos, preguntas de política, etc.). Haz que un humano etiquete los fragmentos canónicos que deberían ser recuperados para cada uno. Ejecuta ese conjunto nocturnamente contra tu índice actual y alerta sobre regresión.
Las primeras 100 consultas deben ser etiquetadas a mano. Esto es innegociable. Te enseña los modos de fallo específicos de tu dominio y fundamenta tu juicio. Después de eso, puedes usar un LLM-como-juez con verificaciones puntuales, pero esos primeros cien son tu verdad fundamental.
Rastrea negativos difíciles: consultas que parecen recuperables pero no deberían serlo, o consultas donde el sistema debería rechazar. '¿Cuál es el número de teléfono personal del CEO?' debería recuperar cero fragmentos y el LLM debería declinar responder. Si tu conjunto de eval no tiene estos, estás midiendo un modo de fallo diferente del que los usuarios golpearán.
Ejecuta nocturnamente. Cuando tu recall de eval cae de 0.88 a 0.84 durante la noche, algo cambió — un bug en el pipeline de indexación, embeddings obsoletos, o un filtro de metadatos que se rompió. Lo atraparás antes de que los usuarios lo hagan.
Cuando la recuperación no es el problema — es la arquitectura
A veces optimizas la recuperación y sigue siendo frágil porque el problema no es búsqueda semántica. Las consultas que necesitan joins, agregaciones o frescura en tiempo real no pertenecen a un almacén vectorial. Un usuario preguntando '¿cuánto costará el envío para este pedido a mi dirección?' necesita una llamada de herramienta SQL o una búsqueda de API, no una búsqueda semántica sobre documentos pasados.
La recuperación híbrida — combinando búsqueda léxica BM25, embeddings densos y filtros de metadatos, luego fusionando resultados con reciprocal rank fusion — funciona mejor que la búsqueda semántica pura para muchas preguntas de producción. Las preguntas estructuradas aterrizan mejor con una llamada de herramienta que con un índice vectorial.
Cuando la respuesta vive en 50 documentos y requiere agregación o razonamiento sobre múltiples fuentes, un bucle de agente con llamadas de herramienta estructuradas a menudo recupera y razona mejor que un sistema RAG con top-k estático. Un agente puede buscar, validar y refinar iterativamente. Un sistema RAG se compromete con el top-k y espera que el LLM pueda coserlо.
El diagnóstico más difícil: saber cuándo dejar de ajustar la recuperación y cambiar la forma del sistema. Si tus métricas se estabilizan a pesar de semanas de ajustes de reranking y optimización de fragmentos, pregúntate si has elegido la arquitectura equivocada. Eso vale una semana de exploración de arquitectura antes de que valga otra semana de ajuste de parámetros.
Un diagnóstico concreto que puedes ejecutar esta noche
Extrae 100 consultas de los logs de la semana pasada. Para cada una, etiqueta manualmente el fragmento o fragmentos que deberían haber sido recuperados. Ejecuta esas consultas contra tu índice actual. ¿Cuántas de las 100 recuperaron el fragmento correcto en los 5 principales? Ese número es tu recall de producción real. Si es menos de 0.85, tu recuperación es un cuello de botella sin importar lo que tu puntuación de eval diga.
La brecha entre ese número y tu puntuación de eval es tu riesgo de producción real. Ciérrala antes de que el próximo usuario presente un ticket a las 2am.