Como Escrever Sua Primeira Avaliação de IA - SallyAnn DeLucia, Arize AI

원제 · How to Write Your First AI Eval - SallyAnn DeLucia, Arize AI

35:204분 읽기AI Engineer2026. 10. 25.컴퓨터/소프트웨어 · AI/미래기술

핵심 요약

A implementação eficaz de avaliações em IA exige rastreamentos estruturados para isolar uma dimensão de qualidade por juiz, começando com conjuntos de cerca de 20 amostras no playground antes da automação contínua.

하이라이트

  • Avaliações subjetivas impedem a detecção de regressões de prompt e inviabilizam a comparação objetiva entre diferentes versões de modelos.

  • Testes de software tradicionais validam uma única saída determinística, enquanto agentes de IA possuem múltiplos caminhos e exigem rastreamentos para expor a lógica interna.

  • Modelos de decisão fornecem saídas probabilísticas rápidas sem explicações, ao contrário do LLM como juiz, que gera justificativas textuais completas.

  • A precisão do LLM como juiz diminui ao avaliar múltiplos critérios simultaneamente, exigindo o isolamento de apenas uma qualidade por avaliação.

  • O agente de IA Alex expandiu seu conjunto inicial de verificações básicas de segurança e QA para 32 avaliações simultâneas em produção.

  • Métricas operacionais apenas sinalizam que algo falhou, mas avaliações específicas identificam o modo de falha exato da aplicação.

타임라인

  1. Limitações das impressões subjetivas no ciclo de vida de agentes

    O hábito de alterar prompts e julgar os resultados por impressões superficiais esconde problemas graves em produção. Sem uma suíte de avaliação estabelecida, equipes não conseguem comprovar se uma alteração consertou um defeito ou se introduziu novas falhas. O monitoramento contínuo depende desse sinal objetivo para comparar versões de modelos e validar se uma atualização realmente beneficia a aplicação.

    • Avaliações são o principal sinal operacional para monitorar o comportamento de agentes de IA.
    • Ajustes empíricos em prompts geram regressões silenciosas que quebram casos de uso semanas após o deploy.
    • A ausência de critérios objetivos impossibilita a criação de barreiras de qualidade no fluxo de CI.
  2. Diferenças entre testes tradicionais, rastreamentos e categorias de juízes

    A execução de um agente envolve árvores complexas de chamadas a ferramentas, subagentes e LLMs que não revelam a lógica diretamente no código. O LLM como juiz resolve essa complexidade ao fornecer rótulos acompanhados de justificativas analíticas que explicam a nota atribuída. Para testes determinísticos como JSON e palavras-chave, funções em código ou métricas ROUGE e BLEU continuam mais adequadas. Novas APIs de modelos de decisão operam com baixo custo e velocidade, entregando probabilidades binárias para os casos avaliados.

    • Rastreamentos funcionam como logs de execução e avaliações atuam como os testes de software em IA.
    • Sistemas multiagente geram múltiplas saídas aceitáveis, tornando testes unitários convencionais insuficientes.
    • Os métodos avaliativos variam entre código determinístico, modelos de decisão rápidos e LLM como juiz com explicação.
  3. Análise prática de rastreamentos em arquiteturas multiagente

    O exame detalhado de uma árvore de rastreamento de um agente de viagens demonstra como dados de ferramentas climáticas e de destinos alimentam spans subsequentes de LLM para síntese. Essa decomposição em nós com hierarquia de dependência permite localizar com exatidão a etapa causadora do erro. A instrumentação nativa captura atributos essenciais de entrada e saída, enquanto esquemas manuais acomodam parâmetros específicos de cada produto.

    • O nó raiz de um rastreamento concentra a entrada do usuário e o resultado final da interação.
    • Spans representam unidades atômicas de trabalho, distinguindo chamadas a ferramentas de etapas de raciocínio de subagentes.
    • Instrumentações agnósticas capturam chamadas modulares de frameworks como LangGraph por meio do OpenInference.
  4. Definição de critérios concretos e regra da qualidade única

    Substituir termos como prestativo por requisitos quantificáveis, como respeitar o orçamento e limitar o número exato de dias de viagem, garante avaliações confiáveis. A literatura e a prática comprovam que concentrar o prompt do juiz em uma única regra por execução evita dispersão e erros de julgamento. O ciclo de vida do agente Alex exemplifica esse princípio ao iniciar com métricas de segurança e evoluir gradualmente para 32 verificadores em produção.

    • Critérios concretos substituem adjetivos vagos por parâmetros verificáveis de sucesso e falha.
    • LLMs atuando como juiz devem focar em apenas uma dimensão de qualidade por prompt de avaliação.
    • A construção de avaliações deve começar simples e expandir conforme a complexidade do tráfego real.
  5. Configuração do dataset e testes de prompt no playground

    A criação de um juiz no Arize começa pela filtragem de spans específicos, como chamadas de ferramentas ou o nó raiz, para consolidar um conjunto representativo. O prompt de avaliação deve conter instruções claras de papel, critérios explícitos de aprovação e reprovação, rótulos e exigência de explicação analítica. Execuções iterativas sobre modelos rápidos como o GPT-4o-mini permitem calibrar as variáveis antes de salvar e disponibilizar o avaliador na plataforma.

    • Filtros por atributos de span isolam os passos exatos que devem alimentar o dataset de teste.
    • O mapeamento desacoplado de variáveis permite reutilizar o mesmo juiz em diferentes tarefas e origens de dados.
    • O playground valida a concordância entre o modelo de avaliação selecionado e as expectativas do projeto.
  6. Alinhamento humano, automação contínua e governança multidisciplinar

    Equipes maduras não limitam a avaliação ao desenvolvimento; elas implementam rotinas online onde cada transação do agente passa por juízes automatizados. Agentes gerenciados como o Signal consomem essas informações analíticas para identificar padrões de falha e sugerir correções. A governança bem-sucedida de IA exige colaboração ampla entre todas as partes interessadas para estabelecer métricas operacionais e diagnósticos específicos de cada modo de falha.

    • O alinhamento confronta o julgamento gerado por IA com a anotação manual realizada por humanos.
    • Avaliações online executam automaticamente sobre cada rastreamento enviado em ambiente produtivo.
    • A definição de critérios de sucesso exige o envolvimento direto de produto, engenharia, suporte e segurança.

설명

A hands-on workshop from SallyAnn DeLucia, head of product at Arize AI, on moving from vibe checks to real evals. She covers what an eval is and how it differs from a unit test, the main types (LLM as a judge, decision models, code evals, annotations, agent as a judge), how to read a trace, how to write concrete pass/fail criteria, and how to build and iterate on an LLM judge in Arize's prompt playground. Chapters 00:00 Intro and agenda 02:06 Why vibe checks don't scale 03:08 Is an eval just a unit test? 04:13 Why agents make evals harder 05:15 Types of evals 07:29 Workshop setup 10:16 Exploring the travel agent's traces 14:20 How to read a trace 19:03 Defining what good means 22:02 Writing pass/fail criteria 25:19 Building a dataset from traces 26:53 Building and testing an LLM judge 32:08 Next steps: alignment, online evals, Signal SallyAnn DeLucia, Arize AI Join us in SF for the second annual AIE CODE summit: https://aie.codes our last flagship summit of 2026. Applications live now!

이 영상에 대해 글쓰기