原贴链接

我即将使用Open WebUI（Ollama）作为大型语言模型（LLM）提供者来设置Continue VS Code扩展。我计划通过调用Open WebUI的API端点来使用我的Open WebUI基于检索增强生成（RAG）的管道。我打算将我的开发人员的应用程序代码库放入单独的Open WebUI知识库中，将它们全部分开，并允许对特定代码库进行RAG（使用#标签）。在我尝试之前，我的问题是，RAG在分块/嵌入的代码库上是否有效？或者说分块/嵌入是否会完全破坏大型语言模型（LLM）理解大型代码库、执行可追溯性等的能力？这是不是那种如果不能将整个代码库放入上下文窗口就无法从大型语言模型（LLM）得到任何有意义答案的情况呢？

讨论总结

原帖对RAG应用于大型代码库以及分块/嵌入是否影响LLM理解代码库存疑。评论者们从不同视角展开讨论，有从程序员日常分析代码需求角度出发的，有分享自己使用相关工具如Continue的体验的，也有给出构建知识图谱、考虑代码依赖关系、研究图数据库等具体操作建议的，整体氛围是积极探索该技术相关问题。

主要观点

  1. 👍 RAG在代码库上的适用性取决于相关操作方式
    • 支持理由：从程序员理解代码需求角度出发，不同的RAG、分块、汇总操作会有不同结果
    • 反对声音：无
  2. 🔥 使用Continue时LLM难以理解代码库完整上下文
    • 正方观点：根据自身使用Continue的体验得出
    • 反方观点：无
  3. 💡 处理代码库需用特定工具解析源代码并构建知识图谱
    • 解释：如用tree - sitter或clang解析文件源代码，摄取代码实体和关系构建知识图谱并做相关操作
  4. 💡 除相似性外需考虑代码依赖关系
    • 解释：在RAG应用于代码库时不能仅考虑相似性，代码依赖关系也很重要
  5. 💡 分块不会破坏LLM对代码库的理解能力，但糟糕且有固有错误的代码会影响
    • 解释：基于经验得出，分块本身影响不大，但代码本身质量差会影响LLM理解

金句与有趣评论

  1. “😂 我是一名程序员，不是RAG专家，但根据理解代码库的实际需求，答案似乎很明显取决于您如何进行RAG/分块/汇总等操作。”
    • 亮点：以程序员非专家的角度出发，指出RAG在代码库上适用性与操作方式有关
  2. “🤔 Pedalnomica：When I use continue no LLM seems capable of understand the full context of the repository I’m working with.”
    • 亮点：分享使用Continue时LLM对代码库理解的体验
  3. “👀 Rag kills formatting so you have to massage a lot of things.”
    • 亮点：指出RAG会破坏格式，在使用时有很多需要处理的情况
  4. “😎 In addition to similarity you want to make relationships between code dependencies, look into graph databases with embeddings support.”
    • 亮点：提出除相似性外要考虑代码依赖关系及研究支持嵌入的图数据库
  5. “👍 based on my experience chunking doesn’t ruin the llm’s ability to make sense of the codebase but badly written code with inherent bugs will definitely ruin because most of the auto completion is based on the users previous syntax and coding patters.”
    • 亮点：基于经验阐述分块与代码质量对LLM理解代码库的影响

情感分析

总体情感倾向为积极探索。主要分歧点在于RAG在代码库上的具体操作影响，如分块是否破坏LLM理解能力等。可能原因是不同人有不同的技术背景和使用经验，从各自的角度出发看待问题。

趋势与预测

  • 新兴话题：探索更好的构建分层知识图谱等技术操作来优化RAG在代码库上的应用。
  • 潜在影响：对大型代码库管理、LLM在代码领域的应用发展等有推动作用。

详细内容：

标题：关于 RAG 在大型代码库中的应用探讨

近期，Reddit 上一则有关“Does RAG work on large codebases?”的帖子引发了广泛关注，截至目前已获得了众多点赞和大量评论。帖子中，作者表示即将使用 Open WebUI 作为 LLM 供应商的 Continue VS Code 扩展，并计划将开发者的应用代码库放入单独的 Open WebUI 知识存储库中以实现 RAG 处理，但提出了 RAG 在代码库被分块或嵌入时是否能有效工作，以及是否会影响 LLM 对大型代码库的理解和追溯能力等疑问。

讨论焦点与观点分析： 有人认为答案取决于 RAG、分块、总结等的具体操作方式。有人会对接口和实现做单独总结。还有人提出了一系列实用的方法，比如建立带有文件概要的索引，不进行不必要的分块，若分块则以函数或类为单位，使用具有更高上下文长度的嵌入模型，并使用多次 LLM 调用等。 有人表示使用 Continue 时，没有 LLM 能理解工作所在存储库的完整上下文，但将相关文件在提示中分开分享很有帮助。也有人指出提供 readme.md 增加上下文能改善结果。 有人提到要使用类似 tree - sitter 或 clang 解析所有文件的源代码，并将代码实体和关系摄入知识图谱，还要用 LLM 生成英文总结以便嵌入。还有人分享了相关项目链接。 有人认为 RAG 不仅仅是向量相似性搜索和提示注入，对于复杂的代码库需要更智能的处理方式，要保留重要信息。有人提出关注代码依赖关系和使用支持嵌入的图形数据库。也有人认为 Continue 有自己的嵌入功能用于索引，分块不一定会破坏 LLM 理解代码库的能力，但有固有缺陷的劣质代码会。有人觉得 RAG 会破坏格式，还是用清晰的英语描述更好。

总之，关于 RAG 在大型代码库中的应用，大家各抒己见，提供了丰富的观点和建议。但目前尚未形成完全统一的结论，仍需更多实践和探索来找到最优解决方案。