展示了如何迅速工程可以是一个真实的的系统的方法，从语言模型中提取的价值。
“提示工程Prompt Engineering”源于语言模型的发展，描述了应用提示以有效地从语言模型中提取信息的过程，通常用于现实世界的应用程序。
但是很多做提示工程的人实际上只是盲目的提示。
“盲目提示”是我用来描述创建提示的方法，该方法采用粗略的试错法，结合最少或没有测试以及非常表面的提示知识。盲目提示不是提示工程。
什么是提示？
对于语言模型（想象一下 ChatGPT，如果您不熟悉这个术语），“提示”是用户生成的模型输入。
在 ChatGPT 中，它可以有效地理解为您输入的文本框。然后语言模型“推断”您的提示“完成”。例如，如果我在 ChatGPT 中键入“4 + 3 =”，它会以“7”（可能）响应。在这种情况下，“4 + 3 =”是提示，“7”是完成。
“提示”是使用提示作为从模型中提取所需信息的方式的行为。
最后，“提示工程”描述了一个更严格的学科（如本文中所示），旨在利用提示作为为实际应用程序构建可靠功能的一种方式。它不同于 ChatGPT 风格的提示，因为通过提示工程生成的提示通常意味着在大量、不同的情况下重复使用，以便可靠地解决应用程序的特定问题。
问题
首先，您必须要尝试为其构建解决方案的问题。
该问题可用于评估提示是否是最佳解决方案，或者是否存在可能更适合作为解决方案的替代方法。
工程从不是为了方法而使用方法开始，而是在相信它是正确方法的信念的驱使下开始。
对于此示例，我们将假设我们是一家构建日历客户端的公司。我们希望用户能够使用自然语言输入事件。例如：
下周二在塔可钟与爱丽丝共进晚餐 |
语言模型可能是一个很好的解决方案，可以采用这种自然语言输入并提取结构化输出来描述我们随后可以在应用程序中使用的事件。
显然还有其他潜在的解决方案。我们可以利用一组正则表达式和字符串搜索来寻找常见的短语（在<星期几>，明天，今天，下周，等等）。
语言模型有其自身的好处：它们可能提供一种能更好地处理其他语言的方法，或者可能更好地处理错别字或语法错误，或者在最坏的情况下，如果正则表达式失败，可能是一个很好的后盾。在任何情况下，都有足够的希望继续将提示作为一种潜在的解决方案来追求。
演示集
接下来，我们必须组装一个演示集。演示集包含预期输入和预期输出。这个集合将服务于多个目标：
- 它将用于衡量我们提示的准确性。通过使用单个演示的输入，我们可以断言我们收到了预期的输出。
- 它指定了我们期望提示输入和输出的样子，使我们作为工程师能够确定它是否适合我们的问题。
- 如果我们选择使用少量提示，我们可以使用该演示集的一个子集作为少量方法的范例。对于那些不熟悉术语“few-shot”的人，few-shot 是一种提示方式，除了提示之外还给出了示例。
上面的第（2）点非常重要。我们需要对我们期望的输入和期望的输出有一些大致的了解，因为在这两个方面 [通常] 需要确保数据采用特定格式并期望返回特定格式的软件。这与典型的软件工程没有什么不同，在典型的软件工程中，我们将问题分解为一组具有某些输入/输出期望的函数。
我们可以利用之前的示例并将它们扩展为完整的演示：
Q: Dinner with Alice next Tuesday at Taco Bell下周二在塔可钟与爱丽丝共进晚餐 |
上面的演示有两个重要的决定。对于任何提示问题，您都必须做出类似的决定。
首先，我们只提取一条信息。尝试让模型提取我们的整个事件（例如事件名称、与会者、时间、位置等）并将其输出为一些漂亮的即用型 JSON 或其他格式可能很诱人。该模型可能能够做到这一点。但是在处理一个新问题时，我建议先将其分解为一个问题。这使得问题更容易处理，并且最终会给你一个基线精度，你可以用它来衡量多输出方法是否真的值得。
第二，我们的输出没有被转换。我们不会尝试将所有内容都变成日期或尝试确保所有内容都正确大写等。我们正在进行文字文本提取。那里有很棒的确定性库，可以将诸如“下周二”之类的字符串以极高的准确性转换为时间戳。这不是我们需要语言模型为我们做的事情。所以，让我们拿出粗略的日期格式（“下周二”、“11/4”、“明天”），并解决使用传统编程方法将其转换为时间戳的问题，因为这是一个微不足道的问题。输出越简单，就越容易获得更高的精度。
最后，关于输出解码的简要说明： LLM 会以各种方式完成你的提示：它可能是一个完整的句子，可能会添加一个句号，可能是大写的等等。你应该确定你希望 LLM 的输出有多完美在验证您的演示集之前，您愿意标准化多少。
我的建议：使 LLM 的输出尽可能简单灵活，并在您的应用程序中执行一些规范化操作。不要试图强迫 LLM 输出完全完美的格式来开始。早期在 LLM 中执行过多的“输出整形”使得难以将 LLM 执行某些核心任务（在本例中为信息提取）的能力与其构建输出的能力区分开来。
相信点击标题