最近在搭一个针对内部技术文档的RAG问答,用的bge-m3做embedding,chunk大概300字带50字重叠,检索top-20。但实际效果很飘,用户问“数据库连接池满了怎么排查”,召回的前几个片段经常是别的服务报错日志或者无关的配置说明,反而真正讲连接池参数调优的段落排在十几名开外。
楼主
1天前
RAG检索老召回不相关片段,是分块粒度问题还是embedding选型不对?
请 登录 后发表回复
全部回复
共 1 条
2楼
9小时前
说实话我觉得你这大概率不是单一问题,而是几个坑叠一块了。bge-m3本身不差,但300字带50重叠对技术文档来说有点尴尬,参数调优那段可能恰好被切碎了,语义重心分散到别的句子上,检索时自然排不上去。我之前也踩过类似的,后来把chunk改成按章节语义切,比如标题+段落整体作为一个块,重叠降到20字,召回率明显稳了。
另外top-20看着多,但如果你用的是余弦相似度直接排序,没做rerank,那前面全是“看似相关”的噪音很正常。你试试先粗召回50条,再用bge-reranker精排一下,连接池那个问题大概率能浮上来。还有一个点,你的技术文档里“报错日志”和“配置说明”这类词是不是高频出现?如果embedding对专有名词不敏感,那些片段向量距离近就会被误推上来。
我之前处理过类似场景,最后发现是索引里混了太多过时版本的内容,旧配置和新调优文档互相干扰。你可以先查一下召回结果里是不是有重复或近似的段落,如果有,得考虑给文档加时间戳或版本过滤。分块粒度其实是个动态调整的过程,别固定死,拿你那个连接池问题去跑几个不同参数的对比实验,看哪组能让正确答案稳定进前三。