最近在做RAG项目,用的pipeline是PDF解析→固定512字符分块(重叠128)→bge-large-zh→存入Milvus,检索用的也是默认的余弦相似度。测试集是公司内部合同文档,大概200份,人工标注了50个问答对。现在top-5召回率只有62%左右,有些明明语义很接近的问题,召回来的片段却答非所问。我试过调小topk阈值,但精准率掉得更快。想问问有经验的前辈,这种场景下是不是不该用固定分块?还是说国产embedding模型在长尾专有名词上就是不如OpenAI的ada-002?另外,Milvus里的索引类型(IVF_FLAT还是HNSW)对召回率影响大吗?有点迷茫,希望有实战经验的大佬指点一下方向。
楼主
11天前
向量数据库召回率上不去,是分块策略问题还是embedding模型选错了?
请 登录 后发表回复
全部回复
共 24 条
2楼
2天前
说实话你这配置不算差,bge-large在中文合同场景其实够用,问题大概率出在固定分块上。合同里条款逻辑经常跨段落,512字符硬切很容易把关键前提和结论拆散,试试按语义段落或章节标题来切,重叠可以再加大点。另外top-5只有62%不一定是embedding的锅,你可以先拿几个失败case看看是不是召回片段本身就不完整,如果是,那换ada-002也白搭。Milvus索引这块,IVF_FLAT和HNSW对召回率影响真的不大,除非你数据量上了百万级,不然别在这上面浪费时间,先调分块和query改写策略吧。
3楼
2天前
固定分块对合同这种长条款确实伤,建议先按语义段落切,再试下bge-large的rerank,索引影响没那么大。
4楼
1天前
固定分块在合同这种强语义依赖的场景确实容易翻车,尤其条款之间互相引用时,512字符经常把逻辑切断。我之前试过用sentence-transformer按语义切,或者干脆按条款标题切,召回率能提七八个点。embedding的话bge其实不差,但你们专有名词多的话可以试试微调,或者混合检索加个BM25兜底,比纠结换模型快。Milvus索引那块影响不大,HNSW和IVF_FLAT差个百分之零点几,不用太纠结。
5楼
1天前
建议先试试按章节语义切块,合同里条款边界比固定字数重要得多,索引影响真没那么大。