A pontuação transforma um benchmark de “analisar o JSON à vista” num número objetivo. O resultado de cada modelo é avaliado com base numa referência de ouro — o resultado esperado — produzindo métricas de integralidade, correção e uma pontuação de qualidade global pela qual pode ordenar.
A pontuação precisa de algo com que comparar. Cada cenário inclui um resultado de referência: a resposta correta para a sua única entidade fixa. Construa-o gerando com modelos fortes (pesquisa web + um documento de fonte de verdade), colando um resultado comprovadamente bom e editando-o depois manualmente — e marque-o como verificado assim que confiar nele. Uma referência verificada é necessária para fazer benchmark do cenário de todo, por isso há sempre algo com que comparar. Se editar posteriormente a referência — ou alterar a configuração de pontuação do cenário — as pontuações existentes são assinaladas como desatualizadas até que volte a pontuar.
A referência também se atualiza a si própria. Uma referência verificada continua a ser um rascunho corrigido à mão, e os modelos que avalia em benchmark são os seus revisores: sempre que o juiz considera a resposta de um candidato melhor do que a da referência (ou a da referência errada), sempre que as amostras do próprio cenário provam que a referência está errada e sempre que um modelo preenche um valor que a referência deixou vazio e o juiz o confirma, o resultado regista uma constatação. No final de cada passagem de pontuação, as constatações de todos os modelos pontuados são consolidadas — primeiro o que as amostras provam, depois a resposta dada pela maioria dos modelos — e escritas na referência. Uma edição já feita por uma passagem só é substituída por evidência mais forte (as amostras, um veredito de que o valor está errado ou mais modelos em concordância — contados ao longo das passagens), nunca pela opinião de mais um modelo, pelo que avaliar os modelos um de cada vez não pode desviar a referência para o último a ser pontuado. Estas edições automáticas nunca marcam as pontuações como desatualizadas (só as suas próprias gravações o fazem) e cada uma delas fica registada com aquilo que substituiu e com os modelos que a originaram.
Reveja-as como registo de alterações: a vista Referência do cenário, ao lado dos respetivos resultados, mostra a própria referência com cada edição automática destacada no sítio onde se encontra — o valor anterior rasurado, o novo, quantos modelos o sustentam e porquê. Tudo é aceite a menos que o rejeite; uma rejeição restaura o valor anterior e mantém esse caminho fora das passagens futuras. Filtre por atributo ou por evidência (as edições de um único modelo são as que merecem atenção), selecione o que está apresentado e rejeite em massa.
O problema central: duas respostas corretas podem ser escritas de forma diferente. Um modelo que nomeia um ator como “R. Downey Jr.” em vez de “Robert Downey Jr.” não está errado. Por isso, cada campo é comparado com uma escada em níveis — primeiro o mais barato e mais certo, escalando apenas quando necessário:
Valores idênticos correspondem. E também valores que diferem apenas em maiúsculas/minúsculas, espaços à volta ou precisão numérica ("Acme" = "ACME", 4.0 = 4). Gratuito e totalmente determinístico.
Para texto, o candidato e a referência são incorporados e comparados por similaridade de cosseno. Acima do limiar, contam como iguais — por isso, uma grafia alternativa válida como «R. Downey Jr.» face a «Robert Downey Jr.» é uma correspondência, não um erro. As datas são a exceção: são comparadas como valores de calendário, nunca por similaridade, pelo que uma data quase-certa mas errada («1972-03-14» face a «1972-03-24») é uma não correspondência clara em vez de um cosseno enganosamente elevado. Os booleanos são, do mesmo modo, exatos ou nada.
Os valores demasiado próximos para decidir por semelhança — todos os campos de texto livre, como resumos e descrições, todos os números não idênticos e um valor claramente diferente que os seus documentos ou a maioria dos outros modelos sustentam — são enviados para um modelo juiz. O juiz é cego: vê os dois valores como A e B, com a posição do campo no schema (os seus pais e respetivas descrições, o seu tipo, a que item de lista pertence) e os seus documentos de origem, quando o cenário tiver algum, e indica qual serve melhor o campo, se ambos estão corretos ou se um está errado. Um candidato considerado equivalente ou melhor do que a referência — ou uma referência considerada errada — obtém crédito total; uma resposta mais fraca obtém crédito parcial e uma resposta errada pouco ou nenhum. Um número obtém crédito parcial quando o campo o tolera (uma massa molecular de 273,37 vs 273,35, uma semivida de 12 vs 15) e falha quando a exatidão é decisiva (um ano de lançamento de 2020 vs 2023). Um valor que a referência deixou vazio é avaliado isoladamente: se for confirmado como correto, conta como um valor que a referência deveria conter e que o modelo encontrou — a pontuação sobe, não fica apenas sem penalização — e a referência passa a adotá-lo.
Uma definição de rigor controla o limiar de embedding: mais elevado significa que dois valores escritos de forma diferente têm de ser mais semelhantes para contarem como iguais. O rigor, o modelo juiz opcional e o modelo de embedding são todos definidos no cenário — e não escolhidos sempre que avalia — para que todos os modelos sejam avaliados de forma idêntica e as pontuações se mantenham comparáveis.
As listas — o elenco de um filme, os efeitos secundários de um medicamento — são onde os modelos mais diferem: um modelo pequeno pode encontrar 4 atores onde um forte encontra 15. A ordem não importa e encontrar mais itens corretos deve prevalecer. Por isso, os arrays são avaliados como um conjunto, e não posição por posição:
Expanda uma linha de resultados para ver exatamente que itens foram correspondidos, ignorados ou alucinados.
Um único número esconde demasiado, por isso cada resultado inclui subpontuações:
A linha expansível mostra a discriminação por campo: candidato vs. referência, qual o degrau da escada que decidiu e a semelhança quando relevante.
A qualidade é apenas um terço da história. Quando um benchmark alimenta a seleção de modelos — enquanto fonte de pontuação —, a posição do modelo resulta da combinação de qualidade, velocidade e custo, e essa proporção é decidida por si: defina-a por tipo de cenário em Definições → Organização → Predefinições, somando 100 em cada caso e repartida de forma equitativa por predefinição. Dê muito peso ao custo e um modelo barato e razoável ultrapassará um excelente mas caro — o que é a resposta certa para algumas cargas de trabalho e a errada para outras, pelo que a plataforma se abstém de decidir por si. A velocidade e o custo são lidos face aos outros resultados do cenário numa escala logarítmica: o modelo mais rápido ou mais barato obtém 100 e um dez vezes mais lento ou mais caro obtém 0, mas um conjunto de valores próximos nunca é esticado para preencher toda a escala — dois modelos a 10 $ e 12 $ ficam em 100 e 92, e não em 100 e 0.
Quando um cenário executa um modelo mais do que uma vez (repetições), cada execução é avaliada individualmente e a linha mostra a qualidade média mais uma dispersão de consistência (mínimo–máximo das execuções) — para que um modelo que está certo em média mas é errático seja fácil de detetar. A saída visível é a execução mediana por qualidade.
Os benchmarks não se limitam ao enriquecimento: um cenário também pode testar a geração de amostras (cada modelo inventa um JSON de exemplo para o mesmo pedido em texto livre) ou a geração de esquemas (cada modelo converte uma amostra fixa num esquema). Cada um tem as suas próprias regras de pontuação:
Em qualquer dos casos, as colunas habituais mantêm o seu significado — passe o cursor sobre um cabeçalho de coluna para ver a definição específica do tipo e expanda uma linha para ver o detalhe completo.
A pontuação é uma passagem separada sobre resultados já guardados — nunca volta a enriquecer, pelo que nunca volta a pagar pelos modelos em teste. Gera embeddings de texto para comparar valores (e executa o juiz, se o cenário tiver um), o que deduz créditos com base na utilização. Isto acontece automaticamente em cada execução — cada modelo é pontuado assim que as suas execuções terminam — e novamente sempre que repontuar. Se a sua organização não tiver um modelo de embeddings configurado (e o cenário não definir uma substituição), a pontuação continua a correr, mas recorre apenas à correspondência exata (grafias alternativas passam a contar como divergências) e indica-o. Um juiz avariado é diferente: se uma chamada ao juiz falhar, a pontuação para com um erro explícito e o modelo afetado não fica com pontuações parciais — um resultado ou está totalmente pontuado ou não está de todo, e pode ser repontuado mais tarde. As respostas do juiz ficam em cache por cenário pelo seu conteúdo: a mesma pergunta levantada por outro modelo, repetição ou passagem nunca é paga duas vezes, e uma repontuação após a referência se ter atualizado só volta a colocar as perguntas nos campos editados. Nada do que o juiz faz fica oculto: cada passagem de pontuação sobre um modelo deixa um registo de pontuação no Histórico — uma linha por chamada do juiz com o respetivo prompt, resposta, tokens e custo, incluindo as chamadas falhadas, além do número de perguntas que a cache respondeu gratuitamente — e a tabela de resultados mostra o custo do juiz, o número de chamadas e o tempo de pontuação de cada modelo, a par de uma ligação para o registo. Ao escolher o juiz, tenha em conta que os juízes LLM podem favorecer a sua própria família de modelos — prefira um juiz de um fornecedor que não esteja a submeter a benchmark.
Em Gestão de modelos → Benchmarks, defina e verifique uma referência no editor de cenários (e escolha aí o modelo de juiz, o modelo de embeddings e o nível de rigor). A partir daí, cada execução pontua automaticamente os seus resultados bem-sucedidos — uma coluna Qualidade ordenável é preenchida sem qualquer passo adicional. Use Repontuar resultados (o botão do cabeçalho ou o menu ···) para reavaliar depois de editar a referência ou a configuração de pontuação. O selo atualizações de referência junto ao estado da referência abre o registo do que as passagens de pontuação alteraram, com reversão por entrada.