Data제작을 하면서 느낀점

부스트캠프에서 데이터 제작 프로젝트를 하였는데, 사실 나한테 정말 필요하고 나의 목표에 다가가기 위해 필요한 과정일까 , 이 코스가 아니면 할 수 없는 일인가를 생각해 보았습니다. 솔직히 말하자면, 1차 산출물 이후 할 필요는 없다고 느꼇습니다. 피드백을 1차 산출물을 이후 제공받지 않았기 때문에  , 할 필요 없다고 느꼈습니다. 2차 피드백을 받지 못한다면, 우물 안의 개구리 에 불과하기 때문에 , 이 과제를 통해서 어떤 점이 성장할 수 있을까라는 의문이 들었습니다.  그리고  이것을 benchmark로 제공해줄 만큼 quality에 자신이 없었기에 , 모든 text 파일에 대해 제작을 하는 과정은 불필요하다고 느꼇습니다. 따라서 , iaa,klue fine tuning 보다는  GuideLine을 작성하는 협업에 중점을 두어서 Data 제작 프로젝트에 임하였습니다. 데이터를 제작하면서 신경썻던 부분을 세션에서 여러 캠퍼분들이 공유해주신 부분들과 저희가 고려했던 부분을  소개해보도록 하겠습니다.

 

1.Granuality

 

세부성 , 영어로 granuality 라고 합니다. 어떻게, granulaity가 잘 정의 되는가가 일관성 있는 annotation을 할 수 있다고 pilot tagging을 하면서 느꼇습니다.  예시를 들어보겠습니다.

 

Ex)

Q2. 구성 요소, 연관대상, 특징 Entity는 어떻게 구별할까요?

1. 구별을 위한 의사 결정 방식을 제안합니다.
   1. Subj ,Obj 가 상하위 개념의 관계가 아니면 특징으로 분류한다.

 

-   <subject:금성>은 지구형 행성 중에서 <object:가장 농밀한 대기>를 가지고 있다.
→ “대상:특징”

-  일반적으로 <subject:행성>은, 어떤 항성의 기원이 되는 성운이 붕괴하였을 때 원시성 둘레를 돌게 된 <object:기체>와 먼지가 모여 생겨난 것으로 알려져 있다. → “대상:구성_요소”

 

2. 상하위 개념이 있으나 ‘구성된다’, ‘이루어진다’ ,’융합된다’, ‘형성된다’와 같은 내용이 있다면 연관 대상이 아닌 구성 요소로 봅니다.

 

• "다른 항성을 흡수하거나 <subject:블랙홀>들끼리 융합하면서 수백만 M☉에 달하는 <object:초대질량 블랙홀>이 형성될 수 있으며, 대부분의 은하의 중심에는 초대질량 블랙홀이 존재한다는 것이 과학계의 일반적인 견해이다. → “대상:구성_요소”
• <subject:목성>목성은 주로 <object:기체> 및 액체 물질로 이루어져 있다. → “대상:구성_요소”
• <object:우주>에서 가장 밝은 천체인 <subject:퀘이사>는 이러한 과정을 통해 만들어진다." → “대상:연관_대상”

• <subject:토성>(土星, 라틴어: Saturnus)은 <object:태양>으로부터 여섯번째에 있는 태양계의 한 행성이다. → “대상:연관_대상”

 

3. 구성 요소로 ‘여겨진다.’, ‘추정되어진다’ 같이 확실하지 않은 경우라 할지라도 구성 요소로 특정한다.

 

• 정확한 성질에 관해서는 아직까지 불확실하지만 <subject:목성 구름>의 실체는 <object:인>, 황 또는 아마 탄화수소일 것으로 여겨진다. → “대상:구성_요소”

저희가 작성했던 GuideLine의 일부입니다. 

 

이 외에도 , 다른 조에서는 '마블' dataset을 다루었는데 , '타노스'가 인류를 멸망시켯는가 '타노스의 핑거스냅'이 멸망을 시켯는가에 대해서도 구분을 하셧고, '도적'도 '생계형 도적'인가 '비생계형 도적'인가 를 구분 하셧다고 합니다.

 

 

2.Document

 

Document 의 이슈도 있었습니다.  '축구' 관련 Data를 다루신 조에는 '첼시'에 관한 문서인데 , '첼시 FC' 보다는 '첼시' 도시의 공업에 관해 적혀있었다고 합니다. 이는 ,  '축구'주제와 벗어나기에 지우고 새로 웹에서 크롤링을 하였다고 합니다. Document에  domain이 통일 되어있는지를 확인하는것도 상당히 중요하다고 느꼇습니다.

 

3 . 문장 내의 관계로만 mapping

 

'토트넘', '아스날' 두 클럽은 라이벌 관계입니다. EPL  팬이라면 다 알만한 사실입니다. 하지만, 문장안에 '토트넘','아스널'이 동시에 주어졌을때 , 사전 지식으로 mapping을 하게 된다면 '토트넘' '아스날'은 '라이벌' 관계이지만, '라이벌' 관계라는 언급이 passage안에 주어지지 않았다면, '동등관계' 로 mapping을 하는것이 맞을겁니다. 하지만, 저는 이것에 대해서 잘은 모르겠습니다. '토트넘', '아스날' 이라는 단어를 해외축구 팬이 검색을 한다면 '라이벌'이라는 관계를 원할 것이기 때문입니다. 저는 이 부분은 여러 조건들을 따져서, 문장내의 지식으로 mapping 할지 안할지 정하는 기술이 필요하다고 느꼇습니다.

 

 

아쉬웠던 점

1. 엑셀시트로 작업시 한계점

엑셀 시트로 작업시 드롭박스를 이용해서 pilot tagging을 진행하였는데 , 이 때 드롭박스를 이용해서 진행시 '잘못 클릭'해서 'miss labeling'이 발생할 확률이 높았습니다. 따라서, '자동완성' 기능으로 속도는 좀 느리지만, 정확성을 올리는것도 상황에 따라 고려해볼만한 선택지라고 생각했습니다.

 

 

2. tagtog의 annotation 정렬

tagtag 툴을 이용해서 작업을 진행하게 된다면, tagtog 의 result를 ann.json 파일을 통해 받을 수 있는데 , 이는 relation 을 기준으로 정렬이 되어있습니다. labeling 작업을 하다가 같은 라벨로 뭉텅이로 밀어버려서(드래그 & 드롭 기능) tagging을 진행할 수 있습니다. 이렇게 되면, guideline을 기준으로 라벨링 할 때 guidline을 잘 안읽고 할 수 있기 때문에 , guideline에서 문제점을 못 찾을 수 있습니다. 따라서, 기업 입장에서는 이렇게 작성된 guideline에 대한 quality를 신뢰할 수 없게 됩니다. 따라서, tagging 작업을 하기전에 전부 shuffle을 해야 guideline의 quality를 올릴 수 있는 기회가 더 많이 제공이 되어진다고 생각했습니다.