Los sistemas de recuperación fallan de maneras específicas. Un cambio en el tamaño de chunk, una actualización del modelo de embeddings, un ajuste en el umbral del reranker — cualquiera de estos puede degradar silenciosamente la precisión en un subconjunto reducido de consultas sin afectar las métricas agregadas.
Un probe de regresión de recuperación es el instrumento que detecta ese subconjunto antes de que llegue a producción.
Qué es un probe de regresión de recuperación
Un probe de regresión de recuperación es un conjunto fijo de consultas que se ejecuta contra tu capa de recuperación antes de cada deploy. Cada consulta tiene un conjunto esperado de IDs de documentos. El probe mide precision@k — la fracción de los top-k documentos recuperados que coinciden con el conjunto esperado — y falla el deploy si la precisión cae por debajo de un umbral definido.
No es un benchmark general. No es una muestra aleatoria. Es un conjunto curado de consultas que ya causaron fallas en producción, ejecutado de forma determinista, con un resultado binario: aprobado o fallido.
El objetivo es acotado: confirmar que los modos de falla conocidos no han regresado.
Cómo construir un probe mínimo
Empieza con 10–15 consultas. Es suficiente para cubrir los patrones de falla de mayor severidad sin que el probe sea lento o costoso de mantener.
Paso 1: Obtén las consultas de fallas reales. Extráelas de los logs de producción. Busca consultas donde el sistema recuperó un documento que sonaba plausible pero era factualmente incorrecto para esa consulta, o donde el documento correcto quedó fuera del top k. Estos son tus candidatos para el probe. No inventes consultas sintéticas — no reflejarán la distribución que realmente rompe tu sistema.
Paso 2: Registra los IDs de documentos esperados. Para cada consulta, identifica el documento o documentos que deberían aparecer en los resultados top-k. Guárdalos como una lista de IDs esperados. Una consulta puede tener más de una respuesta aceptable — codifícalo como un conjunto, no como un ID único.
Paso 3: Define una banda de ruido. Precision@k fluctuará ligeramente entre deploys incluso cuando nada significativo cambie. Establece un umbral que señale deriva real sin dispararse por ruido. Un punto de partida común: fallar si precision@5 cae más de 10 puntos porcentuales por debajo del baseline establecido en el último deploy conocido como bueno. Ajusta según qué tan estable sea tu capa de recuperación en la práctica.
Paso 4: Automatiza la ejecución. El probe debe ejecutarse como un paso previo al deploy en tu pipeline de CI. Si falla, el deploy no continúa. Sin anulación manual sin una excepción documentada.
Cómo un pool de candidatos más amplio cambia el comportamiento del probe
Muchas arquitecturas de recuperación usan un enfoque de dos etapas: un paso de recuperación léxica o densa rápida que genera un pool de candidatos, seguido de un reranker que reordena el pool antes de devolver el top k.
Ampliar el pool de candidatos — por ejemplo, de 12 a 30 candidatos — es un ajuste común. La intuición es válida: darle más al reranker para trabajar aumenta sus posibilidades de encontrar el documento correcto.
Pero los pools más amplios introducen casos límite que un probe detectará y las métricas agregadas no.
Esto es lo que ocurre:
- El recall mejora para consultas comunes. El documento correcto entra al pool de candidatos con más frecuencia. La precisión del reranker sube en promedio.
- El ruido aumenta para consultas ambiguas. Con 30 candidatos en lugar de 12, el reranker ve más documentos que son temáticamente cercanos pero factualmente incorrectos para la consulta específica. En consultas ambiguas — las que con mayor probabilidad causaron fallas en producción — la precisión del reranker puede caer.
- El probe detecta los casos ambiguos. Dado que las consultas del probe provienen de fallas reales, se inclinan hacia el extremo ambiguo de tu distribución de consultas. Un pool más amplio que mejora precision@5 promedio en 4 puntos puede al mismo tiempo regresar la precisión en 3 de tus 12 consultas del probe. La métrica agregada oculta esto. El probe lo expone.
Este es el valor central de un probe de regresión: está construido de forma adversarial contra las debilidades conocidas de tu sistema, no contra su comportamiento promedio.
Qué hacer cuando el probe falla
Un fallo del probe no es una crisis. Es el sistema funcionando correctamente.
Cuando un probe falla:
- Identifica qué consultas regresaron y en qué medida.
- Verifica si la regresión está en el pool de candidatos (etapa de recuperación) o en la salida del reranker (etapa de ranking). Registra los rankings antes y después del reranker para las consultas del probe.
- Determina si la regresión es un efecto secundario del cambio previsto o una consecuencia no intencional.
- Corrige la regresión antes de hacer el deploy, o documenta el trade-off explícitamente y actualiza el umbral del probe con un comentario que explique el razonamiento.
No omitas el paso 4. El probe solo es útil si sus umbrales reflejan decisiones deliberadas, no tolerancia acumulada a la deriva.
La disciplina operativa
Un probe de regresión de recuperación no es una construcción de una sola vez. Requiere mantenimiento:
- Agrega nuevas consultas cuando aparezcan nuevos modos de falla en producción.
- Retira consultas cuando los documentos subyacentes sean eliminados del corpus.
- Revisa los conjuntos de IDs esperados cuando el corpus sea reestructurado.
Quince consultas, mantenidas con honestidad, detectarán más regresiones que un benchmark exhaustivo ejecutado una sola vez al lanzamiento.
Aburrido, consistente y previo al deploy. Ese es el patrón que mantiene confiables a los sistemas de recuperación.
Si estás construyendo o auditando un sistema de IA y quieres analizar la arquitectura de recuperación y el diseño de evaluación, Inicia una conversación →