[Day01]
Language Model Evaluation metric
▮ 언어모델의 평가는 하나의 지표만을 보는 것이 아니라 품질, 다양성, 유창성, 사실성등 다양한 각도에서 평가가 필요할 것 같은데,
BLEU나 Perplexity같이 단순히 모델 출력을 reference와 비교하는 것으로 언어 모델의 성능을 평가할 수 있을까?
▮ 무언가를 최적화/학습한다고 할 때 그 기준을 명확히 정의하지않으면 잘 학습되었는지 알 수 없을 것 같은데, 언어 생성 task에서는 어떻게 평가지표를 정의하는지?
→ 이를 개선하기 위해 연구된 방법
▮ Language Model Evaluation metric의 종류
더보기
Perplexity is the inverse probability of the test set normalized by the number of words
probability of the test set : 좋은 언어모델은 적합한 문장 에는 높은 확률 , 부적합한 문장 에는 낮은 확률 을 부여 → test set에 가장 높은 확률을 부여하는 모델이 좋은 모델
normalized by the number of words : 문장의 길이가 길수록 불확실성이 커질 수 있으므로 기하평균을 구하여 문장 길이에 대해 정규화를 수행한 다.
inverse : 역수
▮ 수식 이해
probability of the test set → unigram 모델의 문장 확률
normalized by the number of words & inverse
▮ 의미 이해
가정: 1부터 6까지 이루어진 주사위의 출현 확률이 같다.
N번 주사위를 던져 얻어내는 수열에 대한 PPL = 6 → 매 time-step마다 가능한 경우의 수가 6가지
다른 예) 만약 20,000개의 어휘로 이루어진 뉴스 기사에 대해 PPL을 측정할 때, 단어의 출현 확률이 모두 같다 면 → PPL은 20,000
⇒ 즉, 언어 모델에서 본다면 매 time-step마다 평균적으로 헷갈리고 있는 단어의 수라고 볼 수 있다.
테스트 문장에 대해 확률을 높게 예측할수록 좋은 언어 모델이기 때문에 확률의 역수값으로 PPL을 계산하므로 perplexity 값이 작을 수록 좋은 모델이다.
또는 PPL 값을 다음에 나올 단어에 대해 고민하고 있는 단어의 수라고 이해한다면 헷갈리는 단어의 수가 적을 수록 좋은 모델이라고 볼 수 있다.
ROGUE (Recall Oriented Understudy for Gisting Evaluation)
[Day 02]
기하 평균 :
데이터셋의 스케일이 다른 경우 사용할 수 있음
데이터가 곱의 관계 를 가지고 있는 경우
평균이 중앙값에 가깝도록 만들고 싶은 경우
불균형한 데이터 셋에 페널티를 주고 싶은 경우
조화 평균 :
데이터가 측정된 기간이 다른 경우 사용할 수 있음.
가중치가 있는 산술 평균에 사용할 수 있음
평균이 작은 값에 가깝도록 만들고 싶은 경우
불균형한 데이터 셋에 큰 페널티를 주고 싶은 경우
산술 평균 :
기하 평균, 조화 평균 사용이 필요없을 떄 또는 사용할 수 없을 때 사용할 수 있음.
데이터의 관계가 합의 관계 일 때 사용할 수 있음.
평균이 큰 값에 가깝도록 만들고 싶은 경우
▮ .contiguous()는 왜 사용하는 것일까?
텐서의 shape을 조작하는 과정에서 메모리 저장 상태가 변경되는 경우가 있다.
narrow(), view(), expand(), transpose()
해당 상태의 여부를 체크하지 않더라도 텐서를 다루는데 문제가 없는 경우가 많지만
RuntimeError: input is not contiguous 의 오류가 발생하는 경우에는
input tensor를 contiguous = True인 상태로 변경 해주어야한다.
[Day 03]
▮ 모델 학습 템플릿 구조 피드백
1. 🔁 함수마다 doc string과 type hinting을 추가하기
협업을 하는 데에 더 도움이 된다.
실제로 회사에서도 doc string, type hinting 같은 룰을 CI에 추가해서 없으면 커밋이 안되도록 하는 경우가 많다.
2. 🔁 좀 더 모듈화 하기
학습 코드 내부의 for step, batch in enumerate(self.train_dataloader): 부분을 따로 함수화 해서 train_per_one_batch(~) 와 같이 한번더 모듈화하면 좋다.
trainer.py
train.py를 보면 너무 길어서 한눈에 알아보기가 어렵다. ✅ 1. 데이터를 불러와서 데이터셋 클래스 및 데이터 로더에 넣어주는 부분도 함수화하기 → dataset/dataloader.py에 모듈화함
✅ 2. main 함수를 더 알아보기 쉽게 Optimizer 부분도 함수화 하기
계속 실험, 모델 개선을 반복하다 보면 모델이 많아지기 때문에 모델들을 config에 있는 이름만 가지고 불러올 수 있도록 구조화 해주는 것이 좋다. ✅ 기존 코드는 RoBertaBaseClassifier로만 정의하여 사용하기때문에 다른 모델을 사용하기 위해서는 코드 수정하기
🔁 라벨 -> id / id -> 라벨 변환을 하는 부분을 사실 json같은 파일로 관리하고 불러서 쓰도록 만들면 좋다. → 실무에서는 라벨이 자주 변하거나, 필요한 부분만 사용하거나 해서 변경하는 일이 종종 있어서, 코드상에 있는 것 보다 따로 관리하는 것이 편리하다!