RAG 项目需求访谈：做知识库前要问清楚的 20 个问题

这是一份给准备启动企业知识库的产品负责人、业务负责人和工程团队使用的 RAG 需求诊断模板。

建议用一轮 5 个工作日完成：访谈关键角色、抽查文档、整理真实问题，最终交付场景说明、文档边界、权限矩阵、初版评估集和试点 brief。它不承诺直接上线，而是帮助团队判断项目是否已经具备开发条件。

为什么先做诊断而不是先选技术

RAG 项目最常见的阻塞，不是向量数据库不会用，而是业务范围、有效文档、权限和验收没有共同答案。

如果团队只说“我们有很多文档”，技术选型没有依据。诊断的价值，是把模糊期待改写成可交付范围，也允许结论是“暂不开发”。

诊断周期与交付结果

| 阶段 | 主要动作 | 阶段产物 | | --- | --- | --- | | 第 1 天 | 确认目标角色与当前流程 | 场景卡 | | 第 2 天 | 盘点文档与所有者 | 文档清单 | | 第 3 天 | 梳理身份、权限和风险 | 权限矩阵 | | 第 4 天 | 收集真实问题并标注来源 | 初版评估集 | | 第 5 天 | 评审范围、责任和停止条件 | 试点 brief |

周期可按组织协调情况调整。没有文档所有者或无法取得样本时，不应为了赶时间伪造交付。

第一组：业务目标的 5 个问题

| 编号 | 访谈问题 | 记录字段 | | --- | --- | --- | | 1 | 知识库服务哪一个具体流程？ | 场景名称、流程节点 | | 2 | 谁提问，谁使用答案？ | 用户角色、接收角色 | | 3 | 当前怎样找到答案？ | 渠道、等待、返工 | | 4 | 哪类错误不可接受？ | 风险类型、业务后果 | | 5 | 第一版只解决什么？ | 支持范围、不支持范围 |

这组问题的交付物是一张场景卡。答案若仍是“提升效率”或“全员都用”，需要继续缩小。

第二组：文档范围的 5 个问题

| 编号 | 访谈问题 | 记录字段 | | --- | --- | --- | | 6 | 第一版接入哪些文档集合？ | 系统位置、格式 | | 7 | 谁确认文档当前有效？ | 所有者、审核人 | | 8 | 怎样识别版本和生效时间？ | 版本字段、状态 | | 9 | 重复或冲突内容怎样处理？ | 替代关系、裁决人 | | 10 | 哪些内容明确不能进入模型？ | 排除项、原因 |

这组问题产出文档清单。每项至少包含所有者、状态、权限、生效时间和同步方式。

第三组：权限与数据的 5 个问题

| 编号 | 访谈问题 | 记录字段 | | --- | --- | --- | | 11 | 哪些角色可访问哪些集合？ | 角色、文档范围 | | 12 | 回答能否展示原文引用？ | 引用策略 | | 13 | 问题、回答和候选能否落日志？ | 留存字段、期限 | | 14 | 是否涉及客户、合同、人事等敏感数据？ | 数据类型、审批 | | 15 | 越权或身份不明时怎样处理？ | 拒答、转人工 |

这组问题产出权限矩阵。权限必须在检索前生效，并覆盖原文、切片、缓存、日志和导出。

第四组：评估与运营的 5 个问题

| 编号 | 访谈问题 | 记录字段 | | --- | --- | --- | | 16 | 哪些真实问题代表日常工作？ | 问题来源、类别 | | 17 | 回答通过由谁判断？ | 评审角色、规则 | | 18 | 哪些问题必须引用或拒答？ | 风险级别、证据要求 | | 19 | 错误怎样区分资料、检索和生成原因？ | 失败分类 | | 20 | 上线后谁处理反馈与文档更新？ | 运营人、状态、复盘频率 |

这组问题产出初版评估集与运营责任表。具体样本数量应由问题类型和风险决定，不设置虚假的通用合格线。

可直接填写的访谈记录

每次访谈复制下面字段：

• 访谈角色与日期：
• 当前任务：
• 原始输入：
• 期望答案与证据：
• 不可接受错误：
• 当前文档来源：
• 权限与敏感字段：
• 人工确认点：
• 结果写回位置：
• 待验证假设：
• 明确不做：
• 责任人与下一次评审：

访谈后让受访者确认记录，避免项目组自行解释业务口径。

适合谁与不适合谁

适合：已经有明确业务负责人、能取得一类文档、愿意提供真实问题、准备从小范围试点开始的团队。

不适合：只想做展示页面、没有文档使用授权、希望一次覆盖全公司、要求系统替代正式审批或专业判断的项目。后者应先完成治理与风险评审。

常见失败与停止条件

场景没有接收人、文档没有所有者、权限只能口头描述、验收问题全部由开发者编写，都是暂停信号。

停止不是否定 RAG。诊断应说明缺什么材料、由谁补、满足什么条件后重启，避免项目在开发阶段反复返工。

FAQ

没有现成问题日志怎么办？ 先访谈一线人员，收集他们最近实际查询过的问题，并标记为人工采集。不要把项目组臆想的问题混成真实日志。

必须先整理全部文档吗？ 不需要。第一版只盘点与目标场景直接相关的一类文档。

诊断阶段要确定向量数据库吗？ 通常不需要。先让权限、更新频率、部署和规模约束清楚，再比较技术方案。

能否直接用准确率作为验收？ 不建议。还要分别定义引用、拒答、权限、失败状态和维护要求。

模板的可信边界与验证方式

本站目前没有可公开核验的客户交付履历或脱敏项目记录来证明这套 20 问模板已经在真实企业中产生效果，因此它应被视为 v0.1 公开草案，不是成熟咨询产品。文中的 5 个工作日是一次工作坊安排，不是对所有组织的交付承诺。

团队若采用，应记录模板版本、参与角色、实际耗时、没有问出的关键问题，以及这些缺口是否在后续开发中造成返工。至少完成一次真实但脱敏的诊断，并由业务、内容、技术和安全角色共同复核后，本站才应把它标为“已验证模板”。在此之前，任何收益结论都保持待验证。

行动入口

准备启动时，先把一条真实流程、三份代表性文档和一组近期问题放进访谈材料。按本文模板完成一次跨角色评审，再形成试点 brief。

第一次沟通只需要提交：目标用户、当前流程、文档位置、主要风险和业务负责人。材料不足时先补诊断，不急着进入开发。