上个月去一家做工业设备维保的客户那儿复盘，他们CIO当着我的面问运维主管：“咱们那个AI知识库，上个月有多少人用过？”主管支支吾吾半天，最后调出后台数据：月活用户11个，其中6个是IT部门自己人。这个项目花了四十多万，接的是当时较好的大模型，结果一线维修工宁可在微信群里吼一嗓子，也不愿意打开那个搜索框。问题出在哪儿？不是模型不够聪明，是知识库从第一天起就没“喂”对。
一、先别急着买向量库，把“知识从哪来”理清楚
我见过太多技术团队一上来就选型：Pinecone还是Milvus？LangChain还是LlamaIndex？讨论了两周，代码没写几行，预算倒是报上去了。但真正决定知识库好不好用的，是数据源头的质量。那家维保客户有23个G的PDF维修手册，全是扫描件，OCR出来错字连篇，“轴承间隙”识别成“轴乘间障”，这种语料喂给再强的模型也是白搭。
我们后来的做法是：先别管技术栈，花两周时间做数据源盘点。把手册按设备型号、故障类型、维修步骤三个维度打标签，扫描件必须人工抽检OCR准确率，低于95%的批次直接退回重扫。这个笨功夫省不得。另一个做 SaaS 的客户更典型，他们的产品文档散落在Confluence、飞书文档和销售个人的PPT里，同一个功能有三种矛盾的说法。我们帮他们建了个“单一事实源”清单，指定每个知识领域的Owner，只有Owner确认过的版本才能进知识库。这一步做完，后面切片和检索的准确率至少提了30%。
二、切片不是切豆腐，要按“人怎么问”来切
技术圈有个默认做法：按固定字符数切分。512个token一刀，切得整整齐齐。但用户不会按你的切片方式提问。维修工问“3号泵异响怎么处理”，你的切片刚好把“异响原因”和“处理步骤”切到了两个块里，检索出来一半有用一半没用。
我们现在的做法是按“问题-答案对”来组织切片。具体操作是让业务专家（不是程序员）把手册里的内容改写成问答形式，比如“问：3号泵运行时发出金属摩擦声，可能是什么原因？答：优先检查联轴器弹性块是否磨损，其次检查轴承润滑……”。每个切片控制在200字以内，带明确的元数据（设备型号、故障现象、处理等级）。这样检索时，向量相似度匹配的是“问题”，返回的是完整答案，命中率明显提升。代价是需要业务部门投入时间做知识加工，但比起上线后没人用，这笔投入划算得多。
三、评测环节别自嗨，让一线员工来打分
很多团队验收知识库的方式是：自己拿几个问题搜一下，觉得“差不多”就上线了。这是典型的自嗨。我们给一个金融客户做的时候，项目组内部评测准确率87%，信心满满拿去给客服团队试用，结果客服主管问了三个真实客户问题，两个答非所问。原因很简单：项目组用的测试问题是“年化收益率怎么计算”，而客户实际问的是“我昨天买的那个理财，说好4.2%怎么今天变成4.1%了”。
后来我们定了个规矩：评测集必须由一线员工提供，至少200条真实提问，覆盖高频场景和长尾问题。每条问题标注“期望答案来源”，检索结果按“完全命中/部分命中/未命中”三档打分。低于80%完全命中率的模块不允许上线。这个标准听起来严，但执行下来返工成本比上线后被投诉低得多。另外建议每周抽20条线上真实提问做复盘，把未命中的问题补进评测集，知识库才能越用越准。
四、上线只是开始，运营机制跟不上照样烂尾
知识库有一个反直觉的特点：它不会自己变好，只会自己变烂。产品更新了，手册没改；流程优化了，FAQ还是旧的；新员工按老文档操作出了事故，才发现知识库里的内容已经过期半年。那个维保客户后来之所以月活从11个涨到200多，关键动作是设了个“知识运营”的兼职岗，由每个业务部门指定一个人，每周花两小时检查本部门的知识条目，过期内容打标下架，新内容审核上架。IT部门只负责平台和工具，内容质量归业务部门自己管。
另外一个小技巧：在搜索框下面加一行字——“没搜到？点这里直接问专家”。用户点了之后，问题自动转给对应的业务专家，回答完再一键入库。这既解决了长尾问题，又让知识库有了持续生长的入口。我们统计过，这个按钮带来的新增知识条目占总量的40%以上。
最后说两句实在的
企业AI知识库不是买个大模型接口就能跑起来的东西，它更像是一个需要持续喂养和调教的“数字员工”。如果你正准备启动这个项目，我建议先做一件事：找三个一线员工，让他们把最近一周在微信群里问过的工作问题截图发给你。那就是你知识库最该回答的问题，也是你评测集的起点。别从技术选型开始，从真实问题开始。