긴 문서 요약 전처리, 검색 단위로 쪼개야 QA가 나아질까?

결론부터 말하면, 긴 문서 요약 전처리의 목표는 '짧게 만들기'가 아니라 '검색 가능한 단위로 분해하기'다. 문서·섹션 요약은 라우팅용으로만 쓰고, 최종 답변에는 원문 청크와 위치 메타데이터를 함께 넘기는 구성이 더 안전하다. 이 글은 EKRAG와 TREC 2025 RAG 트랙, SEC 문서 QA 실무 사례를 근거로 이 판단을 검증한다.

이 글의 핵심

  • 전처리 목표는 압축이 아니라 검색 단위 분해다 — 요약문만 색인하면 세부 수치·예외 조건이 사라질 수 있다.
  • 청크 크기는 문서 유형별로 다르게: 일반 섹션 800~1,200토큰, 위험요인·정책 조항은 400~600토큰이 실무 기준이다.
  • hybrid 검색(BM25+dense)은 기본 비교군이지만, reranker 효과는 데이터셋마다 달라 직접 비교가 필요하다.
  • 검색(Recall@K)과 답변 근거성은 반드시 분리해서 측정해야 전처리 품질이 보인다.
  • 전체 문서를 긴 컨텍스트로 넣는 방식보다 검색 기반 전처리가 비용에서 유리한 사례가 있지만, 모델 가격과 조건에 종속된다.

이번 실험에서 검증하려던 것은 단 하나다. "요약으로 문서를 짧게 만드는 것"과 "구조를 보존해 검색 단위로 쪼개는 것" 중 어느 쪽이 QA 파이프라인에서 더 안정적인가. 결과를 미리 말하면, 둘은 경쟁 관계가 아니라 역할이 다르다. 요약은 빠르게 관련 섹션을 좁히는 라우팅 역할이고, 실제 답변 근거는 원문 청크가 맡아야 한다.

청크 크기와 오버랩, 문서 구조별로 다르게 설계해야 할까?

그렇다. 고정된 청크 길이 하나를 전체 문서에 적용하면 짧은 조항은 과도하게 뭉개지고, 긴 설명문은 과도하게 쪼개진다. SEC 재무제표 QA 실무 사례는 일반 섹션에 800~1,200토큰, 150~200토큰 오버랩을 기본값으로 쓰고, 위험요인처럼 개별 항목이 짧은 구간은 400~600토큰으로 더 잘게 나누도록 권고한다출처.

실험 로그에서 확인한 마찰은 두 가지였다. 첫째, 제목·섹션 경계에서 자르지 않으면 같은 청크 안에 서로 다른 항목의 내용이 섞여 검색 정확도가 떨어졌다. 둘째, 오버랩을 너무 줄이면(50토큰 이하) 경계에 걸친 수치나 정의가 어느 청크에도 온전히 담기지 않는 손실이 생겼다. 이 글의 평가 체계에서 '청크 경계 손실률'을 별도 지표로 둔 이유도 여기에 있다. 청크 크기는 한 번 정하고 끝나는 하이퍼파라미터가 아니라, 문서 섹션 구조를 먼저 파악한 뒤 섹션별로 다르게 적용해야 하는 설계 변수였다.

BM25와 임베딩을 함께 쓰는 하이브리드 검색은 실험할 가치가 있을까?

있다. 다만 "항상 이긴다"는 아니고, 기본 비교군으로 두고 직접 측정해야 할 대상이다. TREC 2025 RAG 트랙은 SPLADE-v3(sparse)와 Snowflake Arctic-Embed-L(dense)을 각각 상위 1,000개까지 검색한 뒤 Reciprocal Rank Fusion으로 결합하는 다단계 구성을 사용했다출처. EncouRAGe 평가에서도 Hybrid BM25가 여러 데이터셋에서 가장 높은 F1과 Recall@10을 기록한 사례가 보고됐다출처.

이 결과를 "하이브리드가 항상 최선"으로 읽으면 과장이다. 특정 트랙·버전의 구성에서 나온 결과이고, 모델 버전이나 임베딩 차원이 바뀌면 색인을 다시 생성해야 하므로 모델 버전·차원·거리 함수·정규화 여부를 함께 고정해 기록하지 않으면 재현이 안 된다. 우리 실험에서도 dense 단독 검색 대비 hybrid가 Recall@10을 끌어올린 질의군이 있었던 반면, 짧은 정의형 질문에서는 BM25 단독과 큰 차이가 없었다. 결론은 "일단 섞어보고 후보 수(candidate_k)와 결과를 로그로 남긴다"였다.

재순위화(reranker)는 항상 추가해야 할까?

아니다. 데이터셋에 따라 효과가 갈린다. EncouRAGe 평가에서는 reranker 추가가 MRR에서 측정 가능한 개선을 만들지 못한 반면출처, EKRAG는 QA-Mistral-4B를 reranker로 써서 임베딩 모델 종류와 관계없이 recall이 일관되게 개선됐다고 보고한다출처. 두 결과가 상반되는 이유는 데이터셋·질의 유형·후보 수 조건이 다르기 때문이다.

실무에서 내릴 수 있는 판단은 "reranker가 항상 유효하다" 또는 "항상 불필요하다"로 일반화하지 않는 것이다. 동일한 candidate_k와 Recall@K 조건에서 reranker 유무를 A/B로 비교하고, 지연시간·비용 증가분과 recall 개선폭을 같이 적어야 추가 여부를 결정할 수 있다. 우리 실험에서는 reranker 호출이 질의당 추가 지연을 발생시켰고, 긴 재무 섹션 질의에서는 recall 개선이 보였지만 단순 정의 질의에서는 체감 차이가 거의 없었다.

요약은 어디까지 쓰고, 원문은 어디서부터 써야 할까?

요약문은 라우팅용, 원문 청크는 근거용으로 역할을 나눠야 한다. 요약문만 벡터화해 색인 비용을 줄이는 방식은 매력적이지만, 세부 수치·예외 조건·정의가 요약 과정에서 빠질 수 있다. 실무 설계에서는 문서·섹션 요약으로 먼저 관련 구간을 좁히고, 최종 답변 생성 시에는 원문 청크와 [문서명 | 섹션 | 페이지 | 청크 ID] 메타데이터를 함께 전달하는 구성이 적합하다출처.

이 구조는 프롬프트 설계에도 그대로 이어진다. 답변 규칙은 "제공된 근거만 사용, 근거 부족 시 모른다고 답변"으로 고정하고, 출력 형식에 주장별 근거 청크 ID와 수치의 단위·기준일을 포함시켜야 검증 단계에서 문장별 근거 존재 여부를 확인할 수 있다. TREC 2025가 답변의 coverage와 문장별 support를 분리 평가한 방향과 정확히 맞닿아 있다.

TREC 2025와 EKRAG 수치를 어떻게 읽어야 할까?

그대로 "정답"처럼 옮기면 안 되고, 조건과 함께 읽어야 한다. TREC 2025 구성은 MS MARCO v2.1 세분화 컬렉션에서 SPLADE-v3·Arctic-Embed-L로 1차 검색 후 RankLLM, RankQwen3-32B로 재순위화해 최종 상위 100개 문서를 선택했다출처. EKRAG는 sparse+dense 결과를 합쳐 중복 제거·재순위화한 뒤 상위 청크를 LLM 컨텍스트에 넣고, Recall@K를 핵심 지표로 삼는다출처.

구성 요소 TREC 2025 RAG 트랙 EKRAG
1차 검색 SPLADE-v3 + Arctic-Embed-L (각 top-1000) sparse + dense 결합
재순위화 RankLLM, RankQwen3-32B QA-Mistral-4B
최종 선택 상위 100 상위 청크(가변)
핵심 지표 coverage, support, Cohen's κ Recall@K

두 사례의 공통점은 candidate_k, rerank_k, context_k를 분리해 기록했다는 점이다. 실무 서비스에서도 이 세 수치를 실험 로그에 남기지 않으면 어느 단계에서 recall이 빠졌는지 추적할 수 없다.

비용 측면에서는 전처리가 항상 더 쌀까?

항상은 아니고, 조건부로 유리한 사례가 있다. SEC 문서 QA 비교 작업에서 요약·검색 기반 방식은 약 0.05달러, 전체 200K 또는 1M 컨텍스트를 통째로 넣는 방식은 1.50달러를 넘을 수 있다고 보고됐다출처. 이 수치는 특정 모델·입력 길이·출력 상한·호출 횟수 조건에 종속된다. 모델 API 가격이 바뀌면 재계산이 필요하다.

이 비교를 일반 법칙으로 쓰려면 최소한 모델명·버전, 입력 토큰 수, 출력 상한, 호출 횟수, 임베딩 비용, reranker 호출 여부, 캐시 사용 여부를 함께 공개해야 한다. 우리 실험에서도 같은 질의를 반복 호출할 때 캐시 적중 여부에 따라 비용 차이가 컸기 때문에, 1회성 비교로 결론을 내리지 않고 최소 3회 반복한 평균값을 기록했다.

이 구성은 어디서 막히는가?

막히는 지점은 명확하다. 첫째, 표·각주가 많은 재무 문서는 파서 단계에서 텍스트 추출이 어긋나면 이후 모든 단계가 틀어진다. 표 보존률을 별도 지표로 두지 않으면 이 손실을 뒤늦게 발견한다. 둘째, reranker 효과가 데이터셋마다 갈리기 때문에, 한 도메인에서 검증한 설정을 다른 도메인에 그대로 옮기면 효과가 사라지거나 역전될 수 있다. 셋째, 2026년 기준으로도 임베딩 모델 버전이 바뀌면 색인을 처음부터 다시 만들어야 하는 비용이 남아있고, 이 재인덱싱 비용은 비교 표에 잘 안 잡힌다.

반복하면서 남은 판단은 무엇인가?

요약 전처리는 단독 기술이 아니라 파이프라인의 한 단계로 봐야 한다는 점이 가장 분명해졌다. 구조 보존 분할 → hybrid 검색 → 필요 시 reranking → 원문 근거 기반 생성 → 검색·답변 분리 평가, 이 다섯 단계를 하나의 실험 단위로 묶어 비교하지 않으면 어느 설정이 실제로 기여했는지 알 수 없다. 공개 벤치마크 수치는 참고점이지 일반 법칙이 아니며, 데이터셋·모델 버전·후보 수 조건을 함께 적어야 다음 실험에서 재현할 수 있다.

핵심 정리

  • 전처리 목표는 압축이 아니라 검색 단위 분해이며, 요약은 라우팅용, 원문 청크는 근거용으로 역할을 나눈다.
  • 청크 크기·오버랩은 문서 전체에 고정값을 쓰지 말고, 일반 섹션 800~1,200토큰·짧은 조항 400~600토큰처럼 구조별로 조정한다.
  • hybrid 검색은 기본 비교군이지만 reranker 효과는 데이터셋마다 달라 동일 조건 A/B 비교가 필요하다.
  • Recall@K와 답변 근거성은 분리 측정해야 하며, candidate_k·rerank_k·context_k를 실험 로그에 남겨야 재현 가능하다.
  • 비용 비교는 모델·토큰 수·호출 횟수 조건을 함께 공개해야 하며, 조건이 바뀌면 재계산이 필요하다.