把一个部门的文档变成知识库：六周推进节奏与交付物

企业知识库项目最常见的失败，不是选型错了，而是一上手就想覆盖全公司。部门越多，口径越难统一，推进会一直卡在协调里。挑一个部门先跑通六周，拿到可复用的节奏再复制，反而更快。

下面这份六周节奏以部门为单位，每周给交付物和责任人。它不要求先买什么、先上什么模型，只要求每周结束时，有一样东西能被下一个人接着用。

一、问题不在工具，在于没有节奏

很多部门启动时开一场动员会，收上来一堆文档，然后没了下文：没人判断哪份是现行版本，也没人说清谁能看哪一层。

卡点通常集中在三处：资料口径没有主人，交上来的版本互相矛盾，谁也拍不了板；权限没提前定，上线才发现一线能看到管理层文件，只能返工重建索引；没有验收节点，做到哪步算成功说不清，项目就在“快好了”里一直拖。

这三处都不属于技术问题。技术能解决检索准不准，解决不了谁对内容负责。所以第一步是把责任分到人头上，而非先挑模型。

二、判断标准：六周结束时该有什么

判断一个部门的知识库有没有做成，不看界面，看下表六周节点是否都有交付物、是否都落到具体的人。

周次	本周目标	交付物	责任人	完成标志
第 1 周	资料盘点	文档清单（含来源、版本、生效时间、责任人）	部门业务负责人	抽十份文档，能说清所属业务线与版本
第 2 周	清洗与去重	入库清单、淘汰记录、待补版本清单	数据负责人	入库数、淘汰数、待补数三者能对上总账
第 3 周	权限设计	角色表、目录可见范围矩阵	部门负责人与 IT	每个角色都能说出自己看不到什么
第 4 周	接入与切片	切片规则、索引重建脚本	技术负责人	抽二十条提问，每条都能指回原文段落
第 5 周	真实提问评测	测试集、基线报告	业务负责人与技术负责人	三十条真实提问有完整命中记录
第 6 周	培训与交接	使用手册、更新流程、接手人名单	部门负责人	三名同事能独立完成一次提问与一次纠错

读表先看周次再看人：周次是顺序不是并行。第 1 周清单没对账，第 2 周清洗就没判据；第 3 周权限没定，第 4 周接入必然返工。

六周下来要留住四样东西：文档清单、权限矩阵、测试集基线、更新流程。前两样决定能不能开始，后两样决定能撑多久。

三、六周怎么走：三段推进

1. 第 1-2 周：把文档变成能对账的清单

第一周不做技术动作，只做盘点。按业务线拉清单，每份文档记四个字段：来源、版本、生效时间、责任人。扫描件单独标出来走识别；重复版本合并到最新一版，旧版标失效但不删除，留追溯依据。

第二周做清洗。标准很简单，三个数要能对上账：入库数量、淘汰数量、待补版本数量，加起来等于清单总数。对不上账的清单基本都是拍出来的，等检索不准时，就找不到原因出在哪环。

这段最容易被跳过，因为它看着不像在“做知识库”。但它决定后面所有环节的输入质量，返工成本也最高——切片策略改一次，索引就要全量重建。

2. 第 3-4 周：权限先定，再谈接入

第三周定权限，不是等上线再补。要做角色表和目录可见范围矩阵：哪些角色能看哪些目录，哪些内容对哪些角色不可见。矩阵要能让每个角色说出“我看不到什么”，说不出来就是没设计完。

为什么权限要放在接入之前？因为过滤条件必须进检索层，不能只做在界面上；事后补要重建索引，测试集也得重跑。顺序颠倒，是这类项目最常见的返工来源。

第四周做接入和切片。切片按结构切不按字数切——条款、表格、操作步骤各自成块，标题跟着块走。按字数硬切，答案就会从半句话开始，这是评测阶段最高频的失败原因。

3. 第 5-6 周：用真实提问评测，再交接

第五周的测试集必须来自真实提问，不能是整理过的标准问法。做法很朴素：找五位一线同事，把最近一个月问过老同事的问题写下来凑三十条，不加修饰，也别提前教他们怎么问。

评测看的不是答对多少条，而是每条回答能不能指回原文哪一段。指不回去的说明检索或切片有问题，先别怪模型。这份基线是二期改进的比较起点，缺了它无法判断后来有没有变好。

第六周做培训和交接。培训不是讲功能，是让三名同事现场独立完成一次提问和一次纠错。能独立做完才算交接完成，只会听讲等于没交。

四、成本与风险：三处容易低估

六周节奏里有三处支出容易被漏算，而且都不在采购单上。

清洗人力。这活看着像整理文件，实际要做格式判断、版本比对、内容取舍。建议按文档类型分组估工，别按总份数平均——扫描件和表格的单页耗时往往是文字页的数倍。

返工成本。切片规则改一次、权限范围调一次，索引都要重建。可行的做法是把清洗、切片、向量化做成可重入的批处理，改参数只跑增量。

交接后的维护。每月要有人看失败样本、更新文档、处理失效链接。这部分不在排期里，却是第二年主要的工作量，也是从能用变成好用的分界线。

还有一类不是钱的成本：权限设计失误。一线能搜到管理层文件不是效果问题，是事故，必须在第三周解决。

五、怎么验收：四份交付物落到人头

验收不看演示，看四份东西在谁手上、别人能不能接着用。

部门业务负责人交文档清单和测试集：哪些文档在范围内、版本对应关系、三十条真实提问及命中记录。这份东西决定系统答的是不是本部门的话。

数据负责人交清洗记录和更新手册：入库范围、淘汰原因、新文档谁审、旧文档谁下架。缺这份，半年后制度改了，系统还在按旧版本回答。

技术负责人交切片规则和调参记录：按什么结构切、召回多少条、怎么重排、上下文怎么拼。要写到别人能照着复现的程度，不是给自己看的笔记。

IT 或运维负责人交权限矩阵和排查路径：角色对应哪些目录、异常时先查哪一层、谁能改配置。建议留一次故障演练记录，证明这条排查路径真的走得通。

六、一个部门跑通，才有资格谈全公司

六周的价值不在做完一个部门，而在跑出一套可复制的节奏：清单模板、权限矩阵、测试集做法、交付物清单。第二个部门照着走通常四周能完成，模板现成了。

反过来，一上手就铺全公司，每个部门都要重新讨论口径、争权限，周期会拖到无法收尾，最后连第一个部门的效果都验不了。

如果一个部门都推不动，大概率不是技术问题，而是没人对内容负责，先解决责任归属再谈选型。想看完整做法可从企业知识库方案入手；关心数据不出内网，可以看私有化部署；要评估算力投入，可对比GPU 算力租赁与AI 推理部署；需要按部门人数和文档量估周期，联系我们。