Pipelines de avaliação de modelos para equipes de produto

Avalie o sistema de produto, não apenas o foundation model

Benchmarks gerais ajudam a comparar capacidades amplas, mas o usuário interage com um sistema composto por instruções, montagem de contexto, retrieval, ferramentas, políticas, memória, interface e fallbacks sobre uma distribuição específica de dados. O HELM, de Stanford, demonstra tanto o valor quanto a incompletude de avaliações multidimensionais. A equipe de produto precisa testar o comportamento exato prometido ao usuário.

Um upgrade de modelo pode melhorar raciocínio e quebrar o JSON. Uma mudança de prompt pode melhorar o tom e aumentar afirmações sem suporte. Um retriever pode elevar recall e expor documentos do tenant errado. A avaliação deve acompanhar o grafo de dependências do produto, sem reduzir tudo a uma nota de qualidade.

A execução precisa ser reproduzível

O AI RMF do NIST pede processos objetivos, repetíveis ou escaláveis de teste, avaliação, verificação e validação. A reprodução começa com um run ID imutável para cada combinação avaliada. Registre modelo e versão do provedor, hash do prompt, instruções de sistema, schema das ferramentas, corpus e índice de retrieval, parâmetros de sampling, versão da política, commit do dataset, versões dos evaluators, commit do código, região e horário.

Sem esse manifesto, a equipe compara screenshots e médias que não consegue reconstruir. Com ele, identifica qual mudança criou a regressão, executa apenas suítes afetadas, preserva evidências e promove para produção o candidato exato que foi aprovado.

Construa datasets a partir da distribuição relevante

OpenAI e Anthropic recomendam definir critérios de sucesso antes dos testes. O eval set deve representar tráfego normal, jornadas de alto valor, falhas conhecidas, casos extremos e abuso. Também deve revelar segmentos escondidos pela média: idioma, região, plano do cliente, tipo de documento, ferramenta, intenção, tamanho de entrada, categoria sensível e necessidade de acessibilidade.

Use camadas. Um smoke set pequeno oferece feedback rápido no pull request. Um conjunto estável protege regressões conhecidas. Uma suíte maior sustenta a decisão de release. Um conjunto confidencial de red team reduz overfitting. Uma amostra móvel de produção detecta drift. Preserve um holdout que autores de prompt e loops de otimização não consultem repetidamente.

Dados de produção exigem consentimento, minimização, acesso controlado, retenção limitada, redação e isolamento entre tenants. Dados sintéticos ampliam casos raros, mas não substituem a distribuição real nem a revisão de especialistas.

Use primeiro o evaluator confiável de menor custo

O LLM-as-judge também precisa ser avaliado

Um model grader é software com dependência de modelo, prompt, rubrica, sampling e modos de falha. Versione-o. Crie um benchmark com exemplos avaliados de forma independente por humanos, meça concordância por categoria e segmento, investigue falsos passes e falsos bloqueios e refaça a calibração quando mudar o judge ou a rubrica.

Prefira classificação, comparação em pares ou critérios explícitos a pedidos vagos de nota. Randomize a ordem, esconda a identidade do modelo, exija output estruturado, permita abstention e envie divergências ou baixa confiança para humanos. Evite a mesma família do modelo candidato quando houver risco de ponto cego correlacionado. Guarde a explicação para debugging, mas faça o gate com campos validados.

Toda métrica precisa de uma política de falha

Uma melhora média pode esconder uma regressão catastrófica. Defina pisos absolutos, regressão máxima contra a baseline, casos críticos que sempre devem passar, mínimos por segmento, requisitos de confiança e orçamento de custo e latência. Segurança, privacidade, autorização e uso destrutivo de ferramentas são restrições rígidas, não dimensões ponderadas que qualidade pode compensar.

O manifesto do release deve explicar a decisão: IDs do candidato e baseline, versões dos datasets, quantidade de amostras, deltas, intervalos de confiança, falhas graves, decisões de revisores, exceções, plano de canary, responsável, expiração e rollback. Assim, avaliação deixa de ser dashboard e vira controle de release.

O eval offline termina na fronteira da produção

Antes da liberação ampla, reproduza traces em sandbox, execute o candidato em shadow mode ou use um grupo canary. Compare conclusão de tarefa, fallbacks, correções do usuário, escalonamento, violações, percentis de latência, tokens, erros de ferramentas e custo por outcome bem-sucedido. Experimentos com impacto precisam respeitar limites aprovados de segurança e privacidade.

Observações de produção devem gerar novos testes. Colete falhas e divergências, agrupe padrões recorrentes, remova conteúdo sensível, obtenha rótulos especializados e promova exemplos estáveis para as suítes. Isso fecha o ciclo sem transformar cada trace em dado permanente de treinamento ou avaliação.

Ownership operacional importa mais que o framework

Produto define outcome e tradeoffs. Especialistas de domínio definem correção. Engenharia garante reprodução. Segurança fornece casos de abuso e limites rígidos. Dados protegem lineage e privacidade. Design e suporte revelam falhas percebidas pelo usuário. Um responsável pelo release aceita ou rejeita o risco residual.

O pipeline deve executar uma suíte pequena em cada pull request relevante, suítes afetadas quando modelo, prompt, ferramenta, política ou corpus mudarem, a suíte completa antes do deploy e amostragem contínua após o release. Dívida de avaliação deve ser visível: casos sem owner, rótulos obsoletos, graders instáveis, segmentos ausentes e thresholds sem justificativa de produto.

O que eu construiria

Eu construiria um control plane de avaliação com registro versionado de datasets, rubricas, graders, prompts, modelos, contratos de ferramentas e políticas. Cada execução produziria manifesto imutável, evidência por caso, links para traces, custo e latência, comparação com baseline, decisões humanas e um registro assinado do release.

A visão de produto mostraria regressões por segmento, não uma nota: quais jornadas melhoraram, quais idiomas pioraram, quais ferramentas falharam, onde judges divergem de humanos, quanto a qualidade custa e se outcomes online confirmam a previsão offline.

O princípio de design

Avaliação de modelos não é um benchmark final antes do lançamento. É um sistema contínuo de feedback de produto. Defina o contrato, versione dependências, combine evidências determinísticas e probabilísticas, preserve autoridade humana diante de risco ambíguo, use gates explícitos e transforme falhas de produção na próxima suíte de testes.