Documentar tu conjunto de datos de anotación: declaraciones de datos, hojas de datos y por qué los datos sin documentar envejecen mal

Terminas la anotación, exportas las etiquetas y entregas un archivo. Seis meses después alguien entrena un modelo con él, obtiene un resultado extraño y no puede saber si el problema es su modelo o tus datos, porque nadie anotó quién los etiquetó, cómo se muestrearon ni qué se suponía que significaban las etiquetas. Las etiquetas sobrevivieron al contexto que las hacía interpretables. Esto pasa constantemente, y es casi enteramente evitable con documentación que podrías haber escrito mientras el proyecto estaba fresco.

Un conjunto de datos es solo tan confiable como su documentación. Una declaración de datos (data statement) registra el motivo de la curación, la lengua y sus hablantes, los anotadores y sus datos demográficos, las directrices y el uso previsto, para que quienes lo usen aguas abajo puedan juzgar cómo generalizarán las etiquetas y dónde no. Escríbela junto con los datos, no como una ocurrencia tardía, y la mayor parte se desprende del proyecto de anotación que ya ejecutaste. Esta entrada trata de qué documentar y de cómo la configuración de Potato ya captura buena parte de ello.

Lo que te cuestan los datos sin documentar

Aparecen dos problemas, y ambos salen caros más adelante.

El primero es la irreproducibilidad. Sin el método de muestreo, la versión de las directrices y el grupo de anotadores, nadie puede reconstruir tu conjunto de datos ni explicar una discrepancia frente a él. Los datos se vuelven una caja negra en la que la gente confía a ciegas o descarta.

El segundo es el sesgo oculto. Un modelo entrenado con etiquetas de un grupo estrecho de anotadores hereda los puntos ciegos de ese grupo, y si el grupo nunca se documentó, el sesgo es invisible hasta que aflora en producción. Este es justamente el fallo que los marcos de documentación se inventaron para prevenir: hacer legibles el quién y el cómo de un conjunto de datos para que los sesgos puedan verse antes de que se publique.

Qué cubre una declaración de datos

La declaración de datos (Bender y Friedman, 2018) es la respuesta específica del PLN, un esquema para caracterizar un conjunto de datos lingüístico de modo que quienes lo usen entiendan cómo pueden generalizar los resultados y qué sesgos cargan los datos. Las partes que vale la pena anotar:

• Motivo de la curación. Qué hay en el conjunto de datos y por qué, incluido cómo se muestrearon los ítems. Una muestra tomada de un solo subreddit no es el mismo conjunto de datos que una extracción representativa, y el motivo es donde lo dices.
• Variedad lingüística. La lengua y el dialecto específicos, no solo «inglés». Un modelo construido sobre una variedad puede fallar en otra.
• Datos demográficos del hablante. Quién produjo el texto fuente.
• Datos demográficos del anotador. Quién produjo las etiquetas. En tareas subjetivas esto es decisivo, porque la composición del grupo de anotadores moldea las etiquetas, que es todo el argumento para recopilar datos demográficos en primer lugar.
• Directrices de anotación. Las instrucciones bajo las que se produjeron las etiquetas. El mismo nombre de etiqueta significa cosas distintas bajo directrices distintas.
• Uso previsto. Para qué sirve el conjunto de datos y, con la misma utilidad, para qué no sirve.

Una declaración de datos registra el quién y el cómo, para que quienes usen los datos aguas abajo puedan juzgar dónde generalizan las etiquetas

Hojas de datos y tarjetas de modelo

Dos marcos vecinos completan esto. Las hojas de datos para conjuntos de datos (Gebru et al.) toman prestada la idea de la industria electrónica, donde cada componente se envía con una hoja de datos: todo conjunto de datos debería enviarse con un documento que cubra su motivación, composición, proceso de recopilación, usos recomendados y mantenimiento. Las declaraciones de datos son la prima específica de la lengua; las hojas de datos son la versión de propósito general, y ambas se solapan mucho.

Aguas abajo de los datos está la tarjeta de modelo (Mitchell et al., 2019), que documenta el uso previsto de un modelo entrenado y su rendimiento desglosado por grupos demográficos y de otros tipos. Los tres forman una cadena: una hoja de datos o declaración de datos documenta los datos, una tarjeta de modelo documenta lo que se construyó sobre ellos, y la sección de datos demográficos del anotador de la primera es lo que hace interpretable la evaluación por grupos de la última. Documenta bien la anotación y ya estarás a mitad de camino de una tarjeta de modelo defendible.

Una lista de verificación para la publicación

Antes de publicar, confirma que puedes responder:

• ¿Cómo se muestrearon los ítems, y de dónde?
• ¿Qué variedad lingüística es esta, y quién escribió el texto fuente?
• ¿Quién lo anotó, cuántas personas, y cuál es la composición demográfica del grupo?
• ¿Qué directrices siguieron, y qué versión?
• ¿Cómo se manejó el desacuerdo, agregado a una etiqueta de referencia o conservado como distribución? Informa el acuerdo de cualquier manera.
• ¿Para qué sirve este conjunto de datos, y para qué no debería usarse?

Si una pregunta no tiene respuesta, esa es una brecha que cerrar antes de publicar, no después.

Hacerlo en Potato

Lo útil de ejecutar la anotación en Potato es que buena parte de la declaración de datos ya existe como artefactos del proyecto. No empiezas la documentación desde una página en blanco.

La configuración es documentación. El YAML registra los esquemas de anotación, los conjuntos de etiquetas y la estructura de la tarea, de modo que la parte de «cuáles eran las etiquetas y cómo se definieron» de una declaración de datos queda bajo control de versiones junto con los datos. Las instrucciones y directrices que escribiste en las directrices de anotación son la sección de directrices, tal cual.

Los datos demográficos ya están recopilados. Si ejecutaste una fase de preestudio, los datos demográficos del anotador se almacenan por anotador. Agregados en distribuciones, nunca registros individuales, son la sección de datos demográficos del anotador, lista para pegar.

La exportación lleva los metadatos. Los formatos de exportación de Potato mantienen el anotador y la marca de tiempo en cada etiqueta, así que la procedencia viaja con los datos en vez de perderse en el paso de exportación:

{
  "id": "doc_001",
  "annotations": { "sentiment": "positive" },
  "annotator": "user_1",
  "timestamp": "2024-01-15T10:30:00Z"
}

Cuando publiques en el Hub, genera una tarjeta de conjunto de datos como parte de la exportación, como muestra el tutorial de exportar a HuggingFace, y rellena sus secciones desde la configuración, las directrices y los datos demográficos del preestudio que ya tienes. La documentación deja de ser un proyecto de escritura aparte y se convierte en el último paso del de anotación.

Adónde ir después

• Recopilar datos demográficos de los anotadores de forma responsable, para hacer bien la sección de datos demográficos del anotador.
• El desacuerdo es señal, no ruido, para documentar cómo manejaste el desacuerdo.
• Escribir directrices de anotación eficaces, que sirven a la vez como la sección de directrices de una declaración de datos.
• Exportar anotaciones para aprendizaje automático, para sacar las etiquetas y sus metadatos de forma limpia.