2주 간의 KoELECTRA 개발기 - 1부
2주 간의 KoELECTRA 개발을 마치고, 그 과정을 글로 남기려고 한다.
이 글을 읽으신 분들은 내가 했던 삽질(?)을 최대한 덜 하길 바라는 마음이다:)
1부에는 실제 학습을 돌리기 전까지의 과정을 다룰 예정이다.
Github Repo: https://github.com/monologg/KoELECTRA
문제 의식
한국에 Public하게 공개되어 있는 한국어 PLM(Pretrained Language Model)
에는 크게 3가지가 있다.
- SKT의
KoBERT
- TwoBlock AI의
HanBERT
- ETRI의
KorBERT
3가지 모두 좋은 성능을 보이지만, 3가지 모두 단점이 존재한다. 각각의 단점을 정리하면 아래와 같다.
단점 | |
---|---|
KoBERT | Vocab size (8002개)가 상대적으로 작음 |
HanBERT | Tokenizer로 인해 Ubuntu 환경에서만 사용 가능 |
KorBERT | API 신청 등의 과정 필요 |
특히 3가지 모두 공통적으로 Huggingface Transformers
라이브러리에서 사용하려면 tokenization 파일을 따로 만들어야 하는 단점이 있다.
KoBERT와 HanBERT의 경우 내가 직접 tokenization 파일을 만들어서 github에 배포했지만, 일부 사용자들이 불편함을 토로하기도 했다.
그래서 이번 기회에 위의 단점들을 모두 해결한 한국어 PLM
을 개발하고 싶었다.
- Vocab size가 어느 정도 커야 함 (30000개 정도)
- 모든 OS에서 사용 가능
- tokenization 파일을 만들 필요 없이 곧바로 사용 가능
- 어느 정도 성능까지 보장되어야 함
위의 4가지를 모두 만족시키기 위하여 시작한 프로젝트가 바로 KoELECTRA
이다.
Tokenizer
실제 현업에서도 좋은 성능을 위해 Mecab + Sentencepiece
를 많이 사용하는 것으로 알고 있다. 그러나 공식 BERT, ELECTRA 등은 Wordpiece
를 사용하고 있으며, transformers
에서도 공식적으로 Wordpiece만 지원하고 있다.
즉, ELECTRA에서 Mecab이나 Sentencepiece를 사용하려면 추가적으로 tokenization
파일을 만들어야 하며, transformers
라이브러리의 api가 바뀌면 내가 직접 그에 맞게 tokenization 파일을 바꿔줘야 한다는 것이다. (KoBERT의 경우 실제로도 그렇게 하고 있다ㅠ)
이러한 문제들 때문에 이번 프로젝트에서는 무조건으로 Wordpiece
를 사용하는 방안으로 진행하였다.
Wordpiece
“Wordpiece vocab을 만들 때 Huggingface의
Tokenizers
라이브러리를 쓰는 것이 가장 좋다.”
import argparse |
- Vocab size의 경우 관례적으로 많이 쓰이는 약 3만개로 세팅하였다.
- 전처리 없이 원본 Corpus만 가지고 vocab 만들면 성능이 굉장히 안 좋음
- character coverage를 최대한 높게 잡는 것이 좋다고 판단 (즉, corpus에서 등장했던 모든 character를 vocab에 포함시킴)
- 예를 들어
퀭메일
이란 단어가 있다고 가정하자.- 만일
퀭
이 vocab에 없다면퀭메일
전체를[UNK]
로 처리하게 된다.- 만일
퀭
이 vocab 안에 있으면퀭 + ##메일
로 tokenize가 될 수 있어##메일
이란 단어의 의미를 가져갈 수 있다.
(자세한 내용은 이전에 포스팅한 [나만의 BERT Wordpiece Vocab 만들기]을 참고)
전처리 (Preprocessing)
“첫째도 전처리! 둘째도 전처리! 셋째도 전처리!”
“PLM의 성능에 가장 큰 영향을 주는 것은corpus quality
이다!”
크롤링한 뉴스의 문장 하나를 살펴보자
[주요기사] ☞ [포토 스토리] 무허가 도시광산 을 아시나요? ☞ [따뜻한 사진 한 장] 사랑, 하나가 되어 가는 길 <찰나의 기록, 순간의 진실 / KPPA 바로가기> Copyrightsⓒ 한국사진기자협회(www.kppa.or.kr), powered by castnet. 무단 전재 및 재배포 금지 보내기
문제는 이런 문장이 매우 많은데다가, 이걸 Pretrain에 넣을 시 성능이 나빠질 게 뻔하다….
이렇게 noise가 많은 Corpus로 vocab을 만들고 pretrain까지 하면 성능이 좋을 리가 없다.
아래는 내가 적용한 대표적인 전처리 기준이다.
- 한자, 일부 특수문자 제거
- 한국어 문장 분리기 (kss) 사용
- 뉴스 관련 문장은 제거 (
무단전재
,(서울=뉴스1)
등 포함되면 무조건 제외)
사실 전처리의 기준에 정답은 없다. 가장 중요한 것은 자신의 Task에 맞게 전처리 기준을 세우는 것이다. 내가 생각했던 Task 들에는 한자는 중요하지 않다고 판단해서 지운 것이지, 한자가 꼭 필요한 Task의 경우에는 지우면 안 될 것이다.
TPU 사용 관련 Tip
(자세한 내용은 이전에 포스팅한 [TPU를 이용하여 Electra Pretraining하기]을 참고)
1. Tensorflow Research Cloud(TFRC)를 쓰면 TPU가 무료
→ 이미 공식 코드가 TPU를 완벽히 지원하기에, 직접 ELECTRA를 만들고 싶다면 GPU보다는 TPU를 쓰는 것을 강력히 권장한다.
2. VM Instance는 작은 것(n1-standard-1
)을 써도 상관 없다
→ ELECTRA를 GCP에서 학습하려면 TPU
, Bucket
, VM Instance
이렇게 3개가 필요하다. 그런데 저장소는 Bucket이, 연산은 TPU가 처리하기 때문에 VM Instance는 가벼운 것을 써도 된다.
→ n1-standard-1
는 시간당 약 $0.037, n1-standard-4
는 시간당 약 $0.14이다. (비용이 무려 2배 차이!!)
3. TPU를 쓰는 경우 모든 input file은 Cloud storage bucket을 통해야만 한다
→ 이것도 처음에 몰랐다가 고생했던 삽질 중 하나다. tf.estimator.tpu
쪽 코드를 쓰는 경우 로컬 데이터가 아닌 Bucket
을 통해야만 한다. (관련 FAQ)
→ 다행히도 Bucket의 비용이 비싸지가 않다 (특정 리전에 만들어 놓으면 1GB당 월 약 $0.03)
4. VM Instance와 TPU를 만들 때 ctpu up
명령어를 사용해라
→ VM Instance와 TPU를 따로 따로 생성하면 처음에 정상적으로 작동하지 않는 경우가 있었다. 아래와 같이 cloud shell
로 명령어를 한 번만 치면 VM과 TPU가 동시에 생성된다😃
$ ctpu up --zone=europe-west4-a --tf-version=1.15 \ |
Configuration의 함정
앞에서도 언급했듯이 ELECTRA Pretraining은 공식 코드를 그대로 가져다 쓰는 것이 좋다. 공식 코드를 가져다쓰기 전에 논문
과 코드 분석
을 어느 정도 하고 진행하는 것을 권장한다.
그럼에도 좀 헷갈렸던 부분이 있어 여기서 언급하려 한다.
1. 공식 레포에서 제공하는 small
모델은 정확히는 small++
모델이다
공식 코드에서도 알 수 있듯이 small
로 공개된 모델은 정확히 말하면 small++
모델이다. 둘의 차이점은 아래와 같다.
max_seq_len | generator_hidden_size | |
---|---|---|
small | 128 | 0.25 |
small++ | 512 | 1.0 |
(generator_hidden_size=1.0
이란 것은 discriminator
와 generator
의 hidden_size가 같다는 것이다)
이러한 부분이 논문에 자세히 나와 있지 않아 처음에 small 모델을 만들 때 진짜 small로 만들었다가 다시 small++로 만드는 수고를 거쳤다…. (이 글을 읽은 분들은 이 삽질을 안 하길 빈다.)
{ |
2. max_seq_length를 128로 줄인다면 max_position_embeddings도 128로 줄여야 한다
간혹 커스터마이즈된 모델을 만들 때 max_seq_length
를 줄이고자 하는 경우가 있다.
그럴 시 max_seq_length
만 줄이면 해결된다고 오해할 수 있는데, max_position_embeddings
도 줄여줘야 transformers 라이브러리에 맞게 변환할 때 문제가 생기지 않는다. (transformers가 max_position_embeddings으로 최대 길이를 알아내기 때문!)
더 큰 함정은 아래와 같이 model_hparam_overrides
라는 attribute 안에 max_position_embeddings
를 넣어줘야 하는 것이다!
마치며
1부에서는 실제 Pretraining을 시작하기 전의 준비 과정을 다뤘다.
2주 간의 KoELECTRA 개발기 - 2부 에서는 실제 Pretraining, Transformers 포팅, Finetuning 등을 다룰 예정이다:)