도메인 문서가 복잡해질수록 “임베딩 유사도만 믿는 RAG”가 왜곡된 근거를 가져오는 순간이 잦아집니다. 이 글에서는 Vectorless RAG(문서 구조 기반 탐색/추론)의 주장과 댓글에서 나온 반론(확장성·교차 질의·비정형 문서)을 정리하고, GraphRAG/그래프DB까지 포함해 어떤 조합이 실전에서 균형이 좋은지 제 관점으로 정리합니다.
기존 Vector RAG가 흔들리는 지점: “유사해 보이지만 실제로는 다른” 근거
전형적인 RAG 파이프라인은 다음 흐름입니다.
- 문서를 chunking
- chunk를 embedding
- vector search로 Top-k 검색
- LLM이 해당 chunk를 근거로 답변 생성
이 방식은 빠르고 범용적이지만, **전문 문서(규정/매뉴얼/기술 명세)**처럼 “용어가 비슷하지만 의미가 다르거나, 같은 개념이 장/절에 따라 정의가 달라지는” 경우에는 문제가 생깁니다.
- 벡터 유사도는 “의미가 비슷해 보이는” 텍스트를 잘 찾지만
- 사용자가 원하는 것은 종종 “정확히 그 조항/그 정의/그 범위”입니다.
- 특히 **문서 내 위치(몇 장, 몇 절, 어느 표/부록)**가 답의 신뢰도를 결정하는 환경에서는 정확한 출처 고정이 더 중요해집니다.
Vectorless RAG란: “문서 구조를 인덱싱하고 LLM이 탐색한다”
원문 요약의 핵심은 간단합니다.
- 문서를 무작정 청킹하지 말고
- 목차/섹션/페이지/하위 절 같은 구조를 **트리(tree)**로 만들고
- LLM이 “어느 노드(섹션)를 읽을지”를 단계적으로 좁혀가며 답하게 하자
이 접근의 장점은 두 가지로 요약됩니다.
1) 정확도: “의미 유사” 대신 “문서 상의 올바른 위치”로 수렴
벡터 검색은 비슷한 표현을 폭넓게 가져오지만, 구조 탐색은 문서가 의도한 분류 체계(목차 체계)에 기대어 정확한 섹션으로 들어가게 합니다.
2) 추적성(traceability): 인용이 쉬워집니다
구조 기반은 답변 근거를 “섹션/페이지/항목”에 자연스럽게 연결할 수 있어, “왜 이 답이 나왔는가?”를 설명하기가 수월해집니다. 특히 컴플라이언스/정책/감사 대응처럼 출처가 곧 품질인 환경에서 매력적입니다.
댓글에서 나온 현실 체크: 확장성과 교차 질의는 어떻게 할 건가?
Vectorless RAG에 대한 반응에서 공통으로 지적된 포인트는 다음입니다.
1) 하이브리드(구조 + 벡터) 필요성
문서 구조는 문서 “안”을 탐색하는 데 강하지만, 어떤 문서를 볼지를 고르는 단계에서는 벡터 검색이 여전히 유효하다는 의견이 많습니다.
- 1단계: 벡터 검색으로 관련 문서/섹션 후보를 넓게 찾고(재현율)
- 2단계: 구조 기반 탐색으로 섹션을 좁혀 들어가며 근거를 고정(정확도·출처)
즉, Vectorless RAG는 “Vector를 완전히 버린다”라기보다 구조를 1급 인덱스로 올려서 벡터의 부정확함을 보정하는 쪽에 가깝다는 해석이 실전적입니다.
2) 장(章) 간 개념 연결 질문: 토큰 비용과 한계
“이 개념이 3장과 7장에서 어떻게 연결되나요?” 같은 질문은 구조 탐색만으로는 결국 여러 섹션을 읽어야 합니다. 이때 문제는:
- 탐색 과정 자체가 LLM 호출/토큰을 늘리고
- 섹션을 여러 개 가져오면 컨텍스트가 커져 비용이 증가합니다.
구조 기반이 정확한 섹션 선택에는 강하지만, 장 간 요약/종합에서는 비용이 빨리 커질 수 있다는 지적입니다.
3) 10만 문서 같은 대규모 확장 시의 부담
문서 수가 많아지면 구조 인덱스 자체도 커지고, “탐색을 위한 LLM 호출”이 누적되면 운영 비용이 무시 못 할 수준이 될 수 있습니다. 벡터DB는 이 지점에서 “빠른 후보 축소 장치”로 여전히 강점이 있습니다.
4) 스캔 PDF 등 비정형 입력: 구조 추출이 선행 과제
Vectorless RAG의 전제는 “문서 구조가 있다/추출할 수 있다”인데, 스캔 PDF나 레이아웃이 깨진 문서에서는
- 목차/헤딩/페이지/표 구조를 만드는 레이아웃 분석이 먼저 필요합니다.
즉, 벡터리스가 만능이라기보다는 문서 전처리(구조화) 품질이 성패를 좌우합니다.
GraphRAG/그래프DB 관점에서 본 “Vectorless”의 위치
대화에서 제가 특히 중요하다고 본 지점은 이것입니다.
- 관계가 핵심인 데이터(사람-조직-거래-이벤트-권한 등)에서는
Vectorless RAG(문서 구조 탐색)보다 **그래프 DB(neo4j/memgraph/janusgraph)**가 본질적으로 유리합니다.
이유는 간단합니다.
- Vectorless RAG는 “어느 섹션을 읽을지”를 잘 찾는 방식이고
- 그래프 DB는 “관계/경로/제약 조건”을 **정형 질의(Cypher/Gremlin)**로 안정적으로 계산합니다.
그리고 GraphRAG 같은 접근은 보통 다음 패턴으로 이해하면 편합니다.
- Vector RAG로 후보를 넓게 찾고(관련 텍스트/단위 수집)
- 그래프(엔티티/관계)로 정리·제약·종합해서 답의 일관성과 설명 가능성을 올린다
여기서 핵심 설계 포인트는 하나입니다.
그래프의 노드/엣지가 “원문 근거(문단/페이지/레코드)”에 단단히 링크되어 있어야 출처가 명확해집니다.
그렇지 않으면 그래프가 “요약된 주장”만 남아 오히려 출처가 흐려질 수 있습니다.
즉, GraphRAG든 Vectorless RAG든 “출처 고정”을 제품 품질의 중심에 놓는다면, **근거 단위를 어디에 붙일지(문서 구간 vs 그래프 엣지/레코드)**가 설계의 승부처가 됩니다.
제가 정리한 실전 결론: “문서 유형/질의 유형”이 답을 정합니다
Vectorless RAG vs Vector RAG를 기술 우열로 보기보다, 아래처럼 질문을 바꿔야 합니다.
1) 문서 구조가 강하고, 인용이 중요한가?
- 예: 정책/규정/감사 문서, 기술 매뉴얼, 계약서, 표준 문서
→ **구조 기반 탐색(Vectorless 성향)**이 정확도·추적성에서 유리합니다.
2) 문서가 많고, 먼저 “관련 후보”를 싸게 줄여야 하는가?
- 예: 대규모 문서 저장소, 다문서 검색 포털
→ 벡터 검색 + 리랭킹 같은 후보 축소 장치가 여전히 강합니다.
3) 질문의 본질이 “관계/경로/제약”인가?
- 예: 권한 그래프, 공급망, 거래/이벤트 네트워크, 영향 분석
→ 그래프 DB + (필요 시) 벡터/텍스트 RAG 보조가 더 정답에 가깝습니다.
결국 많은 팀에게 가장 현실적인 답은 이 조합입니다.
- Vector로 넓게 찾고(재현율/확장성)
- 구조/그래프로 좁히고 설명한다(정확도/추적성)
마무리
Vectorless RAG 논의가 좋은 이유는 “벡터DB를 쓰냐 마냐”가 아니라, RAG의 목표를 검색 성능에서 출처 추적 가능한 정확성으로 다시 정의하게 만들기 때문입니다. 제 경험상, 내 문서와 질문이 무엇인지부터 분류하고(구조/대규모/관계), 그에 맞춰 하이브리드로 균형점을 찾는 게 가장 빠른 길입니다.
