一提到 RAG，很多团队最先想到的问题都是：
- 检索准不准
- 命中率高不高
- 回答是不是比纯大模型更靠谱
这些当然重要。
但真正把 RAG 项目做上线之后，你会发现最容易出问题的，往往不只是“检索不准”。
更常见的情况是：
- 文档明明更新了，回答还是旧的
- 用户问到了不该看到的内容
- 检索链路变慢了，但团队不知道慢在哪
- 改了一次 Prompt，效果突然变了
- 某个知识源出问题了，但没人知道是哪一段链路出了错
也就是说，RAG 项目上线后的难点，往往不在“把检索做出来”，而在“让整个检索链路长期稳定、可控、可优化”。
---
## 一、坑 1：召回太多，上下文越来越胖
这是最典型、也最容易被忽视的坑。
很多团队的默认思路是：
**为了保险，多召回一点。**
于是每次查询都带上：
- 更多文档片段
- 更多候选结果
- 更多上下文说明
短期看，好像回答更稳了；
但长期看，副作用非常明显：
- 输入 Token 持续上涨
- 延迟同步变长
- 每次请求越来越贵
最糟糕的是，团队会误以为“这是正常增长”，直到账单明显失控。
---
## 二、坑 2：没有重排序，相关信息被噪音淹没
很多 RAG 系统的召回并不是完全没命中，而是：
**命中了，但真正有用的信息没有排在前面。**
这会导致两个结果：
1. 无关内容进入上下文，挤占了 Token 预算
2. 真正重要的信息反而被淹没，回答质量下降
这类问题的危险在于：
- 团队会误判为“模型效
