STUDYLLM
‹ Lecture 2 04 / 23

Unicode & Normalization

화면에서 한 글자로 보이는 것과 컴퓨터가 저장하는 단위는 다르다. 사람은 grapheme을 보지만 Unicode는 code point의 sequence로 문자를 표현하고, UTF-8은 이를 다시 bytes로 인코딩한다. Tokenizer는 화면의 모양이 아니라 이 실제 입력 표현을 처리하므로, 같아 보인다는 사실만으로 같은 Token IDs가 나온다고 보장할 수 없다.

  1. 표시된 grapheme
  2. Unicode code points
  3. UTF-8 bytes
  4. 선택적 Normalization
  5. Token IDs

Code Points & Bytes

한을 NFC로 표현하면 code point는 U+D55C 하나이고 UTF-8은 ED 95 9C의 3 bytes다. 반면 AA는 41의 1 byte, 슬라이드의 emoji는 F0 9F 98 80의 4 bytes다. UTF-8이 variable-length이므로 보이는 글자 수와 byte 수를 일대일로 세면 안 된다. 여러 요소가 합쳐진 emoji는 이 예시보다 더 긴 sequence일 수도 있다.

Byte BPE는 256 bytes에서 시작한다. 한이 처음에는 ED / 95 / 9C로 나뉘어도, 학습된 merge에 따라 ED 95 / 9C의 2 tokens나 ED 95 9C의 1 token이 될 수 있다. Byte 수가 같아도 merge가 무엇을 배웠느냐에 따라 token 수는 달라지는 것이다.

Normalization

같은 모양의 한을 NFD로 표현하면 U+1112 / U+1161 / U+11AB의 3 code points가 되고, UTF-8에서는 E1 84 92 / E1 85 A1 / E1 86 AB의 9 bytes를 쓴다. NFC와 NFD는 canonically equivalent여도 raw sequence 비교에서는 서로 다르다. 둘 다 NFC로 맞춘 뒤 비교해야 같은 sequence가 된다.

NFC는 canonical composed, NFD는 canonical decomposed 표현이고, NFKC/NFKD는 compatibility 차이까지 folding한다. 예를 들어 ㈜ → (주), fi → fi, ² → 2로 정리하면 표현 종류를 줄일 수 있지만, enclosure·ligature·superscript라는 원래 차이를 잃는다. Normalization은 항상 가역 변환인 것이 아니므로, 입력을 같게 만들려는 목적과 보존해야 할 정보를 함께 판단해야 한다.

SentencePiece 기본 nmt_nfkc는 설정 가능하고 GPT-2/tiktoken byte BPE는 내부에서 raw UTF-8을 유지한다. training/inference에 동일한 upstream 처리가 필요하다.

Invisible Characters

Zero-width space U+200B와 Unicode Tags U+E0001…U+E007F는 화면에서 숨겨져도 Tokenizer와 모델 입력에 남을 수 있다. UI/필터/모델이 보는 문자열이 다를 때 숨겨진 instruction 문제가 생긴다. 강의의 ASCII Smuggler는 이러한 차이의 사례다.

여기서 문제는 사용자의 화면, safety filter, 모델이 서로 다른 입력을 보게 될 수 있다는 것이다. 사용자는 Hello만 보고, filter는 tags를 지운 Hello를 검사했는데, 모델에는 raw code points와 숨겨진 instruction이 남아 있을 수 있다. 이 차이를 확인하지 않으면 화면에서 정상으로 보인다는 판단이 실제 모델 입력의 검증을 대신하게 된다.

그렇다고 invisible characters를 모두 지우는 것은 해결책이 아니다. 이들에는 실제 표현상의 용도가 있으며, 일괄 삭제하면 emoji나 다른 언어의 표현을 훼손할 수 있다. 교수님이 강조한 판단 기준은 무조건 삭제하는 규칙이 아니라 어떤 단계에서 어떤 code points를 보존·변환했는지 일치시키는 것이다. 한글의 UTF-8 byte 분해와 NFC/NFD normalization도 서로 다른 층위의 처리로 구분해야 한다.

같이 보임 ≠ 같은 code point sequence. Normalization을 모든 Tokenizer가 수행하는 것은 아니다.

Check

화면에 같은 한이 보이는데 Token IDs가 다른 이유와 완화 방법은?

Answer

NFC/NFD의 code point·byte sequence가 다를 수 있다. 필요하면 Tokenization 전에 동일한 Normalization을 training/inference에 적용한다.

보이지 않는 Unicode를 모두 지우면 문제가 완전히 해결된다고 할 수 있는가?

Answer

아니다. 교수님은 실제 사용 목적이 있는 문자도 있어 일괄 삭제가 다른 표현을 훼손할 수 있다고 설명했다. 화면·필터·모델의 입력을 구분해야 한다.

Contents