预生成上下文：重构RAG的关键工程，构建AI编程底座

核心内容概览

1. 预生成上下文在 AI 编码领域的应用场景与独特优势
2. RAG 技术流程中的不确定性因素深度剖析
3. 索引与检索阶段面临的典型挑战及优化方向

近几个月来，预生成上下文在 AI 编码领域迅速成为热门话题与技术趋势。开发人员借助这些 AI 生成的 Wiki，能够快速理解开源项目的用途与技术架构。尽管从理解深度看，当前基于 RAG 和文档检索的方式仍有提升空间，还需引入基于 AST 的上下文分析来增强准确度和覆盖面，但从效率角度看，预生成上下文的方式已逐渐成为主流方向。

为此，我们着手为 AutoDev 开发一项新功能 Context Worker，旨在通过预生成上下文显著改善 RAG 的检索与生成效果。如果对此功能感兴趣，欢迎加入我们的 GitHub：https://github.com/unit-mesh/autodev-work

引子：谁都会，但谁都做不好的 RAG

2023 年，LangChain 框架的推出简化了 AI 应用的开发流程，RAG（Retrieval Augmented Generation，检索增强生成）迅速成为应用开发领域的热门概念。 RAG 的核心思想是将检索与生成相结合，通过检索相关信息来增强生成模型的能力。

技术因素：不确定的 RAG，随机的模型生成

RAG 流程的每个环节都可能引入变量，这些变量累积叠加，形成影响最终效果的“不确定性链条”。

通常，主流 RAG 实现包含两个主要阶段：

1. 索引阶段：将非结构化或结构化数据按照某种拆分方式切分，进行向量化（可选），并存储到数据库中。

2. 检索阶段：对用户输入进行转换，进行向量化（可选），在数据库中检索，返回相关上下文信息，再经过一定处理（可选），传递给生成模型进行生成。

这一过程中存在大量不确定性因素，导致 RAG 的效果往往不如预期。

索引阶段：知识库的构建质量直接决定了后续检索的上限。 核心难点包括：如何合理分块以保留语义完整性（尤其是代码边界）、选择合适的嵌入模型进行向量化、以及针对多源数据进行有效预处理，避免“垃圾进、垃圾出”。

检索阶段的挑战：即使用户查询意图明确，从索引中高效准确地找到相关信息也并非易事。 精准检索需要解决查询歧义、提升搜索能力（如混合搜索、HyDE）、进行结果重排序（Re-ranking），并控制上下文长度，以防信息丢失或干扰生成。

最后，LLM 在生成回复时本身也会引入随机性。模型对查询意图的理解，以及对检索到的上下文信息的解读，都可能存在偏差。这导致即便输入完全相同，输出结果也可能不一致或不准确。RAG 系统高度依赖外部数据的质量和相关性；如果检索过程出现偏差，生成阶段的质量必然受到影响。

业务因素：大量的垃圾知识在影响 RAG 的效果

去年，我们在与大量企业交流时发现：企业中海量的文档和代码（“文档太多”）带来了重大挑战。代码的版本化与文档的版本化方式并不一致。通常，流水线上通过的代码即可正常工作，但你很难从 04-03.docx 和 修订版 12.docx 中判断出哪个是最新版本。即便能判断出最新版，也难以确认该版本是否是正确的版本。

因此，质量参差不齐（“质量不齐”）进一步加剧了问题，因为模型在即时处理时可能会从次优或错误的示例中学习或检索信息（用户查询）。如果引导不当，生成式 AI 可能会产生有害、虚假或剽窃的内容，当输入数据庞大且未经整理（即未经过预处理和筛选）时，这些风险会显著放大。

在这种文档数据背景下，即使拥有最优秀的文本分块、向量嵌入和检索算法，它们也只能在充满噪声、过时或错误的数据之上运行。最终结果是，RAG 系统非但不能解决企业原有的信息混乱问题，反而可能延续甚至放大这些问题。

代码检索：从结构化检索到 DeepWiki

生成式 AI 能很好解决创建新项目的问题，但对于理解和修改存量代码，依然面临大量挑战。软件工程师和 AI 研究员各有不同的思考方式：工程师讲究经典的工程化思维，AI 则更倾向于“大力飞砖”的新一代方式，两种思维方式在过去几年中不断交融。

当前主流的 AI 编程工具在代码检索方面采用了多样化策略，它们通常结合传统基于关键字和结构的方法与新兴 AI 技术，以期在速度、准确性和上下文理解之间取得平衡。

关键信息检索：工程思维与结构化索引

当你的检索需要在客户端运行时，你需要考虑性能和效率问题。你需要思考如何在本地机器上进行高效检索，而不是依赖云端的计算能力。

而代码本身是结构化的，但这并不意味着主流的代码检索方式也是结构化的。我们在之前的文章中提过，主流的代码检索方式有两种：

• 基于关键信息的检索：如 Cline、Copilot、Cursor 等

• 基于代码和文本的检索：如 Bloop、SourceGraph Cody 等

从现有方式来看，主流是基于关键信息的检索方式。例如：

• Cline：AST（抽象语法树）+ 正则检索

• Copilot（2024）：生成关键词 + TreeSitter AST 中的关键信息（类、方法名等）搜索

• Cursor：Ripgrep 文本搜索 + 云端向量化

• Continue：基于 SQLite 的文本搜索 + LanceDB 本地向量化

• ……

简单来说，它们都是基于关键信息进行检索，只需要对代码的类名、方法名、变量名等进行检索即可。因此，用户输入是一个关键词或一句话，再由模型转换成查询条件，最后交给模型总结即可。

不过，关键词检索速度快，但对用户意图的理解有限，容易产生不相关的结果。而基于抽象语法树的检索虽能理解代码结构，但在处理语义相似性方面存在不足。

关键文档生成：预生成代码库文档

当检索可以在云端运行时，又需要考虑性能和效率问题。预先生成文档就变成一种非常理想的方案：它可以解决存量大量文档老旧的问题，并且能大幅提升检索效率。

以下是我们结合 DeepResearch 调研的：代码文档工具中预生成策略对比分析

如开头所说，尽管从理解深度来看，当前基于 RAG、文档检索的方式仍有改进空间，但一旦成为技术趋势，就会有大量工具和平台开始支持这个方向。

然而，这些工具在面对复杂或包含隐式逻辑的代码时，由于缺少准确的代码关联关系，对于缺少文档或大型项目来说，其作用变得非常有限。

与之相似，在模型能力进一步加强后，AI 友好的文档也成为一个重要话题。文档中代码的准确性变得越发关键，错误的文档和知识会让你的 AI 助手难以获得信任。

预生成上下文

预生成上下文是指在用户发起查询或生成请求之前，系统针对特定代码仓库、文档或 SDK，离线构建一组结构化的上下文数据。这些上下文经过理解、加工与组织，使其在运行时能够被快速检索和引用，从而提升代码智能体在生成、解释或检索代码时的准确性、相关性和响应速度。

其核心要素包括：

• 文档与代码的抽取与解析：包括 API 文档、源码注释、示例代码、变更日志等；

• 语义理解与摘要生成：提取关键能力、用途、限制等元信息；

• 向量化与索引构建：为快速语义检索构建 embedding 索引；

• 版本绑定与内容更新策略：确保上下文始终与特定版本保持一致；

AutoDev 探索：AutoDev Context Worker

基于上述想法和研究，我们开始构建 AutoDev Context Worker。结合 AutoDev IDE 插件的能力，以下是我们的基本思路：

• 深度项目解析与 AST 构建结构化：Context Worker 对整个项目（或指定模块范围）进行深度解析。这包括构建完整的 AST，识别所有函数、类、接口及其签名、注释（docstrings）。同时，分析项目依赖（内部模块间和外部库依赖），构建初步的依赖图。

• 自动化代码摘要与“意图”标注：对缺乏良好注释的代码块（函数、复杂逻辑段），尝试使用 LLM 预先生成简洁的摘要或“意图描述”。对一些关键的架构组件或核心算法，可预先打上特定标签或元数据。

• 构建项目级知识图谱：将解析出的代码实体（类、函数、变量等）及其关系（调用、继承、实现、引用等），并围绕领域模型构建知识图谱，标注实体的语义和上下文信息。

• ……

通过这些预计算和预组织工作，Context Worker 旨在为 AI 辅助研发功能（如代码生成、缺陷修复、代码重构、需求理解等）提供高质量、即时可用、深度结构化的上下文。这解决了传统 RAG 在处理复杂代码时可能出现的上下文不完整、不准确、检索效率低等问题，从而更好地实现“AI 友好架构”的理念，赋能更高级别的 AI 自动编程能力。

总结

本文探讨了预生成上下文作为增强 AI 编程能力的关键机制。传统 RAG 方法面临的不确定性和知识质量问题，使得预生成上下文成为一种更可靠的替代方案。通过对比分析当前代码检索方法的局限性，我们看到基于关键信息检索虽快速但理解有限，而 DeepWiki 等预生成文档工具虽有进步，但在处理复杂代码逻辑时仍有不足。

预生成上下文代表了 AI 友好架构的重要实践，它将传统软件工程的结构化思维与 AI 大模型的生成能力相结合，为下一代智能编程工具铺平了道路。 通过主动构建而非被动检索代码上下文，我们能够更好地赋能 AI 理解和修改现有代码库，使开发者能够更专注于创造性工作，而非重复性任务。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：预生成上下文：重构RAG的关键工程，构建AI编程底座要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题