RAG项目上线后准确率暴跌，向量检索结果跟没调一样，求指点排查思路

3000多文档其实不算海量，问题大概率出在召回策略而不是索引本身。你试试把top5提到top20再配个rerank，看能不能把相关片段捞回来，法律文书这种长文本特别吃上下文窗口。另外并发上去响应慢，可能是向量检索没走批量接口或者没用缓存，查一下是不是在线服务里重复计算了embedding。

先查下召回阈值和rerank权重，全量数据分布变了，top5准不代表top1准。

并发飙到8秒大概率是向量检索没走索引或缓存，看看是不是全量扫描了。

这问题我太熟了，当初我们做医疗问答也栽在这上面。3000+文档看着不多，但分布密度一上来，向量空间的区分度其实会断崖式下降，尤其法律文书这种语义高度近似的文本，top5里可能全是长相相似但答非所问的段落。你提到召回里其实有正确片段，只是排序靠后，那问题大概率不在检索召回，而是在排序策略上，单靠向量相似度做最终排序在密集语义场景下基本必崩。建议先别折腾chunk和embedding了，直接上rerank模型，用cross-encoder那种，把召回top20重排到前5，效果立竿见影。另外并发高响应慢，很可能是你向量检索时没用索引加速，比如IVF或者HNSW，默认暴力扫描在3000维上会吃满CPU，8秒基本就是这里卡出来的。还有个隐蔽坑，线上数据是不是做过清洗或脱敏？有时候文档格式变了，比如PDF转出的换行符没处理，切出来的chunk全是碎片，语义被切碎了，召回自然乱。我建议你先把线上和本地的文档预处理流程逐行对比一遍，再在检索日志里把每个召回片段的得分和原文片段打出来，看看是不是某个特定类型的问题文档在干扰全局。最后，如果条件允许，给线上单独调低top_k，比如从5改成20，召回多但交给rerank去压，准确率能稳不少。

大概率是召回top5太浅+rerank没兜住，试试先拉回top20再精排，顺便查下3000文档的向量分布是不是有簇重叠。

先查rerank阈值吧，全量数据分布变了，top5里相关片段排后面很正常，阈值一刀切就漏了。

见过太多次这种本地好好的上线就崩的情况了，尤其法律文书这种专业领域，3000多份文档的分布密度和测试集完全不是一个量级。你日志里既然能看到相关片段只是排得靠后，那问题八成不在召回而在排序和截断——建议先检查一下top_k是不是设得太小，因为全量库下向量分布更拥挤，原来top5能命中的现在可能掉到top20去了，试试把召回数量放大到30到50，再叠加一个rerank模型看能不能把正确片段提上来。另外你说的并发性能问题，大概率是向量检索没走索引或者索引类型不对，HNSW的M参数和ef_search在数据量大了之后会显著影响延迟，还有如果是用pgvector之类的插件，检查一下是不是没建IVFFlat索引导致全表扫描了。还有个隐蔽的坑，很多法律文书里当事人名称、案号这种高区分度的实体，embedding模型其实处理得并不好，你可以试试在召回前加一层关键词过滤或者BM25混合检索，把精确匹配的结果强制提到前面。至于chunk_size，法律文书经常有跨段落引用的逻辑，单纯调大小可能没用，反而可以试试按条款语义切分而不是固定长度。最后想问你一下，线上环境用的embedding模型参数量是不是比本地测试时小？有时候为了省显存偷偷换过量化版本，那个对长文本的语义捕捉会明显变弱。

这问题太典型了，全量库一上，embedding的区分度不够就露馅了，尤其是法律文书这种专业术语密集的场景。你先别急着调chunk，重点看看3000篇文档里是不是有大量相似表述，导致top5被同类型内容霸榜，真正的答案被挤到后面。建议先做个召回数量的对比测试，比如把top5提到top20，看看准召率变化，同时给检索结果加个简单的关键词硬过滤，至少能保证“未找到”的情况大幅减少。另外并发飙到8秒，大概率不是向量检索本身慢，而是embedding调用或数据库连接池没做复用，这个单独压测一下就能定位。

先查下召回阈值和rerank权重，很多项目是top5太死加上重排没生效，全量后噪声就压不住了。

你这情况我太熟了，之前做医疗问答也栽过一模一样的坑。全量文档一上，top5里混着大量相似但无关的片段，真正相关的被挤到十几名开外，rerank没接或者模型太弱基本就是白搭。建议先别折腾chunk了，直接看召回阶段是不是被高频法律术语带偏了，比如“合同无效”和“撤销合同”在向量空间里距离比想象中近。可以试试把召回数从top5提到top20甚至top50，再上个强一点的cross-encoder做精排，bge-reranker-base至少能救回来一截。另外你那个并发变慢，八成是向量索引没做量化，或者HNSW的ef_search和M参数太小，线上千万级数据真的得用IVF_PQ或者重新调HNSW，不然CPU全耗在暴力遍历上了。还有个土办法，把线上日志里“未找到”的query抓出来，跟库里已有的文书标题做个BM25混合检索，大概率能发现是embedding表达不了的关键词匹配问题，比如案号、法条编号这种。最后建议看一眼是不是有文档切分后上下文被截断，法律文书很多条款是跨段落的，单独一个chunk根本看不出来在说啥。

全量库的向量分布和测试集差太多了，3000份文书里相似表述密度一高，top5的区分度自然就崩了，这跟模型关系不大。建议先看下召回里的相似度分数分布，如果前20名都在0.7左右挤成一团，那问题就出在检索粒度上，试试把chunk改成按条款语义切而不是固定长度。并发飙到8秒大概率不是向量库本身慢，而是embedding生成那步没做缓存，高频片段重复算太伤了。另外法律文书这种强专业场景，rerank最好用单独的交叉编码器模型，别依赖向量排序。

这题我熟，之前做案例库检索也栽过同样的坑。单测准不代表全量准，3000+文档下向量分布会明显拥挤，top5里相关片段被挤到第7、第8位太正常了，先别急着调chunk，去查查你这批文档是不是有大量相似表述的模板化内容，那玩意儿特别拉低检索精度。另外你提到并发飙到8秒，大概率不是rerank的问题，倒像是向量索引没走HNSW或者PQ压缩，全量暴力扫描了，建议先用日志确认下线上实际走的检索链路和本地是不是同一个索引文件。还有个土办法，把线上召回的top20全部打印出来看相关片段的真实排位，如果只是从第2掉到第6，那加个轻量rerank（比如bge-reranker-base）可能比换embedding模型管用得多。

3000多文档不算多，但法律文书这种专业领域，chunk切分和embedding的匹配度影响极大，建议先看下召回片段在原文里的上下文是否完整，很多“未找到”其实是切碎了语义。另外线上并发高响应变慢，大概率是向量检索没走索引或者缓存没做好，先查下是否全量扫描了。rerank这块如果没上，排序靠后很正常，但得确认是召回阶段就没排对还是rerank拉偏了。可以试试把线上失败case的query和召回top20单独拉出来做对比分析，看看是不是线上文档预处理和本地测试有差异。

这问题我太有同感了，之前做医疗问答RAG也栽在同样的坑里。你换个角度想，3000+文档的向量空间和单条测试时的分布完全不是一回事，top5可能都挤在某个密集区域，真正相关的片段掉到top20开外很正常。我建议你先别急着调chunk和embedding，把召回数量从5提到20甚至50，看看黄金片段到底排在第几位，这能直接定位是召回阶段的问题还是排序阶段的问题。另外，法律文书这种专业领域，bge-m3虽然通用性好，但未必比微调过的法律向量模型更懂术语关系，你可以试试用几百条人工标注的query-doc对做个简单评测，对比不同模型的召回命中率。还有个容易忽略的点，线上并发高时响应变慢，很可能是向量检索没走索引而是暴力扫描，或者缓存没命中，8秒这个量级更像是IO瓶颈而非计算问题，查下索引类型和内存占用。rerank环节如果你没加，那大概率就是核心短板，单靠向量相似度排出来的顺序，在长文档场景下经常被标题和开头段落带偏，建议加个cross-encoder，哪怕用个轻量模型，效果都会明显改善。最后提醒下，法律文书的术语一致性很重要，chunk_size调大后上下文完整但噪声也多，调小了又容易切碎法条，建议试试按条款边界做结构化切分，而不是纯按字符数硬切。

先查rerank吧，我上次也是top5不对，加了个交叉编码器立马见效。

全量库检索得看召回阈值和向量索引参数，HNSW的efSearch调大了没？

排序靠后基本等于没召回到，先查rerank阈值和向量相似度分布，别急着动chunk。

我之前也踩过类似的坑，3000+文档跟本地测试完全是两码事，问题大概率不在embedding而在召回链路。你可以先看下全量文档的向量分布，是不是某些类别文档太密集导致相似度挤在一起，top5里混进一堆无关内容。另外线上并发高变慢，建议查一下向量检索是不是走了暴力扫描，没走索引，或者索引参数没跟上数据量。还有，你试过rerank没？法律文书这种专业场景，bm25和向量混合召回再rerank，效果通常比单路稳很多。

我之前做合同问答也遇到过，召回片段确实在，但排序靠后，最后发现是分块太碎，语义被切断了。你调chunk_size的时候有没有同步考虑文档结构？法律文书有固定条款，按章节切可能比固定长度好。另外响应时间暴增，八成是没加缓存，高频问题命中率低，建议先查下查询日志看重复query多不多。可以试试先跑个离线召回率评估，看看top20里到底有没有正确答案，再决定是优化召回还是调rerank。

我猜你可能忽略了元数据过滤，法律文书里案号、年份、条款号这些维度不筛掉，语义相似的片段会互相干扰排序。candidate数量也可以拉大，比如先召回100条再rerank，别只盯着top5。还有线上8秒有点夸张，