Pontuação de Benchmark - Documentação do Entity Enricher

Pontuação de Benchmark

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 referência de ouro

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.

Como os valores são comparados

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:

1
Exato e normalizado

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.

2
Similaridade de embedding

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.

3
Juiz LLM

Os valores demasiado próximos para distinguir por similaridade — todos os campos de texto livre, como resumos e descrições, e todos os números não idênticos — são enviados a um modelo juiz, que atribui uma nota de 0 a 100 consoante o quão bem a resposta capta o significado da referência. Recompensa uma resposta correta formulada de forma diferente ou mais breve, e concede crédito parcial a um número quando o campo o tolera (um peso molecular de 273,37 vs 273,35, uma semivida de 12 vs 15), embora ainda o reprove quando a exatidão importa (um ano de lançamento de 2020 vs 2023). Sem um juiz, o texto livre recorre a uma pontuação de similaridade contínua, e um número não idêntico é simplesmente uma discrepância.

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.

A pontuar arrays (listas de itens)

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.

Ler a pontuação

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.

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.

Custo e o que é executado

A pontuação é uma passagem separada sobre resultados já guardados — nunca volta a enriquecer, pelo que nunca volta a pagar pelos modelos em teste. Incorpora texto para comparar valores (e executa o avaliador, se o cenário tiver um), o que deduz créditos com base na utilização. Isto acontece automaticamente no final de cada execução e, novamente, sempre que voltar a pontuar. Se a sua organização não tiver um modelo de incorporação configurado (e o cenário não definir uma substituição), a pontuação continua a ser executada, mas recorre apenas à correspondência exata (as grafias alternativas passam então a contar como discrepâncias), e indica-o.

Onde encontrá-lo

Em Gestão de models → Benchmarks, defina e verifique uma referência no editor de scenarios (e escolha aí o seu model de juiz, o model de embedding e o 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 Voltar a pontuar resultados (o botão do cabeçalho ou o menu ···) para reavaliar após editar a referência ou a configuração de pontuação.