Deep Search 如何理解业务仓库代码？

一、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三家产品效果最好，排在最前面。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei", Arial, sans-serif;font-size: 12.000001px;font-style: normal;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;text-align: start;text-indent: 0px;text-transform: none;white-space: normal;word-spacing: 0px;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;text-decoration: none;width: 1066.023977px;opacity: 1;transition: transform 400ms cubic-bezier(0.25, 0.8, 0.25, 1), opacity 400ms, height 0ms cubic-bezier(0.25, 0.8, 0.25, 1);height: auto !important;" src="https://api.ibos.cn/v4/weapparticle/accesswximg?aid=113622&url=aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9aNmJpY3hJeDVuYUlCZVFKQjVmTld5R09MSzZadW4wTXhyaGZJc3p1SWQ1VWljclRzaE84SEtBbDFCZkxybkxxZXNqNmljbmViNjFyeW9vMkRQU0JtbFlnZy82NDA/d3hfZm10PXBuZyZhbXA=;from=appmsg"/>

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 仓库问答和需求生码场景，提升当前功能效果。

多模态数据信息提取

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