RAG知识库产品需求写作高阶版提示词

角色定义与任务定位

你应当以资深产品经理兼知识库架构师的身份，结合RAG（检索增强生成）技术特性与知识库构建全流程，撰写一份逻辑严谨、细节完备的高阶产品需求文档（PRD）。你的核心目标不是简单罗列功能清单，而是通过清晰定义用户意图、知识源映射、检索策略与生成质量，指导研发团队实现高召回、低幻觉、可迭代的企业级知识库系统。

适用场景

• 面向AI知识库产品（如企业内部FAQ、客服辅助系统、文档问答平台）的产品需求构建阶段
• RAG系统从0到1或迭代升级时，需要规范化需求文档给开发、测试、算法团队
• 跨部门沟通知识库建设方案，需统一语言与评估标准
• 产品经理撰写技术侧PRD，需要兼顾业务价值与工程可行性

核心提示词（可直接复制使用）

• “定义RAG知识库的核心业务场景，明确用户查询的典型意图类型（如事实查询、流程指引、文档对比），并给出意图与知识源字段的映射关系表。”
• “针对非结构化文档（PDF、网页、Markdown），写出智能分块策略的详细要求：分块方式（递归/语义/固定长度）、重叠窗口大小、分块最大token数，以及如何处理表格、列表、代码片段等特殊元素。”
• “列出检索召回阶段的关键需求：嵌入模型选型要求（BGE/M3E等）、混合检索（稠密+稀疏）权重配置、重排序（Reranker）模型部署方式，以及多路召回合并后的Top-K过滤条件。”
• “明确生成阶段的幻觉控制机制：上下文窗口截断策略、引用溯源标记要求（必须输出对应文档段落ID）、模型回答长度上限与无需回答时的兜底话术模板。”
• “写出知识库冷启动与增量更新方案：初始数据清洗规则（去重/格式统一/元数据提取）、增量同步触发方式（定时/回调/手动）、版本回滚与数据一致性校验要求。”

风格方向

• 技术严谨：使用标准术语（如chunk overlap、recall@K、reranker score）而不回避复杂度
• 结果导向：每条需求写明验收标准（例如“检索响应时间≤500ms，准确率≥92%”）
• 分层表达：先写业务逻辑，再写技术约束，最后写边界条件，层次分明

文档结构建议（构图参考）

• 背景与目标：说明知识库要解决的核心痛点（信息分散/回答不一致）、预期指标（首次解决率提升30%）
• 范围定义：明确纳入与排除的知识源类型（如只支持PDF与网页，排除视频字幕）
• 功能列表：按模块维度拆分（数据接入、文档解析、索引构建、检索服务、生成接口、管理后台）
• 非功能需求：可用性（99.9%）、并发量（QPS 200）、数据安全（私有化部署/权限分级）
• 数据流图：用文字描述用户查询→意图路由→多源检索→融合→重排序→上下文组装→LLM生成→溯源标记→返回的完整链路
• 接口定义：列出关键API的输入输出示例（如query接口要求传入user_id、question、temperature）
• 评估指标：离线指标（RecallNDCG）、在线指标（用户满意度打分、回答采纳率）

细节强化方向

• 多模态处理：文档中的图片、图表需指定OCR或视觉语言模型解析方案，并定义是否融入检索上下文
• 元数据设计：每个知识块至少附带上层文档标题、页码、更新时间、权限标签，用于过滤与溯源
• 查询改写需求：用户提问可能模糊或错别字，需明确是否需要增加查询改写/同义词扩展模块
• 反馈闭环：设计用户对回答的点赞/点踩、纠错输入，并作为后续重训练或规则调整的依据

使用建议

• 实际编写时，先根据核心提示词写出每个模块的骨架，再结合具体业务领域（医疗/法律/电商）填充示例与约束
• 与算法团队对齐技术选型后，再固定需求细节（如分块大小、模型版本），避免过早承诺导致后期返工
• 可将本文的结构化提示词直接作为PRD模板的目录，逐条扩展，确保覆盖RAG全生命周期