RAG到DeepResearch技术路线实践

又快到年底盘点时间啦！本文聊聊我所在团队今年在大模型方向的技术路线和应用。

大模型的出现，带来最主流、最接地气的应用之一就是 RAG（Retrieval-Augmented Generation，检索增强生成）。但是在过去不到3年，RAG 在AI技术中多次“死而复生”：

一会儿被说要被 GraphRAG 替代，

一会儿被认为大模型底座已经覆盖RAG功能；

一会儿长上下文兴起，RAG落幕；

一会儿上下文工程成新热点...

前端时间deepseek-ocr也引起了大家对目前基于文本检索的RAG技术方向出现深思。

不过从目前我了解的大模型落地场景来看，RAG 仍然是最核心的基础能力之一。同时也能明显感受到仅仅靠RAG技术已经完全满足不了用户的需求了，本文就介绍 从RAG到DeepResearch，我们的技术实践之旅。

话不多说，先上技术路线图：

descript

1. RAG知识库检索

模型底座的研发门槛极高，在AI项目中，大多数团队更现实的方向是如何更好地利用大模型。

这就把需求的优化方向聚焦到两点：

• 输入优化：也就是 Prompt工程/ RAG / 上下文工程；
• 输出处理：让大模型回答更稳、更准、更可控。

我们先不聊Agent的一套规划，工具调用，记忆和反思操作。仅针对单轮的大模型输入，其实无论叫 Prompt Engineering 还是 Context Engineering，我认为说的都是一件事，就是我们要给大模型喂什么内容，它才能理解我们的意图并产出符合预期的答案.（关于上下文工程和RAG的关系后面单开一篇~）

对于通用知识，大模型底座已经具备。但要让它懂“你的业务”，能回答“你的问题”，就必须构建属于"你的知识库"，然后上RAG技术，RAG就是输入优化技术。

RAG相关技术我在之前分享的文档中其实已经介绍多次，本文就不做过多技术介绍。

（RAG，真是让我们吃了不少苦头...大模型要么降智要么幻觉的表现，让RAG有苦说不出）

聊聊团队在做企业级 RAG 知识库问答平台的一些感悟，召回，检索，大模型问答等技术其实已经相对成熟。在实际落地阶段，算法团队面临的挑战不仅仅是算法，还有数据治理、工程优化，在有些业务场景，数据甚至是更大挑战。

在特定领域中，我们仍然需要基于领域数据进行模型训练与优化，以及针对遇到的问题上技术手段，举些例子：

针对指代问题和多轮改写：我们训练了改写模型

针对版面解析效果不佳，速度慢，图片信息丢失等问题：我们自研版面解析框架

针对全局问题回答效果差：我们魔改GraphRAG，有自己的高效版GraphRAG

针对推理速度慢：我们自研推理框架，算法和工程结合，提升整个链路推理速度。

重要技术模块如下图所示：

descript

谈下RAG在实际项目落地中的一些感悟:

领导层的决心：企业要真正“AI化”，首先需要管理层推动数据入口统一与治理标准化。

跨团队协作：业务需求沟通、数据清洗、结构重构、文档规范、数据解析与入库等环节，特别是前期需要算法和业务团队的紧密沟通和协作

持续迭代优化：不要指望一次性的数据治理，RAG平台就能完美符合用户预期

数据治理和问答效果的优化，都是一个持续迭代的过程。每一次版本发布、每一次用户反馈，都是完善数据与算法的契机。

RAG 技术的接入，不仅是让企业“用上 AI”，更是让企业开始数据统一化治理、知识结构化重塑的起点。同时，RAG 本身也在实践中不断迭代优化——在更多场景下变得更稳、更聪明，也能更灵活地支撑不同业务需求。

2. Web知识扩展

RAG可以说是知识库问答的基操了，但在用户反馈的问题中你会发现有些用户的问题不在底座模型能力内，也不在内部知识库中，而是需要通过实时网络检索，比如"最近武汉有什么演唱会....." 你是不是也不能放弃这部分用户？那怎么办，宠着呗~

所以我们开发了一套实时网络检索工具，把互联网作为另一种信息来源，让模型能够在需要时动态获取新知识。从项目架构上，对原有 RAG 链路几乎不需要大改，只要多接入一个外部检索的数据源即可。

搜推一体，那既然搜都做了，不得上推？所以我们又"顺手"做了每日热点文章 & 最新论文的自动检索工具，帮团队节省了大量人工搜索的时间。没想到这个功能在公司推广后在很多团队受欢迎，在信息过载的时代，能自动过滤并推送高价值内容确实能体现AI的价值。

下图是我们每天为算法同事推送的 AI 热点信息界面。当然，这套机制并不局限于技术领域，任务类型也可以根据业务需求自由扩展。

descript

并且我们可以结合我们的RAG等技术。直接和文章进行问答。

3. 深度检索

随着工具能力的不断扩展、平台整体使用量的提升，我们在实际体验中也愈发清晰地意识到：仅仅具备“检索”能力的 RAG 问答系统，已经无法满足更复杂的业务需求。

信息源越多、问题越复杂，单轮检索 + 浅层推理的方式，很容易够不着真正的答案。因此，所以，我们开始继续向更高层次探索 —— 深度检索（Deep Search）。

当然我们遇到的问题也是RAG应用中的通用问题，所有平台的深度检索能力都在快速演进，比如Tongyi DeepResearch Agent。

Deep Research Agent技术 --通义“狐獴家族”（一）

结合论文方法、实际使用中暴露的问题，以及内部知识库与实时外部检索的双重需求，我们自研并私有化部署深度检索体系：

• 能同时利用内部知识库与实时互联网信息
• 结合自研模型进行问题改写，问题深入检索，多跳问题的推理
• 支持用户按需选择是否启用联网、是否基于自身知识库进行深度搜索

现在，平台在面对更复杂的问题时，能够进行多轮查询、整合与推理，提供更完整、更深入的答案。

4. 深度报告

深度检索通常面向的是某个具体问题，生成篇幅较短的回答。但随着技术发展，用户需求已经从“问答式检索”升级到“让 AI 自主开展系统性研究并生成深度报告”。

Deep Research Agent技术 --通义“狐獴家族”（二）

在上面两篇文章中我已经介绍过从 RAG 浅层检索 → 深度检索 → 深度研究报告的一系列技术演进，本文就不再展开介绍技术，基础流程如图一框架图中的这一部分：

descript

本文重点聊一聊通用的Deepresearch和企业中应用的差异点，以及为什么我们需要自研一套Deepresearch Agent。

目前我们自研的Deepresearch Agent在DeepReasearch_Bench榜单中使用官方测评方法验证，已经超越了第三名

descript

descript

核心创新来自以下几点：

（1）多智能体协作

根据图一的模块和工具，整个DeepResearch需要多个Agent模块以及工具协助，使最终输出更系统、更可控。

（2）自研 Query 扩展模型，提升研究维度的全面性

针对多轮指代、问题改写、问题扩写等真实业务中出现的 Query 理解难题，已经通用数据集，我们构建了高质量多维度训练数据集，并基于 7B 模型进行 SFT + RL 训练。模型的效果已与开源 32B 模型持平，实现了在更小规模模型上的高性价比。

（3）自研 Deep Search 深度搜索模型

结合自研网络检索工具和多跳问题框架，大幅提升了深度研究过程中的信息洞察能力，使模型更擅长处理复杂主题的链式推理与跨源整合。

（4）系统级性能优化

为了在企业环境中真正可落地，我们对全链路进行了专项性能优化，包括：

• 模型层面：在保证关键指标的前提下尽量使用小模型；量化、加速框架、prompt 压缩、投机解码等多项优化方案加速推理；
• 工程层面：采用分布式部署、请求缓冲、并发分流等策略，在有限资源下显著提升吞吐与并发能力。

（5）多模态能力扩展

目前在检索多模态功能上，少有开源模型涉及，而我们在 RAG 项目中已构建完整的多模态检索能力，得以顺利扩展到 DeepResearch 流程中

此外，在企业真实应用场景中，我们发现每个业务对 DeepResearch 的需求差异都很大，例如：

• 某些业务已有固定的 TOC 结构，需要绑定特定报告模板；
• 某些业务需要根据自身领域编写专属章节生成 prompt；
• 有些场景必须同时结合企业私域知识库与外部 Web 检索；
• 报告生成后，还需要具备在线自动润色调整能力；
• 有些行业需要严格的数据引用链路与溯源能力；

……这些需求都远远超出开源框架所能直接支持的能力。

因此，我们在自研 DeepResearch Agent 技术框架的基础上，又投入大量工程化建设，将其真正打磨为面向企业的可落地产品方案。

descript

在工程体系上，我们还通过 AI Coding 模块实现了“报告一键生成 HTML 可视化”的能力，让生成内容能够快速交付与部署。

descript

以及在线画布功能，方便业务同事和AI交互。

descript

5. 多模态

在多模态方向，我们的技术探索主要聚焦在三个核心能力：理解、生成、推理加速。

本文主要讨论的 RAG →Deepresearch Agent 的整体链路，这个模块当前企业最核心、最常用的能力仍然是 多模态理解。

版面分析是RAG里面我觉得非常重要但是常会被忽略的一个环节。文档解析的结构化效果，决定了后续的切片，检索和回复质量。我们团队在这部分也进行了多阶段的迭代：

• 传统文档解析方案：基于通用的文档解析库，速度快，但是丢掉图片信息，复杂版面的阅读顺序混乱；适合结构化文档。
• CV模型 + 工程串联方案：用若干轻量模型拆解多个子任务，工程上可控性强，但是工程链路长，误差会累计，而且工程部署复杂；
• 端到端多模态模型方案：统一输入格式，输出结构化布局，但是也存在输出不稳定难修复的缺点和推理速度慢的问题。

从实践经验来看，并不存在绝对正确的方案。不同业务的数据分布、延迟要求、算力预算都不同，需要按场景选择最优架构。

在完成版面分析后，下一步是对文档中的图片进行理解与处理。

我们在做RAG的图像检索和图文生成的链路包括：

图片语义理解：提取多模态 embedding 和文本描述；

图片存储与索引构建：用于后续高效召回；

检索后的图文结合生成：结合文本片段与图片内容，产出图文混排的多模态回答。

最终获取图文并茂的多模态回复。

6. Agent

如果说 RAG 解决的是“让模型知道该看什么”，让模型有记忆；

DeepSearch 解决的是“让模型知道该怎么看”，让模型能思考；

DeepResearch 解决的是“让模型能把看过的内容系统性整理起来”，让模型能推理研究

Agent需要解决的则是“自主知道下一步应该干什么”，真正有执行力。

我们的技术路线经过RAG、联网检索、深度搜索、深度研究之后，也可以越来越清晰地看到一个趋势，技术正在从“回答问题”向“自主完成任务”演进。

即便不刻意追求将产品打造成 Agent 框架，产品形态为了满足业务需求，也必然会演化出 Agent 的特性——它需要理解用户问题、感知外部环境、学会调用工具、进行思考与研究，并提供完整的解决方案。

当然在企业应用实践中，算法只是一部分，即使只从从技术角度来看，AI 从来不仅仅是一个模型或框架，而是一个完整的技术体系。

在 RAG → 深度检索 → DeepResearch → Agent 的项目建设过程中，除了算法模型的开发，我们还需要构建完整的工程体系，比如同步搭建算力平台、部署中间件、完善工具链、回溯链路、实现并发调度、缓存机制以及大盘数据等。

7. 总结

去年的技术博客可以看出都是偏理论知识，今年团队在深度报告Agent方向，我们在企业AI化中进行了场景落地的技术实践，从RAG到Agent：

• RAG： 构建企业知识库，实现智能检索和稳健问答，是基础能力。
• 知识扩展与深度检索： 结合实时互联网信息，多轮、多跳查询提升答案深度。
• 深度研究与报告生成： 多智能体协作、自研模型和多模态能力，实现系统化研究与可视化报告。
• Agent 化： 模型逐步具备自主执行任务能力，从“回答问题”升级到“完成任务”。

总体来看，企业大模型落地不仅是算法模型的开发，更是一个完整技术体系的建设：从业务沟通、知识管理、数据治理，到算法研究和实施，再到工程化部署、性能优化。RAG 虽然是核心的基础能力，但需要通过深度检索、深度研究和 Agent 化应用，才可以真正实现智能化决策与生产力提升。

朗新AI研究院已在多个技术方向深度沉淀，打造了一系列面向集团内部场景的智能体应用。

其中深度研究报告，产品博士和售前专家 中都需要用到今天介绍的Deepresearch技术。