演示环境里，一个接入内部文档的问答助手对答如流；换到真实工单，它却把旧版本的操作步骤和最新流程混在一起。于是有人提议：换一个模型。先别急。这类“忘事”或“串台”，多数时候不是模型容量不够，而是上下文没有组织好。
模型不是数据库
AI大模型按概率生成文本，它不会自动“读取”企业硬盘里的文件。把文档塞进提示词，只是给了它临时参考；窗口再长，也不等于理解到位。长上下文会稀释关键信息，增加推理成本，还可能让模型在无关段落里过度联想。现实的做法，是先把问题拆清楚：用户到底要查什么、答案应该来自哪几类文档、哪些字段必须原样返回。
检索增强生成，难点在“拼什么”
检索增强生成（RAG）常被当作知识问答的默认方案：先检索片段，再拼进提示词。但检索质量决定系统表现。切片太碎，语义断裂；切片太大，噪声变多。元数据缺失，版本和权限就容易被忽略。一个可用的系统，通常要在检索后做重排、去重和冲突标记，而不是把前几条结果直接交给模型。提示词也不是咒语，而是接口设计：角色、约束、输出格式、拒答条件，都要写清楚。否则模型会用流畅的语气掩盖不确定。
评估不能只看演示
离线评测集容易变成“应试”：问题由内部人编写，答案也由内部人标注，模型表现自然好看。线上真实问题分布复杂，错别字、省略、指代、多轮追问都会出现。务实的做法，是保留小规模人工复核，把失败样本按类型归档，再决定是补检索、改提示，还是加规则兜底。不要用一次演示的顺滑程度判断系统可用性。
边界值得先写清楚
AI大模型适合做草稿、归纳、检索辅助和格式转换，不适合在缺少确认的情况下直接执行高确定性操作。把“生成建议”和“执行动作”分开，保留人工确认节点，反而能减少推进阻力。成本与延迟也要提前算：长上下文增加推理开销，流式输出改善等待体验，但不解决准确性。与其追问哪个模型合适，可以先问：哪个环节必须由人兜底，哪些输出可以自动通过。
回到开头那个问答助手。真正要改的，可能不是模型，而是文档版本管理、检索策略和失败兜底。AI大模型能放大流程里的清晰部分，也会放大含糊部分。先把上下文管好，再谈换不换模型。