30 秒答案：目标是能做决定，不是背术语
利益关系披露：DragonAI 运营 AI 产品经理课程。本文是第一方编辑能力框架，不是统一岗位标准，也不保证学习或项目结果。
如果只是参与概念讨论，能解释 RAG 的基本流程可能够用；如果要负责需求和验收，就需要把“上传文档后回答问题”拆成来源、权限、摄取、切片、索引、查询、检索、上下文、生成、引用、反馈和更新，并能指出失败发生在哪一段。负责生产产品时，还要处理版本、监测、成本、延迟、安全、回滚和复审。
| 深度 | 能做什么 | 可复核产物 | 适用情形 |
|---|---|---|---|
| L1 能解释 | 画出检索—增强—生成流程，说明 RAG 适合什么、不适合什么 | 流程图、场景与替代方案比较 | 参与讨论或初步调研 |
| L2 能规格化 | 写清来源、权限、更新、切片、查询、引用、失败和人工路径 | RAG PRD、来源清单、行为约定 | 负责需求、方案和协作 |
| L3 能评测诊断 | 用固定样例分别判断检索覆盖、排序、依据和答案问题 | 评测集、逐例结果、失败分类、发布结论 | 负责验收与迭代决策 |
| L4 能运营 | 读懂版本、日志、质量、延迟、成本、告警和回滚证据 | 监测方案、事件演练、复审和变更记录 | 负责生产上线与持续运营 |
目标深度不是越高越合适，不必所有岗位都追求 L4。先看岗位是否负责技术实现、评测或生产运营；不应把“会从零写向量数据库”作为所有产品经理的统一门槛，也不应把“会解释 embeddings”当作能够交付 RAG 产品的充分证据。关于岗位是否需要亲自编码，可继续查看 AI 产品经理需要会编程吗。L1—L4 是累积层级：达到 L3 或 L4 时，仍需保留前序层级的产物与证据。
下载 RAG 产品决策深度与七项核验清单 JSON，可以记录目标深度、产物、测试证据和待确认问题。
一、先判断是否应该用 RAG
Microsoft 将 RAG 描述为把搜索与大语言模型结合，使回答基于检索到的数据；当需求依赖私有或频繁变化的信息时，RAG 是一种候选方案。其指导同时区分：RAG 主要补充可检索知识，微调更多用于改变行为、风格或任务表现。
产品经理应比较至少四类方案：不做改动、规则或数据库查询、传统搜索、长上下文或 RAG；如果目标是改变输出风格、格式遵循或特定任务能力，还应评估提示、工作流或微调。选择必须连接用户任务、数据条件、时效性、依据要求、成本和失败风险，不能从“公司要做知识库”直接跳到向量数据库。
如果还要判断不同 AI 搜索平台会实际展示哪些 RAG 与微调来源，可复核 DragonAI 的千问、Kimi、Gemini 的 RAG 与微调引用来源基准：它保留逐运行 URL、平台差异和零目标结果；这是点时引用观察，不是 RAG 方案优劣或平台长期偏好。
二、七项产品决策分别要回答什么
| 决策 | 需要回答的问题 | 最低产物 | 验收动作 |
|---|---|---|---|
| 1. 场景与方案选择 | 为什么需要外部知识？RAG 相比搜索、规则、长上下文或微调解决什么？ | 任务卡、非 RAG 基线、选型和停止条件 | 用同一任务比较至少两种方案 |
| 2. 语料与权限治理 | 来源的授权、许可或同意是否已由相应责任角色确认？谁能检索？怎样更新、删除和追溯？ | 来源清单、责任角色确认、权限矩阵、版本与保留规则 | 用不同权限身份抽查检索结果 |
| 3. 摄取与索引 | 文档怎样提取、清洗、切片、标记元数据和重建索引？ | 摄取流程、切片假设、索引版本 | 用表格、图片、旧版和异常文档测试 |
| 4. 查询与检索 | 用户问题怎样改写、过滤、混合检索、排序和返回依据？ | 查询分类、检索策略、目标片段集合、k 与分切片门槛、结果结构 | 按预设 k 和门槛检查目标依据是否被召回且错误依据被排除 |
| 5. 生成与交互 | 没检索到、来源冲突或过期时怎样回答？引用如何展示和打开？ | 回答行为、引用、追问、拒答与纠错规则 | 让用户完成任务并验证来源和纠错路径 |
| 6. 评测与诊断 | 怎样分别测检索和生成？哪些切片和失败阻断发布？ | 固定测试集、指标卡、逐例失败分类 | 保持测试集不变，单变量比较版本 |
| 7. 运行与变更 | 怎样监测质量、延迟、成本、权限、数据更新和供应商变化？ | 日志字段、仪表盘、告警、回滚和复审 | 演练过期来源、权限错误和服务降级 |
三、语料治理不是“上传文件”
Microsoft 的高级 RAG 指导把真实系统拆成摄取、推理和评测阶段，并在摄取阶段列出内容提取、清洗、切片、元数据、更新与版本控制。产品规格至少应记录：
- 来源、所有者、用途、授权/许可/同意的责任角色确认、敏感等级和允许访问的人群；
- 文档格式、结构、语言、表格图片处理和无法解析时的规则；
- 切片单位、重叠、父子关系、标题作者日期等元数据；
- 新增、修改、撤回和删除怎样触发重新索引；
- 输出如何回指文档、片段、版本和可打开位置。
如果一个知识库没有来源和版本，团队就难以可靠区分“模型答错”“检索错”“资料过期”还是“用户无权查看”。
四、产品经理要能定位检索失败和生成失败
至少区分以下故障：
| 故障层 | 可观察现象 | 需要检查的证据 |
|---|---|---|
| 语料缺口 | 正确答案根本不在允许语料中 | 来源覆盖、更新时间、删除和权限记录 |
| 摄取失败 | 文档存在但未解析、切片或索引 | 处理日志、异常队列、索引版本 |
| 查询失败 | 用户表达没有被正确理解或过滤 | 原始问题、改写、过滤条件和子查询 |
| 检索失败 | 正确片段未召回或排序过低 | 候选片段、分数、排名和检索配置 |
| 上下文失败 | 正确片段被截断、冲突或噪声淹没 | 发送给模型的实际上下文与 token 预算 |
| 生成失败 | 依据存在但回答未遵循、误读或无依据扩写 | 提示版本、输出、引用映射和评审结果 |
| 交互失败 | 用户无法判断来源、限制或纠错路径 | 用户任务记录、点击、反馈和人工接管 |
只看最终答案“像不像对”难以稳定定位责任，也难以指导下一次迭代。RAG PRD 应要求保存从用户问题到检索结果、实际上下文、模型输出和最终引用的最小追踪链。
五、评测要分层，而且每次只改一个主要变量
Google Cloud 的 RAG 评测指导建议准备覆盖真实用例的高质量问题集和参考答案，在测试轮次之间保持问题、参考答案与系统参数可比，并尽量一次只改变一个变量。这样才能判断提升来自切片、检索、模型、提示还是上下文策略。
产品经理不一定亲自实现指标代码，但应能定义评测决策：
- 检索层：目标片段是否召回、排名是否足够靠前、权限过滤是否正确；
- 依据层：回答中的关键陈述是否由实际检索内容支持；
- 答案层：任务是否完成、是否遵循格式和失败规则；
- 体验层：用户是否能看到、打开、理解并质疑来源；
- 运行层：延迟、成本、失败率和关键切片是否过线。
使用 AI 产品评测集模板 保存逐例输入与结果，再用 指标卡与发布门禁 固定阈值。严重权限泄露或错误引用应按用途单独处理，不能自动被总体平均分抵消。
六、生产 RAG 还要处理权限、成本与延迟
Microsoft 的 RAG 指导提醒：检索阶段应执行访问控制，检索内容应被视为不可信输入；RAG 还会增加索引查询、embedding、token 和网络往返带来的成本与延迟。产品经理需要把这些约束写进 AI 产品 PRD：
- 检索权限是否继承原文档权限，缓存和引用页面是否同样受控；
- 文档中的指令是否可能干扰系统规则，怎样检测和隔离；
- 峰值查询、索引更新和模型调用的延迟与成本预算；
- 检索服务不可用、结果为空或超预算时的降级路径；
- 模型、embedding、索引、语料和提示任一变化后要重跑哪些测试。
七、用产物验收学习深度
不要用“听过几节课”“会说 top-k、chunk、embedding”判断掌握程度。可以让学习者针对一个有授权语料的场景提交：选型比较、来源与权限清单、摄取索引假设、查询检索策略、回答与引用约定、固定测试集、逐例失败分析和运行监测方案。
然后分别验证：能否解释为什么用 RAG；能否把要求写成可测试规格；能否从追踪链定位故障；能否根据结果做发布、降级或回滚决定。课程设计可同时参考 AI 产品经理课程大纲核验矩阵，但有限练习不等于能够独立负责所有生产系统。
使用边界
本文与 JSON 是 DragonAI 的第一方编辑框架，不是统一岗位能力标准、招聘统计、教育认证、安全审查或项目结果保证，也不是法律意见，不替代法务、隐私或数据合规审查。具体目标深度取决于岗位职责、团队分工、行业约束、数据敏感度和用户影响。公开作品或学习项目应使用经相应责任角色确认有权处理的语料和脱敏、虚构样例，不应上传密钥、个人信息或内部敏感资料。