Avaliar uma aplicação baseada num grande modelo de linguagem (LLM) consiste em testá-la de forma sistemática, antes e depois de cada alteração. O guia detalha como escolher os métodos de pontuação, conceber um juiz LLM fiável e, depois, avaliar os sistemas RAG e os agentes ao longo de todo o ciclo de publicação.
Ler algumas respostas e considerá-las satisfatórias não é suficiente. Uma modificação do prompt, uma alteração do modelo ou da pesquisa documental pode quebrar um comportamento sem que se aperceba, e torna-se depois difícil determinar qual a alteração responsável. Avaliar equivale a constituir casos de teste, a pontuar cada resposta segundo critérios escritos e, depois, a comparar as pontuações antes e depois de cada alteração, à semelhança dos testes de não regressão do código clássico.
As respostas de um LLM variam de uma execução para outra, e a noção de «boa resposta» depende do contexto. Um teste unitário verifica uma igualdade, enquanto «Pode devolver os sapatos no prazo de 30 dias» e «As devoluções são aceites durante um mês após a entrega» estão ambas corretas. O guia distingue a avaliação, que mede uma qualidade relativa segundo critérios vagos, dos testes, que validam uma colocação em produção através de controlos binários, como um JSON válido ou a ausência de uma fórmula proibida. Bloquear uma implementação com base numa pontuação de fidelidade de 0,7 equivaleria, segundo o autor, a debater semanalmente um limiar arbitrário.
Três formas de pontuar uma resposta
Um pontuador recebe um caso de teste, composto por uma entrada, uma resposta e, por vezes, um contexto ou uma referência, e depois devolve um veredito ou um número. Os pontuadores de código aplicam regras determinísticas, para verificar o formato, o comprimento ou a presença de determinadas cadeias de caracteres. Os pontuadores baseados numa referência comparam a resposta a uma resposta conhecida. As métricas de sobreposição como BLEU e ROUGE, por exemplo, não reconhecem uma paráfrase correta. O juiz LLM, por fim, é um modelo encarregado de aplicar uma grelha de critérios à resposta de outro modelo, útil para o tom, a ancoragem nas fontes ou a utilidade.
O guia recomenda começar pelo código sempre que uma regra for suficiente, pois estes pontuadores não têm custo e dão sempre o mesmo resultado. São descritas três configurações de juiz: pontual, em que atribui uma etiqueta ou uma nota a uma resposta isolada; por pares, em que escolhe a melhor de duas respostas, método comum para comparar dois prompts ou dois modelos; e guiada por referência, quando dispõe de uma resposta de referência.
Tornar o juiz fiável
Uma grelha de critérios bem redigida determina a qualidade do juiz. O guia descreve-a em quatro partes: a definição do critério, os dados que o juiz pode utilizar, o procedimento a seguir e um formato de saída estrito, de preferência em JSON. O raciocínio deve preceder o veredito, e a temperatura é fixada a 0 para reduzir o ruído de amostragem, sem o eliminar. Para os critérios sensíveis, o guia sugere um número ímpar de execuções e a retenção do veredito maioritário.
O método QAG (geração de perguntas-respostas) pede ao juiz que responda a perguntas fechadas com sim ou não, sendo o cálculo depois efetuado pelo código. A fidelidade de uma resposta de quatro afirmações, das quais três são fundamentadas, vale assim 0,75. Para os critérios subjetivos, o método G-Eval calcula uma média ponderada pelas probabilidades das notas possíveis, de modo que um modelo dividido a 60/40 entre 4 e 5 obtém 4,4. Vieses estão documentados em trabalhos de investigação sobre o julgamento das saídas de LLM: viés de posição, viés de verbosidade e viés de autopreferência para os modelos da mesma família. O guia propõe inverter a ordem das respostas, testar casos de comprimento comparável e utilizar um juiz de outra família de modelos.
A calibração continua a ser a etapa mais importante. O guia aconselha a etiquetar pessoalmente entre 30 a 50 respostas e, depois, a comparar essas etiquetas com as do juiz através do kappa de Cohen, que corrige o acordo devido ao acaso. Uma pontuação de 0 corresponde a um acordo ao nível do acaso, e 1 a um acordo perfeito. Para além de cerca de 0,6, o acordo é geralmente considerado substancial.
RAG, agentes e ciclo de publicação
Um sistema RAG (geração aumentada por recuperação) combina dois componentes que podem falhar separadamente: o motor de busca, que recupera o contexto, e o gerador, que redige a resposta. O guia propõe medir a precisão do contexto, o seu recall, a fidelidade da resposta aos documentos recuperados e a sua pertinência relativamente à pergunta. Uma fidelidade elevada associada a um recall baixo sinaliza, por exemplo, uma pesquisa insuficiente.
Para os agentes, o guia começa pela realização da tarefa, depois examina a exatidão da ferramenta escolhida, a dos seus argumentos e a trajetória seguida, sem chamadas redundantes nem ciclos. As avaliações offline fazem-se antes da colocação em produção, num conjunto de 25 a 50 casos versionado, com critérios de publicação fixados antecipadamente. As avaliações online incidem sobre uma amostra do tráfego real. Cada falha observada em produção pode depois tornar-se um caso de teste de referência.
