Avaliações: das experiências com IA à produção com confiança

• Embora os modelos de base tenham melhorado, a verdadeira mudança que permite a sua utilização segura em produção resulta de práticas de avaliação rigorosas.

• Avaliações bem concebidas ajudam gestores de produto, responsáveis pela governação da IA e diretores de tecnologia a implementar agentes de IA em escala e com segurança, transformando a IA de uma ferramenta isolada numa vantagem competitiva.

• Essa confiança resulta da avaliação do comportamento dos agentes de IA face a consultas reais dos utilizadores, casos-limite e cenários específicos do domínio que reflitam o contexto efetivo da empresa, e não de um benchmark público que afirme «este modelo é o melhor».

• O objetivo é justificar essa confiança através de resultados mensuráveis. Ter sucesso significa definir o que é "bom" em termos concretos e mensuráveis, alinhados com as necessidades da empresa e a tolerância ao risco — seja exatidão factual, tom adequado, rapidez ou eficiência de custos.

• Ao integrar a avaliação em todo o sistema (instrumentação, registos, testes A/B e mecanismos de proteção) e equilibrar rigor e eficiência, as equipas conseguem implementar mais depressa e com maior robustez.

A maioria das empresas aceita que os seus colaboradores experimentem o ChatGPT ou o Gemini. Contudo, é menos comum colocar LLM em funcionamento em fluxos de trabalho ou contextos de alto risco.

As razões têm sido muitas vezes válidas: a qualidade era inconsistente e o risco de alucinações ou comportamentos indesejáveis superava os potenciais benefícios da tecnologia.

Este equilíbrio entre risco e benefício mudou significativamente no último ano. Embora parte dessa mudança se deva à melhoria do desempenho dos modelos de base, muito resulta da crescente disciplina em torno da avaliação (ou «evals»). As avaliações dão-nos, a nós e aos nossos clientes, a confiança necessária para implementar agentes em grande escala e orientados para clientes em poucas semanas.

Este guia explica os elementos fundamentais das avaliações e como as conceber, implementar e operar em casos de utilização em produção.

O objetivo da avaliação não é encontrar um modelo perfeito, mas gerar confiança fundamentada de que o modelo se comporta de forma alinhada com as necessidades da empresa, as expectativas dos utilizadores e a tolerância ao risco da organização.

Na base de qualquer estratégia de avaliação está uma pergunta simples: O que significa ser «bom»? A resposta deve ser específica. Para uma organização, «bom» pode significar exatidão factual dentro de tolerâncias rigorosas; para outra, pode dar prioridade à rapidez, à eficiência de custos ou a um tom de voz distinto. Todas as restrições aplicáveis, desde os dados que podem ser utilizados às obrigações regulamentares, moldam esta definição.

Acima de tudo, o que é 'bom' tem de incluir componentes que possam ser efetivamente medidos. Se o sucesso significa prestar orientação financeira útil, essa utilidade deve ser expressa através de atributos: correção factual, avisos adequados, raciocínio personalizado e limites seguros. Depois de definir o que é «bom» em termos mensuráveis, a pergunta seguinte é como analisar e interpretar os resultados. É a atuação com base nestes resultados que transforma a avaliação num método, em vez de numa simples emissão de juízos.

Cada pipeline de avaliação assenta em três pilares interligados:

1. Inputs/benchmarks: exemplos representativos do mundo real para avaliar o desempenho geral e conjuntos de dados internos criteriosamente selecionados para testar a viabilidade no domínio.

2. Comportamento do modelo: como o modelo é chamado (geração aumentada por recuperação, resumo, recuperação de informação estruturada e utilização de ferramentas).

3. Métricas: como medir e interpretar o desempenho.

Os inputs têm de representar o mundo que o sistema encontrará. As conclusões mais relevantes provêm de exemplos reais: consultas dos clientes, cenários financeiros ou casos específicos do setor. Só ao testar estes exemplos poderá perceber se o modelo compreende realmente as nuances exigidas pelos utilizadores e satisfaz as necessidades da empresa.

O comportamento do modelo — como recebe os prompts, como se orquestram a recuperação ou a utilização de ferramentas e como se fornece o contexto — é tão importante como o próprio modelo. Dois modelos idênticos podem comportar-se de forma muito diferente consoante a implementação. Por isso, esta camada deve ser incluída na conceção da avaliação.

Por fim, temos as métricas. Os números, por si só, raramente contam toda a história, mas métricas bem escolhidas tornam o comportamento do sistema interpretável. Latência, exatidão, segurança, coerência, enviesamento, custos e satisfação dos utilizadores formam, em conjunto, uma imagem multidimensional de um sistema em produção. A arte está em escolher métricas alinhadas com os KPI do projeto ou da empresa e que revelem as qualidades mais importantes para os utilizadores. As métricas mais simples são muitas vezes mais exatas e menos dispendiosas, enquanto escolhas inadequadas podem induzir as equipas em erro. Eis como pensar na seleção de métricas:

Exemplos de boas escolhas de métricas:

• Chatbot de apoio ao cliente: taxa de resolução no primeiro contacto (o problema do utilizador foi resolvido sem encaminhamento?), tempo médio de tratamento, índice de satisfação dos utilizadores e taxa de encaminhamento para agentes humanos.

• Ferramenta de investigação financeira: exatidão das citações (% de afirmações com fontes adequadas), precisão factual validada face a dados de referência, relevância da recuperação (encontrou os documentos certos?) e coerência do raciocínio avaliada por especialistas do domínio.

• Assistente de geração de código: correção da sintaxe, taxa de aprovação nos testes, número de vulnerabilidades de segurança e tempo até obter uma solução funcional.

Exemplos de más escolhas de métricas:

• Utilizar apenas o comprimento da resposta como indicador de qualidade (mais longa ≠ melhor).

• Medir a rapidez sem considerar os compromissos ao nível da exatidão.

• Acompanhar as pontuações de confiança do modelo sem as validar face à correção efetiva.

• Depender exclusivamente da perplexidade interna do modelo sem validação junto dos utilizadores.

Erros comuns nas métricas a evitar:

• Métricas contraditórias: otimizar simultaneamente a rapidez e a abrangência sem reconhecer o compromisso entre ambas.

• Sobreajuste aos benchmarks: alcançar 95% no conjunto de testes, mas falhar em produção porque os utilizadores reais se comportam de forma diferente.

Para um cliente de serviços financeiros altamente regulamentado, a exatidão da sua solução de pesquisa aprofundada era essencial. Criámos conjuntos de dados de perguntas e respostas elaborados por especialistas e outros gerados por ferramentas, o que nos permitiu avaliar a precisão, a capacidade do sistema para selecionar as ferramentas certas e recuperar a informação correta, obtendo uma visão equilibrada da exatidão e da qualidade do raciocínio. A chave foi medir várias dimensões: exatidão factual (validação por especialistas), qualidade da recuperação (precisão/revocação dos documentos relevantes) e coerência do raciocínio (avaliação estruturada do fluxo lógico).

Quando utilizar um LLM como juiz para avaliar qualidades subtis

A abordagem LLM como juiz utiliza um segundo modelo de IA como avaliador, substituindo a revisão humana por uma classificação de qualidade automatizada e escalável. A abordagem LLM como juiz é muitas vezes usada indevidamente quando métricas mais simples proporcionariam a exatidão necessária. Pode ser útil quando verificações determinísticas não conseguem captar a qualidade, por exemplo, se a métrica for semântica (utilidade, fundamentação, qualidade do raciocínio, tom ou interpretação de políticas) e não for possível uma classificação determinística. Poderá ser necessário obter feedback escalável para muitas variantes de prompt/modelo e definir uma grelha clara e um schema de output estruturado. Para que esta abordagem funcione, siga estes passos:

• Defina explicitamente as dimensões da grelha: correção, fundamentação, conformidade com políticas, aplicabilidade e tom.

• Utilize outputs estruturados (schema JSON) nas respostas do juiz.

• Registe pontuações binárias de aprovação e texto de diagnóstico para analisar falhas.

• Em cada ciclo de lançamento, calibre os outputs do juiz face a amostras classificadas por humanos.

• Utilize dois juízes ou verificações periódicas de consenso em domínios de alto risco.

• Acompanhe ao longo do tempo o desvio do juiz e a taxa de discordância.

Um conjunto de dados de benchmark é um conjunto fixo e criteriosamente selecionado de exemplos de teste com respostas conhecidas, utilizado para avaliar modelos de forma consistente e comparar resultados de modo justo entre versões. Normalmente, inclui inputs (por exemplo, consultas de utilizadores), outputs esperados ou juízos de referência e critérios/rótulos de avaliação para a classificação. Os testes de benchmarks públicos são utilizados para comparar o desempenho dos modelos mais avançados e podem servir de referência inicial, ao conceber o sistema, para identificar um modelo que seja um bom candidato.

Contudo, no seu próprio sistema, não pode utilizar estes benchmarks como indicador do desempenho no contexto da empresa, pois apresentam problemas conhecidos:

• Contaminação: os modelos podem ter sido treinados com dados do benchmark; avaliá-los com o mesmo conjunto de dados pode equivaler a fazer um teste com as respostas à frente.

• Saturação: todos os melhores modelos já atingem pontuações máximas, pelo que as melhorias ou degradações se limitam a poucos pontos percentuais e ficam muitas vezes dentro da variabilidade natural dos resultados dos testes.

• Âmbito limitado: os dados do benchmark não refletem as tarefas reais, pois são altamente selecionados e limpos. Alguns são até gerados por LLM e não refletem a complexidade nem os casos-limite dos seus dados (erros ortográficos, construções invulgares ou imagens com ruído).

Um aluno pede à aplicação ajuda para resolver problemas matemáticos enunciados por palavras.

Exemplo de um benchmark público que pode utilizar: GSM8K (raciocínio matemático do ensino básico).

• Conjunto opcional mais difícil: MATH.

Por que motivo este benchmark é útil:

• Permite comparar rapidamente qual dos modelos é melhor no raciocínio matemático geral.

• É um bom primeiro filtro antes de investir em avaliações completas do produto.

Por que continua a precisar do seu próprio conjunto de dados:

A sua aplicação tem requisitos que o GSM8K não testa:

• A terminologia e a ordem dos temas do seu currículo.

• O estilo de explicação adequado à faixa etária.

• Como lidar com perguntas ambíguas ou repletas de erros ortográficos.

• Regras de política (por exemplo, quando dar pistas ou respostas completas).

Uma validação eficaz depende da criação de benchmarks de avaliação específicos da aplicação. Estes conjuntos de dados devem resultar de interações reais, casos-limite típicos e modos de falha plausíveis. Esta tarefa pode ser difícil ao implementar um novo produto ou processo. No entanto, na maioria dos casos, é possível recolher dados de um produto existente ou fazê-lo o mais cedo possível, mesmo durante uma fase inicial de testes. Após desenvolver a aplicação, estes benchmarks devem acompanhar a evolução do produto, tornando-se mais ricos e representativos ao longo do tempo.

A ligação entre o benchmark específico da aplicação e a seleção do modelo é crucial. O benchmark revela não só se uma solução funciona, mas também qual é a combinação de dimensão do modelo e técnicas de pós-treino que proporciona o desempenho necessário ao menor custo. As melhorias mais poderosas nos modelos pré-treinados (o «PT» em ChatGPT) não resultam de novo treino, mas de métodos de "pós-treino".

Estes métodos centram-se em moldar a informação a que o modelo pode aceder, a forma como essa informação é estruturada e como o modelo é orientado e orquestrado durante a inferência. Técnicas de pós-treino como:

• Prompts de cadeia de pensamento e alocação dinâmica de recursos computacionais (pensar mais em problemas difíceis).

• Autoconsistência, em que se geram vários outputs e se seleciona o melhor.

• Construção e orquestração de contexto, como a geração aumentada por recuperação (RAG), exemplos few-shot e fluxos de trabalho com agentes.

• Utilização de ferramentas e acesso a conhecimento externo, permitindo ao modelo atuar para além dos seus parâmetros internos.

• Estratégias de representação e armazenamento de conhecimento, concebidas para a recuperação e o raciocínio eficientes sobre dados estruturados e não estruturados.

Embora estas técnicas de pós-treino possam melhorar significativamente o desempenho do sistema, também implicam compromissos. Cada camada adicional de orquestração, recuperação ou raciocínio aumenta a complexidade do sistema, o tempo de inferência e os custos operacionais. Contudo, quando aplicadas de forma ponderada, as técnicas de pós-treino certas permitem muitas vezes utilizar modelos mais pequenos, rápidos e económicos sem comprometer os requisitos de desempenho. Em vez de aumentar a dimensão do modelo, alcança-se o desempenho através de uma melhor conceção do sistema.

Encontrar este equilíbrio depende da aplicação e deve basear-se nas respetivas avaliações específicas para determinar a combinação ideal de técnicas. Estas avaliações permitem identificar o ponto em que mais orquestração deixa de produzir ganhos significativos, para que as equipas escolham o nível mínimo de complexidade de pós-treino necessário ao desempenho pretendido.

Uma solução de IA deve ser encarada como um sistema completo: bases de dados, API, interfaces de utilizador, camadas de orquestração, infraestrutura de monitorização e muito mais. Por conseguinte, a avaliação deve abranger toda a pilha tecnológica. Deve monitorizar as principais partes do sistema para manter a visibilidade sobre potenciais problemas e acelerar de forma responsável.

Monitorizar as principais partes do sistema implica:

• Instrumentar os pipelines para obter resultados mensuráveis.

• Registar as experiências para observar o efeito de cada ajuste.

• Utilizar comparações A/B simples antes de implementar alterações importantes, para detetar potenciais regressões.

A iteração orientada por dados encurta o percurso do protótipo à produção, sem pontos cegos. Os registos e a monitorização também são importantes para compreender a utilização da aplicação no mundo real. Eis um exemplo para garantir a observabilidade:

• Passo 1: o pedido do utilizador entra com request_id, user_segment e intent.

• Passo 2: o rastreio regista a versão do modelo, a versão do prompt, os documentos recuperados e as chamadas de ferramentas.

• Passo 3: o juiz LLM classifica a resposta (correção, fundamentação, policy_risk).

• Passo 4: o motor de regras avalia os limiares.

• Passo 5: se um limiar for violado, é emitido um alerta e o pedido é encaminhado para uma alternativa/revisão humana.

• Passo 6: a falha é adicionada à fila de triagem e, depois, à lista de pendentes do benchmark.

Os utilizadores reais raramente se comportam exatamente como os designers esperam. Alguns interpretarão mal as instruções. Outros testarão deliberadamente os pontos fracos. Estes casos-limite não são anomalias, mas sinais extremamente valiosos. Um pipeline de avaliação bem implementado capta-os, analisa-os e incorpora-os em testes futuros. Só é possível iterar rapidamente sem pontos cegos quando a avaliação está integrada no sistema, em vez de ser acrescentada depois do desenvolvimento.

Recomendamos integrar mecanismos de proteção e monitorização desde o primeiro dia:

• Acompanhe regularmente as métricas e regressões do modelo através do benchmark específico da aplicação.

• Registe e analise casos-limite ou inputs adversariais (e adicione-os ao conjunto de dados do benchmark específico da aplicação).

• Garanta que estas métricas de avaliação estão alinhadas com os seus KPI principais.

• Questione regularmente o conjunto de dados e o benchmark para garantir que não ignora novos riscos nem fica sujeito a enviesamentos.

• Implemente alertas automáticos para a degradação das métricas (por exemplo, se a exatidão descer abaixo de 85%, acione uma revisão).

• Mantenha um processo de revisão humana para decisões de alto risco (aconselhamento jurídico, orientação médica e transações financeiras).

Cada execução do benchmark consome recursos computacionais e energia. Cada experiência redundante aumenta os custos. Uma avaliação responsável deve equilibrar rigor e eficiência.

Há medidas práticas que permitem evitar uma escalada do consumo de energia e dos custos:

• Utilize modelos mais pequenos sempre que possível: execute as experiências iniciais em modelos mais económicos e aumente a escala apenas depois de validar a abordagem.

• Coloque prompts e chamadas de API em cache.

• Utilize agendamento atento ao consumo energético (processamento em lote, instâncias spot e prioridade flexível).

• Acompanhe a utilização de recursos computacionais em conjunto com o desempenho.

Mantenha-se igualmente atento à nova regulamentação sobre IA. Mesmo quando não existe legislação específica, continuam a aplicar-se os quadros existentes e as medidas necessárias, tais como:

Proteção de dados:

• Garanta que os conjuntos de dados dos benchmarks não contêm dados pessoais identificáveis sem o devido consentimento.

• Implemente políticas de retenção de dados para as consultas registadas.

• Disponibilize mecanismos para pedidos de eliminação de dados.

Igualdade e enviesamento:

• Teste o desempenho em diferentes grupos demográficos.

• Inclua uma representação diversificada na criação do benchmark.

Direitos humanos e transparência:

• Documente claramente para os utilizadores as limitações do modelo.

• Apresente explicações para decisões de alto risco.

• Permita a supervisão humana em aplicações críticas.

A avaliação não é um evento pontual, mas um sistema em evolução. Num setor em rápida mudança, a vantagem está na rapidez com que consegue testar, aprender e adaptar-se, para implementar modelos e novas soluções com maior eficácia.

Ao integrar a avaliação como atividade central da engenharia e da gestão de produto, as equipas podem inovar mais depressa e com maior segurança. Comece por definir o que é «bom» no contexto da sua aplicação de IA, crie uma plataforma de avaliação e faça-a evoluir até dispor de um benchmark específico da aplicação que, a cada iteração, lhe dê confiança na prontidão para produção.