왜 다들 청킹(chunking) 부분은 대충 넘어가는 거지?
why does everyone skip the chunking part
핵심 요약
RAG 구현 시 가장 중요한 청킹과 데이터 파이프라인 관리의 어려움을 지적하며 실무적인 해결책을 공유함.
- 청킹의 중요성 — 고정 크기 청킹은 문맥을 끊어먹어 모델의 환각을 유발함.
- 검색 품질 개선 — 실패한 쿼리를 직접 확인하고 하이브리드 검색을 도입해야 함.
- 메타데이터 활용 — 메타데이터 필터링으로 불필요한 검색 결과를 사전에 차단함.
- 인덱스 관리 — 문서 업데이트 시 인덱스 동기화 문제 해결이 필수적임.
내가 본 RAG 튜토리얼들은 80%의 시간을 벡터 데이터베이스와 임베딩에 쏟고는, 정작 "문서를 청킹하세요"라고 마치 당연한 것처럼 말하고 넘어감.
근데 이거 당연한 거 아님. 사실 대부분의 구현을 망치는 주범이 바로 이거임.
고정 크기 청킹은 토큰 제한에 걸리는 지점에서 무조건 잘라버림. 문장 경계는 신경도 안 쓰고, 두 문장이 합쳐져야 의미가 통하는지도 고려 안 함. 결국 절반만 잘린 생각을 가져오게 되고, 모델은 그걸 바탕으로 자신 있게 틀린 답을 내놓음. 이게 바로 우리가 해결하려던 문제의 핵심임.
오버랩을 포함한 슬라이딩 윈도우 방식이 실무에서 가장 많이 쓰이고 괜찮긴 하지만, 나한테 진짜 도움 됐던 건 파이프라인이 잘 돌아가겠거니 가정하는 대신, 실패한 쿼리에서 실제로 어떤 데이터가 검색되는지 직접 읽어보는 거였음. 거의 항상 청크의 주제는 맞았지만 정작 답이 들어있는 문장이 빠져 있었음.
또 다른 문제는 벡터 검색이 정확한 식별자에서 무너진다는 거임. 누군가 특정 모델 번호나 제품 코드를 물어보면 시맨틱 검색은 "비슷한" 결과를 반환함. 근데 "비슷한" 건 틀린 거임. 벡터와 함께 BM25를 사용하는 하이브리드 검색이 이걸 해결해주지만, 입문용 튜토리얼에는 절대 안 나와서 결국 몸으로 때우며 배우게 됨.
그리고 오래된 인덱스 문제. 문서를 업데이트했는데 인덱스를 다시 안 만들면, 사용자는 자신 있게 틀린 답을 받게 됨. 이건 기술적인 문제가 아니라 파이프라인 문제라서 아무도 안 다루는 것 같음.
다들 재인덱싱은 어떻게 하고 있는지 궁금함. 지금은 스케줄링 방식으로 하고 있는데 작동은 하지만 좀 불안정하게 느껴짐.
