Skip to main content
Failproof AI Observability puede puntuar automáticamente cada ejecución de agente finalizada para medir su calidad: tú proporcionas un pequeño servicio de puntuación y Observability se encarga del resto. Úsalo para rastrear las dimensiones que te importan (utilidad, eficiencia de herramientas, factualidad, seguridad; tú decides), detectar regresiones a tiempo y comparar agentes o entornos de un vistazo. La puntuación es opcional: el pipeline no hace nada hasta que configures EVALUATOR_ENDPOINT en el servidor.
Nota: Tú defines las dimensiones de puntuación. Tu evaluador puede devolver las claves numéricas que quiera; Observability almacena, analiza tendencias y muestra todo lo que le envíes.

Resumen rápido

  1. Escribe un evaluador. Levanta un pequeño servicio HTTP que lea la transcripción de una sesión y devuelva puntuaciones. Observability incluye una referencia funcional que puedes copiar. Consulta Escribir un evaluador con el SDK.
  2. Apunta Observability hacia él. Configura EVALUATOR_ENDPOINT (y un EVALUATOR_TOKEN compartido) en el proceso del servidor.
  3. Observa cómo llegan las puntuaciones. Cada sesión completada se puntúa automáticamente; los resultados aparecen en la página de detalle de sesión, la cuadrícula de sesiones y los dashboards guardados.
Vista de detalle de sesión con el resumen de evaluación, barras de puntuación por dimensión y texto de razonamiento en el panel lateral derecho Una vez configurado un evaluador, cada ejecución completada recibe una puntuación y los resultados aparecen en el panel lateral derecho de la sesión: el resumen en la parte superior, seguido de barras de puntuación por dimensión con su razonamiento.

Cómo funciona

Cuando el SDK de Observability emite un evento agent_end para una sesión, el servidor programa una evaluación. Luego envía mediante POST la transcripción completa de eventos a tu servicio evaluador, que puede:
  • Devolver el resultado de forma inmediata con {"status":"done", "scores":{...}, "reasoning":{...}, "summary":"..."}. El resultado se añade a la línea temporal de evaluaciones de la sesión. reasoning y summary son opcionales.
  • Diferir la respuesta con {"status":"pending", "job_id":"abc-123"}. Observability entonces llama a GET {EVALUATOR_ENDPOINT}/evaluate/abc-123 hasta que tu evaluador devuelva {"status":"done", ...} o {"status":"error", "error":"..."}. La cadencia de sondeo es por trabajo: una respuesta pending puede incluir next_poll_secs para sobreescribirla; de lo contrario, Observability usa el valor default_poll_interval_secs de GET /config; si tampoco está definido, el servidor recurre a EVALUATOR_POLLING_INTERVAL_SECS (10s por defecto). Todos los valores se limitan al rango [1s, 1h].
Las sesiones que nunca emiten agent_end (por ejemplo, un proceso de agente que se ha bloqueado) también pueden procesarse: el GET /config del evaluador puede devolver {"inactivity_timeout_secs": 1800}, y Observability evaluará cualquier sesión que haya estado inactiva durante ese tiempo. Establece el campo en null u omítelo para desactivar este comportamiento alternativo. El pipeline es completamente inactivo cuando EVALUATOR_ENDPOINT no está configurado. Una sesión puede acumular múltiples evaluaciones terminales a lo largo del tiempo: cada evento agent_end (y cada re-evaluación manual desde el dashboard) añade una nueva fila de evaluación. Esta es la forma admitida de evaluar una conversación reanudada: un usuario termina un agente, vuelve más tarde, envía más eventos, vuelve a terminar el agente y se ejecuta una segunda evaluación sobre la transcripción completa actualizada. El dashboard muestra la evaluación más reciente como titular y las evaluaciones anteriores como una línea temporal plegable. Mientras se ejecuta una evaluación para una sesión, los eventos agent_end adicionales para esa sesión se ignoran; el siguiente que llegue después de que la evaluación en curso complete pondrá en cola una nueva evaluación como de costumbre. La recuperación por inactividad también se activa en sesiones reanudadas: si llegan nuevos eventos después de una evaluación terminal anterior y la sesión vuelve a quedar inactiva pasando el umbral de inactivity_timeout_secs, se pone en cola una nueva evaluación. Los fallos transitorios (5xx, 429, timeouts, errores de red) se reintentan con retroceso exponencial hasta EVALUATOR_MAX_ATTEMPTS; las respuestas 4xx son terminales. Observability es seguro de ejecutar con múltiples instancias de servidor escaladas horizontalmente; el trabajo se distribuye de forma que la misma sesión nunca se despacha dos veces de forma concurrente.

Contrato HTTP

Todas las rutas autenticadas usan autenticación mediante token bearer. El mismo valor debe configurarse en ambos lados:
  • Servidor de Observability: variable de entorno EVALUATOR_TOKEN
  • Servicio evaluador: configurado de la misma forma (el SDK agenteye-evaluator lee EVALUATOR_TOKEN por convención)
Si EVALUATOR_TOKEN no está configurado, el servidor no envía cabecera Authorization; el evaluador puede entonces aceptar solicitudes anónimas, lo cual es aceptable en una red exclusivamente interna pero no recomendado en internet público.

Rutas que el evaluador debe servir

Cuerpo EvalRequest enviado por el servidor

Formatos de respuesta

Síncrono (done):
reasoning (un mapa de justificación por puntuación) y summary (una narrativa general de un párrafo) son ambos opcionales. Las claves de reasoning deben coincidir con las claves de scores; el dashboard renderiza cada entrada bajo su barra de puntuación. Los evaluadores más antiguos que solo devuelven scores siguen funcionando sin cambios; reasoning y summary simplemente se leen como null y los elementos de UI correspondientes se omiten. Asíncrono (diferido):
next_poll_secs es opcional; si se omite, el servidor recurre al default_poll_interval_secs del evaluador desde /config, y luego a su propia variable de entorno EVALUATOR_POLLING_INTERVAL_SECS. Error terminal en el lado del evaluador:
El servidor trata cualquier otro cuerpo 2xx como un error de protocolo y registra un error terminal para la sesión.

Escribir un evaluador con el SDK

No tienes que implementar el contrato HTTP a mano. El paquete Python agenteye-evaluator te proporciona un wrapper tipado de FastAPI que gestiona la autenticación, el enrutamiento y los formatos de solicitud/respuesta por ti. Failproof AI Observability también incluye un evaluador de referencia funcional que puntúa helpfulness, tool_efficiency y factuality a partir de la estructura de la transcripción. Cópialo como punto de partida y sustituye la lógica por la tuya: un juez LLM, un motor de reglas, lo que mejor se adapte a tu criterio de calidad. Evaluador mínimo viable:
La instancia app se ejecuta bajo cualquier servidor ASGI, por lo que uvicorn module:app la pone en marcha. Para evaluadores que necesitan diferir trabajo costoso, devuelve JobPending en su lugar y registra un handler @app.job_lookup; el servidor de Observability sondea GET /evaluate/{job_id} hasta que devuelves un estado terminal o se agota el límite de EVALUATOR_MAX_POLL_DURATION_SECS (1 h por defecto). La referencia completa de la API, el patrón asíncrono y el esquema de eventos están documentados en el README del SDK agenteye-evaluator.

Ejecutar tu evaluador

El evaluador es tu servicio — Failproof AI Observability no incluye un evaluador por defecto, así que lo construyes y ejecutas donde ejecutas tus propios servicios. Se ejecuta bajo cualquier servidor ASGI (por ejemplo uvicorn my_evaluator:app); sirve las rutas /health, /config y /evaluate del contrato HTTP y luego apunta el servidor hacia él (consulta Configurar el servidor). Una vez que el evaluador sea accesible, GET /health devuelve {"status":"ok"}. Después de que un agente se ejecute de principio a fin, GET /evaluations en el servidor devuelve una fila con status: "done" y las puntuaciones que produjo tu evaluador.

Configurar el servidor

Establece en el proceso del servidor: Para activar la puntuación automática, define tanto EVALUATOR_ENDPOINT como EVALUATOR_TOKEN en el servidor y reinícialo para que tome los cambios. Con EVALUATOR_ENDPOINT sin definir, el pipeline permanece inactivo. Los parámetros de ajuste anteriores son opcionales; configura las variables de entorno correspondientes en el servidor solo si necesitas sobreescribir los valores por defecto.

Referencia de la API

Filtrar por rango de puntuación: score_filters

GET /evaluations acepta un parámetro opcional score_filters que reduce los resultados por valores numéricos dentro del objeto scores. El parámetro es una lista separada por comas de entradas key:min..max; cualquiera de los límites puede omitirse. Múltiples entradas se combinan con AND lógico. Las filas donde la clave nombrada está ausente o no es numérica quedan excluidas. Una solicitud puede tener como máximo 20 entradas de filtro; superarlo devuelve HTTP 400. Ejemplos:
Cada objeto de respuesta de /evaluations tiene estos campos:

Permisos

El administrador bootstrap (ADMIN_KEY, ADMIN_EMAIL) recibe estos permisos automáticamente.

Ver resultados

  • /sessions/<id>: línea temporal de eventos + un panel lateral derecho que muestra las puntuaciones de la sesión y cualquier error del intento de despacho. Si tu clave tiene evaluations:trigger, aparece un botón de re-evaluate junto al botón de exportación, útil para sesiones que nunca emitieron agent_end o para actualizar puntuaciones tras desplegar un nuevo evaluador. El dashboard sondea el nuevo resultado y actualiza el panel lateral cuando llega.
  • /sessions: cuadrícula de sesiones filtrable; la columna de puntuación muestra el estado de evaluación y las puntuaciones de cada sesión de un vistazo.
  • /dashboards: vistas guardadas de salud de evaluación (consulta Dashboards más abajo).
La cuadrícula de sesiones con indicadores de estado de evaluación por sesión e insignias de puntuación con código de colores (helpfulness, factuality, tool_efficiency, safety, coherence) La cuadrícula de sesiones muestra el estado de evaluación y las puntuaciones de cada ejecución de un vistazo; las insignias en rojo/ámbar/verde hacen que las puntuaciones bajas destaquen.

Dashboards

La página de Dashboards (/dashboards) te permite guardar una combinación de filtros de evaluación como una vista con nombre y reutilizable, y observar cómo evoluciona ese subconjunto de evaluaciones de un vistazo. Los dashboards son compartidos en toda tu organización; todos los que tengan dashboards:read ven el mismo conjunto. Cada dashboard fija:
  • Filtros: los mismos controles que la página de sesiones: entorno, estado, agente, una ventana de tiempo deslizante y filtros de rango de puntuación (key:min..max).
  • Una configuración de visualización: qué claves de puntuación destacar, los umbrales de salud verde/ámbar/rojo, qué paneles mostrar y si colapsar a la última evaluación por sesión.
Cada tarjeta muestra el número de sesiones coincidentes, un desglose done/error/timeout, el promedio de cada puntuación destacada y una pequeña línea de tendencia. Abrir un dashboard muestra los paneles a tamaño completo; “open in sessions” te lleva a la página de sesiones prefiltrada exactamente a ese subconjunto. Las métricas se calculan en el servidor sobre todo el conjunto coincidente (mediante GET /evaluations/aggregate), por lo que los números son exactos y no muestreados. Un dashboard de salud de evaluación con barras de puntuación media por dimensión del evaluador, un desglose ok-vs-error de herramientas, las principales herramientas y una tendencia de eventos por hora Permisos: para ver se necesita tanto dashboards:read como evaluations:read; para crear y editar se necesita dashboards:write; para eliminar se necesita dashboards:delete. El administrador bootstrap recibe todos estos permisos automáticamente.

Resolución de problemas

Las sesiones existen pero no se crean evaluaciones. Confirma que EVALUATOR_ENDPOINT está configurado en el proceso del servidor, que el servidor y el evaluador comparten el mismo valor de EVALUATOR_TOKEN, y que el endpoint /health del evaluador es accesible desde el servidor. Con EVALUATOR_ENDPOINT sin definir, el pipeline es inactivo. Las evaluaciones en curso se acumulan. Consulta GET /evaluation-jobs para ver la cola en curso. Inspecciona attempt_count, next_attempt_at y last_error en cada fila. Causas comunes: el servicio evaluador no es accesible o devuelve 5xx (se reintenta con retroceso), EVALUATOR_TOKEN incorrecto (401 es terminal), o un evaluador asíncrono que devuelve pending indefinidamente (ver más abajo). Las sesiones se completaron pero no hay evaluación terminal. Consulta GET /evaluation-jobs?status=polling; el resultado puede seguir en curso. Si un trabajo está atascado en pending, el servidor tiene problemas para contactar con el evaluador; comprueba que el evaluador está activo y que EVALUATOR_TOKEN coincide. HTTP 401 from evaluator: invalid bearer token. El EVALUATOR_TOKEN del servidor no coincide con el valor configurado en el servicio evaluador. Deben ser idénticos. El evaluador asíncrono devuelve pending indefinidamente. El servidor sondea GET /evaluate/{job_id} hasta que el evaluador devuelve done o error, o hasta que se agota EVALUATOR_MAX_POLL_DURATION_SECS (1 h por defecto). Tras el límite, la evaluación se registra como timeout y se elimina de la cola en curso. Aumenta EVALUATOR_MAX_POLL_DURATION_SECS si tu evaluador legítimamente necesita más tiempo del predeterminado.

Próximos pasos

  • Habilidad de agente evaluador: haz que un agente de programación diseñe tus dimensiones a partir de sesiones reales y construya este servicio por ti.
  • Python SDK: emite los eventos agent_end que desencadenan la puntuación.
  • Claves de API: los permisos evaluations:read y evaluations:trigger.
  • Auditorías: la otra función de calidad automatizada de Observability, para revisión basada en políticas.