[WEEK09/10/11] 문장 내 개체간 관계 추출(Relation Extraction, RE) 대회 Wrap-up 및 회고
멘토링에서도 여러번 말씀드렸지만 딥러닝 프로젝트는 어떤 데이터, 어떤 방법론을 사용하더라도 아래의 프로세스를 따라 정의됩니다.
“데이터 처리 (데이터 분석, 전처리, 증강 기법 등) - 모델링 (베이스라인 구현, 모델 구조 개선, 하이퍼파라미터 튜닝, 모델 앙상블) - 성능 산출 - 결과분석”
한번에 순서대로 프로젝트가 진행되는 것이 아니기 때문에 모델 성능과 결과 분석 과정을 통해 추가적인 데이터 분석과 전처리, 증강기법이 지속적인 사이클을 이루어 진행됩니다.
이 부분은 첫번째 대회를 통해 충분 히 많이 느끼셨을거라 생각해요. 그리고 모든 과정은 단순히 "잘될것 같은데?"가 아니라 우리의 생각과 선행 연구(혹은 기타 자료들)를 기반으로 적절한 가설을 세워 진행됩니다.좀더 자세히 말씀드려보자면 모든 대회의 시작에 앞서 가장 중요한것은 “우리가 해결해야하는 문제가 무엇인지 정확히 인식하기” 입니다. relation extraction은 앞서 정리해주신 것 처럼 entity의 속성과 관계를 예측하는 문제입니다. 그렇다면 우리는 entity들의 관계를 잘 분류하는것을 가장 큰 목표로 설정한 후, 이 목표를 이루기 위한 작은 목표들을 리스트업 해야합니다.
이번 데이터셋의 몇가지 허들은 Entity들 사이에 아무런 관계가 없는 “no relation”을 잘 분류하고 난 후 relation들은 어떤 클래스를 가지는지 정확히 분류해야 합니다. 또한 각 클래스별 분포가 매우 상이하고, 성능 평가 지표인 AUPRC 때문에 모델의 output 형태를 깊게 고민해야 했습니다.꽤 까다로운 대회 세팅에도 불구하고 열심히 노력하셔서 조금씩 성능 향상을 이뤄 가시는 모습을 볼 수 있어 좋았습니다.
[우수한 점]
1. 라이트닝을 잘 사용해서 구현하신 것 같습니다. 개인적으로는 라이트닝을 크게 선호하진 않지만 (저는 huggingface를 더 좋아합니다 ㅎㅎ) 라이트닝에서 제공되는 다양한 기능을 잘 활용하셨고, 실제로 코드도 깔끔하게 구현되었습니다.
2. dynamic padding을 통해 불필요한 메모리 사용을 줄인 점은 훌륭합니다. 앞으로도 구현시 메모리와 효율성을 고민하는 과정을 계속 하시면 좋겠네요.
3. 빠른 실험, 빠른 결과 도출이 기억에 남습니다.
4. 각 파트별로 아쉬웠던 부분, 추가로 해볼만한 부분에 대해 언급한점이 매우 좋습니다. 특히 entity embedding의 경우 성능 하락이 크지 않기 때문에 조금 더 다양한 실험을 했다면 충분히 성능 향상으로 이어졌을거라 생각합니다.
5. TAPT가 잘 됐다는 기준을 측정할 지표가 없었다고 생각하신 점은 아주 정확합니다. TAPT의 가장 큰 문제는 loss값으로 보고 모델의 학습 정도를 파악해서는 안된다는 점인데요, 실제로 성능을 제대로 평가하려면 finetuning을 해봐야 합니다. 이부분을 정확히 지적하신점 훌륭합니다.
6. 모든 section별로 가설을 정리해두신 부분이 너무 좋았습니다. (가설에 대한 추가적인 이야기는 가장 아래 기타 코멘트를 참고해주세요!)
[아쉬운점]
1. 초기에 시도한 방법론에서 성능이 높게 나온 덕(?)에 다양한 방법론이나 모델을 폭넓게 적용해보지 못한 것 같아 아쉬움이 있습니다.
2. 리더보드 성능이 높게 나와 좋지만, 우리팀이 새로 가설을 세우고 문제를 해결하는 아이디어가 더 많았으면 좋겠습니다. focal loss, type marker, tapt등 기존에 유명한 방법론을 적용하는 시도는 너무 좋습니다. 하지만 이에 더해 여러분이 이번 대회를 통해 새롭게 가설을 세우고 제안하는 방법론들이 더 많아진다면 이 과정을 통해 큰 성장을 이루실 수 있을거에요.
3. TAPT에서 epoch을 줄이는게 왜 좋은지 이유를 서술해주시면 좋을것 같아요. 준녕님이 담당하셨던 tokenizer 변경 부분에서 잘 서술해주신 것처럼 “원인”을 적어서 분석하시는게 더 좋은 방법입니다.
4. 다양한 augmentation을 고민해보시면 좋겠습니다. PLM을 활용해서 새로운 데이터를 생성해볼수도 있고, relation extraction 같은 Entity 기반의 task는 NER을 함께 사용해서 데이터를 증강하기도 합니다. task에 적합한 augmentation을 찾아나가는 방법도 큰 도움이 되실거라 생각합니다
[기타 코멘트]
- 1. 대부분의 분들이 허깅페이스 코드에 익숙하지 않으시다는 아쉬움을 남겨주셨어요. 처음 배워가는 과정에서는 당연히 익숙하지 않고 어려움이 있으실텐데요, 이때 저를 마음껏 이용(?)해주세요 ! 허깅페이스 코드에 익숙한 제가 여러분들을 충분히 도와드릴 수 있답니다 :)
- 2. STS는 라이트닝으로, KLUE는 huggingface로 구현되어있다보니 가끔 “왜 통일되지 않은 코드가 주어질까”라고 고민하실 수 있어요. 사실 모든것에는 다 의도가 있답니다. 공개된 코드는 연구자의 니즈에 따라 api가 다를 수 있고 (라이트닝, huggingface), framework도 상이합니다 (keras, torch, jax 등) 다양한 api를 다루는 경험을 충분히 부캠에서 경험해보시길 바랍니다 :D
- 3. 준녕님 개인회고가 체계적으로 정리되어있네요. 저는 특히 마주한 한계, 새롭게 시도할 부분, vs level 1파트가 기억에 남습니다. 각 파트가 너무 구체적으로 개선 사항이 정리되어있어요. 회고 과정에서 많은 고민을 하신게 느껴집니다. 체계적인 실험 세팅과 올바른 가설을 설정하는 과정에서 함께 고민해봐요 ! (모든 팀원분들께도 해당되는거 아시죠 !? ㅎㅎ 다른 팀원분들도 준녕님 회고 한번씩 읽어보셨으면 좋겠습니다 !)
- 4. 별희님 회고에서 언급된 것 처럼 다음 stage에서는 각자 실험 가설을 보다 체계적으로 문서화 해서 공유하는 시간을 가지면 좋겠습니다. 조금 더 자세히 설명하자면 아래와 같습니다.
- 1. 먼저 각 section별 가설이 잘 정리된 부분은 정말 훌륭합니다. 하지만 리포트에 가설에 대한 Reference들이 모두 빠져있습니다. 논문을 빠르게 스키밍 하시고 근거들을 함께 적어주시면 더 풍부하고 논리적인 리포트가 될거에요 ! 그리고 저는 여러분이 왜 이 방법론을 선택했는지 조금 더 고민해보셨으면 좋겠습니다. 물론 멘토링 시간을 통해 여러분이 충분한 서치를 통해 해당 방법론을 찾으셨다는걸 알고 있습니다. 대회 과정에서 여러분의 고민과 생각들을 잘 정리해서 적어보고 팀원들과 공유하는 연습을 해보셨으면 좋겠습니다.
- 2. 회사에서 채용을 진행할 때 “프로젝트 경험”을 중요하게 여기는 이유는 어떤 모델을 써서 성능을 몇점 올렸다는 것을 알고싶어서가 아닙니다. 어떻게 문제를 정의하고, 문제를 이해하고, 문제를 풀이하기위해 얼마나 많은 고민을 하고, 해결방법을 찾아갔는지 알고싶기 때문입니다. (결과를 어떻게 해석했고, 어떤 방법으로 평가했는지도 정말 중요하게 봅니다)
- 3. 일반적으로 사람들이 말하는 해당 방법론의 장점을 여러분이 방법론을 선택한 이유로 서술하지 마시고, 1) 내가 왜 이방법론을 써보고싶은지 2) 이 방법론으로 부터 어떤 목적을 달성하고 싶은지 정리해보는 연습을 하셨으면 좋겠어요. 금방 말한 두가지 내용이 새로운 실험에 대한 시작점 입니다. (멋진말로는 실험 가설이라고 표현합니다)