与传统检索的区别
传统检索给人看结果列表，人选一条；上下文工程要给模型一段可用输入，必须处理重复、冲突与格式。检索的终点是链接，上下文的终点是可引用的证据块，两者的验收标准与失败模式都不一样，不能混用。
与搜索排序的区别
搜索排序追求相关性，上下文工程还要考虑篇幅、可读性与冲突。排在第一的片段若过长或夹带无关段落，模型仍可能误读；因此常需要二次压缩与结构化，而不是把排序结果原样拼进去，否则仍会误读。
与知识库的区别
知识库解决存与找，上下文工程解决给什么、给多少、按什么顺序给。库里的条目可以很多，进入窗口的必须少而准；把知识库直接当成上下文方案，常见结果是检索命中、答非所问，用户很快失去耐心。
与提示工程的区别
提示工程关注指令怎么写，上下文工程关注材料怎么选。两者常被混为一谈：指令写得再清楚，若证据缺失或过期，答案仍不可用；反过来，材料齐全但指令含糊，模型也会答偏，两者要配合着看效果，但职责要分清。
与传统报表的区别
报表把数据整理成人可读的固定视图，上下文要按每次问题动态组装。它更像一条实时编辑流程：抓取、筛选、压缩、标注、投放，每一步都要有规则与记录，否则无法解释模型为何这样回答，验收也谈不上。
适用与不适用
适合谁
- 已上检索、但答复质量不稳的技术团队，且有人牵头
- 正在评估检索增强方案边界的产品负责人
- 需要向管理层解释改造范围与投入的项目组
不适合谁
- 只需要关键词搜索、不生成答案的场景
- 没有文档底稿、也无更新机制的项目
典型场景
某制造企业的设备手册检索原本给人用，工程师搜到章节自己读。改造成问答后，团队发现直接返回整章会让模型抓错段落，于是加了条目切分、版本标注与段落压缩，检索命中率未变，答复可用率明显提升，并留下改造记录。
可执行步骤
- 梳理现有检索链路，标出从命中到生成之间的处理环节与责任人，并确认每一步的负责人。
- 把返回内容从整篇改为带标题、时间与适用范围的条目，并留原文链接，并核对授权范围。
- 为条目加压缩规则，超长时只留结论句与适用条件，同时保留完整版本，避免压缩后失真。
- 对比改造前后的引用正确率与人工返工量，再决定是否扩大范围，并把结论写进验收记录。
常见坑
- 把检索结果整段塞给模型，段落里夹带无关条款，模型抓错重点，答复看似有据实则偏离，返工与解释成本都高。
- 只按相似度排序，不看时间与适用范围，旧版本条目排在前面，答复引用作废规定，用户还被蒙在鼓里。
- 知识库条目切得过碎，一句话一条，缺少上下文，模型拼不出完整条件，答案前后矛盾，用户只能反复追问。
- 改造只做检索侧，不给输出做校验，引用错条目也无人发现，问题积累到客户投诉才暴露出来，整改也无从下手。
自检与验收清单
- 返回内容是否从整篇改为可引用的条目，并留原文链接。
- 条目是否带来源、时间与适用范围三类标签，且可逐条核验。
- 是否有超长压缩规则与丢弃记录可查，超出时如何取舍。
- 是否对比过改造前后的引用正确率与返工量，并写进验收记录。
常见问题
这和 RAG 是一回事吗？
RAG 是一种模式：先检索再生成。上下文工程覆盖更广，还包括历史、工具返回、记忆与压缩策略。可以理解为 RAG 解决找什么，上下文工程解决怎么给、给多少，两者是包含关系而非同义词。
知识库要重建吗？
多数不必重建，但要做条目化与元数据补全：标题、来源、时间、适用范围。切分粒度过粗或过细都会影响效果，通常按条款或问答对切分更稳，再按业务需要做二级索引，也便于迁移到新系统。
传统搜索还能用吗？
能，而且常作为第一层召回。关键词搜索在专有名词与编号上往往比向量检索更准，混合召回再加结构化过滤，通常比单一路径稳定。关键是召回之后还有筛选与压缩，而不是直接投喂。