在人工智能与搜索引擎深度融合的浪潮中，阿里云AI搜索负责人邢少敏深度解析了Agentic RAG技术，揭示了如何通过创新架构实现高性能搜索与智能问答。以下教程将带你系统学习阿里云AI搜索的双产品线布局、Agentic RAG关键技术实现、产品落地实践以及未来演进路径。

内容概览

• 阿里云AI搜索双产品线布局：开源Elasticsearch与自研OpenSearch的技术演进
• Agentic RAG关键技术实现：向量检索、LLM融合与智能问答系统
• 从高性能搜索引擎到AI赋能的完整进化路径与未来展望

一、阿里云AI搜索简介

产品线布局

阿里云AI搜索拥有两条主要产品线，分别是开源的Elasticsearch产品线和自研的OpenSearch产品线，两者相互补充，共同为企业提供多层次的搜索解决方案。

开源Elasticsearch产品线

2018年，阿里云与Elastic达成战略合作，将Elasticsearch引入阿里云平台进行托管售卖。在合作过程中，阿里云对Elasticsearch进行了一系列增强和优化。

• Indexing Service：将写入操作单独拆分，实现写入和查询分离，提高并发处理能力和查询性能。
• OSS替代磁盘：在日志场景中使用对象存储服务（OSS）作为存储介质，降低存储成本，并通过增加缓存机制优化读写性能。
• Serverless架构：实现高性能读写分离、智能弹性扩缩等能力。
• AI搜索功能：提供向量检索、LLM+搜索、RAG问答以及AI Assistant等功能。

自研OpenSearch产品线

自研的OpenSearch产品线经历了三个阶段：

• 高性能搜索引擎阶段（2008-2020年）：基于C++开发，无JVM抖动问题，支持节点内外并行处理，在线离线天然隔离，提供毫秒级实时索引。例如，在阿里电商场景中新商品上架后毫秒级可被搜索到。
• 语义搜索阶段：引入NLP模型和排序模型，支持行业级和场景级定制，用户只需上传数据即可自动训练分词器等模型。
• 基于大模型的搜索阶段：探索文本向量混合检索、多模态检索、Agentic RAG、Graph RAG等技术。

小提示：开源引擎采用Apache 2.0许可证可商用，已有客户（如作业帮）使用后计算资源减少50%。

二、Agentic RAG关键技术解读

RAG技术演进

RAG（检索增强生成）技术经历了多个阶段：

• Native RAG（2023年初）：仅能在演示场景使用，效果不理想。
• Advanced RAG：优化文档解析链路（如PDF、PPT不同策略），采用多维度切片，添加ReAct技术，可用于非严谨业务场景。
• Modular RAG：将文档解析、切片、索引等拆分为原子服务，通过API调用，满足客户按需使用。
• Agentic RAG：解决复杂多跳问题。单Agent（1.0）整合规划与生成；多Agent（2.0）拆分为规划Agent、SearchAgent、DB Agent、Graph Agent、澄清Agent等，支持多路检索。

重点：多跳问题需要通过多个步骤推理和检索才能得到答案，如“苹果公司创始人还创办了哪些公司”。

Agentic RAG 1.0架构与效果评估

架构：将Agent规划模型和RAG生成模型整合为一个模型，同时负责生成回答和规划拆解。

效果评估：在HotpotQA数据集上，召回率提升约20%，解答率提升约11%；在Musique数据集上召回率提升85-120%，解答率提升53-98%。

Agentic RAG 2.0改进与优势

• 改进点：将单Agent拆分为多Agent，增加数据库和图数据检索链路。
• 效果与优势：每个Agent专注特定任务，提高处理效率；多路检索提升全面性和准确性。

小提示：目前Claude仍然是效果最好的规划Agent模型。

阿里云AI搜索 MCP Servers

MCP（Model Communication Protocol）协议统一了不同大模型对底层引擎的调用方式。阿里云AI搜索全面基于MCP协议运行，Agent通过MCP Server直接调用向量引擎、数据库等，简化了开发维护。

应用示例：用户提问“阿里云OSS上传文件”，Agent先澄清具体操作方式（API或控制台），确认后由Search Agent通过Elasticsearch检索产品文档生成答案。

Graph RAG

除了Agentic RAG，阿里云还并行研究Graph RAG。两者区别：

• Agentic RAG：通过Agent规划拆解任务，多次检索，增加在线耗时。
• Graph RAG：预先构建知识图谱，离线复杂度高，在线查询快，一次检索即可获取结构化三元组。

阿里云AI搜索 Graph RAG优化：采用向量数据库存储知识三元组，避免自然语言到图数据库查询语言的转换错误。产品提供开关配置，用户可根据性能敏感度选择Graph RAG（离线慢、在线快）或Agentic RAG（离线快、在线稍慢）。

多模态搜索-文搜视频

应用于某头部生活服务APP的视频搜索功能。处理流程：

• 原始元数据（标题、描述、类目等）直接索引。
• 视频内容拆分为视频流和音频流，分别用通义千问VL模型生成文本描述、自研主体识别提取焦点对象、多模态模型向量化。
• 混合召回策略结合点击率评分排序。

阿里云AI搜索专属大模型

基于SOTA模型基座微调，涵盖：文档解析模型、多模态向量化模型、规划Agent模型、NL2SQL模型（NL2Opensearch、NL2Elasticsearch等）、Reranker模型、RAG生成大模型。向量化模型曾在中文向量化榜单获得第一名。

模型优化与向量降维技术

通过降维（如1024维压缩至512维）保持效果不变，大幅减少计算资源。Rerank模型基于1.5B参数已超越流行模型。

NL2SQL技术应用

解决自然语言到数据库/搜索引擎查询（ES DSL）的转换问题，已在申通物流场景应用，相关算法在BIRD榜单获得第一名。

生成模型优化

基于千问14B参数模型优化后，综合评分与幻觉率接近GPT-4o基准水平。团队也在探索MoE架构。

向量检索技术突破

量化技术（BBQ）

• 背景：ES 8.9版本后向量检索性能提升，815之后进入第一梯队。
• BBQ方案：采用RabitQ量化，1024维向量每维压缩至1位。百亿向量存储从37T内存、170节点降至9节点；通过召回Top 2500重排缓解召回率下降。

GPU加速检索

• 索引构建：5台GPU服务器可替代100台CPU服务器，性价比显著。
• 查询阶段：H100可实现20-30倍加速，但硬件成本高。经核算，只有当QPS达到2000-3000时GPU与CPU成本持平，因此采用混合架构：索引构建用GPU，查询用CPU。

重点：GPU加速在经济性上更适合索引构建阶段，而非在线查询。

三、Agentic RAG产品落地

产品落地情况概述

阿里云提供两大搜索产品线（Elasticsearch和OpenSearch），产品形态分为：

• 低代码产品形态：通过平台配置即可实现AI搜索功能（如RAG），支持多种数据源接入，适合快速部署。
• 高代码产品形态：以API形式开放核心功能，用户可通过编程自由组合，适合深度定制。

核心功能与集成方案

• 与Elasticsearch深度整合：支持RAG配置（通过Pipeline、Inference API）和AI Assistant（基于Agent的智能运维）。
• 自研智能问答产品：OpenSearch智能问答版，仅需上传文档即可上线，支持多模态检索（如视频定位、网页爬取）。

技术架构与部署流程

平台分为三层：

• 数据层：支持结构化数据库和非结构化文件接入。
• 服务层：提供文本处理、向量化、检索、大模型调用等子服务。
• 应用层：基于自研引擎或Elasticsearch实现搜索场景，支持与大数据产品一键集成。

四、未来发展方向

阿里云搜索产品将持续聚焦：

• Agent与搜索的深度结合：推动Deep Search、多Agent架构。
• 基础设施优化：GPU加速、向量索引量化。
• 大数据融合：与大数据平台协同，实现搜索功能一键接入。
• 开源生态扩展：兼容LangChain、Llamaindex、DeepSeek等，推进MCP协议标准化。

五、常见问题（Q&A）

1. 问：在规划Agent的测试阶段，您建议优先选择性能最佳的模型（如Claude3.5和通义千问Plus），还是成本更低的模型？

   答：目前可能还未到需要考虑成本的阶段。当前很多基于深度搜索实现的规划Agent，虽然效果有所提升，但实际表现距离理想目标仍有差距。因此在现阶段，建议尽可能使用性能更优的模型来确保效果。只有先验证出有效方案后，后续阶段才需要考虑成本优化问题。如果模型效果本身不达标，成本问题便无实际意义。

2. 问：阿里云当前的PDF解析模块是基于传统PDF解析方法，还是采用了类似CoPPa这样的模型技术？

   答：我们尝试过两种方法。最初阶段主要基于开源PDF解析工具，并在此基础上结合工程化处理策略进行优化。后续尝试引入视觉模型提取文档布局信息，但发现当处理大量文档时，模型解析速度显著下降，无法满足产品性能需求。因此，目前主要采用工程化方法为主，通过细化规则引擎实现高效解析，模型处理部分结构提取问题。

3. 问：您提到解决多跳问题和复杂问题有两种思路：多Agent与知识图谱（如Graph RAG）。我的理解是否正确？即多Agent方法建议将知识库或向量库中的三元组/关系链路进行维护，从而通过这种模式解决复杂问题？

   答：是的。目前实际应用中，Graph RAG与ReAct两种方法在解决多跳问题时效果相近，但Graph RAG的索引构建效率较低。例如在处理约65万文档时，我们曾尝试过需要一天时间仍未完成索引构建，存在优化空间。因此当前产品实践中，更倾向于优先采用多Agent或单Agent模式处理复杂问题。但在特定场景下仍会使用Graph RAG：当文档规模较小且更新频率低时，其离线构建的高成本可被接受，适合数据相对静态的场景。若文档规模庞大、更新频繁，则多Agent方案的实时性与扩展性更具优势。

4. 问：阿里云推出了两个产品：Opensearch NL2SQL和Chat to DB。请问在选型时，这两个产品的优劣势分别是什么？它们分别适用于哪些应用场景？

   答：这两个产品在设计定位上有明显差异。Chat to DB专注于数据库（DB）场景，而Opensearch NL2SQL是一个更广泛的语言转换框架。

   • Chat to DB：专注数据库查询，能精准理解SQL语义，生成符合标准的SQL语法。适合需要直接通过自然语言操作关系型数据库的场景，如数据分析、报表生成等。
   • Opensearch NL2SQL：支持多数据源，包括ES DSL转换（NL2ES）、Opensearch DSL转换（NL2Opensearch）、图数据库（NL2Gremlin）、SQL变种适配。适合需要跨搜索、图数据库、关系型数据库等多引擎查询的复杂场景。

   关键差异：Chat to DB是数据库专用工具；Opensearch NL2SQL是自然语言到多种数据引擎DSL的通用转换框架。

5. 问：在AI搜索项目的交付过程中，涉及哪些关键角色？这些角色如何协作确保项目成功交付？

   答：目前交付流程主要分为两类场景：

   • 一站式需求场景：客户提供数据，全程由平台处理。角色包括数据工程师（负责数据接入、治理和基础搜索部署）和算法工程师（在默认配置不满足时介入模型优化）。
   • 模块化需求场景：客户仅使用部分功能。客户通过API自助集成，技术支持团队排查参数配置问题。深度定制时需客户提供数据/标注数据，由数据分析师评估数据质量，算法工程师定制模型，周期约1周。

   所有场景均通过标准化产品和模块化设计降低人工介入成本。

6. 问：在AI搜索的应用场景中，是否遇到过难以应对的特殊需求？例如市场部提出的舆情监控需求，想听听您的看法。

   答：关于舆情监控的具体需求，我们目前尚未涉及。不过我们曾处理过一个对AI搜索提出极高要求的医疗健康领域项目。用户需要系统准确回答疾病诊断和用药建议，且要求100%零误差。然而在实际操作中，医疗数据不断更新变化，临床指南持续迭代，此外还有患者个体差异等复杂因素，导致完全消除风险存在客观困难。因此，对于要求绝对零失误的场景，目前AI技术的应用确实存在局限性。

7. 问：在选择大模型时，主要考虑客户的数据结构复杂性、数据源规模等要素，还是依据业务场景的具体需求？例如，我们在选择通义千问等不同模型类型时，如何根据业务场景的容错率和数据特点进行选择，并获得相应的算力建议？

   答：在数据结构复杂性方面，数据格式的复杂度越高，越能体现产品的价值，但这一因素并非主要考量。核心依据是业务场景的具体需求。例如，对容错率要求较低的业务，更适合选择效果最优的模型；对错误敏感的场景，则需选择幻觉率较低的模型。在模型微调过程中，重点在于降低幻觉率，而非追求效果提升，因为基础模型的效果已由其本身决定。在算力方面，目前我们的云服务产品尚未遇到显著瓶颈。当前主要挑战在于场景适配的优化，而非算力不足。若未来所有场景均需高性能模型且需求激增，届时可能面临算力压力，但目前尚未达到这一阶段。

结语

通过以上系统解析，我们全面了解了阿里云AI搜索在Agentic RAG技术上的创新与实践。从双产品线布局到多阶段技术演进，从向量检索优化到多Agent协作框架，再到丰富的产品落地形态，阿里云正持续推动搜索与AI的深度融合。未来，Agent与搜索的深度结合、基础设施优化以及开源生态扩展将是关键方向。