1. 새로 공유된 베이스라인 노트북 분석
1) science topic / STEM topic으로 위키 데이터셋의 범위를 줄인 baseline 노트북
- 86.2 첫 번째 노트북 [86.2] with only 270K articles!
- 270k의 STEM과 관련있는 데이터셋만 뽑아내도록 하여 그 데이터셋을 공개하였음
- 데이터셋의 개수가 적어졌기 때문에, indexing을 쓰지 않고도 접근하여 뽑을 수 있게 하였음. 그리고 retrieve 알고리즘으로는 TF-IDF를 사용하였음
- DeBERTa-V3 대신에 Longformer를 사용하였음. (OOM이 나지 않도록 하기 위해서, context를 충분히 다 반영하게 하기 위해서.) → long former는 RACE dataset으로 학습된 mutiplechoice 모델.
- 2가지의 데이터셋에서 관련 있는 문서를 가져온 다음에, 그 context를 넣고 답을 뽑아서 probability를 높이고, 그것을 앙상블 하는 방법을 취했다고 볼 수 있음.
💡 Insight
[strength]
- 지난번 팀회의에서 제안주셨던 것처럼, 데이터의 범위를 줄이는 방식이 의미있는 성능 향상을 가져옴
- longformer를 사용하는 것이 context를 길게 넣어줄 수 있다는 점에서 좋을 것 같음
[room for improvement]
- retrieval 알고리즘을 TF-IDF로 한 이유가 궁금함. sentence-transformer와 같은 Dense embedding을 사용하는 것이 필요함 → 다음 노트북!
- query를 question만 넣거나, 좀 더 다양하게 진행해볼 수 있을 거 같음. → 다음 노트북에서 question뿐만 아니라 option도 넣는 것이 성능이 좋았다는 것을 리포팅!
- longformer를 관련 데이터셋을 가지고 더 학습시켜서 성능을 높일 수 있을 것이라고 생각됨 → 그러나 read model 학습 실험을 통해서 아주 긴 모델을 fine-tuning을 하는 것이 현재 가진 자원으로 쉽지 않을 수 있다고 생각함
2) 87.2 두 번째 노트북
💡 Insight
[strength]
- 가장 이상적이라고 생각했던, Retrieval-augmented LLM 방식. 메모리 관리를 전반적으로 굉장히 잘했다!
- 범위를 줄이고 sentence transformer를 사용했다는 점에서, (쿼리도 question만 넣는 것이 좋다는 것을 공유했다는 점에서) retrieval 알고리즘은 이 노트북에 정착하고! backbone 정도만 바꿔보는 것으로 실험해보면 되겠다고 생각이 들었다.
- 이 retrieval 알고리즘에, read model을 바꾸어서 넣어보는 실험을 하는 것이 최종적으로 좋을 것이라고 보았다.
[room for improvement]
- sentence transformer 바꿔보기
- read model 학습해서 넣어보기
→ 지난 주에 논의되었던 바와 같이, 위키의 범위를 줄인 데이터셋이 나왔으므로, 이 노트북들을 기준으로 다음 단계를 진행 !
2. Retrieval Model
1) sentence transformer backbone 변경 (wikipedia RAG 노트북을 중심으로)
-
베이스라인 노트북에서 쓰고 있는 BAAI/bge-small-en-v1.5, 그리고 폴더 안에 있는 것들
-
기존 transformer 저장 + faiss index 생성하는 코드 (팀 깃헙에 공유)
→ 이렇게 해놓고 밤새 돌아가게 두었읍니다,,,,, ㅋㅋㅋㅋㅋㅋㅋ
-
sentence-transformers/all-MiniLM-L6-v2
-
BAAI/bge-base-en-v1.5
-
BAAI/bge-large-en-v1.5
-
sentence transformer backbone 비교 (BAAI/bge-small-en-v1.5와 sentence-transformers/all-MiniLM-L6-v2) → 팀 깃헙에 공유
- 큰 차이는 느끼지 못했음. 이미 small 모델도 충분히 잘 하고 있었기 때문에, 베이스라인에 비해서 비약적인 성능 향상이 느껴지지는 않았음
- 따라서 모델을 변경하여 노트북에 올려보면서, test set에 더 잘 들어맞는지 제출을 통한 확인을 하는 것이 최선일 것 같다.
2) 캐글 노트북에 업로드 하기
- 주의해야 할 사항!
- 베이스라인 노트북에서는 sentence-transformer class를 직접 정의하여 사용하고 있음. 그것에 맞춰서 Faiss embedding도 생성되어 저장되어 있음.
- 그러나 새로운 라이브러리들은 편의를 위하여 sentence-transformer 라이브러리를 사용하고자 함
- (그러면 Mean pooling으로 뽑아옴, 결과 비교하였을 때 정의한 sentence transformer와 차이가 없었다. faiss index와의 align만 중요!)
- 따라서 Dataset에 다음을 추가하고 sentence-transformer를 쓸 수 있게 해야 하고
!cp -rf /kaggle/input/sentence-transformers-222/sentence_transformers /kaggle/working/sentence-transformers
!pip install -U /kaggle/working/sentence-transformers- 기존의 class는 my_Sentencetransformer로 이름을 변경함.
- 캐글 노트북에 학습한 모델과 Index 올라가는 시간
- 1시간 정도는 족히 걸리는 것 같음. 천천히 시간을 가지고 할 수 있도록 해야 한다. → 그래도 성공적으로 올라가긴 한다!
3. Read Model
- 범위 줄이기 + sentence transformer의 Backbone 확인으로, Retriever에서 할 수 있는 역할이 거의 완성되었다고 생각하고, 더 성능 좋은 Read 모델을 만들기 위해 필요한 것은 무엇일까 생각함
- 특히, 첫 번째 노트북에서 RACE dataset으로만 학습한 Longformer를 사용했음에도 어느 정도의 성능이 나오는 것을 보고, STEM에 관련된 데이터셋으로 read model을 학습시키는 것이 성능이 좋아질 것이라고 생각됨
1) MMLU dataset 으로 multiplechoice model 학습시키기
-
MMLU dataset
Papers with Code - MMLU Dataset
- 특히, Physics와 science 분야의 문제의 경우, 우리가 풀고자 하는 문제와 비슷하다고 볼 수 있다! MMLU_physics_set.csv MMLU_science_set.csv
- 특히, Physics와 science 분야의 문제의 경우, 우리가 풀고자 하는 문제와 비슷하다고 볼 수 있다! MMLU_physics_set.csv MMLU_science_set.csv
-
Back bone model list
- DeBERTa
- longformer
- bigbird
-
학습 코드 → 팀 깃헙에 공유
- hugging face trainer 를 사용하여 자동적으로 accelerator처럼 모델 분산처리 학습이 가능함. 따라서 긴 context를 학습하고 싶어서 이 알고리즘으로 선택하게 됨.
-
32기가 gpu 기준, 512 maxlength인 경우에는 bacth4까지 가능, 1024 maxlength 인 경우에는 batch2까지 가능 → deberta랑 longformer가 2개씩 나눠서 쓰고 있다,,,,
-
결론 : context를 길게 Finetuning 시키는 것이 너무나도 빡세다!!! ㅜㅜㅜㅜ
- 직접 학습하는 것이 여의치 않으면, 기존에 긴 context로 학습된 모델들을 가져와서 사용하는 것이 필요할 것이다.
NLP 엔지니어,,,,? 가 될 수,,,? 나도,,,,?