EVALUATOR_ENDPOINT no servidor.
Nota: Você define as dimensões de pontuação. Seu avaliador pode retornar quaisquer chaves numéricas que desejar; o Observability armazena, acompanha tendências e exibe tudo o que você enviar.
Resumo
- Escreva um avaliador. Suba um pequeno serviço HTTP que leia a transcrição de uma sessão e retorne pontuações. O Observability inclui um exemplo funcional que você pode copiar. Veja Escrevendo um avaliador com o SDK.
- Aponte o Observability para ele. Defina
EVALUATOR_ENDPOINT(e umEVALUATOR_TOKENcompartilhado) no processo do servidor. - Acompanhe as pontuações. Cada sessão concluída é pontuada automaticamente; os resultados aparecem na página de detalhes da sessão, na grade de sessões e nos dashboards salvos.

Como funciona
Quando o SDK do Observability emite um eventoagent_end para uma sessão, o servidor
agenda uma avaliação. Em seguida, ele envia via POST a transcrição completa de eventos para o
seu serviço avaliador, que pode:
-
Retornar o resultado inline com
{"status":"done", "scores":{...}, "reasoning":{...}, "summary":"..."}. O resultado é anexado à linha do tempo de avaliações da sessão.reasoningesummarysão opcionais. -
Adiar com
{"status":"pending", "job_id":"abc-123"}. O Observability então chamaGET {EVALUATOR_ENDPOINT}/evaluate/abc-123até que seu avaliador retorne{"status":"done", ...}ou{"status":"error", "error":"..."}. O intervalo de polling é por job: uma respostapendingpode incluirnext_poll_secspara sobrescrever o valor padrão; caso contrário, o Observability usa o valordefault_poll_interval_secsdeGET /config; caso contrário, o servidor recorre aEVALUATOR_POLLING_INTERVAL_SECS(padrão: 10s). Todos os valores são limitados ao intervalo [1s, 1h].
agent_end (por exemplo, um processo de agente que travou)
também podem ser processadas: o GET /config do avaliador pode retornar
{"inactivity_timeout_secs": 1800}, e o Observability avaliará qualquer sessão
que estiver inativa por esse tempo. Defina o campo como null ou omita-o para
desabilitar esse fallback.
O pipeline é completamente inativo quando EVALUATOR_ENDPOINT não está definido.
Uma sessão pode acumular múltiplas avaliações terminais ao longo do tempo: cada
evento agent_end (e cada re-avaliação manual pelo dashboard) acrescenta uma
nova linha de avaliação. Esta é a forma recomendada de avaliar uma conversa retomada:
um usuário encerra um agente, volta mais tarde, envia mais eventos,
encerra o agente novamente, e uma segunda avaliação é executada contra a transcrição
completa atualizada. O dashboard exibe a avaliação mais recente como título
e as avaliações anteriores como uma linha do tempo recolhível. Enquanto uma
avaliação está em andamento para uma sessão, eventos agent_end adicionais para essa
sessão são ignorados; o próximo evento após a conclusão da avaliação em andamento
enfileirará uma nova avaliação normalmente.
O fallback por inatividade também se aplica a sessões retomadas: se novos eventos
chegarem após uma avaliação terminal anterior e a sessão ficar inativa
além de inactivity_timeout_secs, uma nova avaliação é enfileirada.
Falhas transitórias (5xx, 429, timeouts, erros de rede) são repetidas com
backoff exponencial até EVALUATOR_MAX_ATTEMPTS; respostas 4xx são
terminais. O Observability pode ser executado com múltiplas instâncias de servidor
com escalonamento horizontal; o trabalho é particionado para que a mesma sessão nunca seja
despachada duas vezes simultaneamente.
Contrato HTTP
Todas as rotas autenticadas usam autenticação por bearer token. O mesmo valor deve ser configurado nos dois lados:- Servidor do Observability: variável de ambiente
EVALUATOR_TOKEN - Serviço avaliador: configurado da mesma forma (o SDK
agenteye-evaluatorlêEVALUATOR_TOKENpor convenção)
EVALUATOR_TOKEN não estiver definido, o servidor não envia o cabeçalho Authorization; o
avaliador pode então aceitar requisições anônimas, o que é aceitável para uma
rede interna, mas não é recomendado na internet pública.
Rotas que o avaliador deve servir
Corpo EvalRequest enviado pelo servidor
Formatos de resposta
Síncrono (done):reasoning (um mapa de justificativa por pontuação) e summary (uma narrativa
geral em um parágrafo) são ambos opcionais. As chaves em reasoning devem
espelhar as chaves em scores; o dashboard renderiza cada entrada inline abaixo
da barra de pontuação correspondente. Avaliadores mais antigos que retornam apenas scores continuam
funcionando sem alterações; reasoning e summary simplesmente são lidos como null e
os elementos visuais correspondentes na interface são omitidos.
Assíncrono (adiado):
next_poll_secs é opcional; se omitido, o servidor recorre ao
default_poll_interval_secs do avaliador em /config e, em seguida, à sua própria
variável de ambiente EVALUATOR_POLLING_INTERVAL_SECS.
Erro terminal no lado do avaliador:
error terminal para a sessão.
Escrevendo um avaliador com o SDK
Você não precisa implementar o contrato HTTP manualmente. O pacote Pythonagenteye-evaluator
fornece um wrapper FastAPI tipado que cuida da autenticação, roteamento e
dos formatos de requisição/resposta por você.
O Failproof AI Observability também inclui um avaliador de referência funcional que
pontua helpfulness, tool_efficiency e factuality a partir do formato da
transcrição. Copie-o como ponto de partida e substitua pela sua própria lógica: um
juiz LLM, um motor de regras, o que melhor se adequar ao seu padrão de qualidade.
Avaliador mínimo viável:
app roda sob qualquer servidor ASGI, portanto uvicorn module:app a inicializa.
Para avaliadores que precisam adiar trabalho pesado, retorne JobPending
em vez disso e registre um handler @app.job_lookup; o servidor do Observability
faz polling em GET /evaluate/{job_id} até que você retorne um status terminal ou o
limite EVALUATOR_MAX_POLL_DURATION_SECS (padrão: 1 h) seja atingido.
A referência completa da API, o padrão assíncrono e o esquema de eventos estão documentados no
README do SDK agenteye-evaluator.
Executando seu avaliador
O avaliador é seu serviço — o Failproof AI Observability não inclui um avaliador padrão, então você o constrói e executa onde preferir. Ele roda sob qualquer servidor ASGI (por exemplo,uvicorn my_evaluator:app); sirva
as rotas /health, /config e /evaluate conforme o
contrato HTTP e então aponte o servidor para ele (veja
Configurando o servidor).
Quando o avaliador estiver acessível, GET /health retorna {"status":"ok"}. Após
uma execução completa do agente, GET /evaluations no servidor retorna uma linha com
status: "done" e as pontuações produzidas pelo seu avaliador.
Configurando o servidor
Defina no processo do servidor:
Para ativar a pontuação automática, defina tanto
EVALUATOR_ENDPOINT quanto
EVALUATOR_TOKEN no servidor e, em seguida, reinicie-o para aplicar a mudança. Com
EVALUATOR_ENDPOINT não definido, o pipeline permanece inativo.
Os ajustes acima são opcionais; defina as variáveis de ambiente correspondentes
no servidor somente se precisar sobrescrever os valores padrão.
Referência da API
Filtragem por intervalo de pontuação: score_filters
GET /evaluations aceita um parâmetro opcional score_filters que
restringe resultados por valores numéricos dentro do objeto scores. O
parâmetro é uma lista separada por vírgula de entradas chave:mín..máx; qualquer
um dos limites pode ser omitido. Múltiplas entradas são combinadas com AND lógico. Linhas
onde a chave nomeada está ausente ou não é numérica são excluídas. Uma requisição pode
ter no máximo 20 entradas de filtro; exceder isso retorna HTTP 400.
Exemplos:
/evaluations tem os seguintes campos:
Permissões
O admin bootstrap (
ADMIN_KEY, ADMIN_EMAIL) recebe todas essas permissões automaticamente.
Visualizando resultados
/sessions/<id>: linha do tempo de eventos + painel direito exibindo as pontuações da sessão e qualquer erro da tentativa de despacho. Se sua chave tiverevaluations:trigger, um botão de re-avaliar aparece ao lado do botão de exportar, útil para sessões que nunca emitiramagent_endou para atualizar pontuações após implantar um novo avaliador. O dashboard faz polling pelo novo resultado e atualiza o painel direito quando ele chegar./sessions: grade de sessões filtráveis; a coluna de pontuação exibe o status de avaliação e as pontuações de cada sessão de forma rápida./dashboards: visualizações salvas de saúde de avaliação (veja Dashboards abaixo).

Dashboards
A página Dashboards (/dashboards) permite salvar uma combinação de
filtros de avaliação como uma visualização nomeada e reutilizável, e acompanhar como esse
subconjunto de avaliações está se saindo de forma rápida. Os dashboards são compartilhados em toda a sua organização;
todos com dashboards:read veem o mesmo conjunto.
Cada dashboard fixa:
- Filtros: os mesmos controles da página de sessões: ambiente, status,
agente, uma janela de tempo rolante e filtros de intervalo de pontuação (
chave:mín..máx). - Uma configuração de exibição: quais chaves de pontuação destacar, os limites de saúde verde/âmbar/vermelho, quais painéis exibir e se deve condensar à avaliação mais recente por sessão.
GET /evaluations/aggregate), portanto
os números são exatos em vez de amostrados.

dashboards:read quanto evaluations:read;
criar e editar requer dashboards:write; excluir requer dashboards:delete.
O admin bootstrap recebe todas essas permissões automaticamente.
Solução de problemas
Sessões existem, mas nenhuma avaliação é criada. Confirme queEVALUATOR_ENDPOINT
está definido no processo do servidor, que o servidor e o avaliador compartilham o mesmo
valor de EVALUATOR_TOKEN e que o endpoint /health do avaliador está
acessível a partir do servidor. Com EVALUATOR_ENDPOINT não definido, o pipeline é inativo.
Avaliações em andamento se acumulam. Consulte GET /evaluation-jobs para ver a
fila em andamento. Inspecione attempt_count, next_attempt_at e last_error
em cada linha. Causas comuns: serviço avaliador inacessível ou retornando 5xx
(repetido com backoff), EVALUATOR_TOKEN incorreto (401 é terminal) ou um
avaliador assíncrono que retorna pending indefinidamente (veja abaixo).
Sessões concluídas, mas sem avaliação terminal. Consulte
GET /evaluation-jobs?status=polling; o resultado pode ainda estar em andamento.
Se um job estiver preso em pending, o servidor está tendo dificuldade para alcançar o
avaliador; verifique se o avaliador está em execução e se EVALUATOR_TOKEN corresponde.
HTTP 401 from evaluator: invalid bearer token. O EVALUATOR_TOKEN
no servidor não corresponde ao valor configurado no serviço avaliador.
Eles devem ser idênticos.
O avaliador assíncrono retorna pending indefinidamente. O servidor faz polling em
GET /evaluate/{job_id} até que o avaliador retorne done ou error, ou
até que EVALUATOR_MAX_POLL_DURATION_SECS (padrão: 1 h) expire. Após o limite,
a avaliação é registrada como timeout e removida da fila em andamento.
Aumente EVALUATOR_MAX_POLL_DURATION_SECS se seu avaliador legitimamente precisar
de mais tempo do que o padrão.
Próximos passos
- Habilidade de agente avaliador: tenha um agente de código projetando suas dimensões a partir de sessões reais e construindo este serviço para você.
- SDK Python: emita os eventos
agent_endque acionam a pontuação. - Chaves de API: as permissões
evaluations:readeevaluations:trigger. - Auditorias: o outro recurso de qualidade automatizado do Observability, para revisão baseada em políticas.

