角色一：语料工程
负责清洗、去重、切分与元数据标注，把散落在共享盘与邮件里的文档整理成可检索的结构化语料。这项工作看起来琐碎，却直接决定召回质量；语料脏，后面的检索与生成再怎么优化也很难补救回来。
角色二：检索工程
负责索引、混合召回与重排，维护召回效果与响应延迟之间的平衡。为什么需要专人来管？因为检索参数与切分策略互相影响，改动一处就要回归验证，否则很容易在修好一个域的同时弄坏另一个域。
角色三：评测运营
负责建问答样本集、按召回与生成两段统计指标、跟踪未命中问题。这个角色要能判断答案是否忠于原文，而不只是看语句是否通顺，通常由熟悉业务的骨干兼任，如何选人，要按业务熟悉度与在岗时间定。
数据底稿：四项条件
文档要有可用结构、权限要能细分、版本要能识别、问答样本要能收集。四项里最容易被低估的是版本与权限：没有版本就无法判断新旧，权限不在检索层过滤就只能靠提示词约束，审计时根本说不清楚，这是最容易漏的边界。
适用与不适用
适合谁
- 文档分散、检索靠人肉查找的业务部门
- 有权限体系与文档管理规范的企业
- 愿意投入语料整理与样本标注的组织
不适合谁
- 文档完全无结构、也无人愿整理的项目
- 希望一次接入就能永久可用的团队
典型场景
某能源企业的技术资料分散在三个系统里，检索工程先把手册按章节切分并补齐版本字段，语料工程清理重复文件，评测运营从历史咨询里整理出两百条问答样本，业务负责人确认口径。四方每周对一次未命中清单，逐条补语料或改切分。
可执行步骤
- 指定语料工程负责人，明确清洗、切分与标注的交付标准与验收方式
- 由检索工程维护索引、召回与重排，并把每次参数变更都纳入回归验证
- 从历史咨询里整理问答样本，逐条标注正确段落、标准答案以及出处
- 业务负责人逐条确认答案口径，并明确哪几类问题必须拒答并转人工
- 把未命中的问题做成清单，每周分配补语料、改切分或换问法的任务
常见坑
- 把语料整理当成一次性工作，上线之后无人清理重复与过期文档，召回效果会逐月下滑得很明显。
- 检索参数被随意调整，又没有回归机制，往往改好一处、坏掉另一处，最后没人敢再动配置。
- 问答样本由技术团队自行编写，与真实问法严重脱节，评测结果虚高，上线之后落差很大。
- 权限只靠提示词约束，没有在检索层过滤，审计时既无法自证合规，也说不清谁看过什么。
自检与验收清单
- 语料清洗与切分是否有明确、可验收的交付标准
- 检索参数的每一次变更是否都纳入了回归验证
- 问答样本是否来自真实咨询记录，而非自行编写
- 答案口径是否由业务负责人逐条确认，并留下记录
- 未命中的问题是否有周度清单与固定的责任人
常见问题
一定要配四个角色吗？
小团队可以由两三个人兼任，但四类职责必须都有人认领。常见的失败是想省掉语料工程，让检索工程顺手清洗文档，结果两头都做不好，召回问题长期定位不到根因，最后只能整体重做。
语料整理要花多久？
取决于文档数量与混乱程度，通常比预期长。建议先选一个域做样板，把清洗、切分与元数据的标准定下来，再批量推进；标准没定就铺开，返工量会成倍增加，进度也很难向业务交代。
没有历史问答样本怎么办？
可以从工单、客服记录与内部群提问里抽取，再由业务确认标准答案。起步阶段几十条真实问题就够用，关键是覆盖不同问法与失败类型，而不是追求数量，也不是追求覆盖面有多广。