Do pipeline de avaliação ao primeiro prompt

Aplicações de IA reais são complexas. Uma mesma aplicação pode ter vários componentes, e uma tarefa pode levar vários turnos de conversa até ser concluída. Por isso, a avaliação não pode olhar só para a resposta final. Ela precisa acontecer em vários níveis.

Avalie todos os componentes do sistema

Imagine que você usa uma IA para descobrir por que o seu código Python está quebrando. Antes de ajudar, o modelo pede mais informações: a versão do Python, o sistema operacional, o erro completo. Só depois de você responder é que ele consegue resolver.

Dá para avaliar isso de duas formas:

• Por turno: avalia a qualidade de cada resposta individual.
• Por tarefa: avalia se o sistema concluiu a tarefa. O bug foi corrigido? Quantos turnos foram necessários? Resolver em dois turnos é muito diferente de resolver em vinte.

Como o que interessa ao usuário é se a tarefa foi feita, a avaliação por tarefa é a mais importante. O desafio é saber onde uma tarefa termina e outra começa. Numa conversa com o ChatGPT você faz várias perguntas seguidas. A nova pergunta é continuação da anterior ou um assunto novo?

Crie uma diretriz de avaliação

Essa é a etapa mais importante do pipeline. Uma diretriz ambígua gera notas ambíguas, que podem enganar. Se você não sabe como é uma resposta ruim, não vai conseguir detectá-la.

A diretriz precisa dizer não só o que a aplicação deve fazer, mas também o que ela não deve fazer. Um chatbot de suporte deveria responder sobre a próxima eleição? Se não, você precisa definir o que está fora do escopo, como detectar e como responder nesses casos.

Muitas vezes, o difícil não é saber se uma resposta é boa, é definir o que é bom. O LinkedIn, ao compartilhar o aprendizado de um ano com aplicações de IA generativa, contou que o primeiro obstáculo foi justamente criar essa diretriz. Uma resposta correta nem sempre é uma boa resposta. Numa ferramenta que avalia candidatos a vagas, "você não é uma boa opção para essa vaga" pode estar correto, mas não ajuda ninguém. Uma boa resposta explicaria a distância entre os requisitos da vaga e o histórico da pessoa, e o que ela pode fazer para chegar lá.

Antes de construir a aplicação, pense no que faz uma resposta ser boa. Em média, os times usam mais de um critério. Para um chatbot de suporte, por exemplo:

• Relevância: a resposta tem a ver com a pergunta do usuário.
• Consistência factual: a resposta é coerente com o contexto.
• Segurança: a resposta não é tóxica.

Para chegar nesses critérios, brinque com consultas de teste, de preferência perguntas reais de usuários. Para cada uma, gere várias respostas (na mão ou com IA) e marque quais são boas e quais são ruins.

Rubricas com exemplos

Para cada critério, escolha um sistema de pontuação: binário (0 ou 1), de 1 a 5, de 0 a 1 ou outro. Para consistência factual, alguns times usam 0 para inconsistente e 1 para consistente. Outros usam três valores: -1 para contradição, 0 para neutro e 1 quando o contexto sustenta a resposta. O melhor sistema depende dos seus dados e da sua necessidade.

E coloque exemplos em cada nota. Isso vale tanto para avaliadores humanos quanto para juízes de IA.

Ligue as métricas de IA às métricas de negócio

Uma aplicação existe para cumprir um objetivo de negócio, então as métricas dela precisam fazer sentido dentro desse objetivo. Antes de criar métricas de IA, entenda quais métricas de negócio você quer mexer.

Se o seu chatbot de suporte tem 80% de consistência factual, o que isso significa para a empresa? Talvez seja inaceitável para dúvidas de cobrança, mas suficiente para recomendar produtos. O ideal é chegar em algo assim:

• Consistência factual de 80%: dá para automatizar 30% dos atendimentos.
• Consistência factual de 90%: dá para automatizar 50%.
• Consistência factual de 98%: dá para automatizar 90%.

Com esse mapa, fica mais fácil decidir onde investir: você sabe quanto ganha melhorando cada métrica.

Também vale definir o limite de utilidade, a nota mínima para a aplicação ser útil. Por exemplo, abaixo de 50% de consistência factual o chatbot não serve nem para dúvidas gerais.

Muitas aplicações focam em métricas de retenção, como usuários ativos diários, semanais ou mensais (DAU, WAU, MAU), ou de engajamento, como número de conversas por mês e tempo de cada visita. Aqui existe um equilíbrio delicado entre lucro e responsabilidade: focar demais nessas métricas pode levar o produto a priorizar recursos viciantes ou conteúdo extremo, o que faz mal para o usuário.

Defina métodos e dados de avaliação

Critérios diferentes pedem métodos diferentes. Por exemplo:

• um classificador pequeno e especializado para detectar toxicidade;
• similaridade semântica para medir a relevância entre resposta e pergunta;
• um juiz de IA para medir a consistência factual entre a resposta e o contexto.

Dá para misturar métodos no mesmo critério. Um classificador barato pode olhar 100% dos dados, com um sinal mais fraco, enquanto um juiz de IA mais caro avalia 1%, com um sinal mais forte. Assim você tem confiança no resultado sem estourar o custo.

Use logprobs quando puder

Quando a API oferece logprobs, use. Eles mostram o quanto o modelo está confiante em cada token gerado, o que é muito útil em classificação. Se você pede uma de três classes e as probabilidades ficam todas entre 30% e 40%, o modelo não tem certeza. Se uma delas tem 95%, ele está bem confiante. Os logprobs também permitem calcular a perplexidade do texto gerado, útil para medir fluência e consistência.

Não abandone a avaliação humana

Use métricas automáticas o máximo possível, mas não tenha medo de colocar pessoas para avaliar, inclusive em produção. Como respostas abertas são difíceis de avaliar, muitos times usam a avaliação humana como a métrica principal que orienta o desenvolvimento. Todo dia, especialistas podem avaliar uma amostra das respostas para detectar mudanças de comportamento ou padrões de uso estranhos. O LinkedIn, por exemplo, chegou a avaliar manualmente até 500 conversas por dia.

Avalie o seu pipeline de avaliação

O próprio pipeline também precisa ser avaliado, principalmente quando usa métodos subjetivos como a IA como juiz. Algumas perguntas para fazer:

• Ele está dando os sinais certos? As melhores respostas tiram as maiores notas? Métricas melhores levam a resultados de negócio melhores?
• Ele é confiável? Rodando duas vezes, o resultado muda? E com conjuntos de dados diferentes, quanto varia? Busque reprodutibilidade e pouca variação. Se usar um juiz de IA, por exemplo, deixe a temperatura dele em 0.
• Como as métricas se relacionam? Se duas métricas andam sempre juntas, você não precisa das duas. Se não têm relação nenhuma, ou você descobriu algo interessante sobre o modelo, ou uma delas não é confiável.
• Quanto custo e latência ele adiciona? Avaliação mal feita pesa na aplicação. Alguns times simplesmente desligam a avaliação para ganhar velocidade, o que é uma aposta arriscada.

Itere

Os usuários mudam, as necessidades mudam, e os critérios de avaliação mudam junto. Você vai precisar atualizar critérios, rubricas e exemplos. Mas o pipeline também precisa de alguma estabilidade: se ele muda o tempo todo, os resultados deixam de servir para guiar o desenvolvimento.

Ao iterar, registre tudo que pode mudar entre uma avaliação e outra: os dados de avaliação, a rubrica, o prompt e as configurações de amostragem dos juízes. É o mesmo cuidado de qualquer experimento.

Engenharia de prompt

Engenharia de prompt é o processo de escrever uma instrução que faça o modelo gerar o resultado que você quer.

Com a avaliação montada, dá para começar a adaptar o modelo. E a forma mais fácil e mais comum é a engenharia de prompt. Diferente do ajuste fino, ela muda o comportamento do modelo sem alterar os pesos. Como os modelos de base já são muito capazes, muita gente consegue resolver o problema só com prompt. A regra é: tire o máximo do prompt antes de partir para técnicas mais caras, como o ajuste fino.

À primeira vista, parece que é só ficar mexendo nas palavras até funcionar. Tem um pouco disso, sim, mas também tem muito desafio interessante. Pense no prompt como uma comunicação entre você e a IA. Todo mundo consegue se comunicar, mas nem todo mundo se comunica bem. Escrever um prompt é fácil, escrever um prompt eficaz não.

Tem quem diga que engenharia de prompt não tem rigor suficiente para ser chamada de engenharia. Não precisa ser assim: experimentos de prompt podem e devem ser conduzidos com o mesmo rigor de qualquer experimento de ML, com testes sistemáticos e avaliação.

Ao mesmo tempo, prompt não é tudo. Saber escrever bons prompts é uma habilidade real e útil. O problema é quando é a única coisa que a pessoa sabe. Para colocar uma aplicação de IA em produção você também precisa de estatística, engenharia e conhecimento de ML para rastrear experimentos, avaliar e cuidar dos dados.

As partes de um prompt

Um prompt costuma ter uma ou mais destas partes:

• Descrição da tarefa: o que você quer que o modelo faça, o papel que ele deve assumir e o formato da saída.
• Exemplos: como fazer a tarefa. Se você quer detectar toxicidade, mostre alguns textos tóxicos e alguns que não são.
• A tarefa em si: a pergunta a ser respondida, o livro a ser resumido.

Para o prompt funcionar, o modelo precisa saber seguir instruções. Se ele é ruim nisso, não importa a qualidade do prompt.

Outro ponto é a robustez. Se você troca "5" por "cinco", adiciona uma quebra de linha ou muda uma maiúscula, a resposta muda muito? Quanto menos robusto o modelo, mais você vai precisar mexer no prompt. Dá para medir isso alterando os prompts aleatoriamente e vendo o quanto a saída muda. Em geral, quanto mais forte o modelo, mais robusto ele é.

Aprendizagem no contexto

Ensinar o modelo pelo prompt é o que se chama de aprendizagem no contexto, termo que apareceu no artigo do GPT-3, "Language Models Are Few-shot Learners".

Tradicionalmente, o modelo aprende o comportamento durante o treinamento (pré-treinamento, pós-treinamento, ajuste fino), sempre mexendo nos pesos. Com a aprendizagem no contexto, ele incorpora informação nova na hora, sem retreinar.

Imagine um modelo treinado com a documentação antiga do JavaScript. Sem aprendizagem no contexto, para ele responder sobre a versão nova você teria que treinar de novo. Com ela, basta colocar as mudanças da nova versão no prompt, e o modelo consegue responder além da data de corte do treinamento. É uma forma de aprendizado contínuo.

Cada exemplo no prompt é chamado de shot:

• Zero-shot: nenhum exemplo.
• Few-shot: alguns exemplos. Com cinco, é um 5-shot.

O número ideal de exemplos depende do modelo e da aplicação, e só testando para descobrir. Em geral, mais exemplos ajudam, mas o limite é o tamanho do contexto, e cada exemplo deixa o prompt mais longo e a inferência mais cara.

Prompt do sistema e prompt do usuário

Muitas APIs deixam você dividir o prompt em duas partes:

• Prompt do sistema: pense nele como a descrição da tarefa. É onde ficam as instruções de quem desenvolveu a aplicação.
• Prompt do usuário: é a tarefa em si, o que o usuário pediu.

Quase toda aplicação de IA generativa, incluindo o ChatGPT, tem um prompt de sistema. Mas nada impede você de ser criativo e mover instruções de um lado para o outro, ou colocar tudo em um só. Teste formas diferentes de estruturar e veja qual funciona melhor.

Tamanho do contexto e eficiência

Quanto você consegue colocar em um prompt depende do tamanho máximo do contexto do modelo, que cresceu muito rápido. As três primeiras gerações do GPT tinham 1K, 2K e 4K tokens de contexto, pouco para uma redação de faculdade e insuficiente para a maioria dos documentos jurídicos ou artigos científicos.

Hoje, um contexto de 100K tokens cabe um livro de tamanho médio (um livro técnico de umas 120 mil palavras tem cerca de 160 mil tokens). Um contexto de 2M cabe por volta de 2.000 páginas da Wikipedia, ou uma base de código bem complexa como a do PyTorch.

Mas nem toda parte do prompt recebe a mesma atenção. Pesquisas mostram que o modelo entende muito melhor as instruções que estão no começo e no fim do prompt do que as que estão no meio (Liu et al., 2023).

Uma forma de testar isso é o needle in a haystack (agulha no palheiro): você coloca uma informação aleatória (a agulha) em posições diferentes de um prompt longo (o palheiro) e pede para o modelo encontrá-la. Assim dá para ver em quais partes do contexto ele presta mais atenção.

No próximo artigo, sigo com as boas práticas para escrever prompts e com os riscos que vêm junto, como injeção de prompt e jailbreak.

Referência

Este artigo faz parte dos meus estudos sobre engenharia de IA, baseados no livro AI Engineering: Building Applications with Foundation Models, de Chip Huyen (O'Reilly, 2025).