Text → Token IDs → Embedding

LLM의 Transformer가 계산하는 것은 문자열 자체가 아니라 vector다. 먼저 Tokenizer가 문자열을 Vocabulary의 Token IDs로 바꾸고, 각 ID로 Embedding table의 행을 선택한다. Token ID는 의미의 크기나 순위를 나타내는 숫자가 아니라 table index다. 따라서 ID 두 개의 숫자가 가깝다는 이유만으로 의미도 가깝다고 해석할 수 없다.

Input Pipeline

Chat 입력에서는 structured messages를 먼저 하나의 문자열로 직렬화한다. Chat template가 role과 content, 다음 assistant 응답의 시작 등을 표현한 문자열을 만들면 그 결과가 일반 Tokenization pipeline으로 들어간다. Chat template를 적용한다고 해서 Tokenizer를 그때 새로 학습하는 것은 아니다.

다음 순서는 각 단계가 앞 단계의 결과를 받아 처리한다는 뜻이다.

1. Messages를 Chat template로 serialize한다.
2. 필요한 경우 Normalization으로 Unicode 표현·대소문자·accent 등을 정리한다.
3. 필요한 경우 Pre-tokenization으로 공백·문장부호·regex에 따른 chunk 경계를 정한다.
4. BPE, WordPiece, Unigram 같은 Subword model로 chunk를 pieces로 나눈다.
5. Special tokens / post-processing을 적용하고 Vocabulary indices인 Token IDs를 얻는다.
6. Token IDs로 Embedding lookup을 수행하여 vector sequence를 만든다.

Normalization과 Pre-tokenization은 optional이다. 시작·종료나 role 경계를 나타내는 special token은 일반 문자열처럼 조각나면 제 역할을 잃으므로, 하나의 온전한 ID로 처리할 수 있어야 한다. 이 경계가 있어야 모델이 문장의 시작·끝과 대화 구조를 학습하는 입력도 일관되게 구성할 수 있다.

Following One Input

슬라이드의 BERT-style trace에서는 “Strawberry Café!”를 lowercase와 accent 제거로 “strawberry cafe!”로 정리한다. 이어 공백·문장부호 경계를 나누고, str / aw / berry와 공백이 붙은 cafe, ! 같은 pieces를 만든다. [BOS]와 [EOS]를 붙이는 post-processing 뒤에는 이 pieces에 대응하는 IDs가 남는다. 이는 각 단계의 역할을 보여 주는 예시이며, 모든 Tokenizer가 같은 normalization이나 special token을 사용하는 것은 아니다.

같은 단어도 놓인 문맥에 따라 경계가 달라질 수 있다. 슬라이드의 cl100k_base 예시에서 strawberry 단독 입력은 str / aw / berry, IDs [496, 675, 15717]로 나뉘지만, 실제 질문에서는 앞 공백이 token의 일부가 될 수 있다. 모델이 문자 r 세 개를 세는 대신 여러 pieces를 받는다는 차이가 “How many r’s in strawberry?”를 어렵게 만든다. 9.9와 9.11도 digit position이 명시된 숫자로 직접 입력되는 것이 아니므로 분절 방식이 중요하지만, 그 비교 오류를 Tokenization 하나로 단정해서는 안 된다. 질문의 문맥도 결과에 영향을 줄 수 있다.

Tokenizer & Model Training

Tokenizer는 자신의 corpus와 algorithm으로 먼저 학습한 뒤 고정하며, 그다음 Transformer가 해당 ID 공간을 사용해 학습한다. 학습 절차의 독립성과 학습 결과에 대한 영향을 구분해야 한다. Tokenizer를 fitting하는 절차 자체가 Transformer의 Embedding과 backpropagation을 학습하는 절차는 아니지만, 어떤 pieces를 제공하느냐는 sequence 길이와 Embedding 학습, 최종 LM의 동작에 영향을 준다.

두 corpus가 어긋나면 이 문제는 더 분명해진다. Tokenizer Vocabulary에는 들어 있는데 LM training에서는 거의 등장하지 않는 token은, 사용할 수 있는 ID여도 해당 표현이 충분히 학습되지 않을 수 있다. 뒤에서 다룰 under-trained glitch token이 이런 경우다. 모델이 이상하게 실패할 때는 network만 보기 전에, 실제 입력이 어떤 IDs로 나뉘었는지부터 확인할 이유가 있다.

Check

Tokenizer를 모델과 독립적으로 학습한다는 것은 모델 결과와 무관하다는 뜻인가?

Answer

아니다. Tokenizer의 학습 절차는 독립적이지만, 분절과 ID 공간이 모델의 입력·sequence 길이·Embedding 학습을 결정한다.

Chat template는 pipeline 어디에 위치하며 모델이 받는 최종 표현은 무엇인가?

Answer

messages를 Tokenization 전에 문자열로 직렬화한다. Token IDs가 Embedding table의 행을 선택하고 모델 계산에는 그 vector가 들어간다.

Structured messages가 모델 입력 vector가 되기까지 순서를 설명하라.

Answer

Chat template로 serialize → optional Normalization → optional Pre-tokenization → Subword → special-token post-process → IDs → $E$[i] lookup.

Text에서 model input까지 빈 node를 채우고 각 단계의 역할을 설명하세요.

Answer

Raw Text / Messages → Chat template → Normalization (optional) → Pre-tokenization → Subword model → Special tokens / Token IDs → Embedding lookup 각 화살표가 입력/처리인지 사용 방식의 역사 흐름인지 구분해서 설명한다.