从一次线上事故说起
凌晨两点，告警电话把我从床上拽起来。生产环境的RAG服务响应时间从200ms飙升到了8秒，CPU跑满，内存飙到90%。登录服务器一看，日志里全是重复的Embedding请求——同一个用户连续问了三次“公司今年的营收目标是多少”，系统每次都重新调用OpenAI的Embedding API，每次耗时1.2秒，三次就是3.6秒。更离谱的是，知识库里明明有这条数据的缓存，但缓存键设计得有问题，同一个问题因为带了不同的空格和标点，被当成了三个不同的请求。
这就是典型的“缓存没做好，服务器在裸奔”的案例。今天这篇笔记，我把踩过的坑和最终落地的方案拆开揉碎了讲清楚。
缓存到底要缓存什么
RAG系统里，缓存分两层：Embedding缓存和结果缓存。很多人只做结果缓存，觉得Embedding计算一次就够了，但实际生产环境里，Embedding的重复请求量远超你的想象。
Embedding缓存：把文本向量化后的结果存起来。同一个文本片段，不管它出现在文档里还是用户问题里，向量应该是一样的。OpenAI的text-embedding-ada-002模型，一次调用成本大概0.0004美元，看起来不多，但一天几百万次调用，账单能让你肉疼。
结果缓存：把用户问题和最终生成的答案存起来。同一个问题，如果知识库没更新，答案应该是一样的。但这里有个坑——用户的问题千奇百怪，“今年营收”和“2024年营收”可能是同一个意思，但缓存键不同，就查不到。
