Avaliação de agentes de AI: Phoenix, LangSmith e DeepEval
Tradução automática
Este artigo foi traduzido automaticamente a partir da versão original em inglês.
Nenhuma ferramenta de avaliação de agentes substitui a conceção dos testes. Comece pelas falhas que o produto tem obrigatoriamente de detetar: respostas erradas, escolhas incorretas de ferramentas, argumentos inválidos ou efeitos secundários inseguros. Verifique também passos desnecessários e regressões na latência e nos custos. Depois, escolha a ferramenta adequada ao local onde esses testes têm de ser executados.
Use Phoenix quando o registo aberto de rastos de execução e o alojamento próprio forem importantes. Use LangSmith quando datasets, rastos de execução, anotação e experiências tiverem de partilhar um único processo gerido. Use DeepEval quando a avaliação tiver de se comportar como testes num pipeline de CI em Python. Adicione Promptfoo para uma CLI local, testes em matriz e casos de red team.
Escolha com base no local onde os testes são executados, nos passos que precisa de inspecionar e na necessidade de manter os dados de avaliação no seu ambiente.
Tabela de decisão
| Necessidade | Ponto de partida | Porquê |
|---|---|---|
| Rastos de execução OpenTelemetry e alojamento próprio | Phoenix | O registo de rastos de execução de código aberto, as avaliações, os datasets e as experiências utilizam as convenções OpenTelemetry e OpenInference. |
| Rastos de execução, datasets e revisão geridos | LangSmith | Avalia trajetórias e respostas finais e pode funcionar com agentes fora do LangChain. |
| Testes em Python e controlos de CI | DeepEval | A avaliação de agentes, de ponta a ponta e ao nível de componentes, adequa-se a um processo orientado para testes. |
| Testes locais em matriz e red teaming | Promptfoo | A CLI e a biblioteca de código aberto executam avaliações repetíveis e casos de segurança em CI. |
| Verificações de políticas ou ferramentas específicas do produto | Avaliadores personalizados | Os avaliadores genéricos não conhecem as suas permissões, ações irreversíveis, orçamentos ou invariantes de negócio. |
Avalie os passos e o resultado
Uma trajetória é a sequência de decisões do modelo e de tool calls numa execução. Uma resposta final correta pode ocultar erros nesses passos. Um agente pode chamar a ferramenta errada, repetir uma operação sem necessidade, expor argumentos sensíveis ou chegar a uma resposta plausível sem evidências. Por outro lado, uma sequência de ferramentas diferente, mas válida, não deve falhar apenas por ser diferente de um rasto de execução de referência.
Mantenha verificações separadas para:
- correção da resposta final e suporte por evidências
- seleção de ferramentas e validade dos argumentos
- ações obrigatórias, proibidas ou repetidas
- decisões de políticas e limites de aprovação
- eficiência da trajetória, latência e custos
- recuperação após erros de ferramentas ou resultados parciais
Utilize asserções determinísticas sempre que possível. Reserve os juízes baseados em modelos para questões semânticas, calibre-os com base em exemplos revistos e guarde o modelo do juiz e o prompt com cada resultado.
Por exemplo, teste um agente que consulta o estado de encomendas com um utilizador que não tenha acesso à encomenda pedida. Verifique se não devolve os detalhes da encomenda nem chama uma ferramenta de escrita. Mesmo uma recusa final educada falharia o teste se um passo anterior tivesse divulgado o registo privado.
Uma stack inicial prática
- No código da aplicação que executa o modelo e as ferramentas, registe um ID de pedido, a ferramenta selecionada, os argumentos com os dados sensíveis removidos, o resultado e a duração.
- Transforme as falhas de produção num pequeno dataset de regressão.
- Adicione verificações determinísticas para esquemas, ações proibidas, orçamentos e evidências obrigatórias.
- Adicione um juiz semântico calibrado para resultados que as regras não conseguem avaliar.
- Execute os casos rápidos em cada alteração e uma suite mais abrangente antes do lançamento.
- Analise amostras dos rastos de execução de produção para detetar novos modos de falha e promova-os a testes.
Leitura adicional
- Avaliação de agentes: dos rastos de execução aos conjuntos de testes explica a conceção da avaliação subjacente a estas ferramentas.
- Segurança dos agentes de AI aborda as verificações de políticas que um avaliador deve observar, mas não consegue impor por si só.
- Runtime de agentes de AI de longa duração aborda os rastos de execução e checkpoints que tornam as falhas reproduzíveis.