RAG 的理想很清楚，现实通常卡在第 3 步

用户问“这份报销制度里，住宿上限是多少”，系统在 1.2 秒内返回了一个完整答案，但数字错了。不是模型乱编，也不是文档里没有，问题出在 RAG 的第 3 步：系统检索到了相关页面，却没把真正关键的那一小段送进上下文。

这正是 RAG 最常见的落差。理想状态并不复杂：先检索资料，再让模型作答，以降低幻觉并接入企业私有知识。现实里，RAG 很少输在方向上，更多输在细节上。

难点常常不在模型，而在资料

很多团队第一次做 RAG，会把注意力放在 embedding 模型、向量库和重排器上。这个顺序没错，但容易忽略一个更基础的问题：知识库本身能不能被机器正确读取。

PDF 是典型问题源。标题缺失、表格错乱、页眉页脚混入正文，扫描件还会带来 OCR 噪声。结果是，检索系统召回了一堆“看起来相关”的碎片，真正关键的信息却被切坏了。模型收到的上下文不完整，最后自然会答得像那么回事，但并不准确。

因此，实践中最有价值的工作往往不是“换个更强的模型”，而是清洗文档、补齐结构、设计分块策略。这些工作不显眼，但收益直接。

分块不是越小越好，也不是越大越稳

很多教程喜欢讨论 chunk size，仿佛它是一个万能旋钮。实际情况并非如此。

块太小，语义完整性会丢失。比如“审批条件”在上一段，“金额上限”在下一段，向量检索可能只捞到半句。块太大，又会把噪声一起带进去，增加重排难度，也浪费生成阶段的上下文窗口。

更稳妥的做法是先按文档结构切，再按回答场景补。制度类文档适合按章节、条款切；FAQ 适合按一问一答切；接口文档适合按 endpoint 或参数说明切。没有统一最佳值，只有一个更实际的标准：这个问题能不能仅靠这一块独立回答。

检索命中，不等于答案可用

RAG 的另一个常见误区，是把 top-k 召回率当成成功指标。检索到了相关内容，只能说明“可能有答案”，不能说明“答案已经可用”。

真正影响体验的是这些问题：

• 检索结果是否互相矛盾
• 时间版本是否最新
• 排名第一的片段是否足以支撑回答
• 模型是否误读了引用内容

例如，公司制度 2024 版和 2025 版同时在库里，旧文档因为被引用更多，反而更容易排在前面。用户问的是当前规则，系统答成历史版本，整个链路在技术上并没有损坏，但业务结果已经错了。

这也是为什么许多线上 RAG 系统都要加入元数据过滤。部门、时间、文档类型、权限范围，这些字段并不复杂，但比“只做语义检索”更接近真实业务。

进入业务后，RAG 更像检索系统，不像聊天玩具

一旦进入业务场景，RAG 的核心就不再是“回答得像不像人”，而是“能不能稳定给出可追溯结论”。

这时会发现，引用来源、命中片段高亮、版本控制、权限隔离，往往比润色答案更重要。有些场景甚至不该让模型自由发挥，直接采用“检索 + 抽取 + 模板化回答”反而更可靠。不是模型不能写，而是没有必要每次都生成一段新话。

RAG 也不是在大模型前面加一个搜索框就结束了。它更像一条流水线：文档处理、索引构建、召回、重排、上下文拼接、答案生成、结果评估。任何一段处理粗糙，最后都会在用户的一句追问里暴露出来。

真正值得继续追问的，可能不是“RAG 还能不能做”，而是它应该和工作流、数据库查询、工具调用如何分工，以及哪些问题从一开始就不该交给 RAG。