Como conceber uma avaliação própria de IA: do caso de uso a um limiar de implementação verificável

Os benchmarks públicos são um sinal inicial, não uma decisão de implementação

Uma tabela de benchmarks responde, na melhor das hipóteses, a uma pergunta delimitada: como um modelo teve desempenho sob um protocolo concreto, com um conjunto de tarefas, uma versão e regras de pontuação determinadas. Não responde, por si só, se um assistente será útil, seguro, suficientemente rápido ou sustentável em termos de custo num processo real. A diferença é importante porque um produto não é composto apenas por um modelo. Inclui instruções, ferramentas, recuperação de documentos, formatos de saída, controlos de acesso, interface, pessoas responsáveis pela supervisão e procedimentos de exceção.

Os benchmarks podem ajudar a reduzir o número de candidatos e a formular hipóteses. Por exemplo, um teste público orientado para programação pode ser relevante quando o trabalho se assemelha à resolução de incidentes de software; um teste de terminal pode trazer informação quando o agente precisa de operar em terminais e ambientes reais; e outro centrado em interfaces pode ser mais próximo quando a tarefa exige utilizar interfaces gráficas. No entanto, a semelhança aparente não elimina a necessidade de testar o fluxo próprio, com as restrições e os dados que o sistema realmente encontrará.

A literatura prática sobre benchmarks de modelos alerta para limitações como a contaminação de dados, diferenças de configuração e resultados que não captam a latência nem a integração de ferramentas. Essas limitações não invalidam os testes públicos: delimitam o tipo de inferência que permitem. A análise recomendável é usar os seus resultados como contexto externo e reservar a decisão de produto para uma avaliação local, repetível e documentada.

Para explorar essa diferença, convém incluir, no cluster editorial, o recurso «O que os benchmarks públicos podem contribuir — e o que não podem». Este guia deve também receber um link da página matriz de aprendizagem, no bloco «Guias para implementar e verificar», e um link de descoberta através do módulo «Antes de escolher um modelo: avalie-o com o seu caso de uso». A publicação deve depender de esses destinos e da respetiva navegação estarem implementados ou planeados no mesmo cluster.

Traduzir o problema numa hipótese avaliável

O ponto de partida não deve ser «que modelo obtém mais pontos», mas sim uma descrição verificável da tarefa. Identifique quem utiliza o sistema, que entrada fornece, que resultado necessita, que ações posteriores dependem desse resultado e o que acontece quando o sistema falha. Uma classificação errada de uma consulta comercial pode exigir correção; uma resposta que atribui falsamente uma afirmação a um documento interno pode induzir uma decisão errada; uma ação externa não autorizada pode ter consequências mais graves. A métrica e o limiar devem refletir essa diferença.

Uma hipótese útil tem uma forma condicional: para um segmento definido de utilizadores e tarefas, o sistema produz um resultado que satisfaz critérios explícitos com um nível de qualidade, tempo e custo compatível com o processo, sem exceder um orçamento de erros. Este enunciado obriga a decidir o que significa «satisfaz». Numa extração estruturada, pode significar campos válidos e corretos. Num resumo, pode exigir cobertura dos pontos relevantes, ausência de invenções e atribuição às fontes disponíveis. Num agente, pode ser concluir uma tarefa sem violar permissões nem exigir mais intervenção humana do que a prevista.

A Microsoft descreve, para a priorização de casos de uso, um enquadramento que combina viabilidade de negócio, experiência e adequação, e viabilidade tecnológica. É um enquadramento de priorização, não um teste da qualidade de um modelo; ainda assim, ajuda a evitar uma omissão frequente: avaliar a capacidade técnica sem confirmar que o caso dispõe de processo, responsável, dados, experiência de utilizador e benefício operacional plausíveis.

Delimitar e versionar o sistema completo

A reprodutibilidade exige declarar o que foi comparado. Registe o fornecedor e a versão ou identificador do modelo quando estiverem disponíveis, a data de execução, os parâmetros de geração, o modelo de instruções, a mensagem de sistema, as ferramentas disponíveis, as suas versões, o esquema de saída, o índice de recuperação, a versão dos documentos e as regras de permissões. Acrescente a lógica de repetições, validação, fallback e escalonamento humano. Se esta configuração não puder ser reconstruída, será difícil interpretar uma diferença de resultados entre duas execuções.

Nem todos os componentes mudam com a mesma frequência. Um fornecedor pode atualizar um serviço, os documentos internos podem mudar todos os dias e uma equipa pode modificar uma instrução para resolver uma falha. O registo não impede essas alterações, mas permite saber o que mudou antes de atribuir uma melhoria ou regressão ao modelo. É especialmente importante não comparar uma alternativa com recuperação atualizada com outra que usa um índice anterior, nem atribuir a uma variante de modelo um resultado produzido por um prompt diferente.

O congelamento não implica imobilizar o produto. Durante uma ronda de avaliação, significa fixar uma configuração candidata e um conjunto de teste antes de observar os resultados. No final, pode ser proposta uma nova versão, mas esta deve ser novamente avaliada contra a mesma referência ou contra uma referência explicitamente atualizada. Esta disciplina reduz o risco de escolher retrospetivamente o prompt que teve sorte no teste.

Construir um conjunto de avaliação representativo e separado

Um conjunto de avaliação deve representar decisões e condições de operação, não apenas exemplos fáceis ou memoráveis. Comece por amostrar tarefas históricas, observando segmentos relevantes: idioma, extensão, tipo de documento, canal de entrada, nível de ambiguidade, casos frequentes e casos de elevado impacto. Depois, acrescente deliberadamente casos difíceis: instruções contraditórias, informação incompleta, documentos desatualizados, entradas malformadas, pedidos fora de âmbito e situações em que o resultado correto é abster-se ou pedir esclarecimentos.

Separe pelo menos duas partições: desenvolvimento e teste. A de desenvolvimento serve para conceber prompts, regras, ferramentas e rubricas. A de teste fica reservada para uma comparação final ou para marcos definidos. A razão metodológica é simples: se o sistema for ajustado repetidamente depois de observar os resultados dos mesmos casos, essas observações deixam de medir generalização e passam a fazer parte do desenvolvimento. Uma terceira partição de validação pode ser útil em projetos com dados suficientes, mas não é um requisito universal; o importante é documentar a utilização de cada caso.

Os dados privados introduzem obrigações práticas adicionais. Minimize os dados pessoais e os segredos incluídos na avaliação, aplique controlos de acesso e evite transportar conteúdo sensível para ambientes não autorizados. Este guia não determina, por si só, a licitude de um tratamento nem os requisitos contratuais dos fornecedores. Antes de incorporar documentos privados, convém utilizar o recurso previsto «Exemplo de matriz de avaliação para documentos sensíveis» e validar as condições aplicáveis com as funções jurídica, de segurança e de proteção de dados.

Os casos sintéticos podem ampliar a cobertura quando faltam exemplos, mas não substituem automaticamente a realidade operacional. Devem ser identificados como sintéticos, revistos e mantidos separados nos relatórios. Se apenas os casos criados para a demonstração funcionarem, a avaliação não fornece evidência suficiente sobre o comportamento em produção.

Escolher métricas que correspondam à tarefa e ao risco

Não existe uma métrica única para sistemas generativos. A correspondência literal pode ser adequada quando a saída é uma etiqueta fechada ou um valor exato, mas costuma ser insuficiente para resumos, respostas abertas ou planos de ação. Nesses casos, uma rubrica humana pode avaliar aspetos separados: correção factual, cobertura, clareza, cumprimento de instruções, utilização adequada de fontes e reconhecimento da incerteza. A avaliação automatizada pode complementar esse trabalho com validadores de esquema, regras de negócio, verificação de campos obrigatórios e testes de segurança; não deve ocultar as propriedades que não consegue verificar.

Para recuperação aumentada com fontes, meça separadamente a recuperação e a geração. Entre outros sinais, pode verificar se foi recuperada evidência pertinente, se as afirmações importantes são sustentadas pela evidência disponível, se as citações ou referências correspondem ao conteúdo e se o sistema se abstém quando a evidência não é suficiente. Uma resposta fluente não demonstra fidelidade. O recurso previsto «Como avaliar fidelidade, cobertura e citações em sistemas RAG» pode aprofundar estes critérios.

Em saídas estruturadas, meça a validade do esquema, a presença de campos, a exatidão semântica de cada campo e a recuperação após um erro. Um JSON formalmente válido pode continuar a classificar incorretamente; uma classificação correta pode ser inutilizável se faltar um campo obrigatório. Para conceber esses testes, está previsto o recurso «Como medir validade de esquema e recuperação perante erros».

Acrescente métricas operacionais: latência por percentis e por segmento, custo por tarefa concluída, frequência de repetições, taxa de fallback, intervenção humana e sucesso de ponta a ponta. Apresente distribuições além de médias sempre que possível, porque uma média pode ocultar caudas de latência ou segmentos com resultados sistematicamente piores. Os limiares não decorrem de um número universal: dependem do processo, do volume, do dano e da capacidade de supervisão.

Conceber a rubrica e controlar o desacordo humano

Uma rubrica transforma juízos gerais em decisões observáveis. Em vez de perguntar «a resposta é boa?», defina dimensões, escalas e exemplos. Para o assistente de feedback, uma dimensão de fidelidade poderia distinguir entre: todas as afirmações relevantes são sustentadas pelo texto; pequenas inferências aceitáveis são assinaladas; existem afirmações não sustentadas; e há atribuições claramente falsas. Outra dimensão pode avaliar se a categoria e a prioridade seguem as definições operacionais da equipa.

Alguns controlos podem ser automatizados de forma determinística: análise de um esquema, limites de comprimento, campos proibidos, correspondência com uma lista de permissões ou presença de referências obrigatórias. Outros exigem interpretação. Um avaliador baseado noutro modelo pode acelerar a triagem, mas deve ser calibrado face a anotações humanas numa amostra representativa, e os seus erros devem ser analisados. Não é aconselhável tratá-lo como árbitro independente nem utilizá-lo para substituir a revisão humana em situações de consequências elevadas.

Para medir o acordo, dois avaliadores podem ser comparados através da percentagem de coincidência em critérios simples ou por uma medida de acordo que tenha em conta a coincidência esperada pelo acaso, como o kappa, desde que a escala e a distribuição o permitam. Não existe um nível universal de desacordo que invalide uma avaliação. Como regra operacional, reveja a rubrica se o desacordo afetar casos que decidiriam a implementação, se se concentrar numa dimensão crítica ou se os avaliadores interpretarem o critério de forma incompatível. Documente a revisão e, se alterar as regras, reavalie os casos afetados.

Comparar de forma justa e decidir com limiares explícitos

Defina os limiares antes de executar a comparação final. Estabeleça bloqueadores absolutos, mínimos por segmento e objetivos operacionais. Um bloqueador pode ser uma saída que revele informação não autorizada, uma ação executada sem a confirmação exigida, uma violação de uma permissão ou uma afirmação crítica sem suporte num contexto em que o sistema é apresentado como baseado em fontes. Um mínimo por segmento evita que um resultado agregado aceitável esconda um comportamento inaceitável para um idioma, um tipo de documento ou um grupo de utilizadores.

Uma decisão pode ter três resultados: implementar com controlos, iterar ou descartar. Implementar com controlos só é adequado se os bloqueadores forem zero dentro da cobertura avaliada, se os mínimos acordados forem cumpridos e se existir supervisão compatível com o risco residual. Iterar exige identificar o que irá mudar e como será medido novamente. Descartar pode ser a conclusão responsável se não existir uma configuração que atinja o limiar dentro dos limites de custo, latência ou segurança.

Em agentes que executam ações externas, a avaliação deve testar explicitamente permissões, confirmações, âmbito e reversibilidade. Não basta que a tarefa termine com sucesso. O recurso previsto «Testes de permissões, confirmações e reversibilidade antes de dar ações ao agente» deve abranger este tipo de validação. O guia não define requisitos regulatórios concretos do AI Act europeu: as fontes verificadas fornecidas não constituem texto normativo primário suficiente para determinar artigos, datas ou obrigações aplicáveis. Essa revisão deve ser feita com fontes jurídicas em vigor e aconselhamento especializado.

Monitorizar após a implementação e conservar o registo de decisão

A implementação não transforma a avaliação num procedimento encerrado. Mudam as entradas dos utilizadores, os documentos recuperados, os modelos dos fornecedores, as ferramentas e os padrões de abuso. Instrumente rastos com a minimização de dados adequada para associar uma saída à sua configuração, recuperação, ferramentas, tempo de resposta, custo, validações, fallback e intervenção humana. O recurso previsto «Como instrumentar rastos, latência e custo por tarefa» pode servir como continuação operacional.

Defina sinais de alerta: aumento de erros de esquema, queda do sucesso por segmento, crescimento de abstenções ou repetições, atrasos em percentis elevados, aumento do custo por tarefa, reclamações revistas e eventos de permissões. Faça amostragens de resultados de produção para avaliação humana, com procedimentos que respeitem os controlos de dados aplicáveis. Programe reavaliações após alterações relevantes e também de forma periódica, mesmo que não seja declarada qualquer alteração, porque uma dependência externa pode variar.

O modelo final deve reunir uma ficha de avaliação, a matriz de resultados e um registo de decisão. A ficha inclui objetivo, segmentos, riscos, configuração versionada, proveniência dos dados e métricas. A matriz apresenta resultados agregados e por segmento, juntamente com casos críticos. O registo explica que evidência foi revista, que limiares foram aplicados, que limitações permanecem, quem aprovou a decisão e quando o teste deve ser repetido. Como navegação de encerramento, adicione «Próximo passo» para um modelo descarregável ou um artigo complementar sobre observabilidade. Este encerramento não deve ser publicado como link ativo se o destino não existir ou não estiver planeado dentro do cluster.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.