EN·ES·PT
Consultor de avaliação de LLM

A suíte de eval que decide se o seu modelo vai para produção.

Um projeto de avaliação de LLM não é um relatório — é um sistema em funcionamento. Eu construo o golden dataset, a rubrica de pontuação e o gate de CI que avalia cada mudança de modelo ou de prompt em relação a ele e então bloqueia o merge quando a qualidade regride. Você pode ver uma versão funcional desse juiz avaliar uma resposta ao vivo, agora mesmo, antes de falar comigo.

Demo do juiz ao vivo: eval.html → Avalie a resposta da sua IA → ISTQB CT-AI + Test Automation Engineer
Assista · o diferencial da eval em ~45s
4
dimensões de pontuação por resposta
2
sinais: LLM-juiz + verificações determinísticas
1
gate de CI que pode bloquear um merge
100%
cobertura de citações no build RAG*

*O dashboard de pesquisa RAG cita 100% de suas afirmações por construção — não há caminho de código que gere uma frase sem citação. Verificado em case-studies.html. Todo outro número nesta página é uma característica de projeto do método, não uma média de clientes.

A rubrica · o que a demo ao vivo pontua

Quatro dimensões, cada uma com uma falha capturada e uma nota.

Toda resposta que o juiz vê é avaliada nos mesmos quatro eixos. Dois são determinísticos (passam ou não passam); dois usam um LLM-como-juiz com uma rubrica explícita, para que a nota seja explicável, não um achismo. Esta é a rubrica exata por trás da demo ao vivo.

Rubrica de avaliação — dimensão × falha capturada × método de pontuação
Dimensão O que ela captura Como é pontuada
Grounding Respostas que se afastam da fonte de verdade — afirmações que o contexto fornecido não sustenta de fato. LLM-como-juiz contra a fonte fornecida, mais uma verificação determinística de citações: toda afirmação precisa remeter a um trecho.
Alucinação Invenção com confiança — fatos fabricados, números falsos ou citações a fontes que nunca foram fornecidas. Diff determinístico afirmação-vs-contexto expõe declarações sem suporte; o juiz classifica a gravidade.
Segurança & injeção Obediência a prompt-injection, instruções de sistema vazadas e saídas inseguras ou fora de política. Verificações determinísticas de padrão & recusa em entradas adversárias; uma falha aqui pode bloquear o release de vez.
Qualidade da resposta Respostas tecnicamente fundamentadas, mas inúteis — fora da intenção, incompletas ou que ignoram a pergunta real. LLM-como-juiz em relevância, completude e objetividade, pontuado contra uma rubrica escrita.
▸ cole a resposta da sua IA & veja-a ser avaliada a demo roda esta rubrica em input real, ao vivo
A metodologia · golden set → juiz → gate

Como uma regressão é capturada antes de ir para produção.

Uma mudança de modelo ou prompt entra no CI. Ela roda contra um golden set curado de casos representativos. Cada saída é pontuada pelo LLM juiz e pelas verificações determinísticas. Se qualquer dimensão cair abaixo do seu piso, o gate bloqueia o merge — a mudança nunca chega aos usuários. Se tudo passa, vai para produção.

Fluxo do gate de avaliação de LLM Uma mudança e seu golden set alimentam uma etapa de avaliação que combina um LLM juiz e verificações determinísticas, produzindo notas que chegam a um gate de CI; mudanças aprovadas vão para produção, mudanças reprovadas são bloqueadas. Modelo / prompt mudança → CI Golden set casos curados AVALIAR LLM-como-juiz + verificações determinísticas GATE nota ≥ piso? PRODUÇÃO ✓ todos os pisos atingidos BLOQUEADO ✕ regressão
O gate é a entrega. Sem ele, evals são um dashboard que ninguém lê; com ele, uma mudança ruim fisicamente não consegue dar merge.
A prova · este gate já bloqueou um release

Uma história vermelho → verde com os comprovantes que eu posso te mostrar.

Na minha própria plataforma de QA, nexural-qa-os, o gate fez exatamente o que um gate deve fazer: detectou 15 CVEs altas/críticas e bloqueou seu próprio release. No mesmo dia, os problemas foram corrigidos e o sistema ficou verde — 3.759 testes passando, 13 de 13 gates limpos. A evidência são duas execuções capturadas, antes e depois.

Antes — release bloqueado
  • 15 CVEs altas/críticas detectadas
  • O gate se recusou a aprovar o build
  • Nada foi para produção
Depois — no mesmo dia, verde
  • 3.759 testes passando
  • 13 / 13 gates limpos
  • Corrigido, re-executado, entregue
Por que isso importa para você

Um gate só conquista confiança no dia em que barra o seu próprio release. Este barrou — e eu guardei as capturas em vez de apenas afirmar isso.

▸ a execução bloqueada ▸ a execução verde duas execuções capturadas · antes & depois · mesmo dia
Prova adjacente · a mesma disciplina, em outros lugares

O rigor de eval é uma faceta de como eu testo.

Suítes determinísticas

Uma suíte pública de regressão SDET: 37/37 specs, 0 flakes, 15,3s. Verde significa verde.

ver o repositório ↗
Flakiness sob controle (fintech)

HighStrike (um cargo full-time anterior, dados autodeclarados): taxa de flakiness reduzida de 10% para menos de 1% em mais de 500 testes em fluxos de trading ao vivo.

Escala (Fortune 50)

The Home Depot: um framework Selenium para mais de 2.300 lojas; regressão reduzida de 4h para 75min.

▸ os estudos de caso completos e sim — este site roda seu próprio QA: mais de 100 checagens, limpo no axe
Relacionados · mais sobre testar IA
Contratar um Engenheiro de QA de IA →Avaliação de RAG →Teste de Agentes de IA →Reduzir Flakiness de Testes →

Preocupado com uma funcionalidade de IA específica?

Avalie ao vivo em 30 segundos, ou agende uma conversa e definimos juntos o golden set, a rubrica e o gate que a protege.

Agendar uma conversa → ▶ testar o juiz ao vivo o serviço completo →
perguntas frequentes

Dúvidas, respondidas.

O que é uma avaliação de LLM, na prática?
Uma forma repetível de pontuar a saída do seu modelo — precisão, fidelidade, segurança — em relação a casos comprovadamente corretos, para que uma mudança de prompt ou de modelo que piore os resultados seja detectada antes de ir para produção.
De quantos casos de teste você precisa para começar?
Geralmente de 50 a 200 casos representativos — sinal suficiente para servir de gate — expandidos à medida que modos de falha reais aparecem em produção.
Você consegue aplicar um gate no nosso CI com base nos resultados da eval?
Sim. A eval roda no CI e bloqueia o merge se algum limite regride (cobertura de citações, taxa de alucinação, resistência a injeção). Vermelho antes da produção, não depois.
Quais frameworks e modelos você usa?
Independente de provedor — Promptfoo, DeepEval e Pytest sobre uma interface padrão de chat-completions, usando seus modelos e suas contas sempre que possível.
Qual precisa ser o tamanho do golden dataset para ser útil?
Algumas dezenas de casos bem escolhidos superam centenas de casos aleatórios. Comece pelos modos de falha que de fato te prejudicam — prompts reais de usuários, casos de borda, incidentes passados — e faça o conjunto crescer conforme novas falhas surgem.
A pontuação por LLM-como-juiz é confiável o bastante para servir de gate?
Não sozinha. Os prompts do juiz são validados em relação a casos rotulados por humanos, e o gate se apoia em verificações determinísticas — correspondência exata, presença de citação, schema, detecção de recusa — sempre que a resposta permite, reservando o juiz para os julgamentos genuinamente subjetivos.
Como o gate de eval se encaixa no CI que eu já rodo?
Ele roda como mais uma verificação no seu pipeline existente — um passo no GitHub Actions ou no que você usar — que aprova ou reprova o build. Nenhuma plataforma nova a adotar; a eval fica ao lado dos seus testes unitários e bloqueia o merge no mesmo X vermelho.
O que acontece com o gate quando eu troco de modelo ou edito um prompt?
É exatamente para isso que ele serve. Qualquer troca de modelo ou edição de prompt re-executa a suíte completa, e uma mudança que regride grounding, segurança ou qualidade da resposta deixa o build vermelho antes de chegar aos usuários.
Você constrói isso no meu repositório ou em uma ferramenta separada?
No seu repositório. A suíte, o golden set e a configuração de CI ficam versionados junto ao seu código, então você é dono dele, roda e estende sem depender de mim nem de um dashboard hospedado.
Quanto tempo até o primeiro quality gate estar no ar?
O primeiro gate funcional — um pequeno golden set conectado ao CI e bloqueando em um limite real — chega cedo, e a suíte se aprofunda a partir daí. Você vê um build ficar vermelho diante de uma mudança ruim antes do fim do projeto, não um slide sobre isso.