벡터 RAG와 FTS5 RAG는 대체재가 아니라 협력자 — 최신 실측이 밝힌 덴스와 스파스의 역할

핵심 요약

• RAG에서 문서를 찾는 방식은 크게 벡터(덴스) 검색과 키워드(스파스/FTS5) 검색 둘로 나뉩니다. 벡터는 의미 유사성으로, 키워드는 정확한 단어 일치로 문서를 찾습니다.
• 최신 논문 "Dense Expands, Sparse Anchors"(arXiv 2608.15851, 2026-08-16)가 둘의 역할을 실측으로 규명했습니다. 벡터는 의미를 확장하고, 키워드는 정확한 앵커를 잡습니다.
• 이 논문의 핵심 발견은 하이브리드 퓨전에서 cutoff가 결과를 뒤집는다는 것입니다. "벡터가 최고"라는 결론은, 같은 데이터셋에서도 측정 방식에 따라 달라질 수 있습니다.
• 채널 비대칭 쿼리 확장(DESA)은 벡터+키워드 양쪽에 각각 맞는 확장을 적용해, nDCG@10 +3.82%, Recall@20 +2.38%를 얻고 검색 접근 깊이를 36% 줄였습니다.
• 실전에서는 벡터 + FTS5 하이브리드가 가장 실용적입니다. Hermes·OpenClaw 같은 에이전트 메모리도 SQLite+FTS5를 채택하는 로컬 퍼스트 트렌드가 이어지고 있습니다.

벡터 RAG와 FTS5 RAG는 무엇이 다른가

RAG(Retrieval-Augmented Generation)는 모델이 답하기 전에 관련 문서를 찾아 참고하게 하는 기법입니다. 이때 "어떻게 관련 문서를 찾는가"가 RAG 품질을 좌우합니다. 두 가지 대표적 방식이 있습니다.

벡터 RAG (덴스 검색) — 문서와 쿼리를 임베딩(벡터)으로 변환하고, 코사인 유사도로 가장 가까운 문서를 찾습니다. "자동차"와 "vehicle"처럼 단어는 다르지만 의미가 같은 경우를 포착합니다. 단, 임베딩 모델이 필요하고, 고유명사·코드·정확한 ID는 상대적으로 약합니다.

FTS5 RAG (키워드/스파스 검색) — SQLite에 내장된 FTS5(Full-Text Search)로 정확한 단어 일치·토큰 매칭을 수행합니다. 임베딩이 필요 없어 경량이고 오프라인에서 도는데, 의미 유사성·동의어 검색은 약합니다. 대신 "완전한 기능의 키워드 인덱스"가 그대로 들어있어 정확 매칭에 강합니다.

전통 검색에서 BM25(스파스)와 덴스 임베딩의 비교는 오래된 주제입니다. 최근엔 이 둘을 하이브리드로 결합하는 것이 표준이 됐습니다.

두 방식의 차이를 실용적인 예로 보면 명확해집니다. 코드베이스를 검색한다고 가정합니다.

• "인증 로직이 어디 있지?" → 벡터가 유리합니다. "auth", "login", "credential"처럼 단어는 달라도 의미가 같은 파일을 찾습니다.
• "fetchUserById 함수를 찾아줘" → FTS5가 유리합니다. 정확한 함수명 fetchUserById는 임베딩이 의미를 헷갈리기 쉬운 고유명사라, 키워드 매칭이 확실합니다.

즉, 개념 질문은 벡터가, 정확한 식별자는 키워드가 잘 잡습니다. 이 차이를 이해하는 것이 하이브리드를 설계하는 출발점입니다.

실제 구현 단계에서 하이브리드를 구성하는 과정을 살펴봅니다. 먼저 문서를 FTS5 테이블로 색인하고, 동시에 벡터 컬럼으로 임베딩을 저장합니다. 검색 단계에서는 쿼리를 키워드로 FTS5를 조회하고, 임베딩으로 벡터 검색을 실행해 두 결과를 합칩니다. 코드 스니펫과 매뉴얼을 함께 가진 지식 베이스라면, 코드는 FTS5가, 매뉴얼 개념 질문은 벡터가 담당하게 구성합니다.

최신 실측: Dense Expands, Sparse Anchors

2026년 8월 arXiv에 올라온 논문 "Dense Expands, Sparse Anchors"(2608.15851)가 이 문제를 가장 세밀하게 다룹니다.

핵심 주장은 두 가지입니다.

첫째, 하이브리드 퓨전의 cutoff가 결과를 뒤집는다. 하이브리드 검색은 보통 상위 K개의 덴스 결과와 K개의 스파스 결과를 섞습니다. 그런데 이 K(cutoff) 값에 따라 "어느 채널이 더 기여하는가"가 달라집니다. 한 K에서 벡터가 이긴 것처럼 보여도, 다른 K에서는 키워드가 이깁니다. 즉, "벡터가 최고다"는 측정 방식의 산물일 수 있습니다.

둘째, 벡터와 키워드는 역할이 다르다.

• Dense(벡터)는 확장한다 — 의미적으로 관련된 새로운 방향을 쿼리에 더함
• Sparse(키워드)는 앵커로 작동한다 — 쿼리의 원래 어휘 범위를 넓히지 않고 정확한 어휘 신호를 강화

이 둘을 각 채널 특성에 맞게 다르게 확장하는 DESA 방법이 결과를 냅니다.

즉, 벡터로 의미를 넓히고 키워드로 정확 앵커를 잡으면, 같은 검색 품질을 더 적은 계산으로 얻습니다.

실전: SQLite FTS5 하이브리드가 실용적인 이유

논문은 이론적 최적을 보여주지만, 실전 구현에서 가장 실용적인 선택은 SQLite의 FTS5를 벡터 검색과 결합하는 것입니다.

SQLite FTS5의 장점:

• 임베딩 불필요 — 경량, 오프라인, 로컬에서 즉시 동작
• 정확 매칭 강함 — 코드·고유명사·버전 문자열·ID처럼 임베딩이 헷갈려하는 것을 정확히 잡음
• 내장 — 별도 벡터 DB 없이 SQLite만으로 시작 가능

이런 이유로 에이전트 메모리 분야에서 로컬 퍼스트 + SQLite+FTS5 트렌드가 뚜렷합니다. Hermes·OpenClaw 생태계의 최신 프로젝트들이 이를 채택합니다.

이들의 공통점은 "벡터만 쓰지 않는다" 입니다. 정확한 recall이 중요한 에이전트 메모리에서는 키워드(FTS5)의 앵커 역할이 필수이고, 의미 확장은 벡터가 맡는 하이브리드 구조입니다.

판단 — 무엇을 써야 하나

벡터 RAG와 FTS5 RAG 중 무엇을 쓸지, 실용적 판단 기준입니다.

• 정확한 식별자 검색이 많다면 FTS5가 강합니다. 코드 함수명, 고유명사, 제품 ID, 버전 문자열처럼 임베딩이 의미를 못 담는 경우, 키워드 매칭이 확실합니다.
• 동의어·의역·개념 검색이 필요하면 벡터가 강합니다. "자동차 안전"과 "vehicle safety"처럼 단어가 달라도 의미가 같은 경우, 벡터가 포착합니다.
• 대부분의 실전은 하이브리드가 정답입니다. 논문 실측대로, 벡터(확장) + 키워드(앵커)를 함께 쓰면 품질이 높아지고 계산도 줄어듭니다.
• 경량·로컬이 필요하면 SQLite FTS5로 시작하십시오. 임베딩 파이프라인 없이 바로 동작하고, 나중에 벡터 컬럼을 추가해 하이브리드로 확장할 수 있습니다.
• 측정 방식을 명시하십시오. DESA가 보여주듯 cutoff에 따라 결론이 뒤집힙니다. "벡터가 더 낫다"는 주장은 어떤 K에서 측정했는지를 밝혀야 검증 가능합니다.

결론은 이렇습니다. 벡터 RAG와 FTS5 RAG는 대체재가 아니라 서로 다른 역할의 협력자입니다. 벡터가 의미를 넓히고 FTS5가 정확한 앵커를 잡는 하이브리드가 최신 실측(DESA)과 실전(에이전트 메모리) 모두에서 최선입니다. 특히 SQLite FTS5는 경량·로컬·오프라인에서 시작하기 좋은 실용적 출발점입니다.

참고 링크

• Dense Expands, Sparse Anchors: Channel-Asymmetric Query Expansion for Hybrid Retrieval — arXiv 2608.15851
• Blended RAG: Improving RAG Accuracy with Semantic Search and Hybrid Query-Based Retrievers — arXiv 2404.07220
• Match Your Words! A Study of Lexical Matching in Neural Information Retrieval — arXiv 2112.05662