Data Annotation 보고서
1. 프로젝트 개요
“스포츠” 라는 주제를 가진 위키피디아 문서(e.g. “유도”, “스키” 등)에서 주체(subject entity)와 객체(object entity), 그리고 두 개체간의 관계(relation)을 태깅하여 하나의 데이터셋을 구성하는 것을 이번 프로젝트 주제로 한다.
2. 프로젝트 수행 절차 및 방법
2.1. 문장추출
문장 추출은 원시 데이터 문서(document) 로부터 2 개 이상의 개체를 추릴 수 있는 문장(sentence) 을 추리는 작업이다. 온점(.)의 뒤에 개행문자(\n)를 붙이는 것으로 문장을 구분하였다. 만약 온점으로 구분되었지만 문장이 생성되지 않는 경우, 뒤에 “~이다”, “~다”와 같이 어미를 붙여주었으며, “앞차기”, “뒷차기” 등과 같이 단어만 나열되는 경우에도 “태권도의 발차기에는 앞차기, 뒷차기가 있다” 와 같이 문장의 형태로 만들어주었다. 또한, “이 것은”과 같이 대명사로 표현된 경우 “사브르는”처럼 대명사가 지칭하는 것을 확실히 해주었다.
2.2. 어노테이션 툴 관리
이는 추출된 문장을 TagTog에서 사용할 수 있도록 세팅하고, 추출된 개체 간 Relation을 설정하는 도구를 개발하는 작업이다. 추출된 문장을 TagTog에 업로드하여 개체와 각 개체들의 타입을 추려내었다. 개체가 태깅된 데이터는 엑셀의 VBA를 활용하여 관계를 태깅할 수 있도록 하였다. 관계를 태깅하면서 동시에 개체를 추출할 때의 오류를 수정할 수 있도록 하였으며, 각 오류를 카테고리화하여 가이드라인 작성 시 자주 발생하는 오류를 쉽게 찾을 수 있도록 하였다.
2.3. 개체 추출
개체 추출은 추출된 문장에서부터 주체와 객체, 총 2개의 개체를 추출하는 작업이다. 타입을 선정할 때에는 한국해양대학교 자연어 처리 연구실의 “한국어 개체명 정의(Definition of Korean Named-Entity Task)를 참조하였다. 스포츠 문서는 주로 경기 규칙, 경기에 사용되는 도구, 기술 등에 관하여 서술하기 때문에 “SPR(스포츠 종목)”과 “EQP(기구, 도구)” 개체를 추가적으로 선정하였다. 모든 개체는 ORG(기관, 단체), PER(인물), LOC(장소), SPR(스포츠 종목), EQP(기구, 도구), POH(고유 명사), DAT(날짜) 7개의 타입 중 하나로 태깅된다.
2.4. 관계 추출
관계추출은 추출된 2개의 개체로부터 두 개체 간의 관계를 추출하는 작업이다. 관계는 크게 (1) 단체중심관계, (2) 종목중심관계, (3) 도구 중심관계, (4) 관계 없음으로 분류된다. 단체 중심 관계는 주체가 기관, 회사, 정당, 국가 등의 단체(ORG)일 때 발생할 수 있는 관계로서 “단체:창립일”, “단체:별칭”, “단체:상위_단체”, “단체:하위_단체”, “단체:창립자” 등이 이에 해당한다. 종목 중심 관계는 주체가 스포츠 종목(SPR)일 경우에 발생할 수 있는 관계로서 “종목:선수”, “종목:상위종목”, “종목:하위종목”, “종목:별칭”, “종목:사용기술”, “종목:사용도구”, “종목:기원” 등이 이에 해당한다. 도구 중심 관계는 주체가 도구(EQP)일 때 발생할 수 있는 관계로서 “도구:기원”, “도구:재료”가 이에 해당한다. “관계_없음”은 주어진 문장에서 개체 쌍이 아무 관계가 없음을 의미한다.
2.5. 태깅 및 가이드라인 제작
이는 개체와 관계를 추출하고 이 과정에서 예외나 오류를 가이드라인에 반영하여 수정하는 작업이다. 두 명이서 한 팀을 구성하여 14개의 문서에서 추출할 수 있는 개체를 선정한 후, 팀원 개개인은 본인이 태깅한 7개 문서를 제외한 모든 문서에 대해 관계를 설정한다. 관계 클래스의 분포 및 오류 코드를 확인하여 가이드라인의 문제점을 파악하고, 팀원들이 자주 틀리게 태깅한 타입에 대해서는 가이드라인에서 그 설명을 더욱 구체화한다.
2.6. 사전 학습
KLUE측에서 사전 학습한 모델을 허깅페이스에 업로드한 것처럼 데이터구축을 하고 다양한 다운스트림 태스크의 비교가 되는 모델을 만들려고 했습니다. 확보한 데이터가 문장단위이므로 Bert의 MLM만을 수행하여 사전학습을 진행했습니다.

3. 프로젝트 한계 및 개선사항
3.1. 관계 설정할 때의 모호함 문제
같은 단어라도 다른 개체로 태깅하거나, 같은 타입이라도 그 태깅 범위가 팀원별로 상이한 경우가 많았다. 이는 가이드 라인에 과하게 의존하여 발생한 팀원 간의 의사소통 부족에서 기인한 문제라 생각한다. 가이드 라인을 작성한 후에, 다 같이 하나의 문서에 대한 어노테이션 작업을 하는 것으로 가이드라인을 제대로 이해했는지 파악하고, 추가로 발생한 오류나 예외에 대해 처리를 **했다면 더욱 명확한 합일점을 찾을 수 있었을 것이다.** (해줬어야 했다.)
3.2. 설명 불가능한 관계와 잘 보이지 않는 관계 문제
가령, “단체:관련 종목”과 같이 두 개체를 특정 관계로 설명할 수 있음에도 불구하고 사전에 관계를 정의해주지 않아 “관계 없음”으로 설정되는 개체쌍이 다수 존재했다. 또한, “도구:기원”은 사전에 관계를 설정했음에도 그 수가 매우 적었다. 관계를 태깅할 때 모든 문서를 대상으로 작업하는 것이 아니라 범위를 지정하고, 해당 범위를 마치면 가이드라인을 수정하고 범위를 점진적으로 증가시키는 작업을 반복해서 수행했다면 이러한 문제를 좀 더 빨리 파악하여 대처할 수 있었을 것이라 생각한다.
4. 프로젝트 팀 구성 및 후기
4.1. 프로젝트 팀 구성 및 역할 (가나다순)

[표 1] 팀원 별 프로젝트 기여표
4.2. 프로젝트 후기 (가나다순)
 고지호(T2007): 딥러닝을 배울 때 많이 소홀히 하는 데이터 제작 부분에 대해 여러 가지를 배움과 동시에 실제 경험을 쌓을 수 있는 좋은 프로젝트였던 것 같습니다. 특히 데이터 제작의 어려움을 체험한 것이 가장 큰 소득이었습니다.
 김민성(T2024): 데이터 구축의 파이프라인을 따라가는 경험을 해볼 수 있었고 사전 학습까지 해볼 수 있어서 좋은 경험이었습니다.
 김범찬(T2031):
 김정현(T2051): 딥러닝에서 가장 중요한 부분이 데이터라고 평소에 생각하고있었는데 직접 학습데이터를 만들어볼 수 있는 좋은 경험이였습니다. 적극적으로 다른 팀원분들에게 많은 도움을 드리지 못해 마음이 편치 않았습니다만 그럼에도 옆에서 응원해주셔서 진심으로 팀원분들께 감사드립니다.
 심현덕(T2125): 항상 데이터가 주어지고 그에 대한 딥러닝 모델 개발에만 초점이 맞춰져 있었습니다. 하지만 이 프로젝트를 통해 어떠한 방향으로 데이터를 제작하면 모델의 성능을 높일 수 있을지에 대해 고민하였고, 차후 현업에 일하게 될 경우에도 데이터를 직접 만들 경우에도 많은 도움이 될 것 같아서 좋았습니다.
 최수홍(T2228): 좋은 데이터는 편향을 없애기 위해 2명 이상의 집단에서 최대한 객관적인 방향으로 가이드라인을 만들고 이를 토대로 만들어진 데이터를 여러번 검수하여 최종적으로 만들어 진다는 것을 느끼게 된것 같습니다. 프로젝트에 필요한 데이터를 만들기 위해 많은 노력이 필요하다는 것을 알게된 경험이었습니다.