JwumaComo escrever uma rúbrica de anotação que resista ao contato com a realidade
· 3 min de leitura · specification, quality
Esta tradução foi produzida por máquina e não foi verificada por um falante nativo. Em caso de dúvida, a versão em inglês é a original. Diga-nos se algo estiver errado e corrigiremos. English
Uma boa rúbrica dedica a maior parte do seu comprimento aos casos extremos em vez das definições, porque os anotadores raramente discordam sobre casos claros. Congele-a quando um lote começar para que o padrão não mude durante o projeto, e trate toda ambiguidade sinalizada por um anotador como um defeito da rúbrica, e não como uma falha do anotador.
Em resumo
- A discordância entre anotadores concentra-se quase inteiramente nos casos extremos.
- Uma rúbrica deve ser congelada quando um lote começa e versionada a partir de então.
- Cada rótulo deve ser rastreável até a versão da rúbrica que o produziu.
- Ambiguidade sinalizada é um defeito da rúbrica, não uma falha do anotador.
- Uma rúbrica alterada no meio do lote invalida a comparação dentro desse lote.
Está a definir algo assim?
Preferimos falar do problema em vez de orçamentar por volume.
Ver capacidadesPor que as rúbricas falham?
Quase nunca porque as definições estão erradas. Elas falham porque as definições estão corretas e os casos extremos estão ausentes, então vinte anotadores inventam independentemente vinte respostas diferentes para a mesma questão não abordada.
O sintoma mais comum são pontuações de concordância que parecem aceitáveis no geral, enquanto uma parte específica dos dados é silenciosamente inútil. A concordância agregada esconde isso bem.
Quanto da rúbrica deve ser de casos extremos?
A maior parte. Se a sua rúbrica é principalmente definições com uma curta seção de exemplos no final, é um glossário em vez de uma rúbrica.
A maneira produtiva de escrever uma é executar um pequeno lote piloto com uma rúbrica subespecificada, coletar cada caso que um anotador sinaliza como ambíguo e transformá-lo em uma regra explícita. O propósito do piloto é encontrar as perguntas, não produzir dados.
Por que congelar a rúbrica?
Porque se o padrão mudar no meio do lote, o trabalho concluído corretamente sob a definição antiga torna-se retroativamente errado, e você não pode dizer a partir do conjunto de dados quais itens foram julgados sob qual versão.
Congelar significa que a versão em vigor quando um lote é aberto governa esse lote. As melhorias aplicam-se ao próximo. Cada rótulo então carrega a versão que o produziu, o que torna um conjunto de dados auditável um ano depois, quando alguém pergunta por que dois itens semelhantes estão rotulados de forma diferente.
Como deve ser tratada a ambiguidade sinalizada?
Como um relatório de defeito sobre a sua rúbrica, que é o que realmente é. Um anotador que sinaliza em vez de adivinhar fez exatamente a coisa certa e nunca deve ser penalizado por isso.
Plataformas que penalizam a sinalização recebem menos sinalizações e dados piores, porque a ambiguidade não desaparece, apenas é resolvida silenciosa e inconsistemente onde ninguém pode vê-la.
Outras perguntas
O que torna uma rúbrica de anotação boa?
Tratamento explícito de casos extremos. Os anotadores raramente discordam sobre exemplos claros, então uma rúbrica que é principalmente definições e poucos casos extremos produzirá rótulos inconsistentes.
Uma rúbrica deve ser alterada no meio do projeto?
Não. Congele-a quando o lote começar para que o padrão não mude, e aplique melhorias ao próximo lote. Caso contrário, o trabalho concluído corretamente torna-se retroativamente errado.
O que deve acontecer quando um anotador sinaliza um caso ambíguo?
Deve ser tratado como um defeito na rúbrica e resolvido explicitamente. Penalizar a sinalização simplesmente empurra a ambiguidade para o subterrâneo, onde é resolvida de forma inconsistente.