Avaliando features com LLM como engenheiro, não como fã

O estado mais comum de uma feature com LLM que me chamam para auditar é este: foi para produção, as pessoas gostam, e ninguém consegue me dizer se a mudança de prompt da semana passada melhorou ou piorou. Não existe dataset, não existe score, não existe baseline. Existe uma demo que impressionou um stakeholder e alguns prints num canal. Isso é torcida, não engenharia. Engenharia é quando você pode estar errado de um jeito mensurável.

Sensação não é métrica

A saída de um modelo parece boa na primeira leitura quase por construção. Texto fluente convence. As falhas estão na segunda leitura, no input raro, no caso que não estava na demo. A única defesa é parar de ler saídas individuais como juiz de qualidade e passar a ler resultados agregados sobre um conjunto fixo de inputs. Com isso em mãos, cada mudança no prompt, no retrieval, no modelo ou no schema vira um número que subiu ou desceu, e a conversa deixa de ser gosto e passa a ser evidência.

Construa o dataset antes da feature

Construo o conjunto de evals do jeito que escrevo testes para uma máquina de estados: antes da implementação, a partir da spec. Cinquenta a algumas centenas de inputs bastam para começar. Precisam incluir o meio chato, os casos de borda que importam para o negócio, os inputs que devem ser recusados e alguns abertamente hostis. Para cada um, registro uma saída esperada, um conjunto de fatos obrigatórios ou uma rubrica de avaliação. Tráfego real de produção, anonimizado e rotulado, é a melhor fonte, e o conjunto cresce toda vez que um usuário reporta uma resposta ruim. Cada bug vira um caso, como em qualquer suíte de regressão.

Três tipos de eval

Algumas verificações são determinísticas: a saída bate com o schema, a data confere com a fonte, a frase proibida está ausente, o trecho citado existe. São baratas e rodam em todo commit. Algumas são por similaridade: a resposta está perto o bastante de uma referência, com uma comparação tolerante. E algumas exigem julgamento: este resumo é fiel, esta resposta é adequada. Para essas uso um modelo como avaliador, com rubrica, e trato esse avaliador como um componente com seus próprios testes. A mistura importa. Uma feature avaliada só por um juiz-modelo tem um ponto cego exatamente onde juiz e gerador compartilham premissas.

Juízes precisam ser julgados

Antes de confiar num avaliador-modelo, peço para humanos rotularem uma amostra e meço a concordância. Se o avaliador concorda com as pessoas menos do que duas pessoas concordam entre si, não é avaliador, é ruído com tom confiante. Também verifico os vieses óbvios: preferir saídas mais longas, preferir o próprio estilo, preferir o primeiro de dois candidatos. Calibrar o juiz leva uma tarde, e é a tarde que dá sentido a todos os números seguintes.

Evals como suíte de regressão

Com o conjunto pronto, ele roda no CI como qualquer outro teste, com limiar e relatório. Uma mudança de prompt que derruba a fidelidade em alguns pontos bloqueia o merge, igual a um teste unitário falhando. Uma versão nova de modelo é avaliada antes de ser habilitada, não depois das reclamações. E o relatório é uma tabela que qualquer um lê: casos, scores, diffs. É isso que transforma uma feature de IA de algo que o time se orgulha em algo pelo qual o time responde. Os fãs ficam com o entusiasmo. Os engenheiros ficam com o emprego.