Avaliação offline versus monitorização 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 expressã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 pensamento)

- 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 nos 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 expressõ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 traçado real

- aplica a rubrica e escreve um relatório JSON

- falha na compilação se alguma pontuação cair abaixo de um limiar pré-definido

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

Definindo monitorização online

O que se observa em produção

A monitorização online não compara com um script pré-escrito. Em vez disso, transmite sinais ao vivo a partir do agente em execução e procura desvios em relação às linhas de base estabelecidas. Sinais típicos incluem:

- distribuição do comprimento ou contagem de tokens de expressões do utilizador

- frequência de cada chamada de ferramenta

- taxas de erro devolvidas por APIs externas

- latência de cada passo no loop do agente

- taxa de comportamentos de fallback ou retry

- deriva semântica na saída final (medida com distância de incorporação para um conjunto de referência recente)

Como o tráfego de produção é ilimitado, recolhe-se esses sinais ao longo de janelas de tempo (por exemplo, janelas deslizantes de cinco minutos) e compara-se com quantis históricos.

Pontos de instrumentação

Para obter os dados necessários, é necessário instrumentar o agente em alguns pontos-chave:

- no ponto de entrada – capturar o pedido bruto do utilizador e um carimbo de data/hora

- antes de cada chamada de ferramenta – registar a chamada pretendida e os argumentos

- após cada resposta de ferramenta – registar a flag de sucesso, código de erro e tamanho da carga útil

- após o agente produzir a sua saída final – registar 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

Estes registos são enviados para um backend de observabilidade (Prometheus, Loki ou um timeseries personalizado) onde pode criar dashboards e alertas.

Regra de alerta de exemplo

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

A monitorização online é uma ferramenta poderosa para garantir que o agente esteja a funcionar corretamente em produção. Com a instrumentação certa e regras de alerta bem definidas, pode detectar e corrigir problemas antes que afetem os utilizadores. Além disso, a monitorização online pode ajudar a identificar áreas para melhoria, permitindo que o agente seja otimizado e aprimorado ao longo do tempo.

Armadilhas comuns ao confiar apenas em uma camada

- Envio com apenas pontuações offline – pode passar no portão, mas ainda assim lançar um agente que falha em frases raras de utilizador ou em um comportamento de ferramenta que só aparece em alta concorrência. - Envio com apenas dashboards – 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 utilizador. - Comparar números de produção ao longo de um período em que o modelo, o prompt ou a lista de ferramentas também mudou – a deriva observada pode ser devido à atualização intencional em vez de uma regressão, levando a falsos alarmes. - Usar o mesmo limiar para sinais offline e online – as pontuações offline são geralmente apertadas (espera-se quase perfeitas coincidências) enquanto as métricas online são ruidosas; aplicar um único corte pode causar falsos positivos ou detecções perdidas. - Negligenciar a versão do conjunto de trajectórias – se atualizar as trajectórias douradas sem registar a alteração, as pontuações offline históricas tornam-se incomparáveis.

Construir um portão de regressão em 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 bilhetes.

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 trajectó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 limiares | 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 | registo 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 para e o pedido de merge é bloqueado.

Configuração de alertas de produção que importam

A monitorização online eficaz centra-se em sinais que mudam rapidamente quando algo corre mal, em vez de métricas que apenas derivam lentamente.

Taxa de erro de ferramenta

Medir a razão de chamadas de ferramenta com falha para o total de chamadas de ferramenta para cada serviço externo. Um pico súbito muitas vezes indica uma interrupção downstream ou uma alteração no contrato de serviço que o agente não adaptou.

Contagem de repetição de loop

Alguns agentes repetem uma chamada de ferramenta quando recebem uma resposta ambígua. Rastrear a média de repetições 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 incorporação de saída

Computar uma incorporação de frase para cada saída final do agente e comparar sua distância com a incorporação mediana da última semana estável. Se a distância do percentil 95 exceder um limite pré-definido, acionar uma investigação.

Monitor de sinal de segurança

Se executar um detector de injeção de prompt ou um filtro de profanidade na saída do agente, registrar a fração de solicitações que são sinalizadas. Utilizar a folha de dicas de prevenção de injeção de prompt LLM da OWASP (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.

Fechar o ciclo: transformar descobertas de monitorização em testes offline

O verdadeiro poder de ter ambas as camadas aparece quando usa observações de produção para melhorar o seu conjunto de testes.

Capturar uma falha nova

Quando um alerta dispara, o primeiro passo é extrair a sequência exata de pedido-resposta que causou o problema. A maioria dos sistemas de observabilidade permite que faça download de um ID de traço que inclui:

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

Guarde este traço como um novo ficheiro de trajectória.

Etiquete o comportamento esperado

Trabalhe com o proprietário do produto ou o responsável pela segurança para decidir qual deve ser o comportamento correcto. Se a falha foi devido a um bug na ferramenta, pode decidir simular a resposta da ferramenta para simular a versão corrigida. Se a falha foi devido à razão do modelo, pode escrever uma cadeia de pensamentos que leva à resposta correcta.

Adicione ao conjunto offline

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

Ajuste a rubrica se necessário

Às vezes, uma nova trajectória revela uma dimensão que foi anteriormente ignorada. Por exemplo, pode descobrir que o agente por vezes produz uma resposta correcta, mas inclui uma frase de desculpas desnecessária que irrita os utilizadores. Pode adicionar uma dimensão de "concisão" à rubrica e dar-lhe um peso.

Re-executar o portão

Execute o pipeline de CI novamente. Se a nova trajectória faz com que a pontuação geral caia abaixo do limiar, sabe que o código actual teria falhado no portão - o que é exactamente o que queria capturar antes da libertação.

O que isto não é

Esta discussão não promete que a avaliação offline irá detectar todos os possíveis bugs antes do lançamento. Não afirma que o monitoramento online nunca irá 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á o seu agente perfeito ou que pode saltar as revisões de segurança, exercícios de red team ou verificação formal. Não afirma que o fluxo de trabalho irá eliminar a necessidade de supervisão humana ou que pode confiar apenas em pontuações automatizadas para decisões de lançamento. Não garante que qualquer limiar específico funcionará para cada equipe ou arquitetura de modelo. Não afirma que a tabela acima é a única forma 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 dicas da OWASP irão prevenir todas as tentativas de injeção de prompt ou que elas substituem uma revisão de segurança dedicada, como a realizada pelo ou que o uso de ferramentas como o ou irá resolver todos os problemas de segurança, especialmente em projetos que seguem as diretrizes do do AgentEval.

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 utilizador ou um sistema preza. Eles detectam diferentes classes de falha.

Podem testes offline substituir a monitorização?

Não. O seu conjunto de testes não pode conter entradas que ainda não tenha pensado.

Podem a monitorização substituir testes offline?

Não. A monitorização diz-lhe que algo mudou após o facto; um gate diz-lhe antes da libertação.

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 invulgares — não apenas volume.

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

Prendamos a rubrica e as trajetórias, e registe as alterações ao modelo, prompt e ferramentas ao longo das pontuações.

É alguma 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 — Quadro de Gestão de Riscos de IA - Stanford CRFM — HELM (Avaliação Holística de Modelos de Linguagem)

Experimente o produto: AgentGrade

2026-09-20 · apenas fontes primárias · nenhum tráfego métrico fabricado · apenas suporte à decisão

Artigos relacionados

- Rubricas de avaliação de agentes que viajam através de pilhas - Explore a matriz completa de tópicos de micro-SaaS de IA →