知识库的失败大多不在 AI 模型，而在入库那一步。扫描版 PDF、三个版本并存的管理制度、没有标题的会议纪要，喂进去之后检索出来的东西自然对不上。把知识库当成一条流水线看：入库、切分、索引、检索、生成、维护，六个环节里任何一个松动，后面都只能用人工补。这篇按链条讲清每个环节做什么、怎么判断做没做好。
一条链上，先坏的是哪一环
现象能反推环节，比盲目调参快。答非所问，多半是切分把一段完整的话切断了，或者检索把相近但不相关的内容排到了前面。答得对但内容过时，是维护没跟上。答「没有相关资料」，是入库时压根没收进来。答案对但没有出处，是生成环节没要求引用。
先定位再动手，改一处、测一次。同时改切分和换模型，出了效果也不知道是谁的功劳。
入库：先定不收什么
收资料之前定三件事：范围（哪些部门、哪几类文档）、版本（只留现行版，旧版打标记或移出）、责任人（谁负责更新、多久看一次）。这三件事不定，后面所有环节都在给混乱擦屁股。
格式上优先可复制文本的文件，扫描件先做文字识别，识别完抽两三页人工核对，专有名词和数字错得频繁。表格单独处理，转成结构化的表比塞进正文段落强得多。
每份资料带上元数据：部门、生效日期、版本号、适用范围。检索时能按时间过滤，避免拿到已经废止的版本。判断标准很直接：随便抽五份，能不能在一分钟内说清它是哪一版、管什么、谁维护。说不清，就是没整理好。
切分：按语义边界切，把标题带进去
按固定字数硬切有两种伤害：把一条完整的条款拦腰切断；把不相干的两段拼在一起。检索命中其中一段，另一段的信息就丢了。
更稳的做法是按标题层级切，一段只讲一个完整意思。每段开头拼上所属章节路径，比如「第三章 报销管理 → 3.2 差旅标准」，这样即使片段被单独召回，也不至于失去上下文。
相邻段之间留一成到一成半的重叠，边界处的定义和限定条件不容易丢。粒度按资料类型定：制度按条款，问答按一问一答，手册按操作步骤。单段控制在两百到五百字，太短缺上下文，太长主题被稀释。表格和清单不要切散，整块保留。
检索：先做二十条对照，再谈效果
准备二十到三十条真实问题，每条标注「应该命中哪一段」。题目从客服记录、群里反复问的问题里抄，不要自己编，编出来的问题模型一定答得好。
两个指标要分开看：命中率看该段有没有被召回，正确率看生成的答案有没有用对。命中低，问题在切分或索引；命中高但答错，问题在生成或提示词。混在一起看，只会得出「效果不好」这种没法行动的结论。
检索方式上，关键词和向量各管一半。编号、专有名词、产品型号靠关键词，同义表述和口语化提问靠向量。相似度低于阈值时，宁可回答「资料里没有」，也不要让它拼一个听起来合理的答案。
每次改切分、换模型、加资料，都把测试集重跑一遍。这份对照表是这套系统里唯一能证明「改了有用」的东西。
生成：答案带出处，允许说不知道
引用要落到具体文档名加章节，点开能回到原文那一段。只写「根据相关资料」等于没标。同时明确一条：资料里没有提到的内容，直接说没有。
回答顺序也会影响可用性，先给结论再给依据，比先铺三段背景再收口更省阅读时间。对外场景（客服、官网问答）要限制回答范围，或者加一道人工复核，错一次的成本比省下的人力高。
四类资料的配置差异
| 资料类型 | 切分粒度 | 必带元数据 | 测试题怎么出 |
|---|---|---|---|
| 制度与流程 | 按条款，两百到四百字 | 部门、生效日期、版本号 | 用「能不能报销、怎么申请」这类真实问法 |
| 产品手册与问答 | 按一问一答 | 产品型号、适用版本 | 抄客户原话提问，不用行业术语 |
| 会议纪要与项目文档 | 按议题切，保留结论与责任人 | 项目名、日期、参与方 | 问某次会议的结论和谁负责跟进 |
| 培训材料与课件 | 按知识点，一章一段 | 课程、章节、难度 | 问概念和操作步骤，检查是否跨章拼错 |
这张表的用法是：新收一批资料，先对号入座，把「必带元数据」那一列当成入库前的检查项。
建好了没人用，通常是三件事
不知道里面有什么。目录要能一层层点进去，再配一条每周更新的「本周新增」，让资料的存在被看见。会议类内容尤其容易沉底，实时记录转成纪要后应及时入库，做法可参考会议与课堂的实时记录。
入口不在工作流里。让人专门打开一个系统去提问，使用率一定低。问答入口要出现在群聊、工单页、文档侧边这些本来就待着的地方。
答错一次就被放弃。信任的建立很慢，一次明显的错答就够让人回到手动搜。先选范围窄但答得准的场景跑通，再扩。多人共用的场景还要处理权限，团队共享知识库的分层方式可以参考共享知识库的团队问答。
日常对话里沉淀下来的经验也是一种资料，把有价值的问答导出归档，比重新写一遍文档省力，导出方式见历史记录的搜索与导出。
什么情况下不该上知识库
资料本身互相矛盾。这不是检索能解决的问题，先做版本清理，再谈建库。
数据要实时。库存、价格、排班、订单状态这类字段，直接接数据库查询，塞进文档里只会得到过期的答案。
问题需要跨文档汇总计算。检索擅长找片段，不擅长把二十份表加总，这类需求交给表格工具或报表系统。
手头只有三五份文档。直接搜索原文更快，建库的维护成本高于省下的时间。
权限要求细到字段。先确认产品是否支持按人、按部门、按文档授权，不支持就不要把敏感资料放进去。
知识库落地速查
- 先定不收什么，再谈收什么
- 一段一个意思，标题路径拼进段首
- 二十条对照题，命中率与正确率分开看
- 答案必须能点回原文
- 资料有冲突时，先清版本再建库
