STUDYLLM
‹ Lecture 2 12 / 23

Special Tokens & Chat Templates

Chat UI에서는 system, user, assistant가 다른 영역에 보이지만 모델에 들어갈 때는 하나의 token sequence가 된다. 어느 내용이 누구의 발화인지, 어디서 turn이 끝나는지를 그 sequence 안에 표시해야 한다. Chat template는 이 구조를 문자열로 직렬화하고, Special tokens는 경계를 나타내는 atomic IDs를 제공한다. 화면의 대화 구조가 자동으로 모델 입력 구조가 되는 것은 아니다.

  1. Structured messages
  2. checkpoint Chat template
  3. control markers 포함 문자열
  4. Token IDs

Reserved IDs

Sequence boundary는 전체 입력의 시작·끝을, role/turn boundary는 발화자와 메시지 끝을 나타낸다. 예를 들어 Llama 3의 begin_of_text와 end_of_text는 전자이고, start_header_id·end_header_id·eot_id는 후자의 역할을 한다. Tool protocol 표지는 tool call과 result를 일반 발화에서 구분하는 데 쓰이며, 이름과 format은 모델마다 다르다.

Padding은 길이가 다른 sequences를 batch의 같은 matrix shape에 맞추는 용도다. Unknown token은 OOV fallback 역할이지만 byte BPE에서는 호출할 필요가 드물다. Reserved capacity는 나중에 새 format을 넣을 공간으로, 처음부터 의미가 충분히 학습되어 있다는 뜻은 아니다. 예를 들어 tool 전용 표지로 배정했다면 그 사용법도 추가 학습해야 한다.

Llama 3 예시는 128,000 mergeable + 256 special = 128,256 rows이며, special 영역은 IDs 128,000–128,255다. 슬라이드는 이 중 약 251개를 reserved 공간으로 설명한다. 일반 BPE merge로 새 특수 표지를 만들어 내는 것이 아니라 별도로 등록한다.

Special tokens는 BPE merge로 생기지 않고 등록된 atomic IDs다. eot_id128009, GPT2 endoftext50256, BERT SEP102처럼 모델마다 string/ID가 다르다.

Chat Templates

Llama3 template는 begin_of_text → start_header_id/role/end_header_id → 실제 두 newline → content → eot_id를 이어 붙이고 생성 시 assistant header를 끝에 둔다. tokenizer.chat_template의 Jinja 규칙은 weights 자체와 별개다. Base/instruct·checkpoint별 format이 다르므로 맞지 않아도 에러 없이 품질이 떨어질 수 있다.

Reading a Serialized Conversation

System content가 Be brief., user content가 Hi!라면 Llama 3의 문자열은 다음 구조다. Header 다음 빈 줄은 실제 두 newline이며, 마지막 assistant header 뒤에서 모델이 응답을 이어 쓴다.

<|begin_of_text|><|start_header_id|>system<|end_header_id|>

Be brief.<|eot_id|><|start_header_id|>user<|end_header_id|>

Hi!<|eot_id|><|start_header_id|>assistant<|end_header_id|>

Jinja template는 각 message의 role과 content를 정해진 자리에 채워 이 문자열을 만든다. apply_chat_template는 그 적용 절차이고, generation prompt 설정은 다음 assistant 발화가 시작될 header를 덧붙일 수 있다. Template 문자열은 Tokenizer와 함께 저장되는 규칙이며 model weights 안의 별도 network가 아니다.

모델은 학습할 때 보았던 control-token sequence를 기준으로 이어 쓸 내용을 배운다. 다른 checkpoint의 template를 사용하거나 atomic token을 일반 조각으로 분리하면, 문장은 들어가도 학습 때의 경계는 달라진다. 이 때문에 에러가 없는데 답의 품질이 떨어지는 silent mismatch가 생길 수 있다.

Role/turn 표지도 결국 checkpoint별 token format이다.

Check

Special token과 BPE merge로 만들어진 일반 token의 생성 방식 차이는?

Answer

Special token은 별도로 예약·등록한 atomic ID다. Merge rank로 일반 substring을 합치는 과정에서 생기지 않는다.

Chat template가 틀려도 코드가 실행되면 왜 결과를 신뢰할 수 없는가?

Answer

모델이 학습한 role/turn control IDs와 실제 입력이 어긋나도 예외가 없을 수 있다. 최종 IDs와 decode된 문자열을 확인해야 한다.

Contents