긴 문서는 조각보다 목차 지도로 찾는 편이 낫다
로컬 에서 , , 연구 논문 같은 여러 문서를 보통 방식으로 잘게 나누면 간단한 질의응답은 어느 정도 된다. 하지만 추론하는 에 연결하면 문제가 커진다. 계약서나 API 문서를 512토큰짜리 조각으로 자르면, 에이전트는 그 문단이 어느 상위 항목에 속하는지, 전체 문서 구조와 어떻게 이어지는지 알기 어렵다.
겹치게 자르기나 부모-자식 검색 방식은 조금 도움을 주지만, 문맥 창만 더 크게 차지하는 경우가 많다. 대안은 문서를 먼저 목차처럼 지도화하는 방식이다. 모델이 문서의 , 구조적 계층, 구간별 토큰 범위를 먼저 색인하고, 에이전트는 이 지도를 조회해 필요한 문서와 항목을 찾은 뒤 정확한 구간만 요청한다.
미리 잘라 둔 짧은 조각을 던지는 대신, 에이전트에게 문서의 목차를 주는 셈이다. 구조가 중요한 긴 문서에서는 이 방식이 의미 있는 문맥을 더 잘 보존한다.
핵심 포인트
- 보통의 512토큰 조각 나누기는 긴 문서의 상하 구조를 잃게 만들 수 있다.
- 추론하는 는 문단 자체뿐 아니라 그 문단의 위치와 연결 관계가 필요하다.
- 겹치게 자르기와 부모-자식 검색은 문맥 창 사용량을 늘릴 수 있다.
- 문서의 , 구조적 계층, 토큰 범위를 먼저 색인하면 필요한 구간만 가져올 수 있다.
- 긴 계약서, API 문서, 연구 논문처럼 구조가 중요한 문서에서 특히 유용하다.