문장 간 유사도 측정 Semantic Text Similarity

문장 간 유사도 측정 Semantic Text Similarity

2023.04.10 - 2023.04.21

Github

GitHub - iamzieun/Boostcamp-LV1-STS: [boostcamp Ai Tech] STS (Semantic Textual Similarity) 대회

 

---

💪🏻 1. 학습 목표를 달성하기 위한 노력

나의 학습 목표

1. 프로젝트의 end-to-end 과정을 빠짐없이 경험하기
2. vscode, github, wandb, huggingface datasets 등의 tool을 적극적으로 활용하기
3. 팀원들과 긍정적이고 효율적으로 협업하기

목표를 달성하기 위한 행동

1. 프로젝트의 end-to-end 과정을 빠짐없이 경험하기
   • ‘고민보다 Go’를 실천하려 노력했다.
     • 현 시점에서 필요시 되는 것이 무엇인지 스스로 고민하고 → 고민의 결과를 팀원들에게 전달하고 → 일단 부딪혀보았다.
     • 프로젝트 내 대부분의 경험이 새로운 경험이었기 때문에, 중간에 막히는 부분이 있으면 팀원들에게 질문하여 해결하는 방법을 사용했다.
2. vscode, github, wandb, huggingface datasets 등의 tool을 적극적으로 활용하기
   • 지금까지 위와 같은 tool을 적극적으로 사용하지 않았던 이유는 운영체제에 대한 무지와 환경 설정의 어려움 때문이었다.
     • 이러한 증상은 지난 겨울 mlops 스터디를 하며 겪었던 수많은 알 수 없는 오류들을 끝까지 해결하지 못했던 경험으로 인해 심화되었다..
   • 하지만 이는 예비 엔지니어에게 어울리지 않는 태도라고 생각했고(! 나는 엔지니어링을 잘 하고 싶다), 이번 프로젝트를 통해 tool들과 친해지기 위해 팀에 여러 가지 tool들을 적극적으로 활용할 것을 제안했다.
   • tool들을 사용하는 과정에서 오류가 발생할 경우, 아예 초기화를 하고 새로 시작하는 방법을 지양하고 최대한 정석적인 방법으로 오류를 해결하고자 노력했다.
     • ex1. git branch / commit이 꼬였을 때 팀원들과의 피어세션을 통해 git status / reset / stash 등의 방법으로 문제를 해결
     • ex2. HF datasets을 수정할 때는 항상 commit을 활용
     • ex3. vscode에서 서버에 연결했을 때 python이 제대로 작동하지 않았을 때 터미널에 설치되어있는 python과 vscode extension으로 설치된 python을 점검하여 문제를 해결
3. 팀원들과 긍정적이고 효율적으로 협업하기
   • 좋은 커뮤니케이션이란 ‘상대가 자발적으로 내 의도에 맞게 행동하게 하는’ 커뮤니케이션이다.
     • 이를 위해서
     • (1) 프로젝트의 고도화에 도움이 되는 주장을 하며
     • (2) 주장에 대한 충분한 근거를 제시했다.
     • (3) 더불어 나와 상반되는 주장을 가진 팀원을 설득할 수 있어야 했다. (나는 하지 못했다)
   • 하지만 어떤 커뮤니케이션도 상대방의 경청 없이는 무의미하기에 피어세션 시간에 최대한 집중하고자 했다.
   • 그런데 만약 팀원이 나의 말에 집중하고 있지 않다면 / 팀원의 커뮤니케이션 방식이 내가 생각한 방식과 다르다면 어떻게 해야 할까? 더 고민해보아야 할 지점이다. 

🙂 2-1. 프로젝트 진행 내용 및 성과

• EDA
  • 주어진 데이터를 각 column별로 분석한 후, column간의 관계에 대해 분석했다.
  • 특별한 인사이트는 없었지만, 데이터를 확인하고 데이터 보강의 방향성을 잡는 데 도움이 되었다.

• Huggingface Datasets 연결
  • colab 및 vscode를 통해 Huggingface Datasets에 접속하고, pytorch lightning template과 Huggingface Datasets을 연결하였다.
  • 이로 인해 여러 버전의 데이터를 로컬에 저장해둘 필요 없이 config.json에서 argument만 바꾸어 가며 원하는 버전의 데이터를 불러와 모델을 학습시킬 수 있었다.
• loss function 조사
  • baseline code에서 사용된 loss function 외에 모델의 성능을 향상시키는데 기여할 수 있는 loss function에 대해 조사해보았다.
• 모델 학습 사후 분석
  • 학습된 모델의 inference 결과를 분석하여 1) 문장 내 같은 위치에 특수문자가 쓰인 경우 2) 유의어가 사용된 경우 3) 영어가 사용된 경우 모델의 예측 성능이 떨어진다는 사실을 발견했다.
  • → 모델 학습 사후 분석이 초기 EDA만큼이나 중요하다는 사실을 새롭게 깨달았다 !
• 데이터셋 증강
  • v2.0.0: 원본 데이터 + reverse augmentation 적용한 데이터
    • label = 0인 데이터를 제외하고 sentence_1과 sentence_2를 바꾸는 방식으로 데이터를 증강했다.
  • v3.0.0: 원본 데이터 + style transfer 적용한 데이터
    • SBERT를 이용하여 새로 생성한 데이터와 기존 데이터 간의 유사도를 확인함으로써 새로 생성한 데이터의 품질을 확인했다.
  • 어느 정도 품질이 괜찮은 데이터를 생성함으로써 모델의 성능 향상에 기여했다.

🙁 2-2. 프로젝트 진행 과정 속 한계와 교훈

• EDA
  • 첫 EDA 과정에서, 자료를 보다 객관적인 시선으로 바라보지 않았던 점이 아쉬움으로 남는다.
    • 수치형 자료들 간 상관관계에서 문장의 길이와 문장 간 길이의 차가 약한 양의 상관관계를 가졌는데, 이는 당연한 것이라고 생각해서 이에 대한 추가적인 분석을 해보지 않았다.
  • EDA를 급하게 하다 보니 반복되는 시각화 부분을 함수로 정의하지 않고 계속 복사/붙여넣기를 했다.
    • 하지만 EDA는 프로젝트 내내 계속 진행되어야 하는 부분이기 때문에 급할 필요가 전혀 없었다. 오히려 함수로 정의해두고 그 함수를 불러와서 사용하는 것이 더 시간을 절약할 수 있었을 것이다.
• Huggingface Datasets 연결
  • local에서 터미널을 이용하여 Huggingface Datasets에 직접 데이터를 업로드하는 것에 실패했다.
    • GUI로 데이터를 업로드하는 것도 간단하고 문제는 없었지만, git을 처음 다뤘을 때와 비슷한 오류였던 것 같아서 해결하고 넘어가는 것이 좋을 듯 하다.
  • Huggingface Datasets 버전 관리 convention을 확립하는 데 실패했다.
    • 소프트웨어 버전 관리 방법인 semantic versioning을 참고하여 버전 관리 convention을 만들어 제안했지만, 내가 만든 convention이 포괄하지 못하는 예외 상황으로 인해 팀원 모두의 합의를 이끌어내지 못했다. 이에 따라 현업에서는 데이터셋 버전 관리를 구체적으로 어떻게 진행하는지 알아보고, convention을 보완하여 다시 제안해보려 한다.
    • 더불어 Huggingface Datasets을 혼자 관리한 만큼 이와 관련된 부분에 있어서는 내가 보다 적극으로 명확하게 전달을 했어야 했다는 아쉬움이 남는다.
• loss function 조사
  • ‘조사’에서 그치지 않고 직접 각 loss function을 적용한 실험으로 이어갔으면 팀원들에게 더 효과적으로 loss function에 대해 전달할 수 있었을 것이다.
• 모델 학습 사후 분석
  • 분석한 결과를 반영한 데이터 증강에 성공하지 못했다. 특히 여러 방법으로 유의어 기반 augmentation을 시도해보았는데, 생성된 데이터의 품질이 좋지 않아 실제로 활용하지는 못했다.
• 데이터셋 증강
  • class imbalance를 더 신경써서 데이터를 증강하지 않았던 점이 아쉬움으로 남는다.
  • 모델 학습 사후 분석 결과 가장 유의미한 insight였던 세 가지 (특수문자 / 영어 / 유의어) 중 두 가지에 대한 augmentation에 실패한 점이 아쉽다. 특히 외래어를 한글로 바꾸어주는 모듈인 hangulize가 영어를 지원하지 않았는데, 다른 언어를 통하여 우회적으로 영어를 한국어로 바꾸는 방법을 알고 있었음에도 성능이 좋지 않을 것이라 자의적으로 판단하고 실험해보지 않았다.
    • 저 두 개에만 체크 표시 안되어있는거 굉장히 킹받는다.
     

👨‍👩‍👧‍👦 3. 협업과 커뮤니케이션

• 원활한 프로젝트 진행에 도움이 될 노션 템플릿을 제작하고 팀원들과 공유했다.
  • 프로젝트 진행 내용이 카테고리별 / 시간별로 구분이 되어 있어 필요한 내용을 찾기 편했으나, 팀원들이 현재 어떤 task를 진행하고 있는지에 대한 정보가 보다 더 눈에 띄었으면 좋겠다는 피드백을 받아볼 수 있었다. 더불어 함께 공유하는 내용이 많아지며 노션 페이지가 빈틈없이 채워질 것을 대비하여 레벨별, 프로젝트별로 페이지를 구분하자는 의견도 있었다. 이러한 피드백을 반영하여 노션을 쇄신할 예정이다.
• 효율적인 회의에 대한 팀원들의 공감대를 형성하고 이를 위한 회의 진행 방식 및 회의록을 공유했다.
  • 지금까지 다른 팀에 비해 유난히 피어세션 시간이 길어졌던 이유가 이야기의 ‘주제’를 정해두지 않고 피어세션을 진행했기 때문이라 생각하여, 회의 시작 전 안건을 상정하는 시간을 가질 것을 제안했다.
  • 매번 완벽하게 지켜지지는 못했지만, 특별히 의논할 사항이 없던 프로젝트 전에도 피어세션을 기준 시간의 2배 이상 진행하던 것과 비교하면 의미가 있었다고 생각한다.
• 의사결정이 필요한 시점에 최대한 다수결이 아닌 만장일치를 이끌어 낼 수 있게끔 노력했다.
  • 소수의 인원으로 구성된 팀인만큼 팀원 한 명 한 명의 의견을 확인하는 것이 협업에 도움이 될 것이라 생각하여, 모든 팀원의 의견이 일치하지 않을 경우 충분한 논의 및 설득을 거쳐 모두가 동의할 수 있는 결정을 내리고자 하였다.

🔥 4. 한계와 교훈을 바탕으로 다음 프로젝트에서 시도해볼 점

• 프로젝트 진행
  • 첫 프로젝트를 진행하며 파이프라인 설계를 경험해보았으니, 다음 프로젝트부터는 파이프라인 설계를 빠르게 끝내고 더 많은 실험을 진행해보면 좋겠다.
• 협업과 커뮤니케이션
  • 피어세션을 보다 구체화하여, 진행 상황을 공유하는 시간과 함께 디버깅하는 시간으로 나누어 진행하면 좋겠다.
  • 리더가 없는 팀인 만큼, 팀 전체가 루즈해지거나 방향성을 잃는 것을 예방하는 차원에서 회의 및 프로젝트를 주도할 ‘모더레이터’의 역할이 필요하다는 생각을 했다.
  • 내가 만드는 노션 템플릿은 팀의 커뮤니케이션 방식에 생각보다 큰 영향을 미치는 것 같다. 조금 더 섬세하게 템플릿을 쇄신해보아야겠다. 커뮤니케이션 정말 잘하고싶다..ㅠㅠ
• 기타
  • 강의, 과제, 공지, 멘토링 내용 등을 꼼꼼하게 확인하고 프로젝트를 시작하자.
    • 강의, 과제, 공지, 멘토링 내용에 프로젝트를 진행하며 드는 대부분의 의문에 대한 해답이 제시되어 있다. (!)
    • 특히 이번에는 프로젝트를 빨리 시작해야 한다는 마음에 강의를 꼭꼭 씹어먹은게 아닌 해치워버린 느낌이 있는데, 이런 식으로 강의를 들으면 결국 기억나는 것은 하나도 없음을 누구보다 잘 아는 사람으로서 같은 실수를 반복하지 말아야겠다.
  • ‘중요한 것은 꺾이지 않은 마음’임을 잊지 말고 적극적으로 실험하자.
    • 어느 순간부터 리더보드에 눈길이 가서 무의식적으로 성능 향상에 도움이 되지 않을 것 같은 실험은 시도해보지도 않고 포기했던 것 같다. 하지만 도전적인 실험의 부재는 오히려 성능의 침체를 야기했다.
    • 다른 팀들의 성능 향상에 기여한 아이디에이션과 실험 과정을 들어보았을 때, 나도 생각했지만 실험까지는 해보지 않았던 것도 많았다. 할 지 말 지 고민될 때는 그냥 하기로 !