你知道，关于上下文 — 第二部分：Agentic AI 和对上下文工程的需求

原创已于 2025-11-19 09:56:27 修改 · 772 阅读

8 ·

CC 4.0 BY-SA版权

本文为博主原创文章，未经博主允许不得转载。

文章标签：

#人工智能 #elasticsearch #大数据 #搜索引擎 #全文检索 #ai #数据库

于 2025-11-19 09:54:59 首次发布

Elastic 同时被 3 个专栏收录

2169 篇文章

订阅专栏

Elasticsearch

1452 篇文章

订阅专栏

663 篇文章

订阅专栏

作者：来自 Elastic Woody Walton

了解 LLMs 向 agentic AI 演进如何增加对上下文工程的需求，以解决 RAG 上下文限制和内存管理。系列文章 “Elasticsearch：你知道，为了上下文 —— 混合搜索和上下文工程的演变”

Agent Builder 现在作为技术预览版提供。通过 Elastic Cloud Trial 开始使用，并在此处查看 Agent Builder 的文档。

在了解了（相当广泛的） LLMs 如何改变信息检索底层流程的背景之后，让我们看看它们如何改变我们查询数据的方式。

一种与数据交互的新方式

生成式（ genAI ）和 agentic AI 的工作方式与传统搜索不同。过去我们开始查找信息的方式是搜索（“让我去 Google 一下……”），而 gen AI 和 Agents 的启动动作通常是在聊天界面中输入自然语言。聊天界面是与 LLM 的对话，它利用语义理解将我们的问题转化为提炼后的答案，一个看似来自某个掌握各种信息的神谕般的总结性响应。真正让人信服的是 LLM 生成连贯、有思想的句子的能力，将其呈现的知识碎片串联起来 —— 即便不准确甚至完全幻觉化，它仍然显得 “有点像真的”。

我们过去习以为常的搜索栏，可以被视为我们自己作为推理 agent 时所使用的 RAG 引擎。如今，即使是互联网搜索引擎也正在将我们久经使用的 “东找西找” 的词汇搜索体验转变为 AI 驱动的概览，用结果摘要来回答查询，帮助用户避免自己点击并评估单个结果的需要。

Generative AI 与 RAG

Generative AI 尝试利用其对世界的语义理解来解析通过聊天请求表达的主观意图，然后使用其推理能力即时生成专家级回答。一次生成式 AI 交互由几个部分组成：它从用户的输入/查询开始，聊天会话中的先前对话可作为附加上下文，还有告诉 LLM 如何推理以及在构建响应时要遵循哪些步骤的指令性提示。提示词已经从简单的 “像我五岁一样解释给我听” 演变为针对如何处理请求的完整拆解。这些拆解通常包括描述 AI 的人物形象/角色、生成前推理/内部思考过程、目标标准、约束条件、输出格式、受众，以及用于展示预期结果的示例等不同部分。

除了用户的查询和系统提示之外，检索增强生成（retrieval augmented generation - RAG ）还在所谓的 “上下文窗口” 中提供额外的上下文信息。RAG 一直是架构中的关键补充；我们用它来帮助 LLM 了解其对世界语义理解中缺失的部分。

上下文窗口在你给它什么、在哪里给、以及给多少方面可能会有点挑剔。选择哪部分上下文当然非常重要，但提供的上下文的信噪比同样重要，窗口的长度也一样重要。

信息太少

在查询、提示词或上下文窗口中提供的信息太少会导致幻觉，因为 LLM 无法准确确定生成响应所需的正确语义上下文。文档分块大小的向量相似性也存在问题 —— 一个简短、简单的问题可能无法与我们向量化知识库中丰富、详细的文档在语义上对齐。已经开发了查询扩展技术，例如 Hypothetical Document Embeddings（ HyDE ），它使用 LLM 来生成比简短查询更丰富、更具表达力的假设答案。当然，这里的危险在于假设文档本身就是一种幻觉，使 LLM 更远离正确的上下文。

信息太多

就像对我们人类一样，上下文窗口中的信息过多会让 LLM 不堪重负并困惑，不知道哪些部分才是重要的。上下文溢出（或 “上下文腐烂”）会影响生成式 AI 操作的质量和性能；它会大幅影响 LLM 的 “注意力预算”（工作记忆），并在许多竞争的 token 之间稀释相关性。“上下文腐烂” 的概念还包括一个观察，即 LLM 往往存在位置偏差 —— 它们更偏好上下文窗口开头或结尾的内容，而不是中间部分的内容。

分散注意力或相互冲突的信息

上下文窗口越大，它包含多余或冲突信息的可能性就越高，而这些信息可能会分散 LLM 的注意力，使其无法选择和处理正确的上下文。从某种程度上说，这成为了 “垃圾进 / 垃圾出” 的问题：只是把一组文档结果堆进上下文窗口，会让 LLM 有大量信息要处理（甚至可能太多），并且取决于上下文是如何被选中的，更有可能让相互冲突或不相关的信息渗入其中。

Agentic AI

我告诉过你内容很多，但我们做到了 —— 我们终于在讨论 agentic AI 主题了！Agentic AI 是一种非常令人兴奋的新型 LLM 聊天界面用法，它扩展了生成式 AI（我们能叫它 “传统版” 了吗？）根据自身知识和你提供的上下文信息来综合生成响应的能力。随着生成式 AI 日趋成熟，我们意识到可以让 LLM 执行某些任务和自动化流程，最初只是一些枯燥、低风险且容易被人类检查/验证的活动。在很短的时间内，这个初始范围扩大了：一个 LLM 聊天窗口现在可以成为触发 AI agent 的火花，使其自主规划、执行、迭代评估并调整计划来实现目标。Agents 可以访问其 LLM 自身的推理能力、聊天历史和思维记忆（如果可以这么称呼的话），并且它们还有可用的特定工具来帮助实现目标。我们现在也看到了允许顶层 agent 作为多个子 agent 的协调器的架构，每个子 agent 都有自己的逻辑链、指令集、上下文和工具。

Agents 是大部分自动化工作流的入口：它们是自引导的，能够与用户聊天，然后使用“逻辑”来决定它有哪些工具可以帮助回答用户的问题。工具通常被视为相较于 agents 更加被动，并且通常只执行一种类型的任务。工具可以执行的任务类型几乎是无限的（这真的很令人兴奋！），但主要任务之一是为 agent 收集上下文信息，以便其在执行工作流时参考。

作为一项技术，agentic AI 仍处于起步阶段，容易表现出类似 LLM 版本的注意力缺陷 —— 它很容易忘记自己被要求做什么，并且经常跑去做完全不在任务范围内的事情。在“魔法”背后，LLM 的“推理”能力仍基于预测序列中下一个最可能的 token。要让推理（或有一天的通用人工智能（ AGI ））变得可靠和值得信任，我们需要能够验证它们在获得正确、最新的信息时，是否会按我们期望的方式进行推理（并且或许还能给我们一点我们自己都没想到的额外内容）。为了实现这一点，agentic 架构需要具备清晰沟通的能力（协议）、遵循我们给出的工作流和约束（护栏）、记住任务进度（状态）、管理可用的记忆空间，以及验证它们的响应是否准确并符合任务标准。

用我能理解的语言与我交流

如同许多新技术领域一样（在 LLM 世界中更是如此），一开始 agent 与工具之间的通信方式有不少种，但它们很快就收敛到 Model Context Protocol（ MCP ）作为事实标准。Model Context Protocol 的定义其实就在它的名字里 —— 它是模型用于请求和接收上下文信息的协议。MCP 充当 LLM agents 连接外部工具和数据源的通用适配器；它简化并标准化了 API，使不同的 LLM 框架和工具能够轻松互操作。这使 MCP 成为一个枢纽点，连接起 agent 为实现目标而自主执行的编排逻辑和系统提示，以及发送给工具以更隔离方式执行的操作（至少对发起的 agent 而言是隔离的）。

整个生态系统都非常新，以至于每一种扩展方向都像是在开辟新边疆。我们已经有类似的协议用于 agent 间的交互（ Agent2Agent（ A2A ）当然啦！），还有其他项目用于改进 agent 的推理记忆（ ReasoningBank ）、用于选择最适合当前任务的 MCP 服务器（ RAG-MCP ），并使用语义分析（如零样本分类和模式检测）对输入和输出施加 Guardrails 来控制 agent 被允许操作的内容。

你可能已经注意到，这些项目的核心意图都是为了提升返回给 agent / genAI 上下文窗口的信息质量和可控性？虽然 agentic AI 生态系统将持续发展以更好地处理这些上下文信息（控制、管理并对其进行操作），但始终需要检索最相关的上下文信息，作为 agent 进行推理的原料。

欢迎来到上下文工程！

如果你熟悉生成式 AI 术语，你可能听说过 “提示工程” —— 到现在，它几乎已经成为一种准科学。提示工程用于寻找最优、最高效的方式，主动描述你希望 LLM 在生成响应时采用的行为。“上下文工程” 将 “提示工程” 技术扩展到 agent 端之外，还涵盖 MCP 协议工具端的可用上下文来源和系统，并包括上下文管理、处理和生成的广泛主题：

上下文管理 —— 与在长时间运行和/或更复杂的 agentic 工作流中维持状态和上下文效率相关。迭代规划、跟踪以及任务和工具调用的编排，以实现 agent 的目标。由于 agent 的 “注意力预算” 有限，上下文管理主要关注帮助优化上下文窗口的技术，以捕获最全面的范围和最重要的上下文信息（精准率 vs 召回率！）。技术包括压缩、总结，以及从先前步骤或工具调用中保留上下文，为后续步骤中的额外上下文腾出工作内存空间。
上下文处理 —— 逻辑上（希望主要是程序化步骤）整合、规范化或优化从不同来源获取的上下文，使 agent 能够以较统一的方式在所有上下文中进行推理。基础工作是让所有来源的上下文（提示词、 RAG 、记忆等）都能被 agent 尽可能高效地使用。
上下文生成 —— 如果上下文处理是让检索到的上下文可被 agent 使用，那么上下文生成则赋予 agent 主动请求并接收额外上下文信息的能力，同时也有约束条件。

LLM 聊天应用的各种短暂元素直接映射（有时是重叠的）到上下文工程的这些高级功能：

指令 / 系统提示 —— 提示词是生成式（或 agentic） AI 活动如何引导思维以完成用户目标的框架。提示本身就是上下文；它们不仅仅是语气指令 —— 通常还包括任务执行逻辑和规则，例如 “逐步思考” 或 “深呼吸” 后再回答，以确保答案完全满足用户请求。最近的测试显示，标记语言在构建提示的不同部分时非常有效，但也需要注意将指令调整到既不过于模糊也不过于具体的最佳位置；我们希望提供足够的指令让 LLM 找到正确的上下文，但又不要过于规定，以免错过意外的见解。
短期记忆（状态/历史） —— 短期记忆本质上是用户与 LLM 之间的聊天会话交互。这在实时会话中有助于优化上下文，并可以保存以便未来检索和延续。
长期记忆 —— 长期记忆应包含在多个会话中有用的信息。这不仅仅是通过 RAG 访问的特定领域知识库；最近的研究利用之前 agentic / 生成式 AI 请求的结果，在当前 agentic 交互中进行学习和引用。长期记忆领域一些最有趣的创新与调整状态存储和链接方式相关，使 agent 能够从中断处继续工作。
结构化输出 —— 认知需要努力，所以即便有推理能力，LLM（就像人类一样）也希望减少思考的负担。在缺乏定义的 API 或协议的情况下，为如何读取工具调用返回的数据提供映射（模式）非常有帮助。将结构化输出纳入 agentic 框架，有助于使机器间交互更快、更可靠，并减少基于思考的解析需求。
可用工具 —— 工具可以执行各种任务，从收集附加信息（例如，对企业数据存储发起 RAG 查询，或通过在线 API）到代表 agent 执行自动化操作（例如根据 agent 请求的标准预订酒店房间）。工具也可以是具有自身 agentic 处理链的子 agent。
检索增强生成（RAG） —— 我非常喜欢将 RAG 描述为 “动态知识整合”。如前所述，RAG 是为 LLM 提供在训练时无法访问的额外信息的技术，或者是我们认为最重要以获取正确答案（最符合主观查询的答案）的想法的重复体现。

非凡的宇宙力量，微小的生活空间！

Agentic AI 有太多令人着迷和兴奋的新领域可以探索！仍然有许多传统的数据检索和处理问题需要解决，但也有全新的挑战类型，只有在 LLM 的新时代才开始显露出来。我们今天面临的许多直接问题都与上下文工程有关，即如何在不压垮有限工作内存空间的情况下，为 LLM 提供额外的上下文信息。

能够访问各种工具（和其他 agent）的半自主 agent 的灵活性带来了许多实现 AI 的新思路，很难想象我们可能把这些部分组合在一起的不同方式。目前的大部分研究属于上下文工程领域，重点是构建能够处理和跟踪大量上下文的内存管理结构 —— 这是因为我们真正希望 LLM 解决的深度思考问题具有更高的复杂性和更长的、多阶段的思考步骤，其中记忆至关重要。

该领域的许多持续实验正在尝试找到最佳的任务管理和工具配置，以供 agentic 使用。agent 推理链中的每次工具调用都会产生累积成本，包括执行该工具功能的计算成本以及对有限上下文窗口的影响。一些最新的 LLM agent 上下文管理技术导致了意外的链式效应，例如 “上下文崩溃”，在长期任务中压缩/总结累积上下文时信息丢失过多。理想的结果是工具返回简明且准确的上下文，而不将多余信息侵入宝贵的上下文窗口内存空间。

太多/过多可能性

我们希望职责分离，同时灵活重用工具/组件，因此为连接特定数据源创建专用 agentic 工具是完全合理的 —— 每个工具可以专注于查询一种类型的存储库、一种数据流，甚至一种用例。但要注意：在节省时间/金钱或证明某事可行的驱动下，很容易产生使用 LLM 作为联合工具的强烈诱惑……尽量不要这样，我们以前走过那条路！联合查询就像一个 “通用翻译器”，将传入查询转换为远程存储库能理解的语法，然后还必须以某种方式将多个来源的结果整合成一致的响应。联合技术在小规模下还行，但在大规模，尤其是数据多模态时，联合试图弥合的差距太大。

在 agentic 世界中，agent 是联合者，工具（通过 MCP）是手动定义的连接不同资源的方式。使用专用工具跨不相关的数据源进行查询，似乎是按查询动态联合不同数据流的强大新方法，但使用工具向多个来源提问同样的问题，可能导致的问题比解决的还多。每个数据源底层可能是不同类型的存储库，各自具有检索、排序和保护数据的能力。这些存储库之间的差异或“阻抗不匹配”当然增加了处理负荷。它们也可能引入冲突的信息或信号，即使是看似无害的评分错位也可能严重影响返回上下文的重要性，并最终影响生成响应的相关性。

上下文切换对计算机来说也很难

当你派 agent 执行任务时，其首要任务通常是找到其可访问的所有相关数据。就像人类一样，如果 agent 连接的每个数据源返回不一致和分散的响应，就会产生认知负荷（虽然类型不同），因为需要从检索内容中提取关键上下文信息。这需要时间/计算，每一点都累积到 agentic 逻辑链中。这得出一个结论，就像 MCP 所讨论的那样，大多数 agentic 工具更应该像 API —— 隔离功能，具有已知输入和输出，针对不同类型 agent 的需求进行调整。实际上，我们甚至意识到 LLM 本身也需要上下文来理解上下文 —— 尤其是在将自然语言转换为结构化语法的任务中，当有参考模式时，它们在连接语义点上表现更好（确实需要 RTFM！- Read The F***ing Manual）。