Template Mismatch
모델이 답을 한다고 입력 format이 맞았다는 뜻은 아니다. Chat format은 결국 token sequence이므로, 표지가 두 번 들어가거나 종료 ID가 어긋나도 일반적인 실행 에러가 나지 않을 수 있다. 대신 학습 때와 다른 입력을 받거나, 답이 끝났는데 계속 생성한다. 이 section에서는 입력의 시작, 다음 발화의 시작, 생성의 종료를 각각 누가 담당하는지 구분한다.
- Template / training target / stop list 대조
- final IDs 확인
- 올바른 입력·종료
Double BOS
Template가 BOS/EOS를 이미 넣은 문자열에 add_special_tokens=True를 다시 적용하면 Double BOS가 될 수 있다. apply_chat_template(tokenize=True) 한 번 또는 tokenize=False 뒤 add_special_tokens=False를 쓴다. 생성에서는 add_generation_prompt=True, 강의의 일반 training formatting에서는 False를 구분한다.
Stop Tokens
eot_id는 한 turn, end_of_text는 sequence 전체 끝이다. Training target의 assistant terminator·template·decoder stop list가 맞아야 한다. 강의 Llama3 stop IDs는 128001/128008/128009다. 마지막 생성 ID와 stop reason을 보고 짧은 답인데 max_new_tokens까지 가는 mismatch를 찾는다.
Double BOS를 피하는 핵심은 special token 삽입을 한 곳에서 책임지는 것이다. tokenize=False로 받은 문자열은 특수 표지를 이미 포함할 수 있으므로, 이를 다시 Tokenizer에 넣을 때 기본 삽입을 중복 적용하지 않아야 한다. 최종 IDs를 출력하고 한 번 decode해 보면, 눈에 보이는 대화 내용만 볼 때 놓친 중복을 찾을 수 있다.
add_generation_prompt는 다른 역할이다. Inference에서는 assistant가 이제 답을 시작할 위치를 알려 주지만, 일반적인 supervised training sequence에는 실제 assistant 답변까지 이미 들어 있다. 그 뒤에 또 빈 assistant 시작 표지를 붙이면 의도하지 않은 패턴을 학습할 수 있어 보통 False로 둔다. 다만 학습 중 응답을 생성하는 별도 절차까지 모두 같은 설정이라고 일반화하지 않는다.
Stop mismatch도 token 두 개가 존재해서 생기는 문제가 아니다. 모델이 eot_id로 답을 끝내도록 배웠는데 decoder가 end_of_text만 기다리면, 종료를 알리는 ID를 이미 생성하고도 멈추지 못한다. 따라서 weights를 다시 학습하기 전에 training target, template의 assistant terminator, decoder stop list가 같은 약속을 쓰는지 확인해야 한다. 짧은 답인데 stop reason이 max_new_tokens라면 마지막 생성 ID를 확인하는 것이 출발점이다.
Control Boundaries
User text의 delimiter가 real reserved ID가 되는 permissive parsing은 forged role 문제를 낳을 수 있다. Strict하게 ordinary text로 encode해도 template-like text가 모델을 혼동시킬 수 있다.
Trusted control IDs는 code에서 삽입, untrusted user/tool은 text로 처리, 필요 시 delimiter escape/reject, 실제 permission은 모델 밖에서 검사한다. add_special_tokens=False는 security boundary가 아니고 allowed_special/disallowed_special과 구분한다.
Role 표지도 같은 sequence 안의 tokens로 표현된다는 점은 별도의 한계다. User가 template delimiter를 흉내 낸 문자열을 넣었을 때 이를 진짜 reserved ID로 허용하면, code가 넣어야 할 trusted control과 user content가 섞인다. Strict parsing은 이 경로를 막지만, 모델은 ordinary text로 분절된 template-like pattern에도 영향을 받을 수 있다.
그래서 role separation은 hardware isolation과 같은 권한 경계가 아니다. Control IDs는 code가 넣고 user/tool content는 text로 다루되, delimiter 검사가 필요한 곳에서는 escape 또는 reject한다. 실제 tool permission은 prompt 문장만으로 맡기지 않고 모델 밖에서 검사한다. 이것이 parsing 설정과 외부 permission checks를 함께 두는 이유다.
end of turn과 end of sequence는 scope가 다르다. add_generation_prompt는 BOS 중복을 해결하는 switch와 같은 역할이 아니다.
Training target·template·decoder stop IDs를 함께 확인한다.
Check
Double BOS와 stop mismatch의 원인·확인 지표를 각각 말하라.
Answer
Double BOS는 template와 후속 Tokenization 양쪽의 special insertion이다. final IDs/decode를 본다. Stop mismatch는 학습한 terminator와 stop list의 불일치다. 마지막 ID와 stop reason을 본다.
Special parsing만 막으면 template-like injection이 완전히 차단되는가?
Answer
아니다. ordinary text도 role handling을 흐릴 수 있다. Control/content 분리와 모델 밖 permission 검사가 함께 필요하다.