RAG技术演进的四大核心命题

自2022年11月30日OpenAI发布ChatGPT-3.5以来，预训练大模型技术开启了指数级发展进程。这一革新热潮在2023年3月至4月达到阶段性高峰：阿里通义千问和百度文心一言等国内头部企业相继发布自主训练的大模型，正式宣告人工智能领域迈入大模型驱动的新纪元。尤其值得注意的是，2025年1-3月期间DeepSeek-R1和QwQ-32B推理大模型的开源举措，进一步加速了技术的进程。回顾过去两年间，大模型技术在金融、医疗、教育、客服等垂直领域实现深度渗透，尤其是在智能问答服务领域的突破性进展，通过大模型理解与推理能力的融合，实现了用户服务体验的指数级跃迁。

大模型发展历程[1]

然而，随着技术的深入应用，如何高效利用大模型技术优化用户体验，同时应对其带来的诸多挑战，比如如何将领域数据高效垂直化，如何解决大模型的幻觉等问题，成为行业亟需解决的核心问题。RAG（Retrieval-Augmented Generation，检索增强生成）作为一种前沿的技术方案，为应对上述挑战提供了新的思路和方法。

在2024.05之前，我们完成了对客大模型智能对话机器人Chatbot的RAG从0到1的建设，将检索准确率提升至90%，生成准确率提升至85%。后期，我们的核心目标不仅是继续升级对客RAG链路，将答案准确率提升至90%，还将重点构建小二智能辅助Copilot RAG，将小二信任度（答案准确率）提升至85%。

对客Chatbot

小二智能辅助Copilot

本文将从RAG的发展趋势、技术挑战、核心举措以及未来展望四个维度进行总结，期望激发更多关于RAG技术在云服务领域应用的思考与讨论，推动智能问答系统向更高效、精准和可靠的方向迈进。

在介绍RAG之前，先看下AI的发展趋势，红杉资本（Sequoia Capital）对2025年的AI发展做了三个预测：

1. LLM提供商之间的差异化：竞争将更加激烈，出现独特的超级力量（如OpenAI、Amazon/Anthropic、Google、Meta等）。这些公司已经发展出专门的优势，以在竞争格局中实现差异化，塑造各自的战略重心，并影响获取市场的方式。有的公司卖云，有的卖API，有的卖订阅（token），还有的卖应用等。

2. AI搜索作为杀手级应用的崛起：AI搜索的兴起可能会分化当前由Google主导的搜索市场。AI搜索超越了简单的网页索引，转向语义理解和知识综合，使用户能够更高效地找到信息并获得更深入的见解。

3. AI投资的稳定化和ROI挑战：巨额资本投入需要通过切实的商业成果来证明其合理性，这仍是行业面临的一个关键挑战。

总结一句话总结，2025年的AI格局将明显从最初的兴奋和快速投资阶段，转向注重落地、差异化和展示实际价值的阶段。对红衫资本最近几年的AI预测分析，可以参考下面热帖[2]，高年级洪林师兄的分享，总结非常深刻且全面。

Primary Architectural Approach 2023 vs 2024

接下来看下RAG的发展趋势，从市场份额看，Menlo Partners（门罗的合作伙伴）在2024年11月20日发布的市场调研报告[3]显示，他们调查了600名美国企业IT决策者，这些企业员工人数均在50人以上，覆盖了广泛的行业和应用场景。数据显示，今年企业AI设计模式（用于构建高效、可扩展AI系统的标准化架构）正在快速发展。2024年，RAG（检索增强生成）目前占据主导地位，采用率为51%，较去年的31%大幅上升。与此同时，经常被吹捧的微调（Fine-tuning）和RLHF（Reinforcement Learning from Human Feedback），尤其是在领先的应用提供商中，采用率仍然较低，分别只有9%和5%。

在2025年随着推理大模型的爆发，比如DeepSeek-R1和QwQ-32B，在复杂任务的推理上，结合RAG能否碰出新的火花，是今年最值得期待的。

在服务领域，用户体验至关重要。然而，传统的服务模式往往存在一些问题，如判别式回复、缺乏生成性思考等，这些问题直接影响用户体验。接下来，我将从三个角度分析为什么服务领域需要引入RAG：

1. 拟人化服务：传统客服缺乏对用户主动的个性化关怀，交互过程过于被动和机械，导致用户感受不到温度。

2. 专业性：技术支持人员对知识的维护成本较高，不同客服之间可能存在技术上的偏差。面对新问题时，缺乏有效的解决策略，导致问题解决效率低下。

3. 精准性：客服给出的答案往往泛泛而谈，缺乏针对性。例如，用户咨询某一具体情况时，回复却涉及多个不同情况，造成客户困扰和不满。同时，客户提出的问题大多模糊，需要上下文理解，但单靠小模型的能力难以胜任，导致用户体验不佳。

我们希望通过引入RAG，实现两个核心目标：

1.  为客户提供专业、精准、拟人化的客服服务，打破传统机械回复的不良体验。

2. 为客服人员提供专业、全面的智能辅助，帮助他们快速响应客户问题。

尽管检索增强生成（RAG）技术通过外部信息注入显著拓宽了大型语言模型( LLM )的认知维度，但该技术框架在关键决策场景下的缺陷也日益凸显。实证数据显示初期，小二智能辅助Copilot面临用户信任度危机的核心根源，在于其LLM输出结果存在显著缺陷，虽然内容检索准确率达到83%，但最终LLM生成答案的精准度仅为66%（两者间形成17pt的可信度断层）。这种信息处理链路中的质量衰减效应，在售后服务问答场景，这种要求高度确定性的领域将直接引发严重后果。针对该技术瓶颈，我们通过系统性梳理RAG技术全链路，提炼出制约RAG效果的核心挑战：

第一、数据价值的维度突破（检索什么）：在知识库构建层面，"垃圾进则垃圾出"(GIGO)定律持续制约RAG效能。面对海量异构数据（包括知识库文档、语雀协作内容、小二备忘等结构化与非结构化混合数据），如何以识别核心信息、厘清不同数据之间的关系网络，成为数据质量管控的关键前提。

第二、异构检索的跃迁（怎么检索）：在检索机制维度，当前主流的同构空间检索技术（如向量相似度比对）无法满足小二问答场景的复杂需求。当面对服务领域常见的多源异构数据（不同数据之间、不同描述风格），如何进行异构检索，实现精准的问题Q-答案A（-答案B）映射（一跳，多跳等链式检索），成为提升信息相关性的技术攻坚点。

第三、生成控制优化（怎么用检索内容）：在生成控制层面，简单的上下文注入策略导致模型持续暴露幻觉风险。亟需将检索信息转化为可信赖的认知锚点，去除冗余或者干扰信息，实现"信息指引生成"而非"激活动态联想"的良性交互。

第四、评估体系重构（怎么评估）：在质量控制维度，传统评估指标（如BLEU、Rouge）无法精准捕捉RAG系统的特殊缺陷。需构建多维动态评估矩阵以实现技术改进的方向引导，这套评估矩阵不仅能量化RAG效果，更能为改进指明优化方向。

这些问题构成RAG技术进化的理论坐标系。只有系统性解决数据质量管控、检索范式革新、生成控制优化和评估体系重构这四大命题，才能真正实现"知识增强"的价值闭环，重塑RAG智能系统的可信度基石。

本文从具体业务和技术挑战出发，探讨如何在知识边界拓展与可信度困境的平衡中，提升RAG效能，帮助业务拿到结果。通过实际需求的碰撞与最佳实践的探索，将这些经验内化为RAG系统能力。

RAG 整体方案

作为RAG系统的核心基础设施，知识库的构建直接决定知识检索与生成的质量边界。前期，我们重点根据文档结构进行提供预分好段落的"chunk"语料（structure hierarchical），但这远远不足让模型获得更加深层次的信息，也是造成模型生成幻觉的重要原因之一。后期，我们更加聚焦真实业务场景中的复杂挑战：多模态数据格式的解析、跨chunk显式和隐式关系建模（超链接/引用/章节关联）以及业务专家隐性知识的结构化挖掘等。通过构建分层知识图谱（Graph），我们开始实现从简单文本/语义检索，到复杂逻辑检索的维度突破。

RAG 数据增强

下面重点介绍一下如何进行知识组织，构建一个健全的多层次知识库。知识组织的核心是将解析后的数据构建成一个多层异构图，捕捉不同信息粒度和抽象水平之间的关系，支持下游任务的语义理解和推理检索。第一步，抽象不同数据的特征，挖掘它们之间的关系：

第二步，进行多层次知识库构建，核心流程可以概述为下述流程：Node（文档tree、工具、chunk等）->问题（原子粒度）->社区（问题聚类，该类的解决方案流程等）->主题（产品）->类目（产品线）

多层次知识库构建

示例1：对一篇文档按照结构切分，提取文档、段落及细分Chunk，解析后挖掘核心问题、摘要、因素等特征，并以文本和向量的方式存储到索引中，同时构建Chunk之间的关系，维护一张Chunk图谱。

文档Graph构建式示例

示例2:  根据工单之间和工单内部chunk之间的关系，构建工单的graph

工单Graph构建式示例

前期，我们主要聚焦同构空间检索技术，无法满足小二问答场景的复杂需求。针对RAG系统在异构检索场景下的核心挑战（多源异构数据映射与Q-A的单跳和多跳匹配检索问题），我们重点从以下几个方面进行尝试解决的：

• 问题理解：通过对复杂问题进行拆解和多策略融合技术重构问题处理链路，解决用户输入与知识库的语义鸿沟；

• 检索策略：增加文本异构检索能力和构建"混合语义+向量+图谱"三位一体的混合检索架构，实现不同源数据的协同召回；并且引入迭代式检索，提升复杂场景下的准确性。

4.2.1 问题理解

问题理解

我们针对复杂业务场景进行了三阶优化：

1. 增加问题拆解能力

• 拆解必要性判断

• 对于简单问题（如“rds如何计费”），不进行拆解，直接输出原始问句。

• 对于复杂问题（如“邮箱子账号如何设置邮箱的安全问题及安全手机”），严格按照独立性原则拆解为多个子问题。

• 避免无效拆解

• 不将问题拆解为过于宽泛或无实际搜索价值的形式。例如，“xxx的原因”或“xxx的排查流程”不作为独立子问题。

2. 进行改写策略优化

• 报错信息保留：针对技术问题中的报错码（如“ERR bad lua script”），强制保留英文原文，并适当精简上下文描述，确保改写后的问句仍具备明确的搜索价值。例如：

• 原始问句：redis集群代理模式不兼容redisson分布式锁，目前发现释放时会提示如下：ERR bad lua script for redis cluster, first parameter of redis.call/redis.pcall must be a single literal string. 将redis参数改为script_check_enable就没有问题了，有更好的解决方案吗

• 改写后问句：Redis集群代理模式下Redisson分布式锁ERR bad lua script的解决方案

• 多产品引用支持：对于涉及多个产品的问句，确保所有相关产品在改写后均被正确引用。例如：

• 原始问句：alibaba等保2.0镜像和alibaba快速启动有什么区别

• 不当的改写后问句：['Alibaba等保2.0镜像的特点', 'Alibaba快速启动镜像的特点', '两者在安全合规性上的区别']

• 正确的改写后问句：['alibaba等保2.0镜像的特点', 'alibaba快速启动的特点', 'alibaba等保2.0镜像和alibaba快速启动的区别']

• 上下文感知改写：通过引入上下文信息（包括产品信息），我们增强了改写模块对复杂场景的理解能力。模型会首先进行承接关系判断，仅在必要时结合上下文进行改写。例如：

• 客户的上文信息：如果我的ECS服务器被停机进行检修等操作，我有什么办法能够直接获取到服务器停机吗？

• 客户当前问句：我想要你们那边需要强制停机，我才接收报警，我应该选择哪些

• 改写后问句：ECS服务器如何设置仅在强制停机时才进行报警

3. 进行改写性能优化

• 合并改写链路：将原有的两轮大模型改写压缩为一轮，显著降低了整体耗时（改写模块处理耗时从4.5秒缩短至1.5秒，下降幅度超过60%）

• 旁路策略：对于命中高分知识的用户问句，跳过改写链路，直接进入搜索环节，进一步降低耗时。

我们通过人工打标GSB（Good/Same/Bad）的方式验证了改写新方案相较于旧方案的有效性，得到结果如下：

• Good : Same : Bad = 61.51% : 26.36% : 12.13%

• 暨
  

另外针对拆解效果评估，我们使用大模型进行标注的方式，从以下几个维度进行评估，评估结果见下表

1. 准确性：回答准确无误，不存在答非所问，满分3分

2. 完整性：针对用户的问题回复的内容比较全面，满分3分

3. 语言表达：表达清晰且没有语法错误，满分3分

4. 引用信息：准确且全，满分3分

5. 推荐哪一个答案：1是推荐，0代表不推荐

可以从评估结果中看出，新方案在准确性和效率方面均表现出明显优势，特别是在复杂问题的改写和拆解能力上有了显著提升。

4.2.2 检索策略

如果依托同构双通道检索（文本+向量），存在以下局限性：检索扁平化：单层级召回机制难以应对复杂问题拆解需求；上下文缺失：多文档关联检索能力不足，导致大模型生成可信度降低；语义鸿沟：标准分词器对领域异构同义词的覆盖度不足。

为了克服这些局限，我们从同义词库构建&分词器、增加混合语义检索和逻辑召回和迭代式检索进行了改进：

1. 同义词库构建&分词器的选择，特地收集来一些高频异构同义词，用来增加文本异构召回的能力，另外为了保证召回的准确率，我们在一些核心字段上选用的查准率比较高的分词器aliws->ik_smart。通过对比测试，我们发现两者优化动作，在我们评测集上recall@10提升了4pt，不同同义词之间的性能对比可见下表。

2. 增加混合语义检索和逻辑召回，除了QQ检索之外，增加QA检索和图谱召回，

• 图检索：对关键节点进行向量和关键词检索，选择topN 个节点的子图信息进行返回。

图检索

• 混合检索，总体策略是通过向量、文本和图进行混合检索，结合“小到大”策略获得更丰富的上下文信息，帮助大模型生成更精准的回答。

混合检索

在工单检索场景中的离线评估结果显示，引入多语义召回和图谱召回后，检索系统的Top 5和Top 10准确率都有显著提升，特别是在Top 5准确率上表现尤为突出。虽然多语义召回在Top 10准确率上有轻微下降，但结合图谱召回后，整体性能得到了大幅提升。这表明新的检索策略在提高检索准确性方面效果显著。

3. 迭代式检索，当首次搜索未能获取有效信息时，需要调整搜索策略需要分层次递进式优化，逐步查询（直接解决 → 部分解决 → 关联问题解决），避免“一次性检索”的信息污染进而回复有误。

Agentic RAG

生成控制优化主要包含两个核心方面：一是过滤掉无法解决问题的参考信息，二是进一步完善参考信息的质量和实用性。

4.3.1 过滤无效参考信息

确保搜索结果与用户查询的相关性是我们的基本要求，但更关键的挑战在于如何保证检索出的内容不仅相关，还能有效解决用户的实际问题。用户在进行搜索时，期望得到的是能够直接回答或解决其疑问的具体答案，而不仅仅是表面上看似相关的信息。因此，如何有效地筛选出那些虽然相关但并不能真正解决问题的内容，对于提升检索增强生成（RAG）的质量以及优化大型模型的表现至关重要。

前期，我们在生成内容的相关性方面做了一些初步探索，但尚未实现落地应用。进入2024.4月之后，我们认为进一步深化这方面的工作尤为重要。我们将重点放在通过数据增强来挖掘和理解问题和答案相关性的逻辑上，并引入检索增强相关性（RAR, Retrieval-Augmented Relevance）技术，赋予大模型判断“不相关”的能力。

Retrieval-Augmented Relevance（RAR）

以下是RAR这一过程中的几个核心方法：

1. 相关性数据：利用小二/用户反馈及高参数大模型分析，提炼出用于增强领域理解的相关性评估标准/逻辑。

2. 链式思维提示：设计一系列提示语句，引导模型逐步推理复杂问题，提高其逻辑分析能力和答案组织的条理性。

3. 动态少量示例学习：根据具体场景动态调整参考案例的数量，以优化模型对不同情况的适应性。

4. 相关性级别定义：明确界定查询与文档间相关性的等级，确保模型仅基于最相关的资料生成答案，从而保证信息的准确性和实用性。我们设定了四个相关性级别：

经过多次测试，包括采用不同的模型和不同指令提示策略，结果显示Qwen 2.5 72B搭配Thoughts功能表现最佳，将错误召回率从15.97%可以降至5.03%，同时提高了68.5%的错误减少比例，F1分数达到了94.28%。这表明了在提高搜索结果质量和用户体验方面的显著进步。

4.3.2 完善参考信息的质量

随着大模型支持的context长度越来越长，我们从以下几个方面对参考信息进行优化和完善：

1. 支持更长上下文的响应：采用“small to big”的策略。为大模型提供更丰富的上下文信息，使其能够在生成过程中更好地理解和利用参考内容，从而生成更加全面和准确的回答。

2. 结构化ID过滤机制：为每一条参考信息分配唯一的结构化ID，以便在搜索过程中快速定位和筛选相关内容。这种机制不仅能提高信息检索的效率，还能减少冗余信息的干扰。

3. 多样化图片引用方式：为了优化生成内容的质量，我们对四种不同的图片引用方式进行了评估，目的是提升图片引用的比例，以丰富生成内容的形式和信息维度。以下是每种方式的定义及评估结果的详细分析：

• 图片引用方式说明

• Option 1: 不解析图片内容，仅保留原始图片标记（![原始信息]）。

• Option 2: 使用图片的摘要信息（![图的summary]）替换原始图片标记。

• Option 3: 在图片摘要信息的基础上增加描述性内容（![图的summary] + 图的description），并替换原始图片标记。

• Option 4: 将图片的摘要信息和描述性内容（![图的summary] + 图的description）附加到每条参考信息的末尾。

• 评估结果，对于两种模型（Qwen 1.5 72B 和 Qwen Max），Option 4 的出图比例均显著优于其他方式，得分最高。这表明将图片的摘要信息和描述性内容附加到参考信息末尾的方式能够最大程度地提升生成内容的质量/出图比例，另外Qwen Max 的整体得分显著高于 Qwen 1.5 72B，表明更大规模的模型在处理多样化图片引用时具有更强的能力。

RAG Diagnoser

随着我们对RAG链路优化工作的不断深入，传统的评估方法逐渐显现出局限性。前期，我们主要依赖检索准确率和生成准确率这两个核心指标来衡量系统表现，但这种方法过于单一，难以全面反映复杂业务场景中的实际效果，也无法为后续优化提供明确的方向指引。因此，我们在本年度构建了一套全新的评估体系“RAG Diagnoser”。这套体系通过细粒度的诊断分析，可以帮助团队从粗略判断转向精准定位，从而实现技术突破。

RAG Diagnoser的核心目标是成为RAG链路优化的“后盾”。它通过对模型输出的每个环节进行深入剖析，帮助团队快速识别问题根源，并制定针对性的改进策略。具体来说，这套体系具备三大功能：支持细粒度评估、识别性能瓶颈以及指导迭代优化。为了实现这些目标，第一步，我们先对用户Query进行了细致分类。在评估RAG时对问题进行分类这种模式在之前的工作中也不鲜见，例如阿里NLP团队提出的CoFE-RAG从通用RAG的视角将Query拆分成了Factual, Analytical, Comparative, Tutorial四类[4]。在RAG Diagnoser中，Query的不同类别会影响后文提及的原子事实的定义和检查方式。我们从对客RAG和智能辅助的实际应用的角度出发，经过多轮迭代标注和分析，构建了一套符合自身业务特点的Query分类体系，涵盖以下主要类别：

第二步，我们需要对不同类型Query抽取特定的Ground Truth作为评估Target，得益于我们业务特性，我们可以直接从历史工单中提取相应Query的Ground Truth。

第三步，为了实现细粒度评估，我们引入了“原子事实”这一概念，作为评估的基础单元。所谓原子事实，是指在RAG链路诊断过程中能够被单独分析、不可进一步拆分的具体且可验证的事实或结论。这一概念的灵感借鉴了亚马逊RAG-Checker[5]和经典RAG评测框架RAGAS[6]中的"claims"。例如对于以下句子：“尼罗河是一条向北流的大河，位于非洲东北部。它最终流入地中海。”可以提取出3条原子事实：尼罗河是一条北流的大河、尼罗河位于非洲东北部和尼罗河流入地中海。在我们的场景中，原子事实并不是固定的定义，而是根据业务特点进行了定制化设计。通过原子事实化，我们可以清晰地判断模型是否遗漏了某个关键信息，或者是否违背了某项事实。相比传统端到端的评估方法，这种细粒度的方式更能揭示问题的本质。

第四步，我们会基于原子事实进行性能评估，比如根据RAG的回复与Ground Truth在原子事实粒度上的一致性，计算整体的原子事实准确率、召回率、矛盾率等指标。这些指标可以帮助我们快速了解模型的整体表现。为了更深入地挖掘问题根源，我们还会对RAG链路的各个模块分别进行评估，以精准定位问题来源：

• 搜索诊断：检查原子事实在检索各阶段的覆盖率，判断是否存在召回不足的问题。

• 改写诊断：分析改写前后搜索到的Chunk是否包含正确的原子事实，评估改写的效果变化。

• 回复诊断：检查生成模块是否存在遗漏或错误的原子事实，判断生成质量。

以下是一个针对“Factual-Y/N”类Query的回复诊断模块的具体案例。我们将详细展示如何通过原子事实提取和对比，识别模型输出中的问题，并指导后续优化。根据业务特点，我们在处理Factual-Y/N类Query时的两点特殊设计也可以在下例中看到：对Ground Truth进行了格式化设计，第一句固定回答“Yes/No”；并确保至少有一条原子事实直接对应原问题的答案。

{  "Query来源工单号": "xxx",  "用户问句": "g8i服务器支持二次虚拟化吗",  "Query分类": "Factual-Y/N",  "从工单中提取的Ground Truth": "不是的。仅弹性裸金属服务器和超级计算集群支持二次虚拟化，这些产品的规格都较大。g8i服务器属于通用型实例规格族，不支持二次虚拟化。",  "Ground Truth原子事实列表": [      "g8i服务器不支持二次虚拟化。",      "弹性裸金属服务器支持二次虚拟化。",      "超级计算集群支持二次虚拟化。",      "弹性裸金属服务器和超级计算集群的规格都较大。",      "g8i服务器属于通用型实例规格族。"  ],  "大模型回复": "您好，g8i服务器属于弹性裸金属服务器，支持二次虚拟化。您可以利用这一特性在g8i服务器上安装虚拟化软件，创建虚拟机。更多详情，可参考[弹性裸金属服务器概述](https://help.aliyun.com/document_detail/60576.html)文档。",  "大模型回复原子事实列表": [      "g8i服务器属于弹性裸金属服务器。",      "g8i服务器支持二次虚拟化。",      "您可以利用g8i服务器的二次虚拟化特性在服务器上安装虚拟化软件，创建虚拟机。"  ],  "大模型回复中与Ground Truth矛盾的原子事实": [      "g8i服务器不支持二次虚拟化。"  ],  "Ground Truth中与大模型回复矛盾的原子事实": [      "g8i服务器属于弹性裸金属服务器。",      "g8i服务器支持二次虚拟化。",      "您可以利用g8i服务器的二次虚拟化特性在服务器上安装虚拟化软件，创建虚拟机。"  ],  "分析结论": {      "矛盾的原子事实": "大模型回复中的“g8i服务器支持二次虚拟化”与Ground Truth中的“g8i服务器不支持二次虚拟化”直接矛盾。此外，“g8i服务器属于弹性裸金属服务器”也与Ground Truth中的“g8i服务器属于通用型实例规格族”相冲突。",      "遗漏的原子事实": "大模型未提及“弹性裸金属服务器支持二次虚拟化”和“超级计算集群支持二次虚拟化”这两条重要信息。同时，关于“弹性裸金属服务器和超级计算集群的规格都较大”的补充说明也被完全忽略。",      "引入的错误信息": "大模型引入了“您可以利用g8i服务器的二次虚拟化特性在服务器上安装虚拟化软件，创建虚拟机”这一错误描述，进一步误导用户。"  }}

最后，根据评估结果，明确各模块的性能短板，并提出针对性改进措施。例如，若发现检索模块召回不足，则可考虑扩充同义词库或优化混合检索策略；若生成模块频繁出现幻觉，则推动相关性判断机制的加强等。

回顾过去一年，我们的工作重心主要聚焦于提升RAG系统在通用问题解决能力上的表现，成功完成了小二辅助Copilot RAG从0到1的建设，并显著增强了大模型的信任度。同时，我们也开始在一些复杂场景中进行初步探索，为未来的发展奠定了基础。展望未来，我们将迈向更深层次的技术突破与场景落地，在以下三个关键方向上深入探索：

1. 多模态检索：进一步提升系统对文本、图表、图像等多模态数据的理解与融合能力，以应对复杂的跨模态任务需求。

2. DeepSearch：完善多层次异构图的构建，优化跨文档推理与信息链接能力；把长期的思考和推理过程融入到搜索系统，确保能够高效处理需要深度逻辑推理的复杂任务。

3. 评估与优化：建立更加科学、全面的评估体系，推动RAG系统在实际应用中的持续迭代与性能提升。

我们相信，随着推理大模型的飞速发展，结合在这些方向上的深耕细作，下一阶段，我们服务领域的DeepRAG将迎来质的飞跃，为用户带来更智能、更可靠的服务体验，敬请期待