AI
[RAG] 문서 청킹 토큰 경계 TEI tokenize 413 에러 차단
jykim23
2026. 7. 30. 22:22
반응형

부제: 글자 수로 자르다 나던 413 에러를, 임베딩과 같은 토크나이저로 잘라 없앤 이야기
RAG는 문서를 조각(청크)으로 잘라 각 조각을 임베딩한다.
임베딩 모델엔 한 번에 넣을 수 있는 토큰 한도가 있어서,
조각이 그 한도를 넘으면 413(Payload Too Large) 에러가 난다.
글자로 자르면 토큰이 넘친다
흔한 방식은 글자 수로 자르는 거다.
"한 조각에 몇 글자" 하고 정해서 뚝뚝 끊는다.
문제는 토큰과 글자가 1:1이 아니라는 점이다.
언어와 기호에 따라 한 토큰이 몇 글자인지가 제각각이다.
그래서 글자 수로 잘라도 어떤 조각은 토큰 한도를 넘어 413이 난다.
특히 영어와 기호가 섞인 마크다운은 토큰 밀도가 높아서, 같은 글자 수라도 토큰이 훨씬 많다.
"글자 수 × 대략의 비율"로 토큰을 추정해 자를 수도 있지만,
그 추정이 빗나가는 순간 413이 터진다.
토크나이저로 자른다
그래서 글자가 아니라 토큰으로 자르기로 했다.
그것도 임베딩 모델과 같은 토크나이저로.
임베딩 서버(TEI)에 토큰 경계를 물어보는 기능(/tokenize)이 있다.
이걸로 자르면, 청킹에 쓴 토큰 수가 임베딩이 세는 토큰 수와 정확히 일치한다.
글자당 토큰 비율을 추정할 필요가 없고, 한도를 넘길 일이 없어 413이 원천 차단된다.
게다가 토큰 경계의 바이트 위치를 알려주니, 원문을 정확한 자리에서 잘라낸다.
정리
- 임베딩엔 토큰 한도가 있어, 조각이 크면 413(Payload Too Large)이 난다
- 글자 수로 자르면 언어·기호에 따라 토큰이 넘쳐 413 발생(영어·기호 섞인 마크다운은 토큰 밀도 높음)
- 글자가 아니라 토큰으로, 그것도 임베딩과 같은 토크나이저(TEI /tokenize)로 잘랐다
- 청킹 토큰 수 = 임베딩 토큰 수 → 추정 불필요, 413 원천 차단, 바이트 오프셋으로 원문 정확 추출
길이 제한이 토큰 기준이면 자르기도 토큰 기준이어야 한다.
글자 수로 추정해 자르면 언어·기호에 따라 한도를 넘는다.
판정에 쓰는 것과 같은 자로 재면 추정도, 넘침도 사라진다.
반응형