个人主页 for_ever_love__ 欢迎各位大佬莅临其他栏目: 大模型开发从0到1 其他栏目: iOS项目总结大全 其他栏目: 我想学python了 其他栏目: iOS UI 文章目录上下文工程比提示词工程更重要的事一、从 Prompt Engineering 到 Context Engineering二、上下文的六个组成部分三、① 系统提示写边界而不是愿望四、② 工具定义让模型一眼选对五、③ 长期记忆注入最小必要信息六、④ 检索内容位置和格式都有讲究七、⑤ 对话历史分级而不是全留八、⑥ 当前输入别只给这一句九、装配顺序很重要十、一套可复用的装配器十一、怎么验证上下文的质量十二、小结上下文工程比提示词工程更重要的事提示词工程问的是这句话该怎么说。上下文工程问的是该给模型看什么。后者对效果的影响往往比前者大一个数量级。一、从 Prompt Engineering 到 Context EngineeringPrompt EngineeringContext Engineering关注对象措辞信息载体一句话系统提示 历史 检索 工具 示例关键能力表达取舍效果天花板中高一个真实的例子❌ 提示词写得很好但检索到的是 3 篇不相关的文档 → 模型只能基于不相关内容回答或者拒答 ✅ 提示词写得很朴素但检索到了精确的 2 段内容 → 模型直接给出正确答案信息对了措辞可以朴素信息错了措辞再精妙也没用。二、上下文的六个组成部分一次 LLM 调用的上下文其实是六块拼起来的┌─────────────────────────────────────┐ │ ① 系统提示 角色、规则、约束 │ ├─────────────────────────────────────┤ │ ② 工具定义 schema 与描述 │ ├─────────────────────────────────────┤ │ ③ 长期记忆 用户偏好、历史事实 │ ├─────────────────────────────────────┤ │ ④ 检索内容 知识库片段 │ ├─────────────────────────────────────┤ │ ⑤ 对话历史 最近几轮 │ ├─────────────────────────────────────┤ │ ⑥ 当前输入 用户这句话 │ └─────────────────────────────────────┘每一块都需要单独设计而且要设计它们的装配顺序。三、① 系统提示写边界而不是愿望# ❌ 愿望式模型会自由发挥SYSTEM你是一个专业的、友善的、乐于助人的技术助手 请尽可能准确、详细地回答用户的问题。# ✅ 边界式模型知道该怎么做SYSTEM你是 {product} 的技术支持助手。 【必答】 - 产品的功能用法、常见问题 - 报错信息的排查步骤 【不答】 - 价格引导到销售 - 与其他产品的对比说不便评价 【格式】 - 结论写在第一句 - 步骤用有序列表 - 代码用 包裹 【不确定时】 直接说我不确定不要猜。不要编造 API 名称或参数。 关键差别愿望式边界式“尽可能准确”“不确定就说不确定”“友善专业”“结论写第一句”“详细回答”给出具体的必答/不答清单后者可验证——你能检查模型有没有违反。四、② 工具定义让模型一眼选对工具定义的上下文成本很高每个 100~300 token而且直接影响选择准确率。描述模板tooldefsearch_orders(user_id:str,status:Literal[pending,paid,refunded]|NoneNone,days:int30,)-str:查询用户的订单列表。 何时使用用户问我买了什么、我的订单、订单状态。 何时不用查单个订单详情用 get_order_detail更快。 Args: user_id: 用户 ID格式 U 8 位数字 status: 订单状态。不传则返回所有状态 days: 查询最近多少天。默认 30 天最大 365 四段结构能力 → 何时用 → 何时不用 → 参数说明。何时不用这一段经常被忽略但它最能减少误选。精简原则每个工具的描述控制在 3 行以内 工具总数控制在 8 个以内超过就拆分 Agent 枚举值写进 Literal不写在描述里五、③ 长期记忆注入最小必要信息defbuild_memory_block(user_id:str,query:str)-str:只注入两类记忆 1. 高重要度的偏好/约束永久 2. 与当前问题相关的按需 pinnedstore.search(namespace(memories,user_id),filter{importance:{$gte:4},category:{$in:[preference,constraint]}},limit5,)relevantstore.search(namespace(memories,user_id),queryquery,limit3)lines[]formindedupe(pinnedrelevant):lines.append(f- [{m.value[category]}]{m.value[content]})return【关于该用户的已知信息】\n\n.join(lines)iflineselse常见的错误是把所有记忆都注入——50 条记忆占了 3000 token其中 45 条和当前问题无关。六、④ 检索内容位置和格式都有讲究位置研究显示模型对开头和结尾的内容注意力最强Lost in the Middle。deforder_docs_for_context(docs:list[Document])-list[Document]:最相关的放开头和结尾中等相关的放中间docssorted(docs,keylambdad:-d.metadata[score])iflen(docs)2:returndocs# 第 1 个放最前第 2 个放最后其余放中间out[docs[0]]out.extend(docs[2:])out.append(docs[1])returnout格式给每段内容加来源标记模型更容易引用也更容易识别这是资料。defformat_docs(docs:list[Document])-str:parts[]fori,dinenumerate(docs,1):srcd.metadata.get(source,未知)titled.metadata.get(title,)parts.append(f[资料{i}] 来源{titleorsrc}\n{d.page_content})return\n\n---\n\n.join(parts)加上资料 N编号回答时模型会写根据资料 2用户能核对。七、⑤ 对话历史分级而不是全留defbuild_context(history,question,docs,token_budget8000):parts[]# 关键事实永不压缩factsextract_pinned_facts(history)iffacts:parts.append(【已确认的事实】\n\n.join(f-{f}forfinfacts))# 较早的对话摘要iflen(history)8:parts.append(【较早的对话摘要】\nsummarize(history[:-8]))# 最近几轮原文recenthistory[-8:]return{facts:facts,summary:...,recent_history:recent,docs:docs,question:question,}三级结构事实结构化→ 摘要压缩→ 原文保真。八、⑥ 当前输入别只给这一句用户的这句话常常省略了上下文用户那它的价格呢它是什么得从历史里解析。两种做法① 查询改写推荐REWRITE_PROMPT根据对话历史把用户的最新问题改写成独立完整的问句。 对话历史 {history} 最新问题{question} 只输出改写后的问题。如果问题本身已经完整原样输出。defrewrite(history,question):ifis_standalone(question):returnquestionreturn(rewrite_prompt|cheap_llm|StrOutputParser()).invoke({history:to_text(history[-4:]),question:question})那它的价格呢 → LangChain 的 Pro 套餐价格是多少改写后的问题同时用于检索和生成——这能显著提升检索命中率。② 把历史一起给模型次优但简单九、装配顺序很重要同样的内容顺序不同效果不同messages[SystemMessage(SYSTEM),# 1. 身份和规则SystemMessage(memory_block),# 2. 用户长期记忆SystemMessage(facts_block),# 3. 已确认事实*recent_history,# 4. 最近对话HumanMessage(context_block),# 5. 检索内容HumanMessage(question),# 6. 当前问题]为什么检索内容放在最后离问题最近注意力最强用户消息位置的内容被当作当前关注的信息系统消息位置的内容容易被当作背景设定。另一种有效布局是把检索内容用context包起来放在用户消息里HumanMessage(fcontext{context_block}/context{question})关键给内容打标签让模型能区分资料和问题。十、一套可复用的装配器classContextBuilder:def__init__(self,budget:Budget):self.budgetbudgetdefbuild(self,user,question,history,docs)-list[BaseMessage]:# 1. 改写查询如果依赖上下文qrewrite(history,question)# 2. 检索用改写后的问题ifdocsisNone:docsretriever.invoke(q)docsdedupe_docs(docs)[:self.budget.max_docs]# 3. 分类预算allocself.budget.allocate({history:0.4,retrieval:0.6})# 4. 组装各部分msgs[SystemMessage(SYSTEM),*self._memory(user,q),*self._facts(history),*self._recent(history,alloc[history]),HumanMessage(self._context(docs,alloc[retrieval])),HumanMessage(question),# 原始问题不是改写的]returnself.budget.fit(msgs)def_recent(self,history,tokens):trimmedtrim_messages(history,max_tokenstokens,token_countercount_tokens,strategylast,include_systemFalse,start_onhuman)returntrimmeddef_context(self,docs,tokens):textformat_docs(docs)returnfcontext\n{truncate_by_paragraph(text,tokens*3)}\n/context注意最后一行HumanMessage(question)用的是原始问题不是改写后的——因为用户看到的是他自己的话回答也应该直接回应他的问题。十一、怎么验证上下文的质量上下文工程的效果可测① 检索质量defeval_retrieval(queries,ground_truth):hits0forq,gtinzip(queries,ground_truth):docsretriever.invoke(rewrite(history,q))texts[d.page_contentfordindocs]ifany(gtintfortintexts):hits1returnhits/len(queries)② 上下文精度检索 5 篇只有 2 篇被引用 → 精度 40%说明多塞了 3 篇垃圾。defcontext_precision(answer_with_citations,total_docs):returnlen(set(answer_with_citations))/total_docs③ Lost in the Middle 检查把关键信息放在中间位置看模型能不能找到deftest_middle_recall(docs):把答案放在第 3 篇中间看模型能否答出docsreorder_put_at_middle(docs,answer_idx2)returnask(docs)EXPECTED这三项指标是上下文工程效果的量化依据。十二、小结上下文 系统提示 工具 长期记忆 检索 历史 当前问题六条实践1. 系统提示写边界必答/不答清单不写愿望 2. 工具描述加何时不用控制数量在 8 个以内 3. 长期记忆只注入高价值项不全量 4. 检索内容按相关性排序位置加来源编号 5. 历史三级处理事实 / 摘要 / 原文 6. 查询先改写再检索和生成一句话总结提示词工程的产出是一段文字上下文工程的产出一套信息装配流程。后者更难但它是可测的、可迭代的、能沉淀成基础设施的——这正是它在工程上更有价值的原因。er_idx2)return ask(docs) EXPECTED**这三项指标是上下文工程效果的量化依据。** ## 十二、小结上下文 系统提示 工具 长期记忆 检索 历史 当前问题六条实践系统提示写边界必答/不答清单不写愿望工具描述加何时不用控制数量在 8 个以内长期记忆只注入高价值项不全量检索内容按相关性排序位置加来源编号历史三级处理事实 / 摘要 / 原文查询先改写再检索和生成**一句话总结提示词工程的产出是一段文字上下文工程的产出一套信息装配流程。** 后者更难但它是可测的、可迭代的、能沉淀成基础设施的——**这正是它在工程上更有价值的原因。**