RAG项目上线后召回越来越差，有没有大佬遇到过类似情况？

说实话你这个情况太典型了，我上一个项目也踩过类似的坑。用户query积累影响embedding分布这个点，我觉得方向是对的，但更大概率是faiss索引里的向量和当前文档的语义产生了偏移，尤其是如果文档更新频率不高但用户问法越来越刁钻，旧向量会慢慢变成“死向量”。每天全量重灌其实挺浪费资源的，而且治标不治本，我后来改成增量更新+定期对高频query做伪文档注入，就是拿那些user query直接当文档做embedding塞回索引里，召回率回升很明显。另外query改写那层我觉得有必要加，但不是简单加个改写模型，而是先统计一下bad case，看是实体错配还是意图漂移，如果是发散问题多，可以试试混合检索，比如加个bm25兜底，别让向量一条路走到黑。想问你一下，你那边faiss用的哪种索引类型？IVF的话可能还要考虑nlist和nprobe的参数是不是该跟着数据量调整，这个经常被忽略。还有就是有没有做召回结果的人工反馈闭环？光靠指标监控有时候看不出来用户实际点没点中。

我们之前也踩过这个坑，后来发现是用户query分布漂移导致的，线上真实问法和测试集差太多，embedding空间里慢慢就偏了。全量重灌确实能缓解，但成本高还容易丢历史语义，我们改成按周增量更新加定期小规模重建。query改写这块建议加上，尤其问法发散的时候，先做一层意图聚类再召回，效果提升挺明显的。

你们每天全量重灌其实挺勤的了，但如果embedding模型或者faiss的index_factory参数一直没动，那问题大概率不在索引本身。我比较怀疑是query侧的漂移——上线后真实用户问法跟测试集差太多，历史query多了反而暴露了embedding在你们业务语料上的短板。建议先捞一批badcase看看是召回不到还是排到后面了，再决定要不要加query改写。意图识别那层别急着上，先确认是召回问题还是排序问题，不然容易白忙活。

你们这个每天全量重灌其实已经比很多人勤快了，但问题可能不在索引本身。我建议先看看线上真实query的embedding分布，跟测试集对比一下，大概率是用户问法跟你们当初构造测试集差异太大导致的。faiss索引本身不会因为query积累而漂移，它只是存向量做检索，真正变的是用户query的语义覆盖面。query改写和意图识别我觉得挺有必要，尤其发散问题多的时候，可以先做一层轻量聚类看看高频意图。另外每天全量重灌如果文档没怎么变，不如改成增量更新加定期评估召回指标，不然你根本不知道是哪天开始掉的。

先看看是不是新文档把老知识的向量挤偏了，faiss重建前最好做下聚类分析。query改写确实能救发散问题，但别指望它治本。