RAG를 붙였는데 자꾸 엉뚱한 문서를 물고 온다면, 원인은 검색이 아니라 그 앞 단계에 있을지 모릅니다. 문서를 어떤 단위로 잘라 넣었느냐죠.
MachineLearningMastery가 RAG 파이프라인에서 쓰이는 청킹 전략 일곱 가지를 작동 방식과 선택 기준까지 정리했습니다. RAG를 오픈북 시험에 비유하면, 시스템이 노트 더미에서 관련 대목을 찾아 모델에게 건네주고 모델은 그걸 보며 답을 쓰는 구조죠. 청킹은 그 노트를 애초에 어떤 단위로 잘라 보관할지 정하는 규칙입니다.
출처: 7 Chunking Strategies That Decide Whether Your RAG Works – MachineLearningMastery
일곱 가지는 이렇게 나뉩니다.
- 고정 크기 토큰 청킹 — 512토큰씩 기계적으로 자르고 일부를 겹쳐 경계 손실을 줄입니다
- 문장 윈도우 검색 — 문장 단위로 찾되 모델에게는 앞뒤를 붙여 넘기죠
- 문서 구조 기반 청킹 — 제목 계층과 문단 경계를 따라 자릅니다
- 의미 기반 청킹 — 문장 사이 의미 거리가 벌어지는 지점에서 끊죠
- 계층형 청킹 — 작은 조각과 큰 조각을 부모-자식으로 묶어둡니다
- LLM 기반 명제 청킹 — 모델이 직접 읽고 끊을 자리를 정하죠
- 표 보존 청킹 — 표와 도표를 따로 떼어 요약본만 벡터로 만듭니다
512토큰씩 자르면 무엇이 부서지나
가장 흔한 방식은 문서를 512토큰짜리 덩어리로 균일하게 써는 것입니다. 빠르고 예측 가능하죠. 다만 이 방식은 문서의 구조를 전혀 보지 않습니다.
부정 수식어가 주어에서 떨어져 나가거나, try/except 블록이 한가운데서 갈라지는 일이 생깁니다. 대명사가 가리키던 대상과 다른 조각에 들어가기도 하죠. 이렇게 잘린 텍스트가 임베딩 모델, 그러니까 문장을 숫자 배열로 바꿔 저장하는 장치에 들어가면, 검색기는 이미 눈이 먼 상태로 노트를 집게 됩니다.
일부를 겹쳐 자르면 경계 손실은 조금 줄어듭니다. 대신 벡터 데이터베이스가 부풀고 처리 비용도 겹치는 비율만큼 늘죠. 문서에 애초에 구조가 없는 로그 파일 같은 데서, 그리고 처리 속도가 가장 급할 때 쓰는 방식입니다.
한 가지 구분도 짚고 갑니다. 원문은 청킹과 파싱을 섞어 쓰지 말라고 선을 긋죠. 파싱은 PDF나 HTML 같은 원본 형식에서 논리 구조를 뽑아내는 일이고, 청킹은 그렇게 나온 텍스트를 어떤 규칙으로 자를지의 문제입니다. 파싱이 엉망이면 청킹도 망가지지만, 파싱이 완벽해도 청킹 설계는 따로 필요하다는 것.
작게 찾아서 크게 넘긴다
문장 윈도우 검색은 발상이 재밌습니다. 찾을 때는 문장 하나 단위로 정밀하게 찾고, 모델에게 건넬 때는 그 문장의 앞뒤를 다시 붙여서 넘기죠.
저장 단계에서 문서를 문장으로 쪼개 각각 임베딩하되, 주변 문장을 가리키는 메타데이터를 함께 달아둡니다. 검색이 끝나면 중간 계층이 그 문장들을 원래의 넓은 창으로 바꿔치기해서 모델에 전달하죠. 정밀도와 맥락을 동시에 챙기려는 설계입니다.
문제는 중복입니다. 인접한 두 문장이 나란히 상위 결과에 걸리면 겹치는 창이 두 번 들어가죠. 중복을 걸러내는 단계를 빼먹으면 모델의 컨텍스트 창이 터지고 응답이 느려집니다. 의학 문헌이나 법조문처럼 사실이 촘촘하고 뉘앙스가 중요한 자료에 잘 맞는 방식.
문서 구조 기반 청킹은 다른 길로 갑니다. 제목 계층을 따라 자르고, 각 조각 앞에 상위 제목을 붙여두죠. 3분기 실적 > 위험 요인 > [본문] 같은 형태입니다.
계약서나 API 문서처럼 제목이 곧 의미를 규정하는 자료에서 강한 방식이죠. 다만 잘린 조각 크기가 들쭉날쭉합니다. 임베딩 모델의 최대 길이를 넘는 순간 다시 토큰 단위로 후퇴해야 하죠.
자동으로 자를수록 흔들린다
의미 기반 청킹은 문장 벡터 사이의 거리를 재서 주제가 바뀌는 지점을 찾습니다. 앞뒤 문장의 코사인 유사도, 그러니까 두 문장이 수학적으로 얼마나 가까운지를 계산해 그 값이 기준 아래로 떨어지면 거기서 끊죠.
깔끔해 보이지만 대가가 있습니다. 모든 문장을 한 번씩 인코더에 통과시켜야 하니 저장 단계의 비용과 지연이 크게 늘죠. 기준값도 문서 종류가 섞이면 전역으로 맞추기가 거의 불가능합니다. 회의록이나 음성 전사본처럼 형식은 없는데 주제가 불규칙하게 튀는 자료에 어울리는 방식.
LLM에게 직접 끊게 하는 방식은 더 나갑니다. 문서를 모델에 흘려 넣고 끊을 자리나 개별 명제를 JSON으로 뱉게 하죠. 맥락을 이해한 절단이라는 점에서 매력적입니다.
대신 저장 과정이 비결정적으로 바뀝니다. 모델이 없는 경계를 지어내거나, 깨진 JSON을 내놓거나, 텍스트 일부를 조용히 흘려버릴 수 있죠. 인덱스에서 데이터가 사라지면 되돌릴 방법이 없습니다. 그래서 실시간 처리가 아니라 비동기 배치로 돌릴 때, 그리고 조각 품질이 제품의 성패를 좌우할 만큼 중요할 때만 쓰는 선택지.
표를 떼어내면 유령 참조가 생긴다
표 보존 청킹은 표와 도표를 본문에서 분리해 별도 객체로 다룹니다. 원본 마크다운은 그대로 보관하고, 표의 의미를 요약한 텍스트만 벡터로 만들죠. 검색은 요약본으로 걸고, 모델에게는 원본 표를 그대로 넘깁니다.
재무 보고서나 논문처럼 숫자가 중심인 문서에서 열 정렬이 뭉개지는 걸 막아주는 방식이죠. 다만 함정이 있습니다. “아래 표 1의 결과는 대조군 기준으로 정규화한 값”처럼 표가 주변 문장에 기대고 있으면, 떼어내는 순간 그 근거가 사라지죠. 표만 남고 무엇에 대한 표인지는 없어지는 겁니다.
고를 사람은 문서가 정한다
일곱 가지를 훑고 나면 순위 같은 건 없다는 게 분명해집니다. 로그 파일에는 고정 크기가 맞고, 계약서에는 구조 기반이 맞죠. 회의록에는 의미 기반이, 재무 자료에는 표 보존이 어울립니다. 문서의 성격이 전략을 고르는 셈.
한 가지 흐름은 눈에 띕니다. 자동화 정도를 높일수록, 그러니까 모델에게 판단을 더 맡길수록 결과가 불안정해진다는 것. 고정 크기는 멍청하지만 예측 가능하고, LLM 기반은 똑똑하지만 무엇이 나올지 보장되지 않죠. RAG를 붙이는 쪽에서 감수할 불확실성의 크기를 먼저 정해야 나머지가 따라옵니다.
원문은 청킹 이후의 문제도 짧게 다룹니다. 인덱스를 어떻게 갱신하고 중복 조각을 어떻게 정리할지 같은 것들인데, 실제로 운영 100일차가 되면 청킹보다 이쪽이 더 큰 일이 된다고 하죠.
답글 남기기