OmniRetrieval: 소스 네이티브 쿼리 디스패치 (Source-Native Query Dispatch)

무엇인가 (What): OmniRetrieval 논문은 **소스 네이티브 쿼리 디스패치 (source-native query dispatch)**를 소개합니다. 이는 라우터 (router)가 자연어 쿼리를 가장 적합한 지식 소스 — 텍스트, 테이블, 또는 그래프 — 로 보내고, 모든 것을 하나의 벡터 저장소 (vector store) 에 임베딩 (embedding) 하는 대신 각 소스 고유의 쿼리 엔진 (query engine) 을 실행하는 방식입니다.

왜 필요한가 (Why): 많은 벡터 우선 (vector-first) RAG 스택은 모든 소스를 단일 임베딩 후 ANN (embed-then-ANN) 파이프라인으로 평탄화 (flatten) 하는데, 이는 테이블과 그래프를 유용하게 만드는 구조를 버리게 됩니다. 각 소스를 네이티브 (native) 상태로 유지하면 조인 (JOINs) 및 그래프 엣지 (graph edges) 가 검색 과정에서 보존되어, 생성기 (generator) 가 단순한 평탄 유사도 검색 (flat similarity search)으로는 조립할 수 없는 답변을 볼 수 있게 됩니다.

이전 방식과의 차이 (vs prior): 이전의 기본 방식은 통합 벡터 인덱스 (unified vector index) 입니다. 즉, 모든 것을 청크 (chunk) 단위로 나누고, 임베딩하고, 함께 근접 이웃 (nearest-neighbour) 검색을 수행합니다. 이 방식의 실패 모드는 구조적 붕괴 (structural collapse) 입니다. 테이블의 컬럼 (column) 관계와 그래프의 엣지 (edges) 가 단일 벡터로 평균화되어 더 이상 구조로서 쿼리될 수 없게 됩니다.

비유하자면

각 질문을 적절한 전문 직원에게 배정하는 안내 데스크와 같습니다.

                질문 (THE QUERY)
                    │
             라우터 (router, 직원)
...

질문 (query) = 안내 데스크에 전달된 질문
라우터 (router) = 어느 전문가에게 물어볼지 결정하는 직원
소스 네이티브 쿼리 (source-native query) = 각 전문가에게 그들만의 언어(원장, 기록 보관소, 가계도 등)로 질문하는 것
통합 벡터 인덱스 (unified vector index) = 모든 문서를 동일한 인덱스 카드가 담긴 하나의 통에 갈기갈기 찢어 넣는 것
보존된 구조 (preserved structure) = 원장은 컬럼을 유지하고 가계도는 선을 유지하는 것

빠른 용어 정리

RAG — 검색 증강 생성 (Retrieval-Augmented Generation) — 지식 저장소에서 관련 컨텍스트 (context) 를 가져온 다음, 이를 바탕으로 모델을 조건화 (condition) 하는 방식입니다.

벡터 인덱스 (Vector index) — 기본 RAG 저장소: 모든 청크 (chunk) 는 고정된 차원의 벡터로 임베딩되며, 검색 시 코사인 (cosine) 또는 내적 (dot-product) 유사도에 따라 상위 k개 근접 이웃 (top-k nearest) 을 반환합니다. 청크 내부의 구조는 보존되지 않으며, 임베딩 공간에서의 위치만 보존됩니다.

ANN — 근사 최근접 이웃 (Approximate Nearest Neighbour) — 정확도를 속도와 맞바꿈으로써 벡터 검색을 빠르게 만드는 인덱스 제품군 (HNSW, IVF, FAISS)을 의미합니다.

소스 네이티브 쿼리 (Source-native query) — 공유된 임베딩 공간에서의 단일 유사도 검색 대신, 소스를 자체 엔진에서 실행하는 방식입니다. 즉, 구절(passages)에 대한 전체 텍스트 검색 (full-text search), 테이블에 대한 (JOIN을 포함한) SQL 스타일 쿼리 (SQL-style query), 그래프에 대한 순회 (traversal) 등을 의미합니다.

이종 소스 검색 (Heterogeneous-source retrieval) — 비정형 텍스트, 관계형 테이블, 그래프와 같이 서로 다른 종류의 소스에 걸쳐 검색을 수행하며, 이를 하나의 표현 방식으로 균질화하는 대신 각자의 네이티브 형태 그대로 유지하는 방식입니다.

지식 베이스 (Knowledge base, KB) — 시스템이 검색을 수행하는 단일 코퍼스 (corpus)입니다. OmniRetrieval 보고서에 따르면 13개의 데이터셋에 걸친 309개의 별도 KB를 대상으로 평가를 진행했습니다.

뉴스. 2026년 5월 29일, OmniRetrieval 논문 (arXiv:2605.29250)은 자연어 쿼리를 수락하여 이를 적절한 지식 소스(비정형 텍스트, 관계형 테이블 또는 그래프)로 **라우팅 (routing)**하는 검색 프레임워크를 제안했습니다. 이 프레임워크는 모든 것을 단일 임베딩 인덱스로 평탄화(flattening)하는 대신, 각 소스의 **네이티브 쿼리 (native query)**를 해당 실행 엔진으로 전달(dispatching)합니다. 저자들은 13개의 데이터셋과 309개의 별도 지식 베이스를 통해 평가를 수행했으며, 단일 소스 검색 베이스라인을 상회하는 결과를 보고했습니다.

안내 데스크를 다시 상상해 보십시오. _"3분기에 베를린 창고로 물품을 보낸 공급업체는 어디이며, 누가 그들을 소개했는가?"_라는 질문이 들어옵니다. **직원 (clerk)**은 이 질문을 하나의 무미건조한 공용어로 번역하여 건물 전체에 외치지 않습니다. 대신 질문을 분리합니다. **기록 보관 전문가 (archivist)**는 산문 형태의 계약서를 검색하고, **회계사 (accountant)**는 장부의 수치를 계산하며, **계보학자 (genealogist)**는 인물 관계 그래프를 탐색합니다. 각 전문가는 장부의 열(column)이나 가계도의 선과 같이 자신의 영역을 유용하게 만드는 구조를 유지하며, 자신들만의 언어로 답변합니다.

위의 애니메이션은 그 책상을 나타냅니다. 첫 번째 박자(beat)에서 쿼리는 **쿼리(query) → 라우터(router) → 하나의 평면 벡터 인덱스(one flat vector index)**로 흐릅니다. 모든 소스는 동일하고 균일한 벡터 그리드로 파쇄되며, 테이블의 JOIN 호(arc)와 그래프의 **에지(edges)**는 점선과 회색으로 변합니다. 즉, 구조를 쿼리할 수 없는 임베딩 공간(embedding space)으로 평탄화(flattened)되는 것입니다. 그 다음 라우터가 _평탄화(flatten)_에서 _디스패치(dispatch)_로 전환됩니다. 동일한 세 개의 소스가 각자의 네이티브(native) 형태로 불이 들어오고, 세 가지 유형의 쿼리인 텍스트 검색(text search), 테이블 쿼리 · JOIN(table query · JOIN), **그래프 탐색(graph traversal)**이 펼쳐지며, JOIN 호와 그래프 에지가 녹색으로 복원됩니다.

이 메커니즘은 **라우터와 소스별 엔진(router plus per-source engines)**의 결합입니다. 하나의 균질화된 저장소에 대해 임베딩 후 ANN(Approximate Nearest Neighbor) 조회를 수행하는 대신, OmniRetrieval은 각 소스 고유의 언어로 쿼리를 생성하여 해당 소스의 엔진에서 실행한 다음, 생성기(generator)를 위해 이 이질적인(heterogeneous) 결과들을 통합합니다. 테이블이 관계형(relational) 형태를 벗어나지 않았기 때문에 JOIN은 여전히 키(key)를 통해 행(row)을 구성하며, 그래프가 노드-에지(node-edge) 형태를 벗어나지 않았기 때문에 **탐색(traversal)**은 여전히 에지를 따라갑니다. 이것들이 바로 단일 유사도 벡터(similarity vector)가 지워버리는 **구조적 어포던스(structural affordances)**입니다.

평탄화가 정답을 놓치는 이유

Berlin에 관한 질문을 고정하고 두 가지 경로를 따라가 봅시다. 정답을 구하기 위해 supplier_id를 기준으로 5,000행의 공급업체 (suppliers) 테이블과 40,000행의 배송 (shipments) 테이블을 JOIN해야 한다고 가정해 보겠습니다. 관계형 경로 (relational path)는 키 매칭을 정확하게 (exactly) 평가합니다. 즉, 모든 배송 건이 해당 공급업체로 연결되며, 이후 소개 (introductions) 그래프를 통해 그들을 소개한 사람들에게로 두 번의 홉 (two hops)을 거쳐 탐색합니다. 반면, 평탄 인덱스 (flat-index) 경로는 각 행을 예를 들어 768차원 (768-dimension) 벡터로 임베딩하고, 쿼리에 대해 예를 들어 top-k = 20개의 가장 가까운 청크 (chunks)를 반환합니다. 2억 개의 잠재적인 공급업체-배송 쌍 **(5,000 × 40,000 = 200,000,000, 예시적 수치)**이 코사인 유사도 (cosine distance)에 의해 선택된 **20개의 모호한 이웃 (fuzzy neighbours)**으로 붕괴되어 버립니다. 그리고 "그들을 누가 소개했는가"는 임베딩 과정에서 엣지 (edge)로 포함되지 않았던 하나의 _엣지 (edge)_일 뿐입니다. 평탄 인덱스에서 JOIN과 탐색 (traversal)이 느린 것이 아닙니다; 그것들이 아예 존재하지 않는 것입니다. 이것이 바로 소스 네이티브 디스패치 (source-native dispatch)가 제거하기 위해 설계된 RAG 실패 모드 (RAG failure mode)의 근원입니다.

평탄 벡터 인덱스 (Flat vector index) vs. 소스 네이티브 디스패치 (Source-native dispatch)

속성	통합 벡터 인덱스 (Unified vector index)	소스 네이티브 디스패치 (Source-native dispatch)
사전 구축된 인덱스	모든 소스에 대한 단일 임베딩 패스 + ANN 인덱스	각 소스가 고유의 엔진 (전체 텍스트, SQL, 그래프)을 유지
...	...	...

이 표는 임베딩이 쓸모없다는 주장을 뒷받침하는 것이 아닙니다. 산문 (prose)에 대한 모호한 주제적 회상 (fuzzy topical recall)은 벡터 인덱스가 정확히 잘하는 일입니다. 문제는 단일한 표현 방식이 텍스트, 테이블, 그리고 그래프 모두에 대해 동시에 적절한 표현이 될 수는 없다는 점입니다. **소스 네이티브 쿼리 (source-native query)**로 라우팅하면 각 소스가 실제로 보유한 구조를 사용하여 답변할 수 있고, 그 후에 비로소 통합됩니다. 따라서 생성기 (generator)는 단순한 이웃들의 주머니 (bag of nearest neighbours)가 아니라, 구성된 관계 (composed relations)를 전달받게 됩니다.

더 자세한 내용: AI 에이전트 (AI Agents) → 검색 및 RAG (Retrieval & RAG) → RAG 실패 모드 (RAG Failure Modes)

FAQ

소스 네이티브 쿼리 디스패치 (source-native query dispatch)란 무엇인가요?

이는 라우터(router)가 비정형 텍스트(unstructured text), 관계형 테이블(relational table), 또는 그래프(graph) 등 적합한 지식 소스에 자연어 쿼리를 전달하고, 모든 것을 하나의 공유 벡터 저장소(vector store)에 임베딩(embedding)하는 대신 해당 소스 고유의 쿼리 엔진(전체 텍스트 검색(full-text search), JOIN을 포함한 SQL 스타일 쿼리, 또는 그래프 순회(graph traversal))을 실행하는 검색 설계입니다. OmniRetrieval은 13개의 데이터셋과 309개의 지식 베이스에 대해 이를 수행하였으며, 단일 소스 기준점(baseline)을 상회하는 성능을 기록했다고 보고했습니다.

왜 테이블과 그래프를 동일한 벡터 인덱스에 임베딩하지 않나요?

임베딩은 구조를 붕괴시키기 때문입니다. 테이블의 컬럼(column)과 그래프의 엣지(edge)는 유사도(similarity)에 의해 위치가 결정되는 단일 벡터가 되어버립니다. 따라서 JOIN을 통해 키(key)로 행을 구성하거나, 순회(traversal)를 통해 엣지를 따라가는 것이 더 이상 불가능해집니다. 이러한 관계들은 속도가 느려지는 것이 아니라, 평균화되어 사라져 버립니다. 각 소스를 네이티브(native) 상태로 유지하면 관계형 질문이나 멀티 홉(multi-hop) 질문에 답할 수 있는 구조적 기능(structural affordances)을 보존할 수 있으며, 이는 단일 공간에 대한 top-k 최근접 이웃(nearest-neighbour) 조회로는 재구성할 수 없는 부분입니다.

이것이 벡터 검색(vector retrieval)이 쓸모없어졌다는 의미인가요?

아니요. 의미론적 유사성(semantic similarity)이 핵심적인 역할을 하는 균질한 산문(homogeneous prose)에 대해 퍼지(fuzzy)하고 주제 중심적인 회상을 수행할 때는 여전히 통합 벡터 인덱스가 적절한 도구입니다. 소스 네이티브 디스패치(source-native dispatch)가 중요한 경우는 답변이 서로 다른 종류의 소스에 걸쳐 있거나, JOIN이 필요한 테이블 또는 순회가 필요한 그래프와 같이 정확한 관계가 필요할 때입니다. 변화의 핵심은 기본 설정(default)에 있습니다. 먼저 소스의 네이티브 엔진으로 라우팅하고, 공유 임베딩 공간을 유일한 소스가 아닌 여러 소스 중 하나로 취급하는 것입니다.

원래는 Learn AI Visually에 게시되었습니다.