Prompt进阶2：LangGPT（构建高性能Prompt策略和技巧）——最佳实践指南

0. 前言

先看下面两张图。提示词几乎一模一样，唯一的区别就是“提示工程”这个词用了中文还是英文表达。结果呢？一词之差，回答质量天壤之别。这背后的道理很简单：模型不会读心术，你给提示词的方式，直接决定了它能不能准确理解你的意图。所谓提示工程，说人话就是——想办法调整提示词，让模型输出更接近你想要的东西。

很多人容易掉进一个误区：以为 prompt 就是自己精心设计的那一小段提示词，却忽略了 prompt 的其他来源。用输入法来打个比方：第一张图里，“春眠”是我们的输入，“不觉晓”是模型输出，那么“春眠”就是 Prompt。到了第二张图，“春眠不觉晓”成了输入（因为“不觉晓”是上一轮的输出），“处处闻啼鸟”是输出，所以“春眠不觉晓”也成了 Prompt。你看，prompt 的来源可以是你预先设定的提示词，也可以是用户的输入，甚至可以是模型自己上一轮的输出。所以，想用好大模型，必须意识到一件事：所有会被模型用来预测输出结果的内容，都是 Prompt。

相比一般的提示词，这种把提示词从“作文题”变成“填空题”的做法，编写门槛降低了，同时表达更清晰、能力更强。

1.1 六大提高性能的策略

1.1 策略一：清晰地表达指令

GPT 可不会猜你的心思。如果输出太长，就要求它简短回复；如果太简单，就要求它写出专业水准；如果不喜欢输出的格式，直接示范你想要的格式。模型的猜测越少，你得到满意结果的概率就越大。

• 查询时带上更多细节，才能拿到更对路的回答
• 让模型扮演特定角色
• 用分隔符清楚标出输入的不同部分
• 列出完成任务所需的步骤
• 给个示例
• 明确期望的输出长度（字数、段落数、项目符号数等）

1.2 策略二：提供参考文本

GPT 模型在遇到冷门话题或被要求提供引用时，会非常自信地编造虚假答案。就像考前准备笔记本能帮学生考得更好一样，给模型提供参考文本，能有效减少胡说八道的可能。

• 明确要求模型根据你提供的参考文本作答
• 要求模型在回答里引用参考文本中的具体段落

1.3 策略三：将复杂任务分解为更简单的子任务

在软件工程里，把复杂系统拆成模块是最好的实践。这个道理对 GPT 同样适用——复杂任务的错误率远高于简单任务。而且，复杂任务往往可以重构成一系列简单任务的工作流，早期任务的输出正好用于构造后期任务的输入。

• 用意图分类先判断用户查询属于哪一类，再推送对应的指令
• 对于超长对话，及时总结或过滤之前的对话内容
• 分段摘要长文档，再递归地构建完整摘要

1.4 策略四：给予 GPT“思考”的时间

假如让你立刻算 17×28，你肯定不能脱口而出，但静下来思考就能算出来。模型也一样——如果被逼着马上回答，更容易犯推理错误；如果让它一步一步想，结果会更靠谱。

• 让模型先自己推导出答案，再下结论
• 用内心独白或分步查询，把推理过程藏起来（只展示最终回复）
• 问模型在之前的轮次里有没有漏掉重要信息

1.5 策略五：使用外部工具

GPT 的输入有短板，那就给它补上。文本检索系统可以为模型提供相关文档，代码执行能完成更精确的计算或调用外部 API。一句话：如果某个任务由专门工具做更靠谱、更高效，就大胆外包出去——鱼和熊掌可以兼得。

• 用基于嵌入的搜索实现高效知识检索
• 用代码执行做精确计算或调用外部 API
• 允许模型调用你定义的特定函数

1.6 策略六：系统地测试更改

有时候你很难判断某项改动到底有没有提升系统性能。光看几个例子可能会产生错觉，但样本太少时，你分不清是真实改进还是运气好。说不定某个改动对某些输入有好处，对另一些输入却是灾难。

一个像样的测评流程对优化系统设计至关重要。好的测评要满足三条：

• 能代表真实使用场景（至少覆盖多种情况）
• 包含足够多的测试用例，保证统计可信度（参考下表）
• 容易自动化，或者可以反复执行

评估可以由计算机、人工或两者结合完成。计算机可以用客观标准（比如只有唯一正确答案的问题）自动测评，也可以用其他模型来评判一些主观或模糊的标准。OpenAI Evals 是一个开源框架，提供了构建自动化测评的工具。

对于输出范围广且质量同样高的问题（比如需要长答案的题目），基于模型的测评就能派上用场。这类测评与需要人工评估的问题边界逐渐模糊，而且随着模型越来越强，它的适用范围也在不断扩大。建议你多试试，看看基于模型的测评对你的场景有多大帮助。

• 根据参考答案的标准来评估模型输出

2. 技巧深入

上面每种策略都可以用具体的技巧落地。下面列出的技巧只是给你提供思路，绝不是什么金科玉律——大胆尝试那些这里没写的创意吧。

2.1 策略一：清晰地表达指令

技巧：在查询中包含更多细节，以获取更相关的回答

想要高度相关的回复，就得在查询里提供所有重要的细节或上下文，不让模型去瞎猜你的意图。下面这个表格直观对比了劣质提问和优质提问的差距：

技巧：要求模型采用特定的角色

系统消息可以指定模型在回复时扮演什么角色，比如“你是经验丰富的产品经理”“你是资深财务分析师”。

技巧：使用分隔符清楚地指示输入的不同部分

三引号、XML标签、标题等分隔符能帮你标记不同性质的文本片段。简单任务可能用不上，但任务越复杂，越要明确细节——别让模型费劲琢磨你到底要什么。

技巧：指定完成任务所需的步骤

有些任务最好写成步骤清单。把步骤明明白白写出来，模型就更容易按你的套路走。

技巧：提供示例

有时直接给几个不同变体的示例比单靠文字说明更高效，尤其是当你想让模型模仿某种难以言传的风格时。这就是所谓的“few-shot”提示。

技巧：指定期望的输出长度

你可以要求模型生成特定字数的回答，不过模型对字数的估计并不精确。更可靠的办法是用段落数、句子数或项目符号数来控制长度。

2.2 策略二：提供参考文本

技巧：指示模型使用提供的参考文本进行回答

如果你能给模型一些可信的背景信息，就明确告诉它“用我给你的这些材料来回答”。因为模型上下文窗口有限，你还需要动态地根据问题查找相关信息并塞进输入里。嵌入技术可以实现高效的知识检索，具体方法可以参考“使用基于嵌入的搜索实现高效知识检索”这一节。

技巧：指示模型使用参考文本中的引文进行回答

既然你已经提供了相关知识，那就要求模型在回答里引用原文段落。这样你还可以通过字符串匹配来程序化验证引文是否正确。

2.3 策略三：将复杂任务分解为更简单的子任务

技巧：使用意图分类，识别与用户查询最相关的指令

对于需要大量独立指令集应对不同情况的任务，先对查询进行分类再推送对应的指令，效率很高。你可以定义几个固定类别，为每个类别写一套专用的指令。这个过程还能递归进行，把任务分解成串行阶段。这样做的好处是，每个查询只包含下一步需要的指令，错误率远比一次处理所有指令低，成本也更低（更长的提示意味着更高的运行成本）。

举个例子，客户服务应用可以把查询分成这些类：

根据客户查询的分类，模型就能得到更具体的指令。比如客户需要“故障排除”帮助时，系统会注入特定的故障处理流程。

注意，你还可以指示模型在对话状态发生变化时输出特殊字符串。这样就能把系统变成一个状态机，状态决定注入哪些指令。通过跟踪状态、状态相关的指令以及允许的转移，你可以设置更严格的约束，减少不确定性。

技巧：对需要非常长对话的对话应用，汇总或过滤之前的对话

上下文长度有限，不可能无限地把整个对话都塞进窗口。解决办法有两个：一是当输入达到预定长度阈值时，用一次查询总结部分对话，然后把总结放进系统消息；二是在整个对话过程中异步地在后台做总结。

另一个方案是动态选择与当前查询最相关的之前对话片段，具体还是参考“使用基于嵌入的搜索实现高效知识检索”。

技巧：分段摘要长文档，递归构建完整摘要

文档太长，一次摘要超出上下文长度，那就分段来做。把每段摘要连起来，再做摘要的摘要。这个过程可以递归，直到覆盖整个文档。如果后面部分需要前面部分的信息，可以在摘要当前内容时，把之前部分的运行摘要也带上。OpenAI 此前用 GPT-3 变体做过递归摘要书籍的研究，效果不错。

2.4 策略四：给予 GPT“思考”的时间

技巧：指示模型在匆忙得出结论之前，自己推导出解决方案

有时候，直接让模型先自己算出答案，再回复用户，效果更好。比如你想让模型评判一个学生的数学解答：

SYSTEM：首先自己解出这道题并生成答案。然后再比较你的答案和学生的答案，判断学生的答案是否正确。在比较之前，不要依赖学生的答案来决定其是否正确。

USER：<插入题目>

<插入学生答案>

ASSISTANT：<模型先生成自己的答案>

<模型比较两个答案并作出评价>

技巧：使用内心独白或一系列查询来隐藏模型的推理过程

有些场景下，你不想让用户看到模型的全部推理过程，只展示最终回复。可以用“内心独白”把需要隐藏的部分放进特定格式，展示前去掉。或者，设计一系列查询，只有最后一个查询的输出对外公开。

#隐藏查询1：只给问题描述，让模型解出答案

#隐藏查询2：给问题描述、模型解答和学生解答，让模型判断学生解答正确性

#可见查询：假设模型是位有帮助的导师，如果学生错了就提示，对了就鼓励

技巧：在前几轮后询问模型是否遗漏了相关信息

当你让模型列举某段文本里的所有相关摘录时，它常常罗列到一半就停了。这时可以多追问一轮“还有没有遗漏的？”来补全结果。

2.5 策略：使用外部工具

技巧：使用基于嵌入的搜索实现高效知识检索

在模型输入中加入相关的外部信息，能帮它生成更准确的回复。比如用户问某部电影，就把演员、导演等高质量信息一起加进去。通过文本嵌入实现高效知识检索，可以在运行时动态地把相关信息塞进输入。具体实现可以参考 OpenAI Cookbook。

技巧：使用代码执行进行更精确的计算或调用外部 API

GPT 模型自己算算术或长时间计算误差很大。不如让它写代码，然后运行代码算结果。代码执行也能用来调用外部 API——只要事先教模型怎么用，它就能写出调用的代码。注意，运行模型生成的代码存在安全风险，务必做好防护措施。

技巧：系统地测试各种改变

判断某项改变是否真的提升了系统性能，光看几个例子是不够的。一个像样的评估流程很有用：代表真实场景、包含足够多的测试用例。评估可以由计算机、人工或两者混合完成。计算机能自动做客观评估，OpenAI Evals 提供了现成的开源工具。

当存在多种质量相当的输出时，用模型来做评估也是可行的。建议针对你的使用场景多试试，看看模型评估能发挥多大作用。

技巧：参照标准答案来评估模型输出

如果问题的正确答案需要包含某些特定事实，你可以用模型查询来统计答案里涉及了多少个要点。例如：

SYSTEM：检查提交的答案是否直接包含下列信息：

- Neil Armstrong 是第一个登月的人
- Neil Armstrong 首次登月的日期是 1969年7月21日

对于每个要点：
1. 重述要点
2. 提供与要点最相关的答案摘录
3. 分析仅看摘录的人是否可以推断出该要点，解释推理过程
4. 如果答案是肯定的，写 "yes"，否则写 "no"

最后，统计 "yes" 的个数，用以下格式提供：

{“count”: }

如果答案满足所有要点，count 就是要点总数；如果只满足部分，count 会小于总数。你可以基于这个思路构建不同的模型评估变体，比如统计答案与标准答案的重合度，或者找出矛盾之处。