阿里云AI搜索Agentic RAG技术实践

产品线布局

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

开源Elasticsearch产品线

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

Indexing Service的引入是其中的一项重要举措。在传统的Elasticsearch架构中，写入和查询操作都在同一个节点上进行，当写入流量过大时，会严重影响查询性能。阿里云通过引入Indexing Service，将写入操作单独拆分出来，实现了写入和查询的分离，大大提高了系统的并发处理能力和查询性能。

在日志场景中，阿里云使用OSS（对象存储服务）替代磁盘作为存储介质，降低了存储成本。同时，为了减少OSS带来的延迟，阿里云通过增加缓存机制，优化了数据的读写性能。

随着技术的不断发展，阿里云的开源Elasticsearch产品实现了Serverless架构，具备了高性能读写分离、智能弹性扩缩等能力。

在进入AI搜索时代后，开源Elasticsearch产品线又提供了向量检索、LLM+搜索、RAG问答以及AI Assistant等功能。

自研OpenSearch产品线

自研的OpenSearch产品线是阿里云在搜索技术领域的重要创新成果，其发展历经三个阶段，每个阶段都有其独特的技术特点和应用场景。

高性能搜索引擎阶段（2008 - 2020年）

这一阶段主要聚焦于性能提升，旨在支撑阿里集团内部上千业务的搜索需求。当时，阿里集团的业务规模不断扩大，搜索系统面临着日均PV百亿、双十一百万QPS、实时数据更新百万TPS、千亿数据毫秒级响应以及可用性5个9的严格要求。为了满足这些需求，阿里云自主研发了基于C++的高性能搜索引擎。

与基于Java的搜索引擎相比，基于C++的搜索引擎没有JVM（Java虚拟机）抖动问题，因此线上的抖动几乎为零，保证了系统的稳定性。同时，引擎在节点内部和节点之间都支持并行处理，此外，引擎的在线和离线是天然隔离的，拥有独立的离线索引构建系统，提供天级全量、小时级增量和实时索引构建，时效性可达毫秒级。例如，在阿里集团的电商搜索场景中，当新商品上架后，通过实时索引构建功能，商品信息可以在毫秒级被搜索到，保证了用户能够及时获取最新的商品信息。

2022年11月，阿里云将该自研引擎开源，并在2023 - 2024年持续进行迭代。该引擎采用Apache 2.0许可证，可商用，吸引了众多企业和开发者的关注。在一些客户实践中，开源引擎取得了显著的效果。例如，作业帮使用该开源引擎替换原有引擎后，搜索集群的计算资源减少了50%，大大降低了运营成本。

语义搜索阶段

在高性能搜索引擎的基础上，阿里云引入了语义搜索技术，旨在为用户提供更智能、更精准的搜索体验。语义搜索技术主要基于NLP（自然语言处理）模型和排序模型，支持行业级和场景级定制。

行业级定制可面向电商、教育、游戏等不同行业提供全链路模型定制。场景级定制允许客户上传自己的数据，自动训练定制的分词器等NLP模型和排序模型。客户只需要将数据上传到产品，系统就会自动进行模型训练，整个过程无需工程师过多介入。

语义搜索阶段的产品架构在引擎的基础之上，增加了很多算法模块，如分词、实体识别等，这些模块都可以支持用户定制。用户只需要上传数据，就可以根据自己的需求对这些模块进行定制。然而，构建数据需要一定的成本，这也是用户在使用语义搜索技术时面临的一个挑战。

基于大模型的搜索阶段

随着大模型技术的兴起，阿里云积极探索基于大模型的搜索技术，开展了文本向量混合检索、多模态检索、Agentic RAG、Graph RAG等技术研究。在这一阶段，阿里云的开源产品和自研产品并行推进，共同探索基于大模型的搜索应用场景。

RAG技术演进

RAG（Retrieval Augmented Generation）技术是一种将检索和生成相结合的技术，通过从外部知识库中检索相关信息，并结合大模型进行生成，能够提供更准确、更详细的回答。RAG技术的发展经历了Native RAG、Advanced RAG、Modular RAG和Agentic RAG等阶段。

Native RAG

2022年底，ChatGPT的出现引发了全球范围内的人工智能热潮，阿里云搜索团队迅速跟进，在2023年春节后推出了较为原始的Native RAG。Native RAG的基本架构是在搜索系统后端添加大模型，前端进行文档解析。

然而，Native RAG的效果并不理想，只能用于演示，无法在实际业务场景中应用。主要原因在于，Native RAG的文档解析和检索过程比较简单，无法准确地理解用户的问题和文档的内容，导致检索到的文档相关性较低，生成的回答质量也不高。

Advanced RAG

为了改进Native RAG的不足，阿里云搜索团队对文档解析链路进行了精细化优化，针对不同类型的文档，如PDF、PPT等，开发了不同的解析策略，能够更准确地提取文档的内容和结构信息。比如在解析PDF文档时，通过分析PDF的Meta格式、版面信息，分别提取文本、图片、表格等内容。在切片方面，采用多维度切片方式，将文档按照段落、句子等维度进行切片，提高了文档的检索粒度和准确性。在后置链路中，团队添加了ReAct等技术，增强了系统的推理和决策能力。

经过这些改进，Advanced RAG可以在一些非严谨业务场景中使用。

Modular RAG

随着客户对RAG技术的逐渐熟悉，部分客户希望能够按需使用某些模块，而不是使用整个RAG系统。为了满足客户的需求，阿里云将文档解析、切片、索引等服务拆分为原子服务，搭建了一个平台供客户通过API调用。

客户可以根据自己的需求，选择使用不同的原子服务，并通过API进行集成。这种模块化的设计方式为客户提供了更大的灵活性和自主性，客户可以根据自己的业务需求和技术能力，选择适合自己的服务和模块。目前，这类客户已经成为阿里云RAG产品增长最快的用户群体。

Agentic RAG

2024年下半年，为了解决复杂的多跳问题，阿里云引入了Agentic RAG技术。多跳问题是指需要通过多个步骤的推理和检索才能得到答案的问题，例如，在知识问答场景中，用户可能会问“苹果公司的创始人是谁，他还创办了哪些其他公司”，这类问题需要先检索到苹果公司的创始人，然后再检索该创始人创办的其他公司，需要多个步骤的推理和检索才能得到答案。

最初，阿里云采用了单Agent系统，即一个Agent负责解决所有的问题，包括规划、拆解问题、执行和生成回答等。然而，在实际应用中，发现单Agent系统存在一些问题。由于一个Agent需要同时处理多个任务，在每个任务上都无法做到极致。例如，在生成答案时，可能会因为要兼顾规划和拆解问题的能力，导致生成的答案质量不高。

为了解决这些问题，阿里云将单Agent拆分为多Agent，形成了多Agent系统。在本次分享中，为了区分，将单Agent系统称为Agentic RAG 1.0，多Agent系统称为Agentic RAG 2.0（DeepSearch深度搜索）。

Agentic RAG 1.0架构与效果评估

架构

Agentic RAG 1.0的架构在实现时将Agent规划模型和RAG生成模型整合为一个模型，该模型既负责生成回答，又负责规划和拆解问题。在处理用户的问题时，系统首先将问题输入到Agent规划模型中，模型会根据问题进行推理和检索，然后调用生成模型生成回答，最终输出给用户。

这种架构对多跳问题有显著的效果提升。例如，在一些复杂的知识问答场景中，Agentic RAG 1.0可以通过推理和检索，找到多个相关的文档，并将这些文档进行整合和分析，生成更准确、更详细的回答。

效果评估

为了评估Agentic RAG 1.0的效果，阿里云使用了HotpotQA和Musique等评测数据集进行测试。在HotpotQA数据集上，Agentic RAG 1.0相比标准RAG，召回率提升约20%，解答率提升约11%。

在Musique数据集上，由于标准RAG的基线率较低，Agentic RAG 1.0的提升幅度更大，召回率提升约85 - 120%，解答率提升约53 - 98%。这表明Agentic RAG 1.0在处理复杂的多跳问题时，具有更强的推理和检索能力，能够生成更准确、更详细的回答。

Agentic RAG 2.0改进与优势

改进点

Agentic RAG 2.0相对1.0主要有两个改进。

一是将单一Agent拆分为多个各司其职的Agent，包括规划Agent、SearchAgent（向量文本搜索）、DB Agent（数据库查询）、Graph Agent（图检索）和澄清Agent等。

二是增加了数据库和图数据的检索链路，形成了多路检索架构。在Agentic RAG 1.0中，主要使用文本和向量混合检索，无法充分利用数据库和图数据中的信息。而在Agentic RAG 2.0中，通过增加数据库、图数据和联网搜索的检索链路，可以将数据库、图数据以及网络数据中的信息纳入到检索范围中，提高了检索的全面性和准确性。

效果及优势

Agentic RAG 2.0通过Agent拆解，使每个Agent专注于特定任务，提高了各环节的处理效率和质量。

多路检索架构能够充分利用不同类型的数据，提升了搜索的全面性和准确性。在处理复杂问题时，Agentic RAG 2.0可以同时从文本、向量、数据库和图数据中检索相关信息，并将这些信息进行整合和分析，生成更准确、更详细的回答。

相比Agentic RAG 1.0提升效果不是很明显，一方面是目前测试都忽略简单问题，主要针对多跳问题，多跳问题在Agentic RAG 1.0中已经解决了一大部分。另外一个观察是作为规划Agent，Claude 仍然是目前效果最好的一个模型。

阿里云AI搜索 MCP Servers 

在构建多Agent协作系统时，每个Agent均基于大模型运行，需调用底层引擎（如向量引擎、数据库、文本引擎及API接口）。然而，不同模型对底层引擎的调用协议存在显著差异，比如各个厂商的大模型有自己的调用格式，不同大模型协议互不兼容，导致初期开发需投入大量资源处理协议适配问题。

为应对这一挑战，MCP（Model Communication Protocol）协议被引入并逐渐成为行业标准。随着数据库、引擎等组件逐步实现对应的MCP服务端（MCP Server），系统架构得以简化，Agent不再需要针对不同模型开发兼容逻辑，而是统一通过MCP协议直接调用各引擎的MCP Server。目前，阿里云AI搜索已全面基于MCP协议运行，显著降低了开发与维护的复杂度。

以下为Agentic RAG应用示例，展示Agent协作流程：
用户提出需求“阿里云OSS上传文件”，表述较为模糊。Agent首先询问用户澄清具体操作方式（API或控制台）。用户确认使用控制台后，Agent进一步确认是否指阿里云管理控制台，确保需求准确无误。用户确认后，任务由Search Agent处理：它通过调用Elasticsearch工具检索预先导入的产品文档，生成最终答案，整个过程由多个Agent协作完成。

Graph RAG

在解决多跳或复杂问题时，我们采用了Graph RAG与Agentic RAG两条路径并行的研究方案。针对需要多步检索的问题，Agentic RAG通过Agent规划拆解任务，结合多次检索与校验，利用增加在线链路耗时的方式逐步解决问题。而Graph RAG则通过预先构建知识图谱增加离线复杂度和时间，实现快速在线查询，通常一次检索即可获取所需信息。

在技术实现上，两种方法的关键区别在于检索结果的形式：Agentic RAG返回文档片段供大模型总结，而Graph RAG通过知识图谱检索出实体关系三元组，直接提供结构化数据给生成模型使用。在版本迭代中，1.0版本中Graph RAG与Agentic RAG并行开发，而2.0版本则将Graph RAG整合进系统，优化了整体架构。

关于Graph RAG的原始方法（如微软相关论文），其核心流程包含离线阶段的文档切片处理，从每个切片中提取实体关系三元组，构建全局知识图谱，并通过社区检测与聚类进行知识整合。最终检索时仅需将结果传递给大模型生成答案。然而，该方法落地实现难度较高且步骤繁琐，需进一步简化以提升实用性。

阿里云AI搜索 Graph RAG

技术方案优化 原计划采用图数据库方案，但实际实施中发现存在以下问题：

• 引入图数据库会增加技术栈复杂度

• 需要实现自然语言到图数据库查询语言的转换，存在转换错误率

最终改用向量数据库方案：

• 直接将知识三元组存储于向量数据库

• 省去自然语言到图数据库查询语言的转换步骤

• 在保证同等检索效果的同时，降低了实现复杂度和错误率

产品设计优化

提供两种技术方案的动态选择机制：

• Graph RAG方案： • 离线阶段需花费较长时间（单文档建图需数小时）构建知识图谱 • 在线查询响应速度更快，适合对在线性能敏感的场景

• Agentic RAG方案： • 离线处理时间短，适合需要快速部署的场景 • 在线查询耗时相对较高，但整体技术实现更简单

产品设计中设置开关式配置选项，允许用户根据实际需求选择：

• 性能敏感型用户：优先选择Graph RAG方案（将时间成本转移至离线阶段）

• 效率优先型用户：选择Agentic RAG方案（降低离线处理时间要求）

多模态搜索-文搜视频

该方案基于多模态搜索技术，最初应用于某头部生活服务APP的视频搜索功能（类似抖音的短视频模块）。系统通过以下流程处理视频内容：

• 数据分类处理

• 原始元数据（标题、描述、类目、标签、时间等）直接输入文本搜索引擎进行索引

• 视频内容拆分为视频流与音频流进行分别处理

• 视频流处理流程

• 采用通义千问VL模型生成视频内容的文本描述

• 通过自研主体识别技术对视频帧进行主体分析，提取视频焦点对象（如人物、商品等关键元素）

• 以多模态模型对音频及视频帧进行向量化

本方案采用多模态模型对输入数据进行向量化处理，涵盖音频与视频帧的特征提取。具体流程为：首先将结构化文本数据存入文本引擎，多模态向量数据存入向量引擎，随后通过混合召回策略进行检索，并结合点击率（CTR）评分综合排序，最终输出搜索结果。该方案前端部署了规划Agent，负责解析用户查询并拆解复杂问题。

阿里云AI搜索专属大模型

在模型架构设计中，引入了多种不同功能的Agent，每类Agent均基于独立的大规模预训练模型构建。同时，系统中的离线处理模块（如文档解析、多模态特征提取等）均采用深度学习模型驱动。通过长期针对搜索场景的专项微调优化，已形成完整的模型体系，涵盖：

1. 文档解析模型：用于提取结构化信息与图文内容；

2. 多模态向量化模型：实现文本、图像、音频的统一向量表征；

3. 规划Agent模型：支持复杂查询的语义理解与任务拆解。

4. NL2SQL模型：针对不同产品的查询语法有NL2Opensearch、NL2Elasticsearch等。

5. Reranker模型：基于通义qwen的搜索微调reranker模型。

6. RAG生成大模型：基于通义qwen的RAG总结生成大模型。

该模型体系经过多轮迭代与工程优化，显著提升了多模态搜索的准确性和效率。

我们并没有构建基础模型，而是选择SOTA模型作为基座。基于这些模型，使用脱敏数据及自主收集的公开数据在特定场景上进行微调，其中向量化模型在2024年3月基于bge-m3模型上微调，曾在中文向量化榜单取得第一名。2025年3月在腾讯Conan和阿里GTE模型基础上微调，目前也实现了性能小幅提升，相关优化工作仍在持续进行中。

模型优化与向量降维技术

在模型微调方面，通过降维操作显著降低了计算成本。比如将原始1024维向量压缩至512维，在保持效果不变的前提下，计算资源消耗将大幅减少。此外，Rerank技术在模型优化中取得显著进展：2024年8月，基于1.5B参数量的模型在与流行模型bge-reranker-larger的对比中实现性能超越；2025年3月进一步融合Embedding模型，进一步提升了效果。

NL2SQL技术应用

NL2SQL技术解决了自然语言到数据库和搜索引擎查询（如ES DSL）的转换问题，支持复杂搜索场景的生成。该技术已成功应用于申通的物流场景，相关算法和模型并在2024年8月的BIRD榜单中获得第一名。

生成模型优化

针对生成模型的改进聚焦于降低幻觉率与提升场景效果。实验表明，基于千问14B参数量的模型经过优化后，综合评分与幻觉率已接近GPT-4o基准水平。选择14B模型作为部署方案，在性能与资源消耗间可以取得较好平衡。目前团队也开始探索MoE架构模型的优化方法。

向量检索技术突破

量化技术（BBQ）

• 背景：Elasticsearch（ES）8.9版本前向量检索性能不足，8.9版本后性能显著提升，815之后跻身行业第一梯队。

• BBQ量化方案：针对百亿级数据场景，采用RabitQ量化技术（ES社区实现），将1024维向量每维从32位压缩至1位：

• 成本优化：100亿向量存储从37T内存、170节点降至9节点；

• 效果补偿：通过召回Top 2500后重排策略，缓解量化导致的召回率下降问题（从50%提升至接近原始水平）。

GPU加速检索

在向量索引构建环节，GPU展现出卓越的性价比优势。以典型场景为例：若传统方案需部署100台CPU服务器完成索引构建任务，采用GPU加速后仅需5台GPU服务器（按照性能提升20倍计算），即可实现同等算力。从成本维度分析，5台GPU服务器的硬件采购与运维费用显著低于100台CPU服务器集群，且GPU并行计算特性可大幅缩短任务执行时间，进一步降低时间成本。因此，在索引构建阶段，GPU方案的综合成本效益优势十分突出。

GPU性能与经济性的权衡挑战

在查询性能优化方面，尽管采用NVIDIA H100等高端GPU可实现20-30倍的吞吐量提升（与CPU方案对比），但其硬件成本的陡增可能影响商业部署的可行性。具体而言：

• 性能提升：H100在复杂查询场景中可实现最高达30倍的加速比；

• 成本考量：H100的单卡价格远高于通用CPU服务器，需通过业务收益（如响应速度提升带来的用户增长、资源利用率优化等）进行成本效益核算，方能验证其商业部署的合理性。

当前该对比分析基于NVIDIA官方技术数据及实验环境验证结果，后续需结合具体业务场景进一步评估ROI（投资回报率）。

自研Vector Store系统的GPU加速实践

在自研的Vector Store分布式存储系统中，我们通过早期GPU架构适配与持续迭代，实现了以下突破：

异构算力分层优化

• 基础级GPU（如T4）：向量索引查询性能提升3-6倍；

• 高性能GPU（A100/A800/H100）：查询吞吐量提升达30-60倍，与NVIDIA官方基准测试结果高度吻合。

技术演进路径

• Vector Store系统基于原有分布式存储架构（如传统键值/列式存储）进行深度优化，重点突破了以下方向：

• 向量检索算法的GPU并行化重构（如IVF-PQ倒排索引加速）；

• 存储-计算一体化架构设计，减少CPU与GPU间的数据搬运开销；

• 动态负载均衡机制，适配不同规模GPU集群的弹性调度需求。

在成本效益分析中存在一个关键考量：通过核算发现，当在线查询QPS达到2000~3000时，GPU与CPU的使用成本才能持平。这意味着只有当客户QPS超过2000~3000时，采用GPU方案才能有性价比优势。然而，如此高QPS需求的客户数量非常有限，这使得GPU在查询阶段的大规模应用面临挑战。

相比之下，在索引构建阶段，仅需使用成本较低的A10 GPU即可实现数十倍的效率提升，这一阶段的GPU投入具有显著效益。因此，我们当前的策略是采用混合架构方案：在索引构建阶段通过GPU加速大幅缩短处理时间，而在查询阶段改用CPU处理。这种设计既能充分发挥GPU在高计算密度任务中的优势，又避免了在低QPS场景下的资源浪费，从而在整体上实现性能与成本的最佳平衡，为客户提供更具竞争力的解决方案。

产品落地情况概述

阿里云提供了两大搜索产品线：Elasticsearch（开源产品）和Opensearch（自研产品），二者均支持不同场景的需求，产品形态具体分为以下两类形态：

1. 低代码产品形态

面向快速部署场景，用户仅需通过平台配置即可实现AI搜索功能（如RAG）。该产品支持多种数据源接入（包括OSS、HDFS等文件存储及各类数据库），并提供开箱即用的子服务模块，适用于对开发能力要求较低的企业或团队。

2. 高代码产品形态

针对深度定制需求，产品将核心功能以API形式开放，用户可通过编程（如Python、Java等）或开发框架（如LangChain）自由组合API接口，构建端到端的搜索场景。此类形态适合具备技术开发能力且灵活性要求高的用户。

3. 核心功能与集成方案

1. 与Elasticsearch的深度整合

• RAG（检索增强生成）支持：在ES基础上实现离线/在线检索与大模型调用的流程配置，用户可通过定义Pipeline、配置Inference API等方式快速部署智能搜索服务。

• AI Assistant：作为ES的智能辅助组件，提供索引诊断、数据操作及分析功能，其底层基于Agent技术实现自动化运维支持。

2. 自研智能问答产品

Open Search智能问答版是当前门槛最低的解决方案，具备以下特点：

• 快速部署：仅需上传文档（支持PDF、PPT、视频、JSON等格式）并完成测试即可上线。

• 多模态能力：支持视频内容检索（如定位特定片段）、网页爬取及结构化数据处理。

• 多场景适配：例如在体育赛事视频中，用户可通过关键词（如“樊振东金牌”）快速定位关键帧并展示。

技术架构与部署流程

平台架构分为三层：

数据层：支持结构化数据库（MySQL、Hologres等）及非结构化文件（OSS、HDFS）接入。

服务层：提供文本处理、向量化、检索、大模型调用等核心子服务。

应用层：基于自研引擎或Elasticsearch实现搜索场景开发，并支持与大数据产品的一键集成。

阿里云搜索产品将持续聚焦以下方向：

• Agent与搜索的深度结合：推动Deep Search、多Agent架构发展，提升复杂场景下的智能决策能力。

• 基础设施优化：通过GPU加速、向量索引量化等技术提升搜索效率。

• 大数据融合：强化与大数据平台的协同，实现搜索功能的一键接入。

• 开源生态扩展：

• 兼容LangChain、Llamaindex等开源框架及DeepSeek等大模型。

• 推进MCP协议标准化，增强开源社区的生态兼容性。

以上是全部分享内容

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

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

 2. 问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语法。

• 场景聚焦：适合需要直接通过自然语言操作关系型数据库的场景，例如数据分析、报表生成等。

• 适用性：特别适合需要深度依赖SQL特性的场景，如复杂查询、事务处理等。

Opensearch NL2SQL的扩展性与适用场景：

• 多数据源支持：

• ES DSL转换：支持将自然语言转化为Elasticsearch查询语言（NL2ES）。

• Opensearch DSL转换：支持将自然语言转化为Opensearch查询语言（NL2Opensearch）。

• 图数据库支持：可转换为Gremlin等图查询语言（如NL2Gremlin），适用于知识图谱或复杂关系分析。

• SQL变种适配：支持不同数据库的SQL方言。

• 灵活性：通过配置可适配多种数据引擎（如OpenSearch的特定查询语法），适合混合数据源场景。

• 适用性：适用于需要跨搜索、图数据库、关系型数据库等多引擎查询的复杂场景，例如多源数据整合等。

关键差异总结：

• Chat to DB：聚焦于数据库场景，适合对SQL标准和深度功能有强需求的用户。

• Opensearch NL2SQL：覆盖数据库、搜索、图数据库等多种数据引擎，适合需要跨平台统一语言交互的场景。

两者本质区别在于目标范围：Chat to DB是数据库专用工具，而Opensearch NL2SQL是自然语言到多种数据引擎DSL（领域特定语言）的通用转换框架。

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

答：目前的交付流程主要分为以下两类场景及对应角色协作机制：

• 一站式需求场景（客户仅提供数据，全程由平台处理）：

• 数据工程师：负责数据接入、数据治理及基础搜索功能部署，通过标准化产品完成全流程。

• 算法工程师：在产品默认配置无法满足效果需求时，介入模型参数优化或定制化开发。

• 模块化需求场景（客户仅使用平台部分功能）：

• 客户自助模块：提供标准化API和服务，客户通过API接入使用相关服务和功能。

• 技术支持团队：当客户反馈效果问题时，由该团队排查参数配置问题并提供优化建议。

问题处理机制：

• 配置类问题（占比较小）：由技术支持团队在1小时左右完成参数调整。

• 模型定制需求（占比较高）：若需深度优化，需客户配合提供原始数据或标注数据。此时触发以下流程：

• 数据分析师：评估数据质量并制定数据预处理方案。

• 算法工程师：基于客户需求定制搜索模型，通过半自动化工具完成模型训练与部署，周期通常为1周左右。

所有场景均通过标准化产品（如一站式平台）降低人工介入成本，同时通过模块化设计确保定制化需求可快速集成。关键角色的协同节点均在需求确认阶段明确，以保障交付效率与效果。

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

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

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

答：在数据结构复杂性方面，数据格式的复杂度越高，越能体现产品的价值，但这一因素并非主要考量。核心依据是业务场景的具体需求。例如，类似陈老师提到的小红书场景，对容错率要求较低的业务，更适合选择效果最优的模型；而对错误敏感的场景，则需选择幻觉率（生成不实信息的概率）较低的模型。在模型微调过程中，重点在于降低幻觉率，而非追求效果提升，因为基础模型的效果已由其本身决定。

在算力方面，目前我们的云服务产品尚未遇到显著瓶颈。当前主要挑战在于场景适配的优化，而非算力不足。若未来所有场景均需高性能模型且需求激增，届时可能面临算力压力，但目前尚未达到这一阶段。