从 RAG 到上下文工程：AI 工程的重心，正从“调模型”转向“策展上下文”
AI 趋势观察 · 检索范式 × 上下文工程 | 2026 年 5 月 | 约 15 分钟阅读
最近 IBM Technology 频道上有一期视频，标题平平无奇——《How RAG, GraphRAG, and Context Engineering Improve AI Performance》，主讲人是 IBM 的 Master Inventor Martin Keen。但它讲的事不平常：Keen 全程在推演一条范式演进线，并抛出一个和"参数越多、模型越强"的流行印象相左，却正在被越来越多一线团队认同的判断——
让 AI"做对事"的最大瓶颈，从来不是模型本身，而是它在推理那一刻能触达的上下文。
换句话说，模型的能力上限，不只取决于它有多少参数，更取决于它能实时触达的上下文结构。这句话听起来像句正确的废话，但当你把它和 2024 年以来的一串数据摆在一起看，会发现它正在重写整个 AI 工程的重心：从"调教模型"转向"策展上下文"（from tuning the model to curating the context）。
一、一条被"上下文"串起来的演进线
要理解上下文工程为什么在 2025–2026 集中爆发，得先看清 RAG 这条路是怎么一步步走到"结构"这一站的。
2020 年，RAG（检索增强生成）作为缓解大模型幻觉的第一个工程化方案登场。逻辑很朴素：与其让模型凭"想象"作答，不如先从外部知识源检索真实文档塞进上下文，强迫它基于事实生成。这套"切块 → 嵌入 → 相似度检索 → 生成"的流水线，就是后来被称为 Naive RAG 的范式。它确实把幻觉压下去了一截，于是几乎成了所有 LLM 应用的标配。
但工程师很快撞上天花板。一份 2024 年的综合 RAG 基准测试给出了一个让人清醒的数字：最先进的 RAG 系统也只能正确回答 63% 的事实型问题；朴素 RAG 只有 44%；而完全不做检索的 LLM 约为 34%。检索确实有用，可"切块 + 相似度"这条路，远没有想象中可靠——尤其是当问题需要跨文档连接、需要对整个语料做全局判断时。
2024 年，Microsoft Research 在论文《From Local to Global: A GraphRAG Approach to Query-Focused Summarization》中提出 GraphRAG，并于同年 7 月开源。它的核心洞察一针见血：朴素 RAG 把文档当成一堆"互不相识的孤立碎片"，无法回答需要连接关系、需要全局综合的问题。GraphRAG 用知识图谱（实体为节点、关系为边）替代扁平的文本块，让模型"在结构上推理"，而不是"在文本上搜索"。
2025 年 6 月，应用 AI 领域两个最有分量的声音——Andrej Karpathy 和 Shopify CEO Tobi Lütke——几乎同时公开表态：我们该用的词不再是 prompt engineering，而是 context engineering（上下文工程）。Lütke 的定义是"为任务提供全部上下文，使其对 LLM 而言变得可解"；Karpathy 则称它是"填充上下文窗口的微妙艺术与科学"。三个月后的 2025 年 9 月 29 日，Anthropic 应用 AI 团队发博客把这个概念正式经典化，定义为"在推理期间，为达成期望结果而策展与维护最优 token 集合的一整套策略"。
至此，从 RAG 到 GraphRAG 再到上下文工程的演进线被彻底打通。Martin Keen 这期视频，正是站在这条线的终点回望全程。
二、先把四个词的边界画清楚
这四个词常被混着用，但它们处在不同的抽象层级，不画清边界后面会打架。
关键的层级关系是：Naive RAG、Advanced RAG、GraphRAG 是三种"检索范式"，而上下文工程是包裹它们的"上层工程学科"。检索只是上下文工程的一个环节——上下文工程还要管系统指令、工具定义、对话历史、记忆、输出格式与治理。Keen 在视频里把"精确检索"（含 GraphRAG 与上下文压缩）列为上下文工程的支柱之一，正是这个意思。
三种 RAG 的硬性差异如下：
| 维度 | Naive RAG | Advanced RAG | GraphRAG |
|---|---|---|---|
| 数据表示 | 文本块 + 嵌入 | 文本块 + 嵌入 + 元数据 | 节点 + 边（+ 嵌入） |
| 检索方式 | 向量相似度 | 混合检索 + 重排序 | 图遍历（+ 向量） |
| 查询变换 | 无 | 多查询、HyDE 等 | 实体抽取 + Cypher |
| 多跳推理 | 不支持 | 勉强 | 支持 |
| 全局理解 | 不支持 | 勉强 | 支持（社区摘要） |
| 实现难度 | 低 | 中 | 很高 |
| 索引成本 | 低 | 中 | 高（LLM 三元组抽取） |
| 最适数据 | 通用文档、FAQ | 技术文档、内部 Wiki | 人、组织、事件、关系 |
这张表最该带走的一点是：它们不是"谁取代谁"，而是"何时用谁"。 Keen 反复强调，标准 RAG 处理简单查找（"退货政策是什么？"）依然高效；只有当问题需要跨文档连接关系、需要对整个语料做主题综合时，才值得请出 GraphRAG 或上下文压缩这类更重的武器。一个好用的判断启发法是：如果一个人类专家读一篇文档就能答，用向量 RAG；如果他得读十篇、还要自己连线，才用 GraphRAG。
而上下文工程的独特视角在于，它不问"怎么检索得更准"，而问 Anthropic 那句被反复引用的话：找到"能最大化期望结果概率的、最小的高信号 token 集合"。这句话点破了一个反直觉的事实——更多上下文 ≠ 更好结果。后面会看到，这一点有硬数据撑腰。
三、GraphRAG：结构如何战胜规模
GraphRAG 的工作流可以拆成三个阶段，其中第二阶段才是它真正的"结构性贡献"，也是最容易被教程跳过的部分。
阶段一，抽取（构建图谱）。 先定义一个本体（ontology），告诉 LLM 该抽哪些类型的实体和关系。然后 LLM 逐块阅读文档，抽出"实体—关系—实体"三元组——一条评论"我的充电器用了两个月就坏了"会变成 (某充电器, 存在问题, 耐久失效)。处理完整个语料后，所有文档里对同一个品牌的提及都会解析到同一个节点。你得到的不再是一堆孤立碎片，而是一张语料级的关系地图。
阶段二，社区检测（架构核心）。 抽取完你会得到一张庞大杂乱的关系网。这时用社区检测算法（Microsoft 的实现用 Leiden 算法），把图切成一层层"内部紧密连接、对外松散连接"的实体簇，再由 LLM 为每个簇写一份摘要。这些摘要成为回答全局问题的索引——据原论文，在社区摘要层查询所消耗的 token，仅为直接阅读原始文档的约 2%–3%。你不再扫描 500 条评论，而是阅读 20 份蒸馏后的社区摘要。这一步是 GraphRAG 能回答"整个数据集的主题是什么"这类问题的关键。
阶段三，查询（局部 vs 全局）。 GraphRAG 有两种查询模式，用错是最常见的部署失误。局部搜索从查询出发找到最近实体，沿边遍历收集上下文，适合针对具体实体的问题；全局搜索对所有社区摘要做 map-reduce，每份摘要生成局部答案再综合，适合宏观主题问题。把这两种模式用反，效果会差得离谱。
这套机制的威力，体现在一个反复被引用的数字上：在需要全局综合的问题上，人类评审偏好 GraphRAG 答案的比例达到 72%–83%；综合性比传统向量 RAG 高 50%–70%。最值得玩味的是，这个提升用的是同一个底层 LLM——仅仅因为"看到的信息被组织成了图"，答案质量就出现了断层式跃升。这正是 Keen 那句"瓶颈在上下文结构"的最佳注脚。
四、上下文工程：四大支柱与"少即是多"
如果说 GraphRAG 是"精确检索"这根支柱里的明星技术，那么 Keen 在视频里给出的上下文工程四大支柱，则是托起整个可靠 AI 系统的完整骨架。
第一根是连接访问：让模型能实时触达分散在各处的企业数据，而非依赖训练时被"烧进"参数的静态知识。第二根是知识层：用知识图谱等结构映射实体关系，把机构知识组织成可推理的形态。第三根是精确检索：在海量数据里只取最相关的部分，简单场景用标准 RAG，复杂场景用 GraphRAG 与上下文压缩。第四根是运行时治理：在推理时刻管控权限、合规、数据泄露边界，让上下文不仅"对"，而且"合规可审计"。
Anthropic 则从"为什么必须这么做"的角度补足了原理。它的博客提出一个概念叫 context rot（上下文腐烂）：随着上下文窗口的 token 数增加，模型从中准确召回信息的能力反而下降。根本原因在 Transformer 架构——n 个 token 会产生 n² 对两两关系，上下文越长，模型的"注意力预算"被摊得越薄。所以上下文必须被当作有限资源、边际收益递减来对待，而不是"窗口越大越好"。
这就引出了上下文工程里最反直觉、也最有产业意义的一个实验结论。Anthropic 在多智能体研究中发现：与其把全部上下文塞给一个"大脑很大"的单智能体，不如让每个子智能体只拿到经过仔细裁剪、范围明确的上下文窗口——后者在复杂多步研究任务上的表现高出 90% 以上。用他们自己的话说，"团队是靠隔离上下文赢的，不是靠最大化上下文。"
为了对抗上下文腐烂、维持长程任务的连贯性，Anthropic 给出三种已在 Claude Code 中落地的技术，可以和 LangChain 提出的 Write / Select / Compress / Isolate 四策略对照着看：压缩（Compaction），把接近窗口上限的历史总结后重启新窗口，最轻量的一种是工具调用完成后就把原始结果从历史里清掉；结构化记笔记，让智能体把笔记写到上下文窗口之外（如 NOTES.md），需要时再读回；子智能体架构，主智能体做高层规划，子智能体在各自洁净的上下文里干深活，只回传 1000–2000 token 的精炼结论。
落到产品上还有一个很能说明问题的数字：Anthropic 在 2026 年 4 月 23 日上线智能体记忆能力后，早期客户 Rakuten 报告其智能体错误率下降了 97%。把"跨会话知识"从"实时上下文窗口"里解耦出去，本身就是一次典型的上下文工程胜利。
五、把数据收拢成一张表
讲到这里，散落的数字该收拢了。下面这张表是全文的定量骨架：
| 主题 | 关键数据 | 来源 |
|---|---|---|
| 朴素 RAG 的天花板 | SOTA RAG 仅答对 63% 事实问题；朴素 RAG 44%；无检索 34% | 2024 综合 RAG 基准 |
| GraphRAG 偏好率 | 全局综合问题上人类偏好 72%–83% | Microsoft Research |
| GraphRAG 综合性提升 | 比向量 RAG 高 50%–70% | Microsoft Research |
| LazyGraphRAG 降本 | 索引成本降至全量的约 0.1%，查询成本降至约 4% | Microsoft 官方博客 |
| 多智能体隔离上下文 | 复杂任务表现提升 >90% | Anthropic |
| 记忆能力效果 | Rakuten 错误率下降 97% | Anthropic / Rakuten |
| 行业认知转变 | 82% IT/数据负责人认为"仅靠 prompt 已无法支撑规模化 AI" | 2026 State of Context Management Report |
| 生产部署现状 | 57% 组织已有 Agent 上线，32% 把"质量"列为扩展首要障碍 | LangChain 2025 报告 |
这里要单独说一下成本。GraphRAG 早期有个致命门槛：全量索引一份大型企业语料，一次最高可能烧掉约 3 万美元，仅实体抽取一步就占总索引成本的约 75%。这把绝大多数中小团队挡在了门外。Microsoft 随后推出 LazyGraphRAG，把社区摘要的生成从"索引时预计算"推迟到"查询时按需进行"，使索引成本骤降到全量的约 0.1%（与标准向量 RAG 持平），全局查询成本降到约 4%。在某些工程化实现里，那 3 万美元的索引账单被压到了约 30 美元。代价是查询延迟变高，但"贵到玩不起"这个门槛基本被抹平了。
六、对从业者和企业，这意味着什么
这一节切换到 ICE 的观察视角：撇开技术细节，看看这条演进线对不同人群到底意味着什么。
🔧 技术视角：最值钱的技能从"措辞"变成了"信息架构"。 据报道，Gartner 把上下文工程列为 2026 年的突破性 AI 能力；2026 State of Context Management Report 显示 82% 的 IT 与数据负责人认为仅靠 prompt 已无法支撑规模化 AI。新兴的核心技能不再是写漂亮的提示词，而是四类硬功夫：信息架构（决定哪些上下文重要、怎么组织）、检索系统设计、状态管理（跨会话与跨智能体的记忆）、token 经济学（在固定预算下分配竞争性需求）。一个正在形成的范式叫"上下文即代码"——把上下文配置当作版本化、可测试的产物来管理，就像基础设施即代码改造了 DevOps。
🏢 落地视角：Agent 上不去生产，问题往往不在模型，而在"上下文装配"。 多份生产部署分析指出，2026 年 Agent 落地的主导失败模式既不是选错模型，也不是 prompt 太弱，而是糟糕的上下文装配——模型在该做决策时拿到了错误的、过量的或陈旧的信息。LangChain 的报告也佐证：57% 的组织已有 Agent 上线，但 32% 把"质量"列为扩展的首要障碍。这把可观测性（追踪 token 消耗、定位上下文失效）从"加分项"推成了"必修课"。
🔒 合规视角：治理必须在推理时刻就生效。 Keen 把"运行时治理"列为四大支柱之一并非装点门面。当模型能实时触达企业全量数据时，权限边界、合规约束、数据泄露防护就不能事后补——必须在组装上下文、调用工具的那一刻就生效。这让上下文工程天然地和企业安全、审计、合规团队绑在一起，尤其在多方数据协作、隐私计算这类强约束场景下，"哪些数据能进上下文、进了能不能留痕"会直接决定一个 AI 系统能不能上线。
🇨🇳 本土视角：结构化的门槛正在向中小团队开放。 LazyGraphRAG 把 GraphRAG 的入门成本从 3 万美元压到约 30 美元，意味着国内做行业知识库、法规问答、企业内部 Wiki 的团队，已经可以用 Microsoft GraphRAG 开源框架 + Neo4j 社区版先跑通一个 POC，再决定要不要上全量。对手握大量非结构化行业文档、却苦于"向量检索答不准复杂问题"的国内企业来说，这是一个时机已到的方向。
七、想动手，从哪开始
落地不必一步到位。一条被多方验证的渐进路线是：先用 4–6 周做 POC——选一个边界清晰的知识库（内部技术手册或法规文档），用开源框架搭端到端原型，配 Neo4j 社区版验证图质量与查询效果；确认架构确实改善了你的查询模式后，再进入试运行，补上增量索引流水线、查询路由层（自动判断局部/全局并分派）和质量监控；最后才上生产级集群、成本优化、完整审计日志与访问控制。一个省钱提示：先用 LazyGraphRAG 验证，再迁移到全量 GraphRAG，别一上来就烧那 3 万美元的索引账单。
几个最容易踩的坑值得提前记下：一是实体解析失败，"某品牌"的多种写法没合并成同一节点，会让图谱碎片化、答案漏掉关键连接，抽取后必须做去重 pass；二是查询模式用反，局部/全局搞混是头号部署失误；三是压缩过度，Compaction 太激进会丢掉"当下不起眼、事后才关键"的上下文，正确做法是先最大化召回再迭代提升精度。
还有一个绕不开的基础设施：MCP（Model Context Protocol）。它在 2024 年 11 月由 Anthropic 开源，2025 年 3 月被 OpenAI 采纳，2025 年 12 月移交 Linux 基金会，注册表已有约 2000 个服务器，正在成为"智能体—工具/上下文接入"的事实标准。工程上的建议很务实：把 MCP 服务器当作依赖来管理，锁版本、审计提供方。
结论
如果只带走几句话，我希望是这些：
- 结构是 LLM 的免费午餐。 同一个模型，仅仅因为信息被组织成知识图谱而非扁平文本块，答案质量就能跃升 50%–70%。很多团队花在"换更大模型"上的钱，本可以用更便宜的"重构上下文结构"省下来。
- 更多上下文会主动伤害性能。 context rot 与 n² 注意力预算的存在，使"塞满百万 token 窗口"成了反模式。Anthropic 的多智能体实验给了最锋利的反证：隔离上下文比最大化上下文好 90% 以上。判断一个 AI 系统是否成熟，要看它敢不敢做减法。
- 瓶颈从模型层上移到了平台层。 上下文工程里最高杠杆的动作（压缩、工具结果清理、记忆）都是平台级能力，而非应用级技巧。这把"该招最会写 prompt 的人"变成了"该投资哪个平台团队把上下文当一等公民来运营"——一个总监及以上级别的预算议题。
- 行动建议：如果你手上有"答不准复杂关系问题"的 RAG 系统，先用 LazyGraphRAG 低成本验证 GraphRAG；如果你在做多步 Agent，先把上下文做减法（压缩 + 隔离）再谈换模型。
回到 Keen 那句话——Context is the biggest bottleneck in getting AI to do what you want.（上下文，是让 AI 听话的最大瓶颈。）下次你的 AI 又给出一个"听起来很对、其实全错"的答案时，不妨先别急着怪模型：你真的确定，问题不是出在你喂给它的那一坨上下文结构上吗？