大家好，我是吴师兄。
如果你长期维护过一个真正上线的 RAG 系统，就一定遇到过一个非常真实的问题： 系统上线越久，回答速度越慢 。
开始时还能在 1 秒内出结果，但几个月后：
-
embedding 越算越多
-
向量库越来越大
-
re-rank 越做越慢
-
LLM 吞吐越来越吃力
直到某一天，业务部门跑来投诉：
“师兄，我们的智能助手怎么感觉比昨天又慢了？”
如果你只是做 demo，你永远体会不到这种痛；只有在真实业务中跑过 2～3 个月，你才会意识到：RAG 的调优不是“变快”，而是“防止持续变慢”。
这篇文章就基于训练营里的 RAG 项目经验、向量库优化资料（embedding/TLL/Milvus/HNSW/缓存链路）的内容，一次性系统给大家讲清楚：
1、为什么 RAG 会越跑越慢？
2、我们怎么解决？
3、面试官到底想听你说什么？
为什么 RAG 会“越用越慢”？
我们把问题拆成 4 条链路。
1）Embedding 越算越多 → 阻塞上游链路
Embedding 是 RAG 最贵也最耗时的操作。
随着系统运行：
-
新的网页内容不断进入
-
用户查询越来越多
-
动态增量文本越来越多
-
重复文本比例非常高（网页变化不大但仍重新算 embedding）
最终 embedding API 的 RT（响应时间）就会从 200ms → 800ms → 1500ms。
之前的文章里面也说过： embedding 缓存能减少 50%–90% 的重复请求。
如果没有 embedding 缓存，系统一定越跑越慢。
2）向量库规模膨胀 → 检索时间指数上升
Milvus/HNSW/IVF 的查询速度与向量规模有强相关：
-
10w 向量：几毫秒
-
100w 向量：几十毫秒
-
1000w 向量：几百毫秒甚至秒级
真正让 RAG 变慢的不是模型，而是：
向量库规模失控。
尤其是动态 RAG，每天都增量爬取网页，不做清洗、不做 TTL、不做分区。
这里讲三个关键点：
-
分区检索：按来源或时间过滤
-
过期向量清理：删除无关内容
-
HNSW 参数调优：efSearch / efConstruction
如果没有这些策略，RAG 会在 2 个月后彻底卡死。
3）重排序模型越来越重 → 延迟累积
很多团队为了提升准确率，会加一个 cross-encoder reranker。
但问题来了：
-
向量库大 → 召回量大
-
召回量大 → re-rank 更多
-
re-rank 更多 → 延迟线性上升
所以才说：
准确率是靠工程换出来的，不是靠堆模型。
如果业务规模变大，必须：
-
减少 re-rank 文档数量
-
提高召回精度
-
减少不必要的调用
否则 re-rank 会成为整个系统的瓶颈。
4）模型生成变慢 → Token 调用堆积
动态 RAG 的 Prompt 很容易变重：
-
拼接了大量检索结果
-
缓存没命中 → 重新检索
-
文档越多 → 输入越大
-
输入越大 → 生成越慢
系统整体吞吐量直接下降。
这里有一个很关键的策略： Prompt 构建要“稀疏化”，不是“堆叠化”。
RAG 越用越慢，怎么系统反向调优？
有一句很经典的话： “RAG 的优化不是调模型，而是调链路。”
下面这套反向调优方案，来自工程实践。
1）Embedding 优化：批处理 + 缓存 + 异步并发
a）批量调用 Embedding API
减少网络往返次数。
b）异步并发（asyncio/Semaphore）
OpenAI 高并发下延迟会飙升，要控制在 5～10 并发左右。
c）Embedding 缓存（Redis）
规范化文本后 hash 做 key。
Dynamic RAG 场景下，靠这三条就能提升 50%以上速度。
2）向量库优化：HNSW + 分区 + 清理 + 多副本
a）HNSW 索引（M=16、efConstruction=128）
比 IVF 稳定得多。
b）查询参数（efSearch）调优
efSearch 越大越准，越小越快。
c）分区检索（按时间/来源）
动态网页内容极度适合分区，否则会拖到全库。
d）向量库定期清理（过期策略）
不清理 = 无限变慢。
e）多副本（replica_number=4）
提升并发下的吞吐。
这套方案会让系统从 “越来越慢” → “持续稳定”。
3）答案缓存：只缓存高频问题（FAQ）
FAQ 类问题可以直接做答案缓存，首字时间能从 800ms 降到 20ms。
RAG 不是所有问题都要用 RAG。
高频固定问题直接 hit cache， 复杂问题走 RAG 流程。
这是工程上的“大智慧”。
4）Prompt 优化：只保留最有用的证据
我之前也讲过一个核心点： 检索越多 ≠ 回答越准。
实际上，检索越多 = 干扰越多。
Prompt 构建策略：
-
选择 top-3 或 top-5，而不是 top-20
-
对 chunk 做摘要
-
用 CoT 强制模型先“分析证据再回答”
这会让生成速度明显提升。
面试官到底在考什么？
这一题并不是在考“RAG 的概念”，而是在考你有没有做过真实落地项目。
如果你能从链路角度回答：
“RAG 越用越慢，是因为 embedding 累积、向量库膨胀、re-rank 过重、缓存缺失、链路工程没有优化。
我们通过 embedding 缓存、分区检索、向量缓存、答案缓存、多副本加载以及 Prompt 稀疏化等工程手段解决问题。”
面试官会直接判断：
这是做过项目的人，而不是看过博客的人。
结语
RAG 变慢，是所有工程团队都会遇到的现实问题。
但只要链路、缓存、索引、资源、Prompt 设计是正确的，系统不仅不会变慢，反而会越来越稳。
记住， RAG 是工程，不是魔法，越真实的业务，越依赖工程能力。
这也是为什么训练营里所有 RAG 项目都强调：
-
全链路调优
-
工程可解释性
-
系统级优化
-
缓存体系设计
-
异步并发
-
Milvus 调参
这些才是真正能拉开差距的能力。