1. 项目概述为什么“上下文工程”是LLM应用成败的关键如果你最近在折腾大语言模型无论是想用它来做个智能客服、写个代码助手还是搭建一个公司内部的知识库大概率都踩过这样的坑你精心设计了一个问题但模型的回答要么答非所问要么信息不全甚至干脆开始胡言乱语。问题可能不出在模型本身而在于你“喂”给它的信息——也就是我们常说的“上下文”。“上下文工程”这个词听起来有点学术但它的内核非常朴素如何把正确的信息以正确的格式在正确的时机交给大模型从而让它给出正确且有用的回答。这就像你请一位顶尖的专家来帮你解决一个复杂问题你不能只丢给他一句“帮我看看”而是需要把项目背景、相关数据、历史文档、以及你希望达成的目标都整理好一并交给他。上下文工程就是为LLM这位“专家”准备这份“工作简报”的艺术和科学。我见过太多项目模型选型很先进算力投入也不小但最终效果平平问题往往就出在上下文处理这个“脏活累活”上。一个典型的例子是构建基于私有知识库的问答系统。很多开发者直接把一堆PDF文本切块、向量化、然后塞进向量数据库查询时把最相似的几个片段扔给LLM。结果呢模型经常给出包含矛盾信息或者缺乏关键背景的回答。这是因为简单的“相似度检索”无法理解问题的全局语境和信息的逻辑关联割裂的文本片段让模型“只见树木不见森林”。因此深入理解并掌握上下文工程是让LLM从“玩具”变成“生产力工具”的必经之路。它决定了你的应用是智能助理还是人工智障是效率神器还是垃圾信息生成器。接下来我将结合一线实战经验为你拆解上下文工程的核心思路、关键技术以及那些文档里不会写的避坑指南。2. 核心思路拆解从“堆料”到“精喂”很多人对上下文工程的理解还停留在“把Prompt写长一点、详细一点”。这只是一个起点甚至可能是一个误区。真正的上下文工程是一个系统工程其核心思路可以概括为在有限的上下文窗口内实现信息密度、相关性和结构化的最大化。2.1 理解模型的“工作记忆”限制首先必须建立一个关键认知LLM的上下文窗口Context Window不是硬盘而是它的“工作记忆”或“短期记忆”。就像人脑无法同时思考几百个不相关的复杂概念一样模型在处理超长文本时对中间部分信息的记忆和理解能力会显著下降这被称为“中间层衰减”现象。因此我们的目标不是把所有相关信息都塞进去而是进行智能的筛选、压缩和重组。为什么简单的检索增强生成RAG常常不够用经典的RAG流程是用户提问 - 检索相关文档片段 - 将片段作为上下文输入LLM生成答案。这个模式假设“最相似的片段就是最相关的上下文”。但现实很骨感信息碎片化检索到的多个片段可能彼此冲突或者缺乏串联起完整故事的逻辑线。关键背景缺失最相关的片段可能依赖于前文某个定义或假设而这个背景没有被检索到。噪声干扰相似度高的片段可能包含大量与当前问题无关的细节挤占了宝贵的上下文空间。因此进阶的上下文工程思路是“检索-加工-组装”而非简单的“检索-拼接”。2.2 上下文构建的四大核心原则基于上述认知我总结出构建高质量上下文的四个原则相关性优先Relevance First确保进入上下文的每一个句子、每一个数据点都与当前任务高度相关。这需要超越词频的语义理解。结构清晰Clear Structure为上下文赋予清晰的逻辑结构如“背景-问题-约束-示例”帮助模型快速定位信息。使用XML标签、Markdown标题、分隔符等显式地标记不同部分。信息密度优化Density Optimization去除冗余的修饰词、重复的例句、无关的细节。有时将一段描述性文字总结成一个要点列表能极大提升模型的理解效率。指令与背景分离Instruction-Context Separation明确区分“你要模型做什么”指令和“你给模型提供了什么信息”背景/上下文。清晰的指令应该放在最前面或最后面并用特殊格式标出。举个例子如果你想让模型根据一份用户需求文档写API接口代码差的上下文是把整份需求文档可能包含项目愿景、UI描述等直接粘贴进去。好的上下文工程则是## 指令 请根据以下“用户信息管理”模块的需求生成对应的Python Flask API接口代码。 ## 核心需求摘要 1. 用户注册需邮箱、密码、用户名。 2. 用户登录邮箱密码验证返回JWT令牌。 3. 查询用户信息根据用户ID查询仅管理员可访问。 ## 详细约束来自需求文档第3.2节 - 密码需加密存储使用bcrypt。 - JWT令牌有效期24小时。 - 用户信息查询接口需要‘admin’权限。 - 数据库表结构预定义如下SQL片段...这种方式将指令、摘要、详细约束分层呈现模型能快速抓住重点无需在冗长文档中自行搜寻。3. 关键技术详解超越基础的RAG理解了核心思路我们来看看实现这些思路的具体技术。它们共同构成了现代上下文工程的工具箱。3.1 智能检索与召回优化基础的向量相似度检索是起点但远非终点。为了提升召回内容的相关性和完整性需要引入更多策略混合检索Hybrid Search结合稠密向量检索理解语义和稀疏词项检索如BM25保证关键词匹配。例如用户问“Python里怎么处理列表去重”向量检索可能找到关于“集合(Set)特性”的段落而BM25能确保召回包含“Python”、“列表”、“去重”这些关键词的精确示例代码。用langchain的EnsembleRetriever可以轻松实现。查询重写Query Rewriting在检索前先用一个小型LLM如GPT-3.5-turbo对用户原始查询进行扩展或改写。例如将“它怎么工作的”在聊天历史背景下重写为“解释OAuth 2.0授权码流程的工作原理”。这能显著提升检索的准确性。多跳检索Multi-Hop Retrieval对于复杂问题进行多轮检索。第一轮检索到的文档可能包含需要进一步查询的实体或概念据此发起第二轮、第三轮检索像侦探破案一样层层深入最终组装出完整的上下文。这通常需要借助Agent的思维链能力。实操心得不要盲目追求最先进的向量模型。对于中文场景bge-large-zh或text2vec系列通常是比通用模型更好的起点。检索时适当调低相似度阈值比如从0.7调到0.65并用MMR最大边际相关性算法对结果进行去重和多样性排序往往比只取前k个相似片段效果更好。3.2 上下文压缩与摘要当检索回来的文档仍然太长时必须进行压缩。这里有几个层级抽取式摘要直接提取原文中最重要的句子或片段。可以用无监督算法如TextRank也可以用小型LLM进行指令提取“请从以下文本中提取与‘故障排除’相关的所有步骤”。抽象式摘要用LLM重新组织语言概括核心意思。这对于整合多个来源的信息、消除冗余特别有效。指令可以设计为“请用一段话概括以下三份文档关于‘项目风险评估’的共同核心观点。”选择性上下文这是更精细的策略。不是总结整个文档而是根据当前问题从文档中抽取出相关的信息点。例如面对一份产品说明书当用户问“保修期多久”时上下文工程不是放入整个“售后服务”章节而是精准地提取出“保修期24个月”这个信息点。一个实用的技巧是分层摘要先对每个独立文档生成一个简短摘要如果上下文窗口还有空间再选择性地加入关键文档的详细内容。3.3 上下文的结构化与编排这是将“原材料”加工成“美味佳肴”的关键一步。好的编排能极大降低模型的认知负荷。使用明确的格式标记system_prompt 你是一个资深Python开发助手擅长编写简洁、高效的代码。 /system_prompt user_query 如何用Pandas读取一个大的CSV文件并分块处理 /user_query relevant_documentation [来自Pandas官方文档] pandas.read_csv 参数 chunksize指定一个整数值函数将返回一个可迭代的TextFileReader对象... [来自Stack Overflow高赞回答] 对于内存不足的情况使用chunksize并配合循环是标准做法... /relevant_documentation additional_constraints 请给出一个完整的、可运行的代码示例。假设文件名为‘data.csv’。 /additional_constraints这种结构让模型一目了然。提供少样本示例Few-Shot Examples在上下文中直接放入1-3个“问题-答案”对作为示范是引导模型输出格式和风格的最强信号。示例必须高质量、精准匹配当前任务类型。动态上下文管理在多轮对话中上下文是累积的。需要一套策略来决定哪些历史对话应该保留、哪些可以丢弃或总结。常见策略有滑动窗口只保留最近N轮对话。关键记忆提取用LLM总结对话历史中的关键决策、用户偏好或事实信息将长篇历史压缩成几个要点放入当前上下文。基于重要性的筛选给每轮对话打上重要性标签如包含关键事实高寒暄低优先保留高重要性内容。3.4 长上下文模型的特殊处理随着Claude-3-200k、GPT-4 Turbo 128k等支持超长上下文窗口的模型出现新的挑战和机遇也随之而来。挑战直接将数百页文档扔给模型效果很可能不如精心准备的简短上下文。模型可能会“迷失”在信息海洋中性能反而下降。机遇我们可以放入更完整、更丰富的背景信息减少因信息切割导致的失真。最佳实践即使窗口很长也应遵循“结构化”原则。为超长文档提供一个详细的目录或索引放在上下文开头告诉模型文档的组织结构。在提问时甚至可以引用“请参考文档第3章第2节关于API限流的描述”帮助模型定位。本质上你是在为模型创建一个内部的“导航系统”。4. 实战架构与工具链搭建理论说再多不如看一个实际的架构。假设我们要构建一个“智能技术文档助手”它能够回答关于某个大型软件项目如Redis的复杂技术问题。以下是基于上下文工程的完整实现思路。4.1 系统架构设计一个健壮的上下文工程系统通常包含以下流水线模块用户输入 ↓ [查询理解与重写模块] (小型LLM) ↓ 改写后的查询 ↓ ↓-------------------↓ [混合检索器] [元数据过滤器] (向量库 全文检索引擎) (按文档类型、版本等过滤) ↓-------------------↓ 初步召回文档集 ↓ [重排序器 去重器] (使用LLM或交叉编码器评估相关性) ↓ 精排文档列表 ↓ [上下文构建器] (执行摘要、压缩、结构化编排) ↓ 最终优化后的上下文 ↓ [大模型LLM] ↓ 最终答案4.2 工具链选型与配置以下是一个基于开源技术的推荐工具栈嵌入与向量库嵌入模型BAAI/bge-large-zh-v1.5中文优或text-embedding-3-smallAPI调用。向量数据库Chroma轻量、易用、Qdrant高性能、云原生或Weaviate功能丰富自带向量化模块。对于千万级文档Milvus或Elasticsearch7.x后支持向量是生产级选择。检索与编排框架LangChain/LangGraph生态丰富组件多适合快速原型验证。但有时抽象层次较高对精细控制不友好。LlamaIndex专为RAG设计对文档加载、索引、检索的抽象更直接在复杂查询和上下文优化方面有独特优势。自研流水线对于高定制化需求我建议用FastAPI构建微服务用Redis缓存中间结果自己控制每一步。这能给你最大的灵活性和调试能力。摘要与压缩模型对于关键但不需全文的压缩可以使用较小的开源模型如Qwen1.5-7B-Chat或ChatGLM3-6B专门用于执行“总结”、“提取”等指令。为降低成本可以将这些任务卸载到专门的模型推理服务上。配置要点向量检索的top_k值召回数量需要根据上下文窗口大小动态调整。一个经验公式是可用token数 / (平均文档片段token数 * 安全系数)。安全系数通常取2-3为指令和模型输出留出空间。例如窗口8000token平均片段500token那么top_k初始可设为8000/(500*2) 8。4.3 一个完整的上下文组装示例假设用户提问“在Redis集群中如何安全地进行主从切换”经过检索、重排、压缩后上下文构建器可能组装出如下内容role 你是Redis数据库专家负责提供准确、可操作的生产环境建议。 /role user_question 在Redis Cluster模式下当某个主节点疑似故障时如何安全地进行手动主从切换以确保服务高可用并最小化数据丢失风险 /user_question background_knowledge * Redis Cluster采用去中心化架构数据分片存储在多个主节点上每个主节点有1个或多个从节点。 * “疑似故障”可能由网络分区、节点负载过高导致心跳超时等原因引起需与真实故障区分。 * 手动切换优于盲目依赖自动故障转移尤其在网络不稳定时。 /background_knowledge retrieved_core_information 1. 【来自Redis官方文档 - 集群管理】CLUSTER FAILOVER命令在目标从节点上执行可发起一次手动故障转移。使用FORCE选项可强制切换即使主节点未失联但可能导致数据丢失。使用TAKEOVER选项更激进则完全忽略集群一致性验证。 2. 【来自Redis运维手册 - 最佳实践】手动切换前必须执行的检查清单 a) 确认集群状态 (CLUSTER INFO): cluster_state 应为 ok。 b) 确认主从复制状态 (INFO replication): 目标从节点的 master_link_status 应为 up且 master_repl_offset 与主节点接近。 c) 监控网络延迟和节点负载。 3. 【来自故障排查案例】一次因未检查复制偏移量导致的切换后数据不一致事故切换后新主节点缺失最近约1000条写入命令。 /retrieved_core_information step_by_step_instruction 请按照以下逻辑生成回答 1. 首先强调手动切换的前提条件和风险警告。 2. 然后以清晰的步骤列表形式给出从“决策”到“验证”的完整操作流程。 3. 在关键步骤后用“ 注意”的格式插入从检索信息中提炼出的核心警告或技巧。 4. 最后给出切换成功后对旧主节点的建议处理方式。 /step_by_step_instruction这样的上下文不仅提供了答案所需的“原材料”检索信息还通过背景知识、结构化指令极大地约束和引导了模型的思考方向使其产出高质量、可执行的回答。5. 高级模式与前沿探索当基础玩法掌握后可以尝试一些更高级的上下文工程模式它们能解决更复杂的问题。5.1 思维链CoT与自洽性Self-Consistency的上下文实现对于复杂的数学、推理或规划问题仅仅提供事实上下文不够还需要引导模型的思考过程。在上下文中植入CoT示例这是最有效的方法。在few_shot_examples部分不仅提供问题答案更提供推理步骤。示例问题一个篮子里有5个苹果你拿走了2个又放进去3个梨现在篮子里有多少个水果 示例推理首先拿走2个苹果后苹果数量是5-23个。然后加入3个梨。水果总数是苹果(3个) 梨(3个) 6个。所以答案是6。当模型看到这样的示例后在处理类似复杂问题时会更倾向于先输出推理步骤。要求模型分步思考在指令中明确要求“请一步步思考并给出最终答案”。对于某些模型如Claude这能有效触发其链式推理能力。实现自洽性对于极其重要的问题可以要求模型对同一个问题在稍作变化的上下文下例如重述问题、调整示例顺序生成多个答案然后从中选择最一致或投票最多的那个。这需要在应用层设计多轮调用和结果聚合逻辑。5.2 基于递归的“大纲-细节”上下文加载这是处理超长文档如一本书、一份长报告的利器。核心思想是模仿人类阅读先看目录了解结构再按需深入章节。第一层上下文大纲将整个文档的章节标题、摘要、核心结论提取出来形成一个高度浓缩的“大纲上下文”。模型导航用户提问。模型基于“大纲上下文”判断问题属于哪个或哪几个章节。递归加载系统根据模型的判断动态地将相关章节的详细内容作为新的上下文加载进来替换或追加到原有上下文中让模型基于更详细的信息做出最终回答。这种方式能极大地扩展有效上下文范围但实现复杂度较高需要模型具备一定的自我定位和需求澄清能力。5.3 上下文与工具函数调用的协同在AI Agent场景中上下文不仅包含知识还包含可用的工具API函数描述。如何组织这类上下文至关重要。工具描述结构化不要简单罗列函数签名。为每个工具提供清晰的名称、功能描述、参数说明类型、含义、示例和返回值的意义。{ tools: [ { type: function, function: { name: get_weather, description: 获取指定城市当前天气情况。, parameters: { type: object, properties: { location: { type: string, description: 城市名称如‘北京’、‘New York’。 } }, required: [location] } } } ] }在对话历史中记录工具调用结果当模型决定调用工具后工具返回的结果必须作为上下文的一部分反馈给模型进行后续分析。这通常以系统消息的形式追加例如[工具get_weather调用结果北京晴25摄氏度。]。通过上下文控制工具使用频率如果发现模型过度依赖或回避使用工具可以在系统指令中通过上下文进行调整。例如“你应当优先尝试自己推理。仅当需要实时数据如天气、股价或无法计算时如复杂数学才使用工具。”6. 避坑指南与性能调优在这一部分我分享一些从真实项目中踩坑换来的经验这些在官方文档里很少会提到。6.1 常见陷阱与解决方案陷阱现象可能原因解决方案模型回答“根据上下文…”但上下文里根本没有。1. 上下文过长模型出现“幻觉”。2. 指令不明确模型在“创造”答案。1. 压缩上下文确保关键信息在模型注意力范围内。2. 强化指令“仅依据提供的上下文回答如果上下文没有请明确说‘根据提供的信息无法回答’。”模型忽略了上下文中的关键信息。关键信息被淹没在大量文本中或位置不佳如靠近中间。1.位置很重要将最关键的信息如约束条件、核心定义放在上下文的最开头或最末尾。2.重复强调对核心信息可以用不同方式在上下文中提及两次。多轮对话后模型忘记了几轮前的重要设定。简单的滑动窗口丢弃了早期关键对话。引入“长期记忆”机制用一个小型总结模型将对话中的关键事实、用户偏好提取出来作为一个永久或半永久的“系统备注”注入到每一轮的新上下文中。检索到的上下文片段相互矛盾。知识库本身存在不一致或检索策略召回过多无关内容。1. 在检索后增加一个一致性校验步骤用LLM快速判断多个片段是否冲突并选择最可信的一个或要求用户澄清。2. 在上下文中明确告诉模型“以下是来自不同来源的信息请谨慎甄别并综合判断。”处理速度慢响应延迟高。1. 检索和上下文构建流程复杂。2. 上下文过长模型推理耗时剧增。1.异步与缓存将文档处理、向量化、摘要生成等耗时操作离线进行并缓存。检索过程异步化。2.分级响应对于简单问题使用更小的模型和更短的上下文快速响应。复杂问题再走完整流水线。6.2 成本与性能的平衡术上下文工程直接关联着API调用成本尤其是按Token收费的模型和响应速度。Token消耗分析上下文Token数 系统指令 对话历史压缩后 检索上下文 用户当前问题。其中检索上下文通常是最大的变量。务必监控平均每次调用消耗的Token数。成本控制策略摘要摘要再摘要对检索结果进行激进但准确的摘要是降低成本最有效的手段。小模型干脏活用低成本的小模型如Qwen1.5-1.8B处理查询重写、初步摘要、相关性评分等任务只在最终生成答案时调用大模型。设置上下文预算为每次交互设定一个硬性的Token上限如4000 Tokens所有组件检索、历史管理都必须在这个预算内工作。延迟优化并行化向量检索、关键词检索、元数据过滤可以并行执行。预计算文档的向量、摘要、关键元数据都可以在入库时预计算好。流式输出对于生成式回答务必启用API的流式输出streaming让用户能尽快看到首个Token提升体验。6.3 评估上下文工程的效果如何知道你的上下文工程做得好不好不能只靠感觉。人工评估黄金标准构建一个包含各种问题类型的测试集由专家评判答案的准确性、相关性和完整性。这是最可靠但成本最高的方法。自动化代理评估使用一个更强的LLM如GPT-4作为“裁判”根据标准问题、提供的上下文和模型答案从“是否基于上下文”、“是否准确”、“是否全面”等维度进行打分。虽然不完全可靠但可以快速进行大量测试。关键指标监控答案引用率模型答案中明确引用或复述上下文具体内容的比例。过低可能意味着上下文没用上过高可能意味着缺乏概括。幻觉率答案中出现上下文未提供信息的比例。用户满意度通过“点赞/点踩”或后续对话轮次等隐式反馈来衡量。平均交互Token数监控成本变化。说到底上下文工程没有银弹。它是一项需要持续迭代、紧密结合具体业务场景进行调优的工作。从简单的Prompt拼接到智能检索、动态压缩、结构化编排每一步的优化都能带来应用效果的显著提升。最深刻的体会是与其追求更庞大的模型不如先打磨好你喂给模型的每一段“食粮”。很多时候一个经过精心设计的上下文搭配一个中等规模的模型其效果远胜于一个庞大但上下文混乱的顶级模型。