Modelo como juiz (LLM-as-a-judge): o que avalia e que vieses verificar

Definição: o que é um modelo como juiz

Um modelo como juiz é um modelo de linguagem utilizado para avaliar uma resposta, um resultado ou o comportamento de uma aplicação de IA segundo critérios definidos antecipadamente. Pode, por exemplo, atribuir uma pontuação, classificar o resultado ou comparar duas alternativas. A expressão inglesa habitual é LLM-as-a-judge.

O objeto avaliado não tem de ser apenas um texto. Consoante o uso, pode ser a resposta de um chatbot, um resumo, o resultado produzido por uma ferramenta ou o registo das ações de um agente. A avaliação também pode considerar informações de referência, como a pergunta original, um documento-fonte, uma política ou uma lista de restrições.

A expressão designa um método de avaliação, não uma garantia de exatidão. O julgamento produzido continua a ser o resultado de um modelo: depende do que lhe é pedido para examinar, dos critérios que recebe e das informações disponíveis. Por isso, uma pontuação automatizada não equivale, por si só, a uma verdade verificada, a uma etiqueta de referência independente ou a uma revisão humana.

No seu âmbito operacional, o guia da Langfuse define o método como a utilização de um modelo de linguagem para avaliar a qualidade dos resultados de outra aplicação baseada em LLM. A documentação da MLflow inclui tanto aplicações LLM como agentes e enumera possíveis dimensões de qualidade, entre elas correção, relevância, fundamentação, segurança e utilidade. Estas descrições ajudam a compreender o uso, mas não transformam uma ferramenta específica numa definição universal.

Como funciona o processo

Um fluxo de avaliação razoável começa por definir o que se pretende julgar e com que finalidade. Não é o mesmo verificar se uma resposta respeita uma política ou avaliar se é clara para uma pessoa. Se o objetivo for ambíguo, o modelo pode apresentar um juízo aparentemente preciso que não corresponde à necessidade real.

Em seguida, especificam-se os critérios. Uma rubrica pode descrever dimensões distintas, como fidelidade a uma fonte, cobertura de informação, cumprimento de restrições ou relevância. Também pode definir uma escala e explicar o significado de cada nível. A rubrica não elimina divergências, mas torna explícito o que se espera que o juiz avalie.

Depois, apresenta-se o material pertinente: a resposta ou o registo avaliado e, quando necessário, a pergunta, o documento de referência, as regras em vigor ou as restrições da tarefa. O contexto deve ser suficiente para aplicar o critério, mas este guia não parte do princípio de que acrescentar mais informação melhora sempre o julgamento: convém verificar de que contexto a tarefa realmente precisa.

A instrução de avaliação especifica o papel do juiz e o formato de saída. O resultado pode incluir uma pontuação, uma categoria, uma preferência entre opções e uma explicação. Por fim, o juízo é revisto: procuram-se erros, compara-se o resultado com avaliações humanas ou referências externas quando possível e decide-se se é adequado ao uso previsto. O facto de o juiz gerar uma justificação não demonstra, por si só, que ela esteja correta.

Formas de julgamento: pontuação, classificação e comparação

Numa avaliação por pontuação, o juiz avalia uma resposta individualmente, por exemplo, segundo uma escala definida pela equipa. A escala só é interpretável quando se sabe o que representa cada valor. Uma pontuação global de qualidade pode ocultar que uma resposta é fiel, mas incompleta, ou completa, mas contrária a uma restrição; separar dimensões pode tornar este tipo de compensação mais claro.

Numa classificação, o juiz atribui uma categoria, como «cumpre», «não cumpre» ou «requer revisão». Também pode ordenar várias respostas por grupos ou níveis. As categorias reduzem a aparência de precisão numérica, mas continuam a depender de definições claras e da aplicação adequada dessas definições pelo modelo.

Numa comparação por pares, apresentam-se duas alternativas e pede-se ao juiz que escolha a que satisfaz melhor um critério, ou que declare um empate, se o formato o permitir. O resultado é relativo: o facto de uma opção ser preferida não demonstra que esteja correta nem que ultrapasse um limiar absoluto. Além disso, a comparação responde ao par apresentado; não estabelece automaticamente uma ordenação fiável para todas as respostas possíveis.

Estes formatos são distintos e respondem a perguntas diferentes. Uma pontuação procura expressar o desempenho face a uma escala; uma categoria atribui uma etiqueta; uma comparação indica uma preferência entre opções. Não se deve presumir que um formato é sempre superior. A escolha depende da decisão a tomar e deve ser testada com exemplos representativos.

Exemplo aplicado: respostas de apoio ao cliente

Imaginemos que uma equipa pretende rever as respostas de um assistente de apoio ao cliente. O objeto da avaliação é cada resposta; o contexto pertinente pode incluir a pergunta da pessoa e a versão em vigor da política aplicável. Uma rubrica poderia separar, no mínimo, se a resposta aborda a pergunta, se está de acordo com a política fornecida e se respeita as restrições de comunicação definidas pela equipa.

O juiz poderia classificar cada dimensão ou atribuir pontuações separadas e assinalar os casos duvidosos para revisão. Por exemplo, se a resposta prometer um reembolso, o critério não deve ser se a promessa parece razoável: é preciso verificá-la face à política que foi fornecida. A avaliação do modelo indica como interpretou o material; não substitui a verificação de que a política está atualizada nem a decisão sobre que regra deve ser aplicada.

Para avaliar o método, a equipa pode selecionar casos que abranjam diferentes perguntas e exceções, comparar os juízos com revisões humanas e analisar as divergências. Se o sistema for utilizado para dar prioridade a revisões, também convém verificar se identifica os casos que a equipa considera sensíveis ou incertos. Esta proposta é uma orientação de conceção: as fontes disponíveis não permitem afirmar que um juiz concordará com especialistas em todos os casos.

Exemplo aplicado: resumos de documentos

Para comparar resumos, o objeto avaliado é o resumo e o contexto de referência é o documento original, juntamente com a instrução que pediu a síntese. Os critérios poderiam distinguir a cobertura dos pontos relevantes e a fidelidade das afirmações ao texto-fonte. Manter essas dimensões separadas ajuda a evitar que uma prosa fluente seja confundida com um resumo completo ou fiel.

Um juiz poderia pontuar cada resumo individualmente ou comparar dois resumos para determinar qual abrange melhor os conteúdos relevantes sem introduzir afirmações sem fundamento. A revisão deveria verificar se a avaliação identifica omissões concretas ou afirmações incompatíveis com o documento, em vez de se basear apenas numa explicação genérica como «é mais completo».

A escolha da informação considerada relevante depende da tarefa: um resumo executivo, um resumo técnico e um destinado a responder a uma pergunta específica podem exigir coberturas distintas. Por isso, o documento-fonte e a finalidade do resumo devem estar disponíveis para o avaliador. A pontuação do juiz não é, por si só, uma lista verificada de factos omitidos ou inventados.

Exemplo aplicado: agentes de programação

Na avaliação de um agente de programação, o objeto pode incluir o resultado final e o registo das ações, não apenas o texto da resposta. A tarefa, os testes disponíveis e as restrições definem o que significa concluir o trabalho. Entre os critérios explícitos poderiam estar resolver a tarefa pedida e respeitar limites, como não modificar determinados ficheiros ou não utilizar uma ferramenta específica, se essas restrições fizerem parte do pedido.

Um juiz pode avaliar cada critério, resumir que evidências do registo parecem sustentá-lo ou indicar que não consegue decidir com as informações disponíveis. A equipa deve verificar se o juízo corresponde ao resultado verificável. Por exemplo, uma explicação convincente de que uma tarefa foi concluída não substitui a execução de testes; ao mesmo tempo, passar num teste isolado não demonstra necessariamente que todas as restrições foram respeitadas.

Este exemplo mostra por que motivo o objeto da avaliação deve ser definido com cuidado: avaliar apenas a resposta em texto pode deixar de fora ações relevantes, e avaliar apenas um registo sem conhecer as respetivas restrições pode levar a uma apreciação incompleta. As evidências suficientes dependerão do ambiente e da tarefa concreta.

O que convém verificar antes de confiar num juiz

Uma verificação central é a correspondência entre os juízos do modelo e uma referência adequada à tarefa. Essa referência pode consistir em avaliações humanas, regras verificáveis ou resultados externos, consoante aquilo que está a ser medido. Não basta obter uma percentagem global de concordância sem saber que casos foram avaliados, como foram resolvidas as divergências e se os exemplos representam o uso previsto.

Também convém testar a estabilidade do processo. Se o mesmo caso for apresentado mais de uma vez, o juízo mantém-se de forma suficiente para a decisão prevista? As avaliações mudam quando se alteram elementos de apresentação que não são relevantes? Nas comparações por pares, deve verificar-se se inverter a ordem das alternativas altera a preferência. Estas são perguntas de validação, não afirmações de que a alteração ocorre sempre.

A justificação merece uma revisão independente. Uma explicação pode ajudar a identificar o critério aplicado pelo modelo, mas não constitui prova de que a pontuação esteja correta. É possível comparar as razões com o material de entrada e verificar se apontam para evidências pertinentes ou se são vagas, incompatíveis com o resultado ou não sustentadas pela fonte.

Por último, é preciso avaliar se o juiz é adequado à tarefa. Um modelo capaz de avaliar um tipo de resposta não fica automaticamente validado para outro domínio, outro idioma, outro formato de entrada ou uma decisão com consequências diferentes. Uma análise técnica sobre LLM-as-a-judge apresenta a área como a utilização de modelos de linguagem para avaliar tarefas complexas; a descrição disponível também menciona instruções e exemplos para especificar tarefas. Isso não estabelece, por si só, que um método concreto seja fiável em cada aplicação.

Conceitos próximos e confusões frequentes

Um benchmark é um conjunto organizado de tarefas ou casos utilizado para medir ou comparar sistemas em condições definidas. Um modelo como juiz, por outro lado, é um método para atribuir avaliações a resultados. Um benchmark pode incorporar um juiz, mas os dois termos não significam o mesmo: o conjunto de avaliação define os casos a testar; o juiz produz ou participa nos juízos.

Uma rubrica é uma especificação de critérios, níveis ou regras de avaliação. Não é necessariamente um modelo nem um resultado. O juiz pode receber uma rubrica para orientar a sua avaliação, mas a existência de uma rubrica não garante que a aplique corretamente.

A pontuação de um juiz também não equivale a uma etiqueta de referência ou à verdade do caso. Uma resposta pode obter uma pontuação elevada e, ainda assim, conter um erro que a rubrica não detetou ou que o avaliador interpretou mal. Quando existe uma verificação direta — por exemplo, uma regra verificável ou o resultado de um teste — convém não a substituir por uma opinião gerada sem validação.

Por fim, é importante distinguir o modelo avaliador do modelo avaliado. Numa aplicação, podem ser sistemas do mesmo tipo ou modelos diferentes, mas desempenham funções distintas no processo: um gera a resposta ou executa a tarefa; o outro emite um juízo sobre esse resultado. E «julgamento automatizado» não significa «sem supervisão humana»: a revisão humana pode ser necessária para validar o método, resolver exceções ou tomar decisões importantes.

Limites e critérios práticos de utilização

O julgamento depende da definição da tarefa, dos critérios e do contexto fornecido, além do comportamento do modelo avaliador. Por isso, uma avaliação automatizada deve ser descrita com detalhe suficiente para que outras pessoas compreendam o que foi avaliado, com que instruções e que resultado o juiz produziu. A documentação de ferramentas pode propor formatos operacionais e dimensões de avaliação, mas as recomendações de uma plataforma não constituem, por si só, evidência de que essa conceção funcione em qualquer aplicação.

Antes de adotar o método, convém perguntar: o critério representa uma necessidade real do produto ou apenas uma aproximação fácil de pontuar? Existem casos de referência adequados? Sabe-se como tratar divergências e resultados incertos? A sensibilidade a alterações de apresentação foi testada? A decisão pode ser comparada com uma verificação externa? As respostas ajudam a delimitar em que situações o juiz serve de apoio e quando é necessária uma revisão adicional.

Também é útil começar com um uso limitado e reversível, analisar exemplos de acertos e erros e voltar a avaliar o método quando mudarem as políticas, os dados, as instruções ou o modelo. Trata-se de uma recomendação prática, não de uma garantia de que a avaliação se manterá estável. A extensão da revisão humana deve depender da importância da decisão, das consequências de um erro e das evidências obtidas para essa tarefa.

Para continuar, podem consultar-se as fichas sobre avaliação de IA, benchmark, rubrica e humano no circuito, além da entrada sobre **juiz LLM** e dos critérios de **comparação de modelos**. Estes conceitos estão relacionados, mas não são intercambiáveis.

Em síntese, um modelo como juiz pode estruturar ou automatizar uma parte do trabalho de avaliação quando os critérios e o objeto estão claros. O seu resultado deve ser interpretado como um juízo produzido por um modelo e verificado para o uso previsto. A decisão prática não é saber se um juiz é fiável em abstrato, mas que evidências sustentam a sua utilização para uma tarefa, determinados dados e consequências concretas.

Conceitos relacionados