최종 결과
- public leaderboard: 16th (0.8276)
- private leaderboard: 16th (0.8282)
- 아쉽게도 이번엔 성적이 좋지 않았다…
- 그래도 해볼까 싶은 건 다 해본 것 같고… 나머지는 통제할 수 없는 디테일적인 요소에 의해 결정된 것 같아서 후회는 없다고 생각한다.
프로젝트 소개
- 일단 기본적으로 뉴스 기사의 제목을 보고 7가지의 주제 중 하나로 분류하는 것이다.
- 근데 이번 대회의 키워드는 “Data-centric”.
- 베이스라인 코드에서 주어진 모델의 설정을 바꾸는 것이 금지되어 있다.
- 기본적으로 주어지는 훈련용 데이터셋 외에 추가적인 데이터를 사용할 수 없고, 훈련용 데이터셋은 다음과 같은 노이즈가 존재한다.
- 텍스트 노이즈: 문자열의 일부가 랜덤한 ASCII 문자로 대체됨. 총 1600개
- 라벨 노이즈: 라벨이 무작위로 섞인 1000개 데이터
- 노이즈가 없는 정상 데이터 200개
- 텍스트 노이즈를 잘 복원하고, 라벨 노이즈를 잘 교정하는 것이 이번 프로젝트의 핵심이다.
- 점수는 Macro F1 Score를 사용한다. 특정 label만 잘 맞추면 점수가 낮고 모든 label에 대해서 균등하게 잘 맞추어야 점수가 높게 나온다.
프로젝트 진행 과정
10/28 ~ 10/31
- 원래 30일까지 강의를 다 보고, 31일부터는 프로젝트를 시작할 계획이었다.
- 근데… 구인구팀하느라 너무 바빠서… 강의를 다 못보았고 결국 31일까지 강의를 보도록 일정을 바꾸었다…
- 심지어 바꾸고도 난 강의를 결국 6강까지밖에 보지 못했다. 죄송해요 우리팀 ㅠㅠ.
- 그래도 31일에는 구인구팀을 무사히 마칠 수 있었고, 그때부터는 정신이 차려서 아래와 같은 workflow를 만들어 놓기도 했다.
11/01 ~ 11/03
- 홍 모 캠퍼님께서 열심히 베이스라인 코드를 모듈화해주셔서, 그걸 기반으로 프로젝트를 시작하였다.
- 원래 내가 Cleanlab이라는 라벨 노이즈를 교정해줄 수 있는 도구를 사용해볼까 하였는데, 그 전에 위에서 소개한 workflow에 맞추어 Abstract Class를 작성했다.
- 그리고 하는 김에 Rule-based로 텍스트 노이즈를 감지하는 클래스를 만들어봤는데… 어떤 방법론을 적용해도, 점수로 노이즈를 측정하면 텍스트 노이즈가 있는 것과 없는 것을 완벽히 나눌 수 없는 gray zone이 항상 존재한다는 것을 알 수 있었다.
- 주말을 이용해서 각 클래스들을 한데 모아서 모듈 통합 테스트를 해볼 수 있도록 새로운 클래스를 작성했는데… 프로젝트를 끝난 지금 회고해보면 결국 쓰이지는 않았던 것 같다.
- 모듈들을 한 번에 이용해서 데이터를 만들기 보다, 그냥 중간 결과물들을 저장하면서 만드는 게 더 깔끔했기 때문인 것 같다.
11/04~11/05
- 프로젝트 기간이 총 2주였는데, 앞의 1주는 위에 적은 것처럼 좀 허송세월을 보낸 것 같고, 사실 지금부터 열심히 하지 않았나 하는 생각이 든다.
- rule-based를 넘어서 LLM을 활용해보기 시작했다.
- 처음에는 데이터 증강을 LLM으로 해보자는 목표였는데, 하다보니 성능이 너무 괜찮은 것 같았다.
- 그래서 그냥 텍스트 노이즈 감지랑 복원을 프롬프트만 살짝 바꿔서 진행해보면 어떨까하는 의견이 나왔고, 진행해보니 rule-based보다 훨씬 잘해준다는 걸 알았다.
- 근데도 텍스트 노이즈가 없는데도 노이즈가 있다고 판단하는 경우가 더러 있다는 걸 확인했다.
- 그래서 그런 걸 텍스트 노이즈 복원 전, 후 문장 사이의 BLEU 점수를 구해서 일정 수치를 넘으면 원래 텍스트 노이즈가 없는데 LLM이 있다고 잘못 판단한 경우라고 보고 텍스트 노이즈가 없는 문장이라고 고쳐주었다.
- 근데 이 방법을 활용했는데 오히려 Public 점수가 떨어졌다…
- 더 데이터 품질이 높아졌는데 왜 떨어졌을까 고민을 해봤는데, 노이즈 교정기를 학습시키기 위한 데이터의 절대적인 양이 줄어서 그런 것이 아닐까 하는 추측 정도로 끝냈다.
- 사실은 납득이 잘 안되어서 계속 A/B 테스트를 해보고도 싶었는데 제출 기회가 너무 제한되어 있어서 그러지는 않았다…
11/06 ~ 11/07
- 여기서부터 우리는 선택의 기로에 놓이게 되었다.
- 리더보드 점수를 높이는데 최선을 다할 것인지, 아니면 스스로의 성장에 집중할 것인지
- 당연히 이렇게만 보면 후자가 맞지만, 언급하지 않으면 전자 쪽으로 치우게 될 것 같아서 내가 팀원들에게 어느 것에 집중할지 생각해보자고 했다.
- 그래도 존엄사(ㅋㅋ;)를 하기 위해서, 또 발표도 하기로 했어서 우리만의 실험 체계를 잘 갖추는데에 집중했다.
- 그래서 팀원 모두가 각자 나름대로 체계적인 근거를 마련하는데 힘을 썼다.
- 역번역 증강 평가 지표: BLEU랑 STS, 의미적으로는 유사하면서 문장의 생김새는 많이 다르도록 증강하는 방법을 채용
- 노이즈 복원기 평가 지표: 텍스트 노이즈가 없는 문장에 노이즈를 넣고 복원한 텍스트와 원본 텍스트 사이의 BLEU, ROUGE 점수를 측정
- 군집화로 라벨 노이즈가 잘 교정되었는지 확인
- 그 외 label 분포를 확인하는 것과 같은 기초적인 EDA 진행 등
- 나는 고정적인 validation 데이터셋 만들기에 집중했다.
- 베이스라인 코드에서는 랜덤으로 원래 데이터셋의 일부를 validation 데이터셋으로 사용한다.
- 근데 이러면 데이터셋이 증강되거나 필터링될 때마다 validation 데이터셋으로 바뀌어서 진행한 실험의 성능을 객관적으로 확인하기 어렵다는 문제가 있었다.
- 그래서 증강한 데이터 중 일부를 validation 데이터셋으로 활용하고자, 데이터셋을 바꾸면서 validation 점수와 public 점수를 비교해보며 추세가 비슷하면서도 적절한 데이터셋을 골랐다.
- 최종적으로 고른 validation 데이터셋이 계속 실험을 하면서 확인해보니 추세가 어느 정도 잘 맞는 것 같아서 좋은 지표로 사용할 수 있었다.
- 근데 너무 늦게 만들어서 아쉽다고 생각했다…
잘한 점과 아쉬운 점
- 잘한 점
- 모듈화를 열심히 했다.
- 저번 프로젝트할 때 main.py가 400줄이 나오는 등 코드 유지보수가 정말 끔찍하게 어려운 경험을 한 번 겪고 나니 모듈화의 중요성을 깨달아 버렸다.
- 그래서 이번에는 모듈화를 되게 열심히 해서 코드가 복잡해지지 않도록 관리했다.
- 근데 관리한 거에 비해서 뭔가 모듈화로 이득을 봤다는 기분은 딱히 없었는데, 그래도 후반에 노이즈 복원기 성능 평가 코드가 모듈화 덕분에 쉽게 쓰여진 것 같아서 기분이 좋았다.
- 발표를 했다.
- 발표 자체는 뭐… 그렇게 극적인 효과가 없었다.
- 다만, 발표를 준비하기 위해 시각화에 신경쓰고 체계적인 논리구조에 신경쓰는 등 “할 말”을 만들려고 한 게 좋았던 것 같다.
- 앞으로는 발표 없이도 이런 느낌으로 할 수 있도록 신경을 잘 써보면 좋을 것 같다.
- 아쉬운 점
- 구인구팀 때문에 프로젝트에 너무 집중하기 어려웠다.
해체하는 팀이 불리하다고 생각해요…- 그냥 강의고 프로젝트고 하나도 집중이 안되더라… 그래서 더 집중할 수 있으면 더 좋은 결과가 있었을 것 같다는 생각에 아쉬움이 남는다.
- Data Version Control을 써보면 어땠을까.
- 사실 계속 이야기를 하긴 했었는데… 시간적인 이유로 포기했었다.
- 근데 노션으로는 정리가 너무 잘 안되어서 차라리 시간을 투자해서 DVC를 익혔으면 오히려 좋지 않았을까 하는 생각이 든다.
- 너무 단기적으로만 생각하지말고 좀 큰 그림을 그려야 할 것 같았다.
후기
- 사실 꼴등한 건 상관없는데, 꼴등한 상태로 발표를 해야하는 게 좀 어지러운 모멘트였다.
- 원래 내가 발표할 생각도 있었는데 발표를 대신 해주신 홍 모 캠퍼님만큼 잘 살리지 못했을 것 같아서 가만히 있길 잘한 것 같다.
- 근데 또 차라리 애매하게 15~14등 하느니 걍 꼴등하는 게 더 웃긴 것 같다는 이야기도 했다. (ㅋㅋ)
- 결과는 안좋았지만, 지금까지 진행한 세 개의 프로젝트 중 이번이 제일 과정에 집중할 수 있는 프로젝트가 아니었나 하는 생각이 든다.
- 아이즈원의 마지막 팀 프로젝트인 만큼 유종의 미를 거두고 싶었지만… 그래도 등수 빼고는 다 잘 거둔 것 같다.
- 이젠 새로운 팀원들과 함께 해야 하니 이정도로 마무리하고 다음 프로젝트로 시선을 돌려야 겠다.