从向量存储到 Agentic 数据基础设施：Paimon × Milvus 如何构建 AI 原生多模态数据湖

演讲者：李钰（Yu Li）｜阿里云 EMR & Milvus 负责人，Apache Paimon PMC Member

摘要本文整理自李钰在 Apache Flink Forward Asia 2026 的演讲，讨论 AI 与 Agent 进入生产环境后，数据湖与向量数据库"双系统"架构暴露出的结构性问题，以及 Apache Paimon 与 Milvus 围绕同一份湖数据协同的技术路径。主要内容包括：

为什么 Agent 与多模态工作负载需要新的数据底座
Paimon × Milvus 的统一向量湖架构与三层就绪度
Serving Index、Open Index 与检索层的分阶段演进
自动驾驶数据闭环及企业产品化路径

过去几年，AI 应用的焦点不断变化：从模型能力，到 RAG，再到能够持续运行、调用工具并与环境交互的 Agent。但当 Agent 真正进入生产环境，一个此前被低估的问题开始浮出水面：我们的数据基础设施，是否真的为这种持续运行的 AI 系统做好了准备？

今天我想讨论的，不是某一个单点 feature，也不只是如何把一次向量检索做得更快，而是 AI 时代的数据基础设施应该如何重新分层。

用更直接的话来说：随着 Agent 和多模态应用进入生产，我们是否有可能把数据的存储与治理、在线检索与服务，重新收敛到同一份数据之上？

我的核心判断是：未来 AI 数据基础设施的竞争，不会只体现在检索性能上。更关键的是，谁能率先把存储、治理、发现与服务整合为一体。围绕这个目标，Apache Paimon 与 Milvus 的协同提供了一条值得关注的开源路径：由 Paimon 承载统一湖存储、版本控制和数据治理，由 Milvus 提供高性能、可扩展的向量检索与在线服务。

如果今天只带着一个问题往下读，我建议记住这个问题：既然我们已经有成熟的数据湖和专用向量数据库，为什么 AI 工程实践反而越来越复杂？

为什么需要 AI 原生多模态数据湖

"两份真相"，正在成为 AI 数据架构的结构性负担

今天，几乎每一个开始落地生产级 RAG、Agent 或多模态检索的团队，都会逐渐遇到一种相似的架构：一边是数据湖，保存原始数据、特征、训练集和批处理结果；另一边是向量数据库，保存 embedding 和索引，承担在线检索；两者之间，则是一组不断变长的 ETL、同步、重刷和 Schema 映射管线。

这套架构在早期并不显得荒谬。数据湖擅长存储和批处理，向量数据库擅长 ANN 检索，各自承担最擅长的工作。但随着数据规模、更新频率和治理要求不断上升，系统开始不得不维护"两份真相"：一份在湖中，一份在向量数据库中。

数据一改，索引要重刷；Schema 一变，字段映射要调整；线上服务与离线分析可能看到不同时间点的数据；大量冷数据很少被查询，服务集群却仍要常驻。此时，复杂性已经不是"ETL 写得不够好"，也不是再增加一个同步组件就能解决的问题，而是来自架构本身。

这正是我们希望改变的局面：数据不应该为了被不同引擎使用，就在"两份真相"之间被反复搬运。

从 RAG 到 Agent，变化的不只是检索频率

为什么这个问题现在变得格外突出？因为 AI 系统访问数据的方式已经发生了变化。过去两年，很多团队经历了一个典型的三阶段演进。

第一阶段是静态 RAG。 系统把文档切片，生成 embedding，建立索引，再完成一次检索。数据会变化，但变化相对缓慢，整个系统更像是在查询一个知识库。

第二阶段是 Tool Use。 模型开始连接数据库、API 和工作流，能够在一次会话里执行一串动作，但整体仍是一种会话级的增强能力。

第三阶段是 Production Agent。 Agent 持续运行、反复读写、长期持有上下文，线上服务和线下分析也开始交织。此时，数据不再是一批静态资产，而成为 Agent 持续消费、持续生产、持续修正的运行材料。

因此，问题已经不再只是"向量检索够不够快"，而是数据底座能不能支撑持续读写、反复检索、版本演进和在线离线协同。

与此同时，数据形态本身也在发生变化。真实 AI 应用处理的远不只是文本 embedding，还包括图片、视频、音频、日志、传感器信号和大量结构化属性。一条向量关联着数十、数百，甚至上千个 metadata 字段，已经不罕见。

传统向量数据库以向量检索为中心，标量通常用于过滤，大对象往往需要外置，数据治理能力也相对有限；传统数据湖擅长保存海量结构化和非结构化数据，却长期缺少原生向量类型和 ANN 查询语义。

真正缺少的不是更多系统，而是一个能把向量、标量、非结构化对象和索引都视为一等公民的数据底座。

双系统架构的四个问题

如果把当前双系统架构的代价归纳一下，可以看到四个结构性问题。

第一是重复存储。 Embedding 在湖里一份，在向量数据库里又保存一份。规模变大后，这不仅是存储成本问题，也会变成数据所有权、治理与血缘问题。

第二是索引冗余和重建。 索引往往在向量数据库里独立构建，游离于数据湖的版本、事务和血缘体系之外。源数据或 embedding 模型发生变化，索引就需要重刷，而这一过程很难进入统一的数据治理闭环。

第三是一致性窗口。 源数据更新到在线检索生效之间存在延迟，于是很难回答一个基础问题：线上查询看到的数据，与离线训练和分析看到的，究竟是不是同一份数据视图？

第四是弹性不足。 很多向量服务需要常驻在线集群。即使大量历史数据访问频率很低，团队依然要持续为计算和内存付费。

根因在于，现有架构并不是围绕"同一份数据同时支持服务与发现"设计的。

我们需要什么样的 AI 原生多模态数据湖

面向下一阶段，我们希望得到的不是一个更大的封闭系统，而是一套围绕同一份数据建立的能力组合。

它至少应当具备四个特征。

其一，统一存储。 向量、标量、Blob 和索引共存在受治理、可版本化的底座中。

其二，流批一体。 流式写入、批量回填和离线加工可以作用于同一份数据，不需要为在线服务与离线分析维护两套组织方式。

其三，一份数据、多种引擎。 同一份湖数据可以被在线检索引擎低延迟服务，也可以被 Spark、Flink 等计算引擎大规模扫描和再加工，而且不绑定于某个特定引擎。

其四，弹性计算。 常驻服务、按需计算和离线批处理可以按照访问频率和工作负载自由组合，让资源成本与业务需求匹配。

这并不是某一家厂商独有的叙事。Databricks 在从 Lakehouse 一侧向外延伸，Zilliz 在从向量数据库一侧向外延伸，Paimon × Milvus 则代表了一条"开源数据湖 + 开源检索引擎"的协同路径。

这些路线都看到了同一个趋势，但一个关键问题仍然值得追问：那份数据最终归谁？如果统一存储和治理由独立、开放的湖格式承载，上层检索与服务引擎就可以独立演进和替换，数据所有权也会更加清晰。

Paimon × Milvus：如何围绕同一份数据协同

为什么是 Paimon 与 Milvus

Paimon 与 Milvus 的角色边界相对清楚。

Paimon 是湖底座， 负责"存、管、治"。它正在把 Vector、Blob、Data Evolution 和 Global Index 等能力纳入湖内原生语义，让多模态数据在同一张表中得到持续写入、版本管理和统一治理。

Milvus 是检索与服务引擎， 负责"检、服、扩"。它在 ANN、混合检索、标量过滤、分布式扩展和生产级低延迟服务方面已有深厚积累。

两者协同的重点，不是简单把两个系统重新拼接，而是通过标准接口和共享数据契约，让它们围绕同一份湖数据工作。

在这套架构中，Flink Streaming、CDC、批量回填和离线计算构成统一写入层；Paimon Table 保存向量、标量、Blob 和索引，并提供版本、治理与 Snapshot；Milvus External Collection 则在服务层提供 ANN、Hybrid Search 与 Filter。

它要解决三个核心问题：消除湖与向量数据库之间的主数据搬运；让计算围绕同一份数据发生；通过快照和 Refresh 机制维持服务侧数据新鲜度。

一句话概括，就是 One Data First，先建立共享数据平面。

判断"一份数据"是否成立，要看三层就绪度

两个系统能否共用一份数据，不能只看"接口是否连通"。我们可以用三层就绪度来判断。

第一层是语义层： 双方是否对 Schema、类型和列语义达成一致。例如，Paimon 中的 VECTOR<FLOAT, n> 与 Milvus 中的 FLOAT_VECTOR 能否建立明确映射。

第二层是物理层： 数据是否使用开放格式，另一方能否原地读取，而不必复制主数据。这里需要特别澄清，物理层就绪不等于"两套存储引擎内部格式完全相同"，也不要求两边采用同一套寻址布局。真正的前提是开放格式与可原地访问。

第三层是检索层： 索引由谁构建和维护，ANN 参数与查询语义如何对齐，标量过滤如何与向量召回协同，以及命中结果如何关联回真实行数据。

整体来看，Paimon × Milvus 已经在语义层和物理层形成了较好的协同基础：双方能够对齐数据类型和列语义，Milvus 也可以围绕湖上开放数据提供服务。下一步需要继续完善的，是索引复用、查询语义和结果关联等检索层契约。下面分别来看 Paimon 与 Milvus 在这些层面的具体能力。

Paimon：把 AI 数据对象拉回湖内

Paimon 的变化，不只是"数据湖也能存向量"。更重要的是，它正在把 AI 数据对象从湖外约定变成湖内原生概念。

在语义层，原生 VECTOR<T, N> 类型通过类型系统显式表达维度和元素类型，不再依赖应用层自行约定。

在物理层，Paimon 为向量列提供专用的 Vortex 存储路径，并结合 Data Evolution，让向量列与标量列能够协同演进。图片、视频和音频等大对象，也可以通过 Blob 能力纳入同一张表。

在检索层，Global Index 开始成为表级能力，覆盖 BTree、Bitmap、Vector、Full-Text 和 Hybrid 等索引类型。标量过滤、向量检索与真实行数据也开始被放进同一个查询模型：先由标量索引裁剪候选 Row-ID，再在候选集合内执行 ANN，最后回读真实行数据。

这意味着，Paimon 正在从"保存 AI 数据"走向"用统一语义组织、索引和治理 AI 数据"。

Milvus：从"复制后服务"走向"围绕湖数据服务"

Milvus 的关键增量，则是 External Collection。

传统路径通常要求先把主数据导入向量数据库，再开始构建索引和提供服务。External Collection 希望改变这一点：在 Milvus 已公开支持的外部数据路径上，系统可以扫描外部文件元数据，生成 Manifest 和服务侧查询视图，再执行 ANN、Hybrid Search 与标量过滤；对支持 Snapshot 的外部表格式，还可以绑定特定数据快照。

其中 Manifest、Segment Mapping 或结果回表属于服务执行机制。物理层能够成立的真正原因，仍然是开放数据格式与原地访问能力，而不是两个系统内部存储引擎变得完全一致。

因此，这条路线的重要意义不是"把湖数据换一个地方再保存一次"，而是让生产级检索能力能够围绕同一份湖上开放数据展开。

检索层怎么演进：先共享数据，再走向开放索引

检索层是这套架构最需要分阶段推进的部分。

第一阶段， Milvus 通过 External Collection 围绕 Paimon 数据提供服务，但 Serving Index 仍由 Milvus 构建和管理。这条路径工程上更直接，也更容易首先满足高 QPS、低延迟的在线服务要求。它解决的是最迫切的问题：先消除主数据副本，让湖与服务层共享同一份数据。

第二阶段， 再逐步走向 Paimon Global Index 等开放索引，让索引能够一次构建、多次使用，支持多引擎共享以及在线、离线协同。目前，这条路线仍在持续演进中。

这两条路径都可以建立在同一份开放数据之上，核心差异在于索引由谁持有、是否能被多个引擎复用。

高性能 Serving Index 更适合高 QPS 在线工作负载；开放索引更强调数据与索引的开放复用、离在线协同和多引擎共享。进一步的检索互操作，还涉及统一 Row-ID、结果回表、标量与向量联合裁剪等机制。

总体来看，Milvus 与 Paimon 的开源集成已经具备共享数据平面的基础。其中，Serving Index 路线相对成熟，可以优先满足高 QPS、低延迟的在线服务需求；面向多引擎复用的开放索引，以及标量与向量联合优化等更深层的检索能力，仍将是下一阶段持续演进的重点。

自动驾驶：双系统问题被放大的典型场景

为了理解这套架构的实际价值，可以看一个自动驾驶数据闭环场景。

自动驾驶数据往往达到 PB 级规模，包含图像、视频、时间序列、传感器信号、向量和大量结构化属性。它同时需要两种能力：一方面要做实时相似场景召回和线上分析，另一方面要进行 Corner Case 挖掘、Embedding 去重、训练集构建和模型重算。

如果继续采用传统双系统架构，前面提到的四个问题都会被进一步放大：Embedding 的重复存储会显著推高整体成本；十亿乃至百亿级向量的索引重建会带来漫长的处理窗口；训练与在线检索依赖不同的数据视图；大量低频历史数据仍会长期占用在线服务资源。

统一向量湖则让整个链路围绕同一份数据组织起来。

Flink 持续把传感器数据、元数据、向量和 Blob 写入同一张 Paimon 多模态表；Milvus 围绕 Paimon Snapshot 提供外表查询和向量服务；Spark、Flink 的批处理任务仍在同一张表上执行挖掘、去重和训练集构建。

这样一来，Paimon 专注于持续写入、高效更新和统一治理，Milvus 专注于低延迟检索、高并发服务和弹性伸缩。离线发现与在线服务不再是"概念上同源、工程上分裂"的两套视图，而是真正围绕同一份事实数据展开。

统一数据层，是 Agentic Data Loop 的基础

当在线检索、离线挖掘和持续回写都锚定于同一份数据，Agentic Data Loop 才能真正闭环。

这条链路可以分成四步。

第一，感知与发现。 系统从湖中检索相似历史场景，识别分布偏移或 Corner Case。

第二，触发智能处理。 下游自动标注、去重或数据集编排 Agent 被激活，对数据进行修正和重组。

第三，回写与迭代。 新的 Embedding、修正后的元数据或训练结果，直接回写到同一张表。

第四，进入下一轮服务。 通过快照刷新或增量同步，Milvus 将最新数据纳入服务，结果再次进入后续发现与处理过程。

这里的统一数据层不再只是存储容器。它既是被查询的数据源，也是持续被加工的数据资产，是 Agent 与模型迭代共享的可持续演进数据基座。

讨论 Agent 基础设施时，我们经常把注意力放在模型和工具调用上，却忽略了底层数据是否一致、可追溯、可持续读写。如果数据副本割裂、更新滞后，上层再复杂的 Agent 编排也会被数据层拖住。

从开源架构走向企业产品化

从开源架构走进生产环境，企业关注的不只是技术能不能跑通，更关心它能否长期、稳定、可治理地运行。除了数据格式和检索能力，生产系统还需要统一的 Catalog、权限、血缘、运维、弹性与 SLA，最终形成完整的数据与服务体系。

在阿里云的产品化方案中，DLF 负责 One Data Catalog、湖存储管理、权限治理和血缘追踪；阿里云 Milvus 则提供托管的 Serving 层，并针对不同工作负载提供两类索引路径。

第一类是面向高 QPS、低延迟在线服务的 Serving Index， 由服务层负责索引构建、管理和弹性伸缩；第二类是面向多引擎共享与离在线协同的开放索引， 使多个引擎能够复用同一份湖上索引。目前，两条路径均已完成产品侧实现，并在云上智能驾驶场景中完成内部测试验证，即将在 7 月底随正式产品版本对外提供。

对企业而言，这套方案不是若干功能的简单组合，而是一套可以长期运行的能力交付体系：数据纳入统一治理，服务层提供托管运维、弹性伸缩与 SLA 保障，企业还可以根据工作负载，在性能优先和开放复用优先两类路径之间灵活选择。

一条更务实的落地路线

如果组织已经遇到"两份真相"、冷数据常驻成本或线上线下双视图问题，我建议分三步推进，不必一开始就改造整个系统。

第一步，先建立 One Data 底座。 用 Paimon 多模态表统一承载向量、标量和 Blob 等数据，并接入 DLF 的 Catalog 与治理能力，让数据从进入湖的第一天起就能够持续写入、统一管理和完整追踪。

第二步，再接入服务层。 引入 Milvus，并根据工作负载选择索引路径：高 QPS、低延迟的在线服务，可以优先采用由服务层持有索引的方式；强调多引擎共享和离在线协同的场景，则可以逐步采用开放索引。

第三步，形成完整的数据闭环。 逐步接入 Flink 流式更新、批量重算、数据质量任务和 Agent 工作流，让数据发现、处理、回写与服务连续运转；随着业务需求变化，再扩展另一条检索路径。

这个顺序背后的逻辑很简单：先统一数据所有权和治理方式，再接入 Serving，最后让在线服务与离线处理围绕同一份数据形成闭环。

结语：终局不是更大的封闭库

最后，我想用五点总结今天分享的核心内容。

第一， 数据湖与向量数据库组成的双系统架构，在 Agent 和多模态场景下正逐渐逼近其结构性上限。

第二， Paimon 正在通过 Vector 类型、Vortex、Global Index 和 Data Evolution 等能力，把向量和其他 AI 数据对象拉回湖内原生语义。

第三， Milvus 正在通过 External Collection，从"复制一份数据再服务"走向"围绕湖上数据直接服务"。

第四， 当前更扎实的路径是 One Data First：先让服务和计算共享同一份主数据，再逐步走向可复用的开放索引与更深层检索互操作。

第五， 这条开源路线仍处于演进阶段，但它带来了更清晰的数据所有权、更开放的架构边界，以及更少的单一引擎锁定。

未来 AI 数据基础设施的终局，不是让某一个向量数据库变得无所不包，也不是再造一个更大的封闭系统，而是让同一份开放湖数据能够被治理、被发现、被检索、被持续加工，并被多个引擎自由复用。

归根结底，决定架构边界的，不只是"谁的检索更快"，而是数据究竟躺在哪里、由谁拥有，以及它能否在不被单一引擎锁定的前提下持续演进。