演示那天一般都很顺利。把AI大模型接到内部文档库上，问几个标准问题，回答得像模像样，措辞比人写的还整齐。真正上线以后，第一个星期就会撞上另一类提问：制度里没写、文档已经过期、两个部门的说法互相打架。模型很少说“我不确定”，它会给一个语法通顺、语气笃定的答案。
这不完全是模型出了毛病，而是它的工作方式和我们对“知识库”的期待本来就不一样。
它擅长的是接着往下写
大模型的训练目标是预测下一个词。它学到的是语言在大量文本里怎么分布，而不是某个事实被存放在哪一页。这两件事在多数时候重合，在边缘处分叉。所以它能写出一份格式正确的流程说明，也能在没有依据的地方把空白顺手填上，而且填得很像那么回事。
普遍的做法是检索增强：先在文档里找出相关段落，再让模型只根据这些段落组织回答。这一步确实能压掉相当一部分凭空编造，但它把问题往前挪了一层——检索没命中的，模型仍可能自己补；检索命中三段互相矛盾的，模型会挑一段说，语气依旧肯定。用户看到的是一句完整的答案，看不到背后那次并不确定的检索。
上线之后，工程量大半在模型之外
真正耗时间的部分，往往跟调参没什么关系。
- 文档本身要先能用。怎么切片、标题层级是否清楚、同一份制度有几个版本并存，直接决定检索能不能捞到对的东西。文档乱，再好的模型也只能在乱里找。
- 评估很难自动化。标准问答集能测出一部分表现，但真实提问是散的、口语的、带着上下文的。比较务实的办法是留一条人工抽查的通道，把答得别扭的问题攒起来，定期回头看。
- 延迟和成本是能感觉到的。多一次检索、多一轮改写，响应就慢一截。有些团队为了快，把上下文压得很短，结果模型看不到关键那段，答得更偏。这是个需要反复调的平衡，没有一次性到位的配置。
- 权限得单独想。谁能问什么，不该只靠提示词约束，得在检索那一层就把范围框住。
划一条能接受的错误线
判断一个场景适不适合交给大模型，我倾向于先问两个朴素的问题：答错了，会不会有人当场发现？答案能不能追回到原文某一段？
前者决定风险暴露的速度。写会议纪要、起草内部通知的初稿，错了有人看一眼就改；而对外的口径解释、合同条款的解读，错了可能很久之后才被翻出来。后者决定能不能纠偏。带出处链接的回答，用户可以自己点开核对；不带出处的流畅长句，只能靠信任，而信任恰恰是这类系统最不该透支的东西。
所以我不太赞成把AI大模型当成一个“什么都能问”的入口。更稳的用法是把它放在有边界的位置上：限定它只能基于给定材料回答，答不了就明确说答不了，并把命中的原文摆出来。牺牲一点“聪明”，换来可核对，长期看更划算。
还有一点容易被忽略：模型接入之后，知识库的维护反而变得更重要了。以前文档陈旧只是没人看，现在它会被模型当作依据讲出去，还讲得很有说服力。有人开始认真清理过期文件，这大概是这类项目带来的一个意外好处。
回到最初那个场景。演示成功说明模型有能力，上线顺利说明工程做到位了，两者之间隔着的不是一次模型升级，而是一堆关于文档、权限、评估和错误容忍度的琐碎决定。这些决定做完，AI大模型才算真的进了业务里，而不是停在演示视频里。