提示词优化的自动化探索：Automated Prompt Engineering

提示词优化的自动化探索：Automated Prompt Engineering

引用

CSDN

1.

https://blog.csdn.net/Baihai_IDP/article/details/138186240

在探索如何让母亲使用大语言模型（LLM）完成工作任务时，作者发现提示词的优化并不像想象中那么简单。这引发了对自动化提示词优化工具的进一步探索。本文从两个角度分析了提示词工程的本质：将其视为超参数优化的一部分，以及将其视为一个需要不断尝试和调整的摸索、试错、修正过程。

提示词工程的本质

在过去的几个月里，作者一直在尝试构建各种 LLM-powered apps。在与 LLM 互动的过程中，作者发现撰写 Prompt 的过程可以基本实现自动化。关键在于搞清楚提示词工程（prompt engineering）的真正本质。

尽管互联网上有无数的提示词工程实践手册，但作者仍然无法确定提示词工程是一门艺术还是一门科学。一方面，当必须根据模型输出结果反复学习和润色 Prompt 时，感觉这像是一门艺术。随着时间的推移，作者发现一些微小的细节也非常重要，比如使用“must（必须）”而不是“should（应该）”，或者将 guidelines 放在提示词的末尾而不是中间。

另一方面，也有人可能会认为提示词只是一种超参数。归根结底，LLM 其实只把我们编写的提示词看作是嵌入向量，就像所有超参数一样。如果我们有一组已经准备好并且被认可的用于训练和测试机器学习模型的数据集，就可以对提示词进行调整并客观地评估其性能。

最近，HuggingFace 的 ML 工程师 Moritz Laurer 发表了一篇关于提示词优化的重要观点：

Every time you test a different prompt on your data, you become less sure if the LLM actually generalizes to unseen data… Using a separate validation split to tune the main hyperparameter of LLMs (the prompt) is just as important as train-val-test splitting for fine-tuning. The only difference is that you don’t have a training dataset anymore and it somehow feels different because there is no training / no parameter updates. Its easy to trick yourself into believing that an LLM performs well on your task, while you’ve actually overfit the prompt on your data. Every good “zeroshot” paper should clarify that they used a validation split for finding their prompt before final testing.

经过一番思考，作者认为答案介于两者之间。提示词工程到底是科学还是艺术，取决于我们想让 LLM 做什么。在过去的一年里，我们看到 LLM 做出了许多令人惊叹的事情，但作者倾向于将大家使用大模型的意图归类为两大类：解决问题和完成创造性的任务。

解决问题

在解决问题方面，我们让 LLM 解决数学问题、对情感进行分类、生成 SQL 语句、翻译文本等。一般来说，这些任务都可以归为一类，因为它们可以具有相对明确的 input-output pairs。对于这类具有 well-defined training data 的任务，提示词工程更像是一门科学。因此，本文的前半部分将从把 Prompt 看作超参数的角度进行探讨，专门探讨 automated prompt engineering 的研究进展。

完成创造性任务

在创造性任务方面，要求 LLM 完成的任务更加主观和模糊，如写邮件、报告、诗歌、摘要等。由于我们往往缺乏一个更客观的标准来说明我们希望 LLM 如何回应，因此创造性任务的性质和需求通常不太适合将提示词看作是可以像超参数一样进行调整和优化的参数。

在这些情况下，由于提示词工程仍然主要是通过不断的试验和调整来进行改进，而非一次性完成的，如何将自己的想法用于改进 Prompt，并仍保留 Prompt 的通用性，并不总是一目了然的。

第一部分：LLMs as Solvers

业内很多人都熟悉《Large Language Models are Zero-Shot Reasoners》一文中著名的 “Zero-Shot-COT” 术语。Zhou 等人在《Large Language Models are Human-Level Prompt Engineers》一文中更进一步探讨了其改进版本。以下是他们提出的 Automatic Prompt Engineer 方法的相关内容概述：

总结一下这篇论文：

1. 使用 LLM 根据给定的 input-output pairs 生成候选的指导性提示词。
2. 使用 LLM 为每个指导性提示词评分，可以根据使用该指导性提示词生成的答案与期望答案的匹配程度进行评估，也可以根据通过该指导性提示词获得的模型响应的对数概率来进行评估。
3. 根据高评分的候选指导性提示词迭代生成新的候选指导性提示词。

发现了一些有趣的结论：

• 除证明了（人类）提示词工程师和之前提出的算法性能更优之外，作者指出：“与直觉相反，在上下文中添加示例会损害模型性能…因为所选的指导性提示词过度拟合了零样本学习场景，因此在小样本的情况下表现不佳”。
• 迭代的蒙特卡洛搜索算法在大多数情况下其效果会逐渐减弱，但当 original proposal space 不够合适或不够有效时，却会表现良好。

随后在 2023 年，Google DeepMind 的一些研究人员推出了一种名为 “Optimisation by Prompting (OPRO) ” 的方法。与之前的例子相似，meta-prompt 中包含一系列 input/output pairs。这里的关键区别在于，meta-prompt 还包含了之前训练过的提示词样本及其正确的解答或解决方案和模型对这些提示词的解答准确率是多少，以及详细说明 meta-prompt 不同部分之间关系的指导性提示词。

正如作者解释的那样，研究工作中的每一次提示词优化步骤都会生成新的提示词，旨在参考之前的学习轨迹，让模型可以更好地理解当前任务，从而产生更准确的输出结果。

针对 Zero-Shot-COT 这种场景，他们提出了 “Take a deep breath and work on this problem step-by-step” 这种提示词优化方法，并取得了很好的效果。

对此，作者有几点想法：

• “不同类型的语言模型生成的指导性提示词风格差异很大。一些模型，如 PaLM 2-L-IT 和 text-bison 生成的指导性提示词非常简洁明了，而另一些如 GPT 的指令则冗长又相当详细。”这一点值得我们引起重视。目前市面上许多提示词工程的玩法都是以 OpenAI 的语言模型为参考对象编写的，但随着越来越多不同来源的模型开始被使用，我们应当注意，这些通用的提示词工程指南可能并不那么管用。论文 5.2.3 节中就给出了一个例子，展示了模型性能对指导性提示词对微小变化的高度敏感性。我们需要更多关注这一点。

例如，在 GSM8K 测试集上使用 PaLM 2-L 评估模型时，“Let’s think step by step.” 的准确率达到了71.8%，“Let’s solve the problem together.”的准确率为60.5%，而前两个指导性提示词的语义组合，“Let’s work together to solve this problem step by step.”的准确率仅为49.4%。

这种行为既增加了单步指导性提示词之间的差异，也增加了优化过程中出现的波动，促使我们在每个步骤生成多个指导性提示词，以提高优化过程的稳定性。

论文的结语中还提到了另一个要点：“我们目前将算法应用于实际问题中的一个局限是，用于优化提示词的大语言模型，未能有效地利用训练集中的错误案例来推断有希望的提示词改进方向。在实验中，我们尝试在 meta-prompt 中加入模型在训练或测试时出现的错误案例，而非在每个优化步骤中从训练集中随机抽样，但结果大同小异，这表明仅凭这些错误案例的信息量不足以让 optimizer LLM 了解产生错误预测的原因。” 这一点确实值得强调，因为尽管这些方法有力地证明了提示词的优化过程与传统 ML/AI 中的超参数优化过程类似，但我们往往会偏向于使用正面、积极的例子，无论是我们想要向 LLM 提供什么样的内容输入，还是我们如何指导 LLM 改进提示词。然而，在传统的 ML/AI 中，这种偏好通常没有这么明显，我们更注重如何利用错误的信息来优化模型，而非过多关注错误本身的方向或类型（即我们对 -5 和 +5 的误差大多一视同仁）。

如果你对 APE（Automated Prompt Engineering）感兴趣，可以前往https://github.com/keirp/automatic_prompt_engineer 下载使用。

在 APE 和 OPRO 这两种方法中都有一个关键要求，需要有训练数据来帮助优化，并且数据集需要足够大，以确保经过优化的提示词的通用性。

第二部分：LLMs as Creators

现在，让我们探讨另一类 LLM 任务，在这类任务中，我们可能没有现成的数据。假如我们现在要构思一些短篇小说。而我们根本没有小说文本示例来训练模型，并且编写一些合格的小说文本示例需要的时间又太长。此外，我们并不清楚让大模型输出一个“所谓正确”的回答是否有意义，因为可能有很多种模型输出都是可以接受的。因此，对于这类任务来说，使用 APE 等方法实现提示词工程的自动化几乎是不切实际的。

但是，有些读者可能会有疑问，为什么我们甚至需要将写提示词的过程自动化呢？可以从任意一个简单的提示词开始调整，比如 “provide me with 3 short story ideas about {{issue}} in {{country}}”，将 {{issue}} 用 “inequality” 填充，将 {{country}} 替换为 “Singapore”，观察模型响应结果，发现问题，调整提示词，再观察此次调整是否有效，反复执行这个流程。

但在这种情况下，谁能从提示词工程中获益最多呢？恰恰是那些经验并不丰富的提示词编写初学者，他们没有足够的经验去调整和改进提供给模型的提示词。作者在教妈妈使用 ChatGPT 完成工作任务时，就亲身体会了这一点。作者意识到，无论我们的提示词工程技术如何，我们真正擅长的是表达我们所看到的问题（即抱怨）的能力。因此，作者尝试构建了一个工具来帮助用户表达他们的抱怨，并让 LLM 为我们改进提示词。

首先，编写带有 {{}} 变量的提示词。该工具将检测到这些占位符，供我们后续填写，在此还是使用上文的这个样例，要求大模型输出一些关于新加坡不平等现象的创意故事。

接下来，该工具会根据填写的提示词生成模型响应。

然后给出我们的反馈意见（想对模型输出表达的抱怨）：

然后要求模型停止生成更多的故事创意示例，并输出第一次迭代改进的提示词。请注意，下文给出的提示词经过了改进并泛化了，要求 “描述克服或应对这些挑战的相关策略…（describe the strategies…to overcome or engage with these challenges）”。而作者对第一次模型输出的反馈意见是 “谈谈故事主角是如何解决不平等现象的”。

然后，我们使用改进后的提示词，要求大模型再次构思短篇小说。

我们也可以选择点击““Generate Next Example”，可以让我们基于其他输入变量生成新的模型响应。下面是生成的一些关于中国裁员问题的创意故事：

然后对上述模型输出给出反馈：

然后，对提示词进行了进一步的优化：

这次的优化结果看起来还不错，毕竟最初这只是一句简单的提示词，经过不到两分钟（虽然有些随意）的反馈，经过三次迭代后得到了这个优化后的提示词。现在，我们只需坐下来对 LLM 的输出结果表达不满，就能持续对提示词进行优化。

这个功能的内部实现方式就是从 meta-prompt 开始，不断根据用户的动态反馈优化生成新的提示词。没有什么花里胡哨的东西，肯定还有进一步改进的空间，但已经是一个不错的开端了。

使用该工具过程中得到的一些观察：

• GPT4 在生成文本时倾向于使用大量词语（“多言”特性）。因为这个原因，可能存在两点影响。首先，这种"多言"特性可能会助长对特定示例的过拟合。如果给 LLM 提供过多词汇，它就会利用这些词汇来修正用户做出的具体反馈。其次，这种"多言"特性可能会损害提示词的有效性，特别是在冗长的提示词中，一些重要的指导性信息可能会被掩盖。我认为第一个问题可以通过写好 meta-prompts 来解决，以促使模型根据用户反馈实现泛化。但是第二个问题比较棘手，在其他使用案例中，当提示词过长时指导性 Prompt 往往会被忽略。我们可以在 meta-prompt 中添加一些限制条件（例如上文提供的 prompt 样例那样对字数进行限制），但这确实比较随意，而且提示词中的某些限制或规则可能会受到底层大模型的特定属性或行为的影响。
• 改进后的提示词有时会忘记之前对提示词所进行的优化。解决这一问题的一种方法是向系统提供更长的改进历史记录，但这样做会导致改进的提示词变得过于冗长。
• 这种方法在初次迭代中的一个优势是，LLM 可能会提供不属于用户反馈内容的改进指南。例如，在上文的第一词优化时，该工具添加了“对所讨论的问题提供更广阔的视角…（Provide a broader perspective on the discussed issue…）”，即使作者提供的反馈只是要求提供拥有可靠来源的相关统计数据。

作者还没有部署这个工具，因为他仍在研究 meta-prompt，看看哪种方法效果最好，并解决一些 streamlit 框架存在的问题，然后处理程序中可能出现的其他错误或异常。但该工具应该很快就会上线了！

结论

整个提示词工程领域都专注于为解决任务提供最佳的提示词。APE 和 OPRO 是该领域中最为重要、最为优秀的例子，但并不代表全部，对未来我们能够在该领域取得多大进步感到兴奋和期待。评估这些技术在不同模型上的效果，可以揭示这些模型的工作倾向或工作特点，也能帮助我们了解哪种 meta-prompt 技术是有效的，因此这些都是非常重要的工作，有助于我们在生活生产实践中使用 LLM。

但是，对于希望将 LLM 用于完成创造性任务的其他人来说，这些方法可能并不适用。就目前而言，现有的很多学习手册都可以可以带领我们入门，但没有什么能胜过反复不断地尝试和试验。因此，在短期内，最有价值的是我们如何高效地完成这个符合我们人类优势的实验过程（给予反馈），并让 LLM 完成剩下的工作（改进提示词）。

作者也会在他的 POC（Proof of Concept） 上多下功夫，如果你对此感兴趣，欢迎联系他（https://www.linkedin.com/in/ianhojy/） ！

本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。

原文链接：
https://towardsdatascience.com/automated-prompt-engineering-78678c6371b9