把整本知识库塞进去，往往只是让问题变贵
企业刚开始做知识助手时，最容易想到的办法是把部门资料全部放进提示词。这样做确实能快速演示，但用户一多，响应时间会明显变长；同一个问题每次都重复发送大量文本，调用量增加，模型还可能在互相无关的内容里找到错误线索。
资料越多，答案越稳定的想法并不成立。模型需要的是和当前任务有关、版本明确、来源可信的上下文。把销售报价、历史合同、过期政策和内部讨论一起交给它，看似全面，实际增加了判断负担，也让团队难以解释答案到底依据哪份资料。
先按任务定义上下文，不要按部门文件夹打包
客服问答需要产品功能、服务边界和当前政策；销售准备方案需要客户背景、适用案例和报价规则；合同审阅需要条款版本和审批条件。不同任务的资料范围不同，不能因为文件都属于同一个部门，就默认全部可用。先把任务和输出写清楚，再设计取数范围。
上下文可以分成几层：稳定的品牌和业务定义、当前任务的客户资料、经检索命中的知识片段、工具返回的实时数据和员工补充的特殊说明。每一层都标记来源与版本，出了问题可以知道是检索错了，还是实时数据没有更新。
- 为高频任务设置固定字段和资料上限，避免无限拼接。
- 优先传递与问题直接相关的片段，保留原文链接或文档编号。
- 把实时库存、价格和权限结果与静态知识分开处理。
摘要和缓存可以省钱，但不能抹掉证据
重复的公司背景、客户基本信息和历史对话可以做摘要或缓存，减少每次重新传输。但摘要要保存生成时间、覆盖范围和来源，不能把它当成永远正确的事实。资料版本变化时，相关摘要和缓存要失效，否则系统会继续使用已经过期的压缩内容。
对需要精确引用的任务，摘要只能做导航，最终答案仍应回到原始资料。比如合同金额、退款条件和服务承诺，不能因为摘要里没有提到就当作不存在。成本优化不应以牺牲可核验性为代价，尤其是客户和审批人需要复查时。
上下文预算要和业务结果一起算
团队可以为每个场景记录平均输入长度、输出长度、响应时间、重试率和人工修改时间。一个看似便宜的短上下文，如果导致员工反复追问和修改，实际成本可能更高；一个上下文稍长但一次解决的问题，反而更适合稳定交付。不要只盯单次 token 数。
当上下文超出预算时，系统应有明确处理：缩小检索范围、提示用户补充条件、转人工或分步骤完成，而不是悄悄截断最重要的资料。员工知道系统为什么需要补充信息，也比得到一段来源不明的完整答案更容易建立信任。
验收要用长对话、旧版本和多任务混合场景
测试时加入多轮追问、长文档、资料更新和用户权限变化，观察系统是否忘记当前任务、混入上一个客户的信息，或者在版本变化后仍引用旧内容。再测试高峰并发，记录上下文变长是否让响应和费用突然失控。
好的上下文管理让系统知道“该带什么、带到哪一步、什么时候清掉”。它不是单纯的技术节省技巧，而是企业 AI 交付中的基础设计：资料少而准，答案才更容易解释，团队也才有能力持续维护。
要点总结
- 不一定。无关、过期或互相冲突的资料会增加判断难度，应优先提供与任务相关且版本清楚的内容。
- 不能。摘要适合导航和降低重复输入，涉及金额、政策和合同等事实时仍需回到原始来源。
- 根据资料类型设置失效条件，价格、政策等高频变化内容应在版本变化后立即失效。
参考来源说明
本文围绕“同一份资料每次都重新塞给模型，企业 AI 的成本和延迟会一起涨”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。