Supervisar la desviación de la producción de LLM sin recopilar todo

Qué cubre la investigación y la documentación

ProxyDrift, una preimpresión de agosto de 2026, estudia cómo comparar el tráfico en vivo con conjuntos de prueba utilizando resúmenes estructurados de interacciones. Estos resúmenes representan el acceso directo a las interacciones sin procesar. La documentación de LangSmith describe la puntuación de ejecuciones en vivo y la adición de ejemplos a conjuntos de pruebas fuera de línea. Estos son enfoques diferentes. Ninguno de los dos prueba que una configuración de monitoreo proteja la privacidad o cubra todo tipo de solicitudes de los usuarios.

Evidencia: Detección y recuperación de deriva de datos que preservan la privacidad para aplicaciones LLM a gran escala a través de representaciones proxy [1]Evaluación LangSmith [2]

Observa tres tipos de cambios.

La desviación de entrada significa que las solicitudes han cambiado. Los usuarios pueden solicitar diferentes tareas, utilizar nuevos idiomas o enviar documentos más largos. La desviación de los resultados significa que los resultados han cambiado, como más errores o respuestas más lentas. La desviación de la medición significa que el proceso de puntuación ha cambiado. Un nuevo juez, una guía de puntuación o una regla de muestreo pueden cambiar los números. Registre estos cambios por separado.

Una tasa de fracaso más alta puede significar que las tareas entrantes son más difíciles. No siempre significa que el modelo sea más débil. Un promedio sin cambios también puede ocultar un problema si las solicitudes más fáciles compensan las más difíciles. Compare grupos que sean importantes para su producto, como el idioma o el tipo de tarea. Muestra el número de ejemplos detrás de cada partitura.

Mantenga un registro de seguimiento enfocado

Rubrex recomienda comenzar con la decisión que debe respaldar cada alerta. Para investigar el tiempo de espera de una herramienta, es posible que necesite el nombre de la herramienta, la hora, el tipo de error y la versión del software. Es posible que no necesite el mensaje de usuario completo. Para comprobar si una respuesta es verdadera, es posible que necesite el documento fuente. Acordar quién puede acceder a esos datos y cuándo deben eliminarse.

Las etiquetas y las representaciones basadas en números, como las incrustaciones, aún pueden contener información confidencial. Compruebe si revelan detalles privados o pueden vincularse a una persona. Mantenga los datos de los usuarios en vivo fuera de los ejemplos públicos. Utilice ejemplos ficticios o elimine detalles confidenciales cuando explique una falla. Los datos que se han transformado no son automáticamente seguros para compartir.

Ejemplo: los documentos escaneados provocan nuevos fallos

Supongamos que un asistente de compras comienza a recibir documentos escaneados después de que se inicia una nueva integración. El modelo no ha cambiado, pero el sistema ahora tiene dificultades para extraer el texto. El antiguo conjunto de prueba utiliza texto digital limpio. Todavía pasa, incluso cuando los usuarios reales ven más fallas.

Primero, confirme dónde falla la extracción utilizando ejemplos que pueda revisar. Agregue documentos escaneados a un grupo de prueba separado, con texto de referencia verificado. Luego pruebe el paso de extracción y la respuesta final. Es posible que un cambio rápido no solucione el texto fuente faltante. Compruebe si las nuevas pruebas detectan el problema real antes de confiar en ellas como señal de advertencia.

Dale a cada alerta un siguiente paso.

Nombra un propietario para cada alerta. Explique por qué es importante su umbral y qué debe comprobar primero el propietario. Revise las falsas alarmas y los incidentes que la alerta omitió. Cuando una falla real se convierte en un caso de prueba, registre de dónde vino, qué debería suceder y qué versión del conjunto de prueba la contiene. Tenga en cuenta los cambios en el tráfico y las reglas de puntuación al comparar resultados antiguos y nuevos.

• Registre las versiones de aplicación, conjunto de prueba, juez y muestreo.
• Compare la calidad dentro de cada grupo de tareas y en general.
• Revise una muestra amplia junto con los casos que activan alertas.
• Verifique las reglas de acceso y eliminación de datos sin procesar y etiquetas derivadas.

Hacer que el panel sea útil durante un incidente

El monitoreo muestra cómo las señales seleccionadas cambian con el tiempo. La observabilidad le ayuda a rastrear una señal hasta una solicitud, configuración del sistema o dependencia. La evaluación comprueba si el resultado cumplió con las necesidades del usuario. Rubrex recomienda conectar estos registros con una ID de ejecución. Conserve solo los datos necesarios para la investigación, según las reglas de datos acordadas para el producto.

Intente seguir una alerta de principio a fin. ¿Puede el equipo encontrar los casos afectados y la versión del software? ¿Alguien puede convertir el fallo en una prueba que otro ingeniero pueda volver a ejecutar? Muestre recuentos de muestras, resultados faltantes, fallas graves y definiciones de puntajes junto a cada tendencia. Después de una solución, vuelva a ejecutar la prueba y compruebe si el resultado mejoró. Un panel es útil cuando ayuda a alguien a decidir qué hacer a continuación.

Preguntas comunes