上下文工程实战：长上下文时代RAG并未过时，而是进化了

上一篇AI Agent产业化加速从概念验证到规模化部署的挑战与机遇下一篇OpenClaw三维设计哲学×AI Agent框架选型2026全景摘要GPT-6带来200万Token的超长上下文有人说RAG死了——把整本知识库塞进去不就行了但事实是长上下文解决了能装多少的问题却没有解决能稳定用好多少的问题。2026年上下文工程Context Engineering已从RAG的升级版演变为独立学科涵盖信息检索、上下文压缩、记忆管理、多层次知识组织等核心技术。本文基于中科算网《2026大模型上下文工程指南》和最新工程实践系统讲解长上下文时代的RAG进化路径与工程落地方案。核心结论长上下文是RAG的升维竞争对手而非终结者。在2026年最佳实践是RAG筛选相关片段 长上下文做深度推理的协同模式而非二选一。Context Engineering的本质是在有限的Token预算内最大化放入最有用的上下文。一、为什么200万Token的上下文不能取代RAG1.1 长上下文的四个根本局限局限1注意力稀释Lost in the Middle斯坦福大学AI Lab的研究2025年发现当关键信息被放在100万Token上下文的中间位置时模型的检索准确率比放在开头或结尾低约40%。即使模型能看到所有内容也不等于能平等地注意到所有内容。上下文位置 vs 检索准确率200K Token测试: 开头 (0-10%) ██████████ 91% 中前 (10-30%) ████████ 79% 中间 (30-70%) █████ 64% 中后 (70-90%) ████████ 77% 末尾 (90-100%)█████████ 87%局限2幻觉与上下文污染当知识库中存在矛盾信息时长上下文模型有时会将多个矛盾说法综合成一个看似合理但实际错误的答案而传统RAG通过精确检索可以更好地控制信息源。局限3推理成本线性增长以GPT-6为例$2.5/M输入Token的定价下1万Token查询$0.025可接受100万Token$2.5单次调用200万Token$5.0单次调用对于每天需要处理数千次查询的企业应用200万Token的成本是不可承受的。局限4私有数据实时性长上下文只能处理已有文档无法解决每日更新的数据库库存、股价、CRM数据实时生产环境状态访问控制权限管理不同用户看到不同信息1.2 RAG已死论的反驳一篇广泛流传的文章《长上下文模型并非万能为什么到了2026年RAG仍然必要》来源synthly.cn2026-03-07从四个维度给出了清晰反驳论点长上下文支持者的说法反驳成本模型价格持续下降知识库规模增长更快成本问题依然存在准确率模型越来越强Lost in the Middle问题是注意力机制的固有特性实时性可以加上搜索工具这本质上已经是RAG了溯源模型可以引用原文长上下文下溯源精度远低于精确检索的RAG二、什么是上下文工程Context Engineering2.1 权威定义什么是上下文工程Context Engineering上下文工程是研究如何在大语言模型的上下文窗口中组织、筛选、压缩和管理信息以最大化模型输出质量的工程学科。它超越了传统Prompt Engineering提示工程的范畴将检索增强生成RAG、记忆管理、上下文压缩、工具结果过滤等技术统一到同一框架下。——中科算网《2026大模型上下文工程指南》2026-03-132.2 上下文工程的四层架构┌─────────────────────────────────────────────────────┐ │ Layer 4: 管理层 │ │ Token预算管理 / 上下文压缩 / 遗忘机制 │ ├─────────────────────────────────────────────────────┤ │ Layer 3: 记忆层 │ │ 短期记忆(当前对话) / 中期记忆(Session) / 长期记忆(DB) │ ├─────────────────────────────────────────────────────┤ │ Layer 2: 检索层 │ │ 向量检索 / 关键词检索 / 图检索 / 多路召回融合 │ ├─────────────────────────────────────────────────────┤ │ Layer 1: 组织层 │ │ 文档解析 / 分块策略 / 知识图谱构建 / 索引管理 │ └─────────────────────────────────────────────────────┘ ↓ [LLM上下文窗口] (200万Token)2.3 为什么需要工程思维传统RAG是给模型找答案上下文工程是帮模型思考维度传统RAG上下文工程核心目标找到相关文档构建最优推理上下文信息来源向量数据库多源检索记忆工具结果历史质量评估检索准确率最终输出质量Token效率更新频率文档更新时实时动态调整压缩策略无主动压缩摘要优先级排序三、RAG的进化路径从管道到循环3.1 第一代Linear RAG线性管道用户问题 → [向量检索] → [Top-K文档] → [LLM生成] → 输出问题一次检索结果好坏全看第一步的检索质量。问题稍有歧义检索就会跑偏。3.2 第二代Modular RAG模块化RAG将RAG拆解为可替换的模块支持多路检索向量关键词知识图谱重排序Reranker查询改写Query Rewriting问题虽然模块化了但依然是线性流程不支持迭代和自我纠错。3.3 第三代Agentic RAG智能体RAG2026年主流方案将RAG嵌入Agent的决策循环classAgenticRAG:def__init__(self,llm,retriever,memory):self.llmllm self.retrieverretriever self.memorymemory self.max_iterations5asyncdefanswer(self,question:str)-str:context[]iterations0whileiterationsself.max_iterations:# Step 1: LLM判断是否需要检索decisionawaitself.llm.decide(questionquestion,current_contextcontext,prompt基于当前信息你能回答问题吗如果不能请生成搜索查询。)ifdecision.can_answer:# 已有足够信息生成最终答案returnawaitself.llm.generate(questionquestion,contextcontext)# Step 2: 执行检索search_resultsawaitself.retriever.search(querydecision.search_query,top_k5)# Step 3: 评估检索结果的相关性relevant_chunksawaitself.llm.filter_relevant(questionquestion,candidatessearch_results)# Step 4: 更新上下文context.extend(relevant_chunks)# Step 5: 检查上下文是否已足够充分ifawaitself.llm.is_context_sufficient(question,context):breakiterations1# 超过最大迭代次数生成基于现有信息的答案returnawaitself.llm.generate(questionquestion,contextcontext,note信息可能不完整请标注不确定性)Agentic RAG的关键特性迭代检索不满意就继续搜直到找到足够信息自我评估模型判断当前信息是否足够回答问题查询进化每次检索后基于已有信息优化下一次查询3.4 第四代GraphRAG图增强RAG适用场景需要多跳推理A与B有关系B与C有关系推理A与C的关系的复杂查询。fromgraphragimportGraphRAGPipeline# 构建知识图谱索引pipelineGraphRAGPipeline(documentsdocs,entity_extractorglm-5-turbo,# 提取实体和关系graph_backendneo4j)# 多跳推理查询resultawaitpipeline.query(这家公司的主要投资人与哪些其他科技公司有合作关系,modeglobal,# 全局推理模式综合图结构信息max_hops3# 最大推理跳数)场景推荐方案理由单文档问答直接长上下文文档不大无需检索知识库问答10万TokenLinear/Modular RAG够用且简单复杂多跳推理GraphRAG实体关系推理更准确动态实时数据Agentic RAG支持实时工具调用超大知识库100万TokenAgentic RAG 长上下文融合最佳实践四、长上下文与RAG的协同模式4.1 先筛后读的最优范式2026年最佳实践已经形成共识——“RAG筛选相关片段 长上下文做深度推理”用户问题 ↓ [Stage 1: RAG精确筛选] 向量检索 关键词检索 重排序 目标从100万Token知识库中筛出最相关的5-10K Token ↓ [Stage 2: 长上下文深度推理] 将筛选出的5-10K Token 用户问题 对话历史 送入GPT-6/Qwen3.6-Plus做深度推理 利用长上下文处理多个片段间的复杂关系 ↓ [Stage 3: 可信度验证] 引用源文检验标注不确定性 ↓ 最终输出4.2 上下文压缩策略当上下文超出预算时需要主动压缩fromcontextlibimportasynccontextmanagerimporttiktokenclassContextCompressor:上下文压缩器在Token预算内最大化信息密度def__init__(self,max_tokens:int8000,model:strgpt-6):self.max_tokensmax_tokens self.encodertiktoken.encoding_for_model(model)defcount_tokens(self,text:str)-int:returnlen(self.encoder.encode(text))asyncdefcompress(self,chunks:list[str],question:str,strategy:strrelevance_first)-str: 策略说明 - relevance_first: 优先保留与问题最相关的内容 - recency_first: 优先保留最新的内容 - diversity_first: 最大化信息多样性 total_tokenssum(self.count_tokens(c)forcinchunks)iftotal_tokensself.max_tokens:return\n\n.join(chunks)ifstrategyrelevance_first:# 对每个chunk计算相关性分数scored_chunks[]forchunkinchunks:scoreawaitself._compute_relevance(chunk,question)tokensself.count_tokens(chunk)scored_chunks.append((score,tokens,chunk))# 按相关性排序贪心选取scored_chunks.sort(reverseTrue)selected[]used_tokens0forscore,tokens,chunkinscored_chunks:ifused_tokenstokensself.max_tokens:selected.append(chunk)used_tokenstokenselse:# 如果整块放不下考虑截断remainingself.max_tokens-used_tokensifremaining200:# 至少保留200 Tokentruncatedself._truncate_chunk(chunk,remaining)selected.append(truncated)breakreturn\n\n.join(selected)4.3 上下文质量评估生产环境中需要自动评估检索结果的质量classContextQualityEvaluator:上下文质量自动评估器asyncdefevaluate(self,question:str,context:str,llm_judge:strqwen3.6-plus)-dict:promptf 请评估以下检索上下文对于回答问题的质量 问题{question}上下文{context}请从以下维度评分1-5分 1. 相关性上下文与问题的相关程度 2. 完整性上下文是否包含回答问题所需的全部信息 3. 准确性上下文信息是否可靠 4. 简洁性是否有大量冗余信息 以JSON格式返回评分和建议。 resultawaitself.llm.generate(prompt,modelllm_judge)scoresjson.loads(result)# 综合分数低于3分时建议重新检索overallsum(scores.values())/len(scores)scores[overall]overall scores[should_retry]overall3.0returnscores五、2026年上下文工程技术栈选型5.1 向量数据库选型数据库适用场景优势劣势Qdrant生产级RAG系统过滤性能强Rust实现云原生生态不如Pinecone成熟Pinecone快速原型到生产托管服务简单易用成本较高数据留在第三方Weaviate多模态 图结构原生支持向量图混合查询配置复杂ChromaDB本地开发/测试零配置开源免费生产规模有限PGVector已有PostgreSQL的项目无需额外数据库ACID事务向量性能弱于专用方案5.2 完整RAG技术栈示例# 2026年推荐的生产级RAG技术栈# 文档解析fromdoclingimportDocumentConverter# 企业级文档解析fromunstructuredimportpartition_pdf# 备选复杂PDF解析# 分块策略fromllama_indeximportSemanticSplitter# 语义分块推荐fromlangchain.text_splitterimportRecursiveCharacterTextSplitter# 递归分块# 嵌入模型fromopenaiimportAsyncOpenAI# text-embedding-3-largefromsentence_transformersimportSentenceTransformer# 本地嵌入# 向量数据库fromqdrant_clientimportAsyncQdrantClient# 生产推荐# 重排序fromFlagEmbeddingimportFlagReranker# BGE重排序模型# LLMfromanthropicimportAsyncAnthropic# Claude Sonnet 4.6最佳质量fromopenaiimportAsyncOpenAI# GPT-6超长上下文# 编排框架fromllama_index.coreimportVectorStoreIndex# RAG管道fromlanggraphimportStateGraph# Agentic RAG工作流# 可观测性importlangfuse# RAG全链路追踪5.3 性能基准2026年主流方案对比方案检索准确率BEIR推理延迟成本/万次查询Linear RAG text-embedding-3~62%~800ms~$5Modular RAG BGE-M3 Reranker~71%~1.2s~$8Agentic RAG单次迭代~78%~2.5s~$15Agentic RAG多轮迭代~85%~8s~$45GraphRAG多跳查询~83%~5s~$30RAG 长上下文融合~88%~4s~$25六、工程实践避坑指南6.1 分块策略的常见错误错误1固定大小分块切断语义# ❌ 错误按固定字符数切分容易截断一个完整的论证或代码块splitterCharacterTextSplitter(chunk_size500)# ✅ 正确语义分块保持完整的语义单元splitterSemanticSplitter(embed_modelembedding_model,breakpoint_percentile_threshold95# 语义相似度低于5%的地方才分块)错误2忽略文档结构# ✅ 结构感知分块保留标题层级信息defstructure_aware_chunking(document:Document)-list[Chunk]:chunks[]forsectionindocument.sections:# 将标题信息注入每个chunkforparainsection.paragraphs:chunkChunk(textpara.text,metadata{title:section.title,# 所属章节标题document:document.name,# 所属文档page:para.page_number,# 页码heading_path:section.heading_path# 完整标题路径})chunks.append(chunk)returnchunks6.2 查询改写提升召回率asyncdefmulti_query_retrieval(question:str,retriever,n_variants:int3)-list[str]:生成多个问题变体提升检索覆盖率promptf 原始问题{question}请生成{n_variants}个语义相同但表达不同的变体问题 用于提升文档检索的召回率。每行一个问题。 variants_textawaitllm.generate(prompt)variants[question]variants_text.strip().split(\n)# 并行检索所有变体all_resultsawaitasyncio.gather(*[retriever.search(q,top_k3)forqinvariants])# 去重合并用RRF融合排名returnreciprocal_rank_fusion(all_results)6.3 可观测性追踪每一次检索生产环境中RAG系统必须有完整的可观测性importlangfusefromlangfuse.decoratorsimportobserve,langfuse_context lflangfuse.Langfuse()observe(as_typegeneration)asyncdefrag_pipeline(question:str,user_id:str)-str:带完整追踪的RAG管道# 追踪检索阶段langfuse_context.update_current_observation(metadata{user_id:user_id,question:question})# 检索chunksawaitretriever.search(question,top_k5)langfuse_context.update_current_observation(metadata{retrieved_chunks:len(chunks),top_score:chunks[0].scoreifchunkselse0})# 生成answerawaitllm.generate(question,contextchunks)# 记录最终指标langfuse_context.score_current_trace(namecontext_relevance,valueawaitevaluate_relevance(question,chunks))returnanswerFAQQ12026年应该用哪个向量数据库A生产环境首推Qdrant高性能、强过滤、云原生如果项目已有PostgreSQL可用PGVector省去额外部署快速原型用ChromaDB。企业级托管方案选Pinecone。不建议在生产中使用FAISS无持久化、无过滤、无扩展。Q2长上下文模型出现后还需要做分块吗A仍然需要理由有三1成本控制——把整个知识库塞进去成本极高2召回精度——即使有200万Token用RAG先筛选相关片段仍能提高答案准确率3实时数据——长上下文无法处理动态更新的数据库。Q3Agentic RAG与传统RAG的核心区别是什么A传统RAG是一次检索、一次生成的线性管道Agentic RAG将LLM嵌入到决策循环中支持迭代检索、自我评估、查询优化。当第一次检索结果不够好时Agentic RAG会自动优化查询并重新检索直到获得足够信息。Q4GraphRAG适合什么场景AGraphRAG最适合需要多跳推理的场景例如企业知识图谱A公司→投资→B公司→合作→C项目的链式查询、医学文献疾病→机制→靶点→药物的关系推理、法律文档法条→解释→案例→判决的推理链。对于简单的单文档问答GraphRAG的建图成本高于收益。Q5上下文工程中的Token预算如何设置A经验法则将可用Token预算的40%给检索内容20%给历史对话20%给系统提示剩余20%作为输出预算。对于一个8K Token的上下文3200 Token给检索结果1600 Token给对话历史1600 Token给系统提示1600 Token用于输出。参考资料《大模型上下文工程Context Engineering指南》正式发布中科算网算泥社区2026-03-13长上下文模型并非万能为什么到了2026年RAG仍然必要synthly.cn2026-03-072026年RAG技术演进从向量检索到GraphRAG与AgenticRAG大模型技术专栏2026-04-02文献综述A Survey of Context Engineering for Large Language Models知乎2025-10-28从RAG到Context Engineering大语言模型时代的完整指南blog.hehouhui.cn2025-09-02搞懂上下文工程Context Engineering让你的LLM更聪明53AI2025-08-052026大模型上下文工程Context Engineering指南中科算网2026-03-19上一篇AI Agent产业化加速从概念验证到规模化部署的挑战与机遇下一篇OpenClaw三维设计哲学×AI Agent框架选型2026全景