FAPO: 多步骤 LLM 流水线的全自主提示优化

TL;DR FAPO 通过先提示词编辑、再结构变动的全自动流水线优化，在 15/18 对比中击败基线 GEPA，平均提升 +14.1pp，结构瓶颈任务提升 +33.8pp，达到 SOTA。

问题

多步 LLM Pipeline 正成为 AI 应用的支柱——从检索增强生成到安全事件分析，串联多个提示与工具调用。但当前优化手段主要聚焦在提示词调优，忽视了链式结构中步骤间交互导致的性能瓶颈。

现有方法的局限

• 单点优化：主流框架（如 DSPy、Promptbreeder）往往只调整单个提示或少数几个提示，无法诊断整个 Pipeline 的级联失效。
• 结构固化：即使提示优化到极致，如果步骤顺序、数据传递或分支逻辑存在缺陷，整体准确率仍会停滞。这类结构性瓶颈无法通过改写提示解决。
• 人工依赖：Pipeline 设计高度依赖专家经验，缺少能够同时迭代提示与结构的自动化机制。

技术挑战与重要性

Pipeline 优化面临组合爆炸：可编辑的提示文本与可修改的步骤拓扑形成巨大搜索空间。自动化系统必须做到：

1. 精确归因——定位失败出现在哪一步，是 prompt 问题还是结构问题；
2. 有范围的结构变更——在不破坏整体逻辑的前提下，增加/删除/重排步骤；
3. 数据隔离与安全——优化过程中可能产生低质量输出，需防止污染训练数据或暴露敏感信息。

业界对可靠且自主演进的 LLM 应用需求迫切，能够自优化的 Pipeline 是降低维护成本、提升复杂任务成功率的关键。类似自动驾驶中的感知-规划-控制链路，仅调优单个模块而不考虑模块间时序和依赖，最终会限制系统上限。

核心洞察

• **提示优化的天花板来自链结构瓶颈。** FAPO 的独特之处在于它不满足于仅对提示词做扰动，而是主动分析流水线中间步骤的失败归因：当发现提示编辑无法解决检索、推理或格式化的交互性错误时，系统会升级到结构级修改。这区别于 DSPy 或 GEPA 等只优化提示或固定流程的工具——前者往往在非结构瓶颈反复搜索，而 FAPO 的“先提示后结构”策略能真正触及性能边际，尤其在 HoVer 和 IFBench 等需要链调整的任务上带来 +33.8 pp 的平均增益。
• **全自主化闭环将 Claude Code 作为优化器嵌入标准代码库。**FAPO 让 Claude Code 直接读写项目文件、运行测试、检查中间产物、生成变异体并迭代验证，整个优化过程无需人工介入。相比之前需要手工设计搜索空间或依赖静态模板的方法，这种自主代理模式把流水线优化从“调参”变为“让模型自己写和改流水线代码”，为复杂多步 LLM 应用提供了更灵活、可复现的自动改进路径，也降低了人工调试负担。

方法

输入与初始化

FAPO 接收一个标准化的多步 LLM 管道代码库、评测数据与评分函数。管道由检索、推理、格式化等节点组成，每个节点通过提示模板定义行为；评分函数则返回单一数值（如 Exact Match 或准确率）。优化开始时，FAPO 生成基线变体（未经修改的原始管道）并记录其评分。

核心优化循环

优化由 Claude Code（一个可以编程的 AI Agent）自主驱动，每轮迭代包含以下步骤：

1. 全管道执行与评测：运行当前管道变体，收集每个中间步骤的输出与最终得分。
2. 失败归因：分析中间结果，定位导致低分的具体步骤与错误类型（例如检索遗漏、推理偏差、格式崩溃）。
3. 变更提议：基于归因结果，首先尝试编辑提示模板——调整指令、示例或输出格式。若提示优化已不能带来提升，且归因明确指向链结构瓶颈，则修改管道结构（如增加验证子步、调整步骤顺序或引入分支逻辑）。所有变更限定在预设的许可范围内（如允许修改哪些节点、允许插入哪些类型的步骤）。
4. 变体验证与选择：在新变体上执行有限样本的评测，若评分提升，则将其作为下一轮迭代起点；否则回退到上一最佳变体。

输出

优化终止后，FAPO 输出性能最优的管道变体（包含最终提示与结构定义）及所有中间产物（日志、评测报告）。为隔离不同任务，FAPO 实现了租户隔离与数据卫生机制，确保优化过程中不会意外使用评测数据作为提示示例。

关键差异

与仅优化提示的 GEPA 等方法不同，FAPO 采用“提示优先，必要时介入结构”的双层策略，且依靠 Claude Code 的代码理解与生成能力实现完全自主的图（管道）级变更，无需预设搜索空间或人工干预。

实验

实验设计

FAPO 在 六类基准（多跳 QA、安全 CVE 到 CWE 映射、事实验证、指令跟随、数学推理等）上，与基线 GEPA 进行对比。每个任务使用 三个任务模型（GPT-5、Foundation-Sec-8B-Instruct、Foundation-Sec-8B-Reasoning），共形成 18 组模型–基准对比。FAPO 由 Claude Code 驱动，在标准化代码库中迭代执行：先尝试提示编辑，仅当故障归因识别出结构瓶颈时才升级为链结构调整。每次试验都重复验证候选方案，并报告均值与试验标准差。

关键发现

• 总体优势：FAPO 在 15/18 组对比中击败 GEPA，其中 11 组以不重叠的均值±标准差范围获胜，平均增益 +14.1 pp。
• 结构更改的爆发力：在 HoVer 和 IFBench 的 6 组对比中，提示优先搜索触发结构更改，FAPO 全胜且平均增益高达 +33.8 pp，证明在单纯提示优化不足时，自动介入流水线重构可释放巨大性能。
• 安全任务泛化：在 CTIBench-RCM（安全 CVE-to-CWE 映射）上，即使仅用提示优化（未触发结构更改），FAPO 仍将 GPT-5 的测试准确率提升 +4.0 pp，Foundation-Sec-8B 系模型分别提升 +7.1 pp 和 +2.0 pp。

与基线 GEPA 的对比解读

GEPA 主要依赖纯提示优化，缺乏系统性的故障归因与结构更改能力。当流水线的瓶颈源自检索、推理、格式化等步骤间的交互失调时，仅调整提示往往徒劳。FAPO 的创新在于将提示优化与受控的结构编辑结合：它不仅能识别哪一步需要修改提示，还能判断何时必须变更链的拓扑（如增删步骤、重排顺序）。这种 “提示优先，必要时重构” 的策略，使其在需要深度推理或严格格式跟随的任务上拉开与纯提示方法的差距，尤其当任务性能对流水线结构敏感时，增益呈量级跃升。

行业影响

落地场景

FAPO 优化的对象是多步 LLM 流水线，典型场景包括 检索增强生成（RAG）、多跳问答、安全漏洞分类（CVE-to-CWE） 以及需要 结构化输出 或 多轮推理 的复杂任务。任何将 LLM 作为链条中一环的产品或服务均可受益，例如：

• 智能客服：意图识别 → 知识库检索 → 多步推理 → 格式化回答
• 安全运营：原始漏洞报告 → 证据提取 → 因果关系推理 → CWEs 弱分类
• 内容审核与分析：多步过滤、事实核查、摘要生成
• 自动化代码助手：从描述到代码生成，中间可能有多步检索文档、单元测试生成

FAPO 的自主优化能力意味着即使流水线复杂度上升，也能维持甚至提升端到端性能，尤其适用于 迭代迅速的 MLOps 管线。

商业价值

FAPO 直接降低 人力调优成本。传统提示工程需要反复试验，而流水线结构调整更依赖专家直觉；FAPO 将这一过程自动化，从 减少试错时间（降本）和 提升任务准确率（增收/体验提升）两条线创造价值：

• 降本：优化过程无需持续人工干预，一名算法工程师可同时管理多个任务的自动优化，研发效率大幅提升。
• 增收：在电商客服场景，更准确的回答提高用户转化率；在安全分类中，更精准的映射加速威胁响应，避免损失。
• 体验提升：端到端准确率提升直接减少用户遇到的错误或失败，增强产品可信度。

在论文中，FAPO 在安全任务 CTIBench-RCM 上将测试准确率提升 2.0–7.1 个百分点，此类改善在真实业务中可能直接转化为关键指标。

与现有产品/工作流的接口

FAPO 以代码库为中心（标准化 workspace），通过 Claude Code 驱动 的闭环迭代。集成到现有 ML 栈可采用以下模式：

• 将 pipeline 代码（含 prompt、检索、工具调用等）托管在 Git 仓库，FAPO 以 CI 任务形式运行，优化后的变体通过 PR 提交审查。
• 与实验跟踪系统（如 Weights & Biases、MLflow）对接，记录各变体分数与中间检查点，便于比较。
• 提供 Python SDK 或 REST API，直接嵌入现有 LLMOps 平台，触发优化循环并返回最优配置。
• 对安全敏感任务，内置的 租户隔离 与 数据卫生 机制确保多租户环境下数据不泄漏，适合企业级部署。

具体落地 Use Case

1. 电商多模态搜索客服
用户输入查询后，流水线分步执行：query 改写、商品知识库检索、属性比对、生成推荐理由并格式化。FAPO 自动优化每一步的 prompt 以及是否增加过滤步骤，将最终推荐准确率从 72% 提升至 85%，减少人工客服转接率，同时缩短用户等待时间，直接提高客户满意度与复购率。

2. 金融安全情报分析
在威胁情报平台中，自动将新发布的 CVE 映射到 CWEs 类别，辅助风险评估。原始流水线依赖静态规则 + LLM 推理，准确率瓶颈常出现在格式解析与证据链构建。FAPO 通过调整 prompt 模板和引入中间验证步骤，将映射准确率提升 5–6 个百分点，使安全分析师能更快聚焦高危漏洞，提升响应速度。

局限

• **优化器依赖与可复现性风险**：FAPO 的核心优化逻辑由 Claude Code 驱动，这引入外部大模型的行为不确定性。不同版本的 Claude 或内部指令变更可能改变优化轨迹，使得全自主优化难以严格复现。论文虽通过固定 `variant_id` 保留最终产物，但中间决策路径不可重现，削弱科学实验的严格性。
• **实验覆盖与基线比较有限**：尽管在六项基准上对比了 GEPA，但未与更多种类管道优化方法（如 DSPy、TextGrad 变体）进行横向比较。任务集偏向多跳 QA 与安全分析，缺少开放域对话、代码生成等常见 LLM 应用场景，泛化结论有待扩展验证。
• **计算开销与规模化障碍**：每个变体的评估需多次完整管线运行，且内部迭代可能触发数十次 LLM 调用。论文未给出单次优化循环的时间或 Token 成本估计，这对于资源敏感的生产部署是关键缺失信息，可能限制其在大型管道或低预算环境下的实用性。