OmniRetrieval: Unified Retrieval across Heterogeneous Knowledge Sources
OmniRetrieval: 이종 지식 소스를 하나로 — 통합 검색 프레임워크
논문 제목: OmniRetrieval: Unified Retrieval across Heterogeneous Knowledge Sources
저자: Jinheon Baek, Soyeong Jeong, Sangwoo Park, Woongyeong Yeo, Minki Kang
arXiv: 2605.29250 | GitHub: JinheonBaek/OmniRetrieval
HuggingFace 피처일: 2025년 5월 29일 | arXiv 발표일: 2025년 5월 28일 | 업보트: 32
💡 한 줄 요약
자연어 질문 하나로 텍스트·관계형 테이블·지식 그래프 등 구조가 전혀 다른 지식 소스들을 동시에 검색하는 통합 프레임워크 OmniRetrieval을 제안한다.
📄 Abstract (초록 번역)
실세계의 정보 요구는 구조적으로 다양한 지식 소스에 대한 접근을 필요로 합니다. 비정형 텍스트(unstructured text)와 관계형 테이블(relational tables)부터 지식 그래프(knowledge graphs)와 속성 그래프(property graphs)에 이르기까지 다양합니다. 그러나 기존의 검색기(retriever)들은 고정된 질의 언어(query language) 하에서 한 번에 하나의 소스만 처리하도록 설계되어 있어, 서로 호환되지 않는 인터페이스 뒤에 방대한 지식의 세계가 분절된 채로 남겨져 있습니다.
통합을 위한 자연스러운 시도는 이 소스들을 하나의 공유 공간으로 압축하는 것이지만, 이렇게 하면 각 소스가 가진 표현력의 원천인 구조적 특성들(스키마, 온톨로지, 합성 연산자 등)이 지워집니다. 따라서 다양한 지식에 대한 효과적인 검색은 균질화(homogenization)가 아니라, 각 소스를 그 자체의 언어로 만나는 상위 레이어(overarching layer)를 필요로 합니다.
이를 달성하기 위해 우리는 OmniRetrieval을 제안합니다. 이 프레임워크는 임의의 자연어 질의를 받아, 적절한 지식 소스를 식별하고, 해당 소스의 고유 실행 엔진에 소스-네이티브 쿼리(source-native query)를 발송합니다. 텍스트, 관계형, 그래프 구조 소스에 걸쳐 13개의 데이터셋과 309개의 독립 지식 베이스를 포괄하는 광범위한 벤치마크에서, OmniRetrieval은 단일 소스 기준선(single-source baselines)을 능가하며, 각 소스의 가치를 부여하는 구조적 차이를 보존하면서 이종 소스들에 대한 범용 인터페이스로 기능할 수 있음을 입증합니다.
🔍 1. Introduction — 왜 이 문제가 중요한가?
그림 1: 각 지식 소스는 고유한 구조적 특성과 질의 언어를 가진다(왼쪽). OmniRetrieval은 소스 선택, 네이티브 쿼리 생성, 교차 소스 압축을 통해 각각의 소스를 그 고유한 방식으로 처리한다(오른쪽).
1.1 실세계 질문은 단 하나의 지식 소스에 머물지 않는다
현실 세계에서 우리가 던지는 질문들을 생각해봅시다.
| 질문 유형 | 필요한 지식 소스 | 질의 언어 |
|---|---|---|
| "이 약의 부작용은 무엇인가?" (임상 질문) | 생의학 논문 텍스트 (BEIR) | 자유 형식 텍스트 검색 |
| "이 기업의 부서별 매출은?" (엔터프라이즈 질문) | 관계형 테이블 (Spider, Bird) | SQL |
| "아인슈타인의 출생지는?" (사실 질문) | 지식 그래프 (Freebase, Wikidata) | SPARQL |
| "이 공급망의 병목은?" (네트워크 분석) | 속성 그래프 (Text2Cypher) | Cypher |
각 경우마다 답은 원칙적으로 검색 가능합니다. 하지만 어떤 데이터베이스를 참조해야 하는지, 어떤 질의 언어를 써야 하는지, 어떤 실행 엔진에 질의를 보내야 하는지 미리 알고 있어야만 가능합니다.
즉, 검색 문제는 단순히 소스 내에서 관련 내용을 찾는 것이 아니라, 소스 간에 걸쳐 있는 구조적 이질성(structural heterogeneity)을 탐색하는 것입니다.
1.2 기존 접근법의 한계
기존 검색 시스템들은 모두 단일 소스(single-source) 방식으로 설계되어 있습니다.
- 문서 검색기(Document Retrievers): BM25, DPR 같은 시스템은 비정형 텍스트 말뭉치(corpus)를 대상으로, 자유 형식 질의와의 유사도로 문서를 랭킹합니다.
- 텍스트-투-SQL(Text-to-SQL): Spider, Bird 같은 시스템은 단일 관계형 데이터베이스를 대상으로 SQL 쿼리를 생성합니다.
- SPARQL/Cypher 생성기: SPARQL은 RDF 저장소용, Cypher는 레이블된 속성 그래프(labeled property graph)용으로, 역시 단일 그래프 백엔드에 종속됩니다.
그 결과, 최신 LLM(Claude3, Gemini-2.5, GPT-5 등)이 다양한 소스의 증거를 바탕으로 추론할 수 있음에도, 이를 공급하는 검색 레이어가 모든 소스에 도달하지 못해 광범위한 지식 세계는 여전히 손 닿지 않는 곳에 있습니다.
1.3 "공유 공간으로 압축"은 해결책이 아니다
직관적인 해결책은 모든 소스를 하나의 벡터 공간으로 압축하는 것입니다. 예를 들어 테이블도, 그래프도, 텍스트도 모두 임베딩(embedding)해서 유사도 기반으로 검색하는 방식입니다. 그러나 이 접근은 치명적인 단점이 있습니다.
각 소스의 표현력을 부여하는 구조적 특성(스키마, 온톨로지, 조인 연산자, 경로 탐색 등)이 사라집니다.
SQL의 JOIN, SPARQL의 트리플 패턴 매칭, Cypher의 그래프 탐색 — 이것들은 단순한 텍스트 유사도로는 대체할 수 없는 정밀한 연산들입니다.
1.4 OmniRetrieval의 핵심 철학
OmniRetrieval은 균질화 대신, 각 소스를 그 자체의 언어로 만나는(meeting each source on its own terms) 상위 레이어를 구축합니다. 이를 통해:
- ✅ 각 소스의 구조적 특성 보존
- ✅ 새로운 소스 추가가 인프라 재구축 없이 "등록(registration)"만으로 가능
- ✅ 단일 자연어 인터페이스로 모든 소스에 접근 가능
🧩 2. 방법론 (Method) — OmniRetrieval은 어떻게 동작하는가?
2.1 문제 정의 (Problem Formulation)
공식적으로 문제를 정의해봅시다.
- q: 사용자의 자연어 질문
- ℬ = {b₁, ..., b_N}: 독립적으로 유지되는 지식 소스들의 풀(pool)
각 소스 b ∈ ℬ는 다음을 가집니다:
| 구성 요소 | 설명 | 예시 |
|---|---|---|
| 네이티브 질의 언어 | 해당 소스에 특화된 언어 | SQL, SPARQL, Cypher, 자유 형식 텍스트 |
| 실행 엔진 Exec(b, q̂) | 네이티브 쿼리 q̂를 받아 결과를 반환 | DB 엔진, 그래프 DB, 검색 인덱스 |
| 구조적 컨텍스트 c_b | 외부 호출자가 쿼리를 작성할 수 있도록 노출된 정보 | 관계형 스키마, 온톨로지, 말뭉치 설명자 |
검색 태스크: 질문 q에 대해, ℬ의 하나 이상의 소스에서 관련 증거를 찾아 제공하는 것.
이를 위해 프레임워크는 세 가지를 수행해야 합니다:
- 소스 선택: 참여할 소스의 부분집합 𝒮 ⊆ ℬ 결정
- 쿼리 생성: 각 b ∈ 𝒮에 대해 네이티브 언어로 실행 가능한 쿼리 q̂_b 생성
- 결과 통합: 실행기 출력들 {Exec(b, q̂b)}{b∈𝒮}를 단일 증거 집합으로 통합
핵심 강점: 각 소스가 자체 네이티브 언어로 처리되므로, 조인(join), 탐색(traversal), 속성 경로 같은 구조적 연산이 공유 공간에서의 근사 대신 그대로 보존됩니다. 또한 새 소스 추가는 인프라 재구축이 아닌 등록만으로 가능합니다.
2.2 소스 선택 (Source Selection)
등록된 소스들의 집합 ℬ는 크고 개방적(open-ended)입니다. 새 소스는 등록만으로 추가되고, 소스들을 구분하는 구조적 컨텍스트 {cb}{b∈ℬ}는 형태가 이질적입니다 (스키마는 테이블과 컬럼을 나열하고, 온톨로지는 클래스와 술어를 선언하며, 말뭉치 설명자는 문서의 주제와 스타일을 특성화합니다).
왜 단순한 임베딩 방식은 부족한가?
직관적인 접근은 각 c_b와 질의 q를 공유 벡터 공간에 임베딩하고 유사도로 소스를 랭킹하는 것입니다. 하지만 이 방식은 두 가지 이유로 제한적입니다:
- 설명자들이 형태가 균일하지 않아 단일 인코더가 이를 손실 없이 표현할 수 없음
- b가 q에 답할 수 있는지의 판단은 종종 c_b의 실제 내용(예: 관계형 스키마의 테이블 이름, 속성 그래프의 관계 유형)에 달려 있어, 유사도 점수만으로는 포착 불가
OmniRetrieval의 해법: 장문 컨텍스트 LLM 활용
최근 연구들(LOFT, ToTAL)이 장문 컨텍스트 LLM(long-context LLM)이 전체 말뭉치 규모의 텍스트 입력에서 직접 검색하고 추론할 수 있음을 보인 것에 착안하여, OmniRetrieval은 소스 설명자 전체를 질의와 함께 LLM에 입력하여 참여할 소스를 식별합니다.
공식화:
LLM(q, {c_b}_{b∈ℬ}) → 𝒮 ⊆ ℬ (관련성으로 정렬된 최대 k개의 소스)기존 연구들이 이 능력을 동질적(homogeneous) 말뭉치에만 활용한 것과 달리, OmniRetrieval은 각기 다른 형태의 설명자를 가진 이종 지식 소스들에 이를 적용하는 것이 핵심 차별점입니다.
2.3 쿼리 생성 (Query Formulation)
𝒮가 결정되면, 각 소스 b ∈ 𝒮의 네이티브 언어로 실행 가능한 쿼리 q̂_b를 생성합니다. 각 지식 소스는 자신이 쿼리하는 데이터의 구조에 의해 형성된 고유의 네이티브 질의 언어를 사용합니다:
| 소스 유형 | 질의 언어 | 주요 연산 |
|---|---|---|
| 관계형 DB | SQL | JOIN, GROUP BY, 집합 연산 |
| RDF 그래프 | SPARQL | 트리플 패턴 매칭, FILTER |
| 속성 그래프 | Cypher | 경로 탐색, 노드-엣지 패턴 |
| 비정형 텍스트 | 자유 형식 | 키워드, 시맨틱 쿼리 |
LLM은 질문 q와 해당 소스의 구조적 컨텍스트 c_b를 함께 읽고, 그 소스의 네이티브 언어로 정확한 쿼리를 생성합니다. 이것이 단순히 "키워드를 뽑는" 것과 다른 점입니다 — 실제 실행 엔진이 실행할 수 있는 정확한 쿼리를 생성해야 합니다.
2.4 교차 소스 압축 (Cross-Source Condensation)
여러 소스에서 실행 결과가 돌아오면, 이를 통합하는 과정이 필요합니다. 서로 다른 소스의 결과물은 형태가 다릅니다:
- 텍스트 검색 → 문단들의 목록
- SQL 실행 → 행과 열로 구성된 테이블
- SPARQL/Cypher 실행 → 트리플 집합 또는 경로 목록
OmniRetrieval은 이 이질적인 결과들을 단일 증거 집합으로 통합하여 최종 답변 생성(또는 다운스트림 추론)에 활용할 수 있도록 압축합니다.
📊 3. 실험 (Experiments)
3.1 실험 설정
OmniRetrieval은 매우 광범위한 벤치마크에서 평가되었습니다:
| 구성 요소 | 상세 |
|---|---|
| 데이터셋 수 | 13개 |
| 지식 베이스 수 | 309개 |
| 소스 유형 | 텍스트, 관계형(SQL), 그래프(SPARQL, Cypher) |
| 대표 벤치마크 | BEIR, Spider, Bird, Freebase, Wikidata, Text2Cypher |
이 규모는 기존 단일 소스 기반 평가와는 차원이 다른 포괄적인 평가입니다.
3.2 비교 대상 (Baselines)
- 단일 소스 기준선(Single-source baselines): BM25, DPR 등 기존 각 소스 특화 검색기
- 각 소스 유형별 최강 기존 모델들과 비교
3.3 주요 결과
OmniRetrieval은 모든 소스 유형에서 단일 소스 기준선을 능가했습니다. 이것이 의미하는 바는:
- 텍스트 검색에서도: 기존 문서 검색기보다 우수하거나 동등한 성능
- SQL 생성에서도: 텍스트-투-SQL 전용 시스템과 경쟁적인 성능
- 그래프 쿼리에서도: SPARQL/Cypher 전용 생성기 대비 경쟁력 있는 성능
특히 중요한 점은, OmniRetrieval이 어떤 소스가 관련 있는지 모르는 상황에서도 올바른 소스를 선택하고 적절한 쿼리를 생성할 수 있다는 것입니다. 이는 기존 시스템들이 불가능했던 시나리오입니다.
3.4 소스 선택 정확도
309개의 이종 지식 베이스 중에서 올바른 소스를 선택하는 것은 그 자체로 도전적인 과제입니다. 실험 결과, 장문 컨텍스트 LLM 기반의 소스 선택 방식이 임베딩 기반 유사도 랭킹보다 유의미하게 높은 정확도를 보였습니다. 이는 스키마 이름, 관계 유형 등 구체적인 구조적 정보가 소스 선택에 결정적임을 확인해줍니다.
🔚 4. Conclusion — 결론 및 한계
결론
OmniRetrieval은 이종 지식 소스들에 걸친 통합 검색이라는 오랫동안 해결되지 않은 문제에 대한 실용적인 해법을 제시합니다.
핵심 기여를 정리하면:
- 🏗️ 프레임워크 설계: 소스 선택 → 네이티브 쿼리 생성 → 교차 소스 결과 통합의 3단계 파이프라인
- 🔌 개방형 확장성: 새 소스는 등록만으로 추가 가능 (인프라 재구축 불필요)
- 💾 구조 보존: 각 소스의 구조적 특성(조인, 탐색, 패턴 매칭)을 희생하지 않음
- 📈 강력한 실험적 검증: 13개 데이터셋, 309개 지식 베이스에서 단일 소스 기준선 능가
한계 및 향후 과제
논문에서 명시적으로 논의된 한계들:
- LLM 의존성: 소스 선택과 쿼리 생성 모두 LLM 능력에 크게 의존 — LLM이 복잡한 스키마나 온톨로지를 잘못 해석하면 전체 파이프라인이 실패할 수 있음
- 장문 컨텍스트 비용: 모든 소스 설명자를 LLM에 입력하는 방식은 소스 수가 매우 많아질 경우 계산 비용이 급증
- 쿼리 생성 오류 복구: 생성된 네이티브 쿼리가 실행 엔진에서 실패할 경우의 오류 복구 메커니즘이 필요
- 동적 소스 업데이트: 지식 소스의 스키마나 내용이 변경될 경우 적응 방식
🧠 개인 소감
이 논문을 읽으면서 가장 인상 깊었던 점은 문제 정의의 명확함입니다. "균질화가 아닌, 각 소스를 그 자체로 만나라(not homogenization but meeting each source on its own terms)"는 철학은 단순하지만 심오합니다. 지금까지 많은 연구들이 모든 것을 벡터 공간으로 압축하는 방향으로 달려갔는데, OmniRetrieval은 오히려 "그 구조적 다양성이 가치"라고 말합니다. SQL의 JOIN이 수십 년간 살아남은 데는 이유가 있고, SPARQL의 트리플 패턴 매칭이 지식 그래프에 최적인 데는 이유가 있습니다 — 이것을 벡터 유사도로 흉내 낸다는 건 본질적으로 손실(lossy)입니다.
실용적인 관점에서도 이 연구는 매우 시의적절합니다. 기업들은 이미 SQL 데이터베이스, 문서 저장소, 지식 그래프를 동시에 운영하고 있습니다. 그런데 LLM 기반 RAG(Retrieval-Augmented Generation) 시스템을 구축할 때 "텍스트만" 또는 "DB만"을 대상으로 하는 경우가 대부분입니다. OmniRetrieval이 제안하는 방향은 실제 기업 환경에서 즉각적으로 가치 있는 해법입니다. 특히 새 소스를 "등록"만으로 추가할 수 있다는 설계는 실용적 확장성 측면에서 높이 평가할 만합니다.
다만 걱정되는 부분도 있습니다. 장문 컨텍스트 LLM에 모든 소스 설명자를 넣는 방식은, 소스가 수천 개로 늘어나면 현실적으로 불가능해집니다. 계층적 소스 선택(예: 먼저 소스 카테고리를 고르고, 그 안에서 구체적 소스를 선택)이나 소스 설명자의 효율적 압축 방법이 후속 연구로 필요해 보입니다. 그럼에도 불구하고, 이 논문은 "진정한 의미의 범용 검색(universal retrieval)"을 향한 중요한 첫 걸음을 내딛었다고 생각합니다.
🏷️ 태그
#OmniRetrieval #RAG #검색증강생성 #이종지식소스 #HeterogeneousRetrieval #Text2SQL #SPARQL #Cypher #지식그래프 #KnowledgeGraph #통합검색 #UnifiedRetrieval #LLM #NLP #정보검색 #InformationRetrieval #벤치마크 #AI논문리뷰
