OmniRetrieval: 异构知识源上的统一检索

TL;DR OmniRetrieval 用自然语言查询统一调度文本、关系表与图等异构知识源，保留各源结构优势并生成原生查询，跨 309 个知识库超越单源基线，实现通用检索引擎。

问题

在现实信息需求中，用户常需从 非结构化文本、关系型数据库、知识图谱 以及 属性图 等多种结构各异的知识源中获取答案。然而，当前的检索系统大多为单一后端设计，依赖固定的查询语言（如 SQL、SPARQL、Cypher 或关键词搜索），导致多源知识被割裂在互不兼容的接口背后。简单地将所有源映射到共享向量空间虽能统一接口，却会 抹除模式、本体、组合操作符 等赋予每个源独特表达力的结构特性，使检索无法利用底层数据的精确语义。

核心技术难点在于：如何在不丢失各知识源结构优势的前提下，构建一个通用自然语言查询层？这要求系统同时解决三个挑战：1) 源选择：从候选知识库中准确识别与查询相关的源；2) 源原生查询生成：将自然语言转化为目标源的精确查询语言，并保留其特有的组合语义（如图遍历、表连接）；3) 跨源证据融合：从多个异构源返回的结果中筛选和整合最终答案。尤其在长上下文场景下，候选知识库数量可达数百个，需要高效路由与精准原生查询生成，否则极易因错误源或错误语法而失效。

该问题的重要性随着企业知识库类型的爆炸式增长而愈发凸显：文档、报表、图数据共存已成常态，但现有工具链仍迫使开发者逐一对接。OmniRetrieval 论文通过构建覆盖 13 个数据集、309 个知识库的基准，量化了统一检索的价值，证明了保留结构差异的“各司其职”式检索远优于统一表示方案。此方向有望成为下一代知识引擎的核心组件，降低数据访问门槛，使非技术用户也能用自然语言高效调度多模态知识。

一个恰当的类比是：就像智能操作系统中的全局搜索，用户只需输入“上周销售报告中的关键图表”，系统便能自动判断要去文件系统搜文档、到数据库执行聚合查询、再到图里找关联的客户节点，而不必分别打开各应用并手动编写对应指令。

核心洞察

• - 保留异构知识源的结构多样性，而非强制统一表示，是实现高效检索的关键。OmniRetrieval 与将不同数据源压缩为统一向量或文本块的方法相逆，通过**源选择**与**原生查询生成**让各源保持固有模式、本体、组合操作符，避免了结构信息的丢失。在 13 个数据集、309 个知识库上的实验表明，该框架显著超越单源基线及统一表示基线，证明了“适配而非同化”的设计在准确率与可解释性上的优势。
• - “自然语言→源选择→原生查询→跨源证据选择”的流水线为多源知识编排提供可扩展范式。框架先识别问题最适合的知识源，再生成 SQL、SPARQL 等原生查询，分发到对应引擎，最后进行**跨源证据选择**。相较于固定查询语言或硬融合，新增知识源仅需实现一个查询适配器，无需全局重训。这种松耦合设计降低了企业级多知识库集成的工程成本，且长上下文下的源选择能力使模型能处理大规模源列表，展现出实际落地弹性。

方法

输入

OmniRetrieval 接受自然语言查询，涵盖事实查询、分析需求和比较型问题，无需用户指定目标知识源或查询语言。

关键模块

OmniRetrieval 由三个核心模块串联组成，形成“判断→生成→筛选”的流水线：

• 源选择（Source Selection）：将查询与所有候选知识源（文档、关系数据库、RDF 知识图谱、标注属性图）的元信息（如模式描述、本体摘要）一并编码，借助 LLM 的长上下文能力判断各源与查询的相关性，输出一个或多个应被检索的源列表。该步骤避免了对无关源的全量扫描，提升了效率。

• 查询生成（Query Formulation）：针对选中的每个源，模块根据该源的原生查询语言（例如关系库的 SQL、RDF 的 SPARQL、属性图的 Cypher/Gremlin）生成对应的查询语句。生成过程会注入源的结构信息（表结构、关系定义、属性键），以充分利用其特有的组合运算符和约束机制，而非将查询转换为统一的中间表示。

• 执行与跨源证据选择（Cross-Source Evidence Selection）：在各源的执行引擎上运行生成的查询，获得初步结果后，跨源选择器通过对比不同源返回的片段（文本块、表格行、图谱子图），评估它们对原始查询的覆盖度和互补性，最终合成一个精简且无冗余的证据集合。该选择器可基于 LLM 进行重排序和融合，确保最终输出既保留各源的结构优势，又消除跨源信息冲突。

输出

最终输出为与查询相关的跨源检索证据集，形式可能是文档段落、结构化记录或图模式，可直接供下游生成式模型消费。

与同类方法的差异

与将所有源统一映射到同一向量空间或纯文本表示的方案不同，OmniRetrieval 不在表示层做同质化，而是为每个源生成原生查询，完整保留了模式表达、关系约束和声明性聚合能力，从而在异构知识环境中取得更高的检索精度和更好的可解释性。

实验

实验设计概述

OmniRetrieval 在由 13 个数据集、309 个知识库构成的基准上测试，覆盖文档搜索、关系数据库、RDF 知识图谱和带标签属性图。基线包括：单一后端检索器（仅用某一类源）、KB Routing（顺序路由）、Oracle（理想上限）和 Unified-Representation（将异构源压入统一空间）。评估流程依次为源选择、原生查询生成和跨源证据选择，指标包含源选择准确率、检索准确率和 LLM-as-a-Judge。

关键发现

1. OmniRetrieval 在所有范式上均超越单一来源基线，证明其作为通用接口的可行性。
2. 原生查询生成利用各源的结构特性（模式、组合算子），显著优于统一表示方案，尤其在需要精确结构查询的场景。
3. 跨源证据选择对多源联合信息需求有明显提升，源候选规模增大时性能保持稳定，且增大骨干模型能够持续带来收益。

与基线的深度对比

• vs KB Routing：直接源选择避免了顺序路由的延迟和错误级联，在源数量多时优势更突出。
• vs Unified-Representation：保留各源表达能力，规避了压缩导致的语义损失和查询能力退化。
• vs Oracle：OmniRetrieval 的源选择与查询生成已逼近理想上限，且框架可扩展至新知识源而不损失性能。

这一结果表明，面对异构知识基底的现实挑战，构建一个可解释、可扩展的检索层，无需牺牲各源的结构优势，即可实现高效统一的信息获取。

行业影响

落地场景

OmniRetrieval 为任何需要同时查询多种异构知识源的产品提供了一站式自然语言接口。典型场景包括：

• 企业知识管理：员工通过统一搜索框即可同时检索内部 wiki、数据库报表、供应链图谱等，无需切换系统。
• 智能客服与对话式 AI：在处理用户问题时，动态组合产品手册（文本）、订单状态（关系表）、用户画像（图）和 FAQ（文档）等多源信息。
• 数据分析与商业智能：业务人员用自然语言提问，系统自动从数据仓库、实时指标看板、业务知识图谱中聚合答案，取代手动跨平台查询。

商业价值

• 降本：消除为每个知识源单独开发和维护检索接口的重复工程成本，并减少人工整合多源信息的人力消耗。
• 增收：更全面、准确的检索结果可提升客户满意度、缩短决策周期，在客服、销售、研究等场景中直接或间接驱动收入增长。
• 体验提升：用户获得无缝、跨源的一站式搜索体验，减少认知负担和操作路径，增强产品粘性和生产力。

与现有产品 / 工作流的接口

OmniRetrieval 可作为中间件嵌入现有 RAG（检索增强生成）栈。它通过 LLM 进行源选择与原生查询生成，并以统一 API 对接各类后端执行引擎（如 Elasticsearch、PostgreSQL、Neo4j、RDF 存储）。集成时只需提供各源的 schema 描述与少量样例，无需改造底层数据结构。在 LangChain、LlamaIndex 等框架中，可封装为自定义 Retriever 组件，与已有的向量检索、重排序等模块组合使用。

具体落地用例

1. 电商智能客服
   用户提问：“我的订单 ORD-1234 何时到货？同一商品有没有相似款式？”系统需同时查询订单关系数据库（物流状态）、商品文档库（产品描述）、商品知识图谱（替代关系）。OmniRetrieval 将自然语言分解为 SQL 查询和图查询，派发至对应引擎，最终汇总回答，避免客服在多系统中切换。

2. 医疗临床决策支持
   医生查询：“对青霉素过敏的肺炎患者，推荐哪种抗生素？”需要检索药品相互作用知识图谱（如 DrugBank）、患者电子健康记录（结构化过敏史）、临床指南文档。统一接口确保不遗漏任何关键证据，降低用药风险，并自动生成带引用来源的建议。

局限

• **源选择的扩展性瓶颈**：OmniRetrieval 在源选择阶段将所有候选知识源的描述拼接为长上下文输入 LLM，虽然实验分析了候选数量从 3 到 20 的影响，但当面对数百个动态变化的异构源时，上下文长度和推理延迟将急剧增长，且论文未评估多轮或流式场景下的效率退化。实际工程中知识源目录会频繁更新，每次都重新构造全量提示既不经济也缺乏增量更新机制。
• **跨源证据融合能力有限**：框架将跨源证据选择作为一个独立的后续排序步骤，仅对来自不同源的候选结果重新打分，并未深入处理源间信息矛盾、冗余或互补关系。实验表明 OmniRetrieval 在需要联合推理多源证据的查询上虽优于单源基线，但离 Oracle 仍有显著差距，而 Oracle 需要假设理想的多源证据对齐，说明现有机制对复杂多跳跨源推理的支持仍然不足。
• **对非标准查询引擎的适配成本高**：OmniRetrieval 假设每个知识源都有成熟的 native execution engine 并支持结构化查询语言（如 SQL、SPARQL、Cypher）。对于仅有自定义 API 或弱结构化访问接口的数据源，生成 native query 的难度会显著增加，框架并未提供中间抽象层或适配器模式，这给实际接入新型数据源（例如向量数据库、搜索引擎）带来额外工程开销。