Large Language Models as Optimizers

许多优化变量是字符串或离散方案，无法直接对目标函数求梯度。OPRO 研究 LLM 是否可以理解自然语言目标，阅读历史候选及分数，提出下一批更好的候选。Prompt Optimization 是其主要应用，因为 Prompt 的语义结构可被 LLM 直接理解。

若一个人看到多条指令及其成绩，通常能提出哪些措辞可能有帮助的猜测。LLM 也能从自然语言候选提取共同特征，因而可以把候选表和目标说明直接交给它。下一步仍需要独立执行评分，因为语言上看起来更合理不代表目标函数更高。

历史候选和分数构成一种可读的 optimization trajectory，model 不必只围绕当前最好 prompt 作局部修改，而可以比较多个尝试来提出新 strategy。任务描述和示例提供语义约束，实际运行得分则决定候选是否值得进入下一轮历史。

沿用原文 GSM8K Prompt Search：输入候选指令、对应训练准确率及任务描述；Optimizer LLM 生成新指令，Scorer Model 用它回答一批题；结果追加到历史后进入下一轮。最终输出是选出的 Prompt，再到测试题评估。Scorer 与 Optimizer 的角色可以由不同 Model 承担，不能把历史分数增长解读为 Optimizer Weights 改善。

设 p 为 Prompt，f(p) 为一批任务的平均分。OPRO 根据历史 H={(p,f(p))} 生成候选，而非计算 ∂f/∂p。自然语言相当于带先验的候选生成器，真实目标仍需外部测量。由于反复查看开发分数，选择偏差会累积；测试集必须留到搜索结束后使用。

p_next ~ LLM(objective, constraints, H)
H ← H ∪ {(p_next, f_dev(p_next))}
Report f_test(selected prompt) only after search

OPRO 的最小闭环是提出、测量、记录。它降低了设计候选的门槛，但固定 Model 在越来越长的 Context 中工作，不能自动算作改进算法的持久演化。

最脆弱的假设是候选成绩中的可学习规律多于噪声。小开发集、随机输出和题型偏差可能让 LLM 追逐偶然高分措辞。

训练样本及可计算评分是必要外部信号，反复选择也可能 overfitting 小型训练集。context 预算限制可利用的历史，foundation model 与元优化流程固定；外部数学问题的解变好与部署系统的长期能力改进需分别记录。