多模型表格：一个表格管理文件与嵌入向量，同时为智能体提供混合搜索功能。
多模型表格如何通过动态列、数据溯源功能以及内置的混合搜索机制，确保原始文件、嵌入向量及人工智能生成的特征在各个智能体之间保持一致。
来源: Multimodel Tables: One Table for Every Modality Your Agent Needs
多年来，这款数据库一直在向单一的统一系统发展，涵盖了关键工作负载的分布式事务处理、HTAP、多模型数据以及混合搜索功能。其Lakebase产品则标志着重点方向的进一步转变。现在的问题不再仅仅是数据库能处理什么，而是它为谁服务。过去的数据库是为开发者、数据库管理员和应用程序而设计的。该厂商认为，在人工智能时代，数据库还必须服务于另一类用户——智能体。
按照这个定义，“AI数据库”并不仅仅是能够存储图片、PDF或矢量文件的系统。它是一种专为智能体提供完整、实时且可靠的上下文信息以供其推理和行动而设计的系统，通过嵌入向量、原始文件以及混合搜索功能，所有信息都来自同一来源。其余内容则介绍了Lakebase中的多模型表功能及其要解决的问题。这些都是供应商的宣传说法，需结合您自身的工作负载进行验证。
智能体的数据难题
想象一下智能体需要做出的决策。它可能同时需要结构化的用户资料、对话的文本摘要、知识库中的原始PDF文件、通过矢量检索得到的语义相关结果，以及业务当前的实时状态。
如今，这五种数据通常存储在五个不同的系统中：对象存储、搜索引擎、向量数据库、业务数据库以及离线仓库。它们之间不存在共享事务、一致性的快照，也没有统一的溯源机制。
如果某个PDF文件被更新了，但其嵌入引用仍指向旧版本，那么相关处理工具会给出错误但看似确定的答案，而没人能察觉到问题。这并非单纯增加数据存储类型的问题，而是一个治理问题。一旦多模型数据被纳入关键处理流程，就必须有人来确保版本一致性、计算完整性、可追溯性以及数据的可靠性。在许多团队中，承担这一职责的往往是他们自己维护、每季度都会进行调试和重写的处理流程。
多模型表是Lakebase的解决方案。它是该产品核心的数据管理功能，能够将图像、音频、视频、PDF文件、网页快照、向量、JSON数据以及结构化列视为独立的数据库对象进行管理。所有这些数据都存在于同一个系统中，该系统具备事务处理、数据一致性保障、高可用性、混合搜索、分析计算以及在线服务等功能。
为何智能体需要不同的数据模型
智能体处理的对象本质上是多模型的。输入数据涵盖自然语言、图像、PDF文件、网页、表格以及业务上下文等多种形式。在运行过程中，智能体会依赖用户记忆、知识库、RAG输出结果、结构化业务数据、语义描述以及中间模型计算结果。
由此带来了以下四点转变：
- 非结构化数据开始占据核心地位。它不再只是存储在对象存储中的附件，而是成为决策的重要依据。
- 查询方式转变为混合搜索。单个请求可结合结构化筛选、全文检索、向量检索以及分析聚合功能。
- 实时性要求不断提高。系统需要全天候运行，而传统的次日报告已无法满足需求。
- 特征是动态生成的。许多字段并非直接编写，而是由模型从原始数据中异步提取而来。
实际问题在于如何将原始的多模型数据、结构化字段、衍生特征以及异步结果统一到一个数据库中，使其能够同时服务于在线交易、分析查询和混合搜索，同时保持数据的一致性与可追溯性。这正是多模型表所要解决的设计难题。
核心功能
多模型对象的统一存储空间
多模型表将这些对象置于数据库自身的事务和版本控制之下。图像、音频、视频、PDF文件以及网页快照等大型对象可以通过多种不同的方式存储。这些数据的物理存储位置并非最关键的因素，重要的是数据库对其做出的承诺：不变的ID、访问路径、版本号、可见性状态以及明确的事务范围。
这样做的目的是确保原始对象及其衍生特征（如摘要、标签、嵌入向量及风险评分）始终对应相同的数据版本，从而避免出现对象已更新但其特征仍描述旧内容的情况。
动态特征列
多模型数据极为丰富，单个原始对象就能衍生出无数特征：语义特征、结构特征、质量相关特征以及业务特定特征。从文本中可获取主题、摘要、嵌入向量、安全标签、语言类型以及质量评分；从图像中则能得到OCR识别结果、标签、风险评分以及业务属性。每一种新模型都会增加更多特征。
在传统架构下，每新增一个特征就需要进行DDL修改。而每一次DDL修改都会导致缓存失效、写入操作量增加以及后台数据压缩压力增大，因此特征开发的进度会被表锁的速度所限制。
多模型表采用轻量级的动态列机制。添加新功能无需修改架构，查询仍为原生SQL格式，分析优化功能依然有效，混合搜索也能通过索引完成。这并非退回到键值存储方式，因为后者虽然灵活，但无法进行SQL分析及搜索优化。该设计在可优化结构与动态扩展性之间进行了精心权衡，力求同时兼顾两者。
异步、近乎实时的计算
许多列根本不是由用户直接写入的，而是通过计算任务生成的，这些任务包括使用内置模型功能、后台作业或外部管道来生成嵌入向量、摘要、OCR结果、质量评分、全文索引以及向量索引等。
模型推理通常需要数百毫秒到几秒的时间，这一速度过慢，无法阻碍在线写入操作。因此，表格不会等待：
- 首先提交原始数据，以保持在线写入的延迟不变。
- 后台任务会根据数据来源顺序开始特征提取、索引构建和回填操作。
- 衍生值会在近乎实时的时间内显示出来。
- 读取操作始终能获取一致的快照。
这样设计的原因是，对每个衍生列进行严格同步既不现实也不必要。合理的平衡点应在于延迟、吞吐量、存储效率与一致性之间。计算任务负责生成数值，而表格则使这些数值能够被有效管理、检索、分析，并始终保持一致的读取结果。
列组一致性
异步计算会引发可见性问题。一旦某行数据生成，特征A、特征B、嵌入向量、全文索引以及质量标签等都可能由不同的任务和模型在不同时间完成处理。如果查询在特征A尚未处理完成时就已经看到特征B的处理结果，它就会在没有任何提示的情况下返回错误答案。
在存储层中，列组一致性解决了这一问题。只有当所有相关的派生列都处理完成后，某个业务列组才会生成一个新的可见快照。查询和混合搜索都会读取一致的快照，从而不会遇到半完成的数据。
存储与计算分离，热数据与冷数据并存
多模型数据在文档、图像、视频、向量及衍生特征等方面的规模持续增长且没有上限，因此在大规模环境中无法让所有数据都保持高活跃状态。这些系统采用分散式架构并共享存储，将高活跃数据与低活跃数据视为一个连续体：
- 最近的数据，比如过去90天内的数据，会被缓存到SSD中，以确保快速访问。
- 较旧的数据，例如超过90天的数据，则存储在成本较低的共享存储中，但仍可通过同一接口进行查询、搜索和分析。
无需切换系统即可获取低活跃数据，也无需组合在线数据库、对象存储和离线仓库来回答单个问题。整个系统拥有统一的视图、查询界面和管理模型。
数据溯源与统一目录
那个嵌入内容来自哪段文本？是哪个审计模型赋予了那个安全标签？该摘要描述的是PDF的哪个版本？
数据溯源与统一目录构成了元数据的骨架。它们记录了原始对象、结构化字段、动态特征列、模型任务、版本以及权限之间的关联关系。这些元数据可支持以下三方面功能：
- 触发机制。用于数据提取、索引构建和回填的后台任务会基于数据溯源自动启动。
- 完整性检查。在数据可被查看之前，系统会确认相应的列组或快照是否已完全计算完成。
- 可追溯性。当智能体给出答案时，可以追溯到它所使用的文档、图像、记录以及衍生特征。
适用于事务处理、分析及搜索的统一访问层
多模型表被定义为针对相同数据的三类工作负载的共享基础：
- 在线事务处理，即具有ACID保证和高可用性的业务写入操作；
- 分析处理，即大规模扫描、聚合、过滤、连接以及特征分析；
- 混合搜索，即结构化过滤与全文检索、向量召回、标签过滤及业务排名相结合的方式。
代理访问本质上是分多步进行的。一个请求可能先根据结构化条件进行过滤，再以全文形式搜索描述内容，接着通过向量召回查找相似内容，最后根据标签、质量、更新时间及权限进行排序。没有单一的专用引擎能够覆盖这四个步骤。
核心的权衡在于近乎实时的处理速度与高度同步性之间的平衡。搜索和分析功能无需在写入事务中就完成特征提取，但这些特征必须在有限的短时间内变得可用，并且要来自一致的快照。正因如此，一个表就能同时支持在线写入、混合检索和分析，而无需维护三个相互关联的副本。
它替代了什么
对于如今的智能体项目而言，它的优势在于能够替代对象存储、搜索引擎、向量数据库、业务数据库以及离线数据仓库等一系列组件。过去多模型功能覆盖范围与数据库级管理机制之间的妥协状况将随之消失。
为何重要
真正的问题不在于人工智能数据库是否能够存储图片、PDF文件或向量数据，而在于当智能体成为数据库的首批核心用户时，将会带来哪些变化。
如果答案是每种数据类型对应一个独立的系统，那么就需要保护更多的界面，防范更多的数据管道被破坏，同时也要应对更多隐性偏差。而如果答案是一个统一的受管控表结构，其中每种数据模式都被视为一级对象，那么就能建立起真正稳固的数据基础，而非仅由数据管道构成的临时框架。
多模型表将结构化数据、非结构化数据、人工智能生成的特征以及业务语义整合到同一个系统中，以实现事务处理、治理和计算功能。传统数据库用于统一数据，而在人工智能时代，它们需要同时统一数据、语义以及生成这些内容的操作流程，而这一功能正是 Lakebase 在该方向上的第一步。
评估方法
多模型表作为 Lakebase 的组成部分一同提供。要根据自身的智能体工作负载来评估它们，需列出需要管理的数据类型、正在构建的智能体场景以及任何性能或治理要求，然后构建一个多模型表，并将其与它所替代的现有方案进行比较。关键的测试标准是该智能体是否不再输出错误答案。
相关阅读
- 本体还是语义层？AI 智能体为何需要两者：本体与语义层的区别、仅存在其一时的问题、知识图谱的适用场景，以及构建上下文层的实际步骤。