自动提示词工程师 (APE) 让语言模型能够针对给定任务编写、测试并选择最佳提示词，将曾经依赖试错的“艺术”转变为可重复的数据驱动搜索。

为什么提示词编写已成为瓶颈

提示词工程（Prompt engineering）——即通过精心设计措辞来告知模型该做什么——长期以来一直是直觉与运气并存的过程。从业者在这里微调一个词，在那里更换一个短语，运行模型，直到输出结果“感觉对了”才停止。这种方法耗时漫长，依赖工程师的想象力，并限制了性能上限。在生产环境中，这意味着更长的开发周期、不稳定的结果，以及只有在发布后才会显现的隐藏成本。

APE 的三步工作流

APE 将提示词创建视为一个搜索问题。用户输入一小组输入-输出示例。随后，系统会运行三个自动化阶段：

  1. 提议 (Propose) – 模型扫描示例并生成一批候选指令，例如“返回相反结果”或“写出反义词”。
  2. 评分 (Score) – 系统在另一组未见过的示例上运行每个候选指令，并统计有多少个答案与预期输出匹配，从而得出原始准确率数值。此步骤无需人工干预。
  3. 选择 (Select) – 准确率最高的指令将成为最终的提示词。

该循环可以重复进行。胜出的提示词成为新的种子，模型会据此建议变体。据报告，在实际运行中，一个得分仅为 83% 的通用指令被优化到了在测试集上达到 100% 的版本。

为什么这种方法比人工更强大

  • 覆盖范围 (Coverage) – 大语言模型 (LLM) 可以在几秒钟内生成数十种措辞变体，远超人工测试的能力。
  • 客观性 (Objectivity) – 选择取决于可衡量的准确率，而非措辞听起来多么考究。教科书式的指令可能仍然输给一个虽然简短、听起来古怪，但模型理解得更好的变体。

由于评分指标由用户提供（通常是精确匹配检查或单元测试），系统可以针对任何下游需求进行调整，从代码生成到情感分析。

自动化的代价

权衡之处在于计算资源。为每个候选指令评分会触发大量的模型调用，因此开发阶段会消耗相当数量的 API 使用额度。APE 将这笔开销视为一次性投资：一旦确定了最优提示词，你就可以永久重复使用它，而无需额外成本。

两个前提条件也限制了其应用：

  • 带标签的示例 (Labeled examples) – 系统需要一组具有代表性的输入和正确输出。
  • 评分函数 (Scoring function) – 用户必须定义其任务中“正确”的含义，无论是精确的字符串匹配、数值容差，还是自定义验证器。

该思路可能遇到的问题

如果初始示例集过小或缺乏代表性，所选提示词可能会出现过拟合，导致在实际应用中表现不佳。

后续关注点

该工具提供了一种替代方案：输入少量示例，让模型进行迭代，并获取系统在多次尝试中排名最高的提示词。演示程序位于原始公告中的链接，学习社区则聚集在 Telegram 上。

核心要点： 自动化提示词工程将猜测转变为可衡量的性能，但它需要前期的数据、计算资源以及明确的成功定义。