上个月去一家做工业配件的客户那边复盘，他们花四个月、投入两个全职人力做的AI知识库，后台数据显示日均提问量是11次。而这11次里，有7次是IT部门自己测试点的。员工真正遇到问题，还是打开微信找老张。这不是个例，我经手的企业知识库项目里，上线三个月后日活能上两位数的，不到一半。
问题很少出在模型上。今天的大模型能力，处理企业内部的问答早就够用了。真正卡住项目的，是三个更土的问题：内容从哪来、怎么被找到、错了谁负责。下面按我们踩过的坑一个个说。
一、知识库不是先建库，是先清垃圾
大部分企业的第一步就走偏了：先把共享盘里的文件全量导入。我见过一个客户，光产品手册就有2019、2021、2023三个版本，命名分别是"最终版""最终版2""最终版-改"。三个版本里同一个参数有两个数值。你把这三份都喂给AI，它回答时随机挑一个，员工拿到错误参数去报价，出了事找谁？
我们现在的做法是反过来的。先不导文件，先做一轮"问题清单"：把客服、销售、售后最近三个月真实问过的问题捞出来，通常几百条。然后拿这份清单去比对现有文档——能答上的留下，答不上的标记，答得含糊的直接废弃。一个客户做完这步，原本计划入库的4000多份文档，最后只留了600份。数量砍掉八成，可用性反而上去了。
这里有个判断标准：一份文档如果连人都说不清它现在还有效没有，就不要进库。知识库不是档案室，它只服务"现在这个答案是什么"。
二、检索方式选错，再好的模型也答不准
很多团队一上来就追求"向量检索"，觉得语义搜索高级。但企业文档有个特点：大量专有名词、型号、编号。比如"XG-2200B的额定电流"，向量检索很容易把XG-2200A的内容也召回来，因为它俩语义上太像了。员工问的是B型号，拿到的却是A的参数。
我们在项目里一般用混合检索：关键词匹配兜底型号、编号这类精确信息，向量检索负责处理"这个设备老是跳闸怎么办"这种口语化提问。两路结果合并后再做一次重排。听起来复杂，但用现成的开源框架搭，一个工程师两周能跑通。
还有个细节：分块别切太碎。有团队把文档按200字一段切，结果AI回答"保修期多久"时，只召回了"保修期为"这半句，后面的年限在下一块里没被取到。我们一般按语义段落切，一段300到800字，保留上下文标题。
三、没有"答案负责人"，知识库就慢慢烂掉
这是最容易被忽略、也最致命的一条。知识库上线那天是准的，三个月后就不准了——产品迭代了、政策变了、价格调了，但没人去更新库里的内容。员工问了一次发现答案是旧的，第二次就不问了。
我们的做法是给每类知识指定一个"负责人"，不是IT，是业务口的人。比如产品参数归产品部，售后流程归客服主管。系统里给每条知识打上负责人标签，内容超过设定周期没复核，就自动提醒他。有个客户把这个做进了考核，季度末看谁负责的知识被标记"过期未处理"最多，是要在周会上说明的。
另外，一定要开放"纠错入口"。员工发现答案不对，能一键反馈，反馈直接推给负责人。这个动作看着小，但它让知识库有了自我修复的能力。我们统计过，有纠错入口的项目，半年后内容准确率能维持在90%以上；没有的，普遍掉到60%以下。
要说的话
如果你现在正准备启动，或者手上有个半死不活的知识库，我建议别急着加功能。这周先做一件事：捞30条员工最近真实问过的问题，拿去问你现在的东西，看能答对几条。答对不到一半，那问题就在内容和检索上，不在模型上。
企业知识库这事，本质上不是技术项目，是内容治理项目。技术只占三成，剩下七成是愿不愿意花力气把旧文档理清楚、把责任落到人头上。想清楚这一点，再谈用什么模型、上什么框架，顺序就对了。