Command Palette
Search for a command to run...
OmniRetrieval:跨异构知识源的统一检索
OmniRetrieval:跨异构知识源的统一检索
Jinheon Baek Soyeong Jeong Sangwoo Park Woongyeong Yeo Minki Kang Patara Trirat Heejun Lee Sung Ju Hwang
摘要
现实世界中的信息需求要求能够访问结构各异的知识源,涵盖从非结构化文本和关系型表格到知识图谱与属性图等多种形态。然而,现有的检索器通常基于固定的查询语言,一次仅针对单一数据源进行操作,这使得更广泛的知识资源因接口不兼容而处于碎片化状态。一种直观的统一尝试是将这些知识源映射至共享空间,但这会抹除赋予各源表达能力的结构特性(如模式、本体、组合算子)。因此,针对多样化知识的有效检索不应追求同质化,而需构建一个顶层抽象层,以适配各数据源自身的特性与规范。为实现这一目标,本文提出OmniRetrieval框架。该框架能够接收任意自然语言查询,自动识别适配的知识源,并将源原生查询分发至其对应的原生执行引擎。在涵盖文本、关系型及图结构数据源的13个数据集与309个独立知识库的广泛基准测试中,OmniRetrieval的性能均优于单一数据源基线。该结果证明,OmniRetrieval可作为面向异构知识源的通用接口,在保留各源核心价值之结构差异的同时实现高效检索。
一句话总结
OmniRetrieval 是一个统一的检索框架,能够接收自然语言查询,识别合适的异构知识源,并将源原生查询分发至其原生执行引擎,以保留结构优势。该框架作为通用接口,在 13 个数据集和 309 个独立的文本、关系型及图结构知识库上,均优于单源基线方法。
核心贡献
- OmniRetrieval 是一个统一的检索框架,可自动选择适当的知识源,并以各源的原生语言生成查询,从而保留非结构化文本、关系型表格和图数据库的结构优势,而非将其扁平化为共享表示。
- 该框架采用模块化分发架构,将现有的文本到查询生成器作为可插拔组件进行集成,同时在单一流水线中协同解决联合源选择、多语言查询生成及跨格式证据整合问题。
- 在涵盖 13 个数据集和 309 个知识库的基准测试中,该框架的表现持续优于单源基线方法,确立了其作为异构检索任务通用接口的地位。
引言
现实世界中的信息需求通常跨越非结构化文本、关系型表格和知识图谱,这使得统一检索成为实现准确且全面知识访问的关键。先前的检索系统通常在隔离的孤岛中运行。尽管部分研究尝试通过将数据映射到共享嵌入空间来统一这些源,但这些方法会抹平关键的结构优势,并使结果偏向表面相似度,而非语义相关性。为克服这些局限,作者提出了 OmniRetrieval 框架。该框架能够动态识别相关知识库,并以各源的原生语言生成可执行查询。通过将查询路由至专用后端并整合结构各异的输出,该系统在保留每种数据类型表达能力的同时,提供了一个可无缝扩展至新存储库的通用接口。
数据集
- 数据集构成与来源: 作者基于 13 个公开数据集构建了基准测试,这些数据集共同覆盖四种数据库后端,并提供 309 个独立的知识库。所有资源均来源于现有公开存储库,并在原始许可协议下用于研究目的。团队未对个人信息或不当内容进行额外过滤,而是遵循上游数据集的既定策略。
- 子集详情: 文档检索任务采用七个 BEIR 语料库,涵盖医疗、科学、金融、网页、维基百科及多跳问答领域,每个语料库均作为独立知识库使用。关系型数据库任务取自 206 个 Spider 数据库和 80 个 BIRD 数据库,共计 286 个 SQLite 文件。RDF 任务将三个数据集(SimpleQuestions、QALD-10、LC-QuAD 2.0)映射至单一 Wikidata 端点。属性图任务使用来自 Text2Cypher 的 15 个 Neo4j 图,覆盖电影、金融和社交网络等领域。作者为每个数据集精确采样 300 个问题以统一评估标准。
- 使用与处理: 该数据集专为基准测试而设计,而非用于模型训练。作者未定义训练集划分或混合比例,而是侧重于直接执行。每个采样问题均被转换为相应的查询语言,并在对应的后端(本地 SQLite 实例、公共 SPARQL 端点或 Neo4j 端点)上运行。
- 元数据与上下文构建: 作者为每个后端生成结构上下文描述符,以指导查询生成。针对文档集合,上下文为简要的主题摘要,概述领域特征与典型文档风格。关系型数据库接收通过
CREATE TABLE语句表达的全量模式,包含列类型与键约束。RDF 上下文按问题动态构建,结合固定的 SPARQL 前缀、关联至 Wikidata 标识符的主题实体,以及按语义相似度排名的前 30 个候选谓词。属性图提供完整的模式概览,详细说明节点标签、类型化属性键、关系类型及显式边三元组。
方法
OmniRetrieval 框架旨在通过统一访问层协调三个核心阶段:源选择、查询生成与跨源证据选择,从而实现跨异构知识源的检索。整体架构设计旨在保持各源的原生查询语言与结构语义,同时支持连贯的检索流程。框架首先从独立维护的知识库池中识别相关源,每个源均具备自身的原生查询语言与结构上下文。此初始步骤至关重要,可确保后续操作针对各源调用合适的后端,从而保留连接、遍历和路径查询等原生操作符的表达力。
如图所示,框架将用户问题 q 输入长上下文语言模型,从池 B 中筛选相关源子集。该选择过程通过将查询与所有可用源的结构描述符 cb 编码为模型输入,使模型能够根据问题相关性对源进行排序。该阶段的输出为包含最多 k 个源的有序列表 S,随后用于进入下一阶段。长上下文能力使模型能够在无需统一嵌入空间的情况下,对包含模式、本体和语料库摘要在内的全量源描述符进行推理,从而保留不同类型结构上下文之间的语义差异。
完成源选择后,框架以各选中源的原生语言生成可执行查询。对于每个源 b∈S,系统基于该源的结构上下文 cb 生成查询 q^b。该过程采用针对每个源定制的提示模板,整合用户问题 q、结构上下文 cb 以及指定目标查询语言的指令。查询生成依赖单一大型语言模型(LLM),根据后端类型输出 SQL、SPARQL、Cypher 或自由文本格式的有效查询。针对非结构化语料库,问题可能被改写为假设性段落以提升检索效果;而对于结构化源,LLM 则直接输出对应语言的可执行查询。
最终阶段涉及跨源证据选择,系统将各源执行引擎的输出整合为统一证据集 E。框架的输入包括用户问题 q 与执行器输出 {Exec(b,q^b)}b∈S,其形式可能各异,涵盖关系元组、RDF 三元组或文本段落。为过滤无关结果,系统利用语言模型在问题上下文中评估每项输出。模型通过提示识别最能回答问题的检索结果,从而在异构源中有效筛选出最相关的证据。此步骤确保最终输出兼具准确性与连贯性,通过返回与用户查询语义对齐的过滤结果子集,完成检索任务。
实验
实验在文档检索、SQL、SPARQL 和 Cypher 范式下,使用多种语言模型后端,将 OmniRetrieval 与单后端、路由及统一表示基线方法进行对比。主基准测试验证了启用多个候选源并通过跨源证据选择整合输出,能够持续优于僵化的单范式方法。针对候选规模与模型规模的后续分析证实,准确的初始源选择仍是关键瓶颈,而证据选择即使在初始未选中最优源的情况下,也能可靠地恢复语义正确的答案。最后,与统一表示方法的对比表明,保留原生查询结构对于捕获共享嵌入无法表示的复杂关系组合至关重要。
作者使用源选择、检索质量及基于 LLM 的判断指标,将 OmniRetrieval 与单后端方法、KB Routing 和统一表示方法等多种基线进行对比。结果表明,OmniRetrieval 在所有评估指标上均优于基线方法,在源选择与检索准确率方面取得显著提升,同时获得最高的判断分数。该框架的优势源于启用多个候选源并通过跨源证据选择整合结果,而非依赖单一后端或统一表示。OmniRetrieval 在源选择、检索准确率及基于 LLM 的判断指标上全面领先。相较于单后端方法与 KB Routing,该框架实现了最高的源选择准确率与检索质量。OmniRetrieval 的表现优于统一表示方法,印证了原生查询执行相较于共享表示方法的优势。
作者在不同骨干模型下将 OmniRetrieval 与多种基线方法进行对比,证明其相较于单后端与路由方法具有持续的性能提升。结果表明,OmniRetrieval 通过启用多源并借助跨源证据选择整合结果,实现了更高的准确率,且在 SQL 和 SPARQL 等结构化范式中提升尤为明显。进一步的分析指出,更广泛的源探索与证据选择是取得成效的关键驱动力。OmniRetrieval 在所有骨干模型与检索范式下均稳定优于单后端及路由基线。该框架通过启用多个候选源并结合跨源证据选择提升准确率,尤其使结构化检索任务受益。性能提升在结构化范式中最为显著,且随着源选择准确率的提高,提升幅度逐渐收窄。
作者评估了通过原生查询语言启用多个知识源,并借助跨源证据选择整合结果的框架。结果表明,该框架在所有检索范式下均优于单后端与路由基线,在“LLM-as-a-Judge”准确率方面取得稳定提升,尤其在从多样化源检索时更为显著。该框架在所有检索范式下的性能均高于单后端与路由基线。该方法在“LLM-as-a-Judge”准确率上表现稳定,特别是在多源检索场景下。尽管底层目录以关系型数据库为主,但各范式的源选择分布仍保持均衡。
作者在不同骨干模型下将 OmniRetrieval 与多种基线进行对比,表明 OmniRetrieval 持续优于单后端与 KB Routing 方法。结果显示,随着骨干模型规模增大,源选择准确率与检索质量随之提升,但与 Oracle 上限仍存在差距。证据选择在源选择失败时,对恢复正确答案起到关键作用。OmniRetrieval 在所有骨干模型下均稳定超越单后端与 KB Routing 基线。更大规模的骨干模型表现出性能提升,且随着模型规模扩大,与 Oracle 上限的差距逐渐缩小。即使初始未选中黄金标准源,证据选择仍能有效恢复正确答案。
作者分析了不同骨干模型对预测检索范式的分布情况,表明尽管底层数据集存在不平衡,但源选择在各范式间仍保持大体均衡。各模型的 Top-1 候选预测相对一致,而完整候选集展现出更高多样性,尤其在搜索范式上更为明显。所有模型的预测均紧密围绕均衡参考线分布,表明范式分配保持一致。尽管数据集存在不平衡,源选择预测在各检索范式间仍保持均衡。与 Top-1 预测相比,完整候选集展现出更高多样性,搜索范式尤为突出。所有骨干模型的预测均维持在均衡参考线附近的狭窄范围内。
实验在多种骨干模型与检索范式下,将 OmniRetrieval 与单后端、路由及统一表示基线进行对比,以验证其原生多源查询与跨源证据整合机制的有效性。结果一致表明,该框架在源选择、检索准确率及基于 LLM 的判断方面全面超越对比方法,在结构化查询任务中优势尤为突出。性能提升主要源于框架聚合多样化知识库的能力,使其具备稳健的证据选择机制,即使初始源预测不够完美,也能成功恢复正确答案。此外,该方法随着更大规模骨干模型的引入呈现良好的扩展性,并在底层数据集不平衡的情况下,仍能在各检索范式间维持均衡分布。