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
- 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.
- Apunta Observability hacia él. Configura
EVALUATOR_ENDPOINT(y unEVALUATOR_TOKENcompartido) en el proceso del servidor. - 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.

Cómo funciona
Cuando el SDK de Observability emite un eventoagent_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.reasoningysummaryson opcionales. -
Diferir la respuesta con
{"status":"pending", "job_id":"abc-123"}. Observability entonces llama aGET {EVALUATOR_ENDPOINT}/evaluate/abc-123hasta que tu evaluador devuelva{"status":"done", ...}o{"status":"error", "error":"..."}. La cadencia de sondeo es por trabajo: una respuestapendingpuede incluirnext_poll_secspara sobreescribirla; de lo contrario, Observability usa el valordefault_poll_interval_secsdeGET /config; si tampoco está definido, el servidor recurre aEVALUATOR_POLLING_INTERVAL_SECS(10s por defecto). Todos los valores se limitan al rango [1s, 1h].
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-evaluatorleeEVALUATOR_TOKENpor convención)
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:
error terminal para la sesión.
Escribir un evaluador con el SDK
No tienes que implementar el contrato HTTP a mano. El paquete Pythonagenteye-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:
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 ejemplouvicorn 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:
/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 tieneevaluations:trigger, aparece un botón de re-evaluate junto al botón de exportación, útil para sesiones que nunca emitieronagent_endo 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).

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.
GET /evaluations/aggregate), por lo que los números son exactos y no muestreados.

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 queEVALUATOR_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_endque desencadenan la puntuación. - Claves de API: los permisos
evaluations:readyevaluations:trigger. - Auditorías: la otra función de calidad automatizada de Observability, para revisión basada en políticas.

