如何通过利用上下文工程显著提高-LLM
如何通过利用上下文工程显著提高 LLM
原文：
towardsdatascience.com/how-to-significantly-enhance-llms-by-leveraging-context-engineering-2/
在这篇文章中，我将讨论上下文工程的科学，以及你如何应用上下文工程技巧来提高你的 LLM 的性能。
在这篇文章中，我讨论了上下文工程：为你的 LLM 提供正确上下文的科学。正确利用上下文工程可以显著提高你的 LLM 的性能。图片由 ChatGPT 提供。
你还可以阅读我的关于如何使用 ARC AGI 3 基准测试 LLM和使用多模态 LLM 进行文档问答的文章。
目录
-
定义
-
动机
-
API 与控制台
-
上下文工程技巧
-
零样本提示
-
少样本提示
-
RAG
-
工具（MCP）)
-
-
需要考虑的主题
-
上下文长度的利用
-
上下文旋转
-
-
结论
在这里阅读这篇文章的第二部分。
定义
在我开始之前，定义上下文工程这个术语非常重要。上下文工程本质上是一门决定向你的 LLM 提供什么内容的科学。例如，这可以是：
-
系统提示，告诉 LLM 如何行动
-
使用 RAG 向量搜索获取文档数据
-
少样本示例
-
工具
这之前最接近的描述是术语提示工程。然而，提示工程是一个不那么描述性的术语，因为它只意味着改变你提供给 LLM 的系统提示。为了从你的 LLM 中获得最佳性能，你必须考虑你向其提供的所有上下文，而不仅仅是系统提示。
动机
我写这篇文章的最初动机来源于阅读安德烈·卡帕西（Andrej Karpathy）的这条推文。
+1 对于“上下文工程”优于“提示工程”。
人们将提示与在日常使用中给 LLM 的简短任务描述联系起来。在每一个工业级 LLM 应用中，上下文工程是填充上下文窗口的精细艺术和科学…
t.co/Ne65F6vFcf— 安德烈·卡帕西 (@karpathy) 2025 年 6 月 25 日
我非常赞同安德烈在这次推文中提出的观点。当与大型语言模型（LLMs）一起工作时，提示工程（prompt engineering）无疑是一门重要的科学。然而，提示工程并不能涵盖我们输入到 LLMs 中的所有内容。除了你写的系统提示外，你还必须考虑以下元素：
-
你应该将哪些数据插入到你的提示中
-
你如何获取这些数据
-
如何只向 LLM 提供相关信息
-
等。
我将在本文中讨论所有这些点。
API 与控制台使用对比
需要明确的一个重要区别是，你是通过 API（用代码调用）使用 LLMs，还是通过控制台（例如，通过ChatGPT 网站或应用程序）使用。当通过控制台与 LLMs 一起工作时，上下文工程（context engineering）确实非常重要；然而，本文的重点将放在 API 使用上。这样做的原因是，当使用 API 时，你有更多选项来动态地改变你提供给 LLMs 的上下文。例如，你可以进行 RAG（Retrieval-Augmented Generation），首先执行向量搜索，然后只向 LLM 提供最重要的信息片段，而不是整个数据库。
当通过控制台与 LLMs 交互时，这些动态变化并不以相同的方式出现；因此，我将专注于通过 API 使用 LLMs。
上下文工程技术
零样本提示
零样本提示（zero-shot prompting）是上下文工程的基线。执行一个零样本任务意味着 LLM 正在执行一个它以前没有见过的任务。你实际上只提供了任务描述作为 LLM 的上下文。例如，向 LLM 提供一个长文本，并要求它根据某些类别的定义将文本分类为 A 类或 B 类。你提供给 LLM 的上下文（提示）可能看起来像这样：
You are an expert text classifier, and tasked with classifying texts into
class A or class B.
- Class A: The text contains a positive sentiment
- Class B: The next contains a negative sentiment
Classify the text: {text}
根据任务的不同，这可能会非常有效。LLMs 是通才，能够执行大多数简单的基于文本的任务。将文本分类为两个类别之一通常是一个简单的任务，因此零样本提示通常可以很好地工作。
少量样本提示
这张信息图表突出了如何执行少量样本提示：
这张信息图表突出了如何执行少量样本提示（few-shot prompting）以增强 LLMs 的性能。图片由 ChatGPT 提供。
零样本提示的后续是少样本提示。在少样本提示中，你向 LLM 提供与上面类似的提示，但你还提供它将执行的任务的示例。这个额外的上下文将帮助 LLM 提高执行任务的能力。在上述提示的基础上，一个少样本提示可能看起来像这样：
You are an expert text classifier, and tasked with classifying texts into
class A or class B.
- Class A: The text contains a positive sentiment
- Class B: The next contains a negative sentiment
<example>
{text 1} -> Class A
</example>
<example>
{text 2} -> class B
</example>
Classify the text: {text}
你可以看到我已经向模型提供了一些用
少样本提示（Few-shot prompting）效果良好，因为你在向模型提供你要求它执行的任务的示例。这通常会增加性能。
你可以想象这同样适用于人类。如果你向一个人分配一个他们从未做过的任务，仅仅通过描述任务，他们可能表现不错（当然，这取决于任务的难度）。然而，如果你还向这个人提供示例，他们的表现通常会提高。
总体来说，我认为将 LLM 提示想象成我要求一个人执行任务是有用的。想象一下，如果你不是提示 LLM，而是简单地给一个人提供文本，然后你自己问自己问题：
给定这个提示，没有其他上下文，人类能否完成这个任务？
如果答案是“否”，你应该努力澄清和改进你的提示。
我还想提到动态少样本提示，考虑到这是我取得很多成功的技术。传统上，在少样本提示中，你有一组固定的示例，你将它们放入每个提示中。然而，你通常可以通过动态少样本提示实现更高的性能。
动态少样本提示意味着在为任务创建提示时动态选择少样本示例。例如，如果你被要求将文本分类为 A 和 B 类，而你已经有了一个包含 200 个文本及其对应标签的列表。然后你可以对新文本和已有的示例文本进行相似度搜索。继续进行，你可以测量文本之间的向量相似度，并只选择最相似的文本（从 200 个文本中）作为提示的上下文。这样，你向模型提供了更多相关的示例，以展示如何执行任务。
RAG
检索增强生成是提高 LLM 知识的一种知名技术。假设你已经有了一个包含数千份文档的数据库。现在你收到一个用户的问题，并且需要在数据库中的知识基础上回答它。
不幸的是，您不能将整个数据库输入到 LLM 中。尽管我们有像Llama 4 Scout 具有 1000 万个上下文长度窗口的 LLM，但数据库通常要大得多。因此，您必须找到数据库中最相关的信息来输入您的 LLM。RAG 与此类似，类似于动态少样本提示：
-
执行向量搜索
-
找到与用户问题最相似的文档（假设最相似的文档是最相关的）
-
要求 LLM 在给定最相似的文档的情况下回答问题
通过执行 RAG，您仅通过向 LLM 提供执行其任务所需的最相关数据来进行上下文工程。为了提高 LLM 的性能，您可以通过改进您的 RAG 搜索来优化上下文工程。例如，这可以通过改进搜索，仅找到最相关的文档来实现。
您可以在我的关于为个人数据开发 RAG 系统的文章中了解更多关于 RAG 的信息：
工具（MCP）
您还可以向 LLM 提供可调用的工具，这是上下文工程的重要组成部分，尤其是在我们看到 AI 代理兴起的时代。今天的工具调用通常是通过模型上下文协议（MCP），由 Anthropic 提出的一个概念来完成的。
AI 代理是能够调用工具并执行操作的 LLM。一个例子可以是天气代理。如果您向无法访问工具的 LLM 询问纽约的天气，它将无法提供准确的回答。原因很自然，因为需要实时获取有关天气的信息。为此，您可以为 LLM 提供如下工具：
@tool
def get_weather(city):
# code to retrieve the current weather for a city
return weather
如果您允许 LLM 访问此工具并询问天气，它就可以搜索城市的天气并提供准确的回答。
为 LLM 提供工具非常重要，因为它显著增强了 LLM 的能力。其他工具的例子包括：
-
在互联网上搜索
-
一个计算器
-
通过 Twitter API 进行搜索
需要考虑的主题
在本节中，我简要说明在创建要输入 LLM 的上下文时应考虑的事项
利用上下文长度
LLM 的上下文长度是一个重要的考虑因素。截至 2025 年 7 月，您可以为大多数前沿模型 LLM 提供超过 100,000 个输入标记。这为您提供了很多利用上下文的方式。您必须考虑以下权衡：
-
在提示中包含大量信息，从而可能导致一些信息在上下文中丢失
-
在提示中遗漏一些重要信息，从而可能导致 LLM 没有执行特定任务所需的上下文
通常，确定平衡的唯一方法是通过测试你的 LLM 性能。例如，在分类任务中，你可以检查给定不同提示的准确率。
如果我发现上下文对于 LLM 来说太长，以至于无法有效工作，我有时会将任务分成几个提示。例如，一个提示总结文本，另一个提示对文本摘要进行分类。这可以帮助 LLM 有效地利用上下文，从而提高性能。
此外，向模型提供过多的上下文可能带来显著的负面影响，正如我在下一节中描述的：
上下文退化
上周，我读了一篇关于上下文退化的有趣文章。文章讨论了增加上下文长度会降低大型语言模型（LLM）的性能，尽管任务难度并没有增加。这暗示了：
向 LLM 提供与其无关的信息，将降低其成功完成任务的能力，即使任务难度没有增加
这里要强调的是，你应该只为你的 LLM 提供相关信息。提供其他信息会降低 LLM 的性能（即，性能并非对输入长度中立）
结论
在这篇文章中，我讨论了上下文工程的主题，即向 LLM 提供适当上下文以有效执行其任务的过程。你可以利用许多技术来填充上下文，例如少样本提示、RAG 和工具。这些都是你可以用来显著提高 LLM 有效执行任务能力的强大技术。此外，你还必须考虑这样一个事实，即向 LLM 提供过多的上下文也有不利的一面。增加输入标记的数量会降低性能，正如你可以在关于上下文退化的文章中读到的那样。
此外，查看这篇文章的第二部分。
👉 我的免费电子书和网络研讨会：
👉 在社交媒体上找到我：
📩 订阅我的通讯
🧑💻 联系我
✍️ Medium
浙公网安备 33010602011771号