Vectorless RAG (Vectorless RAG, 벡터 없는 RAG)
2026.10.03 · 17분
1. Vectorless RAG란?
Vectorless RAG는 임베딩과 벡터 데이터베이스 없이 검색(Retrieval)을 수행하는 여러 RAG 방식을 묶어 부르는 말입니다. 이 방식들의 공통점은 벡터 유사도 검색을 쓰지 않는다는 것 하나입니다.
일반적인 벡터 RAG와 비교하면 이렇습니다.
[벡터 RAG]
문서 ──> 청크로 자름 ──> 임베딩 ──> 벡터 DB
질문 ──> 임베딩 ──> 코사인 유사도 Top-K ──> LLM
[Vectorless RAG (트리 탐색형)]
문서 ──> 목차(트리) 인덱스 생성 (제목 + 요약)
질문 ──> LLM이 트리를 보고 "어느 절을 읽을지" 추론 ──> 해당 절 원문 ──> LLM벡터 RAG는 무엇이 비슷한지를 숫자로 계산하고, 트리 탐색형은 무엇이 필요한지를 LLM이 판단합니다.
도서관에 비유하면 다음과 같습니다.
| 구분 | 도서관 | 시스템 |
|---|---|---|
| 벡터 RAG | 질문과 단어 느낌이 비슷한 문장이 적힌 페이지를 전부 찢어서 가져온다 | 임베딩 유사도 Top-K 청크 |
| 키워드 검색 | 색인(찾아보기)에서 단어가 정확히 나오는 쪽수를 찾는다 | BM25, grep |
| 트리 탐색 | 사서가 목차를 펼쳐 보고 "이 질문이면 3장 2절을 봐야겠네" 하고 찾아간다 | LLM이 목차 트리를 추론하며 탐색 |
| 메타데이터/SQL | 분류 번호, 출판 연도, 저자로 서가를 좁힌다 | WHERE 조건, 필터 |
2. 왜 필요할까? "유사도 ≠ 관련성"
2-1. 벡터 검색이 하는 일
벡터 검색은 질문과 청크를 각각 임베딩한 뒤 의미적으로 가까운 것을 고릅니다. 많은 경우 잘 동작하지만, 이 방식이 재는 것은 "비슷함(Similarity)"이고 "답에 필요함(Relevance)"과는 다릅니다.
2-2. 비슷하지만 관련 없는 경우
재무 보고서에 이런 질문을 했다고 해 봅시다.
질문: "2025년 영업이익이 전년 대비 줄어든 주된 원인은?"| 청크 | 유사도 | 실제로 답에 필요한가 |
|---|---|---|
| "영업이익은 회사의 핵심 수익성 지표로..." (용어 설명) | 높음 | 아니오 |
| "2024년 영업이익은 전년 대비 증가하였으며..." | 높음 | 아니오 (연도가 다름) |
| "원자재 가격 상승으로 매출원가율이 악화되었다" (경영진 분석 절) | 중간 | 예 |
| 주석 12. 일회성 손상차손 | 낮음 | 예 |
답에 필요한 정보는 "영업이익"이라는 단어조차 들어 있지 않은 경영진 분석 절과 재무제표 주석에 있습니다. 사람 전문가라면 목차를 보고 "원인 분석은 MD&A 절, 일회성 항목은 주석"이라고 바로 찾아갑니다. 벡터 유사도로는 이런 문서 구조 추론을 할 수 없습니다.
2-3. 청킹이 맥락을 끊는다
벡터 RAG는 문서를 일정 크기 청크로 자릅니다. 그 과정에서 이런 일이 생깁니다.
3. 임베딩 없이 검색하는 방법들
Vectorless RAG는 크게 세 갈래로 나눌 수 있습니다.
Vectorless RAG
┌──────────────────┼──────────────────┐
▼ ▼ ▼
키워드 검색 구조(트리) 탐색 메타데이터 / SQL
BM25, grep LLM이 목차를 추론 WHERE 필터, Text-to-SQL
"단어가 맞나?" "어느 절인가?" "조건이 맞나?"3-1. 키워드 검색 (BM25, grep)
가장 오래되고 단순한 방법입니다. 질문의 단어가 문서에 정확히 나오는지, 얼마나 드물고 자주 나오는지로 점수를 매깁니다.
| 장점 | 단점 |
|---|---|
| 인덱스 구축이 빠르고 싸다 | 동의어, 다른 표현을 못 찾는다 ("해지" vs "계약 종료") |
| 제품 코드, 에러 코드, 조항 번호 같은 고유 문자열에 강하다 | 단어가 없는 관련 정보는 못 찾는다 |
| 결과를 설명하기 쉽다 | 순서, 문맥을 고려하지 않는다 |
3-2. 구조(트리) 기반 추론 탐색
문서를 목차 트리로 만들어 두고, LLM이 질문을 보고 어느 가지로 내려갈지 추론하는 방식입니다. 이 노트의 중심 주제이며, 대표적인 오픈소스 구현이 PageIndex(VectifyAI)입니다.
PageIndex는 스스로를 "벡터 DB 없이, 청킹 없이" 동작하는 추론 기반 RAG라고 소개합니다. 동작은 두 단계입니다.
- 문서에서 목차(Table of Contents) 형태의 계층 트리 인덱스를 만든다.
- 질문이 오면 LLM이 그 트리를 탐색하며 추론해 관련 절을 찾는다.
3-3. 메타데이터 / SQL 기반
검색 대상이 표 형태이거나 메타데이터가 풍부하면, 유사도 대신 조건으로 거릅니다.
질문: "2025년 3분기 이후 법무팀이 작성한 계약 검토 문서 중 '해지' 조항이 있는 것"
→ SELECT doc_id FROM documents
WHERE team = '법무' AND created_at >= '2025-07-01' AND type = '계약검토'
→ 걸러진 문서 안에서 키워드 '해지' 검색4. 트리 인덱스 생성 과정
4-1. 트리 노드의 모양
트리의 각 노드는 문서의 한 절(Section)을 나타냅니다. 원문 전체 대신 이 절이 무엇에 관한 것인지 판단할 정보만 들고 있습니다.
노드 = {
node_id: "0007"
title: "3.2 위험 요인"
pages: 41 ~ 48
summary: "환율, 원자재 가격, 주요 고객 집중도에 따른 위험을 설명"
children: [ "0008", "0009" ]
}4-2. 생성 단계
① 원본 문서 (PDF 200쪽)
│
▼
② 구조 추출
- PDF 목차/북마크, 제목 글꼴 크기, 번호 체계("1.", "1.1", "제3조")로 계층 파악
│
▼
③ 노드 생성
- 절마다 title, 페이지 범위, 자식 목록
│
▼
④ 요약 생성 (LLM)
- 각 노드 원문을 짧게 요약해 summary 채움
│
▼
⑤ 트리 인덱스 저장 (JSON 한 파일)PageIndex 저장소 설명에 따르면 트리 구조 자체는 문서 레이아웃에서 LLM 없이 추출하고, 인덱스 모델은 이를 요약하고 다듬는 역할만 합니다. 목차가 없는 문서라면 ②단계에서도 LLM이 제목을 추정해야 하므로 비용이 커집니다.
4-3. 만들어진 트리 예시
2025 사업보고서 (root)
├── 1. 회사 개요 p.1-8
├── 2. 사업의 내용 p.9-40
│ ├── 2.1 주요 제품 p.9-20
│ └── 2.2 시장 현황 p.21-40
├── 3. 경영진 분석 (MD&A) p.41-70
│ ├── 3.1 실적 개요 p.41-50 "매출·영업이익 증감과 원인"
│ └── 3.2 위험 요인 p.51-70
└── 4. 재무제표 p.71-200
├── 4.1 손익계산서 p.71-75
└── 4.9 주석 p.90-200
├── 주석 12. 손상차손 p.130-134 "일회성 손상 인식 내역"
└── 주석 18. 특수관계자 거래 p.150-160벡터 DB에는 청크가 수천 개 쌓이지만, 트리의 노드는 수십~수백 개입니다. 그래서 트리 전체(제목+요약)를 LLM 컨텍스트에 그대로 넣을 수 있습니다.
5. LLM 탐색 과정
5-1. 탐색 흐름
질문: "2025년 영업이익 감소의 주된 원인은?"
[1단계] LLM에게 최상위 노드 목록을 보여준다
1. 회사 개요 / 2. 사업의 내용 / 3. 경영진 분석 / 4. 재무제표
LLM: "원인 분석은 3번, 일회성 비용은 4번 주석에 있을 것" → [3, 4] 선택
[2단계] 3번의 자식 노드를 보여준다
3.1 실적 개요 (매출·영업이익 증감과 원인) / 3.2 위험 요인
LLM: → [3.1] 선택
[3단계] 4번의 자식 노드를 보여준다
4.1 손익계산서 / ... / 4.9 주석
LLM: → [4.9] 선택 → 자식 중 [주석 12. 손상차손] 선택
[4단계] 선택된 리프 노드의 원문(p.41-50, p.130-134)을 읽는다
LLM: "충분하다" → 답변 생성
탐색 경로: root → 3 → 3.1, root → 4 → 4.9 → 주석12 (그대로 근거로 남김)5-2. 의사코드
아래는 개념을 보여주는 단순화된 의사코드입니다. 실제 PageIndex 구현과 같지는 않습니다.
import json
import anthropic
client = anthropic.Anthropic()
MODEL = "claude-opus-5-5"
def ask(prompt: str) -> str:
msg = client.messages.create(
model=MODEL, max_tokens=1024,
messages=[{"role": "user", "content": prompt}],
)
return msg.content[0].text
def choose_children(question: str, node: dict) -> list[dict]:
"""현재 노드의 자식 중 질문에 필요한 것을 LLM이 고른다."""
options = [
{"id": c["node_id"], "title": c["title"], "summary": c["summary"]}
for c in node["children"]
]
prompt = (
f"질문: {question}\n\n"
f"다음은 문서 목차의 일부입니다:\n{json.dumps(options, ensure_ascii=False)}\n\n"
"질문에 답하려면 어떤 항목을 읽어야 하나요? "
'관련된 id만 JSON 배열로 답하세요. 예: ["0007"]. 없으면 [].'
)
picked = set(json.loads(ask(prompt)))
return [c for c in node["children"] if c["node_id"] in picked]
def tree_search(question: str, node: dict, path=(), max_depth=5) -> list[tuple]:
"""리프에 도달할 때까지 내려가며 (경로, 노드)를 모은다."""
path = path + (node["title"],)
if not node["children"] or len(path) > max_depth:
return [(path, node)]
results = []
for child in choose_children(question, node):
results += tree_search(question, child, path, max_depth)
return results
def answer(question: str, tree: dict, read_pages) -> str:
hits = tree_search(question, tree)
context = "\n\n".join(
f"[{' > '.join(p)}] (p.{n['start_page']}-{n['end_page']})\n"
f"{read_pages(n['start_page'], n['end_page'])}"
for p, n in hits
)
return ask(f"다음 근거만 사용해 답하고, 근거 경로를 함께 밝히세요.\n\n{context}\n\n질문: {question}")포인트는 세 가지입니다.
| 포인트 | 설명 |
|---|
6. 왜 긴 구조화 문서에 강할까?
6-1. 문서 종류별 적합도
| 문서 | 구조 특징 | 트리 탐색이 유리한 이유 |
|---|---|---|
| 재무 보고서 (사업보고서, 10-K) | 정해진 목차, 본문-재무제표-주석의 상호 참조 | 원인은 MD&A, 숫자는 재무제표, 단서는 주석에 흩어져 있다. 목차로 가야 찾는다 |
| 법률 문서 (계약서, 법령, 판결문) | 장-조-항-호 계층, "제5조 제2항에 따라" 같은 참조 | 조항 번호가 곧 주소다. 유사한 문구가 여러 조항에 반복되어 벡터 검색이 헷갈린다 |
| 기술 매뉴얼 | 제품-기능-절차-문제 해결 계층 | 같은 절차가 모델별로 미세하게 다르다. "어느 모델 절인가"가 핵심이다 |
| 학술 논문, 규정집 | 표준화된 섹션 | 방법론/결과/한계가 분리되어 있다 |
6-2. 공통점
긴 구조화 문서의 성질 트리 탐색이 이용하는 것
────────────────────────── ──────────────────────────
저자가 이미 목차를 설계했다 → 목차 = 공짜로 주어진 인덱스
비슷한 문구가 여러 곳에 반복된다 → 문구가 아니라 "위치(어느 절)"로 구분
절 안에서 맥락이 완결된다 → 절 단위로 통째로 읽어 맥락 보존
문서 안 상호 참조가 많다 → 노드 id로 점프
근거 제시가 중요하다 (감사, 법무) → 탐색 경로가 그대로 근거6-3. 성능 주장에 대해
VectifyAI는 PageIndex 기반 시스템(Mafin 2.5)이 재무 문서 QA 벤치마크인 FinanceBench에서 98.7% 정확도를 기록했다고 발표했습니다. 개발사가 직접 보고한 수치이므로, 실제 도입 전에는 자기 문서와 질문으로 직접 평가해 보는 것이 좋습니다. 평가 방법은 노트를 참고합니다.
7. 벡터 RAG와 비교
| 항목 | 벡터 RAG | Vectorless (트리 탐색) |
|---|---|---|
| 인덱싱 | 청킹 + 임베딩 (대량, 빠름) | 구조 추출 + 노드 요약 (LLM 호출) |
| 저장소 | 벡터 DB | JSON 트리 파일 하나로도 가능 |
| 검색 원리 | 코사인 유사도 | LLM 추론 |
| 검색 단위 | 고정 크기 청크 | 의미 단위인 절 |
| 검색 비용 | 임베딩 1회 + 벡터 연산 (매우 쌈) | LLM 호출 여러 번 |
| 검색 지연 | 수십 ms 수준 | 수 초 이상 (호출 횟수 × LLM 응답 시간) |
| 설명 가능성 | 낮음 (점수만) | 높음 (탐색 경로) |
| 문서 수 확장 | 수백만 청크도 가능 | 문서 하나~수십 개에 적합 |
| 구조 없는 텍스트 |
8. 장점과 단점
| 장점 | 설명 |
|---|---|
| 관련성 기반 검색 | 단어가 달라도 "이 질문이면 이 절"이라는 추론이 가능하다 |
| 청킹 불필요 | 절 단위로 읽어 표, 단서 조항, 앞뒤 맥락이 보존된다 |
| 추적 가능성 | 탐색 경로가 남아 감사, 법무, 금융 같은 분야에서 근거 제시가 쉽다 |
| 인프라 단순 | 벡터 DB, 임베딩 모델 운영이 필요 없다 |
| 임베딩 모델 교체 문제 없음 | 임베딩 모델을 바꿀 때마다 전체를 다시 인덱싱할 필요가 없다 |
| 단점 | 설명 |
|---|---|
| LLM 호출 비용 | 질문 하나에 트리 깊이 × 분기 수만큼 LLM을 부른다 |
| 지연 시간 | 호출이 순차적이라 수 초가 걸린다. 실시간 자동완성 같은 용도에는 부적합 |
| 대량 문서 집합에 약함 | 문서 1만 개라면 "어느 문서의 트리를 볼지"부터 정해야 한다. 이 단계에는 결국 키워드나 벡터, 메타데이터 검색이 필요하다 |
| 구조 없는 문서에 약함 | 채팅 로그, 짧은 FAQ 모음, 이메일 더미에는 목차가 없다 |
9. 참고 자료
- PageIndex GitHub 저장소 (VectifyAI): https://github.com/VectifyAI/PageIndex
- PageIndex: Vectorless RAG with Reasoning-Based Document Retrieval (yuv.ai): https://yuv.ai/blog/pageindex
- Vectorless RAG - PageIndex: Learn from First Principles: https://algorisys.substack.com/p/vectorless-rag-pageindex-learn-from
- FinanceBench (Islam et al., 2023): https://arxiv.org/abs/2311.11944
- Robertson & Zaragoza, The Probabilistic Relevance Framework: BM25 and Beyond (2009): https://dl.acm.org/doi/10.1561/1500000019
기준일: 2026-10-03
10. 핵심 정리
Vectorless RAG는 임베딩과 벡터 DB 없이 검색하는 RAG의 총칭으로, 키워드(BM25/grep), 문서 구조(목차 트리) 추론 탐색, 메타데이터/SQL 필터가 대표적인 갈래다. 출발점은 "유사도 ≠ 관련성"이라는 문제의식이다. 트리 탐색형(PageIndex 등)은 문서를 제목·요약·페이지 범위를 가진 목차 트리로 만들고, LLM이 질문을 보고 어느 절로 내려갈지 추론해 고른 절의 원문만 읽는다. 저자가 설계한 목차가 그대로 인덱스가 되므로 재무 보고서, 법률 문서, 매뉴얼처럼 길고 구조화된 문서에 강하고, 탐색 경로가 근거로 남는다. 대신 질문마다 LLM을 여러 번 호출해 비용과 지연이 크고, 문서가 많거나 구조가 없는 데이터에는 약하므로 문서 선택은 싼 검색으로, 문서 안 탐색은 추론으로 나누는 혼합이 현실적이다.