Como Construir uma Suite de Avaliação de IA para um Produto Vertical

Uma suite de avaliação de IA é um conjunto versionado de casos de teste rotulados por especialistas mais avaliadores automáticos que dão nota à saída do modelo a cada deploy e a cada mudança de prompt ou de modelo. Assim a qualidade é medida, não chutada. Com uma boa suite você troca por um modelo mais barato ou melhor sem rezar. Sem ela, cada mudança é uma aposta cujas probabilidades você não enxerga.

Este é o playbook de construção, o companheiro prático do nosso argumento sobre por que evals específicos de domínio são um moat. A Avante Ventures é um venture studio que constrói empresas AI-native no Brasil e na América Latina, e todo produto que lançamos roda sobre uma suite como esta. Aqui está como montar o golden set, escrever os avaliadores, ligar tudo ao seu gate de deploy e transformar isso num ativo que compõe a cada uso do produto.

Quando você precisa de uma suite de avaliação, e quando testes bastam

Uma suite de avaliação não é uma suite de testes, e tratar as duas como a mesma coisa é o primeiro erro. Testes unitários afirmam comportamento determinístico. Dada a entrada X, a função devolve exatamente Y, sempre. A saída de um LLM é probabilística e aberta, então a pergunta real não é se ele devolveu a string exata, e sim se ele acertou com frequência suficiente nos casos que importam. A Anthropic enquadra a disciplina como definir os critérios de sucesso primeiro e só então desenhar avaliações para medir contra eles, e chama esse ciclo de central para a engenharia de prompt.

Você precisa de uma suite no momento em que um LLM entra num caminho de decisão com que um usuário ou um regulador se importa. Classificar uma peça jurídica. Precificar um risco. Extrair um número de um documento. Responder um chamado de suporte que carrega consequência de política. Você não precisa de uma para geração de baixo risco em que um humano já revisa toda saída. O sinal é simples. Se você não consegue mudar um prompt sem um medo silencioso de ter quebrado algo que não enxerga, você já passou do ponto em que olhar as saídas no olho resolve, e está operando no chute.

O relatório DORA de 2024 dá números duros a essa intuição. No estudo, um aumento de 25% na adoção de IA veio acompanhado de uma queda estimada de 1,5% na vazão de entrega de software e de 7,2% na estabilidade da entrega, mesmo com a IA elevando sinais individuais como qualidade de documentação e de código. Os autores são diretos ao dizer que a IA não é panaceia, e que desenvolver mais rápido não melhora a entrega sem o básico, lotes pequenos e disciplina de testes. Uma suite de avaliação é essa disciplina de testes para a camada de IA. É o que permite manter a velocidade sem pagar de volta em instabilidade.

Construa a suite de avaliação de IA em cinco passos

Este é um fluxo que você começa esta semana, não uma lista de capacidades. A ordem importa, porque cada passo é inútil sem o anterior.

• Monte um golden set. Reúna de 50 a algumas centenas de casos reais da sua distribuição de tarefa, cada um com a resposta correta rotulada por um especialista de domínio, nunca pelo modelo. Inclua os difíceis de propósito. Esse conjunto codifica a sua definição de correto, e é a coisa mais valiosa que você vai construir.
• Escreva avaliadores. Um avaliador é código que dá nota a uma saída contra a resposta de referência. Correspondência exata para tarefas categóricas, um juiz modelo pontuado por rubrica para as abertas, com desempate humano onde o juiz e o rótulo divergem.
• Meça uma linha de base. Rode o prompt e o modelo atuais contra o conjunto inteiro e registre o número. Acurácia, F1, taxa de acerto, o que couber. Essa linha é o que toda mudança futura tem que bater ou manter.
• Ligue à CI como gate. Rode a suite a cada pull request e a cada deploy, e quebre o build quando a nota cair abaixo da linha de base. A qualidade deixa de ser opinião e vira condição de merge.
• Feche o ciclo. Toda falha de produção que a suite não pegou entra no golden set com o rótulo correto. A suite vira um registro vivo de cada jeito pelo qual o sistema já errou, e de cada regressão que ela agora bloqueia para sempre.

Escolhendo avaliadores e coletando casos difíceis

Case o avaliador com a tarefa. A Anthropic ordena três famílias por velocidade e confiabilidade, e essa ordem é um bom padrão. Avaliação por código é a mais rápida e confiável, uma correspondência exata em que a saída é igual à referência, ou uma correspondência de string em que uma frase-chave precisa aparecer. Avaliação humana é a mais flexível e de maior qualidade, e também a mais lenta e cara, então você a evita quando pode. Avaliação por modelo, em que um LLM julga a saída contra uma rubrica, é rápida, flexível e escalável, e a ferramenta certa para julgamentos sutis, mas você a valida contra rótulos humanos antes de confiar nela em escala. A OpenAI entrega o mesmo formato no seu framework aberto de evals, dados em JSON e modelos de avaliação por modelo.

A rubrica é onde o juiz modelo vive ou morre. Faça-a detalhada e empírica, force um veredito discreto de correto ou incorreto ou uma nota de 1 a 5 em vez de texto corrido, e peça ao juiz para raciocinar primeiro e depois descartar o raciocínio, o que melhora de forma mensurável a nota nos casos difíceis. Use um modelo diferente para avaliar daquele que gerou a saída.

Os casos difíceis são o ponto inteiro, e são onde a expertise de domínio ganha da esperteza do modelo. Um time genérico escreve casos fáceis que o modelo já passa. Um operador de domínio conhece a peça que parece rotineira mas não é, a condição de borda que um regulador de fato pune, a entrada que um concorrente erra. Colete esses casos dos logs reais de produção, de entrevistas com especialistas e dos incidentes que já custaram caro. Você pode deixar o modelo ajudar a gerar volume, mas os rótulos dos casos que importam continuam humanos e especialistas.

Ligue as avaliações ao gate de deploy

Uma suite que roda quando alguém lembra não é um gate. Coloque a suite na CI para que ela rode automaticamente a cada pull request e bloqueie o merge quando a nota cair abaixo da linha de base que você registrou. Agora um ajuste de prompt que silenciosamente custa três pontos de acurácia não sobe, porque o build fica vermelho antes de qualquer discussão.

Isso só funciona se você versiona o que está no gate. Trate o prompt como código-fonte, comitado e comparável em diff, e fixe o nome e a versão do modelo ao lado dele. Quando você muda um dos dois, a suite dá nota à mudança contra a linha de base e diz o que ela custou ou comprou. Essa é a diferença entre uma decisão medida e um chute. Uma troca de modelo vira um experimento com número anexado, não um salto de fé numa sexta à tarde.

Como o conjunto de avaliação vira proprietário

A suite é onde o flywheel copilot, dado, capital ganha dentes. Cada correção que um especialista de domínio faz e cada falha de produção devolvida com a resposta certa vira uma linha rotulada que nenhum concorrente tem e nenhum consegue comprar. O conjunto de avaliação é proprietário, específico de domínio e composto ao longo do tempo. É a definição escrita de correto para um vertical, e cresce a cada vez que o produto é usado e corrigido. Por isso o conjunto de avaliação, e não o modelo, é o ativo durável, um argumento que fazemos por inteiro no flywheel copilot, dado, capital.

O mecanismo se liga direto à economia da inferência. A qualidade dos modelos está convergindo e o custo da inferência está desabando, então o modelo base não é o moat, e apostar a empresa em um só é a armadilha do wrapper. Segundo a a16z, um LLM na qualidade do GPT-3 caiu de cerca de 60 dólares por milhão de tokens no fim de 2021 para cerca de 0,06 dólar, uma queda de 1000x em três anos, perto de 10x ao ano para desempenho equivalente. A Epoch AI coloca a queda mediana perto de 50x ao ano entre benchmarks. Leia isso como estratégia, não curiosidade. Se um modelo base mais barato ou melhor aparece a cada poucos meses, o time que consegue trocar para ele sem perder qualidade ganha em custo e em capacidade, e a suite é o instrumento que torna a troca segura.

Modos de falha: medir o correto errado

Uma suite construída errado é pior que suite nenhuma, porque entrega ao time uma confiança falsa. Estes são os jeitos pelos quais ela dá errado, e a correção de cada um.

• A definição errada de correto. Um golden set ruim codifica um padrão equivocado, e a suite então certifica o comportamento errado em todo build verde. Corrija com rotulagem por especialista e revisão periódica do próprio conjunto, não só do modelo.
• Overfitting à avaliação. Times ajustam prompts para passar na suite em vez de servir o mundo real, e a nota sobe enquanto a qualidade em produção não. Mantenha um conjunto reservado que o time nunca usa para ajuste, e renove casos a partir do tráfego real.
• Um conjunto envelhecido. Entradas novas aparecem, a distribuição muda, e um conjunto congelado aos poucos deixa de representar a realidade. O ciclo fechado é o antídoto.
• Um juiz modelo sem validação. Um avaliador LLM nunca conferido contra rótulos humanos pode estar confiantemente errado em escala. Valide primeiro, depois mantenha o desempate humano nas divergências.
• Lock-in vestido de segurança. Uma suite presa ao formato de um único fornecedor derruba o propósito. Guarde o golden set e os avaliadores no seu próprio repositório para que a suite sobreviva a qualquer modelo.

Como a Avante constrói avaliações com operadores de domínio

A razão pela qual nossas suites se sustentam é quem escreve o golden set. A Avante Ventures lança 3-4 ventures por ano por um sistema de seis estágios, Research, Partner, Build, Traction, Revenue, Compound, empregando $500K-1.5M por venture e retendo economia de co-founder. O operador de domínio, a pessoa com uma década de calo no vertical, é a fonte dos rótulos corretos, e senta dentro do time de produto desde o estágio Partner. O gate entra no ar no Build e endurece ao longo de Traction e Revenue. O conjunto de avaliação que compõe é um ativo de estágio Compound que acompanha a venture na captação.

É também por isso que um time enxuto entrega um produto defensável sem uma Série A. Inferência barata mais uma suite disciplinada significam que o moat é o dado e as avaliações, não um caixa de guerra para computação. A própria suite é encanamento de empresa que um studio resolve uma vez e roteia por cada venture, transformando infraestrutura compartilhada em cerca de $300K-500K de capital efetivo por venture que vai para produto em vez de overhead.

A pressão é real no nosso mercado. O uso de IA entre empresas industriais brasileiras saltou de 16,9% em 2022 para 41,9% em 2024, cerca de 2,5x em dois anos, segundo o IBGE. A adoção corre à frente do controle de qualidade, que é o gap do DORA num país só. Num mercado em que serviços são cerca de 70% do PIB brasileiro com baixa penetração de software, o prêmio da IA vertical é grande, e vai para os times cuja qualidade é medida, não afirmada. Leia a tese em /why-avante. O time que consegue provar que seu modelo ainda funciona depois de uma troca é o time que continua podendo trocar.

Perguntas frequentes

O que é uma suite de avaliação de IA?

Uma suite de avaliação de IA é um conjunto versionado de casos de teste rotulados por especialistas mais avaliadores automáticos que dá nota à saída do modelo a cada deploy e a cada mudança de prompt ou de modelo. Ela transforma qualidade de algo que você olha no olho em algo que você mede. Diferente de testes unitários, que afirmam uma saída exata, ela avalia saída probabilística nos casos que importam para o seu vertical.

Como construir uma suite de avaliação de IA?

Construa em cinco passos. Monte um golden set de casos reais rotulados por especialistas incluindo casos de borda difíceis, escreva avaliadores que dão nota a cada saída contra sua referência, registre uma linha de base, ligue a suite à CI como gate de deploy e devolva cada falha de produção para o conjunto. A ordem importa, porque cada passo depende do anterior.

Qual a diferença entre uma suite de avaliação e testes unitários?

Testes unitários checam código determinístico, em que uma entrada dada precisa devolver uma saída exata. Uma suite de avaliação dá nota à saída probabilística de um LLM, em que a pergunta é se a resposta está certa com frequência suficiente numa distribuição realista de casos. Você precisa da suite no momento em que um LLM entra numa decisão com que um usuário ou regulador se importa.

Que tipo de avaliador usar para evals de LLM?

Case o avaliador com a tarefa. Use correspondência exata ou de string por código para tarefas categóricas e de extração, por ser a mais rápida e confiável. Use um juiz modelo pontuado por rubrica para saída aberta, validado antes contra rótulos humanos, com desempate humano nas divergências. Evite avaliação humana pura em escala porque é lenta e cara.

Por que as avaliações importam mais à medida que a inferência fica mais barata?

Porque o custo caindo da inferência é o que torna uma troca de modelo valer a pena, e as avaliações são o que a tornam segura. O custo de LLM na qualidade do GPT-3 caiu cerca de 1000x em três anos segundo a a16z, então um modelo base mais barato ou melhor aparece o tempo todo. Um time independente de modelo captura essa vantagem só se uma suite de avaliação provar que a qualidade se manteve na mudança.