原贴链接

你有处理大型代码库的经验吗？大多数模型的上下文长度为128K，这对于大型（甚至中等规模）项目来说是不够的。我尝试使用RAG来处理，但结果仍然很糟糕。

我开始怀疑除了增加上下文限制之外，还有其他方法可以在大型代码库上训练模型。我还尝试了cursor，上下文搜索的效果比我本地尝试的任何方法都要好。我不确定他们是如何进行索引的。

讨论总结

本次讨论主要围绕如何有效处理大型代码库展开，参与者提出了多种策略和工具。主要观点包括将代码库模块化和分层、使用Tree-Sitter解析代码结构、实现Agentic Flow自动探索代码库、推荐使用Aider和CustomGPT等工具。此外，讨论还涉及了模型上下文限制的问题，以及如何通过改进索引方法和使用分布式模型来解决这些问题。总体氛围是探索性和建设性的，旨在寻找更高效和有效的解决方案。

主要观点

  1. 👍 将大型代码库模块化和分层
    • 支持理由：可以有效减少对大型上下文的需求，提高代码的可管理性和可维护性。
    • 反对声音：模块化可能导致代码结构复杂化，增加开发和维护的难度。
  2. 🔥 使用Tree-Sitter解析代码结构
    • 正方观点：便于处理特定代码段，提高代码解析的准确性和效率。
    • 反方观点：需要额外学习和配置，对于小型项目可能显得过于复杂。
  3. 💡 实现Agentic Flow，让语言模型自动探索代码库
    • 解释：通过自动化的方式帮助开发者理解和导航大型代码库，提高开发效率。
  4. 👍 推荐使用Aider和CustomGPT等工具
    • 支持理由：这些工具可以辅助代码库管理，提高开发效率和代码质量。
    • 反对声音：依赖外部工具可能增加项目的不确定性和风险。
  5. 🔥 通过云端大型语言模型（如GPT-4）进行代码处理
    • 正方观点：云端模型可以提供更强大的计算能力和更丰富的上下文信息。
    • 反方观点：云端模型可能涉及数据安全和隐私问题。

金句与有趣评论

  1. “😂 anzzax：A simple trick for big codebases: make it modular and layered.”
    • 亮点：简洁明了地提出了处理大型代码库的有效策略。
  2. “🤔 MrAlienOverLord：the larger the ctx the slower the model will be - you really want a better way to index what effects the "feature" you want to implement instead of pushing all the stuff to a model as it gets confused by that too”
    • 亮点：指出了模型上下文大小增加带来的性能问题，并提出了改进索引方法的建议。
  3. “👀 1ncehost：I added an improved RAG methodology called CGRAG which considerably improves accuracy.”
    • 亮点：分享了一种改进的RAG方法，展示了技术创新的实际应用。

情感分析

讨论的总体情感倾向是积极的，参与者普遍寻求更有效的解决方案来处理大型代码库。主要分歧点在于具体的技术选择和工具使用，如是否使用Tree-Sitter、Agentic Flow等。这些分歧反映了技术社区对于最佳实践的不断探索和讨论。

趋势与预测

  • 新兴话题：分布式模型和改进的RAG方法可能会成为未来讨论的热点。
  • 潜在影响：更高效的代码库管理和处理方法将显著提升软件开发的效率和质量，对整个软件行业产生积极影响。

详细内容：

《如何应对大型代码库工作中的挑战？Reddit 展开热烈讨论》

在 Reddit 上，一则关于“Working with big code base”的帖子引发了广泛关注。该帖指出，多数模型的 128K 上下文对于大型（甚至中型）项目来说远远不够，即便尝试了 RAG 仍效果不佳，怀疑存在除增加上下文限制外训练模型处理大型代码库的方法。此帖获得了众多点赞和大量评论。

讨论的焦点主要集中在应对大型代码库的各种策略和方法。有人提出，对于大型代码库，将其模块化和分层是个简单的诀窍，组织项目时让每个文件夹代表一个组件或功能，把相关的一切（测试、实现等）放在一处，这样对 LLM 来说项目就像许多隔离良好的模块，无需大的上下文。还有人分享，对于处理大型遗留代码库，可以考虑使用 Tree-Sitter 来帮助界定上下文范围，通过解析代码结构让处理特定部分更轻松，或者实施 Agentic Flow，让语言模型从入口点开始自动探索代码库以识别依赖部分。

有人提到好的代码库索引应包含文件级、文件夹级和项目级，且涵盖英语描述和 AST 大纲，并对代码库进行重构以适应块大小，若 GPU 资源丰富，在索引时生成 QA 对。

有人询问用于 Tree-Sitter 和 Agentic Flow 有效工作的工具，得到回复可以尝试 Aider，它在内部使用了 Tree-sitter；对于 Agentic Flow 可以使用 CustomGPT（ChatGPT Plus）。

也有人认为，随着上下文增大，模型会变慢，且所有模型在上下文大小增加时都会损失一些准确性。

还有用户提到自己的项目针对大型代码库进行了设计，如 https://github.com/curvedinf/dir-assistant ，并测试了拥有 90 万行代码的仓库，还为其添加了改进的 RAG 方法 CGRAG 以显著提高准确性，欢迎查看源码了解具体实现方式。

在这场讨论中，大家各抒己见，共同为处理大型代码库的难题出谋划策。但对于最佳的解决方案，仍未形成完全统一的共识，仍需不断探索和实践。