      
      artefato gratuito — sem muro de email
    

O checklist de avaliação pré-lançamento para funcionalidades de LLM

Dezoito checks antes de sua funcionalidade de LLM chegar a um cliente — destilados de uma plataforma de QA com 85 runners e dez evals de segurança de IA dedicados. Se você consegue marcar todas as caixas, lance. Se não consegue, sabe exatamente o que construir primeiro.

Ground truth

sem isso, qualquer outro check é apenas opinião

Existe um golden set: 30–200 inputs reais com outputs combinados como corretos, versionado no repositório junto ao código — não na planilha de alguém. Alguém com autoridade de domínio aprovou os outputs golden — não o engenheiro que escreveu o prompt. O golden set inclui casos difíceis: inputs ambíguos, formulações adversariais, solicitações fora de escopo, e pelo menos um exemplo "deveria recusar".

Medição

"parece melhor" não é uma métrica

Um LLM-as-judge (ou um scorer determinístico) avalia a fidelidade e a relevância em relação ao golden set — ser imperfeito tudo bem, ser consistente é obrigatório. Os scores do juiz são calculados por um comando, de forma reprodutível — você roda duas vezes e obtém o mesmo número. Um score base é registrado para que a próxima mudança de prompt/modelo produza um diff, não um debate. Existem orçamentos de custo e latência por requisição, e a execução do eval reporta contra eles.

Bateria de segurança

os modos de falha que acabam em prints de tela

Alucinação: as afirmações são checadas contra os dados-fonte em respostas baseadas em retrieval; caminhos de geração sem citação ficam fechados ou sinalizados. Injeção de prompt: inputs adversariais que tentam sobrescrever as instruções do sistema são testados e bloqueados. Jailbreak e recusa: a funcionalidade recusa o que deve — e não recusa o que não deve. Toxicidade e viés: os outputs são avaliados sobre seus inputs reais de usuário, não apenas sobre um conjunto de benchmark. Vazamento de PII: a funcionalidade não pode repetir dados de outros usuários nem resíduos de treinamento; os logs são higienizados.

O gate

um eval vermelho que não bloqueia nada é decoração

A suíte de eval roda em CI a cada PR que toca prompts, modelos, retrieval ou tools. Um score abaixo do piso bloqueia o merge — o gate para o deploy, não a retro. O piso só sobe: cada melhoria vira o novo mínimo.

Controle do raio de impacto

a autonomia se conquista com evidência, nunca se presume

Existe um ponto de aprovação humana onde está o risco: antes de cada envio (novo), antes de casos inéditos (comprovado), ou revisão posterior (maduro). As etapas de LLM emitem output estruturado e validado por schema com um rótulo de fallback em caso de falha de parsing — o input bruto sempre fica registrado ao lado da decisão. Existe um kill switch que uma pessoa não engenheira consegue acionar, e todo mundo sabe onde ele está.

Não conseguiu marcar todas as caixas?

Essa é a lacuna que eu fecho em um projeto de 4 semanas com escopo fixo — a suíte, o gate e o runbook, no seu repositório.

Como eu construo isso → Baixar o PDF