代码代理中的检索增强生成（RAG）技术通过整合外部知识库来提升大型语言模型（LLM）在代码生成任务中的表现，但其核心挑战在于上下文工程。这包括处理代码的动态性、维护索引、保护知识产权、采用AST进行语义分块以保留代码结构、克服嵌入搜索在语义理解和可扩展性上的局限、设计混合检索方法（如结合grep和知识图谱）并引入重排机制，以及优化检索结果的融合策略。这些挑战共同决定了代码RAG系统的性能、可靠性和实用性。
1. RAG 在代码生成中的核心挑战与架构概述
1.1 RAG 系统的基本架构与工作流程
检索增强生成（Retrieval-Augmented Generation, RAG）系统通过整合外部知识源来增强大型语言模型（LLM）在代码生成等知识密集型任务中的表现。其核心架构通常包含两个主要阶段：数据准备（索引构建）和运行时（查询处理与生成）。在数据准备阶段，外部知识源（如文档、代码库）被处理成可检索的格式。这通常涉及将文档分割成较小的块（chunking），然后使用嵌入模型（embedding model）将这些文本块转换为向量表示（embeddings），这些向量捕获了文本的语义信息。生成的嵌入向量随后被存储在一个专门的向量数据库（vector database）中，如 Milvus, FAISS, 或 Chroma，这些数据库支持高效的相似性搜索。一些系统还会对原始数据进行转换或丰富，例如格式转换（PDF 到文本）或添加元数据，以提高检索结果的相关性。
在运行时阶段，当用户输入查询时，RAG 系统首先将用户查询同样通过嵌入模型转换为查询向量。然后，系统在向量数据库中执行相似性搜索，以找出与查询向量最接近的 top-K 个文档块。这些检索到的文档块，连同原始用户查询，被组合成一个增强的提示（prompt），并传递给大型语言模型。LLM 基于这个包含外部知识的提示来生成最终的响应。这种架构允许模型访问并利用其训练数据之外的最新或特定领域的信息，从而减少“幻觉”并提高输出的 factual correctness 。例如，在代码生成场景中，RAG 可以从代码库中检索相关的 API 定义、代码片段或文档，以指导 LLM 生成更准确、更符合上下文的代码。
一个典型的 RAG 系统可以进一步细分为以下几个核心组件 ：
- 文档加载器 (Document Loader)：负责从各种来源（如 PDF 文件、网页、数据库）导入文档。
- 文本分块器 (Text Chunker)：将大型文档分割成更小、更易于管理的片段，以便进行索引和检索。分块策略对检索质量至关重要，尤其是在处理代码等结构化内容时，需要保留语义边界。
- 嵌入模型 (Embedding Model)：将文本块转换为数值向量（嵌入），这些向量能够捕捉文本的语义含义。
- 向量存储 (Vector Store)：存储和索引嵌入向量，以便进行高效的相似性搜索和检索。
- 检索器 (Retriever)：根据用户查询，从向量存储中查找并返回最相关的文档块。
- 语言模型 (Language Model)：接收用户查询和检索到的上下文信息，并生成最终的响应或代码。
- 提示模板 (Prompt Templates)：指导语言模型如何有效地利用检索到的信息来生成响应。
整个工作流程可以概括为：用户输入查询 -> 查询编码为向量 -> 检索器在知识库（向量数据库）中搜索相似文档 -> 检索到的文档与原始查询合并 -> 生成模型基于合并后的信息生成响应 -> 向用户返回最终输出。一些高级的 RAG 系统还可能包含反馈循环，允许用户对输出进行评价，从而持续改进系统性能，例如通过识别检索或生成中的问题，或改进底层数据质量。此外，为了处理更复杂的场景，如代码生成中的自我修正，可以使用 LangGraph 等工具构建具有状态管理和条件控制流的代理，实现迭代生成和错误处理。
1.2 代码代理中 RAG 面临的核心上下文工程挑战
在代码代理（Code Agent）场景下应用RAG技术时，上下文工程面临着诸多独特的挑战，这些挑战主要源于代码本身的特性、开发环境的动态性以及开发者对精确性和可靠性的高要求。首先，代码的精确性和结构性对检索和生成都提出了更高标准。与自然语言文本相比，代码具有严格的语法和语义规则，微小的错误都可能导致程序无法运行或行为异常。因此，RAG系统在检索代码片段时，不仅要考虑语义相关性，还要关注代码的正确性、完整性和可用性。例如，检索到的函数片段可能需要包含其所有依赖项（如导入的库、定义的变量等）才能被正确理解和复用。传统的基于文本相似度的检索方法在处理代码时，可能难以捕捉到这些深层次的依赖关系和结构信息，导致检索到不完整或脱离上下文的代码片段。
其次，代码库的规模、复杂性和动态性是RAG系统在代码领域面临的另一大挑战。大型软件项目的代码库可能包含数百万甚至数十亿行代码，分布在成千上万个文件中，并且这些代码库通常处于持续演化和更新的状态。这给索引构建和维护带来了巨大压力。保持索引与代码库的实时同步，确保检索到的信息是最新的，是一个复杂的技术难题。此外，代码库内部往往存在复杂的模块依赖、继承关系和调用链路，理解这些关系对于准确检索和生成代码至关重要。简单的文本分块和嵌入方法可能无法有效处理这种复杂的结构，导致检索结果缺乏必要的上下文信息。例如，一个查询可能针对某个特定的API使用方法，但如果检索系统不理解该API所属的模块或类，就可能返回不相关或过时的代码示例。
再者，代码语义的多样性和上下文依赖性也对RAG系统提出了考验。同一段代码在不同的上下文中可能具有不同的含义或作用。例如，一个名为“process”的函数，在数据处理模块和系统管理模块中可能实现完全不同的功能。RAG系统需要能够理解查询的深层意图以及代码所处的具体上下文，才能返回真正有用的结果。此外，开发者在使用代码代理时，往往期望获得能够直接集成到当前工作环境中的代码建议。这意味着RAG系统不仅要生成语法正确的代码，还要确保其风格、使用的库版本等与现有项目保持一致。这要求RAG系统具备更深层次的上下文感知能力，包括理解项目特定的配置、依赖关系以及编码规范。缺乏这种能力，生成的代码可能虽然“正确”，但在实际项目中难以应用。
最后，评估RAG在代码生成中的效果本身也是一个挑战。如何客观地衡量检索到的代码片段对最终生成代码质量的贡献，以及如何评估生成代码的正确性、效率和可维护性，都需要精心设计的评估指标和基准测试（Benchmark）。简单的文本匹配指标（如BLEU、ROUGE）可能无法完全反映代码的质量。需要结合编译通过率、单元测试结果、甚至人工评估等多种手段，才能全面评估代码RAG系统的性能。这些挑战共同构成了代码代理中RAG上下文工程的核心难题，需要综合运用软件工程、机器学习、自然语言处理等多个领域的技术来加以解决。
2. 代码索引与上下文检索的挑战
2.1 代码的动态性与索引维护难题
代码库的本质是高度动态的，新的提交、分支、合并和重构不断发生，这使得为代码 RAG 系统维护一个最新且相关的索引成为一项持续的挑战。与相对静态的文档知识库不同，代码库的频繁变更意味着索引会迅速过时。如果索引不能反映代码库的最新状态，检索器可能会返回不再有效或已被更优实现替代的代码片段，从而误导代码生成过程，导致生成过时、低效甚至错误的代码。例如，一个被检索到的函数可能在最新的代码版本中已经被弃用或其签名发生了改变，如果 LLM 基于旧版本的上下文生成代码，就会产生兼容性问题。正如 Cline 博客文章所指出的，索引本质上是特定时间点的冻结快照，而代码库则会不可避免地与索引发生偏离 。这种偏离会导致 RAG 系统检索到过时或不相关的上下文，进而影响代码生成或理解任务的准确性和可靠性。
维护索引的实时性或近实时性需要强大的基础设施和高效的索引更新策略。全量重新索引（即每次代码库变更后都重新处理整个代码库并生成新的嵌入向量）在计算资源和时间上都是非常昂贵的，特别是对于大型企业级代码库，可能包含数百万行代码和数千个文件。增量索引是一种潜在的解决方案，它只处理发生变更的部分代码。然而，实现高效的增量索引也面临挑战，例如需要精确识别变更的影响范围（因为一个文件的修改可能影响其他依赖它的文件的语义），以及确保增量更新过程中索引的一致性和完整性。此外，版本控制系统（如 Git）的复杂性，包括分支、合并和标签，使得确定何时以及如何更新索引变得更加复杂。如果 RAG 系统需要跨多个分支或特定版本进行检索，索引策略需要能够支持这种多版本环境下的上下文检索，这进一步增加了索引维护的难度。因此，如何在索引新鲜度、计算成本和索引复杂性之间取得平衡，是代码 RAG 系统面临的一个核心工程难题。
2.2 代码知识产权的考量
在为企业构建代码 RAG 系统时，代码的知识产权（IP）和数据安全问题是一个不容忽视的关键挑战。企业代码库通常包含专有算法、业务逻辑和未公开的 API，这些都是公司的核心资产。将这些代码索引并用于 RAG 系统，尤其是在使用第三方 LLM 服务或云基础设施时，会引发数据泄露和 IP 被盗用的风险。如果代码片段被发送到外部 LLM 进行生成，或者嵌入向量存储在不受企业完全控制的向量数据库中，就可能存在敏感信息暴露给未经授权方的可能性。例如，一个包含核心业务逻辑的代码块被检索并作为上下文发送给一个公共的 LLM API，理论上该代码就可能被服务提供商记录或用于模型训练，从而泄露商业机密。传统的 RAG 方法涉及将数据（在此处为源代码）分块、创建嵌入向量，并将这些向量存储在向量数据库中以便检索 。然而，将整个代码库或其关键部分以嵌入向量的形式存储在外部或第三方管理的向量数据库中，可能会引发严重的安全和知识产权泄露风险。
因此，企业在部署代码 RAG 系统时，必须仔细评估和解决这些 IP 问题。这可能涉及到选择允许数据本地化（on-premise）或私有云部署的解决方案，确保代码数据始终在企业控制的边界内。对于嵌入模型和 LLM，企业可能会选择使用可自行部署的开源模型，或者与提供严格数据保密协议的供应商合作。此外，还需要考虑对索引和检索过程进行审计和监控，以追踪代码上下文的使用情况并检测潜在的数据泄露。在某些情况下，可能需要对代码进行匿名化处理或使用差分隐私技术来保护敏感信息，但这又可能影响代码的语义完整性和检索的准确性。例如，Cline 工具选择不索引用户的代码库，其设计决策部分原因就是为了更好地保护代码的知识产权和安全性 。GitHub Copilot 允许用户通过配置 includePaths/excludePaths 来控制在设置中索引哪些文件夹，以防止敏感文件被索引 。因此，在代码 RAG 的便利性和 IP 保护的需求之间取得平衡，需要仔细的架构设计、技术选型和策略制定，这对于获得企业信任和推动 RAG 技术的采用至关重要。
2.3 传统分块方法对代码语义的破坏
在 RAG 系统中，将大型文档或代码库分割成较小的、可管理的块（chunking）是索引和检索的关键步骤。然而，传统的分块方法，特别是那些为通用文本设计的简单启发式方法（如固定大小的分块或按行分块），在处理具有严格语法和语义结构的代码时，往往会破坏代码的语义完整性。代码的逻辑单元，如函数、类、循环或条件块，具有明确的开始和结束边界，这些边界对于理解代码的功能至关重要。当分块过程不考虑这些语义边界时，一个逻辑单元可能会被不恰当地分割到两个或多个不连续的块中，或者一个块可能包含多个不相关的、被强行合并的逻辑单元片段。正如 Cline 博客文章所比喻的，将代码分块进行嵌入，就像试图通过听随机的 10 秒片段来理解一部交响乐 。这种简单粗暴的分块方式会“撕裂”代码的内在逻辑。例如，一个函数调用可能位于第 47 个块中，而其定义却在第 892 个块中，解释其存在原因的关键上下文则可能散落在十几个其他片段中 。
这种语义结构的破坏会对后续的检索和生成阶段产生负面影响。如果检索到的代码块不包含完整的函数定义（例如，只包含了函数签名而缺少函数体，或者函数体被截断），那么 LLM 将无法获得足够的信息来理解该函数的功能或正确地使用它。如图1所示（在原始论文中），一个计算统计信息的 compute_stats 函数如果被固定大小的分块器从中间截断，模型可能会丢失关于其返回值的关键信息，从而导致生成错误的调用代码。另一方面，如果一个块合并了来自不同函数或类的无关代码片段，这些片段可能会在语义上相互冲突或引入混淆，同样会降低生成代码的质量。例如，检索到的块可能包含函数 A 的一部分和函数 B 的一部分，它们之间没有直接的调用关系或逻辑联系，这会使得 LLM 难以聚焦于与用户查询真正相关的代码。Google Cloud在其关于代码生成RAG的博客中也强调，对于代码，建议选择尊重自然代码边界的分块方法，例如函数、类或模块的边界。因此，对于代码 RAG 系统而言，采用能够识别并尊重代码语义边界的分块技术至关重要，以确保检索到的上下文是自包含的、语义连贯的，并且能够有效地支持代码生成任务。
3. AST 解析与沿语义边界分块的技术
3.1 抽象语法树 (AST) 在代码理解中的应用
抽象语法树（Abstract Syntax Tree, AST）是源代码抽象语法结构的一种树状表示。它以树的形式表现编程语言的语法结构，树上的每个节点都表示源代码中的一种结构，例如表达式、语句、函数声明、类定义等，而不再包含像括号、分号这样的无关紧要的语法细节。AST 是编译器设计和程序分析中的核心数据结构，因为它清晰地揭示了代码的层次结构和语义关系。在代码理解和处理工具中，AST 被广泛应用于各种任务，如代码格式化、静态分析、代码重构、代码转换（transpilation）以及代码生成。通过遍历和操作 AST，工具能够精确地定位代码中的特定元素，理解它们之间的依赖关系，并对其进行修改或转换，而无需直接处理原始的文本字符串，这大大提高了代码处理的准确性和可靠性。例如，在代码编译过程中，AST 是词法分析和语法分析之后的中间表示，用于后续的语义分析、代码优化和代码生成。
在代码 RAG 系统的上下文中，AST 为代码的深度理解和结构化处理提供了强大的工具。通过解析代码生成 AST，系统可以更准确地把握代码的语义信息，而不仅仅是表面的文本相似性。这使得 RAG 系统能够进行更智能的代码分块、更精确的代码检索以及更有效的上下文构建。例如，AST 可以帮助识别代码中的关键实体（如函数、类、变量）及其作用域，从而指导分块过程沿着自然的语义边界进行，避免破坏代码的逻辑完整性。此外，AST 还可以用于代码相似性比较、代码转换、缺陷检测等多种代码智能任务，为 RAG 系统提供更丰富的代码理解和分析能力，从而提升其在代码生成、代码补全等场景下的性能。一些工具如 Tree-sitter 提供了多语言的 AST 解析能力，使得开发者可以方便地处理不同编程语言的代码。Refact.ai 在其 RAG 系统中就使用了 AST 解析器 (tree-sitter) 来分析项目中的所有源文件，构建内存中的索引，从而实现快速的“转到定义”和“查找引用”等功能，并将这些结构化信息用于代码补全。
3.2 基于 AST 的语义分块方法 (如 cAST)
为了克服传统分块方法在代码RAG中破坏语义结构的问题，研究人员提出了基于抽象语法树（AST）的语义分块技术。其中，cAST (Chunking via Abstract Syntax Trees) 是一个典型的代表，它通过解析源代码生成 AST，然后应用一种“先分割后合并”的递归算法，将树结构转换为与语法边界更好对齐的代码块 。cAST 的设计哲学围绕四个核心原则：句法完整性 (Syntactic Integrity)，即尽可能使块边界与完整的句法单元对齐，避免代码结构碎片化；最大信息密度 (Maximum Information Density)，即在固定大小限制内最大化每个块的内容，以优化信息利用率；语言独立性 (Language Independence)，即算法不依赖于任何特定语言的启发式规则，从而能够在多种编程语言和代码相关任务中无缝运行；以及即插即用兼容性 (Plug-and-Play Compatibility)，即连接块必须能够逐字再现原始文件，从而能够无缝替换现有 RAG 管道中的分块模块 。cAST 方法通过利用 Tree-sitter 这样的库进行 AST 解析，支持多种编程语言 。
cAST 的具体分块过程可以概括为：首先，将源代码解析成 AST；然后，从 AST 的根节点开始，自顶向下遍历树结构，尝试将较大的 AST 节点（例如，一个函数定义或一个类定义）放入单个块中，如果节点过大超出了预设的块大小限制，则递归地将其分割成更小的子节点进行处理 。在分割之后，为了最大化信息密度并避免产生过多过小的块，cAST 还会执行一个贪婪合并步骤，将相邻的、合并后仍满足大小限制的兄弟节点合并到同一个块中 。一个关键的优化在于块大小的度量方式。cAST 选择使用非空白字符的数量而不是行数来衡量块的大小，因为两个行数相同的代码段可能包含的代码量差异很大，而且 AST 对齐的块在物理代码长度上自然会有差异（例如，单行导入语句与整个类体）。通过这种基于字符数的度量方式，可以更精确地平衡语义连贯性和信息保留，同时保持代码的结构完整性，确保在不同文件、编程语言和编码风格之间具有可比性 。这种方法不仅保留了代码的结构完整性，还捕获了文件、类和函数级别的元数据信息，极大地增强了上下文匹配能力 。
除了 cAST，还有其他一些工具和方法也利用了 AST 进行代码分块。例如，LlamaIndex 中的 CodeSplitter 使用第三方工具基于源代码生成 AST，然后利用 AST 识别每个源代码组件（如类、函数）的确切位置边界进行分块 。GenAIScript 工具也采用 AST 方法将源代码文件分割成有意义的块，以便 AI 能够独立地对每个代码结构（如类声明、方法声明）进行注释 。Refact.ai 在其 RAG 系统中使用 tree-sitter 解析源文件，获取函数定义、类等的位置，并在内存中建立从名称到位置的映射索引，同时也提到了在向量数据库 (VecDB) 索引时，会先将代码分割成完整的语言结构（如单个函数、单个类），甚至对类进行骨架化处理（缩短函数体），以便语义匹配能更好地工作 。这些方法都强调了利用 AST 保持代码结构完整性的重要性，从而为后续的检索和生成任务提供更高质量的上下文。
下表总结了 cAST 方法的关键特性：
特性描述
核心思想通过解析源代码为 AST，并应用“先分割后合并”的递归算法，生成与语法边界对齐的代码块。,
设计目标1. 句法完整性 (Syntactic Integrity) <br> 2. 最大信息密度 (Maximum Information Density) <br> 3. 语言独立性 (Language Independence) <br> 4. 即插即用兼容性 (Plug-and-Play Compatibility),
AST 解析库主要使用 Tree-sitter。,
分块算法自顶向下遍历 AST，尝试将大节点放入单个块；若超出大小限制则递归分割。执行贪婪合并以避免过多小块。,
块大小度量使用非空白字符的数量，而非行数，以确保内容密度的一致性和可比性。,
优势保持代码结构完整性，捕获元数据，增强上下文匹配，跨语言一致性，提高检索和生成质量。,
实现与可用性论文中提及代码开源，可通过
pip install astchunk 安装，支持 Python, Java, C#, TypeScript 等语言。
Table 1: cAST 方法的关键特性总结
这些基于 AST 的语义分块方法，特别是像 cAST 这样经过系统化设计和验证的技术，为代码 RAG 系统提供了更可靠的基础，显著提升了代码生成和维护任务的性能 。
3.3 语义分块对提升代码 RAG 性能的贡献
基于 AST 的语义分块技术，如 cAST 所展示的，通过生成结构良好、语义完整的代码块，对提升代码 RAG 系统的整体性能做出了显著贡献。其贡献主要体现在以下几个方面：首先，提高检索质量。语义分块确保了检索到的代码片段是具有完整逻辑意义的单元，例如整个函数或类，而不是被任意截断的代码片段。当 LLM 接收到这样的上下文时，它更容易理解代码的功能、输入输出以及与其他部分的交互方式。这直接减少了由于上下文不完整或包含无关代码而导致的检索噪声，使得 LLM 能够更准确地把握用户查询的意图并找到真正相关的解决方案。例如，在 cAST 论文中，通过使用结构感知的分块方法，在 RepoEval 代码检索任务上的平均 Recall@5 指标提升了 4.3 个百分点，这表明语义分块能够帮助系统更有效地找到与查询相关的代码。
其次，提升生成代码的准确性和相关性。当 LLM 接收到语义完整的代码块作为上下文时，它更有可能生成语法正确、逻辑合理且与现有代码库风格一致的代码。因为上下文提供了清晰的边界和依赖信息，LLM 可以更好地模仿这些模式。例如，如果检索到的上下文是一个完整的、设计良好的函数，LLM 可以学习其参数处理、错误处理和数据转换的方式，从而生成更健壮的代码。cAST 论文的实验结果显示，在 SWE-bench 代码生成任务（专注于解决 GitHub issue）上，使用其分块方法后 Pass@1 指标平均提高了 2.67 个百分点，这直接证明了语义分块对生成质量的积极影响。相比之下，如果上下文是破碎的，LLM 可能会错误地推断函数的行为，或者生成与现有代码库不兼容的代码。
第三，增强上下文利用率。语义分块有助于在有限的上下文窗口内填充更有价值的信息。由于每个块都是一个逻辑单元，LLM 可以更有效地从每个块中提取有用的知识，而不是在混杂的、不连贯的文本中寻找线索。这意味着即使上下文窗口大小有限，LLM 也能获得更高质量的输入，从而提高其理解和生成能力。这对于处理大型代码库尤为重要，因为不可能将整个代码库都塞进上下文窗口，因此选择哪些部分作为上下文就显得至关重要。此外，基于 AST 的分块能够更忠实地捕获文件、类和函数级别的元数据，这对于需要结合代码和自然语言进行上下文匹配的混合任务尤其有益。
第四，改善跨语言和跨任务的适应性。由于 AST 提供了一种与具体编程语言语法细节相对独立的代码结构表示，基于 AST 的分块方法（如 cAST）具有更好的跨语言泛化能力。这意味着该方法可以在多种编程语言上保持一致的代码分块效果，而不会像基于行或固定大小的分块那样容易受到特定语言语法和格式的影响。例如，在 CrossCodeEval 基准测试中，cAST 实现了高达 4.3 分的提升。总而言之，通过确保代码块的结构完整性和语义连贯性，基于 AST 的语义分块为代码 RAG 系统提供了更高质量的检索上下文，从而在检索和生成两个关键环节都带来了显著的性能提升，并增强了系统的鲁棒性和跨语言适用性。
4. 嵌入搜索作为检索启发式方法的局限性
4.1 嵌入模型在代码语义理解上的不足
尽管嵌入模型（Embedding Models）在捕捉文本语义方面取得了显著进展，并被广泛应用于 RAG 系统的检索阶段，但在处理代码这种具有严格结构和复杂逻辑的特殊“语言”时，其语义理解能力仍存在局限性。代码的语义不仅仅体现在标识符名称或注释上，更深层次地蕴含在其控制流、数据流、API 调用模式、以及与其他代码组件的交互中。简单的文本嵌入模型，尤其是那些主要针对自然语言训练的模型，可能难以完全捕捉这些复杂的、结构化的语义信息。例如，两个功能上等价的代码片段，如果使用了不同的变量命名约定、代码风格，或者通过不同的库函数实现了相同的逻辑，它们的文本嵌入向量在向量空间中的距离可能较远，尽管它们在语义上是高度相似的。反之，两个文本上相似（例如，都包含了某个 API 的关键词）但功能完全不同的代码片段，其嵌入向量可能意外地接近，导致检索混淆。
嵌入模型在处理代码中的细微差别和特定领域术语时可能不够精确。代码中经常包含对 API 调用、库函数、框架特定注解等的精确引用。这些元素的细微变化（如参数顺序、可选参数、特定版本的方法）可能导致完全不同的行为。通用嵌入模型可能无法充分区分这些细微差别，导致检索到看似相关但实际上并不适用的代码片段。例如，一个查询要求使用特定版本的库进行某个操作，但嵌入搜索可能返回基于旧版本或不同库的代码，因为它们在高维向量空间中的表示可能仍然比较接近。此外，代码中的标识符（如变量名、函数名）往往是简短且高度领域特定的，它们的语义可能难以被通用嵌入模型准确捕捉，除非模型在大量代码数据上进行了微调。一篇博文指出，嵌入模型在处理用户查询时，可能只关注查询中的字面词语，而无法理解其背后更广泛的上下文需求 。例如，对于查询“编写代码使结账时日历中所有选定的日期变为红色”，嵌入模型可能会找到包含“日期”、“红色”、“日历”和“结账”等词语的代码，但这些代码片段可能并非解决该特定问题所需的。
4.2 代码库规模增长带来的可扩展性问题
随着代码库规模的不断增长，尤其是在大型企业或开源项目中，依赖嵌入搜索作为核心检索机制的 RAG 系统面临着严峻的可扩展性挑战。这些挑战主要体现在计算资源、存储需求、检索延迟和索引更新效率等多个方面。首先，嵌入向量的计算成本会随着代码库的增大而显著增加。为代码库中的每个代码块（chunk）生成高质量的嵌入向量本身就是一个计算密集型任务，尤其是在使用大型、复杂的嵌入模型时。对于一个包含数百万甚至数十亿行代码的代码库，将其全部转换为向量并存储起来，需要巨大的存储空间。例如，存储十亿个1024维的float32向量就需要大约4TB的内存。除了存储原始向量，为了支持高效的相似性搜索，还需要构建索引结构（如HNSW、IVFADC等近似最近邻ANN索引）。这些索引结构本身也会占用大量内存，并且其构建时间会随着数据量的增加而显著增长，对于超大规模数据集，构建索引可能需要数天时间。
其次，检索效率也可能成为瓶颈。在庞大的向量数据库中进行相似性搜索，即使使用优化的ANN算法，要保持低延迟（例如亚秒级响应）也是一项复杂的工程挑战。ANN算法本身需要在搜索速度、召回率（准确性）和内存使用之间进行权衡。随着向量数量的增加，为了维持一定的召回率，可能需要在算法参数上做出妥协，导致搜索速度下降。例如，HNSW图中的层级连接虽然能加速遍历，但在处理数十亿向量时，图构造和查询参数（如efConstruction和efSearch）的调整变得非常关键，不当的设置可能导致内存占用过高或查询性能不佳。GitHub Copilot 的本地语义索引默认处理大约 2000-2500 个文件，如果项目文件数量超过此限制（例如，达到 3000+），则会回退到“基本索引”模式，即仅进行关键词搜索，不再使用嵌入 。
再次，索引的更新和维护在大型动态代码库中变得更加复杂。代码库的频繁变更需要索引的相应更新。对于大规模代码库，即使是增量更新也可能涉及大量的重新计算和索引重建工作，这需要精心的调度和资源管理，以避免对系统性能产生负面影响。此外，随着代码库的演变，嵌入模型本身也可能需要重新训练或微调以适应新的代码模式或领域术语，这又带来了额外的复杂性和成本。因此，单纯依赖嵌入搜索的 RAG 系统在面对不断增长的代码库时，可能会遇到性能瓶颈和运营成本过高的问题，需要结合其他检索技术或采用更高级的可扩展性策略。
4.3 嵌入向量的计算、存储与实时更新挑战
嵌入向量的计算、存储和实时更新是代码 RAG 系统中与嵌入搜索相关的核心工程挑战，尤其是在处理大规模和动态代码库时。计算成本是首要考虑因素。高质量的嵌入通常由大型 Transformer 模型生成，这些模型在推理时需要大量的计算资源（CPU 或 GPU）和时间。对于一个大型代码库，首次为所有代码块生成嵌入向量可能需要数小时甚至数天，消耗大量的 CPU 或 GPU 资源。例如，使用OpenAI的API进行嵌入，费用是按处理的token数量计算的，对于数百万个代码块，累积成本可能相当可观。虽然可以使用开源模型在本地进行嵌入以避免API费用，但这又需要相应的GPU硬件和运维投入。
存储成本也是一个不容忽视的问题。每个代码片段生成的嵌入向量通常是一个数百甚至数千维的浮点数数组。对于大型代码库，累积起来的嵌入数据量可能非常庞大。例如，如果每个嵌入向量占用 1KB 的空间（对于一个 768 维的 float32 向量，这已经是一个相对保守的估计），那么一百万个代码片段就需要大约 1GB 的存储空间。这还不包括向量数据库本身为了高效检索而构建的索引结构所占用的额外空间。选择合适的向量数据库并进行有效的存储管理，以控制成本并保证查询性能，是一个重要的工程任务。
实时更新是嵌入向量面临的另一个严峻挑战。代码库是动态变化的，新的代码被添加，旧的代码被修改或删除。为了保持 RAG 系统检索结果的准确性和相关性，底层的嵌入向量也需要随之更新。然而，频繁地重新计算整个代码库的嵌入向量是不现实的。因此，需要设计增量更新策略。当一个代码文件被修改时，只需要重新计算该文件对应的嵌入向量，并更新向量数据库中的相应条目。但这需要精确追踪代码的变更，并能够将代码文件的变更映射到其对应的嵌入向量。更复杂的是，一个代码片段的修改可能会影响其他相关代码片段的语义，从而可能需要级联更新它们的嵌入。例如，一个公共 API 的修改可能会影响所有调用该 API 的代码。处理这种依赖关系和传播变更的影响，同时保证更新过程的效率和原子性，是极具挑战性的。一些研究开始探索动态更新嵌入图的方法，当一个节点的嵌入更新后，其邻居节点的嵌入也会相应更新 ，但这增加了系统的复杂性。
5. 混合检索方法：提升代码 RAG 的检索质量与效率
5.1 结合传统搜索 (如 grep) 与嵌入搜索
在代码 RAG 系统中，单纯依赖嵌入搜索或传统的关键词搜索（如 grep）都存在各自的局限性。为了克服这些局限，混合检索（Hybrid Retrieval）策略应运而生，它结合了不同检索技术的优势，以期在更广泛的场景下获得更优的检索结果。传统的基于关键字的搜索工具（例如 grep 或其更高效的替代品 ripgrep）在代码检索中具有其独特的优势，尤其是在需要精确匹配特定标识符、函数名或错误代码时。然而，它们通常缺乏对代码语义的理解能力。相比之下，基于嵌入的语义搜索能够捕捉代码片段的深层含义，但对于一些具体的、字面性的查询，其效果可能不如关键字搜索直接。因此，将两者结合起来的混合检索策略，可以取长补短，提升整体检索性能。
一种常见的实现方式是利用 grep 进行初步检索，筛选出可能相关的文件或代码行，然后对这些初步结果应用嵌入搜索进行语义排序和精炼。例如，一篇 Medium 文章 详细介绍了如何在 RAG 系统中集成 grep，并提供了一个 Python 类 GrepRetriever 的实现。更进一步，文章还提出了一个 HybridGrepRetriever 类，该类将 grep 检索器与基于句子转换器（Sentence Transformers）的嵌入模型相结合，允许用户为 grep 结果和语义搜索结果分别设置权重。另一种方法是并行执行两种搜索，然后对各自返回的结果列表进行融合（Ensemble）和重排。例如，CodeSignal 的一篇文章 提供了一个在 Rust 中实现 BM25 与嵌入检索结合的实例，通过一个可调的 alpha 参数对两种得分进行加权平均。Superlinked 的一篇文章 展示了如何使用 LangChain 实现一个集成检索器（Ensemble Retriever），该检索器结合了关键词检索器（BM25Retriever）和向量存储检索器（Chroma DB），通过设置不同的权重来调整两种检索方法对最终结果的影响。这种混合方法不仅保留了 grep 在精确匹配上的优势，也利用了嵌入模型在语义理解上的能力，从而能够更全面地满足代码检索的需求。
5.2 基于知识图谱的代码检索与上下文增强
知识图谱（Knowledge Graph, KG）为代码RAG系统提供了一种强大的上下文增强手段。与单纯依赖文本相似性的嵌入搜索不同，知识图谱能够以结构化的方式表示代码元素（如函数、类、变量、API）及其之间的复杂关系（如调用关系、继承关系、参数依赖等）。通过构建一个编程知识图谱（Programming Knowledge Graph, PKG），可以将代码库中的显式和隐式知识整合起来，形成一个丰富的语义网络 。在检索阶段，当用户提出查询时，RAG 系统不仅可以进行文本匹配或嵌入相似性搜索，还可以利用 PKG 进行更深入的语义推理和关联发现。例如，PKG 可以帮助系统理解一个 API 的上下游调用链，或者找到一个特定设计模式在代码库中的应用实例。
论文 中提出的框架利用 PKG 进行细粒度的代码检索，并通过树剪枝技术（tree-pruning technique）来减少不相关的上下文信息，从而更精确地定位到与用户需求最相关的代码片段。此外，PKG 还可以与重排机制（re-ranking mechanism）结合，进一步提升检索结果的质量，并减少 LLM 因接收到不相关信息而产生的“幻觉”现象。通过在 HumanEval 和 MBPP 等基准测试上的评估，该方法在 Pass@1 准确率上取得了显著提升，证明了基于知识图谱的检索和上下文增强在代码 RAG 中的有效性 。通过将代码库的复杂结构和依赖关系显式地编码到知识图谱中，RAG 系统能够进行更深层次的语义理解和推理，从而超越简单的文本匹配，提供更精准、更丰富的上下文信息，这对于处理复杂的代码查询和生成高质量的代码至关重要。
5.3 检索结果的重排 (Re-ranking) 机制
在 RAG 系统中，初步检索阶段可能会返回大量相关的或不那么相关的文档或代码片段。为了提高最终生成结果的质量，并确保传递给大型语言模型（LLM）的上下文信息是最优的，引入检索结果的重排（Re-ranking）机制至关重要。重排机制的目标是对初步检索到的结果列表进行重新排序，将最相关、信息量最大、对当前查询最有帮助的条目排在前面。一篇 Medium 文章 将重排定位为 RAG 系统中提升生成质量的关键环节，指出传统的检索方法可能会返回带有噪声或不那么相关的结果，而重排步骤能够确保将上下文最合适的文档置于顶部。该文还提供了一个使用 Hugging Face 的 sentence-transformers 库进行重排的 Python 代码示例，其中使用了交叉编码器（Cross-Encoder）模型 cross-encoder/ms-marco-MiniLM-L-6-v2 来对检索到的文档进行重新评分和排序。
Google Cloud 的文档 介绍了如何在 Vertex AI RAG Engine 中使用其排名 API 进行重排，开发者可以在工具配置中启用重排，并指定使用的排名模型。Vertex AI RAG Engine 还支持使用 LLM（如 Gemini 模型）作为重排器。另一篇 nb-data.com 上的文章 同样使用了 cross-encoder/ms-marco-MiniLM-L-6-v2 模型进行重排，并展示了如何将基于 LLM 的评分与交叉编码器的评分结合起来进行并行重排。Adasci.org 的一篇文章 将重排过程分解为初始检索、评分与排序、重排以及最终选择顶部文档进行生成几个步骤，强调重排模型能够利用更高级的特征和技术，更精确地评估文档的相关性。LanceDB 的博客文章 将重排视为改进 RAG 流程的最简单方法之一，其核心思想是先利用召回率的优势获取较多相关的块，然后使用一个更强大的模型对这些块进行重排，以提高精确率。NVIDIA 的技术博客 则展示了如何在 LangChain 中使用 NeMo Retriever reranking NIM 进行重排。Pinecone 的学习资源 中也提到了重排器和两阶段检索的重要性。Rankify 作为一个全面的 Python 工具包，支持多种重排方法。Comet ML 的一篇文章 提出了一种使用 GPT-4 和提示工程进行重排的定制实现。通过有效的重排，可以显著提升最终传递给 LLM 的上下文窗口的质量，从而引导 LLM 生成更准确、更相关的代码。
5.4 混合 RAG 架构的优势与实现考量
混合 RAG 架构通过整合多种检索技术和上下文增强策略，旨在克服单一方法在代码理解和生成任务中的局限性，从而提供更优的性能和鲁棒性。其核心优势在于灵活性和互补性。例如，通过结合基于关键字的搜索（如 grep 或 BM25）和基于嵌入的语义搜索，系统既能处理需要精确匹配的查询，也能理解模糊的、基于意图的查询。知识图谱的引入则进一步增强了系统对代码结构、依赖关系和深层语义的理解能力，使得检索结果更具洞察力。重排机制作为混合架构中的关键一环，能够对来自不同检索源的候选结果进行统一评估和优化排序，确保最相关的信息被优先传递给 LLM 。这种多策略的组合使得混合 RAG 能够适应更广泛的查询类型和代码库特性，显著提升检索的准确率和召回率。
然而，实现一个高效的混合 RAG 架构也面临诸多考量。首先是复杂性和集成成本。协调不同的检索模块、设计有效的融合策略（如分数融合、结果合并）以及管理可能存在的异构数据源，都会增加系统的复杂性和开发维护成本。其次是性能权衡。例如，虽然交叉编码器在重排阶段能提供更精确的相关性评分，但其计算开销远大于双编码器，可能影响系统的整体响应延迟。因此，需要在检索质量、召回速度和资源消耗之间进行仔细的权衡。此外，参数调优也是一个挑战，例如在混合检索中如何设置不同检索器的权重，或者在重排中选择合适的模型和策略，这些往往需要根据具体的应用场景和数据集进行大量的实验和优化。最后，确保知识库的一致性和实时性在混合架构中同样重要，需要建立有效的机制来同步不同检索模块所依赖的数据和索引。尽管存在这些挑战，但混合 RAG 架构所展现出的潜力使其成为提升代码代理能力的重要方向。
6. 检索到的代码片段在生成阶段的融合策略
6.1 不同融合策略（如 SIF, SEF, VDF）的比较
在检索增强代码生成（RAG）的生成阶段，如何有效地将检索到的多个代码片段与原始的自然语言描述（查询）融合，以构建一个信息丰富且结构合理的输入供大型语言模型（LLM）使用，是一个关键问题。一篇关于检索增强代码生成的实证研究论文中提到了几种不同的融合策略，包括顺序整合融合 (Sequential Integration Fusion, SIF)、样本扩展融合 (Sample Expansion Fusion, SEF) 和向量化解码融合 (Vectorized Decoding Fusion, VDF)。这些策略在如何组织和利用检索到的代码片段方面有所不同。
顺序整合融合 (SIF) 的核心思想是将检索到的 k 个代码片段直接拼接到原始的自然语言输入之后，形成一个扩展的输入序列，通常使用一个特殊的标记（例如 <retrieved_code>）进行分隔。这种方法的优点是简单直观，易于实现。然而，当检索到的片段数量较多或长度较长时，可能会迅速耗尽 LLM 的上下文窗口限制，并且可能缺乏对片段之间关系的显式建模。
样本扩展融合 (SEF) 则采用了一种更为动态的方式。它首先基于原始查询和每个检索到的代码片段，生成多个“扩展的”输入样本。每个样本都包含原始查询和一个（或少数几个相关的）检索到的代码片段，而它们的目标代码保持不变，仍然是原始的目标代码。这样，训练数据集的规模（不包括原始数据）就扩大了 k 倍。在生成阶段，模型可以根据原始的自然语言输入以及与之最相似的检索到的代码片段来生成代码。SEF 的优势在于它允许 LLM 更细致地处理每个检索到的片段，并且可以通过并行处理来提高效率。然而，它可能需要更复杂的后期整合逻辑，并且如果每个片段都独立处理，可能会忽略片段之间的潜在关联。
向量化解码融合 (VDF) 则引入了更复杂的编码和解码机制。在这种策略中，每个由 SEF 生成的实例（原始查询 + 一个检索到的代码片段）首先被编码成一个向量表示。然后，这些向量表示（对应于不同的检索片段）会被拼接起来，并与原始自然语言输入的向量表示进行某种形式的融合。这个融合后的向量表示最终被送入解码器（LLM 的解码部分）以生成目标代码。VDF 试图通过显式的向量操作来捕捉和融合来自不同检索片段的信息，可能能够更好地处理片段间的复杂关系，并生成更连贯和准确的代码。然而，它通常需要更复杂的模型架构和训练过程。
该实证研究 还提到了草图填充融合（Sketch Filling Fusion），这是一种更高级的融合策略，它首先从检索到的相关代码中提取出一个“草图”（sketch），然后利用这个草图来指导代码生成过程。研究表明，基于样本扩展融合，草图填充融合能够带来显著的性能提升，在三个数据集上，原始CodeT5模型的BLEU指标平均提高了14.83%，CodeBLEU指标平均提高了8.05%，是四种融合策略中表现最好的 。然而，草图填充融合的训练过程计算资源消耗非常大。因此，在平衡计算成本和性能提升方面，顺序整合融合被证明是一种更具成本效益的方法 。
下表总结了这些融合策略的主要特点：
融合策略 (Fusion Strategy)核心机制 (Core Mechanism)优点 (Pros)缺点 (Cons)参考文献 (References)
SIF将检索到的代码片段与原始查询文本直接拼接。实现简单，易于集成。可能超出上下文窗口限制，模型可能难以区分查询与上下文。,
SEF将每个检索到的代码片段与原始查询分别组合成新的训练样本，进行数据增强。允许LLM细致处理每个片段，可能提升对参考代码的理解。训练数据量增大，计算成本高；可能忽略片段间关联。,
VDF将SEF生成的实例编码为向量，在向量空间进行融合后输入解码器。可能更好地处理片段间复杂关系，避免信息截断。实现复杂，需要特定模型架构和训练。,
Sketch Filling从检索到的代码中提取“草图”（高层次结构），指导LLM生成代码。性能提升显著，为LLM提供结构化指导。训练计算资源消耗巨大。
Table 2: 不同融合策略的比较
除了上述方法，还有一些研究探索了将思维链（Chain-of-Thought, CoT）与RAG相结合的策略，以增强模型的推理能力。例如，CoT-RAG 框架通过知识图谱驱动的CoT生成、可学习的知识案例感知RAG以及伪程序提示执行来提升大型语言模型在复杂任务中的推理可信度和准确性。检索增强思维（Retrieval Augmented Thoughts, RAT） 则是一种将零样本CoT与RAG相结合的方法，它迭代地使用检索到的信息来修正CoT中的每一个思维步骤，从而逐步完善最终的回答。实验表明，RAT在代码生成、数学推理等任务上均能带来显著的性能提升，例如在代码生成任务上平均相对评分提高了13.63% 。RankCoT 则专注于通过引入重排序信号来优化CoT的生成，从而提高知识提炼的质量，使得生成模型能够产生更准确的答案。这些结合了CoT的融合策略，通过引导模型进行更结构化的思考和检索，进一步提升了RAG在复杂代码生成任务中的潜力。
6.2 融合策略对代码生成质量的影响
融合策略的选择对检索增强代码生成（RAG）的最终输出质量具有显著影响。不同的融合方法决定了检索到的上下文信息如何被大型语言模型（LLM）感知和利用，从而直接影响了生成代码的准确性、完整性、以及与原始需求的匹配程度。例如，在实证研究中，比较了Sample Input Fusion (SIF), Sample Expansion Fusion (SEF), 和Vectorized Decoding Fusion (VDF)等策略。研究发现，这些融合阶段的策略，连同检索阶段和生成阶段的模型选择，共同决定了模型的整体性能。一个设计良好的融合策略能够最大限度地发挥检索到的相关代码片段的价值，帮助LLM克服其固有的知识局限性和“幻觉”倾向。
如果融合策略过于简单，例如只是简单地将所有检索到的片段拼接起来（类似于SIF的极端情况），可能会导致几个问题。首先，上下文窗口可能很快被占满，使得LLM无法看到所有相关信息，或者无法为生成任务本身留出足够的空间。其次，如果检索到的片段之间存在冗余甚至冲突，简单的拼接可能无法解决这些问题，反而会混淆LLM。相反，更复杂的融合策略，如SEF或VDF，试图通过更结构化的方式来处理检索到的片段。SEF允许LLM分别考虑每个片段，然后整合结果，这可能有助于处理多样化的信息源。VDF则通过将片段信息编码到向量空间并进行融合，可能能够更好地捕捉片段间的语义关系和依赖，从而指导LLM生成更一致和准确的代码。研究表明，草图填充融合（Sketch Filling Fusion） 能够带来最显著的性能提升，在CodeT5模型上，相较于基线，草图填充融合在BLEU和CodeBLEU指标上分别实现了平均14.83%和8.05%的提升。相比之下，顺序整合融合（SIF） 虽然实现简单，但在某些情况下也能取得不错的性能，该研究推荐将SIF与BM25检索方法结合使用，因为这种组合在便利性和性能之间取得了良好的平衡。因此，选择或设计合适的融合策略，使其能够有效地整合检索到的知识，同时适应LLM的处理能力和任务需求，是提升代码RAG生成质量的关键环节。
6.3 上下文管理与依赖处理的挑战
在代码生成RAG系统中，上下文管理和依赖处理是确保生成代码质量和可用性的核心挑战。当LLM基于检索到的代码片段生成新代码时，它必须能够理解并正确运用这些片段所携带的上下文信息，包括变量、函数、类、库导入以及它们之间的复杂依赖关系。如果上下文管理不当，生成的代码可能会出现未定义的引用、错误的函数调用参数、或者与项目现有代码风格和结构不兼容等问题。例如，一篇关于RAG代码生成的博客提到，在生成与数据库交互的函数时，需要包含模式、连接方法和约束等详细信息，以最大限度地减少猜测。这突显了提供充足且精确上下文的重要性。
依赖处理尤为关键。代码库中的代码片段往往不是孤立的，它们依赖于其他文件、模块或第三方库中的定义和实现。RAG系统需要能够识别这些依赖关系，并在生成代码时确保这些依赖得到满足。例如，如果检索到的代码片段使用了某个特定的库函数，那么生成的代码也需要正确地导入该库，并且该库的版本需要与项目其他部分兼容。一些先进的RAG方法，如GitHub Copilot所采用的，会构建本地项目上下文，通过多轮排序来提供来自项目的相关片段，以回答用户的问题。这表明了处理项目级依赖和上下文的复杂性。此外，LLM的上下文窗口限制也是一个实际的约束，即使检索到了大量相关信息，也需要有效的策略来选择最重要的部分输入给模型，这进一步增加了上下文管理的难度。CodeRAG框架 通过构建需求图和DS-代码图，并利用基于代理的推理过程来显式地处理和检索这些支持性代码，从而在一定程度上解决了这个问题。因此，开发能够智能地管理上下文、解析依赖关系，并将这些信息有效地融入生成过程的RAG系统，是提升其在真实世界软件开发中实用性的关键。
7. 代码 RAG 的未来展望与研究方向
7.1 提升 RAG 系统的可扩展性与效率
随着代码库规模的持续增长和应用场景的日益复杂，提升 RAG 系统的可扩展性和效率是未来研究的核心方向之一。当前基于嵌入的检索方法在处理超大规模代码库时，面临着计算、存储和检索延迟的严峻挑战。未来的研究需要探索更轻量级、更高效的代码表示方法和索引结构。这可能包括开发针对代码特性优化的嵌入模型，这些模型能够在保持高语义保真度的同时，降低向量的维度和计算复杂度。此外，研究更先进的近似最近邻（ANN）搜索算法和分布式向量数据库技术，以支持在数十亿甚至数万亿级别的向量中进行快速、准确的检索，将是提升可扩展性的关键。增量索引和实时更新机制的优化也至关重要，以确保 RAG 系统能够快速响应代码库的动态变化，而不会引入显著的延迟或资源瓶颈。探索混合检索架构，将嵌入搜索与传统的基于符号的搜索（如关键词搜索、模式匹配）以及基于知识图谱的推理相结合，可以在不同层面利用各自的优势，从而在保证检索质量的前提下，提高系统的整体效率和可扩展性。
7.2 增强生成内容的真实性与可解释性
尽管 RAG 系统通过引入外部知识来减少 LLM 的“幻觉”，但在代码生成等对准确性要求极高的场景中，确保生成内容的真实性和可靠性仍然是一个持续的挑战。未来的研究需要致力于开发更强大的机制来验证和提升 RAG 生成代码的正确性、安全性和与现有代码库的一致性。这可能包括引入更严格的约束和验证步骤，例如结合静态分析、动态分析甚至形式化方法来检查生成的代码。增强 RAG 系统的可解释性也是一个重要的研究方向。理解 RAG 系统为何会检索特定的代码片段，以及这些片段如何影响最终的生成结果，对于调试系统、建立用户信任以及进一步优化模型至关重要。开发能够解释检索决策和生成过程的工具和技术，例如可视化注意力权重、突出显示关键上下文片段，或者提供生成步骤的推理链，将有助于用户更好地理解和信任 RAG 系统的输出。此外，研究如何让 RAG 系统在生成代码时主动避免引入已知的漏洞或不安全的编码模式，将进一步提升其在生产环境中的实用性。
7.3 面向复杂查询的多跳推理与文档 grounding 能力
当前许多 RAG 系统在处理简单的、单轮的查询时表现良好，但在面对需要多跳推理（multi-hop reasoning）的复杂查询时，其能力仍有待提升。例如，用户可能提出涉及多个步骤、需要整合来自不同代码文件或文档信息的复杂编程任务。未来的 RAG 系统需要具备更强的推理能力，能够将复杂问题分解为若干子问题，并通过迭代检索和生成步骤，逐步收集和整合所需的信息，最终给出完整的解决方案。这可能需要结合更强大的规划（planning）和推理（reasoning）模块，例如利用强化学习来优化多轮检索和生成的策略，或者引入知识图谱来指导推理过程并捕捉实体间的复杂关系。文档 grounding 能力，即确保生成的代码或解释严格基于所提供的上下文文档，避免引入文档之外的假设或“幻觉”，也是未来研究的重要方向。这可能需要开发更精细化的注意力机制，使 LLM 能够更准确地聚焦于检索到的相关片段，并抑制对无关知识的依赖。探索如何让 RAG 系统在生成过程中进行自我验证和修正，例如通过检索额外的证据来验证其生成的中间步骤或最终答案，也将有助于提升其在复杂任务中的表现和可靠性。
