02 [RAG] 编程智能体在真实优化任务上频频失手——而现有基准甚至看不出来
现有的代码基准只评估智能体能否让代码正确运行，而非运行得好不好。这一差别在代码仓库层面至关重要——瓶颈几乎从来不是正确性，而是在真实负载下的吞吐量、内存占用和运行时效率。二元的通过/失败信号对此完全视而不见。
FormulaCode 通过一个专门构建的基准揭示了这一差距。该基准从 GitHub 上的科学计算 Python 仓库中挖掘出 957 个真实性能瓶颈，每个任务都配有专家编写的补丁，以及平均 264.6 个社区维护的性能工作负载——这些是原始开发者用于验证自身优化效果的真实执行profile，而非合成测试套件。多目标指标同时追踪运行时间、内存消耗和吞吐量，因此一个以内存爆炸为代价换取提速的智能体，其得分会如实反映这一权衡。这是第一个能对”它变快了吗”给出精确、多维度答案并与真实代码挂钩的基准。
结果令人警醒。当前的 LLM（大型语言模型）编程智能体在 FormulaCode 上暴露出合成基准从未发现的问题：智能体经常提出正确的补丁，却对性能毫无改善；或者优化了某一指标，却使另一指标恶化。该基准的细粒度评分使这些权衡得以清晰呈现。对于正在构建或评估面向生产环境编程智能体的团队——包括代码审查自动化、性能回归检测以及仓库级重构——FormulaCode 提供了一项 SWE-bench 式正确性评估无法替代的可信度测试。
需要指出一个局限性：该基准专门取材于科学计算 Python 仓库，偏向数值计算和数组操作。Web 服务、数据库访问层或系统代码中的性能优化模式可能并未得到充分体现。在此表现出色的智能体，未必能迁移到其他场景。
核心要点：
- 957 个来自 GitHub 的真实性能瓶颈，每个平均对照 264.6 个工作负载进行评估，涵盖运行时间、内存和吞吐量的多目标指标，首次使智能体的权衡取舍可量化
- 二元正确性评估系统性地掩盖了生产环境编程智能体最常见的失败模式：代码通过了测试，但实际上并未提升性能
- 为性能敏感型应用评估 LLM 编程智能体的团队，在轻信纯正确性评估的基准数字之前，应先用 FormulaCode 进行验证
来源： Evaluating Agentic Optimization on Large Codebases