夜雨聆风RAG 答非所问，90% 是因为喂给模型的资料本身就是脏的。
上一篇讲了 Embedding 和向量检索。你大概以为：把文档切成块、灌进向量库、查询时检索 Top-K，就完事了。
我以前也这么以为。
直到我帮一个电商团队排查"AI 客服老答错"的问题。他们已经用了 BGE-M3 做 embedding，Qdrant 做向量库，Reranker 也加了。技术栈看着很豪华。
但用户问"我买的那件羽绒服，XL 码还有货吗？"——AI 答的是"建议您去门店试穿"。
我打开他们的向量库一看，瞬间明白了。
他们把整个商品详情页（标题、价格、库存、尺码表、买家问答、底部推荐）一整页切成一块。XL 码库存的信息，被埋在"买家都问：这件衣服偏大还是偏小？"这种无关内容里。
模型检索到了这块，但这块里的"XL 码"指的是买家在讨论尺码偏差，不是库存。
模型诚实地答了"建议试穿"，因为它没看到"XL 还有 12 件"那行字。
这事我后来见太多了。
一、90% 的 RAG 质量问题，都出在文档
我问过不下 20 个做 RAG 的团队，召回不准、答非所问，根因都在哪？
答案几乎一样：文档没处理干净。
不是 embedding 模型不够好，不是向量库不够快，是"喂给模型的资料"本身就是一坨。
这就像你给一个特别聪明但视力很差的人请了一个图书管理员。管理员眼镜模糊、书架摆得乱、目录卡片写得不清楚——那他给聪明人递什么书，聪明人都答不好。
RAG 系统里的"图书管理员"工作就是三件：
- 解析：把 PDF、Word、网页变成纯文本
- 切块：把长文切成适合检索的小段
- 贴标签：给每段加上标题、章节、时间等元信息
这三步里任何一步出错，后面的 embedding、再检索、再 rerank、再 LLM 答，都是在错的地基上盖楼。
下面我把每个坑都讲一遍。
二、解析：别让模型看到"乱码"
很多团队栽在第一步：解析。
一个典型 PDF，里头有表格、有图片、有页眉页脚、有跨页段落。你用 PyPDF2 一拉，出来的是什么？
•表格错位成一坨文字
•页眉的"机密文件 - 内部"被重复 50 次
•跨页的段落被切断
•扫描件根本是图片，文字全是乱码
这种"文本"灌进向量库，等于给图书管理员一堆被撕成碎片的书。
一个反例：某律所把 300 份合同 PDF 灌进 RAG。用户问"合同里关于违约金的条款是怎么约定的？"
系统检索到 5 个 chunk，结果 3 个 chunk 里"违约金"这个词都来自页眉（每页都印了"违约金条款汇编"），正文里真正的违约条款一个都没召回。
模型老老实实说"根据文档，违约条款见第 X 页"——但用户点过去一看，页码是错的。
正例怎么做的？用专业的解析工具：
•unstructured：能识别 PDF 的版面结构，把标题、表格、列表分门别类
•pymupdf：处理结构化 PDF 的表格
•marker-pdf：开源的 PDF 转 Markdown，公式、表格、引用都能保留
•扫描件要先 OCR（用 PaddleOCR 或 Tesseract），但 OCR 后还要做版式还原——不然文字顺序还是乱的
这里有个经验法则：解析完成后，人工抽 5 份文档肉眼检查。如果人看着都费劲，模型不可能看懂。
三、切块：不是"切得越细越好"
解析完了，下一步是切块（Chunking）。
这一关最容易被忽略，但恰恰是决定召回质量的关键。
坑一：固定切分不管语义
最常见做法是 chunk_size=500, chunk_overlap=50——每 500 字切一刀，前后重叠 50 字。
听起来很合理对吧？
但实际跑起来问题一堆：
•一段话正好在 500 字处被腰斩，关键词在前面那段，答案在后面那段
•表格被切碎：表头在 chunk A，数据在 chunk B
•代码块被切碎：def 在 chunk A，return 在 chunk B
更糟的是：很多团队的 chunk_size 是拍脑袋定的——要么跟某个教程学的 512，要么跟某个库默认的 1000。从来没人测过自己业务场景下的最优值。
坑二：要么太大，要么太小
chunk 太大，召回里噪音多，模型被无关内容干扰。
chunk 太小，每块信息量不足，模型看了也不知道在说啥。
我做过一组实测。同样的 100 篇中文技术博客，3 种 chunk_size 对比：
256 太碎，1024 太泛，512 在这个场景最优。但这个最优值对每个业务都不同——你得自己测。
怎么切才合理？
三种主流策略：
1. 按语义切分（推荐）
不再按字数切，按"段落/章节/标题"切。
工具用 LangChain 的 MarkdownTextSplitter 或 LlamaIndex 的 SentenceSplitter——它们会保留段落完整性。
2. 父子块（Parent-Child Retrieval）
这是个聪明的玩法：
•检索时用小块（小 chunk），命中精准
•召回时返回大块（大 chunk），上下文完整
具体做法：把文档切成 200 字的小块（用于 embedding），同时记录每块属于哪个 1000 字的父块（用于返回给 LLM）。用户问问题时，召回小块的 ID，然后把对应的大块整块给 LLM。
这样既精准又有上下文。
3. 滑动窗口（不推荐生产用）
每 N 字切一刀，前后重叠 M 字。简单但容易把无关内容带进来。只适合快速跑通 demo。
四、元数据：让检索"自带筛选器"
切完块还不够。要给每块加元数据。
元数据就是"这块是关于什么的"的描述。常见字段：
•title（标题）
•section（章节）
•source（来源：哪个 PDF/网页）
•author（作者）
•date（时间）
•page（页码）
•tags（标签：产品/法务/技术/财务）
为啥要加？举个正例。
某制造业公司的内部 RAG，文档库里同时有 2019、2021、2023、2025 四版《设备维护手册》。
用户问"我们的离心机现在该用哪个型号的润滑油？"
如果没元数据，系统会把四版手册的"润滑油型号"都召回，模型直接懵——给用户列了 4 个答案。
加了 date 元数据后，系统先按时间排序，优先召回 2025 版，模型回答的准确率从 41% 涨到 89%。
反例也不少。我见过一个团队给每块加了 20 多个元数据字段，但没一个能用——因为他们加的是"自动提取的关键词"，结果全是"产品""服务""系统"这种废话。
元数据的关键：必须是业务相关、能被检索条件用上的字段。装饰性的元数据等于没加。
五、HyDE：当用户问得太模糊时，AI 替他想清楚
最后讲一个进阶技巧：HyDE（Hypothetical Document Embeddings）。
它的核心思想是：用户的问题往往很模糊，但"假设的答案"反而和真实文档更接近。
比如用户问：
"我们的退货政策是啥？"
这是个短问题，embedding 后在向量空间里是个孤零零的点。
但如果让 LLM 先假装回答一下（"我们公司支持 7 天无理由退货，需保持商品完好……"），把这个"假答案"拿去 embedding，它和真实政策文档的向量距离就非常近。
流程是这样的：
用户提问 LLM 临时编一个"假答案"（不用真的对） 用"假答案"的 embedding 去检索真实文档 把召回的真实文档 + 真实问题交给 LLM 出最终答案
听起来多此一举？但实测在很多场景下，召回率能提升 10%-20%。
代价是每次查询多花一次 LLM 调用（延迟 + 成本都涨）。所以只对模糊问题用 HyDE，对精准问题（如"文档第 3 章第 2 节讲了什么"）直接走向量检索就行。
六、父子块：小块检索、大块返回
最后讲一个最实用的 chunking 策略——父子块（Parent-Child Retrieval）。
它解决了一个核心矛盾：
•检索时希望小块——小块 embedding 精准，召回命中率高
•生成时希望大块——大块上下文完整，模型能看懂全貌
父子块的玩法是这样的：
把文档按 1000 字切成父块（完整上下文） 把每个父块再按 200 字切成子块（5 个一组） 只对子块做 embedding、存进向量库 用户提问，召回子块（精准命中） 用命中的子块反查它属于哪个父块 把整个父块（1000 字）交给 LLM
这样模型拿到的不是孤零零的 200 字片段，而是完整的章节上下文。
我们项目实测：召回率从 78% 涨到 91%，回答准确率从 71% 涨到 84%。最简单也最有效的一个工程优化。
七、一句话总结 + 行动清单
RAG 答非所问，90% 是因为喂给模型的资料本身就是脏的。
技术栈再豪华（最贵的 embedding + 最快的向量库 + 最好的 reranker），也救不了一个塞满乱码的向量库。
给你 5 条行动清单，明天就能用：
- 解析后人工抽检 5 份：肉眼看不懂的，模型也看不懂
- chunk_size 自己测一遍：256/512/1024 各跑一组召回测试
- 用父子块策略：小块检索，大块返回
- 元数据要业务相关：title/date/source/page，装饰性字段别加
- 模糊问题开 HyDE：精准问题直接走向量检索
做到这 5 条，你的 RAG 质量能上一个台阶。