PageIndex: 트리 검색으로 벡터 검색의 빈틈을 메우다

개요: 검색에서 내비게이션으로, PageIndex의 전환

PageIndex는 전통적 ‘청크-임베딩-벡터 검색’ 파이프라인을 버리고, 문서의 목차 구조를 활용한 트리 검색으로 RAG의 약점을 보완한다. 사람처럼 목차에서 장·절·페이지를 좁혀 가듯, LLM이 문서 구조를 따라 능동적으로 이동하며 필요한 정보를 찾는다. 개발진은 이를 게임 AI의 트리 탐색을 문서 검색에 적용한, 일종의 ‘알파고 스타일’ 접근으로 설명한다.

왜 벡터 검색은 전문 데이터에서 흔들리는가

벡터 검색은 질문과 가장 유사한 텍스트가 곧 가장 관련 있다는 가정을 둔다. 그러나 재무보고처럼 전문 영역에서는 ‘의도 대 내용’ 간극이 자주 드러난다. 예를 들어 EBITDA를 묻는 질의에서 여러 섹션이 용어를 언급하지만, 정작 계산 정의·조정 범위가 담긴 핵심 섹션은 하나뿐이다. 임베딩 길이 한계로 맥락이 잘려 retrieval이 대화의 추론 흐름과 분리되는 점도 정확도를 떨어뜨린다.

PageIndex의 트리 검색: 글로벌 인덱스와 능동 탐색

PageIndex 트리 검색 방식

PageIndex는 문서의 콘텐츠를 벡터화하기보다 구조를 ‘Global Index’로 만들고, 장·절·소절을 노드로 하는 트리를 구축한다. 질의가 들어오면 LLM은 각 노드의 관련성을 전체 맥락을 기준으로 판별하며 트리를 내려간다. 이는 수동적 일치 검색이 아니라, 어디를 볼지 결정하는 능동적 내비게이션이다.

PageIndex가 멀티홉 질의에 강한 이유

멀티홉 문제에서 구조적 단서 추적이 위력을 발휘한다. FinanceBench에서 PageIndex 기반 시스템 ‘Mafin 2.5’는 98.7%를 기록했다. 연준 연차보고서의 이연자산 총액처럼 본문엔 ‘증감’만 있고 총액은 부록 G에 있는 경우, 벡터 검색은 질의와 부록 표 사이의 의미 유사도가 낮아 실패한다. 반면 PageIndex는 본문의 각주·참조 신호를 읽고 부록 링크를 따라가 정확한 표와 값을 찾아낸다.

지연 시간과 인프라: 느릴 것 같지만 다르게 빠르다

스트리밍 중 인라인 검색

전통 RAG는 검색이 답변 생성을 막는 ‘블로킹 단계’다. PageIndex는 모델의 추론 과정 안에서 검색을 병행해 즉시 스트리밍을 시작하고, 생성하며 필요한 정보를 가져온다. 덕분에 첫 토큰까지의 시간(TTFT)은 일반 LLM 호출과 유사하다.

벡터 DB 없는 단순한 운영

임베딩 의존을 제거해 전용 벡터 DB를 유지할 필요가 없다. 트리형 인덱스는 PostgreSQL 같은 관계형 DB에도 얹을 수 있고, 문서 변경 시 전체 재처리 대신 영향받은 서브트리만 재색인하면 된다.

도입 판단 기준: 언제 PageIndex가 맞는가

PageIndex 활용이 빛나는 경우

긴 분량과 뚜렷한 계층 구조, 그리고 오류 비용이 큰 문서(기술 매뉴얼, FDA 제출문서, 합병 계약서)에 적합하다. 답뿐 아니라 어떤 경로(예: 4.1절 확인→부록 B 이동→데이터 종합)로 도달했는지 감사 가능해야 하는 환경에 특히 유리하다.

여전히 벡터가 유리한 경우

이메일·채팅처럼 짧은 텍스트는 통째로 컨텍스트 창에 넣으면 되고, ‘비슷한 느낌의 콘텐츠 찾기’ 같은 순수 유사성 탐색은 벡터 임베딩이 더 적합하다. PageIndex는 범용 대체제가 아니라 ‘딥워크’에 특화된 도구다.

미래 전망: Agentic RAG로의 이동

PageIndex는 데이터 검색의 책임이 DB 레이어에서 모델 레이어로 올라가는 흐름, 즉 Agentic RAG를 보여준다. 코드 도메인에서 에이전트가 능동적으로 코드베이스를 탐색하듯, 문서 검색도 계획·추론 중심으로 재편되고 있다. 벡터 DB의 쓸모는 남겠지만, LLM/AI의 기본 선택지라는 지위는 점차 희미해질 것이다. PageIndex 접근법은 그 전환의 실용적 경로를 제시한다.