第二章说过，上下文窗口是模型唯一的工作记忆。那么一个明显的推论是：模型答不出来，十有八九不是它不会，而是需要的那份资料此刻不在窗口里。公司内部的政策文档、用户三个月前的工单、昨天晚上更新的价格表——模型训练时一个都没见过。把对的资料在对的时刻塞进窗口，这件事有个名字：上下文工程（context engineering）。它是 AI 应用架构师日常花精力最多的一件事。
RAG：开卷考试，不是背书考试
最经典的上下文装配方案是 RAG（检索增强生成）：不靠模型背知识，而是提问时先去资料库里检索出相关的几段，贴进提示词，让模型照着手边的资料回答。就像把闭卷考试改成开卷考试——模型不用记住整本手册，只要会查、会照着答。
检索这一步怎么运作？主流做法是向量检索：把每段资料用一个嵌入模型压缩成一串数字（向量），语义相近的段落，数字也相近。提问时把问题也压成向量，找数字最接近的几段。它的美妙和局限都在同一个地方：它抓的是「语义像不像」，不是「答案在不在」。用户问「退款多久到账」，语义最像的段落可能是「退款政策总则」，而真正写着「三个工作日」的那条细则排在第八名，被截断扔了。
大白话：向量检索像一个只按「主题」找书的图书管理员——你要找的是某页上的一个数字，它给你抱来五本同主题的书。数字在哪页，得靠更细的切分和排序。
检索质量是上限，切分是第一战场
RAG 系统的质量上限由检索决定：资料没检索到，模型再聪明也只能编。而检索质量的第一个战场出人意料地朴素——怎么把文档切成小块。切太大，向量被多个主题稀释，检索不准；切太小，答案的上下文被拦腰砍断，检索到了也读不懂。
实用的原则有两条。一是按文档自身的结构切（按章节、条款、表格边界），而不是死板地每五百字一刀。二是给每块附上它的出处标题——「3.2 退款细则：……」比裸文本好检索得多，因为问题往往和标题语义相近。
再往上，是重排序（rerank）：先用便宜的向量检索粗筛出五十段，再用一个更精细的模型给这五十段按「真的能回答这个问题吗」重排，取前五。粗筛保召回、重排保精度，这是用一层便宜的快换一层贵的准。
记忆：窗口装不下的，用结构换
多轮对话里另一个问题：聊了五十轮，最早的轮次早被挤出窗口了，模型却还要记得用户说过「我对花生过敏」。常见的解法分三层，按成本递增：
- 滚动摘要：定期让模型把历史对话压缩成一段摘要，塞进窗口。便宜，但摘要是有损压缩，细节会丢。
- 事实抽取：把「用户花生过敏」这类关键事实抽出来存进结构化字段，每轮必带。精确，但要预先想清楚「什么算关键事实」。
- 检索式记忆：把历史全部存起来，每轮按当前问题去检索相关旧对话。最灵活，也最贵、最容易检索出噪音。
选哪层，取决于「记错的代价」：过敏信息必须走事实抽取，闲聊偏好用滚动摘要就够了。
上下文装配：架构师真正设计的东西
把这一章收拢：一个 AI 应用的每一次模型调用之前，都有一段看不见的装配代码在跑——查权限、检索资料、拼摘要、带事实、截断历史，最后组装出那一次的上下文。这段装配逻辑才是系统的核心资产，提示词只是它的最后一行。
但模型光会「看资料、答问题」还不够，真实的系统要它去做事：查订单、发邮件、调接口。下一章，给模型接上手和脚。