作者：周康，阿里云开源 OLAP 引擎团队负责人；StarRocks TSC Member
导读：当图片、视频和文档经过模型理解并转化为描述、标签和向量，业务需要解决的已不只是“如何找到相似内容”，还包括结构化过滤、混合检索及后续的关联分析。本文将介绍 StarRocks 为什么建设全模态能力，以及多模态处理、内表、Paimon 和 Lance 四个能力方向如何连接内容理解、检索与业务分析。
一支基础模型训练团队正在准备下一轮训练数据。
面对百亿级 Embedding 和多模态语料，团队首先需要按照任务、语言、来源、质量和版本缩小数据范围，再结合关键词、语义相似度、去重规则和样本分布形成候选集。完成圈选后，还要进一步关联原始内容、标注结果、训练版本和模型评测，判断这些数据是否真正适合进入训练。
这显然不只是一次“输入向量、返回 Top-K”的相似性搜索。
一条完整的训练数据圈选链路，往往同时包含结构化过滤、全文检索、向量召回、集合运算和大规模结果分析。找到样本之后，还要继续评估其质量、覆盖度以及对模型训练效果的影响。
类似的问题也出现在智能驾驶、具身智能、短剧和游戏等行业。尽管原始数据和业务目标不同，其处理链路却具有较强的共性：
原始对象与业务数据 → 内容理解与特征化 → 结构化、全文和向量检索 → 关联业务结果 → 反哺训练、生产或运营。
过去，这条链路通常由对象存储、数据处理任务、模型服务、搜索引擎、向量数据库和分析数据库共同完成。每个系统负责其中一段，团队还需要维护多套数据副本和同步链路，并在应用侧重新拼接检索与分析结果。
问题在于，当检索结果需要继续关联数据版本、设备状态、质量结果或运营指标时，“找到数据”和“分析数据”很难真正分开。向量召回只是其中一个环节，完整的业务判断仍然依赖过滤、Join、聚合和指标计算。
StarRocks 正在围绕多模态处理、全文与向量检索、半结构化数据分析和湖上数据查询建设全模态能力，让不同形态的数据进入同一条 SQL 处理、检索与分析链路，缩短从内容理解到业务使用的距离。
(图 1：从百亿级 Embedding 训练数据圈选出发，StarRocks 将多模态处理、内表、Paimon、Lance 与行业分析组织成一条连续的数据链路。)
01 全模态是什么：让不同形态的数据进入同一条链路
“多模态”和“全模态”经常被放在一起讨论，但本文关注的重点并不是模型能够理解多少种模态，而是企业真实业务中的不同形态数据，如何被组织进一条连续的处理、检索与分析链路。
这些数据大致可以分为三类：
-
结构化数据 ：时间、设备、用户、车型、版本、状态和指标等具有稳定 Schema 的字段；
-
半结构化数据 ：JSON、Variant、动态属性和模型返回结果等结构可能发生变化的数据；
-
非结构化数据 ：图片、视频、音频、文档以及对象存储中的其他文件。
仅仅把这些数据保存在同一个存储系统中，并不意味着已经实现了全模态。真正进入业务流程，还需要继续解决三个问题：
-
如何理解内容 ：将图片、视频、音频和文档转换为描述、标签、结构化字段或向量；
-
如何找到目标 ：组合确定性条件、关键词和语义相似度完成检索；
-
如何使用结果 ：将命中内容与训练结果、设备状态、质量数据或运营指标关联，继续执行 Join、聚合和分析。
因此，本文所说的全模态，不是一种新的数据类型，也不要求单一模型或单一系统解决所有问题。它描述的是一种数据使用方式：让结构化、半结构化和非结构化数据经过内容理解与特征化后，进入同一条检索与分析链路，并最终参与业务计算和决策。
（图 2：不同形态的数据先被理解和特征化，再通过结构化条件、全文和向量完成检索，命中结果继续参与 Join、聚合和业务决策。）
02 AI 时代，为什么检索不能只靠向量
过去，进入分析系统的数据通常已经完成清洗和建模。数据库主要处理订单、设备事件、用户行为和业务指标，图片、视频与文档往往只以 URL 的形式存在，文件中的实际内容很难直接参与查询和分析。
AI 改变了这一点。模型能够批量生成图片描述、提取文档字段、识别视频场景、完成内容分类，并将文本、图片、音频和视频映射为可比较的向量。大量过去只能依靠人工浏览的非结构化内容，开始被转换为可以检索和计算的数据。
但能够将内容转化为向量，并不意味着业务问题可以被简化成一次向量 Top-K 查询。
以智能驾驶的长尾场景挖掘为例，团队可能需要查找“夜间雨天，车辆在路口避让突然出现的行人”这一类片段。视觉和动作上的相似性可以通过向量召回，但查询通常还需要限定车型、软件版本、采集时间和传感器状态，匹配相关故障码或事件标签，并将命中片段与标注结果、模型输出和回归测试表现关联起来。
类似需求也存在于其他行业：
-
基础模型训练需要按照来源、语言、质量和版本圈选语料，并结合语义相似度、去重规则和模型评测筛选训练数据；
-
具身智能需要对相机、LiDAR、IMU、触觉和动作轨迹进行时序对齐，再查找失败片段及相似的成功经验；
-
短剧和内容生产需要在剧本、分镜、视频、音频和字幕中寻找素材，同时检查角色、版权、版本和投放效果；
-
游戏与 IP 资产管理需要关联角色、立绘、3D 模型、动画、台词和设定文档，并维护版本、本地化与世界观一致性。
尽管业务目标不同，这些查询通常都包含四类条件：
-
权限、时间、设备和版本等确定性条件；
-
故障码、角色名和专业术语等精确文本条件；
-
视觉、动作或文本语义上的相似性；
-
检索结果与训练、质量、生产或运营指标之间的关联。
（图 3：不同行业的数据形态不同，但都需要组合严格条件、关键词、语义相似度和业务结果关联。）
向量检索解决的是“内容在语义上是否相似”，但无法单独承担权限过滤、精确匹配、时间关联、集合运算和结果分析。真正进入业务场景后，向量召回还需要与全文检索、结构化过滤和 SQL 分析协同工作。
03 为什么 StarRocks 要建设全模态能力
StarRocks 原本承担的核心工作，是对结构化业务数据进行实时分析、Join、聚合和多维查询。当图片、视频、文档及其对应的描述、标签和向量进入业务流程后，数据形态发生了变化，但许多查询最终仍然需要回到这些分析能力中。
训练数据圈选后，需要比较不同数据版本和模型版本的表现；缺陷图片被召回后，需要关联设备、位置和处置工单；内容素材被找到后，需要检查版权状态、渠道版本和投放效果；知识片段被召回后，还需要叠加租户、权限和时间条件。
这些场景的共同点在于：检索并不是查询的终点。命中结果还要继续与业务数据关联，参与过滤、Join、聚合和指标计算，才能形成可用于训练、生产或运营的结果。
如果全文和向量检索完全在独立系统中完成，团队通常需要将数据复制到搜索引擎或向量数据库，再把命中的 ID 返回分析数据库继续计算。数据更新、删除、权限调整和 Schema 变化，也需要在多套系统之间保持一致。
因此，StarRocks 建设全模态能力，并不是要替代对象存储、模型平台或所有专用检索系统，而是将对象处理、半结构化分析、全文检索和向量检索逐步接入现有的 SQL 分析链路：
-
让模型生成的描述、标签、结构化字段和向量可以继续作为数据被查询和计算；
-
让全文与向量召回结果直接参与过滤、Join、聚合和指标分析；
StarRocks 在这条链路中的核心作用，是连接内容理解、混合检索与业务分析，减少“先在一个系统找到数据，再到另一个系统分析数据”所带来的数据复制、结果搬运和链路割裂。
04 StarRocks 全模态能力如何组织
StarRocks 的全模态能力主要沿多模态处理、内表、Paimon 和 Lance 四个方向演进。它们分别面向对象内容处理、实时检索与分析、湖上大规模数据管理，以及已有多模态和向量数据接入等不同需求。
这四个方向并非相互替代。实际项目中，可以根据原始数据的位置、更新频率、数据规模和查询方式组合使用。
(图 4：多模态处理、StarRocks 内表、Paimon 湖表和 Lance 接入分别对应不同的数据位置、更新方式与分析链路。)
多模态处理：将原始对象转换为可计算的数据
图片、视频、音频和文档通常以文件形式保存在对象存储中，数据库中只记录对象地址和少量元数据。要让其中的内容参与查询，首先需要完成对象发现、内容理解与特征化。
Object Table 用于管理对象存储中的文件位置、版本和基础元数据，将原始对象接入数据处理流程；AI Function 则调用模型完成内容理解、字段抽取、分类、生成和向量化。
原始文件仍然保存在对象存储中，处理生成的描述、标签、结构化字段和向量可以继续进入后续的过滤、检索与分析链路。
StarRocks 内表：面向更新更快的检索与分析
当数据需要快速写入并及时可查，且检索结果需要频繁与业务字段执行过滤、Join、聚合和在线分析时，可以使用 StarRocks 内表承载可检索特征和热点数据。
内表可以组织结构化字段、Flat JSON、文本和向量，并通过全文索引、向量索引与普通 SQL 条件组合查询，适合对数据新鲜度和交互分析要求较高的场景。
Paimon：承载大规模、长期管理的全模态数据
当图片、视频、轨迹和文档数据规模较大，同时需要开放格式、对象存储成本、多引擎共享以及快照和版本能力时，可以使用 Paimon 组织和管理相关数据。
结构化字段、Variant 半结构化内容、BLOB 非结构化对象、文本描述和向量可以围绕同一张湖表组织。数据快照和版本能力还可以固定训练数据边界，为训练复现、历史回溯和跨引擎使用提供数据基础。
Lance：接入已有的多模态与向量数据
部分团队已经使用 Lance 管理多模态和向量数据。针对这类场景，StarRocks 可以通过 Lance Connector 接入已有数据，在保留原有数据组织方式的基础上，提供统一的 SQL 查询入口，并继续执行结构化过滤、全文或向量检索以及结果分析。
生产使用时，需要结合对应版本确认 Lance Connector 的具体支持范围和查询边界。
05 如何选择：从数据位置和查询需求出发
选择全模态数据的处理与查询方式，不能只看是否支持向量索引。还需要综合判断原始数据存放在哪里、数据规模和更新频率如何、是否已经采用特定的数据格式，以及检索结果是否需要继续参与 Join、聚合和业务分析。
td {white-space:nowrap;border:0.5pt solid #dee0e3;font-size:10pt;font-style:normal;font-weight:normal;vertical-align:middle;word-break:normal;word-wrap:normal;}| 需求特征 | 更适合的路径 | 主要原因 |
|---|---|---|
| 对象仍在对象存储，需要抽取描述、标签或向量 | Object Table + AI Function | 先完成对象发现、内容理解与特征化 |
| 数据更新较快，检索结果频繁参与 Join、聚合和在线分析 | StarRocks 内表 | 写入、检索与 SQL 分析链路更短 |
| 数据规模大，需要开放格式、多引擎共享、快照与版本能力 | Paimon | 兼顾湖上存储、长期管理与可追溯性 |
| 已有 Lance 多模态或向量数据 | Lance Connector | 保留既有数据组织方式，通过 StarRocks 统一查询和分析 |
这些能力并非相互排斥。实际项目通常会根据数据生命周期组合多条路径：原始文件保存在对象存储中，通过模型生成描述、标签和向量；Paimon 管理大规模长期数据，StarRocks 内表承载更新频繁或查询时效要求较高的数据；如果已有 Lance 数据，也可以通过 Connector 接入，并与业务明细和指标统一查询。
06 全模态查询不止于检索
在全模态场景中，找到相似的内容通常只是第一步。要形成可以用于训练、质量分析、生产或运营的结果，还需要对候选数据进行组合、关联、排除、统计和版本管理。
一条完整的查询链路可能包含以下几类操作：
-
根据标签、元数据和 JSON 字段筛选数据，单独执行全文检索或向量 Top-K，也可以组合结构化条件、关键词和向量召回完成混合检索；
-
在多棵场景树或多个候选集合之间执行交集、并集、半连接和反连接，例如排除已经完成标注或已经进入训练集的数据；
-
通过时间点落入时间区间、区间重叠等关系，将视频帧、传感器数据、事件片段和模型结果进行关联；
-
在返回命中明细的同时，计算完整命中数、标签分布、质量分布和分桶统计；
-
按照数据集版本、数据快照和训练配方生成可追溯的样本清单。
（图 5：全模态能力覆盖对象理解、精确筛选、全文和向量检索、混合圈选、时间关联、集合运算、统计分析，以及训练和内容生产回流。）
全模态能力的价值不只取决于“检索到了什么”，还取决于这些结果能否继续进入训练、质量、生产或运营流程，并在后续使用中被准确复现。
系列预告
本文介绍了 StarRocks 全模态能力的整体方向。后续内容将围绕多模态处理、不同数据路径下的检索能力，以及具体行业实践分别展开：
-
多模态处理 ：介绍 AI Function 与 Object Table 如何完成对象发现、内容理解、特征化和增量处理；
-
内表全文检索 ：介绍文本索引、关键词检索，以及全文检索与结构化过滤、Join 和聚合的协同；
-
内表向量检索 ：介绍向量数据的组织、索引与语义 Top-K 查询，以及召回结果如何进入 SQL 分析链路；
-
全模态混合检索 ：介绍结构化条件、全文检索和向量召回如何组合，支持更加复杂的数据圈选；
-
Paimon 全模态检索 ：介绍结构化字段、Variant、BLOB、文本和向量如何围绕同一张湖表组织与查询；
-
Lance 全模态检索 ：介绍 StarRocks 如何接入 Lance 中的多模态与向量数据，并进行过滤、检索与分析；
-
行业实践 ：介绍全模态能力在基础模型训练、智能驾驶、具身智能、短剧内容生产和游戏/IP 资产管理等场景中的应用方法。
相关代码已合入 StarRocks Main 分支，将随下一版本正式发布。后续文章也将结合版本进展，进一步介绍不同能力的使用方式与适用场景。