한국어 토크나이저 실험기 3 - 토큰 수를 줄이면 모델도 좋아질까

Table of contents

지난 이야기: 압축률에서 LM으로

2편까지의 질문은 비교적 단순했다.

같은 한국어 텍스트를 더 적은 토큰으로 표현하려면 무엇을 바꿔야 할까?

처음에는 형태소 경계가 핵심일 거라고 생각했다. 그런데 실험을 거듭할수록 더 큰 차이는 pre-tokenizer 쪽에서 나왔다. 특히 공백 처리가 중요했다. 공백을 따로 둘 것인지, 다음 어절 앞에 붙일 것인지에 따라 결과가 크게 달라졌다. 공백 전까지 넓게 잡는 ?\S+ 계열은 한국어 TPW를 낮추는 데 특히 강했다.

여기까지만 보면 결론은 꽤 깔끔해 보인다.

토큰 수가 줄면 학습 비용과 추론 비용이 줄어든다. 같은 context window 안에 더 많은 글을 넣을 수도 있다. 로컬 환경에서 모델을 만들 때 이 차이는 작지 않다. 그래서 TPW는 분명 중요한 지표다.

하지만 언어 모델은 결국 다음 토큰을 맞히는 모델이다. 토큰 수를 줄이는 대신 토큰 하나하나가 너무 어려운 문제가 되면, 전체 성능은 오히려 나빠질 수 있다.

그래서 3편은 질문을 바꿔서 시작했다.

TPW가 낮은 토크나이저는 실제 LM 학습에도 유리할까?

이번 글은 이 질문을 따라간 기록이다. 결론부터 말하면, 답은 단순하지 않았다. TPW 기준으로 좋아 보였던 토크나이저로 실제 LM을 학습해 보니 오히려 좋지 않은 결과가 나왔다. 이때부터 실험의 초점도 바뀌었다. 이제는 “얼마나 짧게 표현하는가”만 볼 수 없었다. “짧으면서도 언어 모델이 배우기 쉬운 단위는 무엇인가”를 봐야 했다.

왜 BPB를 봐야 하나

토크나이저 자체만 볼 때는 토큰 수를 세면 된다. 같은 문장을 더 적은 토큰으로 표현하면 압축률이 좋다고 말할 수 있다. TPW, Fertility, CFert 같은 지표가 여기에 속한다.

언어 모델까지 보려면 한 단계가 더 필요하다. 토크나이저가 만든 토큰열을 모델이 얼마나 잘 예측하는지 봐야 한다.

가장 흔히 쓰는 값은 per-token loss다. 다음 토큰 하나를 맞힐 때 평균 손실이 얼마나 큰지 나타낸다. 같은 토크나이저로 학습한 모델끼리 비교할 때는 이 값도 충분히 쓸 만하다.

문제는 토크나이저가 달라질 때 생긴다.

예를 들어 어떤 토크나이저는 대한민국에서를 긴 토큰 하나로 만들 수 있다. 다른 토크나이저는 대한민국과 에서로 나누거나, 더 작은 조각으로 쪼갤 수도 있다. 이때 per-token loss를 그대로 비교하면 공정하지 않다. 두 모델이 맞혀야 하는 “토큰 하나”가 같은 양의 정보를 담고 있지 않기 때문이다.

그래서 비교 단위를 원문으로 돌려야 한다. 이때 필요한 값이 BPB(Bits Per Byte)다.

BPB는 낮을수록 좋다. 같은 원문을 놓고, 모델이 바이트당 얼마나 적은 손실로 예측하는지 나타낸다.

토큰 수를 줄이면 모델이 처리할 토큰 개수는 줄어든다. 대신 토큰 하나가 더 많은 정보를 떠안는다. 긴 토큰은 압축에는 유리하지만 예측은 어려울 수 있다. 짧은 토큰은 개수는 늘지만, 토큰 하나를 맞히는 부담은 줄어든다.

결국 봐야 할 것은 이 균형이다.

비교: C100과 WS

먼저 비교 대상을 두 개로 좁혔다.

C100은 널리 쓰이는 계열에 가까운 비교 대상이다. 영어, 숫자, 기호를 꽤 세밀하게 나눈다. 반대로 WS는 공백 전까지 크게 잡는다. GPT-4를 같은 한국어 혼합 표현을 BPE가 더 자유롭게 배울 수 있다는 장점이 있었다.

실험 조건은 최대한 단순하게 맞췄다.

이 실험의 목적은 큰 모델의 최종 성능을 판정하는 데 있지 않았다. 토크나이저 차이가 LM 학습으로 넘어가면 어떤 방향으로 움직이는지 먼저 보고 싶었다. 그래서 작은 규모의 실험부터 시작했다. 여러 checkpoint를 남기고, 같은 평가셋에서 BPB를 반복 측정했다.

결과: 예상보다 빨리 뒤집혔다

먼저 전체 흐름부터 보자. 여기서 x축은 누적 학습 토큰이 아니라 optimizer step이다. WS는 같은 원문을 더 적은 토큰으로 표현하므로, C100보다 더 이른 시점에 1 epoch가 끝난다.

전체 그래프를 보면 최종 결과는 알 수 있다. 마지막 손실은 C100이 더 낮다. 다만 이 그래프만으로는 중요한 순간이 잘 보이지 않는다. 두 곡선이 갈라지는 지점은 학습 초반에 있다.

그래서 초반부만 다시 확대했다.

초반만 보면 WS가 더 좋아 보인다. 압축률이 좋은 토크나이저가 학습 초기에 유리할 수 있다는 생각과도 잘 맞았다.

그런데 이 우위는 오래 가지 않았다.

C100은 곧 WS를 따라잡고, 이후에는 더 낮은 손실로 내려간다. 여기서 첫 번째 문제가 생겼다.

토큰 수를 더 아끼는 WS가, 왜 LM 학습 곡선에선 C100에 밀릴까?

그래프 하나만 보고 결론을 낼 수는 없다. 학습 로그는 흔들리고, 기록 방식에 따라 값의 스케일도 달라질 수 있다. 그래서 별도로 저장해 둔 평가 checkpoint를 다시 봤다. 아래 표는 같은 평가셋에서 측정한 BPB다. 이번에는 optimizer step이 아니라 누적 학습량으로 정리했다.

고정 평가에서도 같은 방향이 나왔다.

가능한 설명은 몇 가지다.

첫째, WS는 토큰 수가 적으니 같은 원문 코퍼스를 한 번 훑어도 optimizer update 수가 줄어든다. 단순히 덜 학습해서 진 것일 수 있다.

둘째, WS가 긴 토큰을 많이 만들면서 드문 토큰이 늘어났을 수 있다. 드문 토큰은 embedding이 충분히 학습되지 않았을 가능성이 있다.

셋째, WS가 만든 토큰열 자체가 transformer LM이 배우기 어려운 형태였을 수 있다.

처음에는 이 세 가지를 차례로 의심했다.

첫 번째 의심: 학습량이 달랐나

가장 먼저 확인한 건 가장 쉬운 반론이었다.

WS가 나빠서가 아니라, 그냥 덜 학습해서 진 것 아닐까?

이 반론은 꽤 타당했다.

WS는 C100보다 원문을 더 적은 토큰으로 표현한다. 같은 원문 코퍼스를 한 번 학습해도 모델이 실제로 보는 token 수와 optimizer update 수가 달라진다. C100은 1 epoch 동안 약 2.45B token을 보고 4,747번 update된다. WS는 같은 원문을 약 2.23B token으로 표현하므로 4,322번만 update된다.

그러니 1 epoch 결과만 놓고 “C100이 더 좋다”고 말하면 찜찜하다. C100이 정말 더 좋은 토크나이저라서 앞선 것인지, 아니면 WS가 약 9% 적게 update되어 뒤처진 것인지 나눠 봐야 한다.

그래서 비교 기준을 두 단계로 나눴다.

이 실험은 한 번의 update가 소비하는 token 수가 고정되어 있다. 그래서 update 수를 맞추면 token budget도 거의 함께 맞춰진다.

결과는 다음과 같았다. 값은 네 도메인 평가셋의 평균 BPB이고, 낮을수록 좋다.

중요한 줄은 두 번째다. WS가 단순히 update를 덜 받아서 진 것이라면, C100과 같은 4,747 update까지 더 돌렸을 때 격차가 크게 줄거나 뒤집혀야 한다. 하지만 결과는 거의 그대로였다.

따라서 첫 번째 설명은 힘이 약해졌다. 학습량 차이가 아예 없다고 말할 수는 없지만, WS와 C100의 역전을 설명하는 주된 원인으로 보기는 어려웠다.

두 번째 의심: rare token이 문제였나

다음으로 본 것은 long tail이었다. 쉽게 말하면 “드문 토큰이 너무 많아진 것 아닐까?”라는 의심이다.

토크나이저가 긴 토큰을 많이 만들면 vocab 안에 드물게 등장하는 토큰이 많아질 수 있다. 이런 토큰은 학습 중 충분히 자주 업데이트되지 않는다. embedding이 덜 학습되면 모델은 그 토큰을 잘 예측하지 못하고, BPB도 나빠질 수 있다.

WS를 처음 의심한 이유도 여기에 있었다. 공백 전까지 넓게 잡으면 긴 단어형 토큰이 늘어난다. 긴 토큰이 많아지면 드문 토큰도 늘어날 것 같았다.

그래서 vocab 사용 빈도와 embedding norm을 확인했다.

결과는 예상과 달랐다.

WS가 더 많은 rare token을 만들었을 거라 생각했는데, rare token 비율은 오히려 C100이 높았다. WS는 중간 빈도 구간에 더 많이 몰려 있었다. embedding norm도 큰 차이가 없었다.

물론 이 표 하나로 long tail 문제가 전혀 없다고 말할 수는 없다. rare token 비율만으로 모든 것을 설명할 수는 없기 때문이다. 어떤 토큰이 드문지, 그 토큰이 어느 위치에 나오는지, loss가 어디에 몰리는지도 봐야 한다.

하지만 적어도 처음 떠올린 단순한 설명은 맞지 않았다.

WS는 rare token이 많아서 졌다.

이 문장은 데이터와 맞지 않았다.

세 번째 의심: 토큰열 자체가 어려웠나

그다음에는 토큰열 자체의 난이도를 봤다.

혹시 WS가 만든 토큰열이 언어 모델에게 더 어려운 문제였을까. 긴 토큰을 많이 만들면 다음 토큰 예측이 어려워질 수 있다. 그러면 WS는 TPW는 낮지만, LM이 배우기에는 더 어려운 시퀀스를 만들었을 수 있다.

이를 확인하려고 Kneser-Ney trigram 모델을 학습했다.

trigram은 transformer보다 훨씬 단순하다. 긴 문맥을 보지 않고 최근 몇 개 토큰만 본다. 대신 토큰열의 국소적인 예측 가능성을 확인하는 데는 쓸 수 있다. 만약 WS 토큰열 자체가 더 어려운 문제라면, trigram에서도 WS가 나빠질 가능성이 컸다.

결과는 또 예상과 달랐다.

trigram 기준으로는 WS가 4개 도메인 모두 좋았다. 지역적인 n-gram 관점에서 보면 WS 토큰열이 오히려 더 예측하기 쉬웠다.

그런데 transformer LM은 C100을 더 잘 배웠다.

이 지점이 중요했다.

WS는 단순 n-gram 모델에는 더 쉬운 문제를 만든다. 하지만 transformer LM으로 넘어오면 이야기가 달라진다. WS는 trigram 대비 개선 폭이 작았고, C100은 그보다 훨씬 많이 좋아졌다. C100 토큰열은 trigram에는 조금 더 어려웠지만, transformer가 배울 여지는 더 많았던 셈이다.

즉 문제는 “어느 토큰열이 더 쉬운가”가 아니었다.

더 정확한 질문은 이쪽에 가까웠다.

transformer LM은 어떤 토큰열에서 더 많이 배울 수 있는가?

이 질문은 TPW만으로 답할 수 없다. trigram만으로도 부족했다. 그래서 손실이 실제로 어디에 몰리는지 더 쪼개 보기 시작했다.

손실 위치를 쪼개 보기

이제 전체 BPB 대신 토큰 단위 손실을 나눠 봤다. 길이별로, 위치별로, 토큰 종류별로 나누어 WS가 어디서 어려워지는지 확인했다.

가장 먼저 눈에 띈 것은 긴 word-initial token이었다. 여기서는 편하게 “어절 시작 토큰”이라고 부르겠다.

word-initial은 단어 또는 어절의 시작 위치에 있는 토큰이다. ByteLevel BPE는 앞 공백이 붙은 토큰이 이 역할을 많이 한다. WS는 공백부터 다음 공백 전까지 넓게 잡기 때문에 긴 어절 시작 토큰을 만들기 쉽다.

길이별 NLL 차이는 꽤 선명했다.

16 bytes 이상인 어절 시작 토큰에서 WS 손실이 크게 튀었다.

이건 어느 정도 이해할 수 있다. 대한민국에서 같은 표현이 하나의 긴 토큰에 가까워질수록 토큰 수는 줄어든다. 하지만 모델은 대한민국과 에서를 따로 배울 기회를 덜 얻는다. 자주 나오는 표현이라면 괜찮을 수 있다. 드문 조합이라면 갑자기 어려운 예측 문제가 된다.

특히 어절 시작 토큰은 문맥의 새 단위가 시작되는 자리다. 여기서 긴 토큰이 나오면 모델은 다음 어절의 시작을 통째로 맞혀야 한다. 압축률만 보면 이득이지만, LM에는 부담이 될 수 있다.

그래서 다음 실험은 자연스럽게 정해졌다.

긴 word-initial token만 골라 쪼개면 WS가 회복될까?

P11: 긴 word-initial token을 쪼개 보기

P11은 이 질문을 직접 확인하기 위한 실험이었다.

WS를 기준으로 몇 가지 변형을 만들었다. 핵심은 긴 토큰을 무작정 다 쪼개지 않는 데 있다. 의심되는 위치만 건드렸다.

설계 의도는 세 가지였다.

첫째, 긴 word-initial token이 정말 문제라면 IS16이나 IS12는 WS보다 좋아져야 한다.
둘째, continuation token을 건드린 CS16은 같은 효과를 내면 안 된다. 그래야 손실 위치가 word-initial 쪽이라는 해석이 힘을 얻는다.
셋째, 16 bytes보다 12 bytes 기준이 더 강한 개입이므로, IS12가 IS16보다 더 큰 효과를 내면 dose-response를 확인할 수 있다.

100M 결과는 이렇게 나왔다.

결과는 반쯤 맞고 반쯤 틀렸다.

IS16은 WS보다 좋아지지 않았다. 16 bytes 기준은 너무 약했거나, 건드린 토큰 집합이 전체 BPB를 움직일 만큼 크지 않았던 것으로 보인다. 반면 IS12는 WS보다 ALL과 ko에서 좋아졌다. 어절 시작 토큰을 더 적극적으로 쪼개면 일부 회복이 있었다.

CS16은 대체로 WS 근처에 머물렀다. continuation token을 건드리는 쪽은 핵심 설명이 아니었다. 이 점은 중요하다. 긴 토큰이 전부 문제라기보다, 긴 토큰이 어느 위치에 놓이는지가 중요했다.

하지만 이 실험도 답을 완전히 주지는 않았다.

IS12는 한국어와 전체 BPB를 조금 회복했지만, code와 math는 오히려 손해가 컸다. 한국어 어절 시작 토큰에는 도움이 되는 개입이 다른 도메인에는 독이 될 수 있었다. 토크나이저는 한 언어만 처리하지 않는다. 코퍼스가 한국어 중심이어도 영어, 코드, 수식이 함께 들어가면 한쪽에서 좋은 규칙이 다른 쪽을 흔들 수 있다.

이때부터 “한국어 긴 토큰만 잘라내면 된다”는 설명도 조심스러워졌다.

긴 word-initial token은 원인 중 하나였다. 하지만 WS와 C100의 차이를 전부 설명하지는 못했다.

남은 단서: 넓게 잡은 만큼 부작용도 생겼다

P11 이후에는 WS의 vocab과 merge를 더 자세히 봤다.

여기서 또 다른 단서가 나왔다. WS는 영문 문자와 기호가 섞인 토큰을 많이 만들고 있었다.

WS의 ?\S+는 공백 전까지 넓게 잡는다. 이 방식은 한국어 혼합 표현에는 도움이 된다. GPT-4를 같은 표현에서 숫자와 조사가 한 토큰으로 만들어질 수 있고, 숫자와 조사, 기호와 한국어가 붙은 표현을 더 짧게 표현할 수 있다.

하지만 같은 자유도는 영어와 코드에서 다른 결과를 낳는다.

foo(, name=, value,, path/ 같은 조합도 한 토큰이 될 수 있다. 토큰 수만 보면 이득처럼 보인다. 하지만 LM이 배우기에는 애매하다. 영문 식별자와 기호 구조가 한 토큰 안에 섞이면, 여러 문맥에서 다시 쓰기 좋은 조각이 흐려질 수 있다. code처럼 기호와 나누는 위치가 중요한 도메인은 특히 더 흔들릴 수 있다.

factorization audit에서 본 차이는 컸다.

이 표는 WS의 장점과 단점을 동시에 말해 준다.

WS는 BPE가 더 넓은 범위 안에서 토큰을 만들 수 있다. 한국어 혼합 표현에선 장점이었다. 2편의 TPW 개선도 여기서 나왔다. 하지만 넓게 잡은 만큼 부작용도 생겼다. 특히 영문+기호 조합은 LM이 다시 쓰기 좋은 조각이라기보다, 특정 표면형을 외운 토큰에 가까워질 수 있다.

결국 pre-tokenizer의 문제는 “크게 묶느냐, 작게 자르느냐”만이 아니었다.

무엇을 한 덩어리로 보고, 무엇을 따로 나누어야 할까?

이 질문이 남았다.

도메인별 최선 조합도 확인했다

여기까지 오면 한 가지 생각이 든다.

한 가지 regex로 모든 도메인을 처리하지 말고, 도메인마다 잘 맞는 규칙을 따로 고르면 어떨까?

한국어, 영어, 코드, 수식은 서로 다른 텍스트다. 한국어에는 조사와 어미가 붙고, 영어에는 축약형이 있고, 코드는 괄호와 들여쓰기가 중요하고, 수식에는 숫자와 기호가 자주 나온다. 그러니 한 규칙으로 모두를 처리하는 대신, 도메인마다 따로 후보를 만들고 그중 가장 나은 규칙을 모으면 더 좋아질 것 같았다.

이 실험은 처음부터 “한 번에 좋은 regex를 만들자”가 아니었다. 먼저 후보를 도메인별로 쪼갰다. 한국어 후보 9개, 영어 후보 4개, 코드 후보 5개, 수식 후보 4개를 따로 만들었다. 각 후보는 36K vocab으로 BPE를 학습했고, 같은 구조의 작은 LM을 100M tokens만큼 학습했다. 그 뒤 같은 holdout에서 Fixed BPB를 재서 도메인별로 가장 낮은 후보를 골랐다.

중요한 점은 TPW로 고른 게 아니라는 것이다. 실제로 한국어 후보 중 일부는 TPW가 나빠졌지만 BPB는 더 좋아졌다. 이 글에서 계속 보는 그 역전 현상이다. 그래서 여기서는 “토큰 수를 적게 쓰는 후보”가 아니라, “LM이 실제로 더 잘 예측한 후보”를 골랐다.

도메인별 선택은 다음과 같았다.

그다음 이 네 도메인에서 고른 규칙을 하나의 pre-tokenizer로 합쳤다. 여기에 기본 Latin branch, 한국어 의 예외어 24개, fallback branch를 더했다. 이 글에선 이 통합 버전을 도메인별 최선 조합이라고 부르겠다.

실제 pre-tokenizer는 하나의 긴 Split regex였다. 아래는 tokenizer.json에 들어간 pattern을 보기 좋게 줄바꿈한 것이다. 각 줄은 |로 이어지는 branch다.

1
(?i:'s|'t|'re|'ve|'m|'ll|'d)
2
| ?\p{Latin}[\p{Latin}\p{M}\p{N}]*
3
|\s*[\r\n]+
4
|(?:\t| {4})+
5
|\s+(?=\p{N})
6
|\p{N}{1,3}
7
| ?(?:강의|건의|결의|경의|고의|논의|동의|문의|상의|유의|의의|이의|임의|정의|제의|주의|창의|토의|편의|합의|항의|혐의|호의|회의)(?=[^\uAC00-\uD7AF]|$)
8
| ?[\uAC00-\uD7AF]+?(?=에서는|이라는|이라고|으로는|습니다|적으로|으로|에서|에게|에는|에도|들을|되어|되는|적인|는데|보다|이나|으면|으며|하며|되고|으나|는지|었던|처럼|는게|되지|들은|들의|까지|도록|다고|들이|하는|하고|된(?:[^\uAC00-\uD7AF]|$)|될(?:[^\uAC00-\uD7AF]|$)|을(?:[^\uAC00-\uD7AF]|$)|를(?:[^\uAC00-\uD7AF]|$)|할(?:[^\uAC00-\uD7AF]|$)|던(?:[^\uAC00-\uD7AF]|$)|에(?:[^\uAC00-\uD7AF]|$)|은(?:[^\uAC00-\uD7AF]|$)|의(?:[^\uAC00-\uD7AF]|$))
9
|에서는(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
10
|이라는(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
11
|이라고(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
12
|으로는(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
13
|습니다(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
14
|적으로(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
15
|으로(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
16
|에서(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
17
|에게(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
18
|에는(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
19
|에도(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
20
|들을(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
21
|되어(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
22
|되는(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
23
|적인(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
24
|는데(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
25
|보다(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
26
|이나(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
27
|으면(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
28
|으며(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
29
|하며(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
30
|되고(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
31
|으나(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
32
|는지(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
33
|었던(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
34
|처럼(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
35
|는게(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
36
|되지(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
37
|들은(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
38
|들의(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
39
|까지(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
40
|도록(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
41
|다고(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
42
|들이(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
43
|하는(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
44
|하고(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
45
|된(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
46
|될(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
47
|을(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
48
|를(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
49
|할(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
50
|던(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
51
|에(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
52
|은(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
53
|의(?=[^\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]|$)
54
| ?[\uAC00-\uD7AF\u1100-\u11FF\u3130-\u318F]+
55
| ?[^\s\p{L}\p{N}]+
56
| ?\S+

이 Split regex 뒤에는 ByteLevel pre-tokenizer를 붙였다. 설정은 add_prefix_space=false, trim_offsets=true, use_regex=false였다.

100M 학습 결과만 보면 이 방향은 꽤 설득력 있었다. 같은 102K vocab, 같은 E30 코퍼스, 같은 LM 설정에서 도메인별 최선 조합은 ALL BPB 1.7520을 기록했다. C100은 1.8128, WS는 1.9947이었다. 줄바꿈과 들여쓰기 구조를 따로 다루고, 수식의 숫자를 3자리 단위로 묶은 규칙이 학습 초반에 도움이 된 셈이다.

그런데 이런 우위가 오래 지속되지 않는다. 학습을 1000M까지 진행하면 순위가 다시 바뀐다.

흐름은 조금 복잡하다. 10M과 25M은 WS가 가장 낮다. 이건 앞에서 본 초기 학습 곡선과도 맞다. 50M부터 200M까지는 도메인별 최선 조합이 강했다. 도메인마다 따로 고른 규칙이 초반 수렴을 빠르게 만든 것이다.

하지만 300M부터는 C100이 다시 앞선다. 1000M까지 가면 순위는 더 분명해진다. 도메인별 최선 조합은 WS보다 낫지만, C100보다 나아지진 못했다.

1000M 지점의 도메인별 BPB는 다음과 같다.

100M 근처는 도메인별 최선 조합이 가장 좋았다. 하지만 1000M 기준으로는 C100이 모든 도메인에서 가장 낮은 BPB를 냈다. 도메인별 최선 조합은 WS보다 나았지만, 길게 학습하면 C100을 넘지 못했다.

문제는 구조를 보면 더 분명해진다.

도메인별 최선 조합은 의도한 대로 여러 지점을 미리 나누어 두었다. 문제는 이 방식이 BPE의 자유도까지 줄였다는 점이다. 호텔에서, 구두를, 규범을 같은 표현을 자주 보면 BPE는 그 안에서 다시 쓰기 좋은 긴 토큰을 만들 수 있다. 하지만 너무 많이 나누어 놓으면 이런 길이 막힌다.

실제로 WS는 이런 한글 경계 통합 토큰을 12,238개 만들었지만, 도메인별 최선 조합은 709개에 그쳤다. 같은 한국어 텍스트를 표현할 때도 WS는 토큰 하나당 평균 6.644 bytes를 담았고, 도메인별 최선 조합은 5.503 bytes에 머물렀다. 즉 도메인별 최선 조합은 더 잘게 쪼개는 대신 초기 학습을 쉽게 만든 셈이다.

이건 단순히 “잘게 나누면 나쁘다”는 이야기가 아니다. 100M 기준으로는 그 잘게 나누는 방식이 분명 도움이 됐다. 모델이 작은 조각을 빠르게 익힐 수 있었기 때문이다. 하지만 학습이 길어지면 자주 함께 나오는 표현을 한 토큰으로 만들어 다시 쓰는 능력이 중요해진다. 이때는 너무 많은 지점을 미리 나누어 둔 것이 오히려 손해가 됐다.

결국 질문은 다시 돌아온다.

무엇을 한 토큰으로 보고, 무엇을 따로 나누어야 할까?

한쪽 끝에는 WS처럼 넓은 범위를 한 덩어리로 보는 방식이 있고, 다른 쪽에는 도메인별 최선 조합처럼 미리 많이 나누어 두는 방식이 있다. 도메인별 최선 조합은 단거리형 토크나이저에 가까웠다. 100M급 실험에는 강했지만, 1B까지 학습량을 늘리면 더 단순한 C100이 다시 앞섰다.

3편 정리: TPW 이후에 봐야 할 것

이번 편에서 확인한 것은 단순하다. TPW는 중요하지만 충분하지 않다. 토큰 수를 줄여도, 그 토큰이 모델이 배우기 어려운 단위라면 BPB는 좋아지지 않는다.

WS는 한국어를 짧게 표현했다. 하지만 LM 학습으로 넘어가자 C100보다 불리했다. 학습량 차이만으로 설명되지 않았고, rare token만으로도 설명되지 않았다. 더 중요한 단서는 긴 어절 시작 토큰과, 넓게 잡은 규칙이 만든 부작용이었다.

결국 좋은 토크나이저는 짧게 표현하는 데서 끝나지 않는다. 모델이 다시 쓰기 좋은 조각을 남겨야 한다. 무엇을 한 토큰으로 보고, 무엇을 따로 나눌지 정해야 한다.

이 말을 곰곰이 생각해 보면 결국 언어학적으로 자연스럽게 나누는 일과 닮아 있다. 모델이 배우기 좋은 단위는 아무 곳에서나 생기지 않는다. 자주 반복되고, 여러 문맥에서 재사용되며, 의미나 문법 기능이 어느 정도 안정적인 조각이어야 한다.

그러면 자연스럽게 앞에서 묻어 둔 질문이 다시 올라온다.

형태소 정보를 활용해 나누는 것이 도움이 될까?

1편에서 형태소 경계 penalty는 거의 듣지 않았다. BPE가 merge를 고르는 순간 점수를 조금 깎는 정도로는 충분하지 않았다. 그렇다고 형태소 단위로 나누어 보자는 생각 자체가 쓸모없다는 뜻은 아니었다. 그때의 실패는 “형태소가 틀렸다”가 아니라 “그 위치에, 그 강도로 넣는 방식은 약했다”에 가까웠다.

이번 편을 지나오며 질문은 더 좁아졌다. 이제 보고 싶은 것은 단순히 TPW를 낮추는 방식이 아니다. LM이 실제로 학습할 수 있고, 긴 학습 뒤에도 무너지지 않는 단위다. 그 단위가 언어학적 단위와 얼마나 맞물리는지, 형태소 정보를 토크나이저 내부에 넣어야 하는지, 아니면 학습 데이터나 보조 목표 쪽에 넣어야 하는지를 다시 봐야 했다.

그래서 형태소를 다시 꺼냈다. 이번에는 “한국어는 형태소가 중요하니까 넣으면 좋아질 것”이라는 출발점이 아니었다. WS와 C100의 역전, 긴 어절 시작 토큰의 손실, 도메인별 최선 조합의 단기 우위와 장기 한계를 본 뒤에야 나온 질문이었다. 형태소는 정답이라서 돌아온 게 아니라, 좋은 경계를 찾다 보니 다시 마주친 후보였다.

다음 편은 이 질문을 다룬다. 형태소를 다시 꺼내되, 이번에는 훨씬 조심스럽게 꺼낸다. “한국어는 형태소가 중요하니까 넣으면 좋아진다”는 말은 이미 한 번 무너졌다. 이제 봐야 할 것은 형태소 정보를 어디에, 얼마나, 어떤 비용으로 넣어야 모델이 실제로 쓸 수 있느냐다.