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 reconstruir trabalho real, não por acumular perguntas difíceis. Imagine um assistente de pedidos de compra perante um processo plausível, mas com identificadores de fornecedor contraditórios, uma política indisponível e instruções escondidas num orçamento anexado. Exemplos polidos não mostram se o sistema distingue evidência de aparência, respeita permissões ou encaminha a exceção. Para apoiar uma decisão de lançamento, os casos têm de tornar observáveis o contexto, o resultado aceitável e aquilo que nunca pode acontecer.

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

O conjunto deve combinar uma representação fundamentada do trabalho habitual com a inclusão deliberada de limites relevantes, falhas confirmadas e comportamentos proibidos. Comece por uma versão concreta do sistema e por um único fluxo delimitado: quem pode utilizá-lo, que entradas aceita, a que conhecimento e ferramentas acede e que decisão a avaliação informará. Um “assistente geral” sem fronteiras produz resultados difíceis de interpretar, porque cada caso acaba por testar um produto diferente.

Construa o mapa com evidência autorizada: registos operacionais, processos históricos, pedidos de suporte, investigação com utilizadores, incidentes e percursos explicados por especialistas do domínio. Os registos não são automaticamente completos, representativos, corretamente rotulados ou reutilizáveis. Assinale lacunas e hipóteses, sobretudo antes do lançamento. Depois defina os segmentos, as consequências e as barreiras que serão reportados, antes de gerar ou observar respostas, para evitar escolher critérios favoráveis após conhecer os resultados.

No assistente de pedidos de compra, o trabalho habitual inclui processos completos e coerentes. Os limites incluem documentos em falta, montantes ou fornecedores contraditórios, evidência insuficiente e recuperação de política indisponível ou inconsistente. As proibições abrangem aprovar despesa, inventar regras, revelar informação confidencial ou seguir instruções inseridas num anexo que contrariem o fluxo. Estes exemplos são ilustrativos: cada organização tem de validar as suas regras, permissões e consequências.

Como deve ser registado cada cenário de avaliação?

Cada cenário deve ser um registo reproduzível que permita a outro avaliador recriar o estado inicial, identificar resultados válidos e detetar ações proibidas. A ficha precisa de uma identidade estável, proprietário, histórico de versões, família de cobertura, tarefa, segmentos, consequência, proveniência, autorização e separação prevista. Deve também fixar as versões do modelo, instruções, corpus de recuperação, ferramentas, política, permissões e mecanismo de avaliação; caso contrário, uma repetição pode estar a testar outra configuração.

• Configuração: papel e objetivo do utilizador, estado do fluxo, pedido, ficheiros, histórico, condições ambientais e instruções fornecidas ao sistema.
• Recursos: conhecimento autorizado, ferramentas, permissões e resultados de ferramentas disponíveis durante a execução.
• Expectativas: factos ou mudanças de estado obrigatórios, alternativas aceitáveis e condições que exigem esclarecimento, abstenção, recusa ou encaminhamento.
• Proibições: saídas, divulgações, chamadas de ferramentas, ações e mudanças de estado que não podem ocorrer.
• Operação: classificador, rubrica, barreiras, solução de referência, número de tentativas quando necessário, regra de agregação, qualificação do revisor e via de adjudicação.

Não transforme uma tarefa aberta numa comparação com uma frase ideal. Uma solução de referência conhecida pode provar que o caso é executável e ajudar a testar o classificador, mas os requisitos materiais devem admitir outras redações e percursos válidos. Para sistemas não determinísticos ou com várias etapas, declare antecipadamente quantas tentativas são necessárias e como serão agregadas. Registe ainda limitações conhecidas e divergências por resolver, para que um caso defeituoso não seja confundido com uma falha do sistema.

Um cenário útil recria trabalho delimitado e torna inspecionáveis o sucesso, a variação aceitável e o comportamento proibido.

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

A classificação deve usar o método mais restrito que consiga distinguir validamente sucesso de falha. Verificações determinísticas servem respostas objetivas, esquemas, cálculos, argumentos de ferramentas, estados de registos e ações vedadas. Factos ou soluções de referência são adequados quando a evidência e o estado final estão delimitados, mas existem vários percursos. Para qualidades abertas, use dimensões separadas, com âncoras observáveis, e calibre qualquer classificador baseado num modelo com julgamentos humanos qualificados no contexto relevante.

• Verifique se cada controlo determinístico cobre realmente o requisito e se uma solução conhecida consegue concluir o caso.
• Avalie o resultado material, sem exigir um percurso incidental quando o fluxo permite alternativas legítimas.
• Conceda crédito parcial apenas a componentes com significado, mostrando sempre qual deles falhou.
• Reserve interpretação especializada para revisores qualificados e mantenha decisões reguladas com pessoas devidamente autorizadas.
• Fixe versões da rubrica, barreiras, segmentos, agregação e regra de decisão antes de comparar sistemas.

Uma divulgação proibida ou ação não autorizada deve falhar uma barreira previamente definida, mesmo quando o texto é claro e recebe pontuações elevadas noutras dimensões. Esta é uma recomendação de desenho, não um limiar universal: os responsáveis de produto e risco devem definir proibições e consequências de lançamento. Também não se deve presumir que um classificador automático é adequado por concordar com exemplos de desenvolvimento; no GDPval, a OpenAI considerou o seu classificador insuficiente para substituir avaliadores profissionais experientes.

Como podem os revisores aplicar os critérios de forma consistente?

Os revisores aplicam melhor os critérios quando recebem o mesmo contexto, âncoras observáveis e uma via explícita para casos impossíveis de classificar. Antes de mostrar uma saída, apresente a finalidade do fluxo, o papel do utilizador, a evidência disponível, o comportamento permitido, os limites do produto e a versão da rubrica. Defina cada nível com exemplos positivos, negativos e fronteiriços e inclua a opção “evidência insuficiente” quando o cenário, ambiente ou material de apoio estiver defeituoso.

1. Execute casos de calibração antes da revisão e repita-os quando mudarem a política, rubrica, composição das tarefas ou equipa de revisores.
2. Oculte a identidade do sistema e alterne a ordem das saídas quando isso for prático numa comparação.
3. Recolha pontuações e justificações independentes antes de permitir discussão entre revisores.
4. Investigue divergências como possível sinal de caso defeituoso, limiar ambíguo, contexto ausente, pluralidade legítima ou decisão de produto pendente.
5. Designe um responsável pela adjudicação e conserve rótulos, justificações, versões e decisões finais.

A divergência não é automaticamente erro humano nem deve ser forçada até surgir consenso. Pode revelar que duas respostas são legitimamente aceitáveis ou que a organização ainda não decidiu a fronteira pretendida. A inspeção das saídas, percursos e classificações ajuda também a separar uma falha genuína do sistema de um problema no caso, no classificador ou no ambiente. Práticas como revisão especializada em várias etapas, comparação cega e rubricas detalhadas são úteis, mas não constituem um protocolo obrigatório para todas as avaliações.

Como manter o conjunto útil durante o desenvolvimento e o lançamento?

O conjunto mantém valor quando separa claramente os casos de desenvolvimento da evidência protegida de lançamento. A equipa pode usar repetidamente o primeiro grupo para melhorar instruções, recuperação, ferramentas, política e fluxo, sabendo que a pontuação reflete otimização contra casos visíveis. A pertença a cada grupo deve ser atribuída no registo antes da execução rotineira ou da inspeção de resultados. O teste protegido deve ser usado com parcimónia e não pode orientar diretamente as alterações que pretende avaliar.

Procure duplicados exatos e aproximados, registos de origem comuns, paráfrases e cenários derivados do mesmo molde. Acompanhe o acesso aos casos, soluções, rubricas e resultados. Uma falha que já orientou diagnóstico ou correção pertence à evidência de desenvolvimento ou regressão. O teste protegido pode cobrir a mesma classe através de um caso independente e não duplicado; se um caso protegido moldar materialmente uma alteração, transfira-o e crie uma substituição versionada.

• Registe proprietário, proveniência, autorização, separação, exposição, versões, última revisão, alteração e motivo de retirada.
• Acrescente falhas verificadas apenas depois de minimizar dados sensíveis, confirmar os factos e validar o resultado esperado.
• Reavalie a cobertura após mudanças materiais no fluxo, utilizadores, política, conhecimento, modelo, instruções, ferramentas, permissões ou ambiente.
• Audite referências desatualizadas, rótulos errados, tarefas ambíguas, estados impossíveis e classificadores que rejeitam alternativas válidas.
• Reporte por tarefa, família de cobertura, segmento, consequência e barreira, além de qualquer resumo global.

Não existe uma contagem, percentagem de separação ou calendário de renovação universal. A composição depende da decisão, variabilidade do fluxo, consequências, fiabilidade da classificação e evidência autorizada disponível. Trate o conjunto como evidência para uma decisão, não como certificado. Uma aprovação offline não demonstra isoladamente valor, segurança, equidade, conformidade ou prontidão. Combine-a com monitorização, investigação com utilizadores, análise de incidentes e revisão por funções qualificadas sempre que estejam envolvidos dados, privacidade, segurança ou decisões reguladas.