上下文工程六大支柱：压缩（Compression）
上篇文章我们通过“结构化”和“检索”为模型准备了高质量的上下文。然而，我们很快就会遇到一个无法回避的物理限制：模型的上下文窗口是有限的。即便是拥有百万级Token上下文窗口的“巨无霸”模型，其处理长上下文的成本（无论是时间、算力还是金钱）也是一个不容忽视的因素。这便引出了上下文工程的第三大支柱——压缩（Compression）。
压缩的核心目标是：在将上下文送入LLM之前，通过各种技术手段，在尽可能不损失关键信息的前提下，显著减小其Token数量。 它是一门在“信息保真度”和“成本效益”之间寻求最佳平衡的艺术。
1、 “信息密度”的挑战
从L2和L3记忆中检索出的上下文，往往包含大量的冗余和“低信息密度”内容。例如，一篇完整的技术文档，对于回答一个具体问题来说，可能只有几个段落是真正关键的。将整篇文档塞入上下文，不仅浪费了宝贵的窗口空间，也可能因为引入过多噪声而干扰模型的注意力。
压缩，就是要提升最终送入模型上下文的“信息密度”，确保每一个Token都尽可能地为回答问题贡献价值。
2、压缩的两种哲学：抽取式与抽象式
上下文压缩主要有两种技术路线：
1.抽象式压缩（Abstractive Compression）：这种方法使用一个LLM来重写或总结原始上下文，生成一个更短的版本。我们在L2情景记忆中讨论的“对话摘要”就属于这一类。它的优点是能生成流畅、连贯的文本，但缺点是可能会在总结过程中丢失关键细节，或引入“总结模型”自身的幻觉。
2.抽取式压缩（Extractive Compression）：这种方法不生成新文本，而是像“淘金”一样，从原始上下文中识别并抽取出最重要的部分（如关键句子或词语），然后将它们拼接在一起。它的优点是能最大程度地保留原始信息的“原汁原味”，避免了二次生成带来的信息失真。近年来，抽取式压缩因其高保真度和可控性，成为了研究和应用的热点。
3、抽取式压缩：从“选择性上下文”到LLMLingua
抽取式压缩的核心，在于如何度量上下文中不同部分的重要性。下面介绍两种代表性的技术。
3.1Selective Context：基于信息熵的剪枝
“Selective Context" 提出了一种巧妙的思想：利用信息论中的“自信息”（Self-Information）或“困惑度”（Perplexity）来判断一个词或一个句子的信息量。一个句子的困惑度越低，意味着它越符合语言模型的“预期”，其包含的“意外信息”就越少，也即信息密度越低。
工作流程：
1.使用一个小型语言模型（如GPT-2）计算上下文中每个句子的困惑度。
2.设定一个压缩比率（例如，保留50%的句子）。
3.根据困惑度从高到低对句子进行排序，优先保留那些让模型“感到意外”的、信息量大的句子。
4.将这些高信息密度的句子拼接起来，形成压缩后的上下文。
这种方法实现简单、计算快速，能有效地剔除那些客套话、连接词等低信息密度的内容。
3.2 LLMLingua：用小模型为大模型“减负”
LLMLingua 及其后续版本 LongLLMLingua 是目前最先进的抽取式压缩技术之一。它将压缩问题看作一个“指令遵循”问题，其核心理念是“用一个更小的、专门负责压缩的LLM，来为昂贵的大LLM‘预处理'上下文"。
LLMLingua的“粗到细”压缩流程：
1.指令感知的重要性分析：首先，它会分析用户的最终指令，理解任务的目标是什么。
2.粗粒度压缩：在文档或段落级别，LLMLingua会判断哪些段落与最终指令的关联性较小，并将其整个移除。
3.细粒度压缩：在句子或Token级别，它会逐句分析，进一步删除冗余的词语和表达，同时尽可能保留关键的实体、术语和逻辑关系。
4.迭代优化：它会通过一个迭代过程，不断地在压缩率和信息损失之间进行权衡，直到达到预设的压缩目标。
LLMLingua的强大之处在于，它的压缩过程是面向任务目标的。它不是盲目地保留高信息量的部分，而是保留对完成当前任务最重要的部分。实验表明，使用LLMLingua可以在压缩掉高达20倍的Prompt长度的同时，仍然保持与使用完整上下文相近甚至更好的性能，极大地降低了API调用成本和延迟。
4、压缩在上下文工程中的位置
压缩通常作为上下文流水线中的一个独立步骤，位于检索之后、生成之前。
完整流程：
用户问题→ [查询转换] → 优化查询 → [检索] → 原始上下文块 → [压缩] → 高密度上下文 → [结构化] → 最终Prompt → LLM生成
通过在检索后增加一个压缩环节，我们可以更“奢侈”地进行检索（例如，召回更多的文档块），因为我们有信心通过后续的压缩步骤，将这些粗糙的、可能包含大量噪声的材料，“精炼”成一小块高纯度的“信息金块”，最终喂给LLM。
5、最佳实践：基于LLMLingua官方文档的Prompt压缩
以下代码示例均来自Microsoft LLMLingua官方GitHub仓库。
5.1 安装LLMLingua
5.2 基础使用
5.3 使用不同模型
5.4 LongLLMLingua：长上下文压缩
LongLLMLingua专门针对长上下文场景进行了优化，可以缓解"Lost in the Middle"问题：
5.5 LLMLingua-2：更快更准的压缩
LLMLingua-2通过GPT-4数据蒸馏训练，比LLMLingua快3-6倍：
5.6 结构化Prompt压缩
使用<llmlingua></llmlingua>标签可以精细控制哪些部分需要压缩、压缩比率是多少：
5.7 SecurityLingua：安全防护压缩
SecurityLingua是一个安全护栏模型，通过安全感知的Prompt压缩来揭示越狱攻击背后的恶意意图：
5.8 完整RAG压缩流程示例
以下是将LLMLingua集成到RAG流程中的完整示例：
通过压缩，我们将数千字的原始上下文，精炼成了包含所有核心数字和结论的几十个单词，这便是压缩的威力所在。它使得在有限的上下文窗口内处理海量信息成为可能，是实现高效、经济、可扩展AI应用的关键技术支柱。
我们已经讨论了如何结构化、检索和压缩上下文。然而，一个真正智能的系统，其上下文处理流程不应该是一条僵化的、线性的“流水线”。不同的任务、不同的用户、甚至任务进行到不同阶段，所需要的上下文组合都是不同的。这便引出了上下文工程的第四大支柱，也是最具“智慧”的一环——编排（Orchestration）。
编排的核心目标是：根据当前任务的动态需求，智能地、自适应地决定“应该使用哪些上下文”、“从哪里获取它们”以及“如何将它们组合在一起”。如果说前三大支柱是乐器和乐谱，那么编排就是那位指挥家，他根据乐曲的情感起伏，动态地决定何时让小提琴拉响，何时让铜管奏鸣。
1、从“静态管道”到“动态决策”
一个基础的RAG系统，其上下文处理流程是固定的：检索 -> 压缩 -> 生成。这种“一刀切”的模式在处理简单问题时尚可，但面对复杂多变的现实世界，其局限性便暴露无遗：
成本与效率问题：对于一个简单的事实性问题（"CEO是谁？"），也许根本不需要复杂的网页搜索和多文档检索，直接查询数据库即可。一个固定的、复杂的管道会造成不必要的延迟和API调用成本。
能力与工具问题：有些问题需要实时信息（“今天天气如何？”），必须调用网页搜索工具；有些问题涉及私有数据（“我上个季度的销售额是多少？”），必须查询内部数据库；还有些问题是纯粹的创作（“写一首关于星空的诗”），可能根本不需要外部上下文。
编排，就是要打破这种僵化的管道，引入一个动态决策的“大脑”，让系统能够“看菜下饭”，为每一个请求都量身定制最高效、最合适的上下文策略。
2、编排的核心机制
实现动态编排，主要依赖于两大核心机制：路由（Routing）和代理（Agentic）。
2.1 上下文路由器：智能的“交通警察”
路由器（Router）是实现编排的最直接方式。它是一个前置的决策模块，通常由一个轻量级的LLM来充当。它的职责是在正式执行任务前，对用户的请求进行分析和分类，然后将其“路由”到最合适的处理路径上。
一个典型的上下文路由器的工作流程：
1.接收请求：接收到用户的原始查询。
2.分析意图：调用一个"路由LLM"，并给它一个特殊的Prompt，要求它分析查询的意图，并从几个预定义的“路由”中选择一个。
分发任务：根据路由LLM返回的类别（如vector_db_qa），将任务分发到对应的、专门优化的处理管道中。
通过这种方式，路由器就像一个高效的交通警察，避免了所有请求都挤在一条拥堵的“主干道”上，大大提升了整个系统的效率和准确性。
2.2 代理式编排：会思考的“研究员”
如果说路由器是一次性的静态决策，那么代理式编排（Agentic Orchestration）则是一种更高级的、多步骤的动态决策过程。这也就是业界火热的Agentic RAG。
在这种模式下，系统不再是一个被动的管道，而是一个主动的“代理”（Agent）。这个Agent拥有思考、规划和使用工具的能力。它会根据任务的进展，迭代地、自适应地调整其上下文获取策略。
Agentic RAG的工作流示例：
1.初步规划：Agent首先思考：“这是一个复杂问题，我需要先找到相关论文，再在论文中寻找特定信息。”
2.步骤1：检索：Agent调用search_arxiv工具，查询“大海捞针测试论文”。它召回了3篇最新的论文。
3.步骤2：评估与反思：Agent快速“阅读”了3篇论文的摘要，发现其中2篇是相关的，但摘要中并未直接提及“多头注意力机制”。它反思："我的信息还不够，我需要深入阅读这2篇论文的全文。"
4.步骤3：深入检索（自适应调整）：Agent决定不进行新的外部搜索，而是对已召回的2篇论文全文进行一次内部的、更精细的关键词检索，搜索"Multi-Head Attention"。
5.步骤4：综合与生成：在其中一篇论文中，它找到了相关的段落。于是，它将这个段落作为最终的精确上下文，结合用户的原始问题，生成了最终的答案。
在这个过程中，Agent不再是盲目地执行一个固定流程，而是像一个真正的研究员一样，不断地评估当前上下文的完备性，并动态地决定下一步是该扩大搜索范围，还是该深入挖掘已有信息。这种迭代和反思的能力，是Agentic编排的核心。
3、LangGraph：实现代理式编排的利器
像LangChain推出的LangGraph 这样的框架，就是为实现复杂的代理式编排而生的。它将Agent的工作流建模为一个状态图（State Graph）：
节点（Nodes）：图中的每个节点代表一个“动作”，可以是一个工具的调用（如retrieve），也可以是一次LLM的调用（如generate）。
边（Edges）：图中的边代表了不同动作之间的“流转条件”。你可以定义逻辑，来决定在一个节点完成后，接下来应该走向哪个节点。
状态（State）：一个全局的状态对象，在图的各个节点之间传递和更新，承载着任务的中间结果和上下文信息。
通过LangGraph，我们可以轻松地构建出包含循环、分支和判断的复杂工作流，从而将Agentic编排的思想，用清晰、模块化的代码实现出来。
4、从“工人”到“工头”
编排是上下文工程从“体力劳动”走向“脑力劳动”的关键一步。它让我们的系统从一个只会执行固定指令的“工人”，进化成了一个能够自主规划、动态决策的“工头”。
通过综合运用路由器和代理式编排，我们可以构建出能够根据具体问题，灵活调用不同工具、组合不同信息源、自适应调整策略的智能系统。这不仅极大地提升了系统的性能和效率，也使其在面对未知和复杂的挑战时，表现出更强的鲁棒性和“智慧”。
5、最佳实践：基于LangGraph官方文档的Agent编排
以下代码示例基于LangGraph官方文档，展示了如何使用LangGraph构建一个具备工具调用能力的Agent。
5.1 安装依赖
5.2 完整Agent示例（基于官方Quickstart）
5.3 代码解析
这个官方示例展示了LangGraph的核心概念：
1.状态定义（State）：MessagesState定义了Agent在执行过程中需要维护的状态，包括消息列表和LLM调用次数。
2.节点定义（Nodes）：
llm_call：调用LLM决定是否需要使用工具
tool_node：执行工具调用并返回结果
3.条件边（Conditional Edges）：should_continue函数实现了动态路由逻辑——如果LLM决定调用工具，流程转向tool_node；否则结束。
4.循环结构：tool_node执行完后会回到llm_call，形成一个循环，直到LLM决定不再调用工具。
5.4 自适应RAG Agent示例
基于上述官方模式，我们可以构建一个自适应RAG Agent：
这个示例展示了如何使用LangGraph构建一个能够根据知识库检索结果动态决定是否需要网络搜索的自适应RAG Agent。
