O formulário foi enviado com sucesso.
Encontrará mais informações na sua caixa de correio.
Contrate-nosSelecionar a língua
Sobre nósServiçosTecnologiasIndústriasCarteira
A sua aplicação LLM pode produzir milhares de respostas por hora. Com esse volume, a revisão manual deixa de funcionar como principal controlo de qualidade. Métricas como o BLEU e o ROUGE medem a semelhança superficial do texto, mas não conseguem indicar se uma resposta utiliza os factos corretos ou se se enquadra no produto. E, à medida que o sistema cresce, os pontos cegos crescem com ele.
O método de avaliação «LLM como juiz» resolve esta lacuna ao permitir que um modelo de linguagem avalie outro com base em critérios definidos pelo utilizador. As equipas obtêm um sinal sobre o qual podem agir em grandes conjuntos de resultados, sem ter de recorrer a um revisor humano para cada prompt. A abordagem funciona, mas apenas com a configuração correta. Uma rubrica fraca, um prompt tendencioso ou um modelo que se autoavalia podem fazer com que as pontuações pareçam úteis, enquanto os mesmos problemas de qualidade permanecem ocultos.
Aqui, vou abordar o que é um LLM a desempenhar funções de juiz, como funciona, o que torna os seus resultados úteis ou enganadores e em que situações o método tende a falhar. Analisaremos também a configuração necessária para que as equipas possam confiar nesses resultados num produto de IA real.
Se já estiver familiarizado com o Explicação sobre o LLM na função de juiz, pode dar uma vista de olhos nesta secção. Caso contrário, eis uma breve Definição de «LLM como juiz». O «LLM-as-a-judge» é um método de avaliação em que um modelo de linguagem analisa o resultado de outro modelo com base numa grelha de avaliação definida pela equipa. Esta abordagem também se pode aplicar aos resultados de um sistema de IA mais abrangente ou de um agente.
O avaliador normalmente consulta o pedido do utilizador, a resposta do modelo e a rubrica que explica o que deve ser avaliado. Dependendo da tarefa, pode analisar o resultado de várias formas:
É a rubrica que torna a avaliação útil. Sem ela, o avaliador tem de adivinhar o que conta como bom. Com uma rubrica, a equipa pode orientar o modelo para os indicadores de qualidade que são relevantes para o seu fluxo de trabalho.
Alguns critérios comuns são a precisão, a relevância, a fundamentação, a segurança, a clareza e a utilidade. Num sistema RAG, o avaliador pode verificar se a resposta é corroborada pela fonte recuperada. No apoio ao cliente, pode verificar se a resposta segue as diretrizes e se responde efetivamente à pergunta do cliente. Nos fluxos de trabalho de conteúdo, pode analisar o tom, a clareza e se o rascunho se adequa ao canal.
Por que razão as empresas utilizam o LMétodo de avaliação «LM como juiz»? Os sistemas de IA evoluem mais rapidamente do que a revisão manual consegue acompanhar. No início, basta rever os resultados manualmente. Verifica-se algumas respostas, dá-se feedback e corrige-se os erros evidentes. Mas, à medida que o sistema começa a processar centenas de perguntas sobre diversos temas, a revisão manual já não consegue acompanhar o ritmo.
A revisão humana continua a ser a melhor forma de detetar nuances, avaliar riscos empresariais e lidar com casos invulgares. O desafio reside na cobertura. Os revisores podem ajustar uma grelha de avaliação, verificar resultados sensíveis e investigar falhas, mas não conseguem rever todas as respostas após cada atualização.
As métricas tradicionais, como o BLEU, o ROUGE e as verificações de correspondência exata, também ajudam, mas apenas no caso de verificações rigorosas, tais como respostas exatas, esquemas, formatos e rótulos conhecidos. Estas métricas não têm em conta aspetos como o significado, a fundamentação, a adequação às políticas e a qualidade global da tarefa.
Os avaliadores do LLM podem analisar grandes conjuntos de testes e avaliar aspetos que as métricas fixas não detectam, incluindo relevância, fundamentação, tom, segurança e cumprimento de instruções. As equipas utilizam-nos para testes de regressão, verificações de lançamento, comparações de modelos e monitorização da qualidade após o lançamento.
A maioria das empresas não se baseia apenas num único método. Uma boa configuração combina verificações determinísticas para regras rigorosas, avaliações por modelos de linguagem de grande escala (LLM) para avaliações de natureza aberta e intervenção humana para a calibração e decisões de alto risco.
| Método | Melhor para | Limites | Função na produção |
| Revisão humana | Resultados de alto risco, nuances empresariais, casos extremos e decisões em que o contexto é mais importante do que uma pontuação | Demasiado lento para repetir após cada edição de prompt, atualização do modelo, alteração na recuperação ou atualização da política | Calibra as rubricas, analisa casos contestados, investiga falhas e aprova fluxos de trabalho de grande impacto |
| Métricas tradicionais e verificações fixas | Testes com respostas pré-definidas, validação de esquemas, campos obrigatórios, regras de formatação, rótulos de correspondência exata e verificações rigorosas de aprovação/reprovação | Falta de significado, apoio à fonte, adequação à política, tom e respostas que podem estar corretas de mais do que uma forma | Funcionam como restrições rígidas para verificações que têm de ser cumpridas sempre |
| Juízes do LLM | Respostas de formato livre, verificações de qualidade RAG, comparação de modelos, cumprimento de instruções, tom, segurança e relevância | Pode premiar a prolixidade, seguir critérios de avaliação pouco rigorosos ou não identificar riscos quando as instruções do júri são vagas | Fornecer às equipas uma indicação rápida da qualidade em conjuntos de testes de grande dimensão e encaminhar os resultados menos satisfatórios para revisão humana |
Agora, vamos ver Como funciona o LLM no papel de juiz num processo de avaliação de produtos. À primeira vista, o procedimento parece simples. Um modelo redige uma resposta e outro verifica-a utilizando uma grelha de avaliação. O avaliador analisa a tarefa, a resposta e a grelha de avaliação e, em seguida, apresenta um resultado estruturado que a equipa pode utilizar.
Eis um exemplo básico Diagrama do fluxo de avaliação do LLM na função de juiz:
Para facilitar a compreensão, imagine uma empresa a testar um assistente de IA para o apoio ao cliente. Na prática, o processo funciona da seguinte forma:
O sistema recebe o pedido original. No nosso exemplo, um cliente quer saber por que razão a sua última fatura é mais elevada após ter mudado de plano. Noutros produtos, a tarefa pode consistir num aviso padrão, numa consulta RAG ou numa instrução para um agente de IA.
A IA principal gera três respostas possíveis à pergunta do cliente. Uma resposta é curta e direta. Outra explica a lógica de faturação com mais pormenor. A terceira utiliza um tom mais cordial e coloquial.
O sistema combina a pergunta do cliente, as três opções de resposta e uma grelha de avaliação rigorosa. Uma vez que este assistente utiliza o RAG, inclui também a política de faturação, para que o juiz possa verificar os factos.
O juiz analisa cada resposta com base nos critérios de avaliação. Verifica se a resposta explica corretamente a fatura, utiliza a fonte adequada, evita suposições e está em consonância com o tom da marca. Em seguida, o juiz apresenta um resultado estruturado, frequentemente em JSON, com uma pontuação e uma breve explicação para essa pontuação.
O sistema seleciona a resposta com a pontuação mais elevada para enviar ao cliente. Além disso, guarda as pontuações do avaliador, o raciocínio, a versão da solicitação e o contexto de origem numa base de dados. Este registo permite à equipa acompanhar como a qualidade das respostas evolui à medida que atualizam o sistema.
As respostas com pontuação baixa, os empates e os casos de alto risco são encaminhados para revisores humanos. Um revisor pode perceber que uma resposta é educada, mas não explica a verdadeira razão para a alteração do preço. O feedback humano ajuda a melhorar a rubrica e a corrigir quaisquer pontos cegos que o avaliador tenha deixado escapar.
O sistema recebe o pedido original. No nosso exemplo, um cliente quer saber por que razão a sua última fatura é mais elevada após ter mudado de plano. Noutros produtos, a tarefa pode consistir num aviso padrão, numa consulta RAG ou numa instrução para um agente de IA.
A IA principal gera três respostas possíveis à pergunta do cliente. Uma resposta é curta e direta. Outra explica a lógica de faturação com mais pormenor. A terceira utiliza um tom mais cordial e coloquial.
O sistema combina a pergunta do cliente, as três opções de resposta e uma grelha de avaliação rigorosa. Uma vez que este assistente utiliza o RAG, inclui também a política de faturação, para que o juiz possa verificar os factos.
O juiz analisa cada resposta com base nos critérios de avaliação. Verifica se a resposta explica corretamente a fatura, utiliza a fonte adequada, evita suposições e está em consonância com o tom da marca. Em seguida, o juiz apresenta um resultado estruturado, frequentemente em JSON, com uma pontuação e uma breve explicação para essa pontuação.
O sistema seleciona a resposta com a pontuação mais elevada para enviar ao cliente. Além disso, guarda as pontuações do avaliador, o raciocínio, a versão da solicitação e o contexto de origem numa base de dados. Este registo permite à equipa acompanhar como a qualidade das respostas evolui à medida que atualizam o sistema.
As respostas com pontuação baixa, os empates e os casos de alto risco são encaminhados para revisores humanos. Um revisor pode perceber que uma resposta é educada, mas não explica a verdadeira razão para a alteração do preço. O feedback humano ajuda a melhorar a rubrica e a corrigir quaisquer pontos cegos que o avaliador tenha deixado escapar.
É comum as pessoas reverem o seu próprio trabalho. Relemos o que escrevemos, identificamos pontos fracos e fazemos melhorias. Então, por que razão seria um modelo diferente?
Pode parecer razoável que um modelo reveja o seu próprio texto e o avalie. Mas, na realidade, quando um modelo verifica o seu próprio texto, pode confundir uma formulação fluida com verdadeira qualidade. Chama-se «viés de auto-valorização». O modelo pode ignorar falhas de lógica, frases repetidas ou finais enfadonhos, porque estes se enquadram nos mesmos padrões que utilizou para escrever a resposta. Como resultado, o seu próprio resultado pode parecer melhor do que realmente é.
Por exemplo, Sergei Molchanov, diretor da unidade de negócios da Innowise, deparou-se com este problema enquanto desenvolvia um motor de conteúdo automatizado para publicações no X. Todas as manhãs, o sistema enviava-lhe três variantes de publicação no Telegram. Ele escolhia uma, por vezes editava-a e publicava-a manualmente. A questão era simples: qual das versões preliminares era, de facto, a mais eficaz?
No início, o Sergei pediu ao modelo gerador que classificasse os seus próprios rascunhos utilizando uma rubrica. Mas isso não lhe proporcionou uma indicação útil. As pontuações mantiveram-se próximas umas das outras, na faixa dos 36 aos 40. Um rascunho claramente mais fraco obteve uma pontuação apenas ligeiramente inferior à do favorito, pelo que a avaliação fez com que a escolha parecesse mais fácil do que realmente era.
O resultado mudou quando o Sergei separou as funções. Um modelo redigia as publicações, enquanto um modelo avaliador distinto lhes atribuía pontuações utilizando uma rubrica de 9 critérios. Depois disso, rascunhos semelhantes começaram a receber pontuações mais variadas, como 26, 32 e 39. O avaliador distinto detetou problemas que o gerador tinha disfarçado: palavras evasivas como talvez e provavelmente, metáforas repetidas de publicações anteriores e frases de encerramento vazias, tais como o tempo dirá.
Diferentes tarefas de avaliação requerem configurações diferentes. Algumas equipas verificam as respostas em relação a uma referência conhecida, enquanto outras avaliam respostas em que mais do que uma versão pode estar correta. É por isso que os fluxos de trabalho de produção utilizam frequentemente várias tTipos de LLM na função de juiz sistemas.
Os juízes comparadores comparam o resultado de uma IA com uma resposta de referência verificada, também conhecida como «verdade de referência». Verificam se a resposta corresponde aos factos, segue a lógica correta ou produz o resultado esperado.
Esta abordagem funciona melhor quando existe uma resposta clara. Por exemplo, um bot de apoio ao cliente pode ter de indicar a regra exata da garantia, ou um assistente de programação pode ter de utilizar um algoritmo específico. Os testes de benchmark também têm, muitas vezes, apenas um resultado correto a verificar.
A desvantagem é que os juízes comparativos não são muito flexíveis. Podem ser demasiado rigorosos em tarefas em que há mais do que uma resposta correta, especialmente quando a formulação, o tom ou o contexto são importantes.
Muitas tarefas de IA não têm apenas uma resposta correta. Por exemplo, uma resposta a um cliente, um resumo ou uma publicação gerada podem ser todos válidos, cada um à sua maneira. Neste caso, o avaliador utiliza uma grelha de avaliação, em vez de uma resposta de referência, para analisar o resultado.
Os critérios de avaliação abertos são adequados para verificar o tom, a clareza, a exaustividade, a utilidade e a qualidade do conteúdo. O avaliador analisa se a resposta está de acordo com a tarefa, aborda os pontos-chave e se adequa à finalidade pretendida.
A rubrica é especialmente importante neste caso. Se as instruções se limitarem a dizer “avaliar a qualidade da resposta”, o avaliador tem demasiada liberdade para fazer suposições. Mas se a rubrica indicar “verificar se a resposta abrange todos os passos solicitados e evita afirmações sem fundamento”, a pontuação torna-se mais útil.
Os avaliadores comparativos analisam vários resultados para a mesma tarefa e selecionam o melhor. Por vezes, isto implica comparar duas respostas lado a lado ou classificar várias opções para determinar a melhor escolha.
O Sergei utilizou esta configuração no seu motor de conteúdos. O redator elaborou três versões de uma publicação X para o mesmo briefing. O avaliador utilizou a mesma tabela de avaliação para as analisar e ajudou a identificar o rascunho mais forte.
Este tipo de avaliação é útil para testes rápidos, seleção de modelos e fluxos de trabalho de conteúdo em que a equipa precisa de escolher entre diferentes versões. No entanto, a ordem ou o comprimento das respostas podem ainda afetar os resultados, pelo que as equipas costumam apresentar as opções de forma aleatória e comparar as decisões dos avaliadores com a revisão humana.
É por isso que Metodologia de avaliação do LLM na função de juiz é útil para a avaliação do RAG. Permite à equipa verificar cada parte do pipeline separadamente, em vez de se limitar a analisar a resposta final e tentar adivinhar o que correu mal. Esta análise passo a passo é frequentemente designada por «tríade do RAG».
Esta distinção torna a depuração menos ambígua. Um problema de recuperação significa que o sistema não recuperou o material correto. Um problema de adequação significa que o material correto estava presente, mas o modelo não se manteve fiel a ele. Se a resposta for relevante apenas à superfície, a equipa precisa de analisar a forma como o modelo transforma o contexto numa resposta.
Os juízes do LLM também ajudam no treino do modelo. A sua função, neste contexto, é criar um sinal de preferência, uma indicação de treino que indique ao ciclo qual a resposta que deve ter uma classificação mais elevada e porquê.
Em aprendizagem por reforço a partir do feedback humano, ou RLHF, este sinal tem normalmente origem nas pessoas. Os avaliadores comparam duas respostas-modelo e selecionam a melhor. Estas escolhas transformam-se em dados de preferência para um modelo de recompensa, o que, posteriormente, ajuda o ciclo de treino a privilegiar respostas semelhantes.
O gargalo é o volume. À medida que o conjunto de amostras cresce, os revisores não conseguem verificar todos os pares ao mesmo ritmo. Um juiz LLM ajuda a classificar os resultados numa primeira fase, para que as pessoas se concentrem nos casos duvidosos ou nos exemplos em que uma preferência errada possa prejudicar o modelo.
Otimização relativa de políticas em grupo, ou GRPO, trabalha com um conjunto de respostas. O modelo gera várias respostas para o mesmo prompt, e o ciclo de treino necessita de um sinal de recompensa para cada resposta desse conjunto. O GRPO nem sempre necessita de um juiz LLM. No caso da matemática ou da programação, uma regra ou um verificador pode fornecer a recompensa. Para tarefas sem uma resposta fixa, um avaliador pontua as respostas com base num critério de avaliação. Isto é útil quando a qualidade depende da adequação às políticas e do cumprimento das instruções.
Existe um risco semelhante ao da avaliação de produtos: assim que as pontuações dos avaliadores são introduzidas no treino, o modelo começa a aprender com as preferências dos avaliadores. Se o avaliador recompensar a verbosidade, o modelo poderá aprender a ser verboso. Se ignorar atalhos perigosos, o modelo poderá repeti-los. As recompensas baseadas nos avaliadores precisam de ser calibradas antes de afetarem o treino.
Nas tarefas de raciocínio, a avaliação com base na resposta final pode não detetar erros graves. Um modelo pode chegar ao resultado correto após um passo errado. Em programação ou matemática, esse erro oculto é importante, pois o mesmo passo pode falhar numa tarefa mais difícil.
Modelos de recompensa por processo, ou PRMs, avaliam o raciocínio à medida que o modelo avança até à resposta final. Um avaliador ao nível do processo verifica cada passo e aponta onde a lógica falha.
Assim que as pontuações dos avaliadores são introduzidas no treino, começam a moldar o comportamento do modelo. As equipas devem testar o sistema de avaliação, manter as pessoas a trabalhar em amostras de alto risco e atualizar a rubrica quando o modelo começar a adquirir hábitos errados.
Agora que já abordámos a forma como estes sistemas são configurados e como se comportam num processo de avaliação real, vamos falar dos benefícios concretos. Por que razão se deve dar ao trabalho de configurar um «juiz» LLM no seu projeto e o que ganha com isso?
As equipas humanas de controlo de qualidade atingem um limite quanto ao número de registos de chat ou gerações que conseguem analisar por dia. Um sistema de avaliação baseado em LLM ajuda a analisar amostras muito maiores, incluindo o tráfego de produção cuja verificação manual seria demasiado dispendiosa. Isto dá às equipas uma melhor oportunidade de detetar problemas de qualidade que escapariam em pequenas revisões manuais.
A avaliação por parte de juízes demora normalmente apenas alguns segundos. As equipas podem incorporá-la nas verificações de CI/CD ou utilizá-la como filtro antes de uma mensagem ser enviada ao utilizador. Os programadores podem ver o que mudou após um pequeno ajuste no prompt, sem terem de esperar dias por uma revisão humana.
As métricas tradicionais de software dependem de correspondências exatas de palavras-chave ou da sobreposição de caracteres. Por exemplo, se um modelo indicar “O cliente está satisfeito” em vez de “O utilizador está satisfeito”,” Um critério de avaliação rigoroso poderia considerá-la errada. Um modelo de linguagem de grande escala (LLM) é capaz de reconhecer que o significado é suficientemente próximo e verificar se a resposta cumpre os critérios de avaliação. Isso é importante no que diz respeito ao tom e à estrutura, domínios em que as expressões regulares (regex) quase não fornecem qualquer indicação útil.
A anotação humana pode ser dispendiosa, especialmente no caso de tarefas complexas de raciocínio ou codificação que exigem revisores especializados. As revisões através da API de LLM custam, normalmente, muito menos por amostra.
Num projeto recente, um sistema automatizado de apoio ao cliente por e-mail criou três rascunhos de respostas educadas, o que custou cerca de $0.05 em tokens de API. Recorrer a um avaliador para analisar os três rascunhos à luz dos critérios da nossa marca e escolher o melhor custou cerca de $0.01. Essa etapa de revisão custou cerca de um cêntimo.
Os revisores humanos cansam-se. Por exemplo, um etiquetador pode classificar um texto de forma diferente no final de uma sexta-feira do que no início de uma segunda-feira. Os avaliadores de LLM têm os seus próprios preconceitos técnicos, como a preferência por textos mais longos, mas não se cansam. Com definições fixas e uma grelha de avaliação testada, aplicam os mesmos critérios de forma mais consistente do que uma equipa humana a trabalhar numa longa fila de tarefas.
Quando se altera o que o sistema testa, muitas vezes não é necessário reescrever centenas de linhas de código Python. Em muitos casos, basta atualizar os critérios de avaliação e voltar a testar. Por exemplo, um critério que verifica a exatidão factual pode ser ajustado para avaliar a empatia e a voz da marca.
"Não se deve tratar um juiz LLM como se fosse apenas um verificador de qualidade do tipo «caixa preta». Funciona melhor quando a sua equipa segue um critério de avaliação claro, regista todas as pontuações e compara as suas decisões com as avaliações humanas. Caso contrário, obtém-se apenas números, em vez de uma visão real sobre a qualidade.."
Diretor da especialização técnica IA
O conceito de «LLM como juiz» É útil, mas tem as suas falhas. Se se permitir que uma IA avalie outra, introduzem-se novos pontos cegos no processo de avaliação. Sem uma monitorização cuidadosa, o sistema pode atribuir pontuações com confiança a respostas fracas.
Eis os principais pontos a ter em conta quando configuro um juiz automatizado.
Quando um juiz compara várias versões ao mesmo tempo, pode preferir a primeira ou a última opção que vir. Por vezes, a posição em que uma versão aparece é mais importante do que a sua qualidade. Para evitar isso, misture a ordem das versões antes de as enviar ao juiz.
Os LLMs tendem a preferir respostas mais longas. Um avaliador pode atribuir uma pontuação mais elevada a uma resposta longa e prolixa em vez de uma resposta curta e clara, mesmo que a resposta mais curta seja mais útil. Para evitar isso, a tabela de avaliação deve indicar ao avaliador que penalize a prolixidade desnecessária.
Um modelo avaliador pode dar preferência a respostas redigidas pela sua própria família de modelos. Por exemplo, se utilizar o GPT-5.5 como modelo avaliador, este poderá atribuir pontuações mais elevadas às respostas do GPT-5.5 do que às do Claude Sonnet 5 ou do Gemini. O modelo avaliador costuma preferir formulações e estruturas que lhe são familiares, mesmo que outra resposta seja melhor. Para obter resultados mais justos, as equipas costumam utilizar vários modelos avaliadores e comparar as suas pontuações.
Mesmo uma pequena alteração na rubrica pode afetar as pontuações finais. Por exemplo, alterar a instrução de “Classifique a utilidade” para “Avalie o quão útil isto é” pode fazer com que a taxa média de aprovação desça de 80% para 60%. O avaliador está atento à forma como as regras são redigidas, pelo que as instruções devem ser versionadas e verificadas por pessoas.
Se utilizar uma API alojada, como a GPT-5.5 ou a Claude Sonnet 5, como critério de avaliação, o fornecedor poderá atualizar o modelo sem aviso prévio. Quando isso acontece, as suas pontuações de referência podem alterar-se da noite para o dia. Uma resposta que antes obtinha 4 em 5 pode agora receber um 3, tornando mais difícil comparar resultados anteriores.
Se continuar a treinar um modelo gerador utilizando o feedback do mesmo avaliador LLM, o gerador poderá aprender a burlar o sistema. Em vez de melhorar as respostas para os utilizadores, passa a identificar as palavras e os formatos que o avaliador prefere. Pode até copiar o tom que obtém pontuações mais elevadas. As pontuações aumentam, mas a qualidade real do produto pode diminuir.
Incorporar um modelo de linguagem de grande escala (LLM) ao seu fluxo de trabalho é simples, mas tornar as suas pontuações suficientemente fiáveis para decisões de publicação é mais desafiante. Se utilizar apenas um prompt básico e pedir ao modelo para classificar este texto, os resultados serão, muitas vezes, inconsistentes.
Ao configurar estes pipelines, reuni os mais populares Técnicas de «LLM como juiz» que ajudam a manter os modelos de avaliação estáveis para tarefas de avaliação reais.
É importante estruturar os resultados da avaliação desde o início. Em vez de utilizar comentários livres, certifique-se de que o modelo devolve pontuações para cada critério, uma breve explicação e uma classificação final num formato que o seu pipeline consiga ler facilmente.
Por exemplo, evite que o juiz dê respostas livres do tipo “Este texto é bastante bom, dou-lhe um 8/10”. Estas respostas são difíceis de processar em código. Em vez disso, faça com que o modelo utilize um esquema JSON rigoroso com resultados estruturados, ou recorra à chamada de ferramentas e Métricas do LLM na função de juiz.
Instruções pouco claras levam a pontuações pouco claras. Por exemplo, se pedir a um avaliador para classificar a “criatividade” de 1 a 5, o modelo limitar-se-á a adivinhar. Em vez disso, utilize critérios específicos que reduzam a margem de interpretação.
Por exemplo, ao avaliar artigos ou publicações escritas, evito pontuações gerais de qualidade. Em vez disso, divido a grelha de avaliação em critérios mais específicos, como estes:
É importante estruturar os resultados da avaliação desde o início. Em vez de utilizar comentários livres, certifique-se de que o modelo devolve pontuações para cada critério, uma breve explicação e uma classificação final num formato que o seu pipeline consiga ler facilmente.
Por exemplo, evite que o juiz dê respostas livres do tipo “Este texto é bastante bom, dou-lhe um 8/10”. Estas respostas são difíceis de processar em código. Em vez disso, faça com que o modelo utilize um esquema JSON rigoroso com resultados estruturados, ou recorra à chamada de ferramentas e Métricas do LLM na função de juiz.
Mantenha o gerador e o avaliador separados. Este é um dos controlos fundamentais numa configuração em que o LLM atua como avaliador, uma vez que o modelo que redigiu a resposta pode não perceber os seus próprios padrões ou sobrevalorizar formulações que lhe são familiares. Por exemplo, se utilizar o GPT-5.5 para gerar texto, utilize o Claude Sonnet 5 como avaliador, ou vice-versa. Também pode utilizar um modelo de peso aberto mais pequeno e ajustado com precisão, como uma variante especializada do Llama 4 Maverick ou do Llama 4 Scout, para avaliação. Esta abordagem pode ajudar a reduzir custos e a diminuir o viés de auto-valorização.
Tal como discutimos na secção sobre riscos, os modelos podem apresentar um viés de posição. Para evitar isso, aleatorize a ordem das respostas em cada comparação. Ao avaliar pares ou múltiplas respostas, um modelo pode escolher a primeira resposta simplesmente devido à sua posição. Baralhe as opções antes de avaliar e, em seguida, associe a resposta escolhida ao modelo ou prompt original no seu código. Em testes importantes, tente inverter a ordem e registe quaisquer casos em que o vencedor mude após a inversão.
Para reduzir o viés sistémico, certifique-se de que o avaliador não tem acesso a quaisquer metadados de geração. O avaliador não deve saber qual o modelo que escreveu o texto nem qual foi o prompt utilizado. Forneça ao avaliador apenas o resultado bruto e a tabela de classificação.
A escrita e a avaliação exigem configurações diferentes do modelo. Ao gerar texto, utilize uma temperatura mais elevada, como 0,7 a 0,9, para promover a variedade e um fluxo natural. Para a avaliação, defina a temperatura para um valor baixo, frequentemente 0, para que o modelo atribua pontuações mais consistentes para a mesma entrada.
Mas tenha em atenção que uma temperatura de 0 torna as verificações repetidas mais estáveis apenas quando a entrada se mantém inalterada. Não corrige a sensibilidade do prompt, as alterações na grelha de avaliação nem o enviesamento de posição. Se reescrever a grelha de avaliação ou trocar a ordem das respostas, a pontuação pode continuar a variar.
Quando a OpenAI, a Anthropic ou a Google atualizarem os endpoints dos seus modelos, o seu «juiz» poderá tornar-se mais tolerante ou mais rigoroso. Para detetar esta situação, crie um pequeno conjunto de dados de referência com 50 a 100 respostas históricas que já tenham sido avaliadas e aprovadas por humanos. Execute o seu avaliador LLM com este conjunto de dados uma vez por semana. Se as pontuações subirem ou descerem repentinamente, o modelo pode ter sofrido um desvio, e poderá ser necessário ajustar os seus prompts ou fixar a sua API a uma versão estática.
Um avaliador automatizado é um auxiliar, não um substituto da supervisão humana. Acompanhe a taxa de concordância entre o avaliador LLM e a sua equipa humana de controlo de qualidade. Se utilizar a concordância entre 85% e 90% como meta interna, considere-a como uma verificação de bom funcionamento e não como um padrão universal. Se essa concordância diminuir, os requisitos do seu produto podem ter mudado, sendo altura de atualizar a rubrica.
Conhecer os riscos associados aos juízes dos modelos de linguagem de grande escala (LLM) só é útil se o sistema dispuser de mecanismos de controlo para os detetar. Por exemplo, um juiz pode preferir a primeira resposta que vê ou atribuir pontuações mais elevadas a respostas mais longas. Por vezes, uma atualização do modelo pode alterar as pontuações, mesmo que o seu produto não tenha sofrido qualquer alteração.
A seguir, apresento as práticas que utilizo com mais frequência para reduzir o enviesamento e detetar dados de avaliação pouco fiáveis.
Ao comparar os resultados, certifique-se de que o avaliador não sabe qual das versões corresponde a cada prompt ou modelo. Baralhe sempre as opções antes de as enviar ao avaliador. Se o avaliador escolher a “Opção A”, o seu código deve associar discretamente essa escolha à variante do modelo correspondente.
Esta regra também se aplica aos metadados. O texto a avaliar deve incluir apenas o texto bruto e a grelha de avaliação, e não o nome do modelo nem os detalhes da geração. Se o avaliador vir detalhes como o tamanho do modelo, o número de tokens ou o tempo de processamento, poderá utilizá-los como atalhos para avaliar a qualidade.
No que diz respeito a métricas de produção importantes, um único modelo de avaliação pode não ser suficiente. Por exemplo, um modelo de avaliação baseado no GPT pode ter preferências diferentes das do Claude ou de um modelo Llama ajustado.
Para avaliações críticas, prefiro enviar o mesmo resultado a vários modelos avaliadores e comparar as suas pontuações. Pode calcular a média das pontuações ou recorrer ao voto de maioria, mas certifique-se de que os avaliadores são independentes. Se os avaliadores forem demasiado semelhantes, o painel poderá parecer mais fiável do que realmente é. Preste muita atenção às divergências. Se dois avaliadores atribuírem uma pontuação de 5 em 5 e outro atribuir 1 em 5, envie esse caso a um humano para revisão. Grandes diferenças significam, normalmente, que a rubrica está demasiado aberta à interpretação.
Um juiz automatizado deve funcionar da mesma forma que as pessoas com formação utilizam a grelha de avaliação. Para verificar isso, selecione uma amostra aleatória de registos avaliados com o código 5% e peça à sua equipa interna para os classificar de forma cega, utilizando a mesma grelha de avaliação.
Em seguida, compare os resultados. Algumas equipas utilizam o Kappa de Cohen, enquanto outras limitam-se a analisar a percentagem de concordância. Se o seu objetivo for uma concordância de 85% e o avaliador ficar aquém desse valor, o problema reside normalmente no facto de a rubrica já não ser suficientemente clara ou de os requisitos do seu produto terem mudado.
Alguns fluxos de trabalho requerem uma verificação adicional: a memória. Isto é importante para motores de conteúdo, geradores de relatórios diários e outros sistemas que produzem resultados semelhantes ao longo do tempo.
Uma única saída pode parecer adequada por si só. Mas se o gerador utilizar a mesma analogia três dias seguidos, os utilizadores vão dar por isso. Uma verificação pontual por parte de um revisor pode não detectar esta situação.
Nestes casos, forneço ao juiz um resumo dos dias anteriores. Quando este analisa os rascunhos de hoje, a sugestão inclui um índice vetorial contínuo ou um breve resumo dos resultados aprovados dos últimos 7 a 14 dias. Isso permite ao juiz identificar metáforas repetidas, ganchos reutilizados, palavras de preenchimento e frases finais fracas que passariam despercebidas numa análise de um único documento.
Em que contextos é que as equipas de engenharia utilizam esta abordagem? Ao longo do último ano, tenho observado os avaliadores de LLM a passarem de pequenos scripts de avaliação para fluxos de trabalho de IA em produção.
Vamos analisar as principais áreas em que vejo que são utilizados atualmente.
Como referido anteriormente, os sistemas RAG constituem um caso de utilização claro para os avaliadores automatizados. As equipas recorrem aos avaliadores para verificar se o sistema de recuperação identifica o contexto correto e se a resposta final se baseia nos documentos de origem. Isto ajuda a detetar afirmações sem fundamento antes de se tornarem «alucinações».
Com os motores de conteúdo automatizados, raramente é uma boa ideia publicar o primeiro rascunho gerado por um modelo. Em vez disso, os fluxos de trabalho criam várias versões e recorrem a um avaliador para as comparar com base numa grelha de avaliação. O avaliador escolhe o rascunho mais sólido e assinala a linguagem genérica antes da publicação.
Os bots de apoio podem causar problemas se se desviarem do guião. As equipas recorrem a avaliadores para analisar grandes conjuntos de registos de chat após a conversa. O avaliador verifica se o bot respondeu à pergunta do utilizador e se cumpriu as regras da empresa, incluindo políticas de reembolso, procedimentos de escalonamento e promessas relativas a funcionalidades.
As listas tradicionais de palavras-chave proibidas e os filtros de expressões regulares são fáceis de contornar. Um sistema de moderação baseado em LLM tem em conta o significado e o contexto, o que ajuda as equipas de moderação a detetar conteúdos prejudiciais que não utilizam palavras proibidas óbvias. Este sistema pode analisar tanto as solicitações dos utilizadores como as respostas do modelo à luz da política.
À medida que os agentes de IA começam a realizar ações através de ferramentas e APIs, não basta avaliar apenas o texto final. Nestes fluxos de trabalho, os avaliadores analisam todo o processo. Verificam a utilização das ferramentas, o progresso da tarefa e se o agente concluiu a tarefa sem ficar bloqueado.
Não se deve escolher um modelo de avaliação apenas com base na sua pontuação nos testes de desempenho. O melhor modelo depende da tarefa para a qual é necessário. Por exemplo, um modelo que seja bom a classificar rapidamente registos de apoio ao cliente pode não ser suficientemente robusto para lidar com dados de preferências durante o treino. Um modelo de topo pode ser excelente para avaliações de alto risco, mas a sua utilização todas as noites em milhares de resultados pode revelar-se demasiado dispendiosa.
Por isso, normalmente analiso primeiro quatro aspetos: o que o juiz precisa de avaliar, quanto contexto é necessário, com que rapidez o resultado deve ser apresentado e o que acontece se o resultado estiver errado.
As tarefas de geração e avaliação requerem frequentemente configurações e níveis de potência diferentes dos modelos.
A geração de texto é uma tarefa criativa. Para tal, é normalmente necessário um modelo robusto, como o GPT-5.5, o Claude Sonnet 5 ou o Claude Opus 4.8, configurado com um valor de temperatura mais elevado para que o texto soe mais natural.
A avaliação é uma tarefa de avaliação específica, mas a qualidade costuma ser a prioridade. No que diz respeito a critérios de lançamento, dados de preferências, verificações RAG ou resultados de alto risco, as equipas recorrem frequentemente ao modelo de avaliação mais robusto que podem utilizar. Os modelos mais rápidos podem ser adequados para verificações em lote de baixo risco, após calibração com base em amostras revistas por humanos.
Ao escolher um modelo de avaliação, comece por considerar o custo de uma pontuação incorreta. Em muitas configurações de LLM com modelo de avaliação, a qualidade da avaliação é mais importante do que a velocidade ou o custo por token, especialmente quando as pontuações afetam as decisões de lançamento, os dados de treino ou os mecanismos de proteção destinados aos utilizadores.
Não deves ter de analisar texto bruto para descobrir qual foi a pontuação atribuída pelo juiz. Ao escolher um modelo de juiz, é essencial que este siga um esquema rigoroso. Podes utilizar o «Structured Outputs» da OpenAI, o «Tool Use» da Anthropic ou uma estrutura de código aberto como o «Outlines». Em todos os casos, o modelo deve devolver uma resposta JSON limpa. Se um modelo for barato e rápido, mas frequentemente violar a formatação JSON, será difícil utilizá-lo num pipeline de avaliação automatizado.
Nem sempre é necessário escolher apenas um modelo. Para tarefas importantes, costumo optar por uma abordagem de conjunto de modelos. Em vez de depender de um único modelo dispendioso, envio a mesma avaliação a vários modelos de avaliação de diferentes fornecedores, como a OpenAI, a Anthropic e uma opção de código aberto.
Depois disso, pode comparar as pontuações, calcular a média ou recorrer a um voto por maioria. Isso ajuda a reduzir o viés de qualquer avaliador individual. No entanto, os avaliadores têm de ser suficientemente diferentes entre si. Se todos cometerem os mesmos erros, o cálculo da média ou a votação apenas irão repetir o mesmo viés. É por isso que também procuro divergências entre os juízes e encaminho os casos pouco claros para um ser humano, para revisão.
O LLM-as-a-judge continua a ser uma forma nova de avaliar modelos. Muitas equipas já utilizam «juízes» para pontuação, comparação e verificações RAG, mas a sua configuração ainda exige muito trabalho manual. O próximo passo é tornar os sistemas de avaliação mais fiáveis. Estes devem indicar quando uma pontuação é incerta, utilizar ferramentas para verificar os resultados e apresentar um melhor desempenho em domínios específicos.
Estas são as áreas a que estou a dedicar mais atenção.
Neste momento, os juízes dos modelos de linguagem de grande escala (LLM) podem mostrar-se excessivamente confiantes. Se um juiz receber uma instrução pouco clara, pode mesmo assim atribuir uma pontuação definitiva, em vez de indicar que o caso é incerto.
Espero que mais sistemas de avaliação comecem a apresentar os níveis de confiança juntamente com a pontuação. Em vez de se limitar a dizer passar ou falhar, o juiz poderá proferir algo do género Pontuação: 4, Confiança: 65%. Se o nível de confiança for demasiado baixo, o sistema pode encaminhar o caso para um revisor humano.
Modelos de uso geral, como o GPT-5.5 ou o Claude Sonnet 5, funcionam bem em tarefas como e-mails, resumos e revisão básica de código. No entanto, para avaliações médicas ou jurídicas complexas, precisamos de um maior controlo sobre a área em questão.
É por isso que espero ver modelos de juízes mais especializados. Alguns poderão ser aperfeiçoados para tarefas específicas, como analisar respostas médicas ou verificar contratos jurídicos. Estes modelos não irão substituir os especialistas, mas poderão ajudar ao tratar de casos rotineiros e a encaminhar os casos mais complexos para as pessoas.
ferramenta para a avaliação de modelos de linguagem de grande escala (LLM) na função de juiz provavelmente passará a fazer parte de mais processos de avaliação. Os juízes não devem basear-se apenas no que sabem internamente, quando podem comparar as tarefas com fontes externas.
Por exemplo, se um gerador escrever um script Python, o avaliador pode executá-lo num ambiente de teste para procurar erros. Se o gerador fizer alguma afirmação sobre um acontecimento recente, o avaliador pode recorrer a uma pesquisa ou a uma fonte de dados fiável para a verificar. O objetivo é comparar o resultado com as provas, em vez de avaliar o texto isoladamente.
Quando as equipas utilizam as pontuações dos avaliadores nos ciclos de treino, os modelos generativos podem aprender a agradar ao avaliador, em vez de fornecerem melhores respostas aos utilizadores. Trata-se de uma forma de «manipulação de recompensas».
Por exemplo, o gerador pode perceber que o avaliador prefere listas com marcadores ou uma formulação muito educada. Também pode começar a repetir frases de preenchimento que costumam obter boas pontuações. Os futuros sistemas de avaliação precisarão de melhores formas de detetar isto, para que as pontuações reflitam a verdadeira qualidade das respostas.
Muitas equipas ainda encaram a avaliação como um script separado que executam após um prompt ou uma atualização do modelo. Penso que isto irá mudar à medida que os sistemas de IA se forem integrando cada vez mais na produção. O próximo passo é integrar a avaliação no pipeline de entrega. Antes do lançamento, os avaliadores podem ajudar a detetar regressões nos conjuntos de teste. Após o lançamento, podem monitorizar os resultados amostrados e encaminhar os casos de risco para pessoas.
Se leu até aqui, provavelmente está a pensar num problema de avaliação no seu sistema de IA. Talvez a revisão manual seja demasiado lenta. Talvez os seus resultados mostrem que a qualidade mudou, mas não expliquem o que é que realmente correu mal.
É por isso que a configuração é importante. O mesmo modelo não deve, simultaneamente, elaborar as perguntas e avaliar as respostas. É necessário dispor de uma grelha de avaliação clara, de um método estruturado para registar os resultados e de uma revisão humana regular para manter o sistema calibrado.
O verdadeiro risco é que uma resposta fluente possa, mesmo assim, não cumprir a tarefa. Um modelo pode parecer confiante, mas acabar por não ter em conta o contexto de origem ou ignorar uma parte essencial do pedido do utilizador. Uma camada de avaliação bem concebida ajuda-o a detetar essa lacuna antes que os seus utilizadores o façam.
Na Innowise, ajudamos as equipas a criar camadas de avaliação para Produtos LLM, Agentes de IA, e sistemas de IA empresariais. Se o seu produto de IA necessitar de controlos de qualidade mais rigorosos, vamos conversar.
O «LLM-as-a-judge» é um método de avaliação em que um modelo de linguagem (o «juiz») avalia, atribui pontuações e apresenta o raciocínio subjacente às saídas textuais de outros sistemas de IA. Substitui as dispendiosas revisões humanas, automatizando as verificações de qualidade em termos de precisão, relevância, tom ou segurança em grande escala.
Os avaliadores de LLM costumam ser precisos em muitas tarefas de avaliação, mas o seu desempenho depende da tarefa, do modelo, da rubrica e da calibração do sistema. As equipas devem comparar as pontuações dos avaliadores com amostras revistas por humanos e estar atentas a possíveis enviesamentos, sensibilidade às instruções e desvios.
Os juízes do LLM aceleram e ampliam o fluxo de trabalho de avaliação sem substituir totalmente os seres humanos. A supervisão humana continua a ser necessária em casos sensíveis, na criação de conjuntos de dados de treino e na definição de critérios de classificação.
Quando um aluno avalia o seu próprio trabalho, tende a sobrestimar-se. Muitas vezes, ignora os seus próprios erros e problemas de redação, o que leva a notas demasiado altas e pouco úteis.
A tríade RAG é um quadro de avaliação concebido para sistemas de geração reforçada por recuperação. Mede o desempenho em três axes específicos: relevância do contexto, fundamentação e relevância da resposta final.
Nos ciclos de aprendizagem por reforço, os juízes do LLM geram rapidamente sinais de preferência automatizados e pontuações passo a passo. Isto permite que os modelos de recompensa otimizem o alinhamento do sistema muito mais rapidamente do que as avaliações manuais realizadas por pessoas.
Os principais riscos decorrem de enviesamentos inerentes ao modelo, incluindo uma tendência para privilegiar respostas mais longas (enviesamento de verbosidade), dar preferência às respostas apresentadas em primeiro lugar (enviesamento de posição) e demonstrar elevada sensibilidade a pequenas alterações na formulação do prompt.
As equipas podem minimizar o enviesamento separando os modelos de geração e de avaliação, aleatorizando a ordem das respostas em cenários comparativos, ocultando os metadados dos modelos e validando as pontuações automáticas em relação a valores de referência revistos por humanos.
