어노테이션 데이터셋 문서화하기: 데이터 스테이트먼트, 데이터시트, 그리고 문서 없는 데이터가 나쁘게 늙는 이유

어노테이션을 끝내고, 레이블을 내보내고, 파일을 넘깁니다. 여섯 달 뒤 누군가 그 데이터로 모델을 훈련하다가 이상한 결과를 얻지만, 문제가 자기 모델에 있는지 여러분의 데이터에 있는지 가려낼 수가 없습니다. 누가 어노테이션했는지, 어떻게 표집했는지, 레이블이 무엇을 뜻하기로 했는지 아무도 적어 두지 않았기 때문입니다. 레이블은 그것을 해석 가능하게 만들어 주던 맥락보다 오래 살아남았습니다. 이런 일은 끊임없이 벌어지고, 프로젝트가 아직 생생할 때 써 둘 수 있었던 문서로 거의 전부 예방할 수 있습니다.

데이터셋은 그 문서만큼만 신뢰받을 수 있습니다. 데이터 스테이트먼트는 수집 근거, 언어와 그 화자, 어노테이터와 그들의 인구통계 정보, 가이드라인, 그리고 사용 목적을 기록하여, 다운스트림 사용자가 레이블이 어디까지 일반화될지, 어디에서는 그러지 못할지 판단할 수 있게 해 줍니다. 나중에 덧붙이지 말고 데이터와 나란히 써 두면, 그 대부분은 여러분이 이미 돌린 어노테이션 프로젝트에서 저절로 떨어져 나옵니다. 이 글은 무엇을 문서화할지, 그리고 Potato 설정이 그중 상당 부분을 이미 어떻게 담아내는지에 관한 것입니다.

문서 없는 데이터가 치르는 비용

두 가지 문제가 나타나고, 둘 다 나중에 값비쌉니다.

첫째는 재현 불가능성입니다. 표집 방법, 가이드라인 버전, 어노테이터 풀이 없으면 아무도 여러분의 데이터셋을 다시 만들거나 그에 대한 불일치를 설명할 수 없습니다. 데이터는 사람들이 맹목적으로 신뢰하거나 아니면 버리는 블랙박스가 됩니다.

둘째는 숨은 편향입니다. 좁은 어노테이터 풀의 레이블로 훈련된 모델은 그 풀의 맹점을 물려받으며, 풀이 문서화된 적 없다면 그 편향은 프로덕션에서 드러날 때까지 보이지 않습니다. 이것이 바로 문서화 프레임워크가 막으려고 발명된 실패입니다. 데이터셋의 누가와 어떻게를 읽을 수 있게 만들어, 편향이 배포되기 전에 보이게 하는 것입니다.

데이터 스테이트먼트가 다루는 것

데이터 스테이트먼트 (Bender and Friedman, 2018)는 NLP에 특화된 답으로, 언어 데이터셋을 특징짓는 스키마입니다. 사용자가 결과가 어떻게 일반화될 수 있는지, 데이터가 어떤 편향을 담고 있는지 이해할 수 있게 해 줍니다. 적어 둘 가치가 있는 부분들은 이렇습니다.

• 수집 근거. 데이터셋에 무엇이, 왜 담겼는지, 항목을 어떻게 표집했는지를 포함합니다. 한 서브레딧에서 고른 표본은 대표성 있게 뽑은 데이터셋과 같지 않으며, 그 점을 밝히는 곳이 바로 근거입니다.
• 언어 변종. 그저 "영어"가 아니라 구체적인 언어와 방언입니다. 한 변종으로 만든 모델은 다른 변종에서 실패할 수 있습니다.
• 화자 인구통계 정보. 원본 텍스트를 누가 만들었는가.
• 어노테이터 인구통계 정보. 레이블을 누가 만들었는가. 주관적 과제에서는 이것이 결정적입니다. 어노테이터 풀의 구성이 레이블을 좌우하기 때문이며, 이것이 애초에 인구통계 정보를 수집하는 이유 전부입니다.
• 어노테이션 가이드라인. 레이블이 만들어진 지침입니다. 같은 레이블 이름도 가이드라인이 다르면 다른 것을 뜻합니다.
• 사용 목적. 데이터셋이 무엇을 위한 것인지, 그리고 그에 못지않게 유용하게, 무엇을 위한 것이 아닌지.

데이터 스테이트먼트는 누가와 어떻게를 기록하여, 다운스트림 사용자가 레이블이 어디까지 일반화될지 판단하게 한다

데이터시트와 모델 카드

이웃한 두 프레임워크가 이것을 마저 채웁니다. 데이터셋을 위한 데이터시트 (Gebru et al.)는 이 발상을 전자 산업에서 빌려 옵니다. 그곳에서는 모든 부품이 데이터시트와 함께 출고됩니다. 모든 데이터셋도 그 동기, 구성, 수집 과정, 권장 용도, 유지 관리를 다루는 문서와 함께 출고되어야 한다는 것입니다. 데이터 스테이트먼트는 언어에 특화된 사촌이고, 데이터시트는 범용 버전이며, 둘은 크게 겹칩니다.

데이터의 하류에는 모델 카드 (Mitchell et al., 2019)가 있습니다. 훈련된 모델의 사용 목적과, 인구통계 및 여타 집단별로 쪼갠 성능을 문서화합니다. 이 셋은 하나의 사슬을 이룹니다. 데이터시트나 데이터 스테이트먼트는 데이터를 문서화하고, 모델 카드는 그 위에 무엇을 지었는지를 문서화하며, 앞엣것의 어노테이터 인구통계 정보 섹션이 뒤엣것의 집단별 평가를 해석 가능하게 만들어 줍니다. 어노테이션을 잘 문서화하면 이미 방어 가능한 모델 카드의 절반은 온 셈입니다.

배포 체크리스트

배포하기 전에, 다음에 답할 수 있는지 확인하십시오.

• 항목은 어떻게, 어디에서 표집되었는가?
• 이것은 어떤 언어 변종이며, 원본 텍스트는 누가 썼는가?
• 누가 어노테이션했고, 몇 명이며, 그 풀의 인구통계 구성은 어떠한가?
• 그들은 어떤 가이드라인을 따랐으며, 어느 버전이었는가?
• 불일치는 어떻게 다루었는가, 골드 레이블로 집계했는가 아니면 분포로 지켰는가? 어느 쪽이든 일치도를 보고하라.
• 이 데이터셋은 무엇을 위한 것이며, 무엇에는 쓰이지 말아야 하는가?

어떤 질문에 답이 없다면, 그것은 배포 후가 아니라 배포 전에 메워야 할 빈틈입니다.

Potato에서 처리하기

Potato에서 어노테이션을 돌리는 것의 쓸모는, 데이터 스테이트먼트의 상당 부분이 이미 프로젝트 산출물로 존재한다는 점입니다. 여러분은 빈 페이지에서 문서화를 시작하지 않습니다.

설정이 곧 문서입니다. YAML은 어노테이션 스킴, 레이블 세트, 과제 구조를 기록하므로, 데이터 스테이트먼트의 "레이블이 무엇이었고 어떻게 정의되었나" 부분이 데이터와 나란히 버전 관리됩니다. 여러분이 어노테이션 가이드라인에 써 넣은 지침과 안내는 그대로 가이드라인 섹션이 됩니다.

인구통계 정보는 이미 수집되어 있습니다. 사전연구 단계를 돌렸다면, 어노테이터 인구통계 정보가 어노테이터별로 저장됩니다. 개별 기록이 아니라 분포로 집계하면, 그것이 곧 어노테이터 인구통계 정보 섹션이며, 붙여 넣을 준비가 되어 있습니다.

내보내기가 메타데이터를 실어 나릅니다. Potato의 내보내기 형식은 모든 레이블에 어노테이터와 타임스탬프를 유지하므로, 출처가 내보내기 단계에서 벗겨져 나가지 않고 데이터와 함께 이동합니다.

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

Hub에 게시할 때는, HuggingFace로 내보내기 안내가 보여 주듯 내보내기의 일부로 데이터셋 카드를 생성하고, 이미 가진 설정, 가이드라인, 사전연구 인구통계 정보로 그 섹션들을 채우십시오. 문서화는 별개의 글쓰기 프로젝트이기를 멈추고, 어노테이션 작업의 마지막 단계가 됩니다.

다음으로 볼 곳

• 어노테이터 인구통계 정보를 책임감 있게 수집하기, 어노테이터 인구통계 정보 섹션을 제대로 하는 법.
• 불일치는 잡음이 아니라 신호다, 불일치를 어떻게 다루었는지 문서화하는 법.
• 효과적인 어노테이션 가이드라인 작성하기, 데이터 스테이트먼트의 가이드라인 섹션 노릇도 합니다.
• ML을 위한 어노테이션 내보내기, 레이블과 그 메타데이터를 깔끔하게 빼내는 법.