热血江湖归来职业推荐 热血江湖归来职业选哪个好
2026-07-10 3391735
2026-07-10 0
Embedding（向量嵌入）将文本、图片、音频、视频等多模态数据的内在语义编码为高维向量。当这些向量被放入同一空间，通过计算彼此间的距离来揭示数据之间的语义关联时，它们的真正价值才得以释放——这就是向量检索（Vector Search）。
最初，向量主要服务于搜索和推荐：用户搜一个词，系统需要理解它与商品标题、内容正文之间的语义关系；用户看过一个商品，系统要找出相似款或可能感兴趣的内容。
今天，随着大模型和 RAG 的兴起，向量的应用范围被大幅拓宽——智能问答、图片检索、文档去重、语音意图识别等场景都离不开 Embedding。只要业务需要让系统理解"两段文本是不是同一个意思""两张图是否相似""这个 Query 该匹配哪些知识块"，向量就会进入数据链路。可以说，向量已不仅是搜索推荐的基础设施，而正在成为 AI 时代的通用数据底座。
传统架构下，在大数据处理链路中构建并进行向量检索是一个复杂的过程。数据工程师通常需要：
在数据仓库/外部存储存储并提取原始数据
使用专门的 ML 基础设施生成 Embedding
将 Embedding 加载到独立的向量数据库进行检索匹配
开发自定义管道将检索结果回流到 Maxcompute 进行离线的批量 Join 过滤和分析最终服务于在线场景
对于很多 MaxCompute 客户来说，这条链路的复杂性尤为真切：原始数据在外部对象存储，Embedding 由外部脚本生成，索引构建和相似计算放在独立向量系统，向量匹配结果再回流 MC 做 Join、过滤、评估和回写。
这样的链路能跑通，但跑久了会累 —— 脚本要维护、索引版本要对齐、失败后还要排查是模型、数据、检索还是同步出了问题，多一个模态就多一段处理逻辑。最终形成"碎片化、高成本、高维护"的架构，成为许多团队拥抱向量化的门槛。
MaxCompute 早期的向量检索能力基于达摩院开发的 Proxima CE 向量计算引擎。它以内嵌 JAR 包的形式运行在 MaxCompute 上，底层使用 Proxima 算法库。Proxima CE 能够完成基础的离线向量检索，支持百万级 TopK 查询，但使用流程相当重量级：
环境准备繁琐：需要创建 MaxCompute 项目、创建 DataWorks 工作空间并绑定数据源、单独申请开通 Volume 能力、创建 External Volume 并指定 OSS 内网域名。任何一个环节缺失都会导致作业报错。
平台限制严格：JAR 包基于 Linux 编译，不支持 Windows 和 Mac 平台；odpscmd 命令行工具仅限 Linux 环境使用。
链路割裂明显：向量检索只是独立的一步，检索结果需要额外的管道回流到业务表中做 Join 和过滤；向量化依赖外部脚本或模型服务完成；索引、脚本、结果表分散维护。
多模态无从谈起：仅面向纯向量数据，不支持 BLOB 等多模态对象存储，图文混合检索需要业务侧自行拼接多条链路。
MaxCompute 多模态检索的目标很明确：把多模态对象、向量化、索引、检索、过滤、分析和结果回写，全部放回 MaxCompute 主链路。围绕离线大规模多模态数据处理场景，让客户用熟悉的表、SQL、分区和权限体系完成端到端的向量数据生产和计算。
对比维度 | Proxima CE | Maxcompute多模态检索 |
算法库 | Proxima | VSAG |
数据类型与向量化 | 纯向量（INT8/FLOAT/BINARY），向量化依赖外部脚本或模型调用 | 原生 |
使用流程 | 开通 External Volume → 安装 JAR → 编写 Job脚本 → 结果回流 |
|
SQL 集成 | 检索与后续分析割裂，结构化过滤需业务侧二次处理 |
|
大规模离线处理性能 | 可完成基础检索，但扩展和调优成本高 | 面向批量任务深度优化，以 Proxima CE 同等数据集和召回规模为基线，在已测试的多个业务场景下作业运行时间加速1.27x ~ 5.86x |
运维治理 | 索引、脚本、结果表分散维护 | 统一纳入表、分区、权限、调度、血缘体系 |
MaxCompute 面向多模态检索场景的升级，不仅仅是提供一个VECTOR_SEARCH函数，而是把向量检索从"外部召回步骤"变成"离线数据生产链路的一部分"，从而减少跨系统数据搬运，优化复杂的生产架构。
MaxCompute 多模态检索分层构建了从数据入仓到检索结果产出的完整能力集，包含核心能力如下：
能力层 | 关键功能 | 作用 |
统一存储 |
| 图片、文档、文本、向量放在同一张表里 |
内置向量化 |
| 在 SQL 中完成文本、图片等数据的向量化 |
索引与检索 | 向量索引 + | 批量 TopK 近邻召回 |
业务分析 | SQL Join / 过滤 / 聚合 / 回写 | 检索结果直接接入推荐、广告、搜索、RAG 链路 |
场景问题：图片、文本、文档、OCR、ASR、视频帧和业务标签要一起处理，过去结构化业务数据、非结构化原始数据和向量 Embedding 往往分散在不同系统中，每次模型迭代或数据变更都需要重新同步对齐；
产品能力：MaxCompute 多模态检索支持在同一张表里同时管理结构化字段、多模态对象和向量字段。
CREATE TABLEitem_base( item_id STRING, title STRING, category STRING, brand STRING, price DECIMAL(10,2), stock_status STRING, image BLOB, text_embeddingVECTOR(FLOAT,128), image_embeddingVECTOR(FLOAT,512))PARTITIONEDBY(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 同一张表内完成向量化和存储。
场景问题：真实业务很少只看向量距离。商品召回要看类目、价格、库存、内容安全；广告匹配要看计划、人群、地域、预算；知识库要看租户、权限、文档类型。传统做法是先匹配一个大候选集再过滤——候选集取大了成本高，取小了过滤后结果可能不够。
产品能力：多模态检索把两种数据处理需求统一放到 Maxcompute SQL 链路里处理，先限定业务条件，再对 Query 向量做相似计算，最后继续 Join 商品、用户和实验分组表。VECTOR_SEARCH函数可通过 base/query 子查询分别做过滤，再执行 Base Table 和Query Table之间的离线批量向量检索，业务条件不再是"事后补救"，而是"事前约束"。
SELECTr.query_id, r.item_id, r.distance, i.category, i.brand, i.priceFROMVECTOR_SEARCH( (SELECTitem_id, category, brand, price, text_embedding FROMitem_base WHEREdt='2026-06-22'ANDcategory='3C数码'ANDpriceBETWEEN100AND500ANDstock_status='on_sale'), text_embedding, (SELECTquery_id, query_embeddingFROMquery_embedding WHEREdt='2026-06-22'ANDscene='search_recall'), query_embedding,50) rJOINitem_base iONr.item_id=i.item_idANDi.dt='2026-06-22'ORDERBYr.query_id, r.distanceASC;
场景问题：很多企业的向量检索任务不是"来一条查一条"，而是每天、每小时批量生产：千万级商品相似召回、亿级内容去重、海量 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 语料治理三大方向，展示了Maxcompute多模态检索在不同业务场景下的落地方式。
场景痛点：电商、搜索、推荐和广告链路需要周期性生成商品、内容、广告素材和用户意图的候选集。在原有的架构中通常先需要在外部向量系统召回，再把结果导回数据仓库做过滤、Join 和回写，链路长且候选集质量难控。
MaxCompute 提供的能力：将商品表、行为表、标签表、实验分桶和向量列放在同一套 SQL 链路中处理，支持 Item-to-Item 相似召回、Trigger-Driven TopK 检索，以及类目、价格、库存、地域、人群等业务条件过滤。
业务价值：离线生成“看了又看”“买了又买”、搜推融合召回和广告候选集，线上链路只需合并、去重和重排，降低实时召回压力。
场景痛点：智能座舱数据包含语音 Query、ASR 转写文本、车控指令、导航目的地、座舱图片/视频帧、车辆状态等多种信号。同一意图存在大量口语化、方言化表达，单靠关键词规则很难稳定归类。
MaxCompute 提供的能力：将语音文本、车控标签、图片/视频帧特征和车辆状态字段统一入仓，先按车型、设备、地域、时间窗口等标量条件缩小范围，再做向量相似召回、聚类和 Badcase 对比。
业务价值：离线沉淀意图簇、意图映射表和训练样本表，支持相似 Query 扩增、新意图发现、识别失败样本归因，避免把计算密集型相似度任务放到车端或在线链路中实时完成。
场景痛点：大模型和 RAG 场景需要处理 PB 级文档、网页、图片说明、OCR 文本、问答记录和业务知识。检索结果通常还要叠加租户、权限、业务域、版本、更新时间和质量标签。
MaxCompute 提供的能力：在 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 消耗大幅度优化。
了解更多
（1）VECTOR 数据类型与向量索引：help.aliyun.com/zh/maxcompu…
（2）AI_EMBEDDING 函数：help.aliyun.com/zh/maxcompu…
（3）VECTOR_SEARCH 函数：help.aliyun.com/zh/maxcompu…
（4）多模态存储与 BLOB 类型：help.aliyun.com/zh/maxcompu…
（5）Proxima CE 向量计算（老版本）：help.aliyun.com/zh/maxcompu…