向量：AI 时代的多模态数据基础设施

嵌入（Embedding）——即向量化表示——能够将文本、图像、音频、视频等多种模态的数据语义，统一编码为高维向量。当这些向量被映射到同一语义空间，通过计算彼此之间的距离来揭示深层关联时，真正的价值才得以释放。这一过程被称为向量相似度搜索（Vector Search）。

最初，向量技术主要服务于搜索与推荐场景：用户输入一个关键词，系统需要理解该词与商品标题、描述之间的语义匹配；用户浏览过某件商品，系统要找出相似款式或可能感兴趣的其他商品。这类任务表现不错，但应用范围基本局限于此。

如今，大模型与 RAG 技术的兴起彻底拓宽了向量的应用边界——智能问答、图像检索、文档去重、语音意图识别……几乎每个需要系统判断“两段文本是否表达相同意思”“两张图片是否相似”“当前查询应该匹配哪些知识片段”的场景，都离不开向量嵌入。可以说，向量早已不再是搜索推荐的专属基础设施，它正在成为 AI 时代的多模态数据通用底座。

旧架构的困局：跨系统拼装的多模态检索流程

在传统架构下，将向量检索嵌入大数据处理链路并非易事。数据工程师通常需要经历以下几步：

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

2. 借助专门的机器学习基础设施生成向量嵌入；

3. 将向量嵌入加载到独立的向量数据库中进行相似度匹配；

4. 开发自定义管道，将检索结果回流到 MaxCompute 进行离线的批量关联、过滤与分析，最终服务于线上业务。

对大多数 MaxCompute 用户而言，这条链路的复杂性堪称切肤之痛：原始数据存放在外部对象存储，向量嵌入由外部脚本生成，索引构建与相似度计算放在独立的向量系统，向量匹配结果再回流到 MaxCompute 进行关联、过滤、评估与回写。每一步都像在拼装乐高积木，但拼好后发现，维护工作几乎是个无底洞。

这样的链路当然能跑通，但长期运行下来会让人疲惫不堪——脚本需要持续维护、索引版本必须对齐、故障排查时难以确定是模型、数据、检索还是同步环节出了问题。更棘手的是，每增加一种模态，就需要新增一段处理逻辑。最终形成的，是一个“碎片化、高成本、高维护”的架构，这也成为许多团队拥抱向量化的最大障碍。

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 环境使用。

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

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

2.2 新旧版本功能对比

因此，MaxCompute 多模态检索的目标十分明确：将多模态对象、向量化、索引构建、检索、过滤、分析与结果回写，全部整合回 MaxCompute 主链路。围绕离线大规模多模态数据处理场景，让用户通过熟悉的表、SQL、分区与权限体系，完成端到端的向量数据生产与计算。

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

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

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

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

场景挑战：图片、文本、文档、OCR、ASR、视频帧与业务标签需要一起处理。过去，结构化业务数据、非结构化原始数据以及向量嵌入往往分散在不同系统中。每次模型迭代或数据变更，都需要重新同步对齐，仅对齐版本就能耗费半天时间。

产品能力：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 , ) 格式，用于高效存储和处理嵌入数据。

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

借助以上能力，所有数据可以在 MaxCompute 同一张表内完成向量化与存储，从此无需跨系统来回搬运。

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

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

产品能力：多模态检索将两种数据处理需求统一整合到 MaxCompute SQL 链路中处理。先限定业务条件，再对查询向量执行相似度计算，最后继续关联商品、用户和实验分组表。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 面向大规模离线批量检索的全链路闭环

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

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

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

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

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

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

三个典型应用场景

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

4.1 搜推广告候选集生产

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

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

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

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

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

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

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

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

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

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

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

总结

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

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

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

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

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