构建用于语义代码搜索的 RAG 管道

Agentic AI AI 为语义代码搜索构建 RAG 管道：开发人员日记和现场笔记第 1 部分：解析、分块和矢量化 不久前，我们着手构建最好的语义代码搜索平台：一个 RAG 管道，它为 LLM 代理提供来自真实存储库的精确、可引用的证据，而不是任何 grep 出现的结果。最终的解决方案是 Air Context。我们让它发挥作用，投入生产，一路上我们收集了很多疤痕组织。在这一系列的帖子中，我们将分享我们希望有人在第一天就告诉我们的部分。编码代理无疑是我们十年来软件开发最大的技术飞跃。面对看似难以克服的代码复杂性，代理和前沿模型正在证明它们有能力生成表面上可靠的代码。然而，随着越来越多的开发过程变得由代理驱动，代理的效率和生成的代码的质量变得越来越重要。问题不在于代理是否能够完成任务，只要有足够的时间和代币资源，它肯定会完成，而在于它需要多少时间、精力和指导来生成生产级结果。特别是对于大规模代码库，代理将花费大量时间搜索与其正在处理的功能相关的相关代码片段，并将它们拉入上下文中。为什么语义搜索很重要 为了尝试找到正确的代码片段，代理将诉诸传统的代码搜索工具，例如关键字搜索和 grep。然而，这些工具的局限性在于它们要求代理提前知道要搜索哪些确切文本。例如，寻找会话令牌刷新位置的代理不能依赖包含“刷新”一词的代码。为了通过抽象域进行推理，代理需要能够按含义搜索代码，也称为语义搜索。这就是检索增强生成（RAG）发挥作用的地方。如果我们能够以捕获其语义的方式对源代码进行索引，然后允许代理使用自由文本搜索按需检索相关片段，我们就创建了一个能够发挥代理优势的界面。从原型到生产就像代理时代的许多伟大想法一样，原生原型实现非常简单。经过充分评估的生产级解决方案肯定不是。在这一系列博客文章中，我们想分享制作有效的 RAG 系统所涉及的内容，以及我们在创建自己的空气环境过程中所犯的错误。我们将解决从预处理到存储和代理集成的每个阶段，提供更多的技术背景和建议。本系列的第一部分将介绍管道的初始阶段：解析和分块，其中原始源文件被划分为适当范围的单元，以及矢量化，其中这些单元被转换为支持语义搜索的表示。解析和分块的精细 AST 解析和分块是良好 RAG 解决方案中关键的预处理步骤，但它经常被忽视。为了允许法学硕士嵌入或以其他方式索引源代码，我们必须首先向其提供原始代码行。这听起来可能微不足道，并且可能适用于小型演示项目。然而，生产级系统包含数千个文件，而这些文件又跨越数百甚至数千行。如果说有什么不同的话，那就是代理使问题变得更加复杂，因为他们往往是多产的作家，进一步扩大了代码库。每个文件可能包含大量的类、字段和方法，它们之间的相关程度不同。找到合适的块大小即使可以将这些巨大的代码文件完整地放入嵌入模型中，这种昂贵的壮举最终也会弄巧成拙。由于整个文件嵌入在单个单元中，因此搜索将返回整个文件。这对代理代码探索和导航的目标是适得其反的，代理代码探索和导航主要关注的是查找特定的函数、符号或代码片段。另一方面，如果我们采取另一个极端并精细地嵌入每一行单独的代码，我们将面临不同类型的问题。如果没有周围的上下文，这些单独的行在语义上可能毫无意义。通用函数名称或注释不值得嵌入，并且会产生错误的检索结果。从某种意义上说，我们将无法只见树木，只见森林，并且代理将因多个（通常是微不足道的）微观结果而超载。因此，必须找到正确的方法将代码分块或划分为适当范围的组。每个组应该包含足够的必要上下文并代表共同的语义。为什么固定大小的分块不够充分 分块是一种获取内容的技术的通用名称