Chunking & Indexing

문서를 통째로 저장하면 검색 결과 하나가 너무 길어져서 모델에 넣기 어렵고, 반대로 아무 기준 없이 잘게 자르면 문맥이 끊겨 의미가 사라집니다. 또 어떤 문서에서 나온 조각인지, 어떤 권한 그룹이 볼 수 있는지 같은 정보가 없으면 검색 결과를 안전하게 필터링하기도 어렵습니다.

초기 RAG 실험에서는 embedding 모델만 바꾸면 검색이 좋아질 거라고 생각하기 쉬웠습니다. 하지만 운영 환경에서는 chunk 경계, 제목 유지 여부, 메타데이터 설계, 인덱스 필터가 retrieval 품질을 훨씬 크게 흔들 수 있다는 점이 빠르게 드러났습니다.

보통은 원문을 섹션, 문단, 토큰 길이 같은 기준으로 나누고, 제목이나 문서 출처 같은 메타데이터를 붙입니다. 이후 각 chunk를 벡터화해 인덱스에 저장하고, 필요하면 키워드용 역색인도 같이 둡니다. 질의 시에는 메타데이터 필터와 유사도 검색이 함께 작동해 현재 질문에 맞는 후보만 골라냅니다.

chunking/indexing, embeddings, RAG는 모두 retrieval 품질에 관여하지만 보는 지점이 다릅니다. 무엇을 어떤 단위로 저장하고 어떤 메타데이터로 거를지가 문제면 chunking/indexing을 보고, 비슷한 의미를 얼마나 잘 찾는지가 문제면 embeddings를 보고, 검색 결과를 실제 답변에 어떻게 붙일지가 문제면 RAG를 봐야 합니다. chunk를 잘 나누는 것만으로는 답변 근거 선택과 생성 품질까지 자동으로 좋아지지 않는다는 점이 한계입니다.

chunking/indexing의 가장 큰 이득은 retrieval precision과 권한 필터를 데이터 준비 단계에서 안정화할 수 있다는 점입니다. 대신 수집 파이프라인, 재인덱싱, 메타데이터 유지 비용이 생기고, 문서 구조가 바뀔 때마다 운영 부담이 따라옵니다. 문서가 작고 거의 바뀌지 않는 시스템에서는 단순 검색으로 충분할 수 있지만, 문서량과 권한 규칙이 커질수록 이 준비 비용이 훨씬 빨리 회수됩니다.

실무에서는 문서 구조를 최대한 보존하되, 한 chunk가 하나의 완결된 생각 단위를 담도록 나누는 편이 좋습니다. 너무 크면 관련성은 있어 보여도 답변 근거가 흐려지고, 너무 작으면 문맥이 잘려 엉뚱한 조각이 붙습니다. 인덱싱 단계에서 메타데이터를 제대로 설계하지 않으면, 나중에 권한 필터나 최신 버전 필터를 붙일 때 전체 파이프라인을 다시 손봐야 합니다.