韩国科学技术院研发的"万能图书管理员"

这项由韩国科学技术院（KAIST）与DeepAuto.ai联合完成的研究，于2026年5月以预印本形式发布，编号为arXiv:2605.29250，有兴趣深入了解的读者可通过该编号查询完整论文。

想象一下，你是一位侦探，接到了一个复杂的调查任务。案件的线索分散在四个完全不同的地方：一座存放着数百万份文件的档案馆、一个满是表格数据的数据库、一张密密麻麻标注着人物关系的知识地图，以及一个记录了人与事件之间复杂连接的关系网络图。要找到答案，你必须同时进入这四个地方，用各自不同的语言和工具翻查线索，最后把所有发现整合成一份完整的报告。

这正是当今人工智能系统在处理真实世界问题时面临的困境。现实生活中的问题，答案从来不只藏在一个地方。一个关于某位演员的问题，可能需要查百科文章；一个关于企业财务的问题，可能需要检索结构化数据库；一个关于历史人物关系的问题，可能需要查询专门的知识图谱；而一个关于社交网络中某条连接的问题，则需要在图结构数据库里进行多跳跳跃式搜寻。

过去，人工智能系统只能擅长其中一种，就像一位只会查档案馆的侦探，遇到需要查关系网络的案子就束手无策。为了解决这个问题，韩国科学技术院的研究团队提出了一套名为OmniRetrieval的框架，目标是让一个系统充当全能侦探，能够根据问题的性质，主动选择去哪个"知识库"查询，用那个知识库自己的语言提问，再把各处收集到的线索汇总成一份有用的答案。

一、四种知识库，四种"语言"

要理解这项研究的意义，先得了解知识库这个概念到底有多复杂。

现实世界的信息存储在四种截然不同的结构里。第一种是非结构化文本库，就像一座图书馆，里面堆满了文章、论文和新闻报道，你用自然语言去搜索，系统会返回最相关的段落。第二种是关系型数据库，更像一张超大的Excel表格，每行每列都有严格定义，查询时需要用一种叫SQL的专门语言来写查询命令，例如"从销售记录表中找出2019年5月份奥莱集团的购买次数"。第三种是RDF知识图谱，好比一张画满了"主语-关系-宾语"三元组的地图，比如"爱因斯坦-出生于-德国"，查询时需要用SPARQL这种专门语言，就像用暗语和这张地图对话。第四种是属性图数据库，比RDF知识图谱更复杂，节点和边都可以附带属性，查询时用的是Cypher语言，擅长回答"从A出发，经过几跳能找到满足特定条件的B"这类需要在网络里穿梭的问题。

过去的AI系统，通常只精通其中一种。专门做文本检索的系统不懂SQL；专门写SQL的系统不理解知识图谱；擅长SPARQL的系统对属性图一无所知。这就像一个精通法语的翻译，遇到日文文件就彻底抓瞎。

更麻烦的是，有人曾尝试把所有这些知识库"打平"——把表格数据、图谱三元组、文本段落全都转换成同一种向量表示（可以理解为把所有信息都翻译成一种通用暗语），然后用一个统一的搜索系统来检索。这个思路听起来聪明，实际效果却不理想。研究团队指出，这种做法有两个致命缺陷：一是翻译本身会损失信息，就像把诗歌逐字翻译成白话文，味道全没了；二是SQL能做的"表格联合查询"、Cypher能做的"多跳路径追踪"，这些结构性操作在向量化之后根本无法复现，你只能做粗糙的相似度匹配，精确的结构化查询能力全部丢失。

还有一个更实际的问题：维基百科底下有700万段文本，而Wikidata知识图谱里有超过150亿条三元组，属性图里三跳路径的数量可以达到千亿级别，根本不可能把这些全都打平成一个向量数据库——光是存储成本就无法承受。

研究团队的核心主张因此是：正确的做法不是把所有知识库强行捏成同一副面孔，而是在它们上方搭建一个智能的调度层，让每个知识库都用自己的语言回答问题。

二、全能侦探的工作流程

OmniRetrieval的工作方式，可以用侦探办案来理解。整个流程分成三个环节，环环相扣。

第一个环节是"选择目击者"，也就是源选择。当一个问题进来的时候，系统首先要判断：这个问题应该去哪个知识库查？是去档案馆找文章，还是去数据库查表格，还是去知识图谱找关系？

这个判断本身并不简单。知识库的数量可以很庞大——在研究团队搭建的测试环境里，一共有309个不同的知识库，而且每种类型的知识库，其自我描述的格式都不一样：文本库用一段话描述自己的主题范围，数据库用建表语句描述自己的结构，知识图谱用本体（ontology，可以理解为一份说明这个图谱里存了哪些关系的目录）来描述自己，属性图则列出节点类型和边类型。

面对这种格式不统一的情况，研究团队选择了一个聪明的办法：直接把所有知识库的描述信息和问题一起丢给一个拥有超长上下文处理能力的大语言模型，让它像一个博览群书的侦探一样，读完所有档案后判断应该去哪里查。这个大语言模型不是只给出一个答案，而是给出一个排名靠前的候选列表（默认是3个），因为有些问题确实可能需要同时查多个来源，或者在判断不确定的时候，可以留着多个备选。

第二个环节是"用对方的语言提问"，也就是查询生成。确定了去哪些知识库查之后，系统需要为每个知识库单独生成一个查询语句，而且必须是那个知识库能直接执行的格式。对于关系型数据库，就得生成合法的SQL语句；对于知识图谱，就得生成合法的SPARQL语句；对于属性图，就得生成Cypher语句；对于文本库，则是把问题改写成更适合检索的形式。

这个环节同样由大语言模型完成，但系统会提供每个知识库的结构性背景信息作为参考——比如数据库的建表语句，或者图谱中实体对应的真实ID和候选属性，让模型生成的查询既语法正确又内容准确。

第三个环节是"汇总线索、做出判断"，也就是跨来源证据筛选。三个或多个知识库的查询结果会同时返回，但这些结果格式各异——有的是表格行数据，有的是三元组，有的是图路径，有的是文本段落。系统再次请出大语言模型，把所有这些结果一起呈现，让它判断哪个来源的哪条结果最能回答原始问题，最终输出一个统一的证据集。

这个设计的一个巧妙之处在于：查询阶段必须用结构化语言（SQL、SPARQL、Cypher），因为只有这样才能发挥每个知识库的结构化查询优势；但到了最终筛选阶段，所有结果都已经被执行过了，变成了可以直接阅读的具体内容，这时候再把它们转换成文字进行比较，并不会损失什么关键信息，反而让跨格式的比较成为可能。

三、测试场：13个数据集，309个知识库

研究团队为了验证这套框架的效果，搭建了一个覆盖面极广的测试环境，这在学术界实属罕见。

文本检索部分，他们选用了BEIR基准测试集里的7个数据集，涵盖医学（NFCorpus）、科学事实核查（SciFact）、金融问答（FiQA）、网页文本（MS MARCO）、维基百科事实验证（FEVER）、通用问答（Natural Questions）和多跳推理（HotpotQA）等不同领域，每个数据集对应一个文本知识库。

关系型数据库部分，他们使用了Spider（206个数据库）和BIRD（80个数据库），合计286个不同领域的数据库，全部以SQLite格式提供，可以直接执行SQL语句。

知识图谱部分，他们使用了SimpleQuestions（单跳事实查询）、QALD-10（人工精选问题）和LC-QuAD 2.0（大规模复合型问题），三个数据集都以Wikidata作为后端知识图谱，通过公开的SPARQL查询接口执行。

属性图部分，他们使用了Text2Cypher数据集，其中包含15个来自Neo4j平台的不同主题图数据库，涵盖电影推荐、企业结构、社交网络和金融调查等场景，通过Neo4j的公开接口执行Cypher查询。

每个数据集抽取300道问题进行评测，总计横跨309个独立知识库。这个规模足以说明问题：现实中的知识是真的分散在各处，而不是能够简单整合的。

四、谁在和OmniRetrieval竞争？

为了衡量OmniRetrieval的表现，研究团队设置了一系列对比方法，每种方法代表一种不同的处理策略。

最基础的对比组是四个"单一范式"方法：文档搜索、Text-to-SQL、Text-to-SPARQL和Text-to-Cypher。这四种方法各自只会用一种方式处理所有问题，就像四位各有专长但互不通气的侦探，每人只负责一类案件。这类方法的问题显而易见——当一个应该去数据库查的问题被扔给只会搜索文本的系统时，答案肯定差强人意。

稍微聪明一点的是"知识库路由"方法：它会读取所有知识库的描述，为每道问题选择一个最可能的知识库，然后只查那一个。这比单一范式方法灵活多了，但问题在于，一旦选错了就没有退路，不能回头。

作为不可超越的理论上限，研究团队还设置了"Oracle"方法：假设系统已经知道每道问题的正确答案在哪个知识库，只需要完成查询生成和执行两步。这是人为给定答案的"开卷考试"，现实中不可能实现，但可以告诉我们当前方法和理论极限之间的差距有多大。

另外，团队还在一个经过大幅缩减的数据子集上测试了"统一表示"方法，也就是把所有内容打平成向量后用统一检索器处理。之所以要缩减，正是因为前文提到的规模问题：Wikidata的150亿条三元组根本无法全部向量化，属性图的路径空间更是指数级爆炸，所以这种方法只能在人为压缩过的子集上进行，不具备实际部署可行性，测试结果也被标注为"不可直接比较"。

五、侦探的成绩单

评测结果从三个维度来衡量：来源选择准确率（系统有没有选对知识库）、检索准确率（检索到的内容对不对）以及由另一个大语言模型担任裁判的"软评分"（允许一些语义等价的替代答案获得部分分数）。所有分数在四种检索范式上取宏观平均值，确保每种类型的贡献相同。

结果清楚地显示了一个梯次结构。四个单一范式方法的来源选择准确率都在15%到25%之间，这很合理——毕竟一个系统只擅长一种类型，在四种类型平均的考卷上，运气好的话四分之一的题能答对，大部分题都对不上号。

知识库路由方法的来源选择准确率提升到了61.65%（五种大语言模型的平均值），这说明让系统自己选知识库确实有用，但一旦选错就没有补救机会。

OmniRetrieval在来源选择准确率上达到65.71%，在检索准确率上达到44.34%，在软评分上达到65.88%，全面超越知识库路由方法，同时与Oracle上限（三项指标分别为100%、61.85%和74.55%）之间仍有明显差距，说明还有提升空间。

在不同的大语言模型骨干上，Gemini-3.1 Pro的表现最为突出，来源选择准确率达到73.30%，检索准确率52.69%，软评分71.10%。GPT-5.4紧随其后，而两个开源模型（Qwen-3.5 27B和Gemma-4 31B）的表现略逊，但仍然稳定超过知识库路由基线。

对于那个在缩减数据集上测试的"统一表示"方法，结果也很说明问题：它的来源选择准确率31.00%、检索准确率23.00%、软评分45.00%，虽然比单一范式方法好一些，但远低于知识库路由方法和OmniRetrieval。研究团队指出，这个差距揭示了一个根本性的限制：把所有信息打平成向量后，SQL的联合查询、Cypher的路径追踪等结构化操作都不复存在，只剩粗糙的相似度匹配，自然无法替代真正的原生查询。

六、细节里藏着智慧：三组深入分析

研究团队在主要实验之外，还做了三组深入分析，每组都揭示了框架设计背后的一些有趣规律。

第一组分析考察了候选来源数量（参数k）的影响。当k从1增加到3、5、10时，OmniRetrieval的来源选择准确率单调提升，但提升幅度在k较大时放缓，而且候选数量越多，候选质量反而在下降——k=3时系统能正确包含真实答案来源的概率是67.5%，k=10时这个概率下降到62.8%。与此同时，计算成本随候选数量线性增长。这个分析说明，当前框架最重要的改进空间不是扩大候选池，而是提升初始来源选择的精准度。

第二组分析考察了模型规模的影响，使用Qwen-3.5模型从2B参数一路扩展到27B参数。一个有趣的发现是：在小模型（2B）上，Top 1候选和Top 3候选的效果几乎没有差别，因为2B的模型在来源选择时总是陷入同一种范式，多给几个候选也是重复的。但随着模型参数增大，Top 3候选的优势开始显现，因为更大的模型在来源选择时能够真正探索不同的范式和不同的知识库，产生多样化的候选。到了27B，Top 3明显优于Top 1。这个发现支持了OmniRetrieval的核心设计哲学：先广泛探索，再精准选择，但这个策略需要足够强大的模型才能发挥效果。

第三组分析考察了跨范式覆盖能力，用一个矩阵图展示了不同检索方法在不同类型问题上的软评分。结果显示，文档搜索方法有最宽泛的跨范式覆盖能力——当面对本该用SPARQL查询的知识图谱问题时，文档搜索的软评分竟然达到51.2%，远高于Text-to-SQL的18.7%和Text-to-Cypher的29.6%。原因也不难理解：维基百科文本库里包含大量来自Wikidata的事实信息，两者在内容上高度重叠，用文本检索Wikipedia往往能找到原本该从Wikidata查询的事实。这个发现提示，在某些场景下，不同知识库之间存在内容的部分重叠，跨来源证据筛选步骤正是利用了这种重叠来提供额外的安全网。

七、为什么它比"统一翻译"方案更聪明？

这里值得多花一点篇幅来理解OmniRetrieval相对于"打平向量"方案的本质优势，因为这是整个研究最核心的论点。

"打平向量"的方案，本质上是把四种语言都翻译成一种通用暗语（高维向量），然后用暗语的相似度来匹配。但问题是，SQL查询的精髓在于它能把多张表按照某个字段联合起来，找出满足复合条件的记录集合；Cypher查询的精髓在于它能沿着图的边做多跳遍历，找到距离某个节点N步以内满足条件的其他节点。这些操作，在向量化之后根本无从表达——你只能问"哪些向量和查询向量比较像"，但你问不了"哪些节点通过三步跳跃能到达满足条件X的节点，而且沿途每一步都满足条件Y"。

OmniRetrieval的做法则保留了这些结构化操作的能力：它生成真正的SQL语句，交给真正的数据库引擎去执行，引擎会忠实地做JOIN操作；它生成真正的Cypher语句，交给真正的图数据库引擎去执行，引擎会忠实地做路径遍历。这就好比，与其让一个语言学家用自己的话描述一份法律合同的内容，不如直接把合同交给法官，让法官按照法律条文逐条解读——两者效果天差地别。

说到底，OmniRetrieval做的事情，是给人工智能系统安装了一双能看懂"图书馆索引系统"的眼睛，让它不再只会在一种知识库里打转，而是能够根据问题的性质，自主选择最合适的信息来源，用那个来源听得懂的语言提问，再把各处的线索拼成完整的答案。这项研究最有意思的地方，不仅仅在于它的技术方案，更在于它提出了一个简单却深刻的问题：我们是否在用错误的方式思考"统一"这件事？把所有东西强行变成同一副面孔，往往不是真正的统一，而是以牺牲多样性的代价换来表面上的整齐。真正的统一，或许更像是一位好的翻译官——不是把所有语言都变成英语，而是在不同语言之间架起理解的桥梁，让每种语言都能保留自己最精华的表达方式。

当然，这项研究也坦诚地指出了自身的局限：跨来源证据筛选步骤虽然已经相当可靠，但如果通过带标注数据进行监督微调，或者用下游答案质量作为奖励信号进行强化学习，可能还能进一步提升；此外，当前框架在来源选择、查询生成、证据筛选三个步骤中共用一个大语言模型，如果针对每个步骤单独训练专门化的模型，或许能带来额外的性能增益。这些，都是值得继续探索的方向。

有兴趣深入了解技术细节的读者，可以通过arXiv编号2605.29250找到完整论文，代码也已经在GitHub上公开发布。

Q&A

Q1：OmniRetrieval和普通的搜索引擎有什么区别？

A：普通搜索引擎只在文本库里按相似度找文章，而OmniRetrieval能同时应对四种完全不同类型的知识库——文本库、关系型数据库、知识图谱和属性图数据库。它会根据问题的性质自动选择去哪里查，用那个知识库自己的查询语言提问，再把多个来源的结果汇总起来。本质上，普通搜索引擎只会"找相似的话"，而OmniRetrieval还能"执行精确的结构化查询"，比如做数据库表格的联合查询或者在图数据库里追踪多跳路径。

Q2：把所有知识库都转换成向量后统一检索为什么不行？

A：向量化的方式会抹掉每种知识库最宝贵的结构化操作能力。SQL能把多张表联合查询找到满足复合条件的记录，Cypher能沿图的边做多跳路径遍历，这些操作在向量化后根本无法表达，只剩粗糙的相似度匹配。还有一个更现实的问题：Wikidata有150亿条三元组，属性图里三跳路径数量达到千亿级别，根本没办法全部向量化存储，规模上就不可行。

Q3：OmniRetrieval在来源选择上有没有失败的时候，失败了怎么办？

A：有，而且研究团队坦诚地展示了失败率。系统默认返回3个候选来源而非1个，正是为了应对选错的情况。即使第一个候选选错了，只要真实答案的来源在3个候选里，后续的跨来源证据筛选步骤就能识别出哪个来源的结果更符合问题意图，从而做出正确的最终选择。研究数据显示，当候选列表里包含正确来源时，证据筛选步骤选对的概率比随机猜测高出约30个百分点，说明这个"先广泛探索、再精准筛选"的策略确实有效。