韩国科学技术院万能图书管理员深度测评

由韩国科学技术院（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个不同的知识库，并且每种类型的知识库，其自我描述的格式各不相同：文本库用一段话描述自己的主题范围，数据库用建表语句描述自己的结构，知识图谱用本体（一种说明图谱中存储了哪些关系的目录）来描述自己，属性图则列出节点类型和边类型。

面对这种格式不统一的情况，研究团队选择了一个巧妙的办法：直接将所有知识库的描述信息和问题一起丢给一个具备超长上下文处理能力的大语言模型，让它像一位博览群书的侦探一样，读完所有档案后判断应该去哪里查。这个大语言模型并非只给出一个答案，而是提供一个排名靠前的候选列表（默认是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个百分点，这说明"先广泛探索、再精准筛选"的策略确实有效。