Multimodal Lakehouse，不只是“多模态 + 湖仓”：它到底在补哪条 AI 数据底座的断层？
这两年，很多团队一边在做多模态 RAG、视频理解、内容检索、Agent，一边又在补同一类基础设施的坑。
表面上看，问题像是模型不够强：图文检索不稳，视频理解链路太重，embedding 一升级就得大修，Agent 接知识库总有断层。可往下挖一层，很快就会发现，真正拧巴的往往不是模型，而是数据底座已经开始不够用了。原始文件在对象存储里，结构化元数据在仓库里，embedding 在向量库里，权限在 catalog 里，评测结果又在另一张表里。每一层单拿出来都能跑，拼在一起也能凑合跑一阵，但只要系统开始长期演进，裂缝就会越来越明显。Databricks 这几年一直在把表、文件、模型、函数往 Unity Catalog 里收；Snowflake 也在把非结构化文件、目录表、AI 函数和统一治理往一个体系里拉；Iceberg 社区则持续在推 REST Catalog，想把 catalog 和计算引擎之间那层长期不兼容的问题做成开放接口。术语不完全一样，但方向其实已经很清楚了：行业正在把“表”“文件”“AI 资产”从三摊事，重新往一个系统里并。
先把一句可能不那么讨喜的话说在前面：Multimodal Lakehouse 现在还不是一个边界已经定型的行业标准术语。 它不像 Iceberg、Delta、Feature Store 这种词，大家一听大概知道在说什么。到 2025 年之后，这个说法明显是被少数厂商推热的，尤其是 LanceDB，用得最主动、最明确。它把 “Multimodal Lakehouse” 定义成围绕搜索、探索分析、特征工程和训练的一体化 AI 数据平台。这个判断不是没道理，但它首先是厂商叙事，然后才是行业命题。直接把它当成共识，不严谨。
但另一面同样重要：这个词背后那组问题，不是营销凭空造出来的。 真正变硬的，是数据关系本身。今天一个企业级多模态系统，往往同时要处理原始文档、图片、音频、视频、OCR/ASR 结果、chunk、embedding、索引、标签、特征、评测结果和权限策略。它们不再是“主表之外的一些附件”，而是在训练、检索、推理、Agent 工作流里一起被消费。Databricks 明确把 Unity Catalog 说成 unified data and AI governance；Snowflake 也在把 structured、semi-structured、unstructured 和 AI apps 放到同一个数据架构框架里讨论。这说明一个事实：多模态 AI 最后不是把问题推向模型，而是把问题逼回数据基础设施。
所以我更愿意把 Multimodal Lakehouse 理解成一个架构目标，而不是一个具体产品类别：它要做的，不是“让湖仓多支持几种文件类型”，而是把原始媒体资产、结构化元数据、embedding、派生特征、annotations、chunk/segment、索引、版本、血缘、权限和评测结果，组织成一套能统一管理、统一治理、统一消费的数据系统。这个定义不是哪家文档原封不动写出来的，而是我把目前几条主流路线放在一起之后，更接近工程现实的抽象。
一、这个词为什么会冒出来？
因为传统那套“对象存储 + 数仓 + 向量库 + 应用代码缝一下”的方法，已经越来越难支撑多模态 AI 的长期运营了。
在传统数据平台里，默认主角是“表”。Lakehouse 解决的是开放存储之上的事务、schema 演化、批流处理和跨引擎访问；Warehouse 解决的是治理、SQL、协作和企业级消费；Vector DB 解决的是相似检索；对象存储解决的是原始文件的低成本持久化。大家分工明确，各司其职，这套组合在纯分析、纯报表、甚至一部分轻量 RAG 场景里都没什么问题。Iceberg 的自我定义就是 huge analytic tables 的高性能开放格式；REST Catalog 的目标也很明确，是让 catalog 操作通过标准接口暴露出来，减少引擎之间的绑定。
问题在于，多模态系统天然不是 tabular-first。你会同时有图片、视频、PDF、音频、网页快照、OCR 文本、ASR transcript、caption、切片、segment、embedding、rerank feature、评测日志和权限标签。这里面很多对象不是“为分析准备好的整洁表”，而是不断被派生、重算、重索引、重消费的一串链条。Snowflake 在 unstructured data 的文档和博客里反复强调，要先把文件元数据拉进 directory table，再去做处理、抽取和结构化；Databricks 则把 volumes 单独做成治理非表格数据的对象。单看这些功能像是产品扩展，放在一起看其实已经很说明问题了：表外世界不能再永远当成表外世界。
真正让这个方向成立的，不是“多模态很火”，而是下面几条结构性矛盾开始越来越难绕开。
第一条，是原始资产和结构化元数据长期分离。文件在对象存储里，表里只有路径；真正的业务语义、权限语义、版本语义挂在另一个系统里。早期没事，系统一复杂就很痛。因为你很快就会发现，你在检索的其实不是“一个文件”，而是“这个文件在某种解析规则、某种 chunking 规则、某个 embedding 模型下生成的一批派生对象”。这些对象如果不和主数据体系连上，后面基本没法查清楚。
第二条，是向量索引和主数据系统割裂。很多系统一开始默认“向量库里那份就是数据”。这个阶段最省事，但也最容易留下后患。因为索引本质上是派生物，不是事实主数据。Databricks 的 Delta Sync Index 实际上已经把这个问题摆上台面了：底下是表，上面是同步出来的向量索引；标准端点和存储优化端点的选择，还会直接影响 indexing 速度、查询延迟和成本。换句话说，厂商已经默认你需要把“主数据”和“serving index”分开理解。
第三条，是训练、检索、推理越来越像三条相互拉扯的数据路径。训练要吞吐、顺序读、分片、GPU feeding；检索要 ANN、filter、rerank、低延迟；线上推理更看 freshness、权限传播和可回退。ByteDance 那篇 2025 年的 Magnus 论文把这个问题说得很透：传统做法里，训练数据直接堆在分布式文件系统或对象存储上，文件多了以后元数据操作会很慢；同时，面向分析优化的布局，也不一定适合大规模 ML workload，尤其是在图片、视频和宽表一起出现的时候。这个判断很关键，它说明“统一底座”不等于“统一物理布局”。
第四条，是企业级治理终于追上来了。以前很多团队做多模态系统，默认只要效果和延迟能过关就行。现在不行了。企业一旦把文档、客服录音、合同、广告素材、图像资料、内部知识库放进来，权限、审计、lineage、PII 处理很快就变成第一优先级。Unity Catalog 明确把 volumes、models、functions 都纳入 securable objects；Snowflake 也在用 directory tables、unstructured pipeline 和 AI 函数，把原来“只能人工处理的非结构化数据”往治理范围内拉。这类能力表面上不如模型效果显眼，但它们才是系统能不能生产化的分水岭。
二、它和传统 Lakehouse，根本差异到底在哪？
很多文章喜欢把 Multimodal Lakehouse 写成“Lakehouse 的下一站”。这说法不算错，但如果只停在这儿，等于没说。
传统 Lakehouse 的核心问题，是：怎么在对象存储之上，给分析型表带来仓库级别的可靠性和工程化能力。它关心的是事务、schema 演化、时间旅行、批流统一、跨引擎访问和 SQL 体验。Iceberg、Delta、Hudi 这几条线，本质都在解这类问题。它们很重要，也依然会是未来 AI 数据底座的一部分。
Multimodal Lakehouse 的难点则完全不在“表怎么更像表”，而在于：表、文件、向量、索引、特征、权限、血缘，怎么重新长成一个系统。
这句话里最关键的是“重新长成”。因为现实里它们本来就不在一个地方。对象存储擅长放原始媒体，向量数据库擅长相似检索，仓库擅长治理和分析，Feature Store 擅长训练/服务一致性，Agent runtime 擅长长时程状态。谁都重要，但谁都不单独够。Milvus 现在已经在强调 multi-vector hybrid search，也就是同一个对象可以有多个向量字段，同时检索和重排；Databricks 的 Agent Framework 甚至直接支持 agent 去查自家的向量索引，或者通过 Unity Catalog 连接外部向量服务。这说明一件事：多模态系统正在把“数据对象”和“检索对象”之间的边界抹得越来越近。
所以根本差异不在于有没有图片、音频、视频，而在于系统是否开始承认下面这组关系是一等公民：
- raw asset 不是附件，而是事实源；
- chunk、frame、segment 不是临时中间件，而是检索和训练的主工作单元；
- embedding 不是“算出来就完了”，而是带版本的派生表示；
- index 不是数据本体，而是可替换、可重建、可冷热分层的 serving layer；
- metadata、policy、lineage 不是补丁，而是跨越表和文件的主骨架。
这几点一旦成立，Multimodal Lakehouse 和传统 Lakehouse 的差别就出来了：前者关注的是跨模态对象关系的统一治理与统一消费，后者关注的是表格式数据的可靠管理与分析体验。两者不是替代关系，更像是后一层正在把前一层往外扩。
三、为什么很多“对象存储 + 向量库 + 元数据库”最后会碎掉？
因为它们看起来什么都有，实际上最关键的“系统语义”往往没有。
先说清楚，这套组合不是错。相反，它是很多团队最务实的起步方案。问题不在组件选型，而在组件之间的关系是不是清楚。只要下面几件事说不明白，系统就很容易从“能跑”变成“越来越难运维”。
最典型的问题，是对象身份不稳定。一个 PDF 先做 OCR，再做 layout parse，再切 chunk，再算 embedding，再建索引。你最终服务的对象到底是谁？是 PDF 文件本身，还是某个页块，还是某个 chunk，还是某条向量记录？很多系统里这些 ID 没有稳定映射，只有代码里临时拼接出来的关联。这样一来，只要 chunking 规则变了，旧索引、旧评测、旧缓存就开始失去语义。
第二个问题，是索引生命周期被低估了。大家通常都盯着召回速度看，但真正拖垮系统的，经常不是 query latency，而是 rebuild 成本、增量刷新、冷热数据、低频数据和模型升级。Databricks 文档里，向量索引的 endpoint 类型、同步方式、预算策略、性能调优单独就是几套文档；这本身就说明，索引不是一个“建完就好”的简单部件。VLDB 2025 那篇 “Cracking Vector Search Indexes” 甚至直接指出：如果把 data lake 全部 embedding 化，理论上会需要为大量数据集、模态、workload 和 embedding 模型维护海量索引，这在成本和效率上都不现实。它给出的方向是 workload-adaptive index，而不是一上来先全量建好。这个判断非常重要，因为它意味着未来多模态底座的核心能力，不是“支持向量检索”，而是“管理索引的生命周期”。
第三个问题，是权限和 lineage 无法穿透派生对象。源文件权限改了，embedding 跟不跟着失效？某次回归表现突然掉了，能不能追到是哪一版 parser、哪一版 chunker、哪一版 index build 参数变了？Databricks 之所以把非表格数据纳入 volumes，让 models 和 functions 也进 catalog，本质是在回答同一个问题：治理不能只停在表上。Snowflake 把目录表和 AI 文档处理接进统一 SQL 体系，也是在做类似的事。你可以不喜欢某家的产品实现，但这个方向本身没什么争议。
说到底，“对象存储 + 向量库 + 元数据库”之所以会碎，不是因为它们能力弱，而是因为它们天然分工化。分工本身没问题，问题是缺少一个能把对象关系、版本语义、权限和 lineage 串起来的上层骨架。没有这层骨架，系统看起来很全，实际上只是把问题拆散了。
四、一个真正可落地的 Multimodal Lakehouse，应该长什么样？
我不相信“一个超级数据库吃掉一切”这种说法。至少从今天的工程现实看，更可信的形态是：统一治理，分层执行。
也就是说，你需要一套统一的对象模型、统一的 catalog、统一的权限和 lineage 语义；但在执行层，训练、检索、分析、Agent 状态，很可能仍然会落在不同引擎上。Iceberg REST Catalog 的价值就在这里：它不是替你完成所有计算，而是把 catalog 这层开放出来，让不同引擎能围绕同一套元数据工作。Snowflake 在开放表格式上强调 AI-ready lakehouse，Databricks 在 Unity Catalog 上强调 unified governance，本质上都是在往这个方向推。
我更认可的最小可行架构，大概是下面这个样子。它不是某家产品图，而是把目前更靠谱的工程做法抽象成一张图。
这张图里有几个点特别重要。
首先，原始资产必须是事实源之一，而不是附件。Databricks 的 volumes 和 Snowflake 的 stages/directory tables，虽然实现不同，但都在把“文件对象”从系统外围往内收。一个成熟的多模态底座，绝不能把原始媒体当成一堆随手丢在对象存储里的 blob。
其次，开放表层应该承接关系和版本，而不是只承接分析结果。这里存的不只是元数据表，还应该包括 chunk/segment、embedding 元信息、解析版本、评测结果、标签、派生特征这些“关系对象”。表层未必保存所有大对象本体，但它必须成为这些对象关系的主骨架。Magnus 论文之所以值得看，就是因为它不是把训练数据简单扔回文件系统，而是试图把数据管理、元数据、索引、版本和训练 workload 放到一个统一框架里考虑。
再次，向量索引层最好显式作为派生层存在。不要把它当 source of truth，而要把它当服务层。因为一旦 embedding 模型升级、chunking 策略调整、召回逻辑切换，索引迟早要重建。把它和主数据关系做清楚，比一开始追求“最强检索性能”更重要。Databricks 的 Delta Sync、Milvus 的 multi-vector/hybrid search、关于 data lakes 上索引选择的研究，背后都在支持这个判断。
最后，Catalog 才是这套架构真正的中轴。没有统一命名空间、统一 policy、统一 lineage、统一访问控制，这些层只是摆在一起，不叫系统。Unity Catalog、Iceberg REST Catalog、Snowflake 的目录表与统一数据架构，做法不同，但都在试图把这件事做实。
五、训练、检索、推理、Agent，为什么不能粗暴共用一套布局？
因为它们要的东西压根不一样。
训练要的是吞吐，是顺序读，是分片，是 GPU feeding，是成批地把宽表、图像、视频、标签和特征喂进去。Magnus 论文明确提到，大规模 ML workload 在对象存储和传统文件组织方式下会碰到元数据操作和数据访问效率问题；同时，这类 workload 往往需要数据版本、分支、索引与训练流程更紧的耦合。
检索要的是低延迟，是 filter，是 hybrid，是 rerank，是点查能力。Milvus 这几年明显在往 multi-vector 和 hybrid search 走，本质上就是承认“单一向量字段 + ANN”已经不足以支撑复杂多模态检索。Databricks 也单独把 retrieval quality、load test、performance guide、cost management 拆出来写，说明这已经是一个完整的工程子系统，而不是模型外面的一个小插件。
推理则更在乎 freshness、权限传播和故障回退。你不是只需要“搜到”，而是需要“刚更新的内容多久能搜到”“权限变更多久能生效”“旧版本能不能回滚”。这也是为什么 Databricks 的索引同步模式和预算策略会直接成为文档重点；因为线上问题最后很少死在“能不能算向量”上，更多死在“有没有把更新和成本一起算明白”。
Agent 更进一步，它不仅要查数据，还会引入工具调用、长期状态、trace、evaluation、monitoring。Databricks 现在已经把 agent 直接接到自家向量索引或者外部向量服务上，同时又强调 logging、tracing、evaluation、monitoring。这其实在提醒我们一件很关键的事：Multimodal Lakehouse 可以成为 Agent 的内容底座，但它不等于 Agent 的全部运行时。 Agent 的 durable state、workflow orchestration，大概率还是要靠别的系统来承接。
所以更现实的结论不是“做一个大一统平台”，而是：让训练、检索、推理、Agent 围绕同一套数据对象和治理语义协作，但不要强迫它们共用同一种物理布局。
六、开放格式、开放表、开放治理，为什么会越来越重要？
因为多模态系统一旦进入企业，最怕的不是功能不够，而是迁不动、换不掉、解释不清。
Iceberg REST Catalog 的价值，不只是“多一个 API”，而是它把 catalog 这件事从具体引擎里抽出来了。你可以把它理解成一条很关键的基础设施信号：未来真正有长期价值的，不是某个单体平台独占所有对象，而是不同执行层围绕一套开放元数据和治理接口协作。Snowflake 把 open table formats 和 AI-ready lakehouse 放在一起讲，也是在顺着这个逻辑走。
这件事为什么重要？因为多模态系统的变化比传统分析系统快得多。今天你用一种 embedding，明天可能就换了；今天以文档为主，明天可能加视频；今天只做 RAG，明天要做 Agent 和推荐。底座如果从一开始就把表格式、索引格式、catalog、policy 都和某个单体引擎死绑，后面非常容易被自己的历史决策反噬。开放格式不保证你一开始最快，但它大幅提高了长期可演进性。这个收益在 demo 阶段不明显，在三年期运营里会越来越明显。
当然，开放也不等于“一个开放格式解决所有问题”。这点要说透。Iceberg 很适合 analytic tables；向量 serving、低延迟随机访问、GPU 直读、媒体流式处理，未必都应该塞进同一层。NVIDIA 的 GPUDirect Storage 本质上就在说明另一件事：当训练和推理规模上来以后，数据路径本身都会成为性能瓶颈，存储到 GPU 的路径要不要绕 CPU，已经是架构问题，不只是优化细节。
所以更准确的说法应该是：开放格式和开放治理会成为长期主流，但执行层仍然会分化。 真正成熟的多模态底座，不会是“一个格式吃掉一切”，而是“开放元数据 + 分层执行 + 明确派生关系”。
七、落地时最容易踩的几个坑
我见过很多所谓“多模态统一架构”，做出来其实只是功能堆叠。判断它是不是伪统一，基本看这几个地方就够了。
第一个坑，是只统一存储，不统一对象关系。文件都进了对象存储，路径也统一了，看起来很整齐，但 chunk、embedding、index、eval 之间没有稳定关系，这不叫统一，只叫搬家。
第二个坑，是只统一检索，不统一治理。向量检索很快，hybrid 也有，rerank 也上了，可权限、PII、lineage、回滚语义全是补丁。这样的系统 demo 会很好看，企业会很难受。
第三个坑，是把索引当主数据。一开始最省事，后面最难救。因为索引重建、冷数据、模型升级、历史回放，都会让你越来越依赖一份本来就不应该承担全部语义的派生物。
第四个坑，是默认训练、检索、推理能共用一套最优布局。这在论文 demo 阶段偶尔成立，在生产里通常会出问题。因为这三类 workload 的目标函数根本不是一个东西。
第五个坑，是把可观测性和评测当成收尾项。Databricks 现在把 retrieval quality、cost management、load test、monitoring 都单独做成文档和产品能力，这不是文档写得细，而是现实逼出来的：多模态系统一旦规模化，不观测就没法运营。
八、企业和创业团队怎么落地：先搭对最小可行底座
不是每个团队都需要一上来就搞一个“大一统 AI 数据平台”。多数团队真正需要的，是先把最小可行架构搭对。
我更建议的起步方式是这样的。
先把原始多模态资产统一收口。文档、图片、音频、视频、网页快照，先进同一套受控对象存储，不要到处散。Databricks 的 volumes 和 Snowflake 的 unstructured stage，虽然不是唯一做法，但至少在说明同一件事：原始文件必须进入可治理域。
然后把关系对象表化。不是所有大对象都要塞表里，但至少 metadata、chunk/segment、embedding 元信息、解析版本、标签、评测结果要入表。这里用开放表格式是比较稳妥的，因为你后面一定会面对跨引擎、跨流程、跨团队协作的问题。
接着把索引显式当成派生层。无论用 Databricks Vector Search、Milvus、Weaviate 还是别的服务，都尽量让索引从受治理的数据层派生出来，而不是直接把索引层当唯一真相。
再往后，尽早把版本、权限、lineage 前置。至少要能说清楚 asset_version、parser_version、chunker_version、embedder_version、index_version。别等线上开始回归掉点了，再想补这一层。
最后，再去做训练与在线消费的分层优化。这一步才轮到 GPU feeding、冷热分层、索引生命周期、low-latency serving、Agent 接入。很多团队的问题不是起步太慢，而是起步就先把 serving 做得很花，结果元数据和治理骨架一直没立起来。
如果把它压成一句更直白的话，就是：
先把“对象之间的关系”做对，再去追“每一层都做到最强”。
这个顺序听上去不性感，但几乎总是比“先把功能堆齐”更适合长期运营。
九、我会怎么判断一套架构是不是“真 Multimodal Lakehouse”
最后给一套很实用的判断框架。以后你再看任何“AI-native lakehouse”“multimodal data platform”“统一检索底座”之类的方案，拿这几条去问，基本就能看出它到底是在讲系统，还是在讲宣传。
第一，看它有没有统一 catalog / namespace。表、文件、模型、函数、索引，至少要在治理语义上能讲成一套。
第二，看 raw asset 到 chunk / embedding / index 有没有明确 lineage。不是“概念上有”，而是系统里能追。
第三，看 embedding、chunk、index 有没有显式版本化。没有这层，别谈长期运营。这个结论更多是工程推断，但它和目前各家强调的同步、治理、训练数据管理方向是吻合的。
第四，看索引是不是派生层，能不能从主数据重建。能重建，系统才有韧性。
第五，看检索是不是只会“向量召回”，还是已经把 metadata filter、hybrid、rerank 当成默认能力。复杂多模态场景里，后者才更接近生产。
第六，看权限能不能穿透到非结构化和派生对象。企业场景里，这条过不了，基本就不用继续往下谈了。
第七，看它有没有把训练、检索、推理的差异当回事。谁还在讲“一套布局解决全部 workload”，谁就大概率还停留在 demo 视角。
第八，看它是不是内建了评测、观测和成本控制。没有这层，系统迟早会变成“能跑，但越来越贵，也越来越难解释”。
这八条里，只要有三四条回答得很虚，那它大概率还不是真正意义上的多模态 lakehouse，只是“看起来统一了一点”。
结尾：这个词还没完全定型，但这条路已经很难回头了
回到最初的问题：Multimodal Lakehouse，到底是新架构范式，还是旧问题的新包装？
我的答案是：两个成分都有。
从术语上看，它今天确实还带着明显的厂商叙事色彩，尤其是 2025 年以后，少数厂商在主动把它往一个独立品类上推。把它直接说成已经成熟的行业标准，肯定太早。
但从工程上看，它对应的那组问题已经非常真实了，而且只会越来越硬。只要你的系统开始同时依赖原始文件、结构化元数据、embedding、索引、特征、权限、评测和 Agent 工作流，传统那种“对象存储一份、向量库一份、仓库一份、代码再缝一层”的做法，迟早会碰到上限。这个上限不是模型能力的上限，而是数据系统组织方式的上限。
所以真正值得相信的，不是这个名字，而是它背后的方向：
开放格式会继续重要，catalog 会继续上移，向量索引会越来越像派生层，非结构化数据会越来越深地进入治理体系，训练、检索、推理和 Agent 会围绕同一套对象语义协作，但不会被粗暴地塞进同一种物理布局里。谁能先把这些关系理顺，谁就更接近下一代 AI 数据底座。
说到底，Multimodal Lakehouse 不是在回答“怎么把更多数据类型放进湖仓”，而是在回答一个更硬的问题：
当 AI 系统开始同时依赖文件、表、向量、索引、特征、权限和评测时，底层数据基础设施该怎么重新长成一个系统。
这才是它真正值得研究、也最值得落地的地方。
参考资料与延伸阅读
- Databricks Documentation: Unity Catalog / Volumes / Vector Search / Agent Framework (Databricks 文档)
- Snowflake Documentation & Engineering Blog: Unstructured Data / Directory Tables / AI-ready Data Architecture / Structuring the Unstructured (Snowflake 文档)
- Apache Iceberg: Table Spec / REST Catalog Spec (Apache Iceberg)
- LanceDB: Multimodal Lakehouse 相关博客与定位文章 (lancedb.com/)
- PVLDB 2025: Magnus: A Holistic Approach to Data Management for Large-Scale Machine Learning Workloads (VLDB)
- PVLDB 2025: Cracking Vector Search Indexes (VLDB)
- Milvus Documentation: Multi-vector / Hybrid Search (Milvus)
- NVIDIA Documentation: GPUDirect Storage (NVIDIA Docs)
