Avaliação offline vs monitoramento online para agentes de IA

Definindo avaliação offline

Composição de trajetória

Uma trajetória é uma lista ordenada de etapas que o agente deve seguir quando recebe uma entrada específica. Cada etapa contém:

- a declaração do usuário ou evento do sistema que dispara o agente - o pensamento ou raciocínio que o agente deve produzir (se você registrar a cadeia de pensamentos) - a chamada de ferramenta ou solicitação de API que o agente deve fazer - a resposta de ferramenta esperada ou feedback do ambiente - a saída final do agente que deve ser exibida ao usuário ou sistema downstream

Quando você coleta trajetórias, geralmente começa com um pequeno conjunto de histórias de usuário representativas, então expande-as adicionando casos de bordo que você viu em logs ou que pode imaginar a partir de documentos de requisitos.

Rubrica de pontuação

A avaliação offline compara a trajetória real do agente com a trajetória dourada usando uma rubrica que pode conter várias dimensões independentes:

- Correspondência exata – o agente produz a mesma sequência de chamadas de ferramentas e respostas? - Semelhança semântica – as declarações ou saídas são equivalentes em termos de significado, mesmo que a redação seja diferente? - Fidelidade – o raciocínio do agente permanece fundamentado nas saídas de ferramentas fornecidas? - Sucesso da tarefa – a saída final atende aos critérios de sucesso definidos para a história?

Cada dimensão recebe uma pontuação entre 0 e 1. A pontuação offline geral é frequentemente uma média ponderada, mas você também pode tratar cada dimensão como um portão separado.

Executando avaliação offline no CI

Porque o conjunto de trajetórias é estático e a rubrica é determinística, você pode executar a avaliação como uma etapa no seu pipeline de integração contínua. A etapa geralmente:

- verifica o código do agente e os fixtures de trajetória - instala as dependências necessárias - executa o agente contra cada trajetória, capturando a trilha real - aplica a rubrica e escreve um relatório JSON - falha na compilação se alguma pontuação for inferior a um limite pré-definido

Isso fornece feedback rápido sobre regressões que você pode reproduzir.

Definindo monitoramento online

O que você observa em produção

O monitoramento online não compara com um script pré-escrito. Em vez disso, ele transmite sinais ao vivo do agente em execução e procura por desvios dos padrões estabelecidos. Sinais típicos incluem:

- distribuição do comprimento ou contagem de tokens da fala do usuário - frequência de cada chamada de ferramenta - taxas de erro retornadas por APIs externas - latência de cada etapa no loop do agente - taxa de comportamentos de fallback ou retry - deriva semântica na saída final (medida com distância de embedding para um conjunto de referência recente)

Como o tráfego de produção é ilimitado, você coleta esses sinais em janelas de tempo (por exemplo, janelas deslizantes de cinco minutos) e os compara com quantis históricos.

Pontos de instrumentação

Para obter os dados necessários, você precisa instrumentar o agente em alguns pontos-chave:

- no ponto de entrada – capturar a solicitação raw do usuário e um carimbo de data/hora - antes de cada chamada de ferramenta – registrar a chamada pretendida e os argumentos - após cada resposta de ferramenta – registrar a flag de sucesso, código de erro e tamanho da carga - após o agente produzir sua saída final – registrar o texto de saída e quaisquer pontuações de segurança - em intervalos regulares – emitir um sinal de pulsação que inclui uso de memória e carga de CPU

Esses logs são enviados para um backend de observabilidade (Prometheus, Loki ou um timeseries personalizado) onde você pode criar painéis e alertas.

Regra de alerta de exemplo

Uma regra útil é alertar quando a proporção de chamadas para uma API externa específica que retornam um erro 5xx excede o percentil 99 dos últimos duas semanas para três janelas consecutivas. Isso captura uma degradação súbita em uma dependência que o conjunto offline nunca cobriu porque o modo de falha só aparece sob carga do mundo real.

Armadilhas comuns ao confiar em apenas uma camada

- Envio com apenas pontuações offline – você pode passar no gate, mas ainda assim lançar um agente que falha em frases de usuário raras ou em um comportamento de ferramenta que só aparece em alta concorrência. - Envio com apenas dashboards – você pode notar um problema dias após a alteração ofensiva ter sido mesclada, tornando a reversão mais difícil e aumentando o impacto no usuário. - Comparar números de produção em um período em que o modelo, prompt ou lista de ferramentas também mudou – a deriva observada pode ser devido à atualização intencional, e não a uma regressão, levando a alarmes falsos. - Usar o mesmo limite para sinais offline e online – as pontuações offline são usualmente rigorosas (você espera combinações quase perfeitas), enquanto as métricas online são barulhentas; aplicar um único corte pode causar muitos falsos positivos ou detecções perdidas. - Negligenciar a versão do conjunto de trajetória – se você atualizar as trajetórias douradas sem registrar a alteração, as pontuações offline históricas se tornam incomparáveis.

Construindo um portão de regressão no CI

Abaixo está um exemplo concreto de como você pode estruturar o portão para um agente de suporte ao cliente que usa um modelo de linguagem, uma ferramenta de recuperação e uma API de criação de tickets.

Etapa | Ferramenta ou Script | Saída | Frequência Verificar código e fixtures | git clone + git checkout | espaço de trabalho limpo | uma vez por execução do pipeline Instalar dependências | pip install -r requirements.txt | ambiente isolado | uma vez por execução do pipeline Executar agente em cada trajetória | python run_agent.py --trajectories data/trajectories.jsonl | Arquivo JSONL com traços reais | uma vez por execução do pipeline Aplicar rubrica | python score_traces.py --rubric config/rubric.yaml | pontuações por dimensão e geral | uma vez por execução do pipeline Verificar limites | python gate_check.py --min-overall 0.92 --min-faithfulness 0.88 | status de aprovação/reprovação | uma vez por execução do pipeline Publicar relatório | curl -X POST -d @report.json https://metrics.example.com/ingest | registro em série temporal | uma vez por execução do pipeline

Cada etapa é deliberadamente mantida idempotente para que a reexecução do pipeline produza o mesmo resultado. Se alguma etapa falhar, o pipeline é interrompido e o pedido de merge é bloqueado.

Configurando alertas de produção que importam

O monitoramento online eficaz se concentra em sinais que mudam rapidamente quando algo dá errado, em vez de métricas que apenas mudam lentamente.

Taxa de erro de ferramenta

Mantenha a proporção de chamadas de ferramenta com falha para o total de chamadas de ferramenta para cada serviço externo. Um pico repentino geralmente indica uma interrupção downstream ou uma alteração no contrato de serviço que o agente não adaptou.

Contagem de retry de loop

Alguns agentes repetem uma chamada de ferramenta quando recebem uma resposta ambígua. Acompanhe a média de retries por solicitação de usuário. Um aumento pode significar que o modelo está produzindo saídas mais incertas ou que a ferramenta está retornando erros vagos.

Deriva de embedding de saída

Compute um embedding de sentença para cada saída final do agente e compare sua distância ao embedding mediano da última semana estável. Se a distância do 95º percentil exceder um limite pré-definido, acione uma investigação.

Monitor de sinal de segurança

Se você executar um detector de injeção de prompt ou um filtro de profanidade na saída do agente, registre a fração de solicitações que são sinalizadas. Use a OWASP LLM Prompt Injection Prevention Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) para decidir quais padrões observar. Um aumento nas solicitações sinalizadas pode indicar que o modelo está se tornando mais suscetível a tentativas de jailbreak.

Fechando o loop: transformando descobertas de monitoramento em testes offline

O verdadeiro poder de ter ambas as camadas aparece quando você usa observações de produção para melhorar sua suíte de testes.

Capturar uma falha nova

Quando um alerta é acionado, o primeiro passo é extrair a sequência exata de solicitação-resposta que causou o problema. A maioria dos sistemas de observabilidade permite que você baixe um ID de rastreamento que inclui:

- a declaração original do usuário - cada chamada de ferramenta e seus argumentos - cada resposta da ferramenta - a saída final do agente

Salve esse rastreamento como um novo arquivo de trajetória.

Rotule o comportamento esperado

Trabalhe com o proprietário do produto ou o líder de segurança para decidir qual deve ser o comportamento correto. Se a falha foi devido a um bug na ferramenta, você pode decidir simular a resposta da ferramenta para simular a versão corrigida. Se a falha foi devido à razão do modelo, você pode escrever uma cadeia de pensamento que leva à resposta correta.

Adicione ao conjunto offline

Coloque a nova trajetória no diretório de trajetórias controlado por versão. Atualize a documentação para notar a fonte (por exemplo, "adicionado do incidente de produção INC-2024-09-12-07").

Ajuste a rubrica se necessário

Às vezes, uma nova trajetória revela uma dimensão que foi previamente ignorada. Por exemplo, você pode descobrir que o agente às vezes produz uma resposta correta, mas inclui uma frase de desculpas desnecessária que irrita os usuários. Você pode adicionar uma dimensão de "concisão" à rubrica e dar um peso a ela.

Re-executar o gate

Execute o pipeline de CI novamente. Se a nova trajetória faz com que a pontuação geral caia abaixo do limiar, você sabe que o código atual teria falhado no gate - que é exatamente o que você queria capturar antes do lançamento.

Repetir esse ciclo cria um loop de feedback onde a produção ensina a suíte de testes o que testar, e a suíte de testes impede que regressões conhecidas atinjam os usuários.

O que isso não é

Esta discussão não promete que a avaliação offline capturará todos os possíveis bugs antes do lançamento. Não afirma que o monitoramento online nunca perderá uma falha ou que as duas camadas juntas fornecem uma garantia de 100% de correção. Não afirma que o uso desses métodos tornará seu agente, como o ou o ou qualquer outro, incluindo o ou perfeito ou que você pode pular as revisões de segurança, exercícios de red team ou verificação formal. Não afirma que o fluxo de trabalho eliminará a necessidade de supervisão humana ou que você pode confiar apenas em pontuações automatizadas para decisões de lançamento. Não garante que qualquer limiar particular funcionará para cada equipe ou cada arquitetura de modelo. Não afirma que a tabela acima é a única maneira de configurar um portão de CI ou que as regras de alerta listadas são universalmente ótimas. Não afirma que as folhas de truques do OWASP prevenirão todas as tentativas de injeção de prompts ou que elas substituem uma revisão de segurança dedicada. Não afirma que as referências listadas são exaustivas ou …

Referências

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - https://docs.agents-squads.com/guides/config-files

Perguntas frequentes

Precisamos de ambos?

Sim, se o agente tocar em algo que um usuário ou sistema se preocupa. Eles detectam classes diferentes de falha.

Os testes offline podem substituir o monitoramento?

Não. Seu conjunto de testes não pode conter entradas que você ainda não pensou.

O monitoramento pode substituir os testes offline?

Não. O monitoramento informa que algo mudou após o fato; um gate informa antes do lançamento.

O que devemos alertar na produção?

Taxa de alteração nos sinais de falha, taxas de erro de ferramentas e padrões de loop ou retry incomuns — não apenas volume.

Como mantemos as pontuações comparáveis ao longo do tempo?

Fixe a rubrica e as trajetórias, e registre as alterações no modelo, prompt e ferramentas ao lado das pontuações.

Qualquer uma das camadas é uma certificação de segurança?

Não. Ambos são sinais de engenharia. A revisão de segurança é um exercício separado.

Referências

- NIST — Estrutura de Gerenciamento de Riscos de IA - Stanford CRFM — HELM (Avaliação Holística de Modelos de Linguagem)

Experimente o produto: AgentGrade

2026-09-20 · fontes primárias apenas · sem métricas de tráfego fabricadas · suporte à decisão apenas

Artigos relacionados

- Rubricas de avaliação de Agent que viajam por pilhas - Explore a matriz completa de tópicos de micro-SaaS de IA →