왜 다들 청킹(chunking) 부분은 건너뛰는 걸까?
why does everyone skip the chunking part
핵심 요약
RAG 튜토리얼들이 정작 중요한 청킹 전략을 소홀히 다루는 문제를 지적하며, 실무적인 해결책을 고민하는 글.
- 청킹 전략 — 고정 크기 청킹의 한계와 문맥 손실 문제를 지적함.
- 검색 최적화 — 하이브리드 검색과 BM25 도입의 필요성을 강조함.
- 데이터 최신성 — 인덱스 업데이트 주기와 파이프라인 관리의 어려움을 토로함.
- 실무적 접근 — 튜토리얼의 이론보다 실제 검색 결과를 확인하는 과정의 중요성을 언급함.
제가 본 모든 RAG 튜토리얼은 시간의 80%를 벡터 데이터베이스와 임베딩에 쏟아붓고는, 마치 당연하다는 듯이 '문서를 청킹하세요'라고 말하고 넘어갑니다.
이건 당연한 게 아닙니다. 사실 대부분의 구현을 망치는 주범이죠.
고정 크기 청킹은 토큰 제한에 걸리는 지점에서 무조건 자릅니다. 문장 경계는 신경 쓰지 않고, 두 문장이 함께 있어야 의미가 통하는지도 고려하지 않죠. 결국 절반의 생각만 검색하게 되고, 모델은 나머지 부분을 자신 있게 지어내는데, 이게 바로 우리가 해결하려고 했던 문제의 핵심입니다.
슬라이드 윈도우와 오버랩 방식은 실제로 많은 사람이 프로덕션에서 사용하고 괜찮은 방법이지만, 저에게 진짜 도움이 된 건 파이프라인이 잘 작동할 거라 가정하는 대신 실패한 쿼리에 대해 실제로 무엇이 검색되는지 읽어보는 것이었습니다. 거의 항상 청크는 올바른 주제를 다루고 있었지만, 정작 답이 포함된 문장이 빠져 있었죠.
또 다른 문제는 벡터 검색이 정확한 식별자에서 무너진다는 점입니다. 누군가 특정 모델 번호나 제품 코드를 물어보면, 시맨틱 검색은 '적당히 비슷한' 결과를 반환합니다. '적당히 비슷한' 건 틀린 겁니다. 벡터와 함께 BM25를 사용하는 하이브리드 검색이 이 문제를 해결해주지만, 입문용 튜토리얼에서는 절대 다루지 않아서 결국 몸으로 부딪히며 배우게 되죠.
그리고 오래된 인덱스 문제도 있습니다. 문서를 업데이트했는데 재인덱싱을 안 하면, 사용자는 자신 있게 틀린 답을 얻게 됩니다. 이건 기술적인 문제가 아니라 파이프라인 문제라서 아무도 글을 쓰지 않는 것 같네요.
다들 재인덱싱은 어떻게 하고 계신지 궁금합니다. 저는 현재 스케줄에 맞춰서 하고 있는데, 작동은 하지만 좀 불안하게 느껴지네요.
