一文详解上下文工程：大模型时代的“外脑“，彻底告别人工调优，零基础小白收藏这一篇就够了！！

最新推荐文章于 2025-09-24 11:33:50 发布

原创最新推荐文章于 2025-09-24 11:33:50 发布 · 816 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #大模型学习 #大模型入门 #大模型 #LLM #上下文工程 #大模型教程

前言

今年6月25日，AI大神Andrej Karpathy 在推特上火了一个词——上下文工程（Context Engineering）。这不仅是技术术语更替，更代表着思维范式的转变。

1、上下文工程解决什么问题

我之前有篇文章写GRPO时候提到，“2024年卷RAG，一周出Demo,优化用半年”，现在不是半年的问题，方向上，想提高生成式问答效果，如果还不跳出RAG的思维，那是很难有优化空间的。简单地“检索-拼接-生成”往往并不能得到最优结果。你可能会遇到：

检索到的信息不准确或与问题无关。
即使检索到了相关信息，LLM却忽略了它，依然依赖自身知识产生幻觉。
上下文太长，导致LLM无法关注到关键信息，或者因超过令牌限制而被截断。

上下文工程正是为了解决这些问题而存在的。 它是一门设计和优化输入给LLM的上下文信息的艺术与科学，旨在最大化LLM的推理能力和输出质量。

2、上下文工程所包含的范围

一句话，只要是模型生成回答之前所看到的一切信息，都是上下文工程的范畴。

其核心工作贯穿以下流程：

1. 检索前的数据准备（知识库层面）

分块（Chunking）

如何将长文档切割成更小的片段至关重要。块太大可能包含多主题干扰信息，太小则可能丢失关键上下文。工程师需要根据文档类型（如MD文档、PDF表格、代码）调整块大小和重叠（Overlap）策略。
数据清洗与增强

清除无关内容（页眉、页脚）、标准化格式、为文本添加元数据（如标题、发布日期、部门），这些元数据可以极大提升检索的精准度。
选择嵌入模型（Embedding Model）

不同的模型在不同领域和语言上表现各异。为特定领域微调嵌入模型或选择专有模型，可以显著提升检索相关性。

2. 检索中的优化（查询与搜索层面）

查询重写/扩展（Query Reformulation/Expansion）

用户的原始查询可能很模糊。使用LLM对查询进行重写、扩展同义词或生成假设性答案（HyDE），可以大幅提升检索效果。
检索策略

除了简单的相似性搜索，还可以融合关键词搜索（BM25）进行混合搜索（Hybrid Search），兼顾语义匹配和精确术语匹配。高级技术如重新排序（Re-ranking）模型，可以对初步检索结果进行二次精排，将最相关的结果排在前面。

3. 生成前的上下文构建（提示词层面）——这是上下文工程的核心

上下文压缩与摘要

检索到的多个文档片段可能包含冗余信息。可以使用LLM先对这些片段进行摘要或去重，只将最精炼的信息放入上下文，节省宝贵的令牌。
结构化与排序

将检索到的上下文以清晰、有条理的方式呈现给LLM。例如，按相关性排序，或使用明确的章节标题（如“## 相关文档1：… ## 相关文档2：…”），帮助LLM更好地理解和利用这些信息。
设计系统提示（System Prompt）

这是上下文工程的精髓。系统提示用于明确指导LLM如何利用上下文。

糟糕的提示

“请根据以下文档回答问题。”
工程化的提示

“你是一个专业的客服助手。请严格根据提供的参考文档来回答问题。如果文档中的信息不足以回答问题，请明确回答‘根据已有信息无法回答该问题’，切勿编造信息。你的回答需清晰引用文档来源。参考文档如下：…”

通过上述精细化的操作，上下文工程确保了注入LLM的信息是高相关、高质量、易理解的，从而最终引导LLM生成更准确、更可靠、更符合要求的答案。

3、上下文工程落地的策略

上面四个落地策略来自Langchain 发布的一篇博客文章，归纳四个词就是写入-筛选-压缩-隔离，有点像SQL的增-删-改-查。

本质上，我们现在的调优工作，其实都在上下文工程这个范畴，这里面涉及到的Scratchpads、Memories、Tools、Knowledge、Context Summarization、Multi-agent、Context等

再回归到问题的本质，如果只是需要提高大语言模型回答问题的准确率和质量，engineering这里面有非常大的想象空间，RAG只是一个context engineering非常粗糙的一个工程方案。

Andrej Karpathy一个推特火了一个新词，就能让这个工作成为业界一个追逐范式，并且发展成一个工程学科，这就是业界影响力！

4、上下文工程不等同于上下文

两者的目的都是通过引入额外的、动态的信息，使系统的输出与当前情境更相关、更精准。

在我们MCP应用中，目前我们一个稍微复杂点的问题，MCP最多能调12-15个Tools, 但实际调用3个Tools就能解决这个问题。一些技术报告也实验证明了更多的工具、更多的补充信息、更长的上下文并不一定会产生更好的响应。上下文过载可能会导致智能体以意想不到的方式失败。上下文可能会变得有害、分散注意力、令人困惑或产生冲突。

在我们A2A应用中，智能体之前也是依赖上下文来收集信息，但综合发现一旦涉及到多轮对话上下文，动作智能体之间的关系就容易出错，因为一旦涉及到相互协作和相互依赖，信息之间就会出现错乱。

我个人理解，在比较高级一点的应用，这两项技术应该是相互融合的，一方面要让生成的回答更准确、可信、相关；另一方面，追求个性化、情境化的智能输出。

5、上下文工程前瞻思考

如题，Context Engineering是解锁大模型真正潜力的关键，未来落地落地思考会暂时会围绕以下两点去展开：

1）大语言模型（LLM）作为智能体的大脑，那上下文工程就是这个大脑的”外脑“，它未来要自主决定何时需要检索、检索什么、如何根据初步结果进行下一步操作，这一定是自动化的。

2）突破RAG系统限制，追求对上下文的深度加工**，而RAG只提供了“检索”这一种获取方式。加工包括：总结、翻译、格式化、过滤、排序、压缩等，远非简单的“检索并拼接”。**

最后，回想在深度学习时代，一直在调侃自己是“调参侠”，至从研究人员把离散的网络结构搜索变成连续可微的优化问题，一次训练即可评估数千种结构，从此“调网络结构”不再需要人手动试。后续 ENAS、FBNet、ProxylessNAS 等把显存和搜索时间降到单卡几小时，彻底工程化，模型输出直接可获得部署的模型（模型结构 +网络权重 +超参数），这样AI工程师人员彻底不用关心模型训练过程。

如今在大模型时代，提示工程（Prompt Engineering）已然不能完全解放人工写提示过程，但上下文工程（Context Engineering）是有可能彻底告别人工调优的。

期待人工调优完全自主化这一天的到来！

最后

为什么要学AI大模型

当下，⼈⼯智能市场迎来了爆发期，并逐渐进⼊以⼈⼯通⽤智能（AGI）为主导的新时代。企业纷纷官宣“ AI+ ”战略，为新兴技术⼈才创造丰富的就业机会，⼈才缺⼝将达 400 万！

DeepSeek问世以来，生成式AI和大模型技术爆发式增长，让很多岗位重新成了炙手可热的新星，岗位薪资远超很多后端岗位，在程序员中稳居前列。

在这里插入图片描述

与此同时AI与各行各业深度融合，飞速发展，成为炙手可热的新风口，企业非常需要了解AI、懂AI、会用AI的员工，纷纷开出高薪招聘AI大模型相关岗位。
在这里插入图片描述
最近很多程序员朋友都已经学习或者准备学习 AI 大模型，后台也经常会有小伙伴咨询学习路线和学习资料，我特别拜托北京清华大学学士和美国加州理工学院博士学位的鲁为民老师给大家这里给大家准备了一份涵盖了AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频 全系列的学习资料，这些学习资料不仅深入浅出，而且非常实用，让大家系统而高效地掌握AI大模型的各个知识点。