模型提供商不断推出越来越复杂的大型语言模型(LLM)，这些模型具有更长的上下文窗口和增强的推理能力。
这使得模型能够处理更多信息并进行更多“思考”，但同时也增加了计算量：模型处理和输出的信息越多，消耗的能量就越大，成本也就越高。
再加上提示词调整(prompting)所涉及的反复试验——可能需要尝试几次才能得到预期结果，而且有时手头的问题根本不需要一个能像博士那样思考的模型——计算支出可能会失去控制。
这催生了提示词操作(prompt ops)，一个在AI初露锋芒的时代中全新兴起的学科。
“提示词工程有点像写作，是实际的创作过程，而提示词操作则像出版，你不断优化内容，”IDC总裁Crawford Del Prete告诉记者，“内容是活的，内容在不断变化，你希望确保随着时间的推移不断优化它。”
计算使用与成本的挑战
在大型语言模型的背景下，计算使用与成本是两个“相关但独立的概念”，Vector研究所的应用科学家David Emerson解释道。一般来说，用户支付的价格基于输入令牌数(用户提示的内容)和输出令牌数(模型提供的内容)来计算，然而，对于幕后操作如元提示(meta-prompts)、导向指令或检索增强生成(RAG)等，费用并不会改变。
虽然更长的上下文允许模型一次处理更多文本，但这直接转化为更多的FLOPS(计算能力的度量单位)，他解释道。如果管理不善，模型的某些方面甚至会随着输入长度的增加而呈平方级增长。不必要地冗长的响应也会减慢处理时间，并需要额外的计算和成本来构建和维护算法，以便将响应处理成用户期望的答案。
通常，长上下文环境会激励提供商故意提供冗长的响应，Emerson说。例如，许多更复杂的推理模型(如OpenAI的o3或o1)往往会为简单问题提供长篇大论的回答，从而产生高昂的计算成本。
举个例子：
输入：回答以下数学问题。如果我有2个苹果，吃了1个后又买了4个，我有多少个苹果?
输出：如果我吃了1个，就只剩下1个了。如果我再买4个，就会有5个苹果。
模型不仅生成了比需要的更多的令牌，还把答案藏在了其中。工程师可能不得不设计一种编程方式来提取最终答案，或者提出后续问题如“你的最终答案是什么?”这又会增加更多的API成本。
或者，可以重新设计提示词以引导模型直接给出答案。例如：
输入：回答以下数学问题。如果我有2个苹果，吃了1个后又买了4个，我有多少个苹果?以“答案是”为开头回答……
或者：
输入：回答以下数学问题。如果我有2个苹果，吃了1个后又买了4个，我有多少个苹果?将最终答案用粗体标签括起来。
“提问的方式可以减少获得期望答案所需的努力或成本，”Emerson说。他还指出，像少样本提示(few-shot prompting，提供用户正在寻找的几个示例)这样的技术可以帮助更快地输出结果。
一个危险是不知道何时使用复杂的技术，如思维链(CoT)提示(分步生成答案)或自我优化，这些技术直接鼓励模型生成许多令牌或在生成响应时进行多次迭代，Emerson指出。
并非每个查询都需要模型在提供答案之前进行分析和重新分析，他强调说;当被指示直接回答时，它们可能完全能够正确回答。此外，不正确的提示API配置(如OpenAI的o3，需要高推理努力)在只需要低努力、更便宜的请求就足够时，会产生更高的成本。
“有了更长的上下文，用户还可能倾向于采用‘无所不包’的方法，即把尽可能多的文本塞进模型上下文中，希望这样做能帮助模型更准确地执行任务，”Emerson说，“虽然更多的上下文可以帮助模型执行任务，但这并不总是最佳或最高效的方法。”
向提示词操作的演变
如今，AI优化的基础设施很难获得，这已不是什么秘密。IDC的Del Prete指出，企业必须能够最小化GPU的闲置时间，并在GPU请求之间的空闲周期中处理更多查询。
“我如何从这些极其宝贵的资源中挤出更多?”他问道，“因为我必须提高系统利用率，因为我不能简单地通过增加容量来解决问题。”
提示词操作可以在很大程度上解决这一挑战，因为它最终管理的是提示词的生命周期。虽然提示词工程关注的是提示词的质量，但提示词操作则是关于重复和优化，Del Prete解释道。
“这更像是编排，”他说，“我把它看作是对问题的策划以及你如何与人工智能交互，以确保你从中获得最大利益。”
模型可能会“疲劳”，陷入循环中，输出质量下降，他说。提示词操作有助于管理、测量、监控和调整提示词。“我认为，三四年后当我们回顾时，这将成为一个完整的学科，它将是一项技能。”
虽然这仍然是一个新兴领域，但早期的提供商包括QueryPal、Promptable、Rebuff和TrueLens。随着提示词操作的发展，这些平台将继续迭代、改进并提供实时反馈，以使用户能够随时间更好地调整提示词，Del Prete指出。
最终，他预测，智能体将能够自己调整、编写和构建提示词。“自动化程度将提高，人机交互程度将降低，你将能够拥有更自主地创建提示词的智能体。”
常见的提示词错误
在提示词操作完全实现之前，实际上没有完美的提示词。根据Emerson的说法，人们犯的一些最大错误包括：
• 没有足够具体地说明要解决的问题，这包括用户希望模型如何提供答案、回答时应考虑什么、应遵守的约束条件以及其他因素。“在许多情况下，模型需要大量上下文才能提供符合用户期望的回答。”Emerson说。
• 没有考虑到可以简化问题以缩小回答范围的方法。答案是否应在某个范围内(0到100)?答案是否应表述为多项选择题而不是开放性问题?用户能否提供好的示例来为查询提供上下文?问题能否分解为步骤以进行单独和更简单的查询?
• 没有利用结构。大型语言模型非常擅长模式识别，许多模型都能理解代码。虽然使用项目符号、项目列表或粗体指示器(****)在人类看来可能“有点杂乱”，但Emerson指出，这些标注对大型语言模型来说是有益的。当用户希望自动处理响应时，请求结构化输出(如JSON或Markdown)也会有所帮助。
Emerson指出，基于工程最佳实践，在维护生产管道时还需要考虑许多其他因素。这些包括：
• 确保管道的吞吐量保持一致
• 监控提示词随时间的表现(可能针对验证集)
• 设置测试和早期预警检测以识别管道问题
用户还可以利用专门设计来支持提示词过程的工具。例如，开源的DSPy可以根据一些标记的示例自动为下游任务配置和优化提示词。虽然这可能是一个相当复杂的例子，但还有许多其他工具(包括ChatGPT、Google等内置的一些工具)可以协助设计提示词。
最终，Emerson说：“我认为用户能做的最简单的事情之一就是尽量跟上有效的提示词方法、模型发展和与模型交互的新方式。”
