AI知识库实战：别把资料堆给大模型，我的集团建设心得
不少人认为建知识库就是“把PDF文件丢给大模型，让它自己消化”，我不仅见过这么做的，还见过把10万份合同直接塞进去然后问AI“我们的违约金条款有哪些”；今天分享我在一家制造集团从零搭建AI知识库的真实经历，踩过的坑和填过的土。
去年我们公司引入了RAG平台，搭建了一个AI知识库；我们联合业务智能部门建立了1000多个知识库，10万多份文档，全部传给GPT让它学习。
后来很多职能部门开始使用时，发现准确性仍有较大差距；我们也找了不少同行取经。事实上，AI知识库建设和传统仓库建设很像；你不会把面粉、水泥、洗衣机、猫粮堆在一个仓库里，然后说“仓库有了，东西自己分类”。但你在建AI知识库时，就是这么做的。
今年我们花了半年多时间，在一个大型制造集团从头到尾建了一个AI知识库；覆盖了集团多个事业群的技术文档、操作规程、质量标准和历史案例。今天把真实经验写出来，不说漂亮话，只说踩过的坑。
一、建知识库第一步：做减法，不是做加法
这是我们和所有做知识库的人最大的观念冲突。
绝大多数人做知识库的思路是“收集得越多越好”；领导一开口：“把所有资料都放进去”。
我见过一家制造业企业，第一次收集就拉了2000多份文档；技术文档、规章制度、合同模板、甚至员工的培训心得——填鸭式往里塞。
你没有能力处理2000份文档；大模型也没有。
我们建知识库的第一步，不是收集资料，是筛选资料。
什么资料值得进入知识库？三个标准：
第一个标准——它是不是“知识”；不是文档就是知识；知识必须是“具有回答能力的信息”，一个有明确答案的问答是知识，一篇《售后服务SOP》全文是知识，一张年会照片不是知识，一篇《我的入职感想》不是知识。
第二个标准——它是不是“高频使用的知识”；知识库不是档案馆，档案馆是“万一要用的时候去翻一下”，知识库是“每天都在被问的东西”，设备故障排查流程是高频知识，五年前的某次质量事故报告不是，先做高频，再做低频，优先级错了，知识库上线第一个月就没人用了。
第三个标准——它是不是“有明确答案的知识”；开放性问题、没有标准答案的内容、主观判断类的内容，不适合进AI知识库，AI知识库擅长的，是“已知正确答案”的检索和复述，它不擅长“这件事你怎么看”。
按这三个标准筛下来，我们最初的2000份文档，只留下了400份左右。
负责收集资料的同事很不理解：“那我们辛辛苦苦收集的资料就这么废了？”
我说不是废了；是它们不适合做AI知识库，它们适合继续躺在文件服务器上，等人去翻。
二、建知识库第二步：文档结构比文档内容更重要
这可能是整篇文章里最有价值的一句话。
很多人以为AI知识库的核心是“内容质量”——文档写得越清楚，AI回答得越好。
对，但不全对。
我举个例子；同一份《设备操作手册》，两份不同的版本：
版本A：一本200页的PDF，从第一章到最后一章连续排版，没有章节分隔、没有目录、没有小标题。
版本B：同一本手册，按章节拆分——“开机步骤”、“故障代码表”、“日常维护”、“紧急停机”——每个章节独立文件，每章开头的第一句话是“本章内容……”，每一段的开头是“操作步骤：……”或“注意事项：……”。
这两份文档，内容一模一样。但在AI知识库里的表现，版本B的检索准确率比版本A高出40%以上。
为什么？因为AI检索时，不是把整个文档当成一个整体去理解的；它把文档切分成小块——叫“分块”或者“chunk”；切分的时候，如果文档本身有清晰的结构，AI就很清楚“这一块讲什么”。
文档是结构化的，AI理解就是结构化的；文档是一锅粥，AI理解就是一锅粥。
我们在建知识库的过程中，做了大量“文档整理”工作——不是改内容，是加结构。
加标题、加段落标签、加关键词标注、加“这篇文章适用于什么场景”的元信息描述。
举个例子，我们有一份《供应商来料检验标准》，我们在这份文档开头加了一段元信息：
适用范围：钢材类来料检验。适用场景：质检员验收来料、供应商咨询标准、采购部门做合同条款参考；关键词：尺寸公差、硬度测试、化学成分分析、抽样方案AQL。
这段元信息不占什么空间，写起来也不费事；但它让AI在检索到这份文档的时候，一秒就知道“这是不是用户要找的东西”。
三、建知识库第三步：没有“建完”这回事
知识库项目最危险的三个字是——“建完了”。
很多企业做知识库，画风是这样的：立项 → 收集资料 → 整理上传 → 系统上线 → 开庆功会 → 三个月后发现没人用了 → “AI知识库不行啊”。
AI知识库和传统知识库最大的区别是：传统知识库是死的，AI知识库应该是活的。
死的知识库是什么？文档放上去，再也不更新；AI永远在用一年前的知识回答今天的问题。
活的AI知识库是什么？有更新机制、有内容审核、有使用反馈闭环。
我们建知识库的过程中，做了一个后来被证明是最正确的决定：建立一个“知识库运维小组”。
小组三个人，来自不同部门：一个技术部门的人负责知识的准确性和时效性，一个业务部门的人负责知识是否“有用”，还有一个IT的人负责系统的运维和数据监控。
三个人，每周花半天时间做一件事——审知识库。
看看这周有哪些文档需要更新？有哪些文档被频繁检索但始终没找到答案？有哪些文档的“点击率”很低、可能需要下架？
这不是高科技；这甚至有点“土”，但就是这每周半天的审核，让我们的知识库在上线六个月后，使用率没有下降，反而在持续上升。
很多企业可以花50万买一套知识库系统，但不愿意花半个人的工资做一个“知识库运营专员”；这是最大的认知误区，系统是工具，运营才是灵魂。
四、建知识库第四步：效果度量不是“准不准”，是“用不用”
这是最打击人的部分。
知识库上线之前，我信心满满；当时我们的测试准确率超过了90%，内部演示的时候领导频频点头。
上线第一个月，我看后台数据，心凉了半截——日活不到20人；集团几千号人，只有20个人在用。
我找到那些没用的人问原因。反馈基本统一：“习惯问人了”。
这不是准确率的问题。是习惯的问题；业务人员遇到问题，第一反应是打电话问老同事、在微信群里吼一嗓子、找组长问。没有人会想到去知识库搜一下。
我意识到一个残酷的事实：知识库的价值不取决于它有多准确，取决于它被用了多少次；一个准确率95%但没人用的知识库，不如一个准确率80%但每天都在用的知识库。
怎么办？两个动作。
第一个动作：把知识库嵌入业务系统；不是让用户打开一个独立网站去查知识，是在他们日常用的系统里——ERP、MES、OA——嵌入知识库入口；鼠标悬停、右键查询、智能推荐。不要让用户“去找知识库”，让知识库“来找用户”。
第二个动作：在群里降维打击；我们把知识库做成了一个微信群机器人。群里有人问“XX-200的扭矩是多少”，机器人秒回。三个月之后，没人再在群里“艾特”老同事问问题了。所有人都习惯了问机器人。
这不是知识库本身的功劳，这是把知识库放到用户触手可及的地方的功劳。
五、写在最后
AI知识库不是一个“技术项目”，是一个“内容工程”；不是把一堆资料扔给大模型就完事了，是你需要把知识从资料里“提取”出来，组织好、标注好、运营好、分发好；每一个环节都有人的工作。
系统选型花一个月就能决定；内容建设要花半年甚至一年，运营维护是永无止境的事。
但大多数企业，把90%的预算和精力花在了系统选型上，把10%留给了内容和运营。然后抱怨AI知识库“不好用”。
不是不好用，是你根本没给它好用的条件。
这里是一个在制造行业做了10年数据的人，下一篇聊聊另一个话题——「数据出境合规在制造业的真实挑战——一个服务全球客户的集团视角」，我们接着聊。