JwumaCómo escribir una rúbrica de anotación que sobreviva al contacto con la realidad
· 3 min de lectura · specification, quality
Esta traducción fue generada por una máquina y no ha sido revisada por un hablante nativo. Ante cualquier duda, la versión en inglés es la original. Avísanos si algo está mal y lo corregiremos. English
Una buena rúbrica dedica la mayor parte de su extensión a los casos límite en lugar de las definiciones, porque los anotadores rara vez discrepan sobre los casos claros. Congélela cuando comienza un lote para que el estándar no pueda cambiar a mitad del proyecto, y trate cada ambigüedad que un anotador señale como un defecto de la rúbrica en lugar de un error del anotador.
En resumen
- La discrepancia entre anotadores se concentra casi por completo en los casos límite.
- Una rúbrica debe congelarse cuando comienza un lote y versionarse a partir de entonces.
- Cada etiqueta debe ser rastreable a la versión de la rúbrica que la produjo.
- La ambigüedad señalada es un defecto de la rúbrica, no un error del anotador.
- Una rúbrica cambiada a mitad de lote invalida la comparación a lo largo de ese lote.
¿Estás definiendo algo así?
Preferimos hablar del problema antes que cotizar por volumen.
Ver capacidades¿Por qué fallan las rúbricas?
Casi nunca porque las definiciones estén mal. Fallan porque las definiciones están bien y los casos límite están ausentes, por lo que veinte anotadores inventan de manera independiente veinte respuestas diferentes a la misma pregunta no abordada.
El síntoma más común son las puntuaciones de acuerdo que parecen aceptables en general mientras que una parte específica de los datos es silenciosamente inútil. El acuerdo agregado lo oculta bien.
¿Cuánto de la rúbrica deben ser casos límite?
La mayor parte. Si su rúbrica es principalmente definiciones con una breve sección de ejemplos al final, es un glosario en lugar de una rúbrica.
La forma productiva de escribir una es ejecutar un pequeño lote piloto con una rúbrica poco especificada, recopilar cada caso que un anotador señale como ambiguo y convertir cada uno en una regla explícita. El propósito del piloto es encontrar las preguntas, no producir datos.
¿Por qué congelar la rúbrica?
Porque si el estándar cambia a mitad de lote, el trabajo completado correctamente bajo la antigua definición se vuelve retroactivamente incorrecto, y no se puede saber a partir del conjunto de datos qué elementos fueron juzgados bajo qué versión.
Congelar significa que la versión en vigor cuando se abre un lote gobierna ese lote. Las mejoras se aplican al siguiente. Cada etiqueta lleva entonces la versión que la produjo, lo que hace que un conjunto de datos sea auditable un año después cuando alguien pregunta por qué dos elementos similares están etiquetados de manera diferente.
¿Cómo se debe manejar la ambigüedad señalada?
Como un informe de defecto sobre su rúbrica, que es lo que es. Un anotador que señala en lugar de adivinar ha hecho exactamente lo correcto y nunca debe ser penalizado por ello.
Las plataformas que penalizan el señalamiento obtienen menos señalamientos y peores datos, porque la ambigüedad no desaparece, simplemente se resuelve de manera silenciosa e inconsistente donde nadie puede verla.
También preguntan
¿Qué hace que una rúbrica de anotación sea buena?
El manejo explícito de los casos límite. Los anotadores rara vez discrepan sobre ejemplos claros, por lo que una rúbrica que es principalmente definiciones y pocos casos límite producirá etiquetas inconsistentes.
¿Debe cambiarse una rúbrica a mitad de proyecto?
No. Congélela cuando comience el lote para que el estándar no pueda cambiar, y aplique mejoras al siguiente lote. De lo contrario, el trabajo completado correctamente se vuelve retroactivamente incorrecto.
¿Qué debe suceder cuando un anotador señala un caso ambiguo?
Debe tratarse como un defecto en la rúbrica y resolverse explícitamente. Penalizar el señalamiento simplemente empuja la ambigüedad a un lugar oculto donde se resuelve de manera inconsistente.