“多模”这个词容易有歧义，熟悉数据库的人大概会理解为多种数据模型（Multi-model，多模型），而熟悉人工智能的人大概会理解为多种数据模态（Multi-modal，多模态）。这也体现了数据与人工智能相结合要首先解决的问题：概念和语义的对齐，不然就可能造成鸡同鸭讲的后果。此外，在不同上下文中，所谓”多模数据库”也有可能指的不是一种东西。日常沟通中没那么严谨，大多用”多模”表示多种不同类型的数据（例如文本、声音、视频等）。类似的，内存（Memory）与记忆（Memory）、健值（KV）与大模型的 KV 也都存在类似的问题。考虑到后面这两个例子的英语单词是一样的，更需要注意区分不同的上下文。

人工智能领域要处理的数据除了结构化数据和半结构化数据之外，更多的是非结构化数据。传统数据库最擅长结构化数据处理，半结构化数据就有点勉强，非结构化数据就更捉襟见肘了。从机器学习到现在的大模型训练，日常的数据处理中，人工智能领域更多的是用 Python 等写程序，发展出了各种函数库或框架来方便数据处理。DuckDB 应该算是数据库领域想要发挥自身强项的典型案例，希望通过简单易用的 SQL 语言和高性能的系统实现来加快日常的数据处理。在大规模的结构化和半结 构化数据处理领域，大数据系统、数据仓库系统、数据湖系统等发挥了更重要的作用。

面对多模态数据分析的挑战，数据领域中最自然的想法是增强或设计新的数据湖等系统，将非结构化数据的处理做得更好，甚至能够在一套系统中处理包括文本、图像、声音、视频等在内所有的数据。于是架构师们要解决的仍然是传统的几大问题：1. 数据存储（存到哪）2. 数据格式（怎么存） 3. 数据查询（怎么算）。从大规模数据处理的角度看，数据存储没得选，优先对象存储。从大规模数据处理生态的角度看，数据格式也好办，优先开源开放格式，不然没法互联互通。数据查询处理除了大规模并行计算外，还得实现各种多模态算子，引入新的代价模型和查询优化技术。从系统部署运行监控的角度看，运行环境（优先容器或轻量级虚拟机），处理器芯片（CPU、NPU、GPU 等），运维监控系统（优先介入现有系统）等都需要选择。

除了大规模数据处理需要多模态数据分析之外，日常不那么大的数据处理也将需要多模态数据分析。例如每个人的手机、平板、笔记本、PC 设备中都存有大量的多模态数据，也应该把它们深入整合起来，做出更易用的查询分析应用。

然而，多模态数据分析处理与传统的大数据处理存在明显的差异。一条结构化数据没多少个字节，用 CPU 处理起来非常快也很经济。一条非结构化数据往往是一个很大的文件，用 GPU 处理也没那么快。这两种数据放到一条数据库记录中同时处理时，显然是后者要占用更多的资源和时间。服务器中 CPU 与 GPU 的配比也很难完美匹配这两种不同的负载，数据除了跨卡流动还得跨机器流动。即便是相对简单的多摸数据向量化（Embedding）后做相似性检索，批量和增量数据 Embedding 做向量化也很慢。因此，我们可以合理推断，多模态数据分析系统要先解决好少量多摸数据的问题，才有机会去解决海量多摸数据的问题。