요약: RAG 품질이 낮을 때 많은 팀이 임베딩 모델이나 벡터DB부터 바꾼다. 하지만 검색 실패의 상당 부분은 문서를 어떻게 자르느냐에서 시작된다. 최근 arXiv에 올라온 Query-Adaptive Semantic Chunking(QASC)은 고정 길이 청킹의 한계를 지적하고, 사용자 쿼리를 청킹 단계에 반영해 관련 문장을 seed로 찾은 뒤 주변 문맥을 확장하는 방식을 제안한다. 논문은 100개 기술 문서와 200개 쿼리 평가에서 F1 0.85, 고정 청킹 대비 18~27% 개선을 보고했다.
RAG 시스템은 보통 문서를 작은 조각으로 나누고, 각 조각을 임베딩해 벡터DB에 넣고, 사용자 질문과 가까운 조각을 찾아 모델에 넘긴다. 여기서 청킹은 단순 전처리처럼 보이지만 실제로는 검색 품질의 바닥을 결정한다. 잘못 자른 문서는 좋은 임베딩 모델로도 복구하기 어렵다.
고정 길이 청킹은 구현이 쉽다. 500토큰 또는 1,000토큰 단위로 자르고 overlap을 넣으면 된다. 문제는 문서 구조와 사용자 의도를 무시한다는 점이다. 너무 작게 자르면 정확도는 올라갈 수 있지만 필요한 문맥이 빠진다. 너무 크게 자르면 문맥은 보존되지만 검색 결과에 불필요한 내용이 섞인다. chunk size와 overlap을 튜닝해도 precision과 recall의 trade-off가 남는다.
검색 의도로 보면 이 글의 핵심 키워드는 RAG 청킹 전략, Query-Adaptive Semantic Chunking, RAG 검색 품질 개선이다. 목표는 논문 요약이 아니라, 기존 RAG 파이프라인에 어떻게 안전하게 적용할지 정리하는 것이다.
QASC는 문서를 미리 같은 크기로 잘라두는 방식에서 벗어난다. 사용자 쿼리를 청킹 단계에 넣는다. 논문 설명 기준으로 세 가지 메커니즘이 있다. 첫째, 문장 임베딩과 쿼리 임베딩의 cosine similarity를 계산해 관련성이 높은 seed sentence를 찾는다. 둘째, seed 주변의 문맥 창을 확장해 의미가 끊기지 않게 한다. 셋째, chunk-level score aggregation으로 조각 전체의 관련성을 평가한다.
이 접근은 간단한 질문에 특히 직관적이다. 예를 들어 “OAuth token refresh 실패 시 재시도 정책은?”이라는 질문이 들어오면, 전체 인증 문서를 800토큰 단위로 뒤지는 대신 refresh, retry, token expiry가 포함된 문장을 먼저 찾고 그 주변 문맥을 가져온다. 문서의 제목이나 고정 구간보다 실제 질문과 가까운 부분을 중심으로 조각을 만든다.
논문은 고정 청킹 5가지 granularity, recursive splitting, semantic chunking, agentic chunking과 비교했고 QASC가 F1 0.85를 달성했다고 보고한다. 고정 청킹 대비 1827%, semantic·agentic 대안 대비 812% 개선이다. 사람 평가에서도 Cohen kappa 0.82로 관련성과 일관성이 더 낫다는 결과를 제시한다.
QASC를 제품에 넣을 때 기존 인덱스를 전부 버릴 필요는 없다. 실무에서는 두 단계 구조가 안전하다. 1단계는 기존 문서 인덱스를 유지한다. 문서 단위 또는 섹션 단위로 coarse retrieval을 해서 후보 문서 5~20개를 찾는다. 2단계에서 후보 문서 내부에 QASC 스타일의 query-adaptive chunking을 적용한다.
이렇게 하면 전체 문서를 매번 동적으로 자르는 비용을 피할 수 있다. 사용자 쿼리가 들어올 때 모든 문장을 비교하면 비용과 지연 시간이 커진다. 먼저 후보 문서를 좁힌 뒤 해당 문서 안에서 문장 단위 seed를 찾으면 운영 가능한 수준으로 줄어든다.
구현 흐름은 다음과 같다. 문서를 문장 단위로 파싱하고 각 문장 임베딩을 저장한다. 쿼리가 들어오면 후보 문서를 찾는다. 후보 문서의 문장들과 쿼리의 유사도를 계산한다. 상위 seed를 고른다. seed 앞뒤로 문장 또는 토큰 윈도우를 확장한다. 중복 chunk를 병합한다. 마지막으로 chunk 점수를 계산해 상위 몇 개만 LLM 컨텍스트에 넣는다.
동적 청킹은 품질이 좋아질 수 있지만 공짜가 아니다. 문장 단위 임베딩 저장량이 늘고, 쿼리마다 추가 계산이 발생한다. 따라서 모든 질문에 QASC를 적용하기보다 실패 비용이 큰 검색에 우선 적용하는 편이 좋다.
예를 들어 사내 기술 문서, API 레퍼런스, 운영 runbook, 법무 문서처럼 정확한 문맥이 중요한 영역에 적합하다. 반대로 짧은 FAQ나 이미 구조화된 테이블 검색에는 과할 수 있다. 쿼리 유형도 나눠야 한다. 정의 질문, 절차 질문, 오류 해결 질문, 비교 질문은 필요한 문맥 길이가 다르다.
운영 지표는 세 가지를 본다. 첫째, retrieval hit rate다. 정답 문서 또는 정답 문장이 검색 결과에 포함되는지 본다. 둘째, answer faithfulness다. 모델 답변이 가져온 chunk에 근거하는지 평가한다. 셋째, latency다. 동적 청킹을 붙인 뒤 P95 응답 시간이 얼마나 늘었는지 확인한다. 품질이 10% 좋아져도 P95가 3초에서 12초로 늘면 제품에 맞지 않을 수 있다.
청킹 전략은 감으로 바꾸면 안 된다. 팀 내부 문서 50100개와 실제 사용자 질문 100300개를 모아 작은 평가셋을 만든다. 각 질문에 대해 정답 문서, 정답 문장 또는 근거 범위를 라벨링한다. 처음부터 완벽한 데이터셋이 필요하지 않다. 개발자 2명이 서로 검토한 100개만 있어도 chunk size 튜닝보다 나은 결정을 할 수 있다.
비교군은 최소 네 가지로 둔다. 현재 고정 청킹, 고정 청킹 with overlap, semantic chunking, query-adaptive 방식이다. 같은 임베딩 모델과 같은 reranker를 사용해야 청킹 효과를 볼 수 있다. 모델까지 같이 바꾸면 원인을 알 수 없다.
정답률만 보지 말고 실패 케이스를 분류한다. 문맥 부족, 잡음 과다, 문서 선택 실패, 최신 문서 누락, 표현 차이로 인한 검색 실패를 나누면 다음 개선 방향이 보인다. QASC는 특히 문맥 부족과 표현 차이 문제에 도움이 될 가능성이 높다.
