收益：
- 可以用例子解释上下文如何决定输出的准确性
- 可以选择和配置任务所需的上下文信息
- 识别并避免冗余、矛盾或隐藏上下文的风险
即使你把同样的任务交给两个人，如果其中一个人了解情况而另一个人对此一无所知，就会出现截然不同的结果。对于人工智能来说，情况也完全一样。上下文是告诉模型“在什么背景下工作”的信息：为谁、为了什么目的、有什么历史、在什么约束下。在本单元中，我们将学习上下文如何决定输出，为任务选择什么上下文，以及太多或错误的上下文会造成多大的伤害。
为什么环境如此具有决定性？
除了您提供的文本之外，模型无法了解您的情况。他不知道你的公司名称、你的客户的历史、你的项目的目标，或者上周谈论的内容。如果您不提供此信息，模型将使用“平均”假设进行编写，而平均值很少适合您的独特情况。提供上下文将模型从“平均”转变为“只适合您”。
例如，当您说“向客户写折扣优惠”时，模型会生成一般文本。但如果你给出这样的背景：“这位客户已经与我们合作了 3 年，他去年的营业额为 40 万土耳其里拉，他说他从竞争对手公司收到了更便宜的报价，我们希望保持他的忠诚度”，报价的语气、理由和折扣逻辑将完全合适。
任务需要什么上下文？
没有必要为每个任务编写所有内容；你的工作是为该任务选择必要且充分的背景。这四个问题可以让你的工作变得更轻松：
- 为了谁？买家是谁，他的知识水平，他与你的关系。
- 从哪里？此输出的目的是；说服、信息还是决定？
- 和什么过去？之前谈了什么，发生了什么，做了什么决定？
- 有什么限制？预算、期限、品牌规则、法律框架。
逐步设置上下文
- 用一句话写下任务。
- 回答以上四个问题；在要点中添加答案。
- 消除不必要或矛盾的条款（过多的上下文也是有害的）。
- 如果存在机密/个人数据，请将其屏蔽（我们将在第 11 单元中返回此主题）。
- 在视觉上将上下文与任务分开（标题、行或“上下文：”标签）。
上下文很少/上下文足够/上下文很多
状态
结论
背景很少
结果很笼统，不准确，“适合所有人但不适合任何人”
足够的背景
针对具体情况、切题、可直接使用的输出
过多/矛盾的上下文
该模型混淆了重要与不重要，模糊了主要需求
与普遍的看法相反，太多的背景是不好的。如果你写了十段背景并用一个模糊的句子说出你想要的内容，模型就会淹没在一堆细节中而错过主要任务。良好的背景是选择相关的内容；不把所有东西都洒出来。
四个可复制模板
1）上下文块骨架：
上下文：- 对于谁：[接收者、级别、关系]- 目的：[我们想要实现什么]- 历史：[相关的先前事件/决定]- 边界：[预算、持续时间、规则] 任务：[单个清晰动词 + 输出]
2）客户沟通：
背景：- 客户：合作 2 年，每月支出约 3 万土耳其里拉。- 问题：上次交货晚了 5 天，客户受到责备。- 目的：维持关系，重建信任。任务：写一封简短的补偿电子邮件（最多 100 个字）。约束：接受责任；不要责怪任何人。
3) 内部报告/执行摘要：
背景：- 读者：总经理，对技术细节不感兴趣，注重结果。- 目的：说服预算批准。- 背景：项目推迟 2 个月，但范围扩大。任务：写 1 段执行摘要 + 3 项行动清单。
4）连续上下文（长对话的开始）：
将您未来的所有答案建立在以下背景之上： - 我们的公司：[域名、规模] - 品牌声音：[具体形容词] - 禁止：[竞争对手名称、炒作、承诺] 确认这一点并在每个答案中遵循这些规则。
弱提示/强提示
弱：
对我们收到的此投诉进行回复。[投诉文本]
强：
背景：抱怨顾客4岁，忠诚；该产品有缺陷，他想要更换。我们的政策允许在 14 天内无条件换货，并允许客户在第 6 天进行无条件换货。宗旨：快速解决和信任。任务：写一封回复给客户。最多 90 个单词，在第一句中给出答案。限制：不得做出政治以外的承诺；使用指责性语言。投诉：[投诉文字]
第二个提示为模型提供了客户概况、政策、持续时间和目的；因此，答案不是“笼统的道歉”，而是正确且可行的解决方案。
三个迷你箱
案例1——房地产顾问。一位顾问正在制作广告文字，以“写得漂亮”。当我们添加“目标买家是年轻家庭，应突出该地区靠近学校，价格比市场平均水平低5%”的信息时，广告直接吸引了目标受众，每次浏览的搜索率在顾问自己的监控下有所增加。
案例 2——项目经理。当一位产品经理在每周状态电子邮件中给出“上周错过了 2 个关键交付，但有一个风险已提前关闭；读者高级管理层”的背景时，该模型的语气很平衡，既不惊慌，也不隐藏。如果没有背景，同样的任务要么过于乐观，要么过于悲观。
案例 3——人力资源。一位人力资源专业人士在打印拒绝邮件时添加了这样的语气：“该候选人在最后一轮表现强劲，未来可能会空缺另一个职位。”结果是一篇没有关门或冒犯候选人的文字；没有上下文的版本是冰冷和公式化的。
提示：使用“上下文：”和“任务：”等清晰标签将上下文与任务分开。这样，模型就不会混淆哪部分是背景，哪部分是请求。
注意：在将机密数据（真实姓名、TR ID、帐号、合同详细信息）添加到上下文之前停止。大多数时候，说“3年企业客户”和提供真实姓名一样有效。我们将在第 11 单元讨论隐私规则。
常见错误
- 零上下文。只需编写任务，等待模型了解情况即可。
- 太多的上下文。堆积十个不相关的段落并掩盖了主要要求。
- 上下文冲突。在同一个地方说“正式”和“写得真诚、幽默”。
- 将上下文与任务混淆。解释背景并没有明确说出你想要什么。
- 不假思索地添加机密数据。粘贴敏感信息而不匿名。
综上所述
- 上下文是将模型从“平均答案”转变为“专门为您提供的答案”的背景信息。
- 良好的背景可以回答四个问题：为谁、为什么、有什么历史、有什么界限。
- 太少的上下文会产生一般性的输出，足够的上下文会产生准确的输出，太多的上下文会产生分散性。
- 用清晰的标签将上下文与任务分开；选择相关的内容，不要泄露所有内容。
- 在添加机密数据之前对其进行匿名处理；大多数时候，一般定义就足够了。
应用任务
从您的工作中选择一项实际任务（电子邮件、报告或回复）。首先运行上下文无关版本。然后回答四个问题（为谁，为什么，什么历史，什么边界），添加一个“Context：”块，然后再次运行。观察两个输出之间的命中差异并检查是否有多余的上下文。
清单
- [ ] 我可以通过四个问题确定任务需要什么上下文。
- [ ] 我用清晰的标签将上下文与任务分开。
- [ ] 我避免冗余和矛盾的上下文。
- [ ] 我在添加机密数据之前将其匿名化。
- [ ] 我可以看到上下文无关和上下文无关输出之间的区别。