千问 APP × 阿里云：MaxCompute 向量检索重构 RAG 数据收录评估链路，一条SQL将性能提速 11 倍

评估一个领域的数据收得全不全，千问 App数据团队过去要花大半天：导出数据、发版审批、部署常驻服务、等召回跑完。现在，基于阿里云MaxCompute 多模态检索，只需一条提交即跑的数仓 SQL——全链路从约 6 小时 15 分压到约 32 分钟，全程零常驻资源。

业务诉求：从自建向量服务到数仓内批量召回

千问 APP 数据团队负责各领域垂类数据的收集与加工，持续供给 RAG 场景。某领域的数据是否收全，直接决定回答质量的上限，因此团队需要周期性地回答一个问题：各领域数据的覆盖率是多少？

评估方法很直接：以权威数据源为基准抽取一批 query，对向量化后的自有语料做全量向量召回，候选交模型判定命中，命中比例即覆盖率。全流程的关键环节是"全量批量向量召回"——而问题恰恰出在这里。

迁移之前，这一步依赖内部自建的 ude 向量服务。数据在数仓（ODPS）里，召回服务在数仓外，中间隔着导出转换、新建服务、字段配置、发版审批、资源部署等一串环节，一轮评估从准备到出结果，往往要耗大半天。

这条链路带来三方面负担：

·资源常驻：向量服务以固定核数的实例长期部署，即便不做检索时也持续占用资源。

·研发效率受限：发版审批、资源申请、部署等环节串行阻塞、耗时不可控，一轮评估周期长，难以支撑当天多轮迭代。

·数据要出仓：向量数据经由额外链路流出数仓，权限与安全管理的复杂度随之增加。

所以团队要的不是简单换一个检索引擎，而是同时要三样东西：能承载全量批式向量召回的引擎能力；足够低的检索成本，以支撑高频甚至全量重跑；能与既有自研数据处理与向量化链路衔接，无需为迁移重写流程。

解决方案：MaxCompute 离线向量检索承接批量召回

千问 APP 数据团队与阿里云大数据 AI 平台共同梳理了数据链路，形成"自研链路负责数据加工与向量化、MaxCompute 负责存储与批量检索"的分工。

上游，一行不改。 原始数据存储在 OSS / ODPS，由 Python 脚本或 Ray 调用模型实例完成数据处理与向量化，产出的 embedding 直接写入 ODPS 表——这条链路在迁移前后完全不变。

检索，收进一条 SQL。 向量存储、索引构建与全量批式检索三个环节由 MaxCompute 离线向量检索统一承接，"导出转换 + 服务化部署"的整段工程工作被抹掉，收敛为四个动作（SQL 示意）：

2.1 建表

2.2建索引

2.3导入向量数据并建索引

2.4批量召回

除首次建表建索引外，此后每一轮评估都是"提交即跑"的周期性 SQL 作业：没有审批排期，没有部署等待，数据始终留在数仓内，复用现有权限体系。

合作成效：让覆盖率评估从"重工程"回到"轻查询"

专业文档场景实测（base 约 2400 万 × query 约 120 万）：

*注：表中 1100+ QPS 为批量作业的等效吞吐，用于与批量场景对比，不代表在线服务能力；在线毫秒级点查场景请使用专业向量服务。*

全链路口径的提速，一方面来自索引构建与检索本身的性能提升，另一方面来自导出转换、审批部署等流程环节的彻底消除。

成本结构也随之改变：固定常驻实例换成按量弹性作业，"不用也要花"变成"用多少花多少"。相同预算下，同一领域的覆盖率评估可以更高频地重跑，新增垂类也能低成本接入同一套链路。

迭代方式同样变了。仍以专业文档领域为例：外部权威文档条目清单约百万行作为 query 集，自有文档向量千万条作为 base 集，每条 query 召回 top10 交模型判定，命中比例即覆盖率。升级 embedding，重灌 base 表，一条 SQL；调整 query 集，重落 query 表，一条 SQL；检索结果十几分钟返回，当天即可完成多轮评估。"发现缺口 → 补充数据 → 再评估"的循环，第一次真正转了起来。

“以前一轮评估要经历导出转换、发版审批、资源部署一连串环节，常驻实例的成本也长期摆在那里。现在批量向量检索收敛成了数仓里的一条 SQL 作业——数据不出仓，索引由平台自动维护。我们希望把它推广到更多垂类和更大规模，让覆盖率评估成为可持续、低成本的常规动作。”—— 千问 APP 数据团队

目前该方案已在生产上线，新垂类沿用同一架构；团队还在 亿级向量的全量规模上验证了链路可行性——规模越大，相较常驻服务方案的优势越明显。

展望

覆盖率评估只是这套向量检索能力的起点。随着法律、财经、学术等更多垂类陆续接入同一套架构，数仓内批量召回正在从单一的评估动作，延伸为数据建设各环节的通用底座——无论是训练数据集构建中的 corner case 圈选、候选集的批量生产，还是新增数据的相似性排查，都可以复用同一条 SQL 链路，而无需为每个场景单独搭建和维护向量服务。

对千问 APP数据团队而言，把大规模批量检索交给平台承接之后，团队得以将精力集中在真正构成差异化的环节——垂类数据的理解、加工与向量化质量上。对阿里云大数据 AI 平台而言，这一实践也在持续反哺产品能力：大表索引分片调度参数的沉淀，正推动向量检索在超大规模场景下的易用性完善。双方将围绕检索性能、规模上限与场景覆盖持续联合打磨，让"在数仓里批量找相似"成为一种低门槛、可持续的常规能力。

免责声明：该文章系本站转载，旨在为读者提供更多信息资讯。所涉内容不构成投资、消费建议，仅供读者参考。