数据库

嘉宾介绍：

苗东菁，哈尔滨工业大学教授、博士生导师，CCF 数据库专委会委员、理论计算机科学专委会委员，黑龙江省大数据科学与工程重点实验室副主任。从事数据库系统、大数据计算与数据质量管理的基础理论研究。发表计算机领域国际顶级刊期、会议学术论文 40 余篇，包括 The VLDB Journal, IEEE Transactions on Knowledge and Data Engineering, Theoretical Computer Science, SIGMOD, VLDB, ICDE, COCOON, COCOA, AAIM, ICFEM, IPCCC 等。数据一致性管理基础理论和关键技术方面研究成果获得 2018 年中国计算学会优秀博士论文奖，2019 年 ACM SIGMOD CHINA RISING STAR AWARD 奖。主持 NSFC 面上项目《面向跨模型分析型负载的数据存储方法》、CCF-华为胡杨林基金数据库专项项目《压缩态数据向量化执行引擎》，作为骨干成员参研了包括国家基础研发 973 项目、国家重点研发计划、国家自然科学基金重大、重点项目在内的多个国家级项目。担任 COCOON、DASFAA、COCOA 等多个知名国际会议程序委员会主席、委员等，国际顶级算法期刊 Algorithmica Leading Guest Editor。

以下内容为哈尔滨工业大学教授苗东菁在中国计算机学会（CCF）、CCF CTO CLUB 联合数新智能共同主办的“多模态数据融合技术创新与落地实战”活动中演讲全文

感谢主办方中国计算机学会的邀请，以下分享我们团队在相关领域的研究思考与成果。作为学界研究者，部分观点可能存在争议，期待与各位探讨交流。

我们团队早期研究聚焦数据管理领域基础问题，涵盖计算复杂性与严格算法设计等方向。我们曾承担数据质量管理相关国家课题，彼时主要基于逻辑规则及推理开展研究，未采用当前深度学习技术，核心探索如何构建质量管理系统——包括选择一阶逻辑或其子类等逻辑体系（逻辑系统的选择直接决定系统表达能力及对劣质问题的覆盖范围）。但研究发现，表达能力增强会导致计算复杂度上升；尽管我们通过证明问题复杂性、研究具有理论误差保证的算法为系统构建提供指导，但这类基于逻辑的严格方法存在高效实现条件苛刻、落地灵活性不足等问题，在复杂现实场景中应用受限。

当前，基于深度学习的 AI 模型作为启发式近似计算工具，展现出更强的落地可行性，尽管其效果误差的理论保障尚未明确，但近期借助数论与群论工具解释神经网络及大模型动力学的研究，已显现理论突破的可能。因此，我们开始关注此类方法的应用及与数据管理领域的关联。

今年被行业称为所谓 “智能体的一年”，智能体技术与应用的发展正与数据管理领域深度交织，这也是本次分享的核心议题。

今年 1 月，我看到一则产业新闻，称京东已投入运行的智能体数量已超过七千个，各类公司也都有类似应用。包括一些不为大众所熟知的中小企业，而今年常被提及的观点是，单人公司会越来越多，即一个人借助智能体开展工作。

这些智能体在工作过程中不断产生数据并进行数据检索，在多模态场景下，如何以更低成本、更快速的方式构建 “甩手掌柜式” 数据底座，这对我们而言是一个机会，至少可作为一个研究方向。这一趋势也让早年的多模数据库概念重新焕发生机，只不过其实现方式已有所不同，例如对象数据库、多引擎聚合、联邦数据库中间件等。

但是到了今天，在 AI 领域发展的推动下，我们的兴趣可能更趋向于去做原生的方式。

这个就是很经典的架构。智能体可能还要区分一下，这个不是我们强化学习里面的智能体，更多的是基于大模型的智能体。对于基于大模型的智能体，我们的期待并不仅限于让它像以往那样提供简单的问答服务，而是希望它能够具备独立工作的能力，协助我们解决更多实际问题。

这里面有几个重要的能力，比如方案的规划运筹的能力。在规划能力的构建中，我们可能需要借助智能体过往的 “经历”，这就涉及到记忆模块的设计。它需要像人类一样，对过去的 “事件” 进行选择性记忆，并且能在这些记忆的基础上不断进行反思，反思完之后的 thoughts 也都能积累起来，然后在我们后续工作中的去检索使用。最后就是去实地调用工去解决实际的问题，比如说读邮件、写邮件、发送回复邮件这样一条龙的方式。

在这里，我们比较兴奋的一点就是看到记忆模块，这实际上就是我们数据库所要发挥作用的地方，包括底下的数据基建是要发挥的地方。

早期的像 Chat GPT，里面有记忆的功能，这是我跟我的学生在讨论一个事情。他们正好做毕业设计，在讨论一个标题，我就让 Chat GPT 记下来，于是它作为往智能体化这个服务形态去转换的大模型，它就会把你对话的内容选择记下来。

之后我就好奇继续打开它的记忆模块，会发现实际上用户过往的这些经历，它都会选择性的记下来，这就是在它之后为你服务的时候，可以提供个性化服务的依据，这是我们的所说记忆模块。

Open AI 的底层同样需要维护这样的数据基础设施，用于存储海量用户数据。我们发现其存储的数据具有两个特点：一是经过选择性筛选，二是存储内容中没有主语，仅保留了谓词部分，也就是说，在主谓宾的结构中，只包含谓语和宾语。尽管我们并不清楚其内部具体的运作机制，但基于这些观察，我们推测其数据可能是以知识图谱的形式构建的。

我们的基础大模型也都往智能体化去提供服务，像 Open  AI 今年就直接发布了两项功能，一个是 Deep Research 我们写论文都用，另外一个是前两天的 Agent。在这种情况下，我们为智能体构建的简单行为模型是这样的：每个智能体都有自己明确的目标，目标设定后，它会先观测当前的状态，然后决定下一步的动作：可能是生成执行计划，可能是调用相关工具，也可能是进行逻辑推理。完成这一步动作后，它会继续观察新的状态，并依次执行下一个动作，形成这样一个循环往复的序列。

当然有些论文就是通过一些测试，发现对于这样一个“观测-行动-记忆-再观察”的序列来说，如果你把它过往的经历存下来，之后将再继续回答问题，去检索过往的经验都会提高精度。

智能体阶段性工作完成了之后，我会把相应的事情或者观测或者事件写入存储系统的模块。写完了之后，我们会把这些过往的经历再进行一些反思，这些就会存下来，当我们再进行行为的时候，就会利用 read 模块去检测过往的相关事实，再改进我们的智能体的服务。

这一块目前落地的形式，实际上就是一种 RAG 的方式，比如 GraphRAG，比如说海马回等。但是本质上还是做数据的管理和检索。

这一块不光是文本知识库，可能还有图、多媒体，只不过现在落地的时候还比较有难度，也是我们未来技术发展的方向。这是我们组针对这样一个场景做我们的技术。

我们在调研中看到一些资料，举一个非常有意思的真实的例子，尽管它从某种意义上来讲，还不算是特别理想的智能体，更多的还是智能工作流。这里面就涉及到仓储的订单履约，订单的处理，还有库存调用，物流执行等管理，这是一个实际实现的智能体。

在这个智能体的实现过程中，有这么几个步骤：

第一个步骤订单解析：在订单的自然语言里面把备注字段拿出来，大模型进行解析之后，又去更新我们表里面相应的制作。这里面可能就需要我们用模型来解析，去做关系数据的 CRUD；

第二步需要在文档里面做相应的文本检索，在文档和关系数据数据里面进行融合的操作、查询等等，找到相应的产品文档，将产品文档和订单关联起来，这就是简单的融合的分析；

第三步调用工具预测未来可能的库存分配；

最后就是当我们完成这件事的时候，要更新知识，更新记忆。

我们从学术研究的去看了一些相关的实践，它是怎么实现的？

是在一个公司里面落地，他们是这样做的，就是人工预先写一个 SQL 囊括进 agent 的行为。

但是实际上，我们觉得未来的发展方向是 agent 从表格里读取数据后，智能体去写这个 SQL，通过了解环境以后去写 SQL。

所以说，我们还把它当做一个智能工作流，而没有把它视为真正的智能体。如果未来真正的智能体在工作的时候，我们认为应该是这样的实现方式。在这种方式下，我们认为随着智能体服务的实例越来越多，有 7 千个、8 千个、1 万个、100 万个，数据更新的压力以及多模型的更新的压力，跟现在会是大不相同的，因为现在很多场景人工去生成数据的速度肯定不如智能体的速度。同时，人工去写好查询的模版可预测的可构建的，这也是我们一直探讨的（实时）数仓的架构所依赖的一个前提。但是如果是智能体来自由、灵活地去写这些多模型融合查询的话，它可能对于现在的架构就提出了很大的挑战。这也是我们希望能做原生 HTAP 多模数据库的原因之一。

在这里面，其实还是有这样的 RAG 的重要的场景，在检索的时候要用业务知识来进行增强，对于检索的增强。在这里面，还有在我们看到的是文档还有订单的表达的数据，还有在智能体的经验里检索的时候，有 RAG 的数据，同时在智能体工作的时候，还会有对这些数据反向的更新。

比如当前智能驾驶场景中，系统能够实时查询空间位置并动态更新，再加上智能体的记忆功能，这些都是我们正在考虑的多模态融合应用场景。由于我们身处高校学术领域，相比从应用层面整合现有技术，更希望从底层原生的角度，深入探索多模数据库的构建逻辑与实现路径。

因此，在这些场景中，我们需要支持多模型、多模态的数据，其中向量数据涵盖图像、文本等内容，且主要以向量形式存在。这对我们提出的核心要求，除了实现数据的融合汇聚，实时交互也是极为关键的环节。因为大量智能体在线进行反向更新时，系统性能至关重要，而这背后的核心原因，正是这些场景对结果的 “新鲜度”有着极高的要求。

我们再从系统的角度考古一下多模数据库的评估系统，如今，我们能看到数据库朝着平台化发展，追求大而全的功能覆盖；从我们单独看数据库管理系统的角度来说，一是通过多种引擎结合的方式，这在过去，已有国家基金项目围绕此方向开展研究；二是在同一套数据库中，集成不同的搜索引擎等组件来适配多模态数据需求。

到单引擎的方式，也有现在比如说在 AWS 上面挂的 ArangoDB、OrientDB 这些，它也是一种单引擎单数据库，通过拓展的方式把所有的其他的模式转化成 KV，像某些公司也做大的 KV 系统，在业务组织的时候构建相应（join）视图。

我们想追求最灵活、效率最高、最极致的形式就是这种原生的方式，我们现在希望总引擎一套架构去把数据融合，同时提供 ACID 和实时交互。

但是现在做多模，很多的行业的做法，是从上层统一产品，从行业的角度从普及客户的角度去兼容现有的系统。现有的这种多引擎联合的方式，可能不同的模态产生不同的数据库。也有单引擎存储的方式，比如全都转换成关系、转化成文档、转换成知识，都有各自的优缺点，这个显而易见。

还有就是我们刚才说的 KV 的方式。我们也简单列了一下优缺点，从我们研究的角度实际希望的是追求甩手掌柜式的状态。

我们在探索的过程中，我们自己还是在做双模态的图-关系数据库存储引擎。我们现在大概在做一个原型，9 月份可能还会融合文档，基于 LSM-Tree 的底层架构去融合这些工作。

上面是我们去年被 VLDB 接收的论文，这也是我们针对 HGTAP 性能，去融合其他的模型走的第一步。我们在关系、表这一块有很多的 LSM-Tree 的架构，可以达到高吞吐。但是在图数据库方面还未达到这种性能，于是做了图上 HTAP 的这个工作。

尽管今年再搜索就有 11 篇相关的论文了，但我们依然觉得我们的 idea 是这其中最好的。大家都在做这样的一个性能，就是能够提供图的高动态的更新，同时给他最高新鲜度的查询，我们希望在原生单引擎下直接去工作。

我们做这样一个图的 CSR 的存储，加上 LSM-Tree 的融合。目前我们在论文里做了这样的试验，就是我们用了比较经典的 LDBC 工作负载做了 8 个常用的分析算法试验，包括 BFS（广度有限搜索），三角计数等等这些重要的操作，这也是 RAG 里面一些常用的查询。

我们的性能实际上就是三方面：

一方面是图事务吞吐量，更新的时候，图也可以动态更新，能支持成千上万 agent 实时更新。

二来是分析负载处理。在这种吞吐量的情况下，我们对于算法的分析性能能不能达到保持新鲜度的要求，得益于我们把 CSR 和 LSM-Tree 进行融合以后，我们的算法和分析的性能是高于开源的引擎。

最后是我们在整体的 HGTAP 上的表现，我们可以看到同时有大批量吞吐的时候，同时还有大规模分析查询的时候。我们表现的稳定性非常高，其他系统不乏假死状态。这就是我们在几个主要算法上进行 HGTAP 的测试。

目前，我们正致力于将这类引擎与基于关系引擎的架构进行融合，不过相关开发工作尚未完成。在现有架构的基础上，我们还尝试通过基于压缩数据的方式来提升 LSM-Tree 的性能，以此更好地支撑多引擎的融合工作，这正是我们当前投稿 VLDB 的重点内容，也是与华为数据库组合作预研的工作。

谢谢大家！