1. 项目概述从“提示工程”到“上下文工程”的范式跃迁如果你和我一样在过去两年里深度参与了LLM应用开发那么“提示工程”Prompt Engineering这个词你一定不陌生。我们曾花费大量时间像炼金术士一样精心雕琢每一句指令、每一个示例试图从模型里“压榨”出更精准、更稳定的回答。这确实有效尤其是在处理单轮、定义明确的问答时。但当我们试图构建一个能处理复杂业务流程、能记住用户偏好、能从海量企业知识库中精准定位信息的“企业级AI大脑”时问题就来了。你会发现无论提示词写得多么精妙模型依然会“一本正经地胡说八道”或者对几分钟前刚讨论过的事情“失忆”。问题的根源往往不在于模型本身而在于我们喂给它的“上下文”出了问题。这就是“上下文工程”Context Engineering要解决的核心命题。它不再仅仅关注“如何问”而是系统性地解决“给什么”和“怎么给”的问题。你可以把它理解为为LLM这个强大的“大脑”构建一套高效、精准、结构化的“感官系统”和“记忆系统”。我的亲身经历是在一个金融合规问答项目中仅仅通过优化上下文管理策略——包括更智能的检索、更有效的记忆注入和更合理的上下文窗口编排——就将系统的回答准确率从68%提升到了92%幻觉率从15%降到了3%以下。这种提升不是线性的而是质变。简单来说上下文工程是一套方法论和技术的集合旨在为LLM的每一次推理动态地组装、管理和优化其所能接触到的所有信息。这些信息包括实时检索到的外部知识、历史对话的摘要、用户的个人偏好、可调用工具的描述、以及任务执行的中间状态等。它的目标是确保模型在“思考”时拥有完成当前任务所需的全部、且最相关的“背景信息”从而做出更可靠、更一致的决策。接下来我将结合多个实战项目为你拆解上下文工程的完整体系。2. 核心架构解析构建企业级AI的“信息中枢”一个健壮的上下文工程系统绝非简单的“检索拼接”。它是一个分层、解耦的架构每一层都有其明确的职责和最佳实践。我通常将其划分为四个核心支柱它们共同构成了LLM应用的“信息中枢”。2.1 知识检索层从“大海捞针”到“精准制导”知识检索层是上下文工程的基石负责从外部知识源文档、数据库、API中实时查找相关信息。早期的“朴素RAG”Naive RAG存在明显缺陷固定长度的文本分块常常割裂语义简单的向量相似度检索可能召回不相关的内容缺乏对检索结果的验证机制。实战演进三代RAG架构对比在我的项目中RAG的演进清晰地反映了我们对“精准”的追求第一代朴素RAG (2023年初)模式文档→固定长度分块→向量化→存入向量数据库→用户查询时进行Top-K相似度检索→结果直接拼接给LLM。痛点回答质量极不稳定。当用户问“我们公司第三季度的销售政策有什么变化”时系统可能检索到“第一季度销售政策”、“第三季度财报摘要”等不完整或无关的片段导致模型生成混淆或错误的答案。教训语义分块是关键。我们后来转向了基于句子边界、段落或章节的“语义分块”并引入了10-15%的重叠保证了上下文的连贯性。第二代高级RAG (2023-2024年)核心增强引入了查询改写、混合搜索、重排序等环节。查询改写LLM将原始用户问题“销售政策变了吗”改写成更利于检索的“2024年Q3销售政策修订内容”或“销售政策最新版本”。混合搜索结合向量搜索语义和关键词搜索如BM25。例如搜索“API速率限制”向量搜索能找到“接口调用频次控制”而关键词搜索能精准命中包含“API”、“速率”、“限制”字样的文档段落。两者结果融合后重排序召回率显著提升。工具链这个阶段我们重度依赖LangChain和LlamaIndex。它们提供了可插拔的模块让我们能快速搭建管道。例如使用LlamaIndex的SentenceSplitter进行智能分块用CohereRerank对检索结果进行重排序。第三代智能体化RAG (2024年至今)范式转变RAG不再是一个被动的管道而是一个由LLM驱动的、具备规划、反思和决策能力的智能体。这是当前企业级项目的标配思路。工作流程路由判断LLM首先判断用户问题是否需要检索外部知识。例如“今天天气怎么样”可能直接调用天气API而无需检索知识库。多源检索规划如果需要检索LLM决定检索哪些来源。是向量数据库还是知识图谱GraphRAG或是需要调用某个内部API查询结构化数据例如“找出去年Q4表现最好的产品及其负责团队”可能需要同时检索销售数据API和产品文档向量库。迭代检索与验证LLM评估首次检索结果是否充分。如果不够它会自主改写查询或调整检索策略进行二次、三次检索直到获得满意信息。生成后验证LLM生成答案后会再次检查答案是否与提供的检索来源一致是否存在幻觉。如果发现矛盾则触发“反思”机制重新检索或修正答案。GraphRAG的引入对于需要“全局洞察”的问题传统向量RAG显得力不从心。比如“公司近两年在可持续发展方面有哪些关键举措它们之间有何关联”。微软提出的GraphRAG技术通过从文档中自动提取实体和关系构建知识图谱并能对图谱中的社区进行摘要非常适合回答这类需要跨文档推理的开放性问题。我们在一个竞品分析项目中将向量RAG与GraphRAG结合前者处理具体产品参数查询后者分析市场趋势和竞争格局效果拔群。实操心得不要盲目追求最复杂的Agentic RAG。对于简单、明确的文档问答Advanced RAG已经足够。引入Agentic RAG会显著增加复杂度和延迟。决策的关键在于问题的“开放性”和“推理步骤”。我的经验法则是如果一个问题可以通过在单一文档中查找一句话来回答用Advanced RAG如果需要串联多个文档中的信息并进行归纳、对比或推理则必须上Agentic RAG。2.2 记忆管理层赋予AI“持续对话”的能力默认情况下LLM是“金鱼脑”没有记忆。记忆管理层的目标就是打破这个限制让AI能记住对话历史、用户偏好甚至从过去的错误中学习。三层记忆模型实战我参考了学术研究并加以工程化设计了以下三层记忆架构在多轮对话助理项目中取得了很好效果工作记忆 (Working Memory)是什么相当于LLM当前上下文窗口里的内容。这是最“热”、最昂贵的数据。管理策略不能无脑地把所有历史对话都塞进去。我们采用“滑动窗口摘要”策略。保留最近3-5轮完整对话对于更早的对话则用LLM生成一个简短的摘要例如“用户之前咨询了关于VPN报销的政策已告知需部门领导审批”然后将摘要而非原始对话放入上下文。这大大节省了Token并保留了关键信息。情节记忆 (Episodic Memory)是什么存储在外部数据库如Redis或PostgreSQL中的过去对话“经历”。如何工作每次对话结束时系统自动生成本次对话的摘要和关键点例如“用户偏好用Markdown格式查看代码示例”并向量化后存入向量数据库。当新对话开始时系统会检索与当前话题相关的历史“情节”记忆并将其摘要注入工作记忆。价值实现了跨会话的个性化。用户下次再来说“像上次那样总结”AI就知道他指的是什么。语义记忆 (Semantic Memory)是什么这就是企业的知识库本身是相对静态的“世界知识”。实现即RAG系统中的向量索引和知识图谱。它是记忆系统的基石。Reflexion模式让AI从错误中学习这是记忆系统最酷的应用之一。我们在一个内部运维问答机器人中实现了它。当系统给出的答案被用户标记为“错误”或“不准确”时会触发以下流程LLM对这次失败的交互进行“反思”分析错误原因例如“混淆了A服务和B服务的重启命令”。将这段反思文本连同问题、错误答案、正确答案一起存储为一条“情节记忆”。未来遇到类似问题时系统在检索知识的同时也会检索相关的“反思”记录并在上下文中加入提示“注意历史上曾在此类问题上出错需仔细区分A和B”。 实测下来系统的重复犯错率在一个月内下降了70%。2.3 上下文编排层信息呈现的“艺术”这是最体现“工程”二字的地方。当知识、记忆、工具描述都准备好后如何将它们“喂”给LLM直接影响模型的理解和输出质量。这里有几个核心策略1. 结构化与标记千万不要把一堆文本杂乱无章地拼接起来。一定要使用清晰的标记来区分不同来源和类型的信息。XML或特定的Markdown格式是很好的选择。system_instruction 你是一个专业的金融合规顾问回答必须基于提供的法规条文并注明出处。如果信息不足请明确说明。 /system_instruction conversation_history [用户] 上次我们说到内幕交易处罚力度是怎样的 [助理] 根据《证券法》第202条内幕交易行为人没收违法所得并处以违法所得一倍以上五倍以下的罚款。 /conversation_history retrieved_documents relevance_score0.96 source证监会2024年处罚案例库 案例编号2024-001 涉事主体XX公司高管李某 违法事实利用内幕信息交易本公司股票 处罚结果没收违法所得350万元并处以1050万元罚款三倍。 /retrieved_documents user_query 如果是五倍罚款具体怎么计算 /user_query这种结构化的上下文让模型能清晰地分辨指令、历史、依据和当前问题极大减少了混淆。2. 位置与顺序管理LLM对上下文不同位置的注意力是不同的存在“中间迷失”Lost in the Middle现象。关键信息应放在开头或结尾。我们的策略是开头放置最核心的System Prompt和本次任务的关键指令。紧随其后放置相关性最高的检索结果经过重排序的Top 1-2。中间偏后放置补充性背景知识和压缩后的对话历史。结尾放置当前的用户查询。有时也会把工具描述放在较后的位置。3. 动态压缩与选择当总上下文长度接近模型限制时需要对低优先级信息进行压缩。例如将十轮前的长对话压缩成一句话摘要“用户曾深入讨论过项目A的预算问题最终倾向增加10%”。或者在有多条检索结果时只注入相关性分数超过0.9的那几条。2.4 工具与环境层连接数字世界的“手脚”对于需要执行具体操作查数据库、发邮件、调用API的AI智能体工具的描述和状态也是上下文的重要组成部分。这部分的关键是提供清晰、准确、结构化的工具定义通常遵循OpenAI Function Calling或ReAct格式并将工具的执行结果成功或失败包括返回的数据及时地反馈到上下文中供模型进行下一步推理。3. 关键技术选型与实战配置理论讲完我们来点硬的。搭建一个上下文工程系统需要做出一系列技术选型。以下是我在多个项目中总结出的选型建议和配置心得。3.1 向量数据库存储与检索的基石选项核心优势适用场景实战注意事项Pinecone全托管无需运维上手极快性能稳定。原型验证、中小型生产项目、团队无专职运维。成本随数据量和QPS增长较快复杂过滤查询能力相对较弱。Weaviate开源/云皆可内置混合搜索(BM25向量)支持GraphQL模块化设计。需要高度自定义、混合搜索需求强、或计划多云部署的企业。自托管需要一定的K8s运维能力。其“模块”概念如text2vec-transformers需要花时间理解。Milvus/Zilliz为超大规模向量搜索设计性能顶尖社区活跃。数据量在千万乃至亿级对查询延迟和吞吐量要求严苛。架构相对复杂运维门槛高。Zilliz Cloud是其托管版可降低运维负担。QdrantRust编写性能优异内存效率高过滤功能强大。对延迟极度敏感的应用如实时推荐、资源受限的边缘环境。云服务相对较新社区生态略小于Milvus。pgvectorPostgreSQL扩展无需引入新数据库利用现有PG生态和事务能力。已有PostgreSQL数据量中等百万级希望技术栈统一。性能上限不如专用向量库大规模数据下需要精细的索引调优。我的选择对于大多数企业级知识库项目如果数据量在百万级以内我倾向于Weaviate。它的混合搜索能力在实际业务中非常实用用户经常用关键词提问开源属性也让后期定制和成本控制更有把握。如果项目要求快速上线且预算充足Pinecone是最省心的选择。3.2 Embedding模型语义理解的“翻译官”Embedding模型将文本转换为向量其质量直接决定检索的准确性。别再只用OpenAI的text-embedding-ada-002了现在有更好的选择。选型关键MTEB排行榜关注 Massive Text Embedding Benchmark 榜单排名靠前的模型通常表现更优。多语言支持中文业务必须选择在中文语料上训练良好的模型如BGE-M3、Alibaba-NLP/gte-multilingual。维度与性能权衡text-embedding-3-large达到3072维能力很强但更贵更慢。BGE-M3支持可变维度在1024维下就能达到很好的效果是性价比之选。实战配置示例使用Sentence Transformers库from sentence_transformers import SentenceTransformer # 加载多语言模型 model SentenceTransformer(BAAI/bge-m3) # 编码时指定维度 embeddings model.encode(documents, normalize_embeddingsTrue, batch_size32)注意normalize_embeddingsTrue至关重要它会将向量归一化使得相似度计算余弦相似度更高效准确。3.3 LLM框架LangChain vs LlamaIndex这是开发者最常面对的选择。两者并非互斥常结合使用。LangChain更像一个“胶水”框架其核心概念是“链”Chain和“智能体”Agent。它擅长将不同的组件模型、检索器、工具连接成复杂的工作流。如果你要构建一个多步骤、有状态、需要复杂逻辑编排的AI智能体LangChain尤其是其LangGraph扩展是首选。它的抽象层次高灵活性强但学习曲线稍陡。LlamaIndex专注于“数据层”和“检索”。它在文档加载、智能分块、向量索引构建、高级检索策略如父子分块、递归检索方面提供了极其强大和易用的接口。如果你的核心需求是快速构建一个高效、可靠的RAG系统LlamaIndex往往更直接、更“傻瓜式”。我的策略用LlamaIndex做“数据引擎”和“检索器”用LangGraph编排“智能体工作流”。例如用LlamaIndex建立知识库索引并提供高质量的检索结果然后将检索结果和用户查询喂给LangGraph构建的智能体由智能体决定如何调用工具、如何反思、如何生成最终答案。3.4 长上下文模型是救星还是新坑Claude 200KGemini 200万Token……长上下文窗口让人兴奋。是不是可以把所有文档都塞进去告别复杂的RAG了答案是几乎不可能也不应该。成本长上下文的推理成本呈超线性增长。处理一个20万Token的上下文费用可能是4K上下文的数十倍。性能“中间迷失”效应在超长上下文中被放大。模型对开头和结尾的信息关注度高中间部分的信息容易被忽略。延迟生成200K Token的上下文需要时间可能导致用户体验不佳。正确用法将长上下文能力作为RAG的补充而非替代。我们的策略是先用RAG从海量知识库中精准检索出最相关的5-10个文档片段可能总计2-3万Token然后将这些精选过的片段连同系统指令和对话历史一起放入长上下文窗口。这样既利用了长上下文模型能同时处理多文档的优势又通过RAG保证了信息的精准性还控制了成本。4. 企业级落地从零搭建一个上下文工程系统假设我们要为一个中型科技公司搭建一个内部技术问答与文档助理。以下是完整的实战步骤和避坑指南。4.1 阶段一需求分析与数据准备明确范围确定知识库覆盖范围如API文档、部署指南、故障排查手册、公司制度。切忌一开始就贪大求全。数据收集与清洗从Confluence、GitHub Wiki、Google Docs、PDF手册等来源收集原始数据。关键步骤清洗HTML/PDF格式噪音统一字符编码确保UTF-8处理乱码。一个常见的坑是PDF中的换行符和空格异常需要用pymupdf或pdfplumber仔细提取后做正则化处理。选择分块策略不要用固定长度分块我们使用基于语义的分块。工具采用LangChain的RecursiveCharacterTextSplitter并设置separators为[\n\n, \n, 。, , , , , , ]结合chunk_size512和chunk_overlap50。对于代码文档我们单独写了一个分块器确保函数定义或类定义的完整性。父子分块对于较长的文档如一篇完整的架构设计文档我们同时创建“父块”整个文档的摘要和“子块”各个章节。检索时先找到相关的子块但返回给模型时附上其父块摘要以提供全局背景。4.2 阶段二索引构建与嵌入嵌入模型选择选择BGE-M3模型因为它对中英文混合文本支持好且开源可私有化部署。向量数据库部署选择自托管Weaviate使用Docker Compose部署。# docker-compose.yml version: 3.4 services: weaviate: image: semitechnologies/weaviate:latest ports: - 8080:8080 environment: - QUERY_DEFAULTS_LIMIT25 - AUTHENTICATION_ANONYMOUS_ACCESS_ENABLEDtrue - PERSISTENCE_DATA_PATH/var/lib/weaviate - DEFAULT_VECTORIZER_MODULEtext2vec-transformers - ENABLE_MODULEStext2vec-transformers - TRANSFORMERS_INFERENCE_APIhttp://t2v-transformers:8080 t2v-transformers: image: semitechnologies/transformers-inference:sentence-transformers-paraphrase-multilingual-MiniLM-L12-v2 environment: - ENABLE_CUDA0 # 如果无GPU则设为0构建索引管道使用LlamaIndex的SimpleDirectoryReader加载清洗后的文档。使用自定义的语义分块器进行分块。使用BGE-M3模型生成嵌入向量。将向量和元数据如来源文件、章节标题、创建日期批量导入Weaviate。务必为元数据建立索引以便后续进行混合搜索和过滤如“只搜索2024年之后的文档”。4.3 阶段三检索与编排逻辑开发实现混合检索器在Weaviate中可以轻松配置同时进行向量搜索和关键词搜索BM25并对结果进行融合重排序。设计上下文组装模板使用LangChain的PromptTemplate或LlamaIndex的ChatPromptTemplate定义一个结构化的上下文模板明确指令、知识、历史、查询的位置和格式。实现记忆管理工作记忆使用LangChain的ConversationBufferWindowMemory或ConversationSummaryMemory来管理对话历史。情节记忆在PostgreSQL中创建一张表用于存储session_id,user_id,conversation_summary,embedding_vector。每次对话结束用LLM生成摘要并向量化存储。新对话开始时根据当前用户问题检索相关的历史摘要。构建智能体工作流使用LangGraphfrom langgraph.graph import StateGraph, END from typing import TypedDict, List import operator class AgentState(TypedDict): question: str retrieved_docs: List[str] analysis: str final_answer: str def retrieve(state: AgentState): # 调用Weaviate进行检索 state[retrieved_docs] weaviate_hybrid_search(state[question]) return state def analyze(state: AgentState): # 判断检索结果是否充分是否需要进一步分析 if not state[retrieved_docs]: state[analysis] 知识库中未找到相关信息需告知用户无法回答。 elif needs_deeper_analysis(state[question], state[retrieved_docs]): state[analysis] 信息已找到但需要进行对比和归纳。 else: state[analysis] 信息充分可直接回答。 return state def generate_answer(state: AgentState): # 根据分析和检索结果组装最终上下文并调用LLM生成答案 context assemble_context(state[question], state[retrieved_docs], state[analysis]) state[final_answer] call_llm(context) return state workflow StateGraph(AgentState) workflow.add_node(retrieve, retrieve) workflow.add_node(analyze, analyze) workflow.add_node(answer, generate_answer) workflow.set_entry_point(retrieve) workflow.add_edge(retrieve, analyze) workflow.add_conditional_edges( analyze, lambda x: answer if x[analysis] ! 无法回答 else END, {answer: answer, END: END} ) workflow.add_edge(answer, END) app workflow.compile()4.4 阶段四评估、迭代与监控建立评估集收集100-200个真实用户可能问的问题并准备好标准答案或参考答案。定义评估指标检索相关度 (Retrieval PrecisionK)人工或使用LLM-as-Judge评估检索出的前K个文档是否相关。答案忠实度 (Answer Faithfulness)生成的答案是否严格基于提供的检索来源有无幻觉。答案相关性 (Answer Relevance)答案是否直接回答了问题。延迟 (Latency P95)从请求到响应的95分位耗时。自动化评估使用RAGAS或DeepEval等框架定期如每周在评估集上运行测试监控指标变化。持续迭代根据评估结果调整分块大小、重排序模型、提示词模板等。建立一个反馈循环将用户标记的“踩”回答加入评估集并分析原因。5. 常见问题与避坑指南在多个项目的摸爬滚打中我踩过无数坑也总结出一些宝贵的经验。问题一检索结果看似相关但模型就是不用。原因上下文噪音太大或者关键信息被埋没在长篇文档的中间。解决方案实施重排序在向量检索后增加一个基于交叉编码器如bge-reranker的重排序步骤将最相关的1-2个片段排在前面。优化上下文结构将最相关的检索结果放在系统指令之后、用户查询之前。使用highly_relevant这样的标签包裹它。在指令中明确要求在System Prompt里加入“你必须严格依据以下提供的参考信息来回答问题忽略与你已有知识冲突的部分。”问题二多轮对话中模型“忘记”了之前的设定。原因工作记忆管理策略不当过早丢弃或过度压缩了关键历史信息。解决方案关键信息持久化将用户明确指定的重要偏好如“叫我老王”、“用表格输出”提取出来存入“情节记忆”或单独的“用户画像”存储中并在每次对话开始时作为系统指令的一部分注入。更智能的摘要不要简单截断历史。使用LLM对较长的历史对话进行“针对性摘要”聚焦于当前任务相关的部分。例如如果当前在讨论API就摘要之前关于API的讨论点。问题三系统响应速度慢用户体验差。原因检索链路长或LLM生成速度慢。解决方案异步与流式将耗时的检索步骤与LLM生成步骤解耦甚至可以考虑在用户输入时就开始预检索。对于长答案采用流式输出Streaming让用户先看到部分结果。缓存对常见问题FAQ的检索结果和生成答案进行缓存。可以使用Redis存储query_embedding到answer的映射。模型选型在保证效果的前提下考虑使用更小、更快的模型如Qwen2.5-7B-Instruct进行初步检索重排序或答案生成用大模型做最终校验。问题四知识库更新后回答质量下降。原因新文档的嵌入分布与旧索引不同或新旧知识冲突。解决方案增量更新与版本控制为向量索引引入版本概念。每次全量更新时创建新版本索引并通过一个路由层将查询导向新旧两个索引对比结果平滑过渡。定期全量重建对于更新频繁的知识库建立自动化管道每周或每天在低峰期全量重建索引。虽然耗时但能保证一致性。冲突检测在更新时用新文档的嵌入去旧索引中搜索最相似的旧文档。如果相似度高但内容有冲突则打上“待审核”标签提醒管理员处理。上下文工程不是一个一劳永逸的项目而是一个需要持续观察、测量和优化的动态系统。它一半是科学一半是艺术。科学的部分在于严谨的评估指标和架构设计艺术的部分在于对模型行为的细微体察和对用户体验的不断打磨。当你看到自己构建的系统能够像一个真正专业的助手一样准确、连贯、有记忆地处理复杂问题时那种成就感是无与伦比的。这条路没有终点但每一步的优化都会让你的AI应用变得更聪明、更可靠。
