optimizeanything: 一个用于优化任意文本参数的通用API

TL;DR 一个基于 LLM 的通用文本优化 API，将优化问题统一为文本改进 + 打分，在智能体架构、云调度、CUDA 内核等六个领域全面超越专用工具，**首次**证明文本优化可成为跨领域通用求解范式。

问题

领域焦点
当前 AI 工程化前沿正从“单模型能力提升”转向“自动化系统设计与优化”：如何让 LLM 自主搜索最优的文本化决策参数（如 agent 架构、调度策略、推理提示），已成为提升系统智能上限的关键路径。

现有方法局限
传统优化通常依赖领域特定算法或人工设计：

• 强化学习需定义完备的状态空间与奖励函数，难以处理符号化、长文本动作；
• 遗传编程等元启发式方法缺乏语言先验，搜索效率低且不易迁移；
• 针对特定任务的 LLM 优化（如 prompt tuning）仅覆盖单点问题，无法复用跨领域知识。
  这类孤立工具使得每遇新任务需“重新造轮子”，且缺少对优化过程中的中间反馈（side information）的结构化利用，限制了收敛速度与最终质量。

难度与重要性
挑战在于：不同领域的问题表示、评价函数与可行解空间差异巨大，要求优化框架既能统一建模（将一切视为文本 artifact 与打分函数），又能自适应搜索策略（何时利用单任务深度搜索、何时进行多任务迁移）。业界高度关注通用化优化范式，因其能显著降低 AI 系统开发成本，并可能解锁人工难以触及的设计创新——论文中 ARC-AGI 精度提升近三倍便是例证。

场景类比
这类似于 AutoML 对模型超参搜索的统一，但 optimize_anything 将搜索空间从数值/结构扩展到了可执行代码、策略文档、甚至 CUDA 内核，更贴近当前大模型驱动的生产系统自动化需求。

核心洞察

• 将优化问题统一为**文本参数的迭代改进**，让 LLM 成为通用黑盒优化器，跨越了传统上需要领域专家设计专用算法的壁垒。该框架不依赖梯度或特定搜索启发式，仅通过文本接口与评分函数交互，在智能体架构搜索、云调度、CUDA 内核生成等截然不同的任务上取得 SOTA，证明 LLM 驱动的文本优化可作为通用的解题范式。
• **多任务搜索与跨任务迁移** 是该系统的核心优势：通过维护跨问题的改进历史与共同知识，优化器能将一个任务发现的成功模式复用于其他任务，其收益随相关任务数量增加而扩大。这与传统的单任务独立优化形成鲜明对比，为超参数调优、自动机器学习等需要调优多个关联目标的场景提供了更高效的资源利用策略。
• **可操作的侧信息**（如错误类型、性能剖析）的引入，比仅使用数值评分能显著加快收敛并提升最终解质量。这一发现揭示了 LLM 优化中反馈粒度的重要性：提供结构化的诊断信息而非仅给标量分数，能让 LLM 更精准地定位缺陷并做出针对性改进，减少盲目搜索，对实际部署 LLM 优化器有直接指导意义。

方法

问题形式化

optimize_anything 将任意优化任务统一抽象为：给定一个文本产物（如代码、提示、调度策略）和评分函数 score(artifact) → float，目标是自动发现高分产物。

核心优化循环

系统采用基于帕累托前沿的演化搜索，由 LLM 充当变异与反思引擎：

1. 初始化：从种子（或无种子）候选集开始。
2. 评分与边信息（SI）：每次迭代中，对当前候选评分，并可获取领域相关的可操作性边信息（如测试失败日志、性能剖析、约束违反细节），不仅告知“好/坏”，更提示“为何差、如何改”。
3. 帕累托候选选择：按得分与候选结构多样性构建帕累托前沿，保留多目标（如精度 vs. 延迟）或单目标下的多样化解，防止过早收敛。
4. LLM 反思与变异：
   • 反思：LLM 分析帕累托前沿历史，识别成功模式与失败原因，生成改进方向。
   • 变异：基于反思与选定的父代候选，LLM 生成多个变异后代（如局部修改、跨候选重组）。
   • 当存在边信息时，反思与变异会直接引用具体失败模式，生成更具针对性的修改，显著加速收敛。
5. 迭代：后代加入候选池，循环 2-4，直至预算耗尽或收敛。

三种搜索模式

• 单任务搜索：独立优化，适用于孤立问题。
• 多任务搜索：同时优化一组相关任务，通过跨任务迁移机制（在反思/变异中显式参考其他任务的高分产物）共享经验，同等算力下超越独立搜索，且收益随任务数增长。
• 泛化：优化训练实例集合，测试单一产物对未见输入的泛化能力。

关键差异

与传统的专域优化器（如编译器自动调优、专用元启发算法）相比，optimize_anything 不依赖领域特定搜索算子，而是将领域知识注入边信息与评分函数，让 LLM 通过文本操纵自主发现有效解。相较于仅使用分数反馈的 LLM 自改进方法，引入可操作性边信息和基于帕累托的多样性维持是其性能突出与收敛稳健的主要来源。

实验

实验设计

系统将不同领域的优化任务统一为文本参数优化：给定一个文本工件（如 agent 架构描述、调度策略、CUDA 代码），使用 LLM 生成候选改进，并通过评分函数评估质量。实验覆盖六个任务：ARC-AGI（抽象推理）、云调度、CUDA 内核生成、圆填充等。每个任务都设有对应的专用基线方法。消融实验对比了仅得分反馈与可操作侧信息（actionable side information）的效果，并设计了单任务搜索与多任务搜索（含跨问题迁移）的公平预算对比。

关键发现

• 可操作侧信息在所有测试领域中显著加速收敛并提升最终分数，比纯得分反馈高出数个百分点至数十个百分点。
• 多任务搜索在总预算相同的条件下，通过跨任务迁移持续超越独立优化，且收益随相关任务数量增加而增长。
• 单个通用系统首次在多个截然不同的任务上匹敌甚至超越专用工具：ARC-AGI 准确率从 32.5% 提升至 89.5%(+57 pts)；云调度成本降低 40%；87% 的 CUDA 内核与 PyTorch 持平或更优；圆填充解优于 AlphaEvolve 报告结果。

基线对比解读

将 LLM 驱动的文本优化与传统专用算法直接对比，揭示出通用范式的颠覆性：ARC-AGI 任务上远超 Gemini Flash 原始能力，逼近专门设计的程序搜索方法；在代码生成类任务中，生成的 CUDA 内核多数不比手写 PyTorch 差，说明 LLM 自我改进能触及专家级代码质量。多任务迁移的优势进一步表明，随着任务领域积累，系统可形成跨领域的知识复用，打破“一个任务一个模型”的不可复用壁垒，其增益曲线表明生态效应可能放大边际收益。

行业影响

落地场景

optimize_anything 将任意文本参数优化问题统一为“文本工件 + 评分函数”范式，可落地于所有需要自动搜索最优文本化策略、配置或代码的产品线。典型目标包括：

• AI Agent 行为策略：如客服机器人决策逻辑、推荐系统代理的候选生成规则、RPA 流程的交互脚本。
• 基础设施调度与内核优化：云资源分配算法、CUDA 算子实现，直接降低延迟和成本。
• 工业设计与工程规划：几何排样（如 Circle Packing）、供应链调度脚本等。

商业价值

• 大幅降本：在实验中，自发现的调度算法将云成本降低 40%；自动生成的 CUDA 内核有 87% 达到或超过 PyTorch 原生性能，可节省大量人工优化与硬件开销。
• 核心指标倍增：Agent 架构搜索将 Gemini Flash 在 ARC-AGI 上的准确率从 32.5% 提升至 89.5%，这类跳变可直接转化为产品竞争力，带来营收增长。
• 加速迭代：多任务搜索与跨任务迁移使优化效率随相关任务数量增加而提升，减少冷启动成本，适合平台型公司快速覆盖多个业务线。

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

系统以 Python API 形式交付（开源仓库 gepa），可无缝嵌入现有 MLOps 或 DevOps 流水线：

• 输入为文本工件（如 JSON 配置、代码字符串、提示词模板）和一个评分函数（仿真器、A/B 测试、用户反馈打分器等）。
• 支持多个 LLM 后端（Gemini 等），可直接利用企业已有的 GPU 集群或云推理服务。
• 单次优化可输出 Pareto 前沿解，方便人工筛选或直接部署。

具体落地用例

1. 电商推荐策略调优：将商品推荐 Agent 的决策逻辑表示为文本规则（如“若用户加购但未下单，24 小时内推送限时优惠”），通过离线仿真环境打分，optimize_anything 自动搜索出最优规则组合，提升转化率。
2. 云服务提供商的 Kubernetes 调度器优化：自动生成 Pod 调度的分配策略代码，使用历史集群负载数据作为评分函数，直接搜索出能降低数据中心能耗与延迟的策略，在数千节点规模下实现显著成本节约。

局限

• 对评分函数质量的强依赖：优化系统以评分函数为唯一反馈信号，其设计质量直接决定搜索方向。若评分函数无法全面刻画目标属性（如代码的可维护性、对偶发情况的鲁棒性），优化可能陷入 reward hacking 或局部最优。此外，评分函数的计算开销也会传递至优化循环，对于需仿真或真实环境评估的问题，成本高企，实用性受限。
• LLM 生成与评估的高计算开销：尽管过程免训练，但每次迭代需大量 LLM 调用（如候选生成、反思、评分解释），在多任务搜索中尤甚。论文中 ARC-AGI 优化消耗数万次 LLM 调用，普通开发者难以承受。这限制了其在资源敏感或实时场景中的部署，且目前缺乏对 proposer 调用次数的自适应控制。
• 跨任务迁移的局限性：多任务搜索依赖任务间可共享的结构化知识，但当任务不相关时，强制迁移会引入噪声，导致搜索效率反而不如独立单任务优化。论文消融实验已证实负迁移现象，但未提供自动识别任务相关性的机制，用户需自身判断分组，提高了使用门槛，也限制了框架在开放任务集上的鲁棒扩展。