提示工程基础（上）

原文出处：Prompt Engineering Fundamentals 原作者：Microsoft · 许可证：MIT License 中文译本由诸葛AI学院整理，仅供学习参考，版权归原作者与微软所有。

（这是原课程第 4 课译文的上篇，对应原文从引言到 GitHub Copilot 案例研究的部分；提示词的结构设计与最佳实践见下篇。译文按资料库规范不保留图片。）

引言

本模块讲解在生成式 AI 模型中编写有效提示词（prompt）的核心概念和技巧。你给大语言模型（Large Language Model，LLM）写提示词的方式是有讲究的，精心设计的提示词能换来更高质量的回答。那么"提示词""提示工程（prompt engineering）"这些词到底指什么？我该怎么改进发给 LLM 的输入？这一章和下一章就来回答这些问题。

生成式 AI 能够根据用户的请求创建新内容（文本、图片、音频、代码等）。它靠的是 GPT（"生成式预训练变换器"，Generative Pre-trained Transformer）这类大型语言模型，这些模型是用自然语言和代码训练出来的。

用户现在可以用聊天这样熟悉的交互方式使用这些模型，不需要专门的技术背景。这类模型是基于提示词的：用户发一段文字输入（prompt），拿回 AI 的回答（completion，补全）。然后用户可以"和 AI 聊天"，在多轮对话里反复调整提示词，直到回答符合预期。

提示词就此成了生成式 AI 应用的主要编程接口：告诉模型该做什么，同时影响返回回答的质量。"提示工程"是一个快速发展的研究领域，关注如何设计与优化提示词，规模化地稳定产出高质量回答。

学习目标

在这节课里，我们将了解什么是提示工程、它为什么重要、怎样针对特定模型和应用目标写出更有效的提示词。我们会掌握提示工程的核心概念和最佳实践，并认识一个可交互的 Jupyter Notebook"沙盒"环境，在里面看这些概念如何用在真实例子上。

学完这节课，你将能够：

1. 解释什么是提示工程，以及它为什么重要。
2. 说明一条提示词由哪些部分组成、各部分怎么用。
3. 学习提示工程的最佳实践和技巧。
4. 用 OpenAI 接口，把学到的技巧应用到真实例子上。

关键词

• 提示工程（Prompt Engineering）：设计并打磨输入，引导 AI 模型产出想要的输出的实践。
• 令牌化（Tokenization）：把文本转换成更小的单位"令牌（token）"，也就是字块，模型理解和处理的就是这些字块。
• 指令微调 LLM（Instruction-Tuned LLMs）：用特定指令做过微调的大语言模型，回答更准、更贴题。

练习沙盒

提示工程这门手艺，眼下是艺术多过科学。想练出直觉，最好的办法是多动手，用试错法，把对应用领域的理解、推荐技巧和针对具体模型的优化结合起来。

本课配套的 Jupyter Notebook 提供了一个沙盒环境，学到哪里就可以试到哪里，也可以用来完成后面的代码挑战。跑练习需要三样东西：

1. 一个 Azure OpenAI API key，也就是已部署 LLM 的服务接口地址。
2. 一个能跑 Notebook 的 Python 运行环境。
3. 本地环境变量。现在就照 SETUP 步骤 配置好。

Notebook 里带了入门练习，但也鼓励你自己加 Markdown 单元格（写说明）和代码单元格（发提示词请求），多试些例子和点子，练出提示词设计的直觉。

图解导览

想在深入细节之前先看全貌？可以看这份图解指南，它列出了本课的主要话题和每个话题下你该思考的要点。课程路线图从核心概念和挑战讲起，再走到对应的提示工程技巧与最佳实践。注意：指南里的"进阶技巧"部分，讲的是本课程下一章的内容。原文此处有一张手绘风格的图解笔记。

我们的创业公司

现在说说这个主题和我们创业目标的关系：我们要把 AI 创新带进教育。我们想做个性化学习的 AI 应用，那就来想想不同用户会怎么"设计"提示词：

• 学校管理者可能会让 AI 分析课程数据，找出覆盖面缺口。AI 可以汇总结果，或者用代码做成可视化。
• 教师可能会让 AI 针对目标学生和主题生成一份教案。AI 能按指定格式做出个性化教案。
• 学生可能会让 AI 辅导自己薄弱的科目。AI 就能按学生的水平，给出贴合的讲解、提示和例子。

这还只是冰山一角。去看看 Prompts For Education，一套由教育专家整理的开源提示词库，能帮你打开思路。在沙盒里或用 OpenAI Playground 跑几条试试，看会发生什么！

什么是提示工程？

本课开头我们把提示工程定义为：针对特定的应用目标和模型，设计与优化文本输入（提示词），以稳定产出高质量回答（补全）的过程。可以拆成两步：

• 为给定的模型和目标设计第一版提示词
• 反复打磨提示词，提高回答质量

这必然是一个试错过程，要靠用户的直觉和投入才能拿到最优结果。那它为什么重要？要回答这个问题，先得理解三个概念：

• 令牌化：模型怎么"看"提示词
• 基础 LLM（Base LLM）：基础模型怎么"处理"提示词
• 指令微调 LLM：模型为什么能看懂"任务"

令牌化

LLM 把提示词看成令牌序列。不同模型（或同一模型的不同版本）对同一条提示词的切分方式可能不同。LLM 是在令牌上训练出来的，不是直接在原始文本上，所以提示词怎么被切分，直接影响生成回答的质量。

想对令牌化有点体感，可以试试 OpenAI 提供的 Tokenizer 工具。把你的提示词粘进去，看它怎么被转成令牌，留意空格和标点是怎么被处理的。注意这个例子展示的是较早的模型（GPT-3），换更新的模型结果可能不一样。原文此处有一张令牌化演示的截图。

概念：基础模型

提示词被切成令牌之后，"基础 LLM"（也叫基础模型）的主要工作就是预测序列中的下一个令牌。LLM 在海量文本数据集上训练过，对令牌之间的统计关系有很好的把握，可以有把握地做出这个预测。注意，它们并不理解提示词或令牌里词语的"含义"，只是看到一个可以用下一次预测"补全"的模式。它们会一直预测下去，直到用户打断或触发预先设定的终止条件。

想看基于提示词的补全是怎么运作的？把上面那条提示词按默认设置输入 Microsoft Foundry playground。这个系统的设定是把提示词当作信息查询来对待，所以你看到的补全会贴合这个语境。原文此处有一张基础 LLM 对话补全的界面截图。

但如果用户想要的是满足某些标准或任务目标的特定内容呢？这就是指令微调 LLM 出场的地方。

概念：指令微调 LLM

指令微调 LLM 以基础模型为起点，再用示例或输入/输出对（比如多轮"消息"）做微调，这些样本里含有明确的指令，以及 AI 尝试遵循该指令后得到的回应。

这背后用到了人类反馈强化学习（Reinforcement Learning with Human Feedback，RLHF）之类的技术，训练模型去遵循指令、从反馈中学习，让它的回答更适合实际应用场景、更贴近用户目标。

我们动手试试。回到上面那条提示词，把系统消息（system message）改成下面这条指令作为语境：

面向小学二年级学生总结提供给你的内容。结果控制在一个段落、3 到 5 个要点。

看看结果是不是变成了想要的目标和格式？教师现在可以直接把这段回答用进课堂幻灯片。原文此处有一张指令微调后对话补全的界面截图。

为什么需要提示工程？

既然知道了 LLM 怎么处理提示词，我们来谈谈为什么还需要提示工程。答案在于：当前的 LLM 存在不少挑战，不在提示词的构建和优化上下功夫，就很难拿到可靠、稳定的补全。比如：

1. 模型输出是随机的（stochastic）。 同一条提示词，在不同模型或不同模型版本上很可能得到不同回答；哪怕是同一个模型，不同时间跑，结果也可能不一样。提示工程技巧能通过设置更好的护栏来减少这类波动。

2. 模型会编造回答。 模型的预训练数据集再大也是有限的，训练范围之外的概念它并不知道。结果就是，它可能给出与事实不符、凭空想象、甚至直接和已知事实矛盾的内容。提示工程技巧能帮用户识别并缓解这类编造，比如要求 AI 给出引用或推理过程。

3. 模型能力参差不齐。 更新的模型或新的模型代际能力更强，但也有各自的怪脾气，在成本和复杂度上各有取舍。提示工程能帮我们把差异抽象掉，沉淀出可复用的最佳实践和工作流，以可扩展、平滑的方式适配具体模型的要求。

我们到 OpenAI 或 Azure OpenAI Playground 里看一下实际效果：

• 把同一条提示词发给不同的 LLM 部署（OpenAI、Azure OpenAI、Hugging Face 等），你看到差异了吗？
• 把同一条提示词反复发给同一个 LLM 部署（比如 Azure OpenAI playground），这些差异又表现在哪里？

编造示例

在本课程中，我们用"编造（fabrication）"这个词来指 LLM 由于训练局限或其他约束、有时生成事实错误内容的现象。大众文章或论文里也可能见到"幻觉（hallucinations）"的叫法。不过我们强烈建议用"编造"这个说法，避免把机器行为拟人化、给机器安上人类特征。从术语上讲，这也更贴合负责任的 AI 准则，去掉了一些在特定语境下可能冒犯或不包容的用词。

想体会编造是怎么发生的？构造一条让 AI 为不存在的话题生成内容的提示词（确保它不在训练数据里）。比如我试过这条：

提示词： generate a lesson plan on the Martian War of 2076.（生成一份关于 2076 年火星战争的教案。）

我上网搜过，关于火星战争的虚构作品（电视剧、书籍）是有的，但没有 2076 年的。常识也告诉我们 2076 年在未来，不可能对应真实事件。

那么把这条提示词发给不同的 LLM 供应商，会发生什么？原文此处依次有三张截图，分别是 OpenAI Playground（GPT-35）、Azure OpenAI Playground（GPT-35）和 Hugging Face Chat Playground（LLama-2）对这条提示词的回答。

和预期一致，由于随机行为和能力差异，每个模型（或模型版本）的回答都略有不同。比如一个模型把目标听众设为初中八年级，另一个假设是高中生。但三个模型给出的回答，都足以让不明就里的用户信以为真。

元提示（metaprompting）、配置温度（temperature）这类提示工程技巧，能在一定程度上减少模型编造。新的提示工程架构也会把新工具、新技巧无缝接入提示流程，来缓解或削弱这些影响。

案例研究：GitHub Copilot

我们用 GitHub Copilot 这个案例，看看提示工程在真实产品中是怎么用的，为本节收尾。

GitHub Copilot 是你的"AI 结对程序员"：它把文本提示词转成代码补全，并且集成在你的开发环境（比如 Visual Studio Code）里，用起来无缝衔接。如下面这组博客所记载，最早的版本基于 OpenAI Codex 模型，工程师们很快意识到需要微调模型、发展更好的提示工程技巧，来提高代码质量。到了七月，他们发布了超越 Codex 的改进版 AI 模型，给出更快的建议。

建议按时间顺序阅读这些文章，跟着走完他们的学习历程：

• 2023 年 5 月 | GitHub Copilot 理解你的代码的能力在进步
• 2023 年 5 月 | 深入 GitHub：与 GitHub Copilot 背后的 LLM 一起工作
• 2023 年 6 月 | 如何为 GitHub Copilot 写出更好的提示词
• 2023 年 7 月 | GitHub Copilot 换上改进版 AI 模型，超越 Codex
• 2023 年 7 月 | 开发者的提示工程与 LLM 指南
• 2023 年 9 月 | 如何构建企业级 LLM 应用：来自 GitHub Copilot 的经验

你也可以逛逛他们的工程博客，找更多像这篇的文章，看这些模型和技巧怎么被用在真实应用上。

从原理上讲，提示词会被怎么处理、编造（fabrication）问题从何而来，见上篇；本篇讲提示词的结构设计与最佳实践。