第一步：盘点语料与授权
列出文档来源、负责人、版本与可见范围，标出可以进索引的部分。为什么先做这一步？因为语料权属不清时，后面所有工作都可能推倒重来；把不能用的文档提前剔除，比上线之后再清理要便宜得多。
第二步：切分与建索引
按条款、章节与表格切分，给每段打上来源、版本、生效日期与权限标签，再建关键词与向量两套索引。切分粒度要按问题类型调：制度问答适合按条切，技术手册适合按步骤切；切多细要看问题通常怎么问。
第三步：检索与生成
先按用户身份过滤，再做关键词与向量混合召回与重排，最后让模型基于片段作答并附出处。低置信度时给出拒答话术，把问题引到人工或工单，而不是强行生成一段看起来通顺的内容，这条边界要写进产品说明。
第四步：评测与运维
把评测拆成召回与生成两段，各自建样本与指标，按月复查。同时建立文档变更触发更新与失效标记，指定语料维护人。没有维护人的知识库，三个月后准确率一定下滑，这是最常见也最难补的坑，如何分工要在立项时就定。
适用与不适用
适合谁
- 文档量大、员工提问重复度高的企业
- 有明确语料负责人和权限体系的组织
- 需要答案可追溯的内部知识支持场景
不适合谁
- 语料极少、靠人工查询更快的团队
- 文档权属不清、无法确认可用范围的项目
典型场景
某保险公司的核保团队把条款、作业指引与常见问题接入检索，先按条款切分并标注险种与版本，再按岗位过滤权限。上线前用一百条历史咨询做召回测试，正确段落进前三的比例达标后才放开使用，拒答的问题统一转人工坐席。
可执行步骤
- 逐项列出文档的来源、负责人、版本与可见范围，剔除不可用的部分
- 按条款与章节切分，给每一段补上来源、版本号与权限标签，再做抽检
- 分别建立关键词与向量两套索引，接入重排后逐轮比较两边的召回效果
- 先按用户身份过滤权限再做召回，答案必须附出处，并设置拒答规则
- 按召回与生成两段分别建立评测集，同时指定语料维护人与更新节奏
常见坑
- 跳过语料盘点直接建索引，权属不清的文档混进来，上线后被迫整体下线，进度全部重来。
- 切分粒度过粗，一段里混着三个主题，召回之后模型只能答对其中一部分，用户以为它答错。
- 权限放在生成之后才过滤，模型已经读到敏感内容，等于没有防护，还把风险留在日志里。
- 没有语料维护人，制度更新后索引长期不动，答案逐渐失真，最后没人敢在业务里使用它。
自检与验收清单
- 语料清单是否包含负责人、版本号与可见范围
- 切分粒度是否与主要问题类型相匹配，是否抽检过
- 权限过滤是否在检索之前就已经生效，并留下记录
- 答案是否附出处，并支持在置信度较低时拒答
- 是否指定了语料维护人，并约定了更新节奏与范围
常见问题
四步里哪步最花时间？
语料盘点与切分通常占掉大半时间，也最容易被低估。很多团队以为难点在模型，实际是文档结构混乱、版本不清。把这段时间排进计划，比赶进度上线更划算，也能少返工一次。
要不要先做一个小语料试点？
建议。选一个文档结构清晰、问题集中的域，例如某类产品的售后手册，两周内能跑通全流程。小语料能把切分与拒答规则试出来，再扩到全公司时返工最少，权限也容易设计。
验收看哪些指标？
召回层看正确段落进前三的比例，生成层看答案是否忠于原文与引用是否准确，运营层看拒答率与人工转接量。三类指标一起看，才能判断系统是真的可用，还是只会答简单问题。