Skip to main content
O Failproof AI Observability pode pontuar automaticamente cada execução de agente concluída em termos de qualidade: você fornece um pequeno serviço de pontuação e o Observability cuida do restante. Use-o para acompanhar as dimensões que importam para você (utilidade, eficiência de ferramentas, veracidade, segurança — você escolhe), identificar regressões cedo e comparar agentes ou ambientes de forma rápida. A pontuação é opcional: o pipeline não faz nada até que você defina 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

  1. 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.
  2. Aponte o Observability para ele. Defina EVALUATOR_ENDPOINT (e um EVALUATOR_TOKEN compartilhado) no processo do servidor.
  3. 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.
Uma visualização de detalhes da sessão com o resumo da avaliação, barras de pontuação por dimensão e texto de raciocínio no painel direito Após configurar um avaliador, cada execução concluída é pontuada e os resultados aparecem no painel direito da sessão: o resumo no topo, seguido pelas barras de pontuação por dimensão com o raciocínio correspondente.

Como funciona

Quando o SDK do Observability emite um evento agent_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. reasoning e summary são opcionais.
  • Adiar com {"status":"pending", "job_id":"abc-123"}. O Observability então chama GET {EVALUATOR_ENDPOINT}/evaluate/abc-123 até que seu avaliador retorne {"status":"done", ...} ou {"status":"error", "error":"..."}. O intervalo de polling é por job: uma resposta pending pode incluir next_poll_secs para sobrescrever o valor padrão; caso contrário, o Observability usa o valor default_poll_interval_secs de GET /config; caso contrário, o servidor recorre a EVALUATOR_POLLING_INTERVAL_SECS (padrão: 10s). Todos os valores são limitados ao intervalo [1s, 1h].
Sessões que nunca emitem 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-evaluatorEVALUATOR_TOKEN por convenção)
Se 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:
O servidor trata qualquer outro corpo 2xx como um erro de protocolo e registra um error terminal para a sessão.

Escrevendo um avaliador com o SDK

Você não precisa implementar o contrato HTTP manualmente. O pacote Python agenteye-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:
A instância 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:
Cada objeto de resposta de /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 tiver evaluations:trigger, um botão de re-avaliar aparece ao lado do botão de exportar, útil para sessões que nunca emitiram agent_end ou 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).
A grade de Sessões com pílulas de status de avaliação por sessão e emblemas de pontuação codificados por cor (helpfulness, factuality, tool_efficiency, safety, coherence) A grade de sessões exibe o status de avaliação e as pontuações de cada execução de forma rápida; emblemas em vermelho/âmbar/verde destacam pontuações baixas.

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.
Cada card exibe o número de sessões correspondentes, um breakdown de done/error/timeout, a média de cada pontuação destacada e um pequeno sparkline de tendência. Ao abrir um dashboard, os painéis são exibidos em tamanho completo; “abrir em sessões” leva você à página de sessões pré-filtrada exatamente para aquele subconjunto. As métricas são calculadas no servidor sobre todo o conjunto correspondente (via GET /evaluations/aggregate), portanto os números são exatos em vez de amostrados. Um dashboard de saúde de avaliação com barras de pontuação média por dimensão do avaliador, um breakdown de ferramenta ok vs. erro, principais ferramentas e uma tendência de eventos por hora Permissões: visualizar requer tanto 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 que EVALUATOR_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_end que acionam a pontuação.
  • Chaves de API: as permissões evaluations:read e evaluations:trigger.
  • Auditorias: o outro recurso de qualidade automatizado do Observability, para revisão baseada em políticas.