夜雨聆风摘要搭建AI助手知识库时，我们将产品PRD文档直接导入RAG系统，结果用户问"怎么创建商品"，AI一本正经地讲起了分布式架构。根因不在模型能力，而在知识工程的前置环节——文档结构、Chunk策略、多模态对齐。本文复盘了PRD文档接入RAG的3个致命缺陷（文档过期、语义密度不足、Chunk策略失配），并给出了一套文档标准化+语义分块+元数据标注的解决方案。核心结论：RAG的上限由源文档质量决定，AI产品的真正瓶颈在知识工程基础设施。
— — —
一、问题定义：PRD文档为什么不适合直接喂给RAG
1.1 场景
我们在商家工作台落地AI助手的第一阶段，做了最"自然"的决策——把产品现有的PRD文档全部导入知识库，让RAG（检索增强生成）系统自动检索并回答用户问题。
逻辑上成立：PRD是产品功能的权威描述文档，理论上应该是最优质的知识来源。
但第一次评测的结果是灾难性的。用户输入"商家怎么创建商品"，系统返回：
"本系统采用分布式架构，支持高并发、高可用、可水平扩展……"
这个回答在技术上没有错误——它确实来自某份PRD文档的"技术架构"章节。但它完全不是用户想要的答案。
1.2 这不是"AI不够聪明"，是知识工程的系统性缺陷
RAG系统的工作流程是：用户Query → Embedding向量化 → 向量相似度检索 → 召回相关Chunk → LLM基于Chunk生成回答。
这个pipeline中，LLM只负责最后一步"生成"。前四步的质量——文档内容、Chunk划分、Embedding质量、检索策略——决定了LLM拿到的上下文是否正确。
PRD文档的问题在于，它从源头就污染了整个pipeline。
— — —
二、根因分析：三个致命缺陷
2.1 缺陷一：文档过期——知识库里的"化石"
现象：我们导入的一份"商品创建"PRD，写于两年前。作者已离职，接手PM从未更新过。但RAG系统不知道这份文档是"过期的"。
技术根因：RAG系统的检索层基于向量相似度计算（通常是余弦相似度），只关心Query与Chunk的语义匹配程度。它不内置"时效性"判断——没有expired_at字段，没有version标记。只要向量相似度够高，即使是两年前的文档也会被排在召回Top-K中。
RAG检索公式（简化）：
score(q, d) = cosine_similarity(embed(q), embed(d))
这个公式里没有时间维度。如果我们在它之上叠加时效性加权：
score(q, d) = cosine_similarity(embed(q), embed(d)) × time_decay(d.updated_at)
但在知识库建设初期，我们根本没给文档打updated_at标签。这是元数据治理的缺失，不是算法问题。
2.2 缺陷二：语义密度不足——PRD本身就不是给机器读的
现象：一份功能描述为"支持商家有效创建商品"的PRD，经过Chunk切分后，每个Chunk的语义信息量极低。AI无法从中提取任何可执行的操作步骤。
技术根因：RAG系统的检索质量高度依赖Chunk的语义密度——即单位文本长度中包含的可检索信息量。
将PRD原文和理想的知识条目做对比：
• **语义密度**："支持商家有效创建商品"（信息量≈0） —— "创建商品路径：商家后台→商品管理→新建商品→填写SKU/价格/库存→提交审核"
• **可检索性**：低（"有效"是虚词，无检索价值） —— 高（每个动名词都是检索锚点）
• **可操作性**：零（读完后不知道怎么做） —— 完整（可直接作为操作指引）
Embedding视角：当文本语义密度低时，其向量表示趋近于"噪声"。在向量空间中，这类Chunk与大量无关Query的距离都很近，导致检索精度下降。这本质上是Garbage In, Garbage Out——差的源文档产生差的Embedding，差的Embedding产生差的检索结果。
2.3 缺陷三：Chunk策略失配——固定大小切分破坏语义完整性
现象：PRD文档包含大量截图（界面原型、流程图、表格），我们按固定500字符切分Chunk后，出现了"文字讲字段说明，配图是商品创建界面"的错位。
技术根因：常见的Chunk策略有四类：
• **Fixed-size** | 原理=按固定token数滑动窗口切分 | 适用场景=连续性强的长文本（如技术文档） | 对PRD的适配性=❌ 会切断表格/图片引用
• **Recursive** | 原理=按自然分隔符（\\n\\n, \\n, 。）递归切分 | 适用场景=段落清晰的文档 | 对PRD的适配性=⚠️ 能处理段落但不能处理图文关系
• **Semantic** | 原理=用Embedding判断语义边界，相似度跳变处切分 | 适用场景=结构化程度低的文本 | 对PRD的适配性=⚠️ 对图文混排的文档仍会错位
• **Document-aware** | 原理=解析文档结构（标题层级、表格、图片锚点） | 适用场景=**结构化文档（PRD、技术手册）** | 对PRD的适配性=✅ 但需要文档本身有清晰结构标记
我们的错误是用了Fixed-size策略处理结构化PRD——这相当于用切面包的刀去切一块有骨头的肉。
更根本的问题是：PRD文档本身没有结构标记。Markdown有#标题层级，HTML有<h1>标签，但大多数PRD是自由格式的Word文档，Chunk系统无法识别"这段文字对应的截图是哪个"。
— — —
三、解决方案：文档标准化 + 语义分块 + 元数据层
3.1 整体框架
解决PRD接入RAG的问题，不能只靠调Chunk参数。需要在三个层面同时治理：
┌─────────────────────────────────────┐
│ ① 文档标准化层（源头治理） │
│ PRD → Markdown结构化模板 → 知识条目 │
├─────────────────────────────────────┤
│ ② Chunk策略层（结构感知分块） │
│ 按标题+表格+图片锚点智能切分 │
├─────────────────────────────────────┤
│ ③ 元数据层（时效性+版本管理） │
│ 每条知识附加 version/updated_at/owner│
└─────────────────────────────────────┘
3.2 文档标准化：从"给PM看"变成"给AI看"
我们设计了一套PRD的知识条目模板，将自由格式的PRD转换为结构化Markdown：
## 功能：商品创建
- **路径**：商家后台 → 商品管理 → 新建商品
- **前置条件**：已登录，拥有商品管理权限
- **操作步骤**：
1. 填写商品名称（必填，≤30字）
2. 选择商品类目（必填，三级类目）
3. 上传商品主图（必填，≥800×800px）
4. 设置价格和库存
5. 提交审核
- **常见问题**：
- Q: 审核需要多久？ A: 1-2个工作日
- Q: 审核不通过怎么办？ A: 查看驳回原因，修改后重新提交
- **关联功能**：商品管理、类目管理、审核中心
- **更新日期**：2026-01-15
- **负责人**：张三
为什么这能解决问题：
1. **提高语义密度**：每个字段都是具体的、可检索的。用户搜"审核要多久"，Embedding能精确匹配"常见问题"区域
2. **提供结构标记**：`##`标题、`-`列表项、`**粗体**`标签，让Chunk系统能识别语义边界
3. **嵌入元数据**：`更新日期`和`负责人`直接写在文档中，检索层可以直接过滤和排序
3.3 Chunk策略：从固定大小到结构感知
切换到Document-aware分块策略后，Chunk的划分逻辑变为：
1. 以`## 功能：XXX`为Chunk边界
2. 每个功能模块作为一个完整Chunk（包含路径、步骤、FAQ）
3. 图片通过``内联在Markdown中，与文字保持锚定关系
4. Chunk大小控制在500-1000 token（兼顾检索精度和上下文完整性）
关键参数对比：
• **Chunk大小**：固定500字符 —— 动态500-1000 token
• **边界判定**：字符数 —— Markdown标题层级
• **图文关系**：随机错位 —— Markdown内联锚定
• **语义完整性**：经常被截断 —— 保证功能模块完整
3.4 短期补丁策略：Fine-tuning + RLHF标注
文档标准化是长期解，但需要跨团队协作和流程改造。在标准落地前，我们采用了短期补丁策略：
做法：将badcase（用户问"商品创建流程"，AI答错）逐条标注正确答案，回灌给模型的RAG优化管道。本质上是基于人类反馈的强化学习（RLHF）在RAG场景的轻量级应用——用人工标注的Query-正确答案对来微调检索排序和生成策略。
效果递减曲线**：我们观察到，前20个case的标注带来的提升最显著（满意度+12%），之后边际效益递减。这是典型的"补丁天花板"——标注能修复已知问题，但无法防止新问题的产生。这也印证了一个结论：**补丁策略只能治标，文档标准化才能治本。
— — —
四、效果验证
• **功能类query回答准确率** | 优化前=37% | 优化后=55% | 提升=+18pp
• **平均Chunk语义完整性** | 优化前=~60% | 优化后=~90% | 提升=+30pp
• **"PRD内容导致"的badcase占比** | 优化前=50% | 优化后=25% | 提升=-25pp
准确率从37%提升到55%，主要归功于两个动作：Chunk策略优化（+10pp）和文档标准化模板试点（+8pp）。
— — —
五、核心启示
5.1 可迁移的方法论
1. **RAG的上限由源文档质量决定**。模型再强，也补不了知识工程的欠账
2. **Chunk策略要与文档结构匹配**。结构化文档必须用结构感知分块，Fixed-size只适用于无结构文本
3. **元数据是RAG的第一道过滤器**。在向量检索之前，应该先用元数据（时间、作者、版本）缩小候选集
4. **分两层解决问题**：短期用RLHF标注补丁止血，长期用文档标准化根治
5.2 行动建议
• **P0**：切换Chunk策略为Document-aware —— 立即减少图文错位问题
• **P1**：设计PRD结构化模板，试点2-3个核心功能 —— 提升语义密度和检索精度
• **P2**：建立知识条目元数据标准（时间/版本/作者） —— 为时效性治理打基础
• **P3**：搭建标注管道，持续收集badcase —— 支持RLHF持续优化
— — —
但PRD文档的问题只是冰山一角。
解决了"源文档质量"，下一个问题随之而来——知识有时效性，但RAG系统不知道哪份文档是最新的。
1月用户问"今年有什么促销"，系统召回了去年12月的"年终大促"文档——因为它的关键词匹配度更高。年货节的新文档明明就在知识库里，但系统"看"不到它。
这不是源文档的问题了，这是检索策略的问题。
下一篇文章，我们来拆解知识库的时效性困境。
— — —
关注我，一起见证一个AI产品经理的成长。
更多干货点这里↓