wsl-docs

长上下文提示实践

发布日期：2026-01-06原文链接：https://www.anthropic.com/news/prompting-long-context19分钟阅读

摘要

1) 一句话总结 本文通过定量案例研究表明，在提示词中要求模型先提取参考引用（使用草稿本）并提供与上下文相关的问答示例，可以显著提升 Claude 在长上下文（高达 100K Token）中的信息召回准确率。

2) 关键要点

  • 测试基准：实验使用超出 Claude 训练数据截止日期的政府文档，通过“随机拼贴”方法构建了包含 75,000 和 90,000 个 Token 的多项选择问答数据集。
  • 主要测试模型：主要使用 Claude Instant 1.2 进行评估（因其速度快且更容易观察到提示词带来的性能提升），同时也验证了 Claude 2 的表现。
  • 核心技术一（提取引用）：使用 <scratchpad>（草稿本）让模型在回答前提取相关段落引用，在所有正面比较中均提升了准确性，且延迟代价极小。
  • 核心技术二（动态示例）：在提示词中提供从上下文中动态提取的、已正确回答的问题示例（测试了 2 个和 5 个），能有效提升 70K 和 95K 长度下的性能，且示例越多效果越好。
  • 无效策略：提供与文档无关的通用常识性问答示例对提升召回性能没有帮助。
  • Claude 2 性能提升：采用最佳提示词策略后，Claude 2 的准确率从 0.939 提升至 0.961，相当于错误率降低了 36%。
  • 指令位置优化：强烈建议将核心指令放置在提示词的最末尾，以确保模型对指令具有最高的召回率。
  • 资源开源：本次实验的完全可复现代码已发布在全新的 Anthropic Cookbook 中。

3) 风险与不足（基于原文明确提及）

  • 末尾位置性能下降风险：使用草稿本和示例虽然大幅提升了文档开头和中间的召回率，但可能会导致文档结尾部分的性能下降，原因是示例增加了末尾相关信息与最终问题之间的距离。
  • 计数能力缺陷：由于 Claude 基于 Token 而非单词处理信息，模型在处理“计数”类问题（如统计单词数、表格数量或制成品种类）时表现不佳且容易出错。
  • 自动生成评估题的偏差：使用 Claude 生成测试题时存在多个陷阱，包括：生成无需文档即可回答的问题、正确答案比错误答案更详细（留下线索）、引用指代不明（如模糊使用“本文档”），以及问题过于明确直接暴露答案。
  • 数据集噪声：在自动生成问答对的过程中，Claude 预先指定的“正确”答案有时实际上是错误的，这构成了评估实验中的一个噪声来源。

正文

Claude 拥有 100,000 个 Token 的长上下文窗口，这使得该模型能够处理数百页的技术文档，甚至是一整本书。随着我们不断扩展 Claude API，我们发现用户对如何最大化 Claude 潜力的提示词指南的需求日益增加。今天，我们很高兴分享一项定量案例研究，探讨两种可以提高 Claude 在长上下文中召回率的技术：

  • 在回答之前提取与问题相关的参考引用

  • 在提示词中补充关于文档其他部分已正确回答的问题示例

让我们深入了解具体细节。

测试长上下文召回率：多项选择问答

我们此次实验的目标是评估能够最大化 Claude 从长文档中正确召回特定信息概率的技术。

作为我们测试的基础数据源，我们使用了一份每日发布、公开可用的政府文档，其中包含许多不同部门的会议记录和活动。我们选择了 7 月 13 日的一份文档，该日期在 Claude 的训练数据截止日期之后。这最大限度地降低了 Claude 已经知道该文档中信息的可能性。为了生成问答（Q&A）对数据集，我们使用了一种称为“随机拼贴（randomized collage）”的方法。我们将文档分成多个部分，并使用 Claude 为每个部分生成五个多项选择题，每个问题包含三个错误答案和一个正确答案。然后，我们将这些部分的随机组合重新组装成长文档，以便我们可以将它们传递给 Claude 并测试其对文档内容的召回率。

提示 Claude 生成多项选择题

让 Claude 为你编写评估（evals）是一个强大的工具，也是我们作为提示词工程团队经常使用的方法。然而，要让 Claude 写出难度适中的问题，需要精心设计提示词。以下是我们在设计有效测试套件的过程中克服的一些挑战：

  • Claude 可能会提出一些它无需参考任何文档就能脱口而出回答的问题，例如“交通部是做什么的？”

  • Claude 可能会包含一些即使在短上下文情况下也很难正确回答的问题。例如，因为 Claude 是以 Token 而不是单词（words）来看待世界的，像“这段话中有多少个单词？”这样的问题往往会给 Claude 带来麻烦。

  • Claude 可能会在答案中留下无意的线索，使得正确答案很容易被猜到。值得注意的是，我们发现它的默认做法是让正确答案比错误答案详细得多。

  • Claude 可能会引用“本文档”或“本段落”，而没有具体说明是指哪一段。这是一个问题，因为当我们将多个文档拼接在一起形成长上下文时，Claude 无法知道问题问的是哪个文档。

  • 还有一种风险是做得太过火，让问题变得过于明确以至于包含了答案。例如，“内政部 2023 年 7 月 2 日关于渔业额外季内行动的通知的发布日期是什么？”将是一个无效的问题。

为了帮助避开这些陷阱，我们使用了一个提示词模板，其中包含两个会议片段示例以及手写的问题，作为少样本（few-shot）问题编写示例，此外还有一些编写指南，以让 Claude 具体说明段落的细节。该模板以及本实验中使用的所有其他提示词可在此处获取。

评估

在本次评估中，我们主要关注较小的 Claude Instant 模型（1.2 版本），而不是 Claude 2 模型。这有几个原因。首先，Claude 2 在阅读非常长的文档后已经非常擅长召回信息。Claude Instant 需要更多帮助，这使得我们很容易看出提示词的改变何时能提高性能。此外，Claude Instant 速度非常快，你可以使用我们分享的 notebook 自行复现这些评估。当仅提供 Claude 用于编写问题的确切段落时，Claude Instant 能够在大约 90% 的情况下回答自己生成的问题。我们丢弃了它回答错误的 10% 的问题——因为 Claude 即使在短上下文情况下也会答错，它们太难了，无法用于测试长上下文。1 我们还测试了当给定一个不包含问题源材料的随机部分时 Claude 的召回率。理论上，在有三个错误答案的情况下，Claude 猜对正确答案的概率应该只有 25%。在实践中，它猜对了 34%；高于随机概率，但也没有高出太多。Claude 可能有时会根据其常识或答案中的微妙线索直觉地猜出正确答案。为了用较短的片段构建长文档，我们通过将随机的段落组合拼接在一起，直到达到所需的 Token 数量，从而为每个问题人为生成了一个新的长上下文。我们在包含大约 75,000 和 90,000 个 Token 的拼接文档上测试了 Claude。这种拼凑的上下文结构正是 Claude 在问题中引用“本文档”或“本段落”等模糊短语会引发问题的原因。当上下文中存在十几个不同的通知，而“本通知”可能指代其中任何一个时，像“本通知的发布日期是什么？”这样的问题就变得无法回答了。这就是为什么我们的问题生成提示词中包含明确要求 Claude 具体说明问题所指段落的语言——例如，“关于渔业额外季内行动的通知的发布日期是什么？”在生成长文档（拼贴）后，我们使用四种不同的提示词策略测试了 Claude 的召回率：

  • 基础（Base）——直接让 Claude 回答

  • 非政府示例（Nongov examples）——给 Claude 提供两个固定的、已正确回答的常识性多项选择题示例，这些示例与政府文档无关 2

  • 两个示例（Two examples）——给 Claude 提供两个已正确回答的多项选择题示例，这些示例是从 Claude 生成的关于上下文中其他片段的问题集中随机动态选择的

  • 五个示例（Five examples）——与策略 #3 相同，但提供五个示例

对于上述四种策略中的每一种，我们还测试了使用和不使用 <scratchpad>（草稿本）的情况，在 <scratchpad> 中我们指示 Claude 提取相关的引用。此外，我们还测试了这些策略在包含答案的段落位于输入开头、结尾或中间时的情况。最后，为了了解上下文长度对结果的影响，我们测试了 70K 和 95K Token 的文档。我们在上述测试中使用了 Claude Instant 1.2。我们还展示了 Claude 2 在基线策略以及在 Claude Instant 1.2 中表现最好的策略上的结果。

结果

关于实验的一些注意事项：

  • 虽然使用草稿本和示例大幅提高了文档开头和中间部分的性能，但结尾部分的性能可能会下降。这可能是因为在提示词中添加示例增加了文档最末尾（相关信息所在位置）与 Claude 需要回答问题时的距离。这可能只是一个小问题，因为源文档中只有一小部分数据位于最末尾。然而，这确实强调了将指令放在提示词末尾的重要性，因为我们希望 Claude 对指令的召回率尽可能高。

  • Claude 2 通过提示词从 0.939 提升到 0.961，在绝对数值上可能看起来很小，但这反映了错误率降低了 36%。

在编写长上下文问答提示词时，你可以借鉴以下经验：

  • 使用多个示例和草稿本，以在两种上下文长度上获得最佳性能。

  • 在所有正面比较中，将相关引用提取到草稿本中都是有帮助的。这会带来微小的延迟代价，但能提高准确性。在 Claude Instant 的情况下，延迟已经非常低，因此这不应成为问题。

  • 上下文示例对 70K 和 95K 都有帮助，而且示例越多越好。

  • 关于常识/外部知识的通用示例似乎对性能没有帮助。

对于 Claude Instant，性能与相关段落到问题及提示词末尾的距离之间似乎存在单调的反比关系，而 Claude 2 在 95K 上的性能在中间位置出现了小幅下降。3

隆重推出全新的 Anthropic Cookbook

本次实验的完全可复现代码已在全新的 Anthropic Cookbook 中上线。这个不断丰富的资源库目前还包含另外两个配方（recipes）：

  • 一个搜索和检索演示，展示了用于搜索维基百科的工具使用流程。

  • 关于通过 Anthropic API 实现模拟 PDF 上传功能的指南。

我们期待在未来扩展 Anthropic Cookbook 以及我们的其他提示词工程资源，我们希望它们能激发你的宏大构想，去探索用 Claude 可以构建什么。如果你还没有获得 Claude API 的访问权限，请注册表达你的意向。

脚注

1 Claude 答错的问题中一个常见的主题是计数，例如“通知中说明的担保贷款表格通用表格包中每种表格的每个受访者估计回复数量是多少？”以及“在 Getinge Group Logistics Americas LLC 设施的生产活动通知中列出了多少种拟议的制成品？”值得注意的是，在其中一些问题上，Claude 预先指定的“正确”答案（在它生成问答对时）实际上并不正确。这是本实验中的一个噪声来源。

2 这些问题是：1. 美国第一任总统是谁？A. 托马斯·杰斐逊，B. 乔治·华盛顿，C. 亚伯拉罕·林肯，D. 约翰·亚当斯；2. 水的沸点是多少华氏度？A. 200，B. 100，C. 287，D. 212。

3 最近的一篇论文发现在类似任务中，性能与在上下文中的位置之间存在 U 型关系。对于不同结果的一个可能解释是，该论文中的示例平均长度为 15K 个 Token（附录 F），而这里的长度为 70K/95K。

相关文档

关联主题

关系图谱

反向链接