先说症状：三种失败长相
企业知识库项目上线三个月后，问题一般长成这三种样子：
- 没人用：访问量集中在上线首周，之后归零；
- 答不准：员工试了几次，从此自己 Google；
- 不敢用：答案看着挺像那么回事，但没人敢照着执行。
这三种症状的根因，很少在模型上。下面是我们接手别人做砸的项目时反复看到的八个坑。
坑一：文档没治理就上切片
症状：同一个问题，答案取决于命中的是哪份文件。
原因：公司里同时存在《差旅报销制度 v3》、《差旅报销制度-最终》、《差旅报销制度-2024修订》三个版本，全都进了索引。
对策：建索引前先做一次归并与归档，一份主题只留一个生效版本，并在元数据里写清生效日期、责任部门和版本。这件事必须有人长期负责，没有 owner 的知识库一定会重新烂掉。
坑二：只切不清洗，表格和扫描件直接进库
症状：问参数答不对，问流程答一半。
原因：PDF 里的表格被按行切成碎片，扫描件是一整张图片，Word 里的批注和页眉被当成正文。
对策：按结构解析而不是按字数切——条款走条款、表格转成带表头的语义行、图片走 OCR 加人工校对、页眉页脚批注在入库前删掉。宁可少收录十份文档，也别塞一百份脏数据。
坑三：一套切片参数打天下
症状：查制度条文很准，问跨文档的综合问题就崩。
原因：不同类型的问题需要不同的检索策略。精确定位靠关键词，模糊描述靠语义，跨文档汇总靠大颗粒上下文。
对策：做混合召回加二次重排，并为高频问法单独维护检索配置。别指望一个 chunk size 解决所有问题。
坑四：没有评测集，靠“感觉不准”推进
症状：改一版提示词，谁也不知道是变好还是变坏。
对策：开工前和业务方一起整理 30-100 个真实问题，附上正确答案和出处，作为验收依据。每次改动跑一遍，把命中率、引用正确率、拒答率记下来。有了这个集子，项目才有“进步”这个概念，也才有明确的上线标准。
坑五：权限写在提示词里
症状：普通员工问“上季度某某客户回款多少”，模型老老实实答了。
原因：权限控制在生成层（“请不要回答无权内容”），而不是检索层。提示词是建议，不是访问控制。
对策：文档带密级与部门标签，检索阶段按当前用户过滤；生成层只做二次防护。全过程审计日志必须留存，出事能追到是谁在什么时候问了什么。
坑六：没有更新机制，半年后还在答旧政策
症状：制度改了，答案没改，员工开始怀疑所有答案。
对策：文档变更触发重建索引，答案里必须显示出处文档与生效日期，并给管理员一个“这篇已过期”的反馈入口。一次性的导入项目，半年后必然失效。
坑七：入口不在工作流里
症状：单独做了一个知识库网站，登录页都没人打开。
对策：把问答嵌到员工本来就在的地方——工单系统侧边栏、企微或飞书机器人、IDE 插件、客服工作台。多一个入口就是多一个不被使用的理由。
坑八：把幻觉当 bug 去修
症状：团队花几个月调提示词想把幻觉调到零，项目永远结不了尾。
对策：承认模型会错，然后改流程而不是改模型——强制引用出处、低置信度时明确说不知道、高影响操作必须人工确认、给错误答案一条快速的反馈与修正通道。用户能容忍一个会说“我不确定”的系统，容忍不了一个经常自信的系统。
立项前对照清单
八件事都有解，但都必须花人力。所以在你决定做之前，先把这七条问一遍。
- 谁对资料的准确性和更新负责？名字，不是部门。
- 现在有多少文档，格式分布如何，能拿到源文件吗？
- 有多少人会真的用它？周活跃目标是多少？
- 有没有 30 个以上真实问题和标准答案，用来当验收依据？
- 数据能不能出内网？需要私有化吗？
- 权限模型清楚吗？按部门、按密级还是按项目？
- 运维谁做？预算里包含每年的索引重建和评测吗？
常见问题
RAG 是不是已经过时了？长上下文和 Agent 会不会取代它？
作为“把企业资料喂给模型”的机制不会过时。长上下文解决不了权限和成本问题——你不会把全公司文档每次请求都塞进去。变的是实现方式：检索从单纯向量召回走向混合检索与重排，并且越来越多地被包在 Agent 的工具调用里。
用现成的 SaaS 知识库产品不就行了？
很多场景确实够用，别为了自建而自建。当出现这三种情况时自建才划算：数据不能出门、需要和你内部系统深度打通、需要按部门做权限与审计。
怎么判断一个知识库项目是成功了？
看两个数：周活跃提问人数占比，以及答案被采纳的比例。没有这两个数，任何“准确率 95%”的宣称都只是实验室里的成绩。