Avaliação de LLMs: datasets próprios e checagens no CI
Um agente que funciona numa demo não está avaliado. Assim avalio os do AgendaGo, que está em produção: datasets próprios, checagens determinísticas e evals com modelo contra o stack real.
O que significa avaliar um LLM
Avaliar é medir o comportamento do agente com casos fixos e critérios escritos de antemão, não testar à mão algumas frases. Sem isso, cada mudança de prompt ou de modelo pode quebrar algo e ninguém descobre até um cliente reportar.
Como fiz no AgendaGo (em produção)
- Assistente do painel: um dataset de 100 frases, com a ferramenta esperada para cada uma, e checagens determinísticas no CI.
- Agente de WhatsApp: um dataset de 52 cenários e 15 conversas. As categorias incluem saudação, preço, reserva, ambiguidade, adversarial e prompt injection.
- Cada cenário declara a rota esperada, os critérios de acerto e o comportamento proibido.
- Os evals com modelo rodam contra o stack real, com um teto de gasto, e existe um script de juiz às cegas.
Decisões e compromissos
Separei o que pode ser verificado sem modelo do que não pode. As checagens determinísticas rodam no CI a cada mudança; os evals com modelo rodam contra o stack real e custam dinheiro, por isso levam um teto de gasto.
Que cada cenário declare o que o agente não deve fazer importa tanto quanto o que ele deve fazer: um caso adversarial ou de prompt injection só passa se o agente não cair.
A avaliação se complementa com a telemetria por chamada da tabela ai_usage_log, que registra modelo e versão do prompt, e com um teste que exige que cada insert declare as duas coisas. Conto isso na página de observabilidade.
Stack relacionado
- OpenAI
- Supabase
- CI