Opik LLM Observabilidad: Auditar puntuaciones de subprocesos antes de verde

Opik puede decirle mucho sobre un agente de múltiples turnos, pero un rastro visible o una puntuación de conversación alta aún no es un veredicto de salud. El valor predeterminado razonable es usar Opik para seguimiento y evidencia de evaluación, luego requerir cuatro hechos adicionales antes de mostrarse en verde: los giros previstos aterrizaron bajo una identidad de subproceso, el subproceso era elegible para puntuación, la puntuación se produjo después de la última actividad y el resultado solicitado existe en su destino. Esa distinción es más importante cuando falta una puntuación o parece tranquilizadora. "Sin puntuación" puede significar que la conversación sigue activa, que la regla de muestreo la excluyó, que la puntuación está pendiente o que la puntuación se ha estancado. Una puntuación de 0.94 puede pertenecer a la versión anterior de un hilo. Incluso un 0.94 nuevo puede coexistir con un archivo faltante, un mensaje no enviado o una actualización fallida. Esta guía crea un recibo sin contenido y reproduce diez casos en su contra. Se comparó con Opik 2.2.12 en la confirmación del repositorio. c54a6a9 el 29 de julio de 2026. No requiere indicaciones, respuestas, credenciales ni identificadores de clientes. Pruebe el hilo antes de juzgar la puntuación. Opik agrupa trazas relacionadas con un thread id definido por el usuario. Es documentación de conversación fijada dice que el identificador debe ser único dentro de un proyecto. Eso les da a los operadores un límite importante: una conversación no es "cualquier fila que parezca relacionada" en el tablero. Antes de leer cualquier resultado del evaluador a nivel de subproceso, registre: el espacio de trabajo y el proyecto que se espera que reciban las trazas; un hash opaco o una representación no sensible del ID del hilo esperado; los distintos ID de hilo observados para las vueltas previstas; el último tiempo de actividad de rastreo; el recopilador o el tiempo de consulta utilizado para establecer la visibilidad. Una identificación observada que coincide con la identificación esperada pasa la puerta de identidad. Las identificaciones cero son un problema de telemetría. Dos ID para una conversación prevista constituyen fragmentación, incluso si ambos fragmentos tienen intervalos válidos individualmente. Reutilizar la misma identificación compatible con pantalla en un proyecto diferente también es un alcance de evidencia diferente. No empiece culpando al evaluador cuando no hay rastro. Opik guía de configuración fijada SDK procesamiento por lotes de documentos en TypeScript SDK y controles explícitos client.flush() y flushAll() . Una descarga completa es una prueba de entrega útil, pero aún no prueba que el recolector aceptó el lote o que la consulta lee el proyecto previsto. Confirme la visibilidad después del límite de nivel. Este orden previene un error de diagnóstico común: Trate el tiempo de reutilización y el muestreo como elegibilidad, no como fracaso La evaluación en línea a nivel de hilo es intencionalmente asincrónica. Opik documenta un tiempo de reutilización predeterminado de 15 minutos después de la última actividad antes de que se califique un hilo. El valor se puede cambiar en la configuración del espacio de trabajo o mediante la configuración del entorno autohospedado documentado. Lo mismo documentación fijada explica que el retraso tiene como objetivo permitir que la conversación se resuelva en su totalidad. Por lo tanto, now last activity at < configured cooldown está activo , no vencido. El agente puede estar trabajando, esperando un turno de usuario legítimo o simplemente dentro de la ventana de observación. La localización en el minuto cinco cuando la política registrada es de 15 minutos genera un incidente. El muestreo crea una segunda ruta sin fallas. Una regla en línea Opik tiene una frecuencia de muestreo explícita junto con su modelo, indicación, mapeo de variables y definición de puntuación. Si un recibo dice que no se seleccionó un hilo, el estado correcto es coverage excluded . No es scoring overdue . Para los hilos seleccionados, agregue un período de gracia de puntuación separado después del tiempo de reutilización. Ese período de gracia es su SLO operativo, no una garantía de Opik: Entre esos momentos, conserve el veredicto scoring pending . Después de overdue at , inspeccione los registros de reglas, las credenciales del evaluador, la disponibilidad del modelo, los límites de velocidad y el estado de la cola. Esto crea un límite de alerta claro sin confundir una actividad legítima con un evaluador fallido. El recibo debe preservar la política que produjo la decisión. Almacene el tiempo de reutilización configurado real, la versión de la regla, la decisión de muestreo, el nombre del evaluador y el período de gracia con la clasificación. Si el tiempo de reutilización cambia de 15 a 30 minutos, los acontecimientos históricos deberían seguir siendo explicables en lugar de adquirir silenciosamente un nuevo significado. Una puntuación visible todavía puede estar obsoleta La nueva actividad cambia la versión de la evidencia. Opik documentación del hilo de conversación dice que agregar un seguimiento conserva las puntuaciones de comentarios existentes, reinicia el tiempo de reutilización y vuelve a ejecutar la evaluación en línea después del nuevo tiempo de reutilización. La preservación es útil para la continuidad, pero crea un riesgo temporal de obsolescencia. Utilice esta regla: Si la puntuación visible es anterior al turno más reciente, clasifíquela como score stale independientemente de su valor. Espere a que se vuelva a ejecutar o evalúe explícitamente la última revisión del hilo. No promedie la puntuación anterior en verde ni la borre; retenerlo como evidencia sobre un estado anterior del hilo. La frescura es necesaria pero no suficiente. Opik almacena los resultados de la evaluación en línea como puntuaciones de retroalimentación y sus reglas de hilo pueden juzgar una conversación completa. El documentación de reglas fijadas También describe la coherencia de la conversación, la frustración del usuario y las métricas personalizadas, incluido el acceso a la ruta de ejecución cuando el modelo seleccionado admite la llamada a herramientas. Esos son los resultados de la evaluación. Responden a la pregunta codificada en la métrica. No prueban automáticamente que exista un efecto secundario externo o un resultado. Supongamos que un agente de soporte recibe una puntuación alta de relevancia y coherencia después de decir que actualizó un ticket. La evidencia del hilo puede respaldar que "la conversación fue coherente" y tal vez "apareció la llamada de herramienta esperada". Sólo el sistema de tickets puede demostrar que el ticket previsto contiene ahora el cambio acotado previsto. La puerta final debe consultar ese destino utilizando una clave de correlación no sensible y comparar el resultado con una regla de aceptación determinista. Esto produce tres decisiones distintas: puntuación nueva por debajo del umbral: quality alert ; puntuación aceptable nueva sin recibo de destino: outcome unverified ; Puntaje aceptable nuevo más un recibo de destino coincidente: verified . El orden es deliberado. Un recibo de destino no hace que una mala conversación sea saludable y una buena puntuación de conversación no crea el resultado de destino. Repetir la auditoría de diez estados El dispositivo opik thread score audit.mjs adjunto no contiene contenido de conversación. Cada caso proporciona únicamente visibilidad, identidad esperada y observada, última actividad, selección de muestreo, puntuación y tiempo de puntuación, y un recibo de destino booleano. La política de ejemplo utiliza el tiempo de reutilización predeterminado documentado de 900 segundos, una gracia de puntuación de 300 segundos elegida localmente y un umbral de demostración de 0.7 . La precedencia estatal es más fácil de aplicar como una lista de decisiones seguras para dispositivos móviles: 1. telemetry missing : el rastro deseado no es visible. Verifique la actualización de descarga, recolector, proyecto y consulta. 2. thread fragmented : los ID observados no equivalen al ID esperado. Reparar la propagación antes de juzgar. 3. active : la última actividad está dentro del tiempo de reutilización. Déjalo en paz. 4. coverage excluded : el hilo elegible no fue muestreado. Cobertura récord; no paginar. 5. scoring pending : el hilo seleccionado es elegible pero está dentro de gracia. Mantener desconocido y esperar. 6. scoring overdue : el hilo seleccionado está fuera de lugar sin puntuación. Inspeccione la ruta del evaluador. 7. score stale : el tiempo de puntuación es anterior a la última actividad. Evaluar la última revisión. 8. quality alert : una nueva puntuación está por debajo del umbral elegido. Revisar la evidencia con autoridad limitada. 9. outcome unverified : la puntuación es reciente y aceptable, pero no hay recibo de destino. Verifique el resultado real. 10. verified : identidad, tiempo, puntuación y resultado, todo pasa. Conserve los recibos. Ejecute el artefacto desde su directorio: La repetición fija devuelve diez estados esperados diferentes y sale de un valor distinto de cero si algún caso cambia inesperadamente. Vale la pena comparar dos casos: El primero tiene una puntuación de 0.94 , pero la puntuación es anterior al último rastro. El segundo tiene un 0.91 nuevo, pero no tiene recibo de destino. Solo el tercero tiene un hilo estable, una evaluación actual completa, una puntuación aceptable y un resultado verificado. Adapte el dispositivo reemplazando los recibos sintéticos con una exportación de contenido minimizado desde su entorno. Identificadores hash si todo lo que necesita es igualdad. Mantenga los mensajes de texto, las respuestas, las cargas útiles de las herramientas, los secretos y las rutas locales absolutas fuera del flujo de estado. Establezca el umbral de gracia y calidad de la puntuación a partir de los datos de calibración y latencia de su propio evaluador; ninguno de los valores se proporciona como valor predeterminado universal Opik. Utilice una regla de funcionamiento tranquilo Para la observabilidad de Opik LLM, la regla práctica es: No interprete la puntuación de un subproceso hasta que los seguimientos previstos formen un subproceso actual y la política de puntuación indique que el subproceso era elegible. No borre la ejecución hasta que la puntuación sea más reciente que la última actividad y el resultado solicitado se verifique de forma independiente. Esta regla preserva la espera legítima, hace que el muestreo sea visible y evita tanto las alarmas de puntuación faltante como los estados verdes de puntuación obsoleta. También mantiene los límites honestos: Opik proporciona valiosas pruebas de seguimiento y evaluación; su destino proporciona el recibo de resultado. La auditoría tiene límites. No prueba la calibración del evaluador, la calidad rápida, la corrección semántica, la integridad del proveedor ni la disponibilidad de una implementación Opik en vivo. Una máquina de estado libre de contenido no puede decidir si 0.7 es el umbral adecuado para su tarea. Calibre a los jueces según etiquetas deterministas y humanas, registre la incertidumbre y mantenga una ruta de revisión humana para decisiones importantes. Sidewisp se encuentra actualmente en versión preliminar privada. Su capa de estado planificado tiene como objetivo poner evidencia, actualización, estados de espera y resultados verificados en una vista del operador, pero este artículo no implica que hoy se envíe un adaptador Opik o un motor de monitoreo de producción. fuentes primarias Documentación de identidad de subprocesos y conversaciones Opik, anclada a la confirmación revisada Reglas de evaluación en línea Opik, fijadas al compromiso revisado Configuración de Opik SDK y controles de descarga, anclados a la confirmación revisada