Large Language Models as Optimizers (OPRO)
这是什么
这是 Google DeepMind 2023 年 9 月的工作(ICLR 2024,S2 引用已过千),是 'LLM 自动优化 prompt' 这个方向被引最多的奠基论文。核心想法一句话:传统优化器靠梯度或手写启发式更新解,OPRO(Optimization by PROmpting)直接用自然语言把优化问题和历史尝试描述给一个 LLM,让它 '看着走势提出下一个更好的解'。优化任务、目标函数、约束全部写在所谓 meta-prompt 里,不需要任何形式化建模,也不需要对被优化对象求导。
论文先用线性回归和 TSP 两个经典问题做 motivating example,证明 LLM 确实能从纯轨迹里推断出下降方向(小规模问题上能到全局最优),然后把主战场放在 prompt 优化:把 '找一条让任务准确率最高的 instruction' 本身当成优化问题,优化变量是一段自然语言。被优化的模型叫 scorer(打分用,论文里主要是 PaLM 2-L 和 text-bison),做优化器的模型叫 optimizer(PaLM 2-L-IT、gpt-3.5-turbo、gpt-4 等),两者解耦。
这篇论文出圈是因为它找到的最优 GSM8K 指令是 'Take a deep breath and work on this problem step-by-step.'——'让 AI 深呼吸能提高数学成绩' 被大量媒体报道。抛开段子,它真正的贡献是给出了一个极简、可推广的范式:任何能算出标量分数的东西,都可以塞进这个 '生成-评估-写回轨迹' 的循环里让 LLM 迭代改进,后续 PromptBreeder、EvoPrompt、DSPy 一系工作都在这个问题设定下展开。
机制与做法
框架:meta-prompt + 生成-评估循环
整个系统就一个循环(见架构图):meta-prompt 作为 optimizer LLM 的输入,包含两块——(1) 任务描述(目标、约束、输出格式,prompt 优化时再加 3 个从训练集随机抽的 exemplar);(2) 优化轨迹,即历史生成的 (solution, score) 对,按分数从低到高排序,只保留 top 20。LLM 生成新解,objective function evaluator 打分,新的 (解, 分数) 写回 meta-prompt,进入下一步;直到收敛或达到最大步数(默认 200 步)。
两个关键的稳定性设计:每步让 optimizer 以 temperature 1.0 采样 8 条新指令(类似 mini-batch 降方差,消融显示 8 是最优);轨迹升序排列是刻意的——LLM 有 recency bias,更容易模仿靠近 prompt 末尾的内容,把好解放最后能收敛更快。
热身:线性回归和 TSP 上 LLM 真能 '看轨迹下降'
一维线性回归(黑盒设定,不给解析式):从 5 个随机 (w,b) 起步,gpt-4 / text-bison / gpt-3.5-turbo 都能收敛到全局最优,探索的 unique 点数远少于穷举,gpt-4 最省(例如 w=15,b=14 时平均 17.2 个点、4 步收敛)。看轨迹能发现它确实在做 '数值比较 + 提出下降方向',比如看到 (8,7)、(8,6)、(8,5) 目标值递减就提出 (8,4)。
TSP 上则暴露了边界:n=10 时三个模型全部 5/5 找到最优;n=50 时全军覆没,gpt-4 的 optimality gap 还有 11%(和 Farthest Insertion 启发式 9.8% 相当),text-bison 恶化到 219.8%。论文明确说 OPRO 不是要打 solver,大规模问题受 context 长度和崎岖 landscape 限制。这两节更像能力演示,真正的应用是下一节。
主实验:prompt 优化的具体设定
优化目标是训练准确率:GSM8K 只抽 3.5% 训练集(约 260 题)作为打分集,BBH 每个任务用 20% 样本,评估时 scorer 用 temperature 0 贪心解码。指令插入位置有讲究:pre-trained 的 PaLM 2-L 用 A_begin(答案开头),instruction-tuned 的 text-bison 用 Q_begin / Q_end。
GSM8K 上从 'Let's solve the problem.'(训练准确率 60.5)起步,优化曲线整体上行并有几次跳变:第 4 步 'Let's break it down!' 71.3,第 6 步 'Let's do the math!' 78.2,第 107 步才找到 80.2 的 'Take a deep breath...'。作者自己也指出:如果只是要一条好指令,几步就够了,后面涨的主要是整批指令的分布质量。对照实验:一次性让 LLM 生成 50 条指令(不带轨迹迭代),最好的仍是初始指令 60.8,远差于迭代式的 76.3——轨迹信息是涨分的来源。
消融与对比:meta-prompt 里什么最重要
消融(text-bison scorer + PaLM 2-L optimizer):轨迹升序 > 降序/随机;显示准确率分数比只给指令排序好;exemplar 必须有但 3 个就够,10 个反而因挤占 context 分散注意力;温度 1.0 最优,0/0.5 会卡在同一条指令,1.5/2.0 则无视轨迹乱探索。
与同期进化式方法 EvoPrompt(GA/DE 版)对比:在 GSM8K 上从通用初始指令起步,EvoPrompt 两个版本越优化越差(它只做两条 prompt 的 crossover/mutation,不带 exemplar、不知道任务是什么),OPRO 稳定爬升;给 EvoPrompt 任务相关的初始指令后它才能改进但曲线仍不稳。结论:带分数的完整轨迹 + 任务 exemplar 是这个范式 work 的关键,而不是 '用 LLM 生成 prompt' 本身。
关键结果
- GSM8K(PaLM 2-L scorer):OPRO 找到的 'Take a deep breath and work on this problem step-by-step.' 测试准确率 80.2%,对比 'Let's think step by step.' 71.8%、APE 的指令 58.8%、空指令 34.0%;摘要里 'up to 8%' 指的就是 80.2 vs 71.8。
- BBH 23 任务(PaLM 2-L scorer,PaLM 2-L-IT optimizer):19/23 任务比 'Let's think step by step.' 高 5% 以上,20/23 比空指令(优化起点)高 5% 以上;个别任务如 word_sorting 高出约 50%,但也有一个任务反而掉约 30 个点(见柱状图)。
- 迁移性:为 GSM8K 优化的指令直接搬到 MultiArith / AQuA 依然领先,'Take a deep breath...' 在 MultiArith 95.3%(step-by-step 85.7%)、AQuA 54.3%(44.9%)。
- 最优指令高度依赖 scorer:同是 GSM8K,text-bison scorer 下最好的是 'Let's work through this problem step-by-step:'(68.5%),'Take a deep breath' 只属于 PaLM 2-L;不同 optimizer 风格差异也大,PaLM 系简短、GPT 系冗长。
- 语义相近的 prompt 分数可以差很远:'Let's think step by step.' 71.8% vs 两句好指令的语义组合 'Let's work together to solve this problem step by step.' 只有 49.4%——prompt 空间极不平滑,这是每步采 8 条降方差的动机。
- 过拟合真实存在:训练准确率通常比测试高 5%-20%(论文附录表格),但作者验证了训练/验证曲线同步涨跌,所以直接取训练分最高的指令仍然可行。
- 作者自承的两个局限:optimizer 用不好 error case(把错题放进 meta-prompt 没带来提升);必须有几十条带 golden label 的训练样本来打分(issue #6 官方确认只适用于有标准答案的任务)。
实证核查
与我们方向的关系
对 ai4ai / prompt 自动优化方向,这篇是必须精读的原点:后续 EvoPrompt、PromptBreeder、PE2、DSPy(MIPRO)等基本都是在 '有打分函数,让 LLM 提议新 prompt' 这个设定上改搜索策略。OPRO 的消融给了几条直接可抄的工程结论:轨迹按分数升序放末尾(利用 recency bias)、每步采 8 条降方差、必须放少量 exemplar 让 optimizer 知道任务长什么样、温度 1.0 平衡探索/利用——这些设计比 '用哪个模型' 更决定成败,EvoPrompt 对比实验就是反例。
两条实操提醒:第一,optimizer 模型必须够强(gpt-3.5 量级以上),想用 7B 本地模型自举优化 prompt 大概率无效(Revisiting OPRO 的教训);第二,优化出来的 prompt 是 scorer-specific 的,换模型要重新跑,别直接搬 'Take a deep breath'。另外它需要几十条带标签样本打分、一次优化要评估上千条指令(200 步 × 8 条 × 每条几百题),API 成本不低,README 专门写了 cost 警告——课题组如果做这个方向,可以把 '更样本高效 / 利用 error feedback' 当切入点,这正是论文结论节留下的 open problem。