模型没换，为什么AI变笨了？

先说一个我们在项目一线反复遇到的场景。

系统上线第一个月，业务群里全是夸的。第三个月，开始有人小声说：它好像不如以前准了。第五个月，没人再提它，只有 IT 的工单系统里躺着几条没人回的记录。

你去问模型团队，答案通常是：模型没换，参数没动，版本没退。你去问业务，答案更直接：它就是变笨了。

两句话都对。变笨是真的，模型没换也是真的。

因为变笨的不是模型，是本体。

这里的本体，还是前几期那个定义：企业知识的沉淀形态，是 "这家公司怎么运转" 这件事本身的答案。

它有一个特点:会老。

01 三种 "变笨", 其实是同一件事

第一种，答非所问变多。

它还在按三月份的口径给你出报表，而公司四月份已经把「活跃客户」的定义改过一次 —— 从「近 90 天有下单」改成「近 90 天有登录或下单」。同一句话，两个答案。

更麻烦的是，它答得依然流利、依然自信、依然带图表。错的东西一旦配上对的形式，比明显的错更难被发现。

第二种，老规矩不认了。

某个审批原来过到总监就够，现在要过两道。系统还按老黄历给建议，业务拿着它的结论被打回来，来回两次，人就不用它了。

注意这里的损耗方式：不是它算错了，是它算对了昨天的规则。在规则变更的那一周，它是最不可靠的时候 —— 因为它比谁都确信。

第三种，边界开始糊。

它开始回答一些本不该它回答的问题 —— 因为没人告诉过它，那条线是什么时候划过来的。曾经属于「不能问」的字段，现在能问出来了，而当事人并不知道这个变化。

这一种最危险，因为它不产生错误答案，它产生不该存在的答案。

三种表现，一个根因:现实往前走了三个月，本体还停在交付那天。

模型给的是当下的聪明，本体给的是随时间不走样的可靠。

02 换个视角：本体不是交付物，是胃

上一期我们说过，demo 死于不接本体。

这一期要说一句更扎心的:本体接上了，系统也会死 —— 死于不代谢。

大多数企业把本体当成一件交付物：知识库建好、规则录完、语料清洗完，验收、上线、结项。这套动作的逻辑是 "买回一台冰箱，插上电就该一直冷"。

但本体不是冰箱。本体是胃。

胃不会因为今天装满了就永远饱，它每天都在分泌、消化、排出。今天吃进去的东西，明天就变成了别的东西。

企业本体也一样：数据进来，理解留下，包袱排掉。三个动作少一个，它就开始僵。

只进不出，那是仓库，不是本体。

一个很常见的画面：知识库里躺着 2019 年的报价规则，编号还在，条文还挺工整。没有人删它，也没有人知道它已经作废。新来的员工问一句，系统答一句，答得理直气壮。

这不是知识库的错。知识库本来就只会存。错在我们让它承担了 "理解" 的职责，却没给它 "遗忘" 的能力。

03 三个腐蚀机制，比模型退化常见得多

先把话说在前面:真正的模型性能退化很少见。腐蚀发生在模型外面。

机制一，语义漂移。

组织每改一次流程、每换一次口径、每调一次架构，本体的语义就整体偏移一次。这种偏移不报错、不告警，它只会让答案慢慢变得「好像不太对」。

最麻烦的是它不可见。版本号没变，界面没变，参数没变，只有答案在偏。

这就像一艘船，每天都在轻微偏航。单看一天的偏差可以忽略，三个月后，你已经不在原来的航线上，而罗盘还是好的。

机制二，知识沉积。

旧规则不下线，新规则进不来；或者两条规则同时存在，互相矛盾。本体里最危险的状态不是没有知识，是有两条打架的知识，而模型每次随机挑一条。

对使用者来说，这比「不知道」更糟 —— 不知道还能查，答错了会背锅。

记住错误的事实，比忘记更危险。

机制三，责任真空。

这一条最致命。项目上线，团队解散，没有一个具名的人被指定为「养它的人」。每逢有人问这块谁负责，回答是「之前那个项目组」。

胃停摆了不会立刻疼，只是消化一天比一天差。而组织往往要到「有人被答案坑了一次」的时候，才想起这件事。

三个机制叠在一起，就构成了那个熟悉的过程：不是某一天突然坏了，是每一天都差一点点。

04 为什么偏偏是「三个月」

这里做一个量级估算，你可以按自己公司的情况换算。以下是推算，不是行业统计。

一家 300 人的公司，一年流程级的变化大概 20 到 50 次，折算成每月 2 到 4 次。

一线问答里，涉及口径和规则的问题通常占三成以上。

再往下拆一层：假设一个业务场景累积了 300 条高频问题，其中 100 条和口径、规则相关。每月发生 3 次流程变更，每次波及 8 到 12 条问答 —— 包括答案要改的，和答案变得有歧义的。

一个月是 24 到 36 条，三个月就是 70 到 100 条。

也就是说，三个月之后，三分之一的「常识问答」, 答案已经不是今天的答案了。

而使用者遇到的第一条过期答案，通常就是他们放弃这个系统的原因。不是因为它错得多，是因为它在最该准的地方错了一次。

这解释了为什么「三个月」这个说法在不同行业反复出现 —— 它不是一个精确的临界点，它是一个经验上的心理账户余额。

系统的崩塌不是断崖，是漏水。

断崖会有人修，漏水只会有人绕。

05 新陈代谢要做的四件事

第一，定期体检。

不是看模型跑分，是每周抽 20 条真实问答，人工判对错。跑分测的是模型，抽样测的是本体。

做法上有个细节：抽样必须从真实提问日志里抽，不能让业务部门自己报。人报的都是难题，日志里才有那些「没人觉得有问题、其实已经错了」的答案。

这两类问题的价值完全不同。前者暴露能力边界，后者暴露本体裂缝。

第二，规则退役。

每条规则都该有生效时间和失效条件。旧的不是删掉，是标成「已废止」, 并写清被谁替代。

这一步，九成团队没做。原因也不难理解 —— 写了没人看，删了怕出事。所以最稳的做法是:只标不删, 加一个「作废时间」字段，让系统自己不去用它。

保留痕迹，但停止生效。这比 "删干净" 安全，也比 "留着不管" 负责。

第三，责任到人。

必须有一个具名的人，对本体准确性负责。不是「数据团队」, 是一个名字。

没有名字的职责，等于没有职责。

这个人的工作量不大，每周两三个小时，但他必须拥有两样权力：能决定一条旧规则下线，能驳回一条来路不明的知识。

这两样权力很关键。只有维护权、没有否决权的人，最后一定会被业务部门推着往里塞东西，本体就会越来越胖、越来越乱。

第四，反馈闭环。

业务人工兜底的每一次修正，都要回到本体里，而不是留在某个人电脑的聊天记录里。

人纠正过的地方，系统第二次还错，这是最伤信任的事。

一次纠正没回写，等于那次纠正白做了，而且还多了一个人的失望。

这四件事对应下来，很像一个医疗系统:体检、换药、主治医生、病历。

医疗系统不会因为病人出院就停止运转。企业本体也不该因为项目结项就停止保养。

06 划个边界：什么时候不需要养

这一段必须说清楚，否则又变成卖焦虑。

一次性任务不需要。 一次尽调、一份报告、一场活动的文案，用完即弃，养它就是浪费。

规则长期稳定的场景也不需要。 标准明确、三年不变的那种查询，改一次就够。

真正需要养的是三类:口径会变、组织会动、答案会被追责。 这三条同时成立，本体就必须是活的。

养一个器官是有成本的。先判断需不需要这个器官，再谈怎么养。

很多时候问题不在 "没养", 而在 "养错了对象"—— 把该一次性用完的东西，做成了需要长期维护的系统；把该长期维护的本体，当成了一次性交付的项目。

07 带走三件事

01 AI 系统变笨，先查本体，别急着换模型。

换模型是成本最高、收益最不确定的动作。而本体的问题，往往一次口径对齐就能解决一半。

02 本体是名词和关系，代谢是动词。只有名词的系统，一定会僵。

建本体只是把知识放进去，养本体才是让它保持正确。前者是项目，后者是职能。

03 给本体配一个名字，比给它配一套工具更重要。

工具决定它能做什么，名字决定它会不会被持续修正。而长期来看，后者才是它活下来的原因。

结语

我们习惯用「上线」来定义一个 AI 项目的成败。

但上线不是终点，出生只是第一次呼吸。

真正让一个系统活下来的，是它每天都在做的那件小事 —— 把新的现实，重新写进自己。

这件事不性感，不会出现在验收报告里，也没人为它写新闻稿。它只是每周两小时，一个具名的人，翻二十条问答，标一条旧规则，回写一次修正。

但就是这件小事，决定了三个月后，还有没有人打开那个系统。

这不是幻想。这是每一家把 AI 当长期资产的公司，迟早都要学会的手艺。

而手艺的开始，往往是给一个没人管的角落，写上一个名字。