Como criar um conjunto de avaliação por cenários para um sistema de IA empresarial

Um bom conjunto de avaliação começa por um fluxo empresarial delimitado, não por uma coleção de perguntas difíceis. Imagine um assistente interno de solicitações de compra recebendo uma pasta plausível, mas com identificadores de fornecedor conflitantes, política indisponível e uma cotação que contém instruções dirigidas ao próprio assistente. Exemplos polidos de demonstração dificilmente mostram se ele pedirá evidências, respeitará a aprovação humana e ignorará a instrução inserida no arquivo. Para apoiar uma decisão de liberação, os casos precisam reproduzir o trabalho, explicitar variações aceitáveis, revelar falhas importantes e tornar condutas proibidas observáveis.

O que um conjunto de avaliação por cenários deve cobrir?

Um conjunto por cenários deve cobrir o trabalho representativo e, de forma intencional, limites relevantes, falhas confirmadas e comportamentos proibidos. Primeiro, fixe a versão do sistema, os atores autorizados, as entradas permitidas, o conhecimento e as ferramentas disponíveis e a decisão que o resultado apoiará. Depois, mapeie famílias de tarefas e variações com registros de trabalho autorizados, chamados de suporte, pesquisa com usuários, incidentes e caminhadas guiadas por especialistas do domínio. Quando os dados operacionais forem incompletos ou inexistentes, registre a incerteza em vez de inventar precisão.

A parcela de casos comuns deve guardar relação com o fluxo observado, sem transformar frequência em único critério de inclusão. Condições raras, porém consequentes, precisam entrar deliberadamente, assim como os dois lados de um limite: quando o sistema deve agir e quando deve pedir esclarecimento, se abster, recusar ou encaminhar. Defina antes das saídas quais famílias, fatias e barreiras serão reportadas. Essa ordem reduz o risco de escolher critérios depois de descobrir qual configuração parece melhor e mantém o teste ligado à decisão originalmente declarada.

No assistente de compras, o mapa pode reunir solicitações completas, documentos ausentes, valores ou fornecedores conflitantes, fatos não disponíveis, tentativas de pular uma aprovação, instruções escondidas em cotações, recuperação de política indisponível e reproduções minimizadas de falhas anteriores. As regras são apenas ilustrativas: cada organização precisa definir seus próprios poderes, fontes aprovadas e limites. Dados reais também não são automaticamente reutilizáveis ou corretamente rotulados; informações pessoais, confidenciais, licenciadas ou reguladas exigem autorização aplicável, minimização e controles de acesso.

Como registrar cada cenário de avaliação?

Cada cenário deve ser registrado como um caso reproduzível que permita a outro avaliador recriar a configuração, reconhecer resultados válidos e aplicar a mesma regra de avaliação. Dê ao caso identidade estável, responsável, histórico de versões, família de cobertura, família de tarefa, etiquetas de fatia, consequência, proveniência, autorização e divisão pretendida. O registro completo é uma síntese editorial adaptável, não um padrão prescrito por uma única fonte. Seu nível de detalhe deve acompanhar o fluxo, os riscos e a governança das evidências.

• Configuração: ator e objetivo, estado inicial, solicitação, arquivos, histórico relevante, instruções e condições do ambiente.
• Recursos: conhecimento autorizado, ferramentas, permissões e resultados de ferramentas que realmente estarão disponíveis durante o teste.
• Expectativas: fatos ou mudanças de estado exigidos, caminhos alternativos aceitáveis e situações que pedem esclarecimento, abstenção, recusa ou encaminhamento.
• Operação: avaliador, rubrica, barreiras, solução de referência quando útil, versões técnicas, qualificação do revisor e rota de adjudicação.

Separe resultados proibidos — como divulgação, chamada de ferramenta ou mudança de estado não autorizada — das expectativas gerais de qualidade. Em tarefas abertas, não converta uma boa resposta de referência na única redação aceita; use-a para demonstrar que o caso é solucionável e identificar elementos necessários. Se o sistema for não determinístico ou executar várias etapas, declare antecipadamente quantas tentativas serão realizadas e como serão agregadas, sem transformar qualquer quantidade em regra universal. Registre também modelo, prompt, corpus de recuperação, ferramentas, política, permissões e harness usados.

Um caso útil não apresenta apenas uma pergunta difícil: ele recria um trabalho delimitado e torna inspecionáveis o sucesso, a variação aceitável e a conduta proibida.

Como pontuar cada cenário sem premiar o comportamento errado?

Cada cenário deve usar o método mais restrito que consiga distinguir sucesso de falha com validade. Verificações determinísticas servem para respostas objetivas, esquemas, cálculos, argumentos de ferramentas, estados de registros e ações vedadas, mas uma verificação precisa ainda pode estar incompleta ou aceitar atalhos indevidos. Fatos ou soluções de referência atendem tarefas com evidências delimitadas e múltiplas formulações válidas. Qualidades realmente abertas pedem dimensões separadas, âncoras observáveis e calibração contra julgamentos humanos pertinentes ao contexto.

• Use verificações determinísticas quando o resultado ou estado correto puder ser observado objetivamente.
• Use fatos de referência quando vários caminhos forem aceitáveis, mas as evidências exigidas ou o estado final forem delimitados.
• Use rubricas ancoradas para utilidade, completude, fundamentação, tom ou explicação, avaliando cada dimensão separadamente.
• Use julgamento humano qualificado quando a interpretação de domínio ou a consequência não puder ser resolvida validamente por automação.

Avaliar o resultado costuma ser menos frágil do que exigir uma trajetória incidental, e componentes significativos podem receber crédito parcial. Entretanto, uma divulgação proibida ou ação não autorizada deve permanecer fora da soma compensável, conforme barreira definida previamente pelos responsáveis autorizados pelo produto e pelo risco. Fixe versões da rubrica, lógica das barreiras, definições de fatia, agregação de tentativas e regra de decisão antes de comparar candidatos. Mudanças posteriores formam uma nova versão da avaliação. O próprio GDPval relatou que seu avaliador automatizado não substituía profissionais experientes.

Como fazer os revisores aplicarem os critérios com consistência?

Os revisores aplicam critérios com mais consistência quando recebem contexto suficiente, âncoras observáveis, casos de calibração e uma rota explícita para dúvidas. Antes de exibir uma saída, informe o propósito do fluxo, o papel do ator, as evidências disponíveis, o comportamento permitido, o limite do produto e a versão da rubrica. Para cada ponto da escala, descreva sinais que possam ser observados e ofereça exemplos positivos, negativos e de fronteira. Inclua uma opção de evidência insuficiente ou caso impossível de pontuar.

1. Execute casos de calibração antes da revisão ativa e repita o exercício quando tarefa, política, rubrica ou grupo de revisores mudar.
2. Oculte a identidade do sistema e alterne a ordem das saídas quando isso for viável e relevante para comparações.
3. Colete notas e justificativas independentes antes da discussão para não substituir julgamento por alinhamento social.
4. Investigue divergências como possível sinal de caso defeituoso, limiar ambíguo, contexto ausente ou pluralidade legítima.
5. Nomeie um responsável pela adjudicação e diferencie correção de erro de uma decisão ainda pendente do produto.
6. Preserve rótulos, justificativas, versões da rubrica e decisões para auditoria posterior e recalibração de avaliadores.

Consistência não significa forçar unanimidade. Se duas respostas atendem legitimamente ao objetivo, o caso ou a rubrica deve comportar essa variação; se o desacordo expõe uma escolha de política ainda não tomada, o responsável autorizado precisa resolvê-la fora da sessão de pontuação. A inspeção conjunta de notas e rastros também ajuda a separar uma falha real do sistema de uma tarefa impossível, ferramenta quebrada, evidência ausente ou avaliador mal configurado. O procedimento completo é adaptável e não determina um número universal de revisores.

Como manter o conjunto útil durante o desenvolvimento e a liberação?

O conjunto permanece útil quando os casos visíveis de desenvolvimento são separados de um teste protegido de liberação e ambos são mantidos em um registro versionado. A equipe pode executar repetidamente o conjunto de desenvolvimento para ajustar prompts, recuperação, ferramentas, políticas e o próprio fluxo, mas sua nota passa a representar evidência de desenvolvimento. A divisão de cada caso deve ser atribuída quando ele entra no registro, antes da execução rotineira e da inspeção de saídas que possam influenciar sua seleção.

• Reserve o teste protegido para comparações finais ou decisões de liberação e evite que casos, respostas, rubricas ou resultados orientem a iteração.
• Procure duplicatas exatas e próximas, registros de origem compartilhados, paráfrases e casos irmãos gerados pelo mesmo modelo de cenário.
• Registre o acesso ao conteúdo dos casos, às respostas de referência, às rubricas e aos resultados, não apenas a abertura do arquivo principal.
• Mova para desenvolvimento qualquer caso protegido que tenha influenciado materialmente uma mudança e crie uma substituição independente e versionada.
• Revise a cobertura após mudanças relevantes em usuários, fluxo, política, corpus, modelo, prompts, ferramentas, permissões ou ambiente operacional.

Uma falha confirmada que já orientou diagnóstico ou correção pertence ao desenvolvimento ou à regressão. O teste protegido pode examinar a mesma classe de falha por meio de um caso criado de maneira independente, sem duplicar o registro original nem revelar a resposta usada no ajuste. Não existe porcentagem universal entre as divisões, quantidade fixa de casos ou prazo único de renovação. Composição e tamanho dependem da decisão apoiada, da variabilidade do fluxo, das fatias consequentes, da confiabilidade da avaliação e das evidências autorizadas disponíveis.

O registro deve guardar responsável, proveniência, autorização, divisão, exposição, versões, revisão, motivo da mudança e motivo de retirada. Relate resultados por família de tarefa, família de cobertura, fatia, consequência e barreira, pois uma média isolada pode esconder o ponto que define a decisão. Um resultado offline é apenas uma fonte de evidência: não comprova sozinho valor empresarial, segurança, equidade, conformidade ou prontidão para produção. Combine-o com monitoramento, pesquisa com usuários, análise de incidentes e outros controles adequados ao sistema.

Responsáveis pelo produto e pelo risco devem definir as barreiras e o uso da avaliação antes de ver os resultados; especialistas do domínio devem validar o realismo do fluxo e os resultados esperados. Privacidade, segurança, jurídico, compliance, dados e outras funções qualificadas precisam revisar casos quando seu material governado estiver envolvido. Decisões jurídicas, médicas, financeiras, trabalhistas, de segurança, privacidade ou de outras áreas reguladas devem permanecer com pessoas devidamente qualificadas e autorizadas. O conjunto apoia uma decisão documentada, mas não funciona como certificado permanente de segurança ou liberação.