Deep Search:如何像专家一样理解你的代码仓库?

告别低效代码搜索!Deep Search方案融合业务上下文,深度解析查询,助你精准定位代码,提升研发效率。

原文标题:Deep Search 如何理解业务仓库代码?

原文作者:阿里云开发者

冷月清谈:

本文深入探讨了Deep Search和Deep Research的概念,它们与传统RAG的区别,以及在代码领域的应用。传统RAG在代码搜索中存在局限性,无法精准理解用户意图和业务逻辑。为此,提出了Deep Search方案,通过融合代码库中的业务上下文信息,深度解析用户查询,从而更精确地匹配代码及其相关信息。Deep Search通过query增强模块动态优化查询,并通过分阶段总结模块处理代码片段,最后通过代码信息模块进行系统整理和总结,重点介绍了Deep Search在代码仓库问答中的应用及效果,并展望了未来的发展方向,包括研发专用代码搜索Agent以及多模态数据信息提取。

怜星夜思:

1、Deep Search 方案中提到的 Query Enhancement Module,在实际应用中,如何平衡“增强”带来的好处(更精确的检索结果)和潜在的坏处(计算成本增加,检索时间变长)?有没有什么策略可以动态调整增强的程度?
2、文章提到未来会开发和训练一个专门的代码搜索智能体(Code Search Agent),那么这个 Agent 相比于直接使用通用 LLM,有哪些优势是显而易见的?又有哪些潜在的挑战?
3、Deep Search 在企业级代码仓库中的应用,除了文章中提到的代码仓库问答和需求生码,你觉得还可以应用在哪些场景?这些场景又会带来哪些价值?

原文内容

阿里妹导读


本文系统地介绍了 Deep Search 和 Deep Research 的概念、与传统 RAG 的区别、当前主流的商业产品与开源方案、在代码领域的应用(如 Deep Search for 仓库问答)以及未来的发展规划。


一、Deep (Re)Search

1.1 Deep (Re)Search定义:

Deep Search和Deep Research均致力于对信息或数据进行深度挖掘与分析。这超越了表层搜索或初步了解的范畴,需要投入显著的时间、精力及资源,其目标是获得高质量、全面的洞察,而不是只在片面的思考或者粗略的判断上面。对于他俩的区别如下:

a.Deep Search(深度思考):更侧重“找”的过程,它的目标是把相关信息尽可能全面、深入地挖掘出来。

b.Deep ReSearch(深度研究):更侧重“写”的过程,它可以利用Deep Search找到的信息,进行深入地思考,分析和创造,目标是产出深刻的理解或知识。

1.2 和传统RAG区别

传统RAG是一种结合了信息检索和文本生成的AI架构。它的核心思想是当用户提出问题,系统会从大规模的知识库(通常是向量检索库)中检索出跟问题最相关的文档片段或信息,然后将这些检索到的信息连同原始问题一起提供给LLM,让LLM基于这些“增强”的上下文信息生成更准确的、更具事实性的答案。

二、Deep (Re)Search调研

这是一张各家Deep (Re)search产品的四象图,可以看到OpenAI、Google和XAI三家产品效果最好,排在最前面。

2.1 商业产品

OpenAI、Google和xAI他们各家的Deep (Re)Search产品,共同点是将agent检索能力集成在了自家的模型里面,在使用体验上非常丝滑,效果也非常出彩。

2.2 开源方案

2.2.1 非训练版本

当前Deep Search领域,很多开源的解决方案在流程结构上非常相似。经过深入分析,我们可以将其概括成一种增强型的“大循环式强化生成”(Recurrent Augmented Generation, RAG) 结构。该结构对以下两个关键流程进行了优化:

  • 原始查询处理优化:在初始查询阶段,这些方案对输入的关键词进行处理,从而提高查询的精度和效率。这种方案确保在数据检索过程中能够捕获更多相关的信息,并为后续数据处理提供优质的输入;

  • 检索结果智能分析:在检索结果分析方面,利用LLM对数据进行深层次的思考和解析。通过这种方式,LLM结合外部知识和上下文语义,对检索结果进行深入分析,提升结果的可靠性。

这种整合策略不仅提升了信息处理的效率和准确性,还为用户提供了更加精准和丰富的结果。在开源软件的推动下,这类创新技术正在引领业界的发展,成为数据处理与分析的重要工具之一。

OpenDeepResearch为例,他的过程大致如下:

1.用户输入一个问题后,LLM会根据问题生成四个不同的关键词;

2.每个关键词通过检索接口进行检索;

3.将获取到的信息进行聚合处理和去重处理;

4.利用LLM去评估每个结果的有效性,并提取相关内容;

5.汇总所有信息,用LLM判断是否需要生成新的关键词。如果需要,则生成新的查询,反之,结束循环;

6.将所有收集到的上下文信息进行整合,交给LLM生成一份详细的、全面的报告。

Search-o1代表:

还有一种以Search-o1为代表,他主要聚焦在推理过程中知识不足的问题,通过系统检索(RAG)来完成。另一方面,检索回来的内容大多数情况下会非常杂乱,直接放到模型中会影响造成上下文长度受限的问题,这里提出一种文档内推理(Reason-in-Documents)方式,来对搜索返回的上下文进行整理总结。

触发search的prompt:

Reason-in-Document的prompt:

2.2.2 训练版本

目前业界也有一些开源的Agent模型训练方案,目的是提升LLM base推理模型在复杂推理任务的能力,通过外部检索工具(如搜索引擎)解决多步推理、知识检索、减少幻觉等问题。最终是想让模型更像人一样去思考或检索问题,增强模型在推理过程中的动态决策能力,阅读能力以及最终的汇总能力。

下面这三篇论文(Search-R1、ReSearch 和 AutoCoA)都是通过强化学习的方式来提升LLM的推理能力,使其能够更自主地与外部工具或搜索引擎互动。

Search-R1:https://arxiv.org/pdf/2503.09516

ReSearch: https://arxiv.org/pdf/2503.19470

AutoCOA:https://arxiv.org/pdf/2503.06580

这三篇论文都是围绕“推理-搜索”交互展开,通过RL来提高LLM的自主决策能力。在结构格式方面也都是通过一些符号定义来分割推理步骤、搜索查询和查询结果,规范模型输出结构来支持多轮交互。

三种方案对比:

三、Deep Search在代码领域应用

3.1 动机

代码搜索在需求生码、仓库问答等场景是非常重要的前置环节。高质量的输入内容决定了LLM的输出结果,在企业级代码仓库场景下,由于代码逻辑与业务流程紧密耦合,若缺乏足够的业务背景信息输入,LLM 往往难以准确解析用户需求或问题本质,导致输出结果偏离预期,甚至出现答非所问的情况。

当前,RAG(检索增强生成)技术虽被广泛应用于代码搜索领域,通过 Embedding 向量检索方式,能快速匹配仓库内相关代码片段。然而,这种单次检索机制存在显著局限性:一方面,面对复杂业务需求时,难以精准定位最匹配的代码片段,容易遗漏关键上下文;另一方面,由于缺乏对用户意图的深度挖掘,仅依赖表层语义匹配,无法充分理解需求背后的业务逻辑和应用场景,导致检索结果与实际需求存在偏差。

3.2 Deep Search方案

为克服这些限制,我们提出 Deep Search 方案。该方案通过融合代码库中的业务上下文信息,对用户查询进行深度解析,超越表层语义匹配,发现与用户根本需求最为匹配的代码及其相关信息,从而显著提升检索的精准度和相关性

为构建高效精准的代码检索与分析能力,我们研发了 Deep Search 工具。该工具的设计借鉴并整合了业界领先的开源 Deep Search 框架的核心思想与先进技术,同时深入分析了当前主流闭源 Deep (Re)Search 解决方案的功能特性与局限性。通过融合两者的优势,我们构建了一套独特的代码理解与检索架构。

3.3 Deep Search架构图

我们设计的 Deep Search 专注于代码检索领域,能够深度理解用户查询意图,精确匹配并定位最相关的代码片段。此外,系统还具备根据用户特定需求,自动化生成结构化分析报告的能力,为代码审计、复用及理解提供有力支持。

3.3.1 Query Enhancement Module

在实际的代码检索场景中,用户初始问题通常具有高度发散性和模糊性。直接基于原始查询进行简单的相关性检索往往会导致检索结果精度和召回率的显著下降。为了提升代码检索的准确性和智能性,我们提出了一个Query增强模块,旨在通过仓库和已有的query信息,动态优化query查询。

Query 增强模块的输入包括:

  • 原始 Query: 用户提交的初始查询语句。

  • 代码仓库信息: 包含仓库整体结构信息、API链路信息、CodeGraph信息等。

  • 已生成 Query 列表 : 之前迭代生成的 Query 序列,用于辅助判断和优化。

Query增强模块内部通过LLM,根据输入信息判断是否需要Query下钻,提取更细粒度的特征,生成新的Query。增强后的Query将被用于后续的代码检索流程,以获得更精确的检索结果。

3.3.2 Staged Summary Module

为避免代码搜索产生的代码片段数量过多,导致下游大型语言模型 (LLM) 上下文长度超出限制,进而影响模型推理效果,本模块在 LLM 处理前进行阶段性总结与筛选。 该模块旨在根据已检索的信息,对候选代码片段进行一次初步评估,剔除相关性较低的代码,以优化上下文质量和降低计算成本。

输入:

  • 代码仓库信息

  • 历史查询 (Query) 列表

  • 搜索返回的代码片段集合

输出:

  • 经过筛选和提炼的、相关度更高的代码片段集合,为后续处理提供精简的上下文。

3.3.3 Need New Query Module

在获取到代码片段后,我们会对当前信息进行完整性评估。通过分析已有信息,包括代码仓库信息,历史查询query列表以及搜索筛选后的代码片段信息,识别潜在的信息空白。基于此分析,该模块会动态生成补充的搜索条件,目的是填补信息缺口

输入:

  • 代码仓库信息

  • 历史查询(Query)列表

  • 搜索筛选后的代码片段

输出:

  • 信息缺失项,为后续深度搜索提供指导。

3.3.4 Code Information Module

在本模块,我们会对上面收集到的代码信息进行系统性的整理和总结。最终的输出策略根据具体的任务目标进行相应调整:

  • 代码回答任务:需要对获取到代码片段里的代码逻辑、关键函数、调用关系等内容进行归纳整理,形成结构化的分析报告,便于后续推理和回答;

  • 代码生成任务:应聚焦识别最相关或最需要修改的代码片段,并基于上下文和变更需求,生成清洗的、可执行的代码修改方案。

通过针对性的信息筛选和组织,确保最终输出内容精准服务当前任务目标,提高整体处理效率和生成效果。

四、Deep Search在仓库问答效果展示

4.1 视频

4.2 截图

结果部分截图:

五、未来规划

5.1 当前系统概述:

我们构建的Deep Search代码搜索系统,该系统基于先进的开源大型语言模型(LLMs)。其核心运作机制包括:

(1) 运用复杂的提示策略(Complex Prompting Strategies)引导LLM理解用户意图;

(2) 设计外部工具和存储系统,增强代码搜索能力和LLM输入的上下文信息;

(3) 最终依赖LLM的通用推理与生成能力完成代码片段的搜索、筛选与整合。

尽管此方法已展现出潜力,但其性能在一定程度上受限于通用LLM在代码领域知识的深度以及复杂代码逻辑推理的精度。

5.2 研发专用代码搜索Agent:

为克服上述限制并实现更高水平的代码搜索智能化,我们的下一阶段核心任务是开发和训练一个专门的代码搜索智能体(Code Search Agent)。分解为两个关键方面:

领域知识注入 (Domain Knowledge Infusion): 通过在大量高质量代码数据集(包括多种编程语言、框架、API文档和开发实践)上进行微调(Fine-tuning),使Agent模型学习和内化代码领域的专门知识。旨在提升模型对代码语义、结构、依赖关系及常见模式的理解能力。

推理能力专项训练 (Reasoning Capability Enhancement):  通过设计针对性的训练任务和数据集,专注于提升Agent在代码搜索中的高级推理能力。训练重点在于使其能够深度理解复杂查询意图,自主规划搜索策略,精准评估代码片段的相关性与质量,并有效地整合与提炼搜索结果。

5.3 使用场景

Deep Search即将应用在CodeFuse 仓库问答和需求生码场景,提升当前功能效果。

多模态数据信息提取


随着信息技术的快速发展,数据的获取与处理变得尤为重要。本方案提供多模态文件信息抽取能力,通过先进的人工智能技术,能够识别和解析各种格式的文件,包括文本、图像、音频和视频,从而提取出有价值的信息,大幅提升数据处理效率。    


点击阅读原文查看详情。

我觉得本质上还是对用户意图的理解。如果能准确识别用户是想快速得到一个大概的结果,还是愿意花更多时间获取更精确的答案,就可以据此调整 Query Enhancement 的策略。比如,可以提供一个“精确搜索”模式,让用户手动选择是否进行深度增强。

学术一点来说,这是一个典型的收益-成本优化问题。可以考虑使用强化学习来训练一个策略,让 Agent 根据当前 Query 的状态(比如长度、包含的关键词数量、历史检索结果等)来决定是否需要增强,以及增强的程度。奖励函数可以设置为检索结果的准确率减去计算成本。此外,还可以借鉴 A/B 测试的思想,对不同的增强策略进行在线评估,选择最优的策略。

代码重构也是一个有潜力的方向。Deep Search 可以帮助开发者快速找到需要重构的代码片段,并提供重构方案。这可以大大提高代码的可维护性和可扩展性。还有,可以用于代码知识图谱的构建,将代码的各种关系(例如调用关系、依赖关系)可视化,帮助开发者更好地理解代码。

优势肯定在于对代码的理解更深入啊!通用 LLM 虽然厉害,但毕竟是“通才”,在代码领域的理解肯定不如专门训练的 Agent。比如,Agent 可以更好地理解代码的语法、语义,甚至可以理解代码的风格和设计模式。但是,训练一个专门的 Agent 也很难,需要大量高质量的代码数据,还需要设计合适的训练目标和方法。而且,Agent 的泛化能力也是一个挑战,需要确保 Agent 在不同的代码仓库和不同的编程语言上都能表现良好。

代码安全漏洞检测绝对是一个重要场景!Deep Search 可以帮助安全工程师快速定位潜在的安全风险代码,并提供修复建议。另外,还可以用于代码合规性检查,确保代码符合企业的规范和标准。这些应用可以大大提高代码质量,降低安全风险。

从模型层面来说,专用 Agent 可以针对代码搜索任务进行定制化的模型结构设计,例如引入代码相关的先验知识(例如 AST 结构)到模型中。挑战在于数据的获取和标注,高质量的代码数据往往涉及版权和安全问题,难以获取。另外,如何有效地利用代码数据进行模型训练也是一个难题,需要设计合适的预训练和微调策略。

我觉得最大的挑战在于如何让 Agent 真正理解代码的“意图”。代码不仅仅是字符的堆砌,更是程序员意图的表达。如何让 Agent 理解代码背后的设计思想、业务逻辑,甚至程序员的个人风格,才是最难的。否则,Agent 最终可能只是一个“代码搬运工”,而不是一个真正的“代码理解者”。当然,如果能把这个做好,那想象空间就太大了!

Query 增强有利有弊啊,个人觉得可以根据用户 Query 的复杂度来动态调整增强程度。如果用户 Query 本身就很清晰明确,可能就没必要进行过度增强,直接检索就行了。但如果 Query 很模糊,或者涉及到多个模块的交互,就可以考虑加深增强的力度。另外,可以考虑引入一个“增强收益评估”机制,评估每次增强带来的精度提升和成本增加,如果收益小于成本,就停止增强。

我觉得在新人入职培训上也能发挥作用。新人刚接触一个大型代码仓库时,往往会感到无从下手。Deep Search 可以帮助他们快速找到相关的代码片段,了解系统的架构和设计。这可以大大缩短新人的学习曲线,让他们更快地融入团队。