RAG 上下文优化代理

这是我们近期黑客马拉松获胜者之一的客座文章。

代理架构的承诺在于，AI 可以通过协调更简单的任务来变得更强大，这些任务共同调集资源并逐步解决问题，而不是依靠巧妙的提示、微调和扩展单个大型语言模型（LLM）来一次性解决问题。最近的 Agentic RAG-A-Thon 为参与者提供了激励、资源和社区，以构建实现这一目标的原型和演示。

问题：代码仓库的 RAG

我们团队面临的问题场景始于 RAG 在技术支持中的实际应用。用户提出问题，支持工程师提供答案。有时，答案基于普通用户可能或多或少容易访问的文档。例如，半导体制造商会举办社区论坛，列出数千个操作指南和故障排除问题。许多问题和答案都来自公司可能维护的数百个包含 API、示例代码、固件和文档的 Git 仓库。人工智能应该帮助支持工程师找到正确的文档，并为客户的问题合成有用的答案。

检索增强生成（RAG）在上下文块来源于结构良好的自然语言源文档片段时效果良好。但某些知识源，例如代码仓库，往往会产生缺乏有效索引所需的上下文和意义的块，并且对于 LLM 响应合成所需的有用问题+上下文提示缺乏重要性。

一种解决方案是在知识源准备阶段进行操作，以构建更智能的块。例如，在软件文件中识别的函数级块之外，包含导入和类成员注释。或者为每个块包含一个叙述性摘要。目前，像 VS Code 和 Cursor 这样的集成开发环境（IDE）已经超越了代码完成功能，通过将软件表达式与目的和功能的叙述性解释联系起来。

当然，RAG 的前期知识准备是通用的——它无法针对任何特定的用户问题来调整知识的呈现。

提案：重新访问源文档

另一种方法更接近于人类专家会做的事情。通过多轮迭代，他们在文档中搜索和追寻线索，直到找到或拼凑出一个满意的答案。

我们的想法是在问答时部署一个 AI 代理来模仿这种策略。我们建议代理不是仅仅依赖通过索引搜索和重新排序检索到的块，而是重新访问源文档本身，以完善 LLM 提示的上下文部分，直到其包含足够的信息来回答用户的问题。

我们的设计围绕一个包含特定于问题的上下文信息的暂存区（scratchpad）。优化后，此上下文会与初始用户问题和指令提示一起包含在生成最终答案的 LLM 调用中。

暂存区的内容始于从 RAG 向量存储中提取的初始检索块集合。

但关键在于，一个评估器（Evaluator）步骤决定暂存区上下文是否足以回答问题。例如，如果初始块只是看起来与问题相关的各种代码片段，但未能提供关于它们如何组合在一起的连贯解释，那么评估器会将控制权传递给代理内的其他步骤。

上下文优化代理包含一个开放式的工具库，可用于优化暂存区。工具可包括：

• 基于块得分和投票，选择和过滤有用的仓库与无关仓库。
• 对文件和目录应用摘要。
• 基于与片段匹配的块，包含整个代码文件（受大小限制）。
• 移除被认为与问题无关的块。
• 选择与函数、文件和仓库相关的解释性文档。
• 追溯在公司网站或其他第三方网站上找到的文档链接。

一个工具选择器（Tool Selector）步骤决定接下来应用哪个工具。这个决定可能是一个预先确定的序列、一个类似规则的策略，或是一个开放式的判断。

借鉴经典人工智能

人工智能的学生会认识到这个架构是经典的生产系统（Production System）。在 AI 术语中，“生产系统”并非指“准备好用于生产部署的系统”。相反，生产系统建立了一系列竞争以修改中央“黑板”（blackboard）内容的增量计算步骤。控制流不是预先定义的，而是取决于数据。与传统的声明式程序不同，这种方法提供了异步、分布式和并行的计算模式。这个想法可以追溯到 Selfridge 1959 年提出的用于视觉感知特征匹配的“Pandemonium”架构；其他重要的生产系统包括Soar、Act-R和OpenCog。

基于符号表示的传统生产系统未能达到在深度神经网络上训练和运行的大型语言模型（LLM）所带来的惊人效果。其中的挑战之一在于在决定触发哪些生产规则以及它们的输出应如何修改黑板工作空间时，如何权衡上下文。

LLM 提供了几项突破性能力，为围绕评估、工具选择和工具应用循环组织的代理架构带来了希望：

• 大量松散结构的上下文可以应用于决策。
• 接口表示是人类自然语言和可理解的人工语言。
• 向量嵌入提供了“模糊”模式匹配能力。
• LLM 对概念的有效抽象消除了对复杂逻辑规则进行显式编程的需求。

概念验证

在黑客马拉松周末期间，我们构建了一个最小化的 RAG 上下文优化代理的概念验证。样本问题选自半导体公司英飞凌（Infineon）的公共社区论坛网站。我们选择了同行和专家答案中包含英飞凌公共 GitHub 网站引用的问题。然后，我们使用 LlamaIndex 和 Pinecone 工具链从这些仓库构建并索引了知识块。为了进行基线测试，我们针对 ChatGPT 和使用 top-K 检索作为上下文的标准 RAG 运行了这些问题。

下图展示了 AI 上下文优化如何改善对样本问题的响应，相较于基线 RAG。用户的问题是关于微控制器的睡眠状态。我们的评估器步骤要求 LLM 提供一个数值分数，评估暂存区上下文回答问题的效果。最初检索到的块没有提供有用的答案；它们被评估器评分 0.3，评估器将控制权发送给工具选择器。在这种情况下，相关的工具是识别同一文件中高得分块并将整个文件获取到暂存区的工具。评估器将改进后的上下文评为 0.7 分。通过这种上下文优化，检索到了解决 HOST_WAKE、DEV_WAKE 和问题其他方面的信息。

我们在 LlamaIndex Workflow 框架中构建了上下文优化代理。实际上，我们在事件驱动的 Workflow 框架中构建了整个 RAG 问题/响应生成管道。开发者设计的自定义事件（Events）以异步、数据流的方式触发操作步骤（Steps）。Workflow 步骤可以是纯粹的程序化执行，也可以调用 LLM，或者可以引入人工交互。我们发现这个框架既优雅又直观——尽管在 Python 中处理同步和异步代码之间的切换可能会有些棘手。

Workflow 框架支持一个全局上下文（Context）对象，该对象自然地映射到我们的暂存区（scratchpad）或黑板（blackboard）。在上下文优化代理内部，上下文状态包括用户问题和问题阐述，以及将在最终 LLM 答案生成调用中提供的源知识上下文的当前内容。

我们发现使用 Reflex 的工具在 Python 中构建 Web GUI 并在 Web 浏览器中运行我们的演示非常容易。

展望：RAG 上下文优化

有了概念验证和工作实现（至少是原型或大纲形式），这个想法值得进一步完善。需要进行大量的开发和针对真实世界问题与代码仓库案例的测试，以巩固和改进它。具体而言，任何程度的代理自主性都可能导致不可预测的行为，因此需要仔细的仪器化、监控和评估。例如，一些工具可能会探索开放网络以拉取相关信息，例如对第三方库的引用，但这些来源必须受到限制和审查。

Agentic RAG-A-Thon 提供了一个令人兴奋的机会，可以与其他开发者交流想法，了解不断增长的工具和服务集，并学习 Agentic RAG 技术如何解决实际问题。我们很荣幸获得 Global 500 奖以表彰我们的努力，我们祝贺所有赞助商和参与者成功举办了这次精彩的活动。

Eric Saund，博士，是 ept.ai 的首席 AI 官。

Tico Ballagas 是 Penumbra 的软件工程副总裁。

Mohit Shankar Velu 最近毕业于马萨诸塞大学阿默斯特分校，目前在 Prosimo 工作。