过去两年，鼎上娱乐交付了十余个企业知识库项目。失败的案例有一个共同点：团队把精力放在模型选型和界面设计上，却把文档切分、权限继承和引用校验当作实施细节。上线后，用户问三次得到三个答案，很快就回到原来的群聊里找人。
知识库不是「把文件传上去」。它是一条从原始资料到可追溯答案的工程链路，任何一环偷懒，都会在回答里暴露出来。下面三条底线，是我们在项目复盘里反复确认过的。
底线一：按语义切，不按字数切
最常见的错误是设定固定长度，比如每 500 字切一块。这样做的后果是，一条完整的操作步骤会被切成两半：前一块讲「什么时候需要停机」，后一块讲「停机后如何复位」。检索命中前一块时，模型只能给出半截答案。
更稳妥的做法是按文档结构切分：标题层级、段落边界、表格与图注各自成块。表格必须整体保留，因为一行参数脱离表头就没有意义。切完之后给每块补上「来源文件、章节路径、版本时间」三项元数据，检索时才有过滤依据。
底线二：权限在检索前生效
知识库最容易出事的地方不是答错，而是答了不该答的内容。很多团队的做法是先检索再过滤，这在工程上很方便，但意味着无权限的片段已经进入了模型的上下文，日志里也留下了痕迹。
鼎上平台把权限校验放在检索之前：先用用户身份过滤候选集，再做向量与关键词召回。权限继承自源文件，文档移动或权限变更时自动同步。上线前还需要一次权限审计，重点检查三类账号：实习生、外包与离职未回收账号。
判断一个知识库是否可交付，不看它答得多流畅，而看它能否在越权提问时明确拒绝，并把这次拒绝记录下来。
底线三：每条结论都能点回原文
生成式回答的可信度来自可核对。平台要求回答携带引用片段编号与原文位置，用户点开就能看到依据。技术上这意味着三件事：分块时保留页码与段落锚点；重排后不丢弃来源信息；生成时约束模型只能使用给定片段。
当检索不到足够依据时，正确做法是拒答并提示「未在知识库中找到」，而不是让模型凭常识补全。拒答率不是越低越好，它反映的是系统的边界感。
三种常见的失败切法
- 整篇入库：一份 60 页的手册作为一个片段，检索命中后上下文超限，模型只能看到开头。
- 按页切分：跨页的表格与流程被割裂，页码成为唯一关联，回答经常缺半张表。
- 去重过度：把相似段落全部合并，丢失了不同版本的差异，用户拿到的是过时口径。
一份可以带走的检查清单
- 每份文档是否有明确的负责人和版本时间；
- 表格、流程图与参数表是否独立成块并保留表头；
- 权限是否在检索前过滤，是否有定期审计机制；
- 回答是否强制携带引用，找不到依据时是否拒答；
- 是否建立了至少 50 条的评测集，覆盖高频与边界问题；
- 是否有周度的错误复盘，把错例补回知识库或评测集。
知识库是长期资产，不是一次性交付物。鼎上娱乐在项目结束后通常会保留一个轻量的运营角色，负责每月检查新增文档、失效条款与错例回流。没有这个角色，再好的初始结构也会在半年内退化。
如果你正在评估知识库项目，可以先做一次小范围试验：选一个部门、二十份文档、五十条真实问题，用两周时间跑一遍完整链路。结果会比任何方案书都更有说服力。