RAG 在真实系统里的几个坑

RAG 最像哪类工程问题？我越来越觉得，它像“搜索系统 + prompt 工程 + 线上稳定性”揉在一起的混合体。

做 demo 的时候，RAG 看起来很简单：切 chunk、做 embedding、向量检索、把召回片段塞进 prompt，再让模型生成答案。但真正在系统里跑起来，你会发现它最难的部分从来不是“能不能跑”，而是“能不能稳定地对”。

我在做 Synapse（一个隐私优先的 AI 记忆系统）时，这一点体感特别明显：当数据变杂、问题变长、多端接入、模型混用之后，RAG 的问题会以一种很工程的方式出现。

这篇文章把我踩过的坑拆成 6 类，每一类都给一个可操作的处理方式。不是理论综述，是“真正在系统里会出问题”的那种。

1. chunk 切分：不是越大越好，也不是越小越准

RAG 的第一坑基本都从这里开始。

我一开始的直觉是“chunk 大一点，语义更完整”。结果线上表现是：召回经常不准，模型拿到上下文后更容易抓错重点，因为每个 chunk 里包含了太多无关信息。

后来我反过来切得很小，召回看似更精细了，但又出现另一个问题：上下文碎片化。模型能看见局部，但很难复原“这个片段在原文里到底在说什么”，回答会变得断裂、或者靠模型脑补把缝补起来。

最后我在 Synapse 里采用的是“按语义边界切分 + chunk 上限控制”的策略：

• 尽量按段落、标题、列表、代码块等自然边界切。
• 对过长段落再做二次切分，但保证每个 chunk 是一个“完整意思”。
• 给 chunk 设定一个上限窗口，避免把太多无关内容塞进一个向量。

Chunk 切分 Checklist

优先语义边界

先按标题/段落/列表切，再补“长度约束”，不要反过来。

保留局部上下文

需要时给 chunk 加少量 overlap，但只为保持语义连续，不要用 overlap 解决所有问题。

把原文结构写进 metadata

在向量库里保存 doc_id、段落序号、标题路径，后面做过滤/聚合会救命。

我对 chunk 的最终结论是：切分不是“预处理”，它是 RAG 系统质量的核心参数之一。

2. 检索不准：向量召回不是搜索的全部

很多人遇到“检索不准”会第一时间怀疑 embedding 模型，或者怀疑向量库的相似度算法。但在真实系统里，问题常常出在更朴素的地方：你到底检索了什么、过滤了什么、以及你怎么把多次召回合成一个可用上下文。

我在 Synapse 里做了三件事来对抗“召回看起来相关，但实际上无用”：

1. 混合检索：关键词 + 语义一起用。关键词能提供确定性锚点，语义负责补齐同义表达。
2. 过滤策略：对某些类型内容（比如模板、重复记录、极短片段）直接降权或过滤。
3. 结果聚合：不直接把 topK 全塞给模型，而是按 doc_id 聚合，避免同一篇文档的碎片占满上下文。

3. 上下文污染：把错的东西放进去，比不放更糟

RAG 最危险的失败模式不是“答不上来”，而是“答得很像，但其实来自错误上下文”。

我把这类问题叫上下文污染（context pollution）。常见来源有三类：

• 召回混入了相似但不同对象的内容（同名项目、同名人、相似概念）。
• 历史对话里的旧假设没有被清掉，被当成事实继续传播。
• topK 片段之间互相矛盾，但模型会自动选择一个看起来最顺的版本。

Synapse 里我做的应对策略是“先做约束，再做生成”：

• 先让系统对问题做轻量分类：这是查事实、要总结、要对比、还是要推断？
• 对“查事实”类问题，优先只给出引用片段，不让模型发挥太多。
• 对“总结/写作”类问题，再放宽一些生成空间，但强制返回引用来源。

一个很实用的小技巧是：把回答分两段。

1. 先给“证据”（引用片段摘要）。
2. 再给“结论”（模型生成）。

这样你能很快看出污染发生在哪一步。

4. token 问题：预算不是限制，是产品设计

token 预算在 demo 里像一个技术限制，在真实系统里更像产品设计边界：你到底允许系统在一次查询里调用多少“上下文”，以及你愿意为这个问题付出多少延迟和成本。

我见过最常见的两种失败：

• 上下文塞太多：token 爆炸、延迟变长、模型更容易走神。
• 上下文太少：模型开始脑补、回答缺乏依据。

Synapse 的做法是把 token 当作一等公民去管理：

• 给每类任务一个上限：例如摘要、问答、写作分别是不同预算。
• 先做召回，再做压缩：召回的片段先被“压缩成证据摘要”，再进最终 prompt。
• 允许“多跳”：如果一次召回不够，就做第二次，但每次都要有明确的停止条件。

Token 预算 Checklist

先压缩再生成

不要把 raw chunk 直接堆进 prompt，先做结构化压缩（bullet/证据表）。

把 stop 条件写出来

多轮检索/多轮生成必须有停止条件，否则就是无限烧 token。

把引用当作输出的一部分

强制 citations 会反过来约束模型少胡说，也能帮助定位污染来源。

5. 本地模型问题：隐私和质量不是二选一，但得分层

在 Synapse 里，一个核心现实是：本地模型隐私好、成本低，但效果通常不如云模型，尤其是长文本总结、复杂问题推理、稳定性。

我一开始尝试全本地化，踩到的坑很典型：

• 长文本总结效果差
• 复杂问题容易跑偏
• 响应时间不稳定

最后我做了模型分流（model routing）：

• 简单任务走本地模型（低成本、低风险）。
• 复杂任务走云模型（高质量、稳定输出）。
• 路由层根据任务复杂度、文本长度、隐私级别做自动选择。

这个取舍让我意识到：AI 系统很多时候不是“选最强模型”，而是做整体权衡。模型只是系统的一环。

6. latency 问题：别把 RAG 变成“慢而贵的问答机”

RAG 链路天然长：切分/embedding/向量检索/重排/压缩/生成。每一步都可能把延迟叠上去。你如果不主动设计，最后用户体验会变成“等 8 秒，得到一段看起来很像的答案”。

我在 Synapse 里做的延迟治理主要有三点：

1. 缓存：对高频 query、以及 embedding 结果做缓存（同时注意隐私边界）。
2. 分层返回：先返回“正在检索/已找到 N 条证据”的状态，再补最终答案，让用户知道系统在干什么。
3. 限制链路长度：对某些场景直接跳过重排/压缩，宁愿回答短一点，也别把延迟拖到不可用。

如果把 RAG 当作“一个组件”，你会只盯着召回率；但如果把它当作“一个产品能力”，你必须同时盯召回率、幻觉率、成本、延迟和稳定性。

收尾：RAG 的本质是系统工程

我写这篇文章的目的不是强调 RAG 多难，而是想把一个事实说清楚：

RAG 从 demo 到系统，差的不是一两个参数，而是一整套工程约束。

chunk 怎么切、检索怎么聚合、证据怎么压缩、token 怎么预算、模型怎么分流、延迟怎么治理，这些看起来分散的点，最后都会汇聚成同一个问题：

你到底在构建一个“能回答一次”的 demo，还是一个“能长期运行”的系统。

对 Synapse 来说，我更在意后者。