문서 QA에서 컨텍스트 조립, 어디까지 손봐야 답이 좋아지나?
결론부터: 벡터화 모델을 바꾸는 것보다 청크가 의미 단위를 보존하는지, retrieval이 근거 문장을 실제로 가져오는지, rerank가 노이즈를 걸러내는지가 먼저다. 이 세 축을 순서대로 점검하지 않으면 벡터 모델을 아무리 좋은 걸로 바꿔도 답변 품질은 크게 안 움직인다. 아래는 이 세 축을 각각 별도로 검증한 기록이다.
핵심 정리
- 청크 분할은 "작게"가 아니라 "질문-답변 단위 보존"이 기준이다. PIC 계열은 WebQ에서 semantic/proposition chunking 대비 평균 2포인트 이상 향상을 보고했다[3].
- Recall@K이 첫 번째 지표다. rerank나 프롬프트 구성은 그다음이다. EKRAG는 이를 명시적으로 우선순위로 정리했다[8].
- top-k를 그냥 이어붙이면 노이즈가 늘어난다. MIRAGE는 noise vulnerability·context misinterpretation 같은 지표로 이걸 따로 측정한다[1].
- 평가는 정답률 하나로 안 된다. TREC 2025 RAG 트랙은 relevance 0~4점, coverage, support verification을 나눠 본다[5].
- 벤치마크마다 chunking 규칙·평가 설정이 다르므로, 수치는 "해당 벤치마크 버전 기준"으로 읽어야 한다.
실험에서 검증하려던 건 단순했다. "컨텍스트 조립 파이프라인의 어느 단계를 손대면 체감 변화가 가장 큰가"였다. 청크 크기를 줄이면 좋아질 거라 예상했지만, 실제로는 청크 경계가 질문-답변 쌍을 갈라놓는 경우가 더 많은 손실을 만들었다. 이 지점부터 단계별로 나눠 기록한다.
청크를 어떻게 잘라야 질문-답변 단위가 안 깨지나?
청크는 글자 수 기준으로 균등 분할하는 것보다, 문서 구조(문단·섹션·표)를 따라 자르는 쪽이 retrieval 성능에 직접 영향을 준다. PIC(Proposition-In-Context) 계열 연구는 여러 QA 벤치마크에서 semantic chunking과 proposition 기반 chunking보다 구조 보존형 chunking이 더 높은 retrieval 성능을 냈고, WebQ에서는 평균 대비 2포인트 이상 향상을 보고했다[논문].
2026년 벤치마크인 HiCBench는 여기서 한 걸음 더 나가, chunking 품질 자체를 평가 대상으로 삼았다. Qasper 데이터셋에서 level-1 chunk point detection F1이 0.5481에서 0.6742로 개선된 사례를 제시했는데, 이는 "잘 자른 청크"가 retrieval 이전 단계에서 이미 성능 상한을 결정한다는 뜻이다[출처]. 실무에서는 이걸 "청크 크기를 얼마로 할까"라는 질문 대신 "이 청크 안에 질문-답변 쌍이 통째로 들어가는가"라는 질문으로 바꿔서 점검하는 게 더 실용적이었다. 글자 수 500자, 1000자 같은 숫자 실험보다 표·리스트·섹션 경계를 건드리지 않는 규칙을 먼저 세우는 쪽이 체감 차이가 컸다.
검색이 근거를 못 가져오면 rerank로 살릴 수 있나?
부분적으로만 가능하다. rerank는 이미 top-k 안에 들어온 후보를 재정렬할 뿐, retrieval 단계에서 아예 빠진 문서는 되살리지 못한다. 그래서 기업 지식 QA용 EKRAG는 Recall@K를 가장 중요한 지표로 명시했고, retrieval된 chunk가 실제 답변 단위를 얼마나 포함하는지를 우선 확인하라고 정리한다[출처]. 실험에서도 top-5 recall이 낮은 상태에서 rerank 모델만 바꿔본 경우, 답변 정확도 변화는 미미했다. 반대로 top-20~30까지 넉넉히 가져온 뒤 rerank로 상위 5~10개만 남기는 구성에서는 변화가 뚜렷했다.
2026년 요약 자료는 이 패턴을 "hybrid retrieval + rerank + top-5~10 압축"으로 정리하는데, dense cosine-only보다 sparse+dense 하이브리드가 기본값에 가깝다고 설명한다[출처]. 다만 이 구성은 비용이 공짜가 아니다. 같은 자료는 query embedding, vector lookup, sparse lookup, rerank, generation을 나눠 비용을 추산하면서, rerank 단계가 전체 지연·비용의 주요 비중을 차지할 수 있다고 지적한다. 후보군을 넉넉히 가져올수록 rerank 비용도 같이 늘어나므로, "일단 많이 가져오고 rerank로 거른다"는 전략은 recall 개선과 비용 증가를 맞바꾸는 선택이다.
top-k를 그냥 이어붙이면 왜 노이즈가 늘어나나?
컨텍스트를 많이 넣는다고 답이 좋아지지 않는다. 오히려 관련 없는 문서가 섞여 들어가면 모델이 엉뚱한 근거를 참조하거나(context misinterpretation), 관련 문서가 있어도 무시하는(context insensitivity) 현상이 늘어난다. MIRAGE는 이걸 측정하기 위해 7,560개 인스턴스와 37,800개 retrieval pool로 평가 세트를 구성했고, noise vulnerability·context acceptability·context insensitivity·context misinterpretation이라는 네 가지 지표를 새로 제안했다[논문].
실험 환경에서 top-3, top-5, top-10을 그대로 이어붙여 비교했을 때, top-10에서 답변 정확도가 항상 올라가지는 않았다. 관련 문서 3개와 무관 문서 7개가 섞인 구성보다, 관련 문서 5개만 압축한 구성이 더 안정적인 답변을 냈다. 이건 "컨텍스트를 늘리면 안전하다"는 직관과 반대되는 결과였고, 노이즈 억제가 조립 단계의 별도 목표로 다뤄져야 한다는 걸 확인하는 계기였다.
정답률만 보면 왜 평가가 틀어지나?
정답률 하나로는 컨텍스트 조립이 잘됐는지 판단하기 어렵다. TREC 2025 RAG 트랙은 relevance assessment를 0~4점으로 세분화하고, 응답 평가에서는 "nugget" 기반 coverage와 support verification을 따로 본다[출처]. 즉 답이 맞았는지뿐 아니라, 그 답이 실제로 검색된 근거에 의해 뒷받침되는지(support)와 필요한 정보를 얼마나 빠짐없이 담았는지(coverage)를 나눠서 채점한다.
2026년 리뷰는 task별로 평가 지표를 다르게 골라야 한다고 정리한다. open-domain QA에는 Natural Questions·TriviaQA·HotpotQA, fact-checking에는 FEVER·AveriTeC, 멀티태스크에는 KILT, 범용 retrieval에는 BEIR, 멀티턴 대화에는 MTRAG, 최신 RAG 통합 평가에는 TREC RAG Track이 자주 쓰인다는 게 그 구성이다[출처]. 실무 리뷰에서는 이 중 하나만 골라 "이 지표에서 이 점수"라고 말하기보다, recall·coverage·support를 각각 확인하고 어느 지점에서 막히는지 구분하는 편이 원인 파악에 더 도움이 됐다.
벤치마크마다 기준이 다른데 뭘 믿어야 하나?
아래는 이번 실험에서 참고한 2025~2026 자료들의 초점을 정리한 표다. 같은 "컨텍스트 조립"을 다뤄도 측정 대상이 다르다는 점이 핵심이다.
| 벤치마크/연구 | 초점 | 대표 수치 |
|---|---|---|
| PIC | chunking 방식 비교 | WebQ 평균 대비 2포인트 이상 향상[3] |
| HiCBench | chunking 품질 자체 | Qasper level-1 F1 0.5481→0.6742[2] |
| MIRAGE | 노이즈·컨텍스트 오해석 측정 | 7,560 인스턴스, 37,800 retrieval pool[1] |
| EKRAG | retrieval 우선순위 | Recall@K를 최우선 지표로 명시[8] |
| TREC 2025 RAG | 답변 평가 세분화 | relevance 0~4점, coverage/support 분리[5] |
표에서 보듯 어느 하나도 "컨텍스트 조립 전체"를 통합 평가하지 않는다. chunking은 chunking대로, retrieval은 recall대로, 답변은 nugget 기반으로 각각 다른 잣대를 쓴다. 실사용 리뷰에서 수치를 인용할 때는 "이 벤치마크의 이 버전에서 이 값"이라고 붙이는 게 안전하다. 벤치마크 설정이 바뀌면 같은 chunking 방식도 순위가 달라질 수 있기 때문이다.
이 실험은 어디까지 됐고 어디서 막혔나?
구조 보존형 chunking과 top-k 압축까지는 재현 가능한 개선이 확인됐지만, 도메인 특화 코퍼스에서의 일반화는 검증하지 못했다. 이번 실험은 공개 벤치마크(WebQ, Qasper 계열)와 소규모 사내 문서 세트를 함께 봤는데, 공개 벤치마크에서 확인된 개선폭이 사내 문서에서는 그대로 재현되지 않는 경우가 있었다. 2025~2026 RAG 벤치마크들이 MS MARCO V2.1, Wikipedia, enterprise knowledge, benchmark-specific QA corpus처럼 도메인별 코퍼스를 따로 쓰는 것도 같은 이유다[출처]. 즉 같은 embedding 모델이라도 도메인 매칭이 안 되면 chunking·rerank 개선 효과가 줄어들 수 있다.
또 하나 막힌 지점은 rerank 비용이다. 후보군을 넉넉히 가져와 상위 몇 개만 남기는 방식은 recall 개선에는 도움이 됐지만, 질의당 지연·비용이 늘어나는 트레이드오프를 완전히 없애지는 못했다. 이 부분은 rerank 모델 크기나 후보군 크기를 더 좁혀보는 후속 실험이 필요하다고 판단했다.
다음에는 무엇을 다시 테스트할까?
2026년 기준으로 정리하면, 컨텍스트 조립 실험에서 가장 재현성 있게 확인된 건 "구조 보존형 chunking → recall 우선 확인 → rerank로 노이즈 압축 → coverage/support 분리 평가"라는 순서 자체였다. 벡터화 모델을 바꾸는 실험은 이 순서를 다 확인한 다음에 해도 늦지 않았다. 다음 라운드에서는 rerank 후보군 크기를 top-10, top-20, top-30으로 세분화해 비용 대비 recall 개선폭을 다시 재보고, 사내 문서 도메인에서 chunking 규칙을 별도로 튜닝하는 걸 우선순위로 남겨뒀다.