VectifyAI의 PageIndex는 한 줄 태그라인이 모든 걸 말한다. “Document Index for Vectorless, Reasoning-based RAG.” 지난 2년간 RAG의 기본 가정은 단단했다. 문서를 청크로 자르고, 임베딩으로 벡터를 만들고, 벡터 DB에 박아두고, 질의 시 코사인 유사도로 top-k를 꺼낸다. PageIndex는 이 파이프라인의 가장 앞단, ‘인덱스’의 모양을 통째로 갈아엎는다. 임베딩 대신 문서를 hierarchical tree — 사실상 LLM이 읽을 수 있는 목차 — 로 변환하고, 검색은 벡터 거리 계산이 아니라 LLM이 트리를 따라 내려가는 reasoning으로 수행한다.
트리의 각 노드는 제목, 요약, 노드 ID, 그리고 원문 페이지 범위를 가진다. 그래서 답변에는 “3.2.1 노드, p.42–45”처럼 출처가 자연스럽게 붙는다. 벡터 RAG에서 늘 어색했던 explainability — 왜 이 chunk가 top-k에 뽑혔는지 — 가 “LLM이 어느 노드를 traverse했는가”라는 단계별 trace로 바뀐다. 디버깅이 쉬워지는 건 부수적이고, 본질은 “문서의 구조 자체를 1급 시민으로 인덱스에 박아 둔다”는 점이다. 임베딩은 표현이 닮은 문단을 골라줄 뿐 챕터 위계를 모른다. 재무제표에서 비GAAP 정의가 1.2.3에 있고 조정이 5.4에 있다는 사실, 법률문서에서 정의 조항과 예외 조항이 어디 있는지, cosine similarity는 절대 가르쳐주지 않는다.
그래서 어울리는 자리가 분명하다. 긴 재무보고서 QA, 기술 표준·규제 문서 어시스턴트, 학술 논문 요약·QA, 사내 정책·SOP처럼 “어느 절에서 나왔느냐”가 답의 신뢰도를 결정하는 코퍼스. 반대로 짧은 FAQ나 평면적인 지식베이스, 구조가 거의 없는 인터뷰 트랜스크립트 같은 데에선 트리의 효용이 떨어지고 LLM 토큰만 더 든다. 트리 생성은 한 번이지만 질의 때마다 LLM이 traverse를 돌므로 latency와 비용이 평면 벡터 검색보다 길다. 모든 RAG에 들어맞는 마법이 아니라, 문서의 모양에 따라 인덱스의 모양을 고르는 선택지가 하나 더 생긴 것이다.
PageIndex가 953 stars/day를 받는 이유는 단순한 라이브러리 신상이라서가 아니다. RAG의 default assumption — “먼저 임베딩하고 본다” — 을 정면으로 의심하는 제안이라서다. 벡터 DB가 인덱스의 유일한 모양일 필요는 없다. 문서가 위계를 갖고 쓰였다면, 인덱스도 그 위계를 보존하는 게 LLM에게 더 친절하다. 임베딩과 트리 인덱스는 경쟁자라기보다 다른 모양의 데이터에 맞는 다른 도구이고, PageIndex는 그 두 번째 도구를 깔끔한 형태로 보여준다. 다음 RAG 프로젝트에서 우리가 먼저 물어야 할 것은 “어떤 임베딩 모델을 쓸까”가 아니라, “이 문서는 어떤 모양의 인덱스를 원하는가”일지 모른다.