CI/CD + eval gates
Você implementará um pipeline que executa testes e um gate de regressão antes de preparar publicação. O artefato final inclui manifesto, relatório e workflow. A primeira validação será local e determinística: a candidata com erro de autorização precisa falhar; a versão corrigida precisa passar com o mesmo conjunto.
Prepare Node, package.json com script eval:gate e um dataset congelado. O gate não necessita de API. A etapa opcional com modelos reais exige segredos específicos de avaliação e orçamento definido; implantação exige credencial separada. Não coloque chaves no workflow, no JSON de casos ou no manifesto. A execução local deve continuar disponível para diagnosticar uma falha do runner remoto.
JavaScriptAgentesAvaliaçãoInfraestruturaAo terminar esta aula
- Gate precisa rejeitar regressão e falta de evidência.
- Versão inclui prompt, modelo, dados, ferramenta e avaliador.
- O artefato publicado deve ser o artefato aprovado.
Antes de continuar: Leitura: CI/CD + eval gates
Organizar versões e construir o manifesto
FundamentosCrie prompt.txt, cases.json e rubric.json. Calcule hashes dos três arquivos e acrescente commit, modelId, provider, schemaVersion e lockfileHash ao manifest.json. Mude uma linha do prompt e confirme que o hash muda. Faça o relatório de avaliação referenciar esse manifesto, e não somente um nome como prompt-final. Guarde versão concreta do avaliador. Para aliases de modelo ou prompt, explique que são referências mutáveis e registre a resolução observada. O manifesto deve acompanhar o pacote que será promovido.
Validar o gate com falhas intencionais
FundamentosExecute gate.cjs e confira a saída false com reason critical e exit code um. No PowerShell, inspecione LASTEXITCODE após o comando; em Bash, use o status do processo. Corrija candidate do caso auth para true e espere aprovação. Remova common e espere incomplete; duplique um ID e espere a mesma classe de falha. Adicione uma regressão não crítica e confirme o bloqueio pela política do exemplo. Esses testes verificam que a ausência de dados e as perdas não desaparecem dentro de uma média.
const assert=require('node:assert/strict');
function gate(rows,expectedIds){
const ids=rows.map(r=>r.id);
if(new Set(ids).size!==ids.length || ids.length!==expectedIds.length ||
expectedIds.some(id=>!ids.includes(id))) return {pass:false,reason:'incomplete'};
const critical=rows.filter(r=>r.critical && !r.candidate);
const regressions=rows.filter(r=>r.baseline && !r.candidate);
return {pass:critical.length===0 && regressions.length===0,
reason:critical.length?'critical':regressions.length?'regression':'ok'};
}
const rows=[
{id:'common',baseline:true,candidate:true,critical:false},
{id:'auth',baseline:true,candidate:false,critical:true},
{id:'abstain',baseline:true,candidate:true,critical:false}
];
assert.equal(gate([],['common']).pass,false);
assert.equal(gate([...rows,rows[0]],rows.map(r=>r.id)).reason,'incomplete');
const result=gate(rows,['common','auth','abstain']);
console.log(JSON.stringify(result));
process.exitCode=result.pass?0:1;Criar o workflow e preservar dependências
AutomaçãoEm .github/workflows/quality.yml, defina eventos de pull_request e push, um job quality e steps para checkout, setup-node, npm ci, npm test e npm run eval:gate. Use as versões oficiais vigentes das ações e registre-as, preferindo SHA quando a política do projeto exigir pinning. Declare um job build com needs:quality para demonstrar bloqueio. Não adicione continue-on-error ao gate. Teste o workflow em uma branch com a fixture errada e depois corrigida, conservando os logs sanitizados. Se não executar GitHub, entregue validação local e identifique a execução remota como pendente.
Separar segredos e controlar código não confiável
FundamentosCrie uma variável de ambiente local fictícia para verificar que o script não imprime seu valor. Para eval real, configure um segredo de avaliação com limite de uso, separado do segredo de deploy. Não forneça credenciais a contribuições não confiáveis sem uma política explícita. Revise artefatos e logs antes de enviar; respostas de modelo podem conter dados sensíveis mesmo quando a chave está mascarada. Simule ausência da credencial e espere erro de configuração legível, sem um resultado de avaliação vazio aprovado.
Demonstrar promoção e revisar o limite do gate
FundamentosEmpacote a versão apenas após passar os checks e faça o pacote conter o manifesto aprovado. Compare o hash do pacote que sai do build com o usado na próxima etapa. Adicione um caso difícil da semana 37 e explique como o juiz é calibrado e versionado antes de integrar sua decisão. Entregue uma tabela com cenário, resultado esperado, exit code observado e motivo. O README deve dizer quais verificações são determinísticas, quais usam API, quantos casos foram executados e quais falhas ainda requerem revisão humana. Um pipeline verde não é uma promessa de ausência de erro fora desses critérios.
Exercício aplicado
O pipeline aprova uma candidata com zero casos porque a API de avaliação falhou, e o deploy resolve um alias de prompt atualizado depois do gate. Corrija as duas fronteiras.
- Exija todos os IDs esperados e resultado não vazio.
- Trate falha de avaliação como erro ou inconclusivo bloqueante.
- Registre prompt imutável no manifesto.
- Promova o mesmo artefato que foi avaliado.
Abrir resolução comentada
Um conjunto vazio não fornece evidência e deve bloquear. O gate valida completude antes de calcular qualquer score. A indisponibilidade externa não equivale a aprovação.
O alias mutável permite mudar o comportamento depois da avaliação. Resolva e fixe a versão concreta no artefato; uma atualização exige novo gate. A integridade entre relatório, manifesto e pacote torna a decisão revisável.
const assert=require('node:assert/strict');
function gate(rows,expectedIds){
const ids=rows.map(r=>r.id);
if(new Set(ids).size!==ids.length || ids.length!==expectedIds.length ||
expectedIds.some(id=>!ids.includes(id))) return {pass:false,reason:'incomplete'};
const critical=rows.filter(r=>r.critical && !r.candidate);
const regressions=rows.filter(r=>r.baseline && !r.candidate);
return {pass:critical.length===0 && regressions.length===0,
reason:critical.length?'critical':regressions.length?'regression':'ok'};
}
const rows=[
{id:'common',baseline:true,candidate:true,critical:false},
{id:'auth',baseline:true,candidate:false,critical:true},
{id:'abstain',baseline:true,candidate:true,critical:false}
];
assert.equal(gate([],['common']).pass,false);
assert.equal(gate([...rows,rows[0]],rows.map(r=>r.id)).reason,'incomplete');
const result=gate(rows,['common','auth','abstain']);
console.log(JSON.stringify(result));
process.exitCode=result.pass?0:1;Como conferir seu resultado
- Regressão crítica retorna exit code não zero.
- Dataset vazio ou incompleto bloqueia.
- Manifesto liga prompt, agente, dados e avaliador.
- Build depende do gate e preserva o artefato aprovado.
Aplique em um problema novo
Primeiro resolva sem consultar a resposta. Explique suas decisões e guarde a evidência. A conclusão de leitura é independente desta autoavaliação.
Confira seus pré-requisitos
- Ligar manifesto e artefato avaliado.
- Definir gate com completude/criticidade.
Gate exige ids C1, C2, A1 sem perda crítica; outputs contêm só C1/C2. Depois conjunto completo passa, mas prompt muda hash H1→H2 antes do build. Defina dois gates.
Conferir raciocínio e critérios de domínio
Primeiro gate falha por A1 ausente: completude insuficiente produz exit não zero, não uma taxa perfeita de2/2.
Com conjunto completo e sem perdas, H1 pode passar. O build H2 não corresponde ao manifesto H1 e requer novo gate; promoção de H2é bloqueada.
Jobs posteriores sódependem da versão/relatório aprovado. continue-on-error ou resolver alias mutable após o gate destruiria essa ligação.
Evidências para autoavaliação ou revisão por pares
- Completude dos casos: Primeiro gate falha por A1 ausente: completude insuficiente produz exit não zero, não uma taxa perfeita de2/2.
- Vínculo do manifesto: Com conjunto completo e sem perdas, H1 pode passar. O build H2 não corresponde ao manifesto H1 e requer novo gate; promoção de H2é bloqueada.
- Dependências da promoção: Jobs posteriores sódependem da versão/relatório aprovado. continue-on-error ou resolver alias mutable após o gate destruiria essa ligação.
Um erro frequente
Pipeline verde prova ausência de erro futuro.
Pipeline verifica critérios conhecidos, não todos os erros futuros.
Teste sua compreensão
Responda com suas palavras antes de abrir o comentário. Saber explicar uma decisão é parte do domínio.
1. Um alias identifica uma versão imutável?
2. Falha de API de avaliação pode virar pass?
Não.
Sem evidência, o gate precisa bloquear ou exigir revisão.
3. Por que separar teste e eval?
Porque verificam contratos diferentes.
Autorização de backend é determinística; comportamento de modelo pode ser variável.
Seu progresso fica salvo neste navegador. Concluir a leitura não substitui demonstrar o domínio nos exercícios.
Referências e aprofundamento
Documentação oficial e trabalhos originais. As referências registram o escopo e as limitações para você conferir o que sustentam.
- Understanding GitHub Actions
GitHub • consulta: 2026-10-06
FundamentosWorkflows, eventos, jobs, steps, dependências e build/test/deploy automatizados.
Limites: Gates de eval são política da aplicação implementada em scripts e limiares, não garantia nativa de qualidade.
- Evaluation best practices
OpenAI • consulta: 2026-10-06
OpenAIDatasets representativos, casos difíceis, avaliação contínua, rubricas, comparação pareada, sucesso de ferramentas e tarefas.
Limites: Juízes LLM têm viés de posição e extensão; calibrar com avaliações humanas. Um score não garante verdade factual.
- Version Tracking for Agents and LLMs
MLflow • consulta: 2026-10-06
AgentesIA & MLVersionamento e rastreamento de aplicações de agentes e sua associação a traces e avaliações.
Limites: Versionar código/configuração não congela comportamento de aliases de provedores externos.
- Prompt Registry
MLflow • consulta: 2026-10-06
FundamentosRegistro, versões e aliases de prompts e associação ao ciclo de avaliação.
Limites: Aliases são mutáveis; registrar versão concreta para comparação e reprodução.
- Using secrets in GitHub Actions
GitHub • consulta: 2026-10-06
FundamentosSecrets por repositório, ambiente e organização e seu uso em workflows.
Limites: Disponibilidade e acesso variam por evento e configuração; não imprimir segredos.
- Manage secrets securely in Docker Compose
Docker • consulta: 2026-10-06
DockerSecrets montados em arquivos e concessão explícita por serviço.
Limites: O arquivo de origem também precisa de proteção; suporte apresentado para Linux containers.
- ML Model Registry
MLflow • consulta: 2026-10-06
IA & MLRegistro central de modelos, versões, aliases e rastreamento de ciclo de vida.
Limites: Registro organiza artefatos; permissões, implantação e políticas precisam de configuração.
- Model selection
OpenAI • consulta: 2026-10-06
OpenAIEscolha e iteração de modelos usando qualidade, custo e latência com evals.
Limites: Nomes, disponibilidade e tarifas mudam; o curso deve usar experimentos e critérios, não ranking fixo.