Subword

Tokenization의 단위를 작게 잡으면 낯선 문자열도 표현하기 쉽지만 sequence가 길어진다. 반대로 단어 전체를 하나의 token으로 삼으면 sequence는 짧아져도 사전에 담아야 할 경우의 수가 커진다. Subword는 이 두 비용 사이의 절충이다. 자주 나오는 문자열은 묶고 희귀 문자열은 작은 pieces로 표현하되, 그 경계가 사람이 생각하는 morpheme과 일치할 필요는 없다.

Segmentation Units

예를 들어 unhappiness를 Character-level로 나누면 u / n / h / a / p / p / i / n / e / s / s의 11 tokens가 된다. Word-level에서는 사전에 있다면 1 token이지만, 없다면 [UNK] 하나로 대체되어 어떤 단어였는지 잃을 수 있다. 슬라이드의 Subword 예시는 un / happi / ness의 3 tokens다. un이나 ness 같은 piece는 다른 문자열에서도 재사용할 수 있다.

Character-level의 장점은 작은 Vocabulary와 명시적인 spelling이다. 그러나 English에서 sequence가 약 4배 길어진다면 pairwise Attention의 $n^2$ 항은 약 16배가 된다. 같은 Context Length 안에 담을 수 있는 원문의 양도 줄어든다. 작은 Vocabulary만으로 비용을 판단할 수 없다는 뜻이다. 유한한 compute와 context budget에서는 token 수 $n$의 증가도 함께 계산해야 한다.

Word-level은 반대 문제가 생긴다. unseen word를 구분하려면 Vocabulary를 계속 키워야 하며, Embedding table의 $V\times d$ 비용도 커진다. 특히 한국어처럼 어간에 조사와 어미가 붙는 교착어에서 학교 / 학교에서 / 학교에서만 같은 surface form을 각각 등록하면 경우의 수가 빠르게 늘어난다. Subword는 고정된 적당한 Vocabulary로 이 조합들을 표현하려는 방법이다.

Positions & Types

Context Length는 position의 수이고, Vocabulary Size는 각 position에서 선택할 수 있는 ID의 종류 수다. 128K context라면 최대 약 128K개의 칸을 사용하는 것이고, 약 200K Vocabulary라면 각 칸에 들어갈 ID를 약 200K개의 선택지에서 고르는 것이다. Llama 3의 128K Vocabulary / 8K context 예시는 두 값을 별도로 정한다는 것을 보여 준다.

English에서 1 token ≈ 4 characters ≈ 0.75 words라는 수치는 평균적인 근사다. 이를 적용하면 128K tokens는 대략 96K English words에 해당하지만, 그 공간은 prompt만의 공간이 아니다. System prompt와 대화 이력, 생성할 answer도 함께 고려해야 한다. 또 Context Length가 같아도 Tokenizer가 다르면 담기는 실제 원문의 길이는 달라진다.

슬라이드에 제시된 Vocabulary 규모는 GPT-2 약 50K, cl100k / GPT-4 약 100K, Llama 3 약 128K, o200k / GPT-4o 약 200K로 커진다. 이것을 읽는 능력의 길이가 같은 비율로 늘어난 것으로 해석하지 말고, position마다 사용할 ID 종류가 늘어난 것으로 읽어야 한다.

Same Meaning, Different Token Counts

cl100k_base 예시에서 “The weather is nice today.”는 The / 공백 weather / 공백 is / 공백 nice / 공백 today / .의 6 tokens다. 같은 의미의 “오늘은 날씨가 좋다.”는 14 tokens를 사용한다. 눈에는 9개 음절·기호처럼 보여도 한글 음절 하나가 반드시 token 하나는 아니다. 예를 들어 씨의 UTF-8 표현은 EC 94 A8이고, 희귀 음절은 학습된 merge가 부족해 byte 단위로 더 나뉠 수 있다.

따라서 같은 의미의 글을 넣어도 token 수가 많아지면 비용과 latency가 늘고, 같은 context 안에 담을 수 있는 의미의 양은 줄어든다. 실제 입력을 비교할 때는 자신의 이름, chemical formula, Python code, emoji처럼 분포가 다른 문자열도 직접 분절해 보아야 한다. 겉으로 보이는 글자 수만으로 처리량을 추정하면 이 차이를 놓친다.

Check

Character로 바꾸어 sequence 길이가 4배가 되면 pairwise Attention 항은 어떻게 변하는가?

128K Vocabulary를 가지면 128K tokens를 한 번에 읽을 수 있는가?

Character · Word · Subword를 축별로 비교하고 그 차이가 필요한 이유를 설명하세요.

Related

• Vocabulary Size
• FLOPs
• Fertility & Token Tax