Documentar conjuntos de datos y modelos: fichas técnicas, declaraciones de datos y tarjetas de modelo
Una referencia sobre los tres marcos estándar de documentación para datos anotados y los modelos que se construyen a partir de ellos: qué cubre cada uno, cuándo usar cuál y cómo la información de reproducibilidad los conecta.
Tres estándares de documentación se han convertido en la norma para los datos de aprendizaje automático: las declaraciones de datos y las fichas técnicas para el conjunto de datos, y las tarjetas de modelo para lo que entrenas con él. Se solapan mucho y ninguno es opcional si quieres que los datos se consideren fiables y se reutilicen. Esta guía es una referencia sobre qué cubre cada uno y cuándo recurrir a él. Para un recorrido narrado sobre cómo redactar uno, consulta la publicación complementaria sobre cómo documentar tu conjunto de datos de anotación; esta página es la comparación de estándares.
Por qué documentación estructurada y no un README
Un conjunto de datos anotado sin documentación envejece mal. Seis meses después, nadie puede decir cómo se muestreó, quién lo etiquetó ni qué se suponía que significaba una etiqueta, de modo que los datos se convierten en una caja negra en la que la gente confía ciegamente o que descarta. Se repiten dos costes concretos: la irreproducibilidad (no puedes reconstruir el conjunto de datos ni explicar una discrepancia sin el método de muestreo, la versión de las directrices y el grupo de anotadores) y el sesgo oculto (las etiquetas de un grupo reducido y no documentado arrastran puntos ciegos que permanecen invisibles hasta que aparecen en producción). Los marcos que siguen existen para hacer legibles el quién y el cómo antes de que cualquiera de los dos cause problemas.
Los tres estándares
Cada marco apunta a un artefacto y a un público distintos, pero se diseñaron para encajar entre sí.
Las declaraciones de datos (Bender and Friedman, 2018) son el esquema específico del PLN. Caracterizan un conjunto de datos lingüístico, la justificación de la curación, la variedad lingüística y sus hablantes, la demografía de los anotadores, las directrices y el uso previsto, de modo que un lector pueda juzgar cómo se generalizarán los resultados y a qué poblaciones infrarrepresentan los datos. Recurre a una declaración de datos cuando los datos son texto y la variedad lingüística importa.
Las fichas técnicas para conjuntos de datos (Gebru et al., 2021) son la versión de propósito general, tomada de la electrónica, donde cada componente se entrega con una ficha técnica. Plantean un conjunto de preguntas estándar sobre motivación, composición, proceso de recopilación, preprocesamiento, usos recomendados y mantenimiento. Usa una ficha técnica para cualquier conjunto de datos de aprendizaje automático, sea texto o no; se solapa mucho con una declaración de datos, así que en un conjunto de datos lingüístico en realidad estás eligiendo en torno a qué conjunto de preguntas organizarte, no haciendo ambos desde cero.
Las tarjetas de modelo (Mitchell et al., 2019) documentan el modelo, no los datos: su uso previsto y, sobre todo, su rendimiento desglosado por grupos demográficos y de otro tipo, en lugar de como una única cifra agregada. Una tarjeta de modelo es donde se hace visible un problema de equidad.
Los tres forman una cadena. Una ficha técnica o una declaración de datos documenta los datos; una tarjeta de modelo documenta lo que se construyó a partir de ellos; y la sección de demografía de los anotadores del primero es precisamente lo que hace interpretable la evaluación por grupos del último. Documenta bien la anotación y ya tendrás gran parte del camino recorrido hacia una tarjeta de modelo defendible.
| Marco | Documenta | Ideal para | Secciones clave |
|---|---|---|---|
| Declaración de datos | Un conjunto de datos lingüístico | Datos de PLN / texto | Justificación de la curación, variedad lingüística, demografía de hablantes y anotadores, directrices |
| Ficha técnica | Cualquier conjunto de datos de ML | Datos de ML en general | Motivación, composición, recopilación, usos, mantenimiento |
| Tarjeta de modelo | Un modelo entrenado | Cualquier modelo publicado | Uso previsto, evaluación desglosada, limitaciones |
La reproducibilidad es la cuarta pata
Documentación y reproducibilidad son el mismo objetivo desde dos ángulos. Pineau et al. (2021) informaron sobre el programa de reproducibilidad de NeurIPS y lo condensaron en una lista de verificación de reproducibilidad: declara los datos exactos, los pasos de recopilación y preprocesamiento, la configuración de evaluación y suficiente detalle para volver a ejecutar el trabajo. Para un proyecto de anotación en concreto, los datos críticos para la reproducibilidad son los que una ficha técnica ya pide: cómo se muestrearon los elementos, qué versión de las directrices se usó, quién anotó y cómo se gestionó el desacuerdo. Si puedes responder a eso, el conjunto de datos está documentado y es reproducible; si no puedes, esa es una brecha que hay que cerrar antes de la publicación, no después.
Una lista de verificación para la publicación
Antes de publicar, confirma que puedes responder:
- ¿Cómo se muestrearon los elementos y de dónde?
- ¿Qué variedad lingüística es esta y quién escribió el texto original?
- ¿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?
- ¿El desacuerdo se agregó en una etiqueta de referencia o se conservó como una distribución? Informa del acuerdo en cualquier caso.
- ¿Para qué sirve este conjunto de datos y para qué no debería usarse?
Cómo hacerlo en Potato
La mayor parte de la documentación de un conjunto de datos ya existe como artefactos del proyecto, así que no partes de una página en blanco. La configuración es documentación: el YAML registra los esquemas, los conjuntos de etiquetas y la estructura de la tarea, con control de versiones junto a los datos, y las instrucciones que escribiste son la sección de directrices al pie de la letra. Si ejecutaste una fase de estudio previo, la demografía de los anotadores ya está almacenada por anotador; agrégala en distribuciones para la sección de demografía de los anotadores. Y la exportación conserva el anotador y la marca de tiempo en cada etiqueta, de modo que la procedencia viaja con los datos en lugar de eliminarse:
{
"id": "doc_001",
"annotations": { "sentiment": "positive" },
"annotator": "user_1",
"timestamp": "2024-01-15T10:30:00Z"
}Cuando publiques en el Hub, genera la tarjeta del conjunto de datos como último paso de la exportación y completa sus secciones a partir de la configuración, las directrices y la demografía del estudio previo que ya tienes.
Lecturas adicionales
- Cómo documentar tu conjunto de datos de anotación, el recorrido narrado con una declaración de datos trabajada.
- Cómo recopilar la demografía de los anotadores de forma responsable, para hacer bien la sección de demografía de los anotadores.
- Cómo redactar directrices de anotación, que sirven a la vez como sección de directrices.
- Cómo exportar anotaciones para ML, para obtener etiquetas y metadatos de forma limpia.