MaxCompute 多模态检索：原生向量能力开启多模态 AI 大数据处理新范式

向量：AI 时代的多模态数据底座

Embedding——也就是向量嵌入——将文本、图片、音频、视频等多模态数据的语义，全部编码成高维向量。当这些向量被放进同一个空间，通过计算彼此之间的距离来揭示语义关联时，真正的价值才得以释放。这个过程就是向量检索（Vector Search）。

起初，向量主要服务于搜索和推荐：用户搜一个词，系统得理解它与商品标题、正文之间的语义关系；用户看过一个商品，系统要找出相似款或可能感兴趣的内容。这活儿干得不错，但应用边界也就限于此了。

到了今天，大模型和 RAG 的崛起彻底拓宽了向量的舞台——智能问答、图片检索、文档去重、语音意图识别……几乎每个需要系统理解“两段文本是不是同一个意思”“两张图是否相似”“这个 Query 该匹配哪些知识块”的场景，都离不开 Embedding。可以说，向量早已不只是搜索推荐的基础设施，它正在成为 AI 时代的通用数据底座。

旧链路之困：跨系统拼装的多模态检索架构

在传统架构下，把向量检索塞进大数据处理链路，可不是一件轻松的事。数据工程师通常需要经历这么几步：

1. 在数据仓库或外部存储中存放并提取原始数据；

2. 动用专门的 ML 基础设施来生成 Embedding；

3. 把 Embedding 加载到独立的向量数据库进行检索匹配；

4. 开发自定义管道，将检索结果回流到 MaxCompute 做离线的批量 Join、过滤和分析，最终服务于线上场景。

对于很多 MaxCompute 用户来说，这条链路的复杂性是切肤之痛：原始数据在外部对象存储，Embedding 由外部脚本生成，索引构建和相似计算放在独立的向量系统，向量匹配结果再回流 MC 做 Join、过滤、评估和回写。每一步都像在拼乐高，但拼好后发现，维护起来简直是个无底洞。

这样的链路当然能跑通，但跑久了真的会累——脚本要维护、索引版本要对齐、失败后还得排查是模型、数据、检索还是同步出了问题。更麻烦的是，每多一种模态，就要多一段处理逻辑。最终形成的，是一个“碎片化、高成本、高维护”的架构，这也成了很多团队拥抱向量化的最大门槛。

2.1 老版本：Proxima CE 的复杂链路

MaxCompute 早期的向量检索能力依托于达摩院开发的 Proxima CE 向量计算引擎。它以内嵌 JAR 包的形式运行在 MaxCompute 上，底层使用 Proxima 算法库。Proxima CE 能完成基础的离线向量检索，支持百万级 TopK 查询，但使用流程相当“重量级”：

• 环境准备繁琐
  ：需要创建 MaxCompute 项目、创建 DataWorks 工作空间并绑定数据源、单独申请开通 Volume 能力、创建 External Volume 并指定 OSS 内网域名。任何一个环节出了岔子，作业就会报错。

• 平台限制严格
  ：JAR 包基于 Linux 编译，Windows 和 Mac 平台一概不支持；odpscmd 命令行工具也只限 Linux 环境使用。

• 链路割裂明显
  ：向量检索只是独立的一步，检索结果需要额外的管道回流到业务表中做 Join 和过滤；向量化依赖外部脚本或模型服务完成；索引、脚本、结果表分散维护，稍有不慎就乱套。

• 多模态无从谈起
  ：仅面向纯向量数据，不支持 BLOB 等多模态对象存储。图文混合检索？业务侧只能自己拼装多条链路，费时费力。

2.2 新旧版本功能对比

那 MaxCompute 多模态检索的目标就很明确了：把多模态对象、向量化、索引、检索、过滤、分析和结果回写，全部拉回 MaxCompute 主链路。围绕离线大规模多模态数据处理场景，让用户用熟悉的表、SQL、分区和权限体系，完成端到端的向量数据生产和计算。

对比维度	Proxima CE	MaxCompute 多模态检索
算法库	Proxima	VSAG
数据类型与向量化	纯向量（INT8/FLOAT/BINARY），向量化依赖外部脚本或模型调用	原生 VECTOR + BLOB 多模态对象，SQL 内调用 AI_EMBEDDING 完成向量化
使用流程	开通 External Volume → 安装 JAR → 编写 Job 脚本 → 结果回流	CREATE TABLE → AI_EMBEDDING → VECTOR_SEARCH + Join，一条 SQL 闭环
SQL 集成	检索与后续分析割裂，结构化过滤需业务侧二次处理	VECTOR_SEARCH + 距离函数 + Join + 过滤一体化，与类目、分区、标签、价格等业务条件在同一 SQL 中完成
大规模离线处理性能	可完成基础检索，但扩展和调优成本高	面向批量任务深度优化，以 Proxima CE 同等数据集和召回规模为基线，在已测试的多个业务场景下作业运行时间加速 1.27x ~ 5.86x
运维治理	索引、脚本、结果表分散维护	统一纳入表、分区、权限、调度、血缘体系

MaxCompute 面向多模态检索场景的升级，绝不仅仅是提供一个 VECTOR_SEARCH 函数那么简单。它把向量检索从“外部召回步骤”变成了“离线数据生产链路的一部分”，从而减少跨系统数据搬运，从根本上优化复杂的生产架构。

它解决了传统链路的四个痛点

MaxCompute 多模态检索分层构建了从数据入仓到检索结果产出的完整能力集，核心能力如下：

能力层	关键功能	作用
统一存储	BLOB 多模态对象 + VECTOR 原生向量类型	图片、文档、文本、向量放在同一张表里
内置向量化	AI_EMBEDDING 函数	在 SQL 中完成文本、图片等数据的向量化
索引与检索	向量索引 + VECTOR_SEARCH + 距离函数	批量 TopK 近邻召回
业务分析	SQL Join / 过滤 / 聚合 / 回写	检索结果直接接入推荐、广告、搜索、RAG 链路

3.1 统一存储：多模态数据不再多系统拼装

：图片、文本、文档、OCR、ASR、视频帧和业务标签要一起处理，过去结构化业务数据、非结构化原始数据和向量 Embedding 往往分散在不同系统中。每次模型迭代或数据变更，都需要重新同步对齐，光是对齐版本就能耗掉半天。

：MaxCompute 多模态检索支持在同一张表里同时管理结构化字段、多模态对象和向量字段。

CREATE TABLE item_base(
  item_id STRING,
  title STRING,
  category STRING,
  brand STRING,
  price DECIMAL(10,2),
  stock_status STRING,
  image BLOB,
  text_embedding VECTOR(FLOAT,128),
  image_embedding VECTOR(FLOAT,512)
)
PARTITIONED BY (dt STRING)
TBLPROPERTIES ("data.evolution.enable"="true","table.format.version"="2");

其中：

• BLOB（Binary Large Object）作为 MaxCompute 支持存储图片、音频、视频、文档等非结构化二进制大对象的类型，将多模态数据的原始文件、元信息和标注信息统一存放。

• VECTOR 是 MaxCompute 的原生向量数据类型，基于 VECTOR(FLOAT , ) 格式，用于高效存储和处理 Embedding 数据。

• AI_EMBEDDING 函数支持在 SQL 中直接调用大语言模型，将文本或多模态数据转换为向量。

通过以上能力，所有数据得以在 MaxCompute 同一张表内完成向量化和存储，再也不用跨系统来回倒腾了。

3.2 统一分析：标量过滤与向量检索一体化执行

：真实的业务很少只看向量距离。商品召回要看类目、价格、库存、内容安全；广告匹配要看计划、人群、地域、预算；知识库要看租户、权限、文档类型。传统做法是先匹配一个大候选集再过滤——候选集取大了成本高，取小了过滤后结果可能不够用，左右为难。

：多模态检索把两种数据处理需求统一放到 MaxCompute SQL 链路里处理。先限定业务条件，再对 Query 向量做相似计算，最后继续 Join 商品、用户和实验分组表。VECTOR_SEARCH 函数可通过 base/query 子查询分别做过滤，再执行 Base Table 和 Query Table 之间的离线批量向量检索。业务条件不再是“事后补救”，而是“事前约束”。

SELECT
  r.query_id,
  r.item_id,
  r.distance,
  i.category,
  i.brand,
  i.price
FROM
  VECTOR_SEARCH(
    (SELECT item_id, category, brand, price, text_embedding
     FROM item_base
     WHERE dt='2026-06-22'
       AND category='3C数码'
       AND price BETWEEN 100 AND 500
       AND stock_status='on_sale'),
    text_embedding,
    (SELECT query_id, query_embedding
     FROM query_embedding
     WHERE dt='2026-06-22'
       AND scene='search_recall'),
    query_embedding,
    50) r
JOIN item_base i
  ON r.item_id = i.item_id
  AND i.dt = '2026-06-22'
ORDER BY r.query_id, r.distance ASC;

3.3 面向大规模离线批量检索的全链路闭环

：很多企业的向量检索任务不是“来一条查一条”，而是每天、每小时批量生产：千万级商品相似召回、亿级内容去重、海量 Query 聚类、全量知识库重建。而且检索通常只是中间一步——结果还要补排序特征、做实验分桶、看质量指标、分析坏例，再写给下游链路使用。过去这些动作分散在多个系统中，数据在向量库和业务库之间反复搬运，维护成本高，传统向量数据库面对大规模批量任务时扩展和调优成本也不低。

：MaxCompute 多模态检索将“检索→打分→补全→分析→回写”整条链路在 SQL 中一次性闭环：

• 检索与打分
  ：支持 VECTOR_SEARCH 批量检索，同时结合 cosine_distance、l2_distance、inner_product_distance 等距离计算函数完成融合打分。

• 业务补全
  ：SQL Join 补充类目、价格、标签、权限、用户分层等业务字段，过滤和聚合直接在检索结果上执行。

• 分析与回写
  ：相似结果写入推荐、广告、搜索、RAG、数据治理等下游表，纳入现有调度、权限和血缘体系，分区表沉淀每日候选集交给下游任务消费。

尤其值得强调的是，这一全链路面向离线批量任务做了深度优化，充分利用 MaxCompute 的分布式计算能力——以 Proxima CE 同等数据集和召回规模为基线，在已测试的多个业务场景下，作业运行时间获得了 1.27x ~ 5.86x 的加速，CU 消耗也有明显下降。

三个典型应用场景

MaxCompute 多模态检索更适合承接大规模、批量化、需要和业务数据深度结合的离线多模态数据处理链路。下面三个场景分别围绕搜推广告、多模态理解和 AI 语料治理三大方向，展示在不同业务场景下的落地方式。

4.1 搜推广告候选集生产

：电商、搜索、推荐和广告链路需要周期性生成商品、内容、广告素材和用户意图的候选集。在原有架构中，通常先要在外部向量系统召回，再把结果导回数据仓库做过滤、Join 和回写，链路长且候选集质量难控。

：将商品表、行为表、标签表、实验分桶和向量列放在同一套 SQL 链路中处理，支持 Item-to-Item 相似召回、Trigger-Driven TopK 检索，以及类目、价格、库存、地域、人群等业务条件过滤。

：离线生成“看了又看”“买了又买”、搜推融合召回和广告候选集，线上链路只需合并、去重和重排，显著降低实时召回压力。

4.2 汽车多模态理解与意图预处理

：智能座舱数据包含语音 Query、ASR 转写文本、车控指令、导航目的地、座舱图片/视频帧、车辆状态等多种信号。同一意图存在大量口语化、方言化表达，单靠关键词规则很难稳定归类。

：将语音文本、车控标签、图片/视频帧特征和车辆状态字段统一入仓，先按车型、设备、地域、时间窗口等标量条件缩小范围，再做向量相似召回、聚类和 Badcase 对比。

：离线沉淀意图簇、意图映射表和训练样本表，支持相似 Query 扩增、新意图发现、识别失败样本归因，避免把计算密集型相似度任务放到车端或在线链路中实时完成。

4.3 AI 语料治理与 RAG 候选集构建

：大模型和 RAG 场景需要处理 PB 级文档、网页、图片说明、OCR 文本、问答记录和业务知识。检索结果通常还要叠加租户、权限、业务域、版本、更新时间和质量标签。

：在 MaxCompute 内完成“数据入仓 -> 向量化 -> 索引构建 -> 批量检索 -> 关联分析 -> 结果回写”，统一管理 BLOB 对象、文本片段、Embedding、质量标签和业务元数据。

：批量构建知识块候选集，支持语料去重、相似内容发现、低质样本清洗和召回效果评估。相比把语料、向量和分析结果分散在多个系统中，MaxCompute 能大幅降低跨系统搬运和批处理编排成本。

总结

说到底，MaxCompute 多模态检索并不是把向量检索包装成一个更复杂的新概念，而是把向量能力放回 MaxCompute 数据生产链路里，和表、SQL、分区、权限、调度、血缘一起工作。这样一来，客户少维护几段链路，少搬几次数据，也少在每次改规则、换模型、重建索引时来回对齐系统状态。核心优势概括如下：

• 少搬数据
  ——多模态对象、向量、索引和召回结果都留在 MaxCompute 内，消除了 Proxima CE 时代跨 Volume、OSS、外部向量系统的数据搬运。

• 少写脚本
  ——向量化、检索、过滤、Join、融合打分和回写全部用 SQL 串起来，外部脚本和临时同步任务大幅减少。

• 结果更可控
  ——向量相似度可以和类目、价格、权限、人群、地域、时间窗口等业务条件在同一 SQL 中联合使用。过去需要先召回十万级候选集再逐层过滤到几百条，现在直接在查询中约束条件精准匹配。

• 适合离线批量处理
  ——面向千万级、亿级离线召回、内容去重、知识库重建等任务深度优化。对比 Proxima CE 同等数据集和召回规模为基线，在已测试业务档位中，MaxCompute Vector Search 能力相比 Proxima CE 取得了 1.27x ~ 5.86x 的作业运行时间加速，CU 消耗也大幅优化。