Elasticsearch：上下文工程 vs. 提示词工程

作者：来自 Elastic Tomás Murúa

了解上下文工程和提示词工程的区别，以及为什么同时掌握两者对于构建生产级 AI agents 和 RAG 系统至关重要。

Elasticsearch 与行业领先的 Gen AI 工具和提供商有原生集成。查看我们关于超越 RAG 基础知识的网络研讨会，或使用 Elastic 向量数据库构建生产级应用的内容。

为了为你的用例构建最佳搜索解决方案，现在可以开始免费云试用或在本地机器上尝试 Elastic。

在 Web 开发的早期，网页设计是一个涵盖从视觉美学到用户工作流程的单一学科。随着行业的发展，它分裂成两个不同领域：用户界面 (UI) 和用户体验 (UX)。它们仍然相互关联，但每个都需要不同的专业知识和工具。

我们在 AI 中也看到类似的分化。自 2022 年 11 月 ChatGPT 推出以来，行业一直专注于优化提示词以改善大型语言模型 (LLM) 的交互。随着我们构建更复杂的 AI 系统，尤其是需要访问外部知识的 agents 和 Model Context Protocol (MCP) 工具，出现了两个不同的学科：提示词工程 和上下文工程。虽然它们协同工作，但解决的是根本不同的挑战。

提示词工程关注你如何与模型交流。上下文工程关注模型在生成响应时可以访问哪些信息。

什么是提示词工程？

提示词是用于指导生成式 AI 模型输出的输入。提示词可以由文本、图像、声音或其他媒体组成。

提示词工程是不断优化你与模型交流方式以获得更好结果的迭代过程。它关注在单次交互中你使用的词语、结构和技巧。

以下是一些提示词工程技术示例：
来源: https://arxiv.org/pdf/2406.06608

常见技术包括少量示例提示（提供示例）、链式思维推理（要求模型展示其推理过程）和角色分配（赋予模型一个角色）。这些技术应对诸如歧义的挑战，即一个问题可能有多种解读，模型必须猜测用户意图的解读。

提示词工程的一个关键挑战是找到 Anthropic 所称的 "指令的正确高度"。在一个极端，工程师在提示中硬编码复杂且脆弱的逻辑以预见每种场景，这会导致系统脆弱且维护成本高。在另一个极端，工程师提供模糊指导，无法给模型具体信号，或错误假设共享上下文。最优高度在两者之间取得平衡：足够具体以指导行为，同时足够灵活以让模型应用良好判断。

提示词工程通常在单轮交互层面运作，优化你如何表述一个查询以获得最佳响应。这在简单交互中效果很好，但当任务需要外部知识、持久状态或多步推理时，会达到其极限。

欲深入了解提示词工程技术，请参考《The Prompt Report: 提示词技术系统调查》。

什么是上下文工程？

上下文工程是在 LLM 推理过程中策划和维护最优 token 集合的更广泛学科。提示词工程问的是，"我应该如何表述这个？ "，而上下文工程问的是，"模型现在需要访问哪些信息？"

正如 12-Factor Agents 框架所解释的，LLM 是无状态函数，将输入转化为输出。在任意时刻，你对 LLM 的输入本质上是，"这是到目前为止发生的情况。下一步是什么？"每次交互都成为上下文：

你给模型的提示和指令。
通过检索增强生成（RAG）获取的文档或外部数据。
过去的状态、工具调用或其他历史。
关于结构化数据输出格式的指令。

这个区分很重要，因为现代 AI agents 并不是单轮操作。一个循环运行的 agent 会生成一个不断扩展的信息宇宙：工具输出、检索文档、对话历史、中间推理。上下文工程就是决定在任何给定时刻，来自这个信息宇宙的哪些内容进入模型有限工作内存的实践。

关于上下文工程的组件和最佳实践的全面探讨，请参考《什么是上下文工程？》和《你知道，为了上下文》。

主要区别：提示词工程 vs. 上下文工程

维度	提示词工程	上下文工程
核心问题	"我应该如何表述这个？"	"模型需要知道什么？"
范围	单个查询	系统级信息流
失败模式	歧义：表述不当的指令导致误解	检索问题：错误文档、过时信息或上下文溢出
工具	描述期望输出	选择和排序工具
调试方法	语言精确度：优化措辞，添加示例	数据架构：调整检索、修剪上下文、排序工具

单轮 vs. 多轮

提示词工程优化单次交互。上下文工程考虑序列：前几轮建立了什么？工具输出携带了哪些信息？三步之后应该保留什么？随着任务从简单问答转向多步 agent 工作流，上下文工程成为主要挑战。

上下文窗口管理

上下文工程管理有限资源，有三种失败模式：

信息过少导致幻觉或错误响应。当 LLM 缺乏足够上下文时，无法确定语义上下文来生成准确响应。
信息过多导致上下文溢出。它会压垮 LLM 的注意力范围，降低整个上下文窗口的相关性，使模型难以判断哪些部分最重要。
分散或冲突信息会让模型混淆。更大的上下文窗口增加了出现冲突或无关信息的机会，从而干扰 LLM 回答。

关键区别：提示词工程将上下文窗口视为既定。上下文工程主动策划上下文窗口。

工具编排

提示词工程可以请求使用工具并描述工具应做什么。上下文工程决定可用哪些工具、传递给工具哪些信息，以及它们的输出如何流回上下文。

最常见的失败模式之一是工具集膨胀且功能重叠。如果人工工程师无法明确指出在特定情况下应使用哪个工具，则不能期望 AI agent 做得更好。上下文工程应用明确原则：策划最小可行工具集。每个工具应独立、自我容错且目的明确。工具还应高效使用 token，仅返回必要信息，而不是提供所有可用内容。

即时上下文 vs. 预检索

传统 RAG 系统会预处理并提前检索所有可能相关数据，在推理前将其加载到提示中。上下文工程越来越倾向即时策略，例如 Anthropic 的 Agent Skills，agent 会发现并动态加载到上下文中。

Agent 不会一次性加载所有内容，而是保持轻量引用（文件路径、存储查询、文档 ID），并在运行时使用工具动态加载数据。这类似人类认知：我们不会记住整本书，而是维护文件夹和书签等系统按需检索信息。

权衡在于速度与精度。预检索速度更快，但存在上下文溢出风险。即时检索速度较慢，但保持上下文窗口集中。最有效的 agents 通常采用混合方法：提前检索必要的基础上下文，同时在需要时允许进一步探索。

实际示例：图书推荐 agent

为了演示提示词工程和上下文工程如何协同工作，我们使用 Elastic Agent Builder 构建了一个图书推荐 agent，数据集包含在 Elasticsearch 中索引的 103,063 本书。

设置：

索引：books-dataset，包含 103,063 条文档
字段：Title、Authors、Description、Category、Publisher、Price、Published Date
工具：Agent Builder 预设工具
模型：Elastic Managed LLM

映射：

复制代码

{
  "mappings": {
    "properties": {
      "@timestamp": { "type": "date" },
      "Authors": { "type": "text" },
      "Category": { "type": "text" },
      "Description": { "type": "text" },
      "Price Starting With ($)": { "type": "double" },
      "Published Date": { "type": "date", "format": "iso8601" },
      "Publisher": { "type": "text" },
      "Title": { "type": "text" }
    }
 }

我们测试了三个场景，以展示基于提示词质量和上下文管理的不同结果。