Como avaliar uma funcionalidade de produto baseada em modelo de linguagem quando não existe uma única saída correta?

Pergunta em aberto

Um classificador supervisionado vem com uma receita de avaliação: uma divisão de dados reservada para teste (held-out), uma métrica escolhida a partir da decisão, uma matriz de confusão e um intervalo. Uma funcionalidade construída sobre um modelo de linguagem (resumir este ticket, redigir uma resposta, extrair as partes de um contrato, responder a uma pergunta sobre documentos) muitas vezes não tem uma única saída correta, e o modelo por trás dela muda debaixo dos pés da equipe a cada edição de prompt, atualização do provedor ou alteração na recuperação de informação. As equipes montam alguma coisa: algumas centenas de exemplos avaliados à mão, uma rubrica curta, um segundo modelo que avalia o primeiro, contagens de polegares para cima dadas pelos usuários e uma suíte de regressão com prompts que não podem piorar. O que a wiki não registra é qual dessas peças teve peso ao longo do tempo. Quando se usa um modelo avaliador, como se mediu a concordância dele com avaliadores humanos, e ela se manteve estável depois que o próprio modelo do avaliador foi atualizado? A documentação do scikit-learn descreve o kappa de Cohen como uma medida de concordância entre anotadores; algum kappa entre avaliadores humanos, ou entre avaliadores humanos e modelos avaliadores, é reportado em algum lugar, e a partir de que nível uma equipe considera o avaliador confiável? Para funcionalidades do tipo extração, com saída verificável, a equipe recorre à precisão e à revocação usuais por campo, e isso basta? Como os exemplos são escolhidos para que o conjunto não se torne, sem que ninguém perceba, um conjunto dos casos que o prompt atual já resolve? E qual sinal de produção, se algum, variou junto com as notas offline quando uma mudança foi publicada?

O que uma resposta útil contém

O tipo de funcionalidade (texto livre, texto restrito, saída estruturada) e o tamanho e a origem do conjunto rotulado. A rubrica, com cada critério formulado como uma pergunta a que um avaliador consiga responder. A configuração da avaliação: quantos avaliadores humanos, se houve um modelo avaliador e a concordância medida entre eles, com a estatística nomeada e o número de itens. O que aconteceu com a avaliação ao longo de pelo menos duas mudanças de modelo ou de prompt: quais casos regrediram, se a nota offline previu mudanças visíveis para o usuário e o que foi acrescentado ao conjunto depois. O custo em tempo de avaliadores por rodada de avaliação, já que isso decide se o processo sobrevive. Relatos negativos, como um modelo avaliador que concordava com os humanos na primeira versão e passou a divergir depois de uma atualização, são tão úteis quanto os positivos. Relatos de uma única funcionalidade são bem-vindos se o tipo de funcionalidade e o tamanho do conjunto forem informados; comparações entre funcionalidades de uma mesma equipe são mais úteis.