3.3 上下文与背景信息的提供

上下文是提示词中容易被忽视但至关重要的组成部分。充分且相关的上下文可以帮助模型更准确地理解任务需求，生成更符合预期的输出。本节将探讨如何有效地构建和提供上下文信息。

3.3.1 上下文的重要性

大语言模型虽然在训练中学习了大量知识，但它并不了解：

• 用户的具体情境和背景

• 任务的特定约束条件

• 输出的最终用途

• 行业或组织的特殊规范

上下文信息填补了这些空白，使模型能够在正确的框架内思考和生成内容。

对比示例

无上下文：

指令：帮我回复这封邮件。

邮件内容：
"您好，请问你们的产品保修期是多久？"

模型可能给出一个通用的、可能不准确的回复。

有上下文：

上下文：
- 角色：某电子产品公司的客服代表
- 产品线：笔记本电脑（保修 2 年）、配件（保修 1 年）
- 公司政策：保修期从购买日期开始计算，需保留购买凭证
- 沟通风格：专业友好，称呼客户为"客户"而非"亲"

指令：帮我回复这封邮件。

邮件内容：
"您好，请问你们的产品保修期是多久？"

模型可以生成准确、专业且符合公司规范的回复。

3.3.2 上下文的类型

1. 背景知识

与任务相关的事实信息、专业知识或规则说明。

背景知识：
在中国法律框架下，劳动合同应当具备以下条款：
（一）用人单位的名称、住所和法定代表人或者主要负责人
（二）劳动者的姓名、住址和居民身份证或者其他有效身份证件号码
（三）劳动合同期限
（四）工作内容和工作地点
...

任务：检查这份劳动合同是否符合法律要求。

2. 场景描述

说明任务发生的具体情境或环境。

场景描述：
这是一家初创公司的首次产品发布会，面对 100 位潜在投资人和合作伙伴。
公司主营业务是企业级 SaaS 解决方案，成立 2 年，已有 50 个付费客户。
CEO 将亲自演讲，时间约 15 分钟。

任务：为这场发布会撰写演讲稿大纲。

3. 目标受众

描述输出内容的目标读者或用户。

目标受众：
- 年龄：45-60 岁
- 技术背景：基本无编程或 IT 经验
- 需求：了解如何使用智能手机的基本功能
- 阅读习惯：偏好简短、步骤清晰的说明

任务：编写一份智能手机使用指南。

4. 约束条件

限制模型输出的规则或边界。

约束条件：
- 所有数据须来源于 2023 年之后的公开报告
- 不得使用任何未经验证的第三方估算
- 涉及竞争对手时使用中性表述
- 符合公司品牌指南要求

任务：撰写行业分析报告。

5. 参考材料

可供模型参考的文档、数据或示例。

参考材料：
以下是公司过去三封成功的销售邮件模板：

[模板 1]
主题：...
正文：...

[模板 2]
主题：...
正文：...

任务：参考这些模板的风格，为新产品撰写一封销售邮件。

3.3.3 上下文组织的最佳实践

使用清晰的分隔和标签

## 背景信息

[背景内容]

## 任务要求

[具体任务]

## 待处理内容

[输入数据]

或使用 XML 标签（特别适合 Claude）：

<context>
公司背景和业务介绍...
</context>

<constraints>
必须遵守的规则...
</constraints>

<task>
需要完成的任务...
</task>

信息分层组织

先提供最重要、最相关的信息，次要信息放在后面：

核心上下文：[最关键的信息，必须理解]

补充上下文：[有帮助但非必需的信息]

参考资料：[可选参考的材料]

简洁不冗余

只包含必要信息，避免信息过载：

❌ 冗余上下文：
我是一家公司的员工。这家公司成立于 2010 年，总部在北京，
有约 500 名员工，业务覆盖全国主要城市。我们的 CEO 是张三，
他是北大毕业的，之前在某大公司工作过。公司去年收入约
2 亿元人民币...（继续大段无关信息）

任务：帮我写一封请假邮件。

✓ 精炼上下文：
角色：公司员工
请假原因：家中有事需处理
请假时间：明天（周三）一天
请假审批人：直属经理李四

任务：写一封简短正式的请假邮件。

3.3.4 上下文来源策略

手动编写

适用于固定场景的系统提示词，内容来自人工整理的知识。

优点：质量可控、针对性强 缺点：维护成本高、更新不及时

检索增强

从知识库或文档中动态检索相关信息注入上下文。

[系统自动检索的相关文档片段]

---
基于以上参考资料，请回答用户问题：
{用户问题}

优点：信息时效性好、覆盖面广 缺点：依赖检索质量、可能引入噪音

用户输入

从用户交互中收集必要的上下文信息。

在处理用户请求之前，模型需要询问：
1. 请问您的具体使用场景是什么？
2. 您希望输出的大致长度和格式是怎样的？
3. 是否有任何特殊要求或限制？

优点：高度个性化 缺点：增加用户负担

3.3.5 上下文的动态管理

在多轮对话或复杂任务中，上下文需要动态管理。

关键信息持久化

某些重要信息应在整个会话中保持：

[固定上下文 - 始终存在]
用户偏好：简洁回答，技术导向

[动态上下文 - 根据对话更新]
当前讨论话题：数据库索引优化
用户的数据库类型：MySQL 8.0
表数据量：约 1000 万行

上下文刷新策略

当对话主题发生重大变化时，适当刷新上下文：

检测到话题从"产品功能咨询"转变为"投诉处理"，
切换相应的上下文模板和回复策略。

3.3.6 常见问题与解决方案

问题 1：上下文太长

症状：超出上下文窗口限制，或模型注意力稀释

解决方案：

• 压缩和摘要：提炼核心信息

• 分块处理：将任务拆分为多个步骤

• 优先级排序：保留最相关的信息

问题 2：上下文冲突

症状：上下文中包含相互矛盾的信息

解决方案：

• 明确优先级：指定冲突时应遵循的规则

• 清理数据：确保上下文来源一致

• 显式处理：要求模型识别并说明冲突

如果提供的参考资料与背景规则有冲突，请优先遵循背景规则，
并在回复中说明发现的冲突点。

问题 3：上下文被忽略

症状：模型输出未反映提供的上下文

解决方案：

• 强调关键信息：使用加粗或单独提及

• 调整位置：将重要信息放在开头或结尾

• 明确引用要求：指示模型必须使用特定信息

重要提示：回答必须引用以下产品规格数据，不得使用其他来源的参数。

思考

1. 提供过多的背景信息是否反而会降低输出质量？你认为“信息量”和“信噪比”之间的最佳平衡点在哪里？

2. 如果背景信息本身包含错误，模型是会纠正还是会忠实地使用这些错误信息？这对你的提示词设计意味着什么？