RAG知识库PRD需求文档专业版提示词

角色定义与任务定位

请以资深产品经理兼技术解决方案架构师的身份，运用你对RAG（检索增强生成）技术栈与产品需求管理的双重理解，撰写一份用于指导开发团队落地的专业级PRD。你的核心目标是：将“构建一个RAG知识库”的模糊需求，转化为一份目标清晰、边界明确、技术方案具体、验收标准可衡量的权威需求文档，确保项目高效、高质量推进。

适用场景

• 为内部团队（AI研发、后端、前端）启动一个新的企业级RAG知识库项目时，提供权威的需求基准。
• 向客户或上级汇报RAG知识库项目的完整实施方案、资源投入与预期价值。
• 作为项目迭代或外部团队协作时，统一各方对需求范围、技术路径和交付物认知的核心依据。

核心提示词（可直接使用或组合）

• 文档目标：定义本项目RAG知识库要解决的核心用户痛点（如“解决非结构化文档信息检索效率低下与答案准确性不足问题”），并明确衡量成功的核心指标（如“检索准确率、答案相关性、响应延迟”）。
• 范围与边界：明确说明本知识库支持的数据源类型（如PDF、Word、内部Wiki页面、数据库表结构文档）、支持的查询类型（如事实问答、多步骤推理、文档摘要）以及明确排除不支持的范围（如实时流数据、语音对话、图像内容理解）。
• 系统架构：描述核心模块：文档接入与解析层、向量化与嵌入模型选择、向量数据库选型与索引策略、检索器（Retriever）与重排器（Reranker）配置、大语言模型（LLM）接口与提示工程（Prompt Engineering）方案、答案生成与溯源展示逻辑。
• 数据流程：详细说明从原始文档上传、预处理（文本提取、清洗、分块）、向量化、存储到用户查询触发检索、结果合成与返回的端到端流程与数据格式。
• 非功能性需求：定义性能要求（P99延迟、吞吐量）、准确性要求（召回率、精确度）、安全性要求（访问控制、数据脱敏）、可维护性（日志、监控、更新回滚机制）与扩展性（支持新数据源、新模型的成本）。
• 验收标准：提供可验证的测试用例，例如：“给定一份50页的技术白皮书，用户提出其中涉及的三个关键技术参数问题，系统应在3秒内返回答案，并正确高亮显示答案在原文中的出处段落。”

风格方向

• 文体风格：采用客观、精准、结构化的技术文档风格，避免营销性语言和模糊表述。
• 叙述逻辑：遵循“业务背景->项目目标->用户故事->系统特性->技术方案->非功能需求->验收与上线”的递进式逻辑。
• 术语使用：准确使用RAG领域专业术语（如嵌入模型、向量索引、TOP-K召回、链式推理），并在文档附录提供术语表解释。

构图建议（文档结构框架）

• 1. 文档首部：项目名称、版本历史、撰写人、评审人、文档状态。
• 2. 项目概述：项目背景、目标、成功指标、核心价值陈述。
• 3. 用户角色与场景：定义知识库的使用者（如客服人员、研发工程师、市场分析师）及其典型使用场景与用户故事（User Story）。
• 4. 功能需求详述：按模块（文档管理、检索查询、答案生成、系统管理）详细描述功能点、输入、处理逻辑与输出。
• 5. 非功能性需求详述：分点阐述性能、安全、可用性、可靠性等要求。
• 6. 系统架构与设计：提供系统架构图、数据流图、核心接口定义与技术选型理由。
• 7. 验收标准与测试计划：列出具体的验收场景、测试数据与通过标准。
• 8. 附录：术语表、参考文档、待决策问题列表。

细节强化

• 技术选型对比：在架构描述中，可简要对比不同向量数据库（如Milvus, Pinecone, Weaviate）或嵌入模型在本项目上下文中的选型考量。
• 提示词（Prompt）示例：在LLM集成部分，给出1-2个针对答案生成和溯源的关键提示词示例，例如：“请基于以下上下文回答问题。如果上下文不包含足够信息，请明确回答‘根据提供信息无法确定’。在答案后，列出用于生成答案的原文片段编号。”
• 错误处理：明确说明系统在文档解析失败、检索结果为空、LLM生成异常等情况下的降级处理与用户提示方案。
• 数据与监控：定义需要记录的关键指标（如查询量、平均响应时间、检索命中率、用户反馈满意度）及其监控看板呈现方式。

使用建议

• 撰写时，请将“核心提示词”部分的关键点，填充到“构图建议”的相应章节中，形成完整文档。
• 在“功能需求详述”部分，建议采用“作为[用户角色]，我希望[执行某操作]，以便于[达成某价值]”的用户故事格式，使需求更贴近实际场景。
• 评审时，重点检查“验收标准”是否足够具体、可测量、可测试，这是避免需求歧义的关键。
• 本方案为专业版框架，请根据项目实际复杂度，对技术细节进行增删，确保文档既完整又不冗余。