最近在做一个企业知识库问答,用的开源Embedding模型(bge-large-zh)加Milvus,文档切了512字符带overlap。本地测试top5召回看起来挺准,但一接到大模型(Qwen-14B)那边,回答经常瞎编,甚至不如不挂RAG直接问。我怀疑是不是我拼接prompt的方式有问题——现在就是把检索到的段落一股脑塞进system prompt里,没做重排序,也没过滤低分块。另外,文档里表格和图片比较多,切分后语义碎得厉害。有没有大佬遇到过类似情况?想请教下是重排序(比如bge-reranker)能救回来,还是我切分策略本身就得推翻?先谢过。
RAG上线后效果还不如直接调大模型,是我的检索环节废了吗?
全部回复
共 6 条说实话你这情况我太熟了,之前做合同审查也栽在检索上,但后来发现真不全是切分的锅。bge-large-zh的向量本身对长文档语义压缩就有限,512字符对表格和图片密集的内容来说基本等于硬拆,你召回看着准大概率是top5里有几段能对上关键词,但真正能支撑回答的细节早就被切散了。重排序确实能救一部分,尤其bge-reranker对“相关但不够精确”的段落打击挺狠,能帮你把低分噪音压掉,但前提是你得先把top20甚至top50的召回量提上来再重排,不然rerank只是在矮子里拔将军。另外拼接方式我建议别一股脑塞system prompt,可以试试把检索结果拆成“直接引用原文”和“基于原文推断”两部分,让模型明确知道哪些是事实依据哪些需要自己组织语言,不然它容易把碎片信息脑补成完整的答案。表格和图片这块,要么单独抽出来做结构化文本再单独索引,要么干脆对这些块用更大的窗口比如1024字符配合标题层级切分,不然语义连续性很难保证。最后你可以先做个对比实验,只喂一条最相关的段落让大模型回答,看它是不是还瞎编,如果还编那可能不是检索的问题是模型指令遵循能力不够,考虑换个更强的底座比如Qwen-72B或者加few-shot示例。
说实话你这情况我太熟了,刚上RAG那会儿我也被检索坑过。top5看着准没用,低分块混进去对模型的干扰比没检索还大,建议先加个score阈值卡到0.4以上试试。重排序肯定要上,bge-reranker对表格碎片效果挺明显的,但别指望它能救回切烂的表格——那种结构化内容最好单独走CSV或Markdown解析,512字符切分对表格就是灾难。另外Qwen对长上下文里夹带噪声很敏感,试试把检索结果压缩成要点式摘要再塞prompt,比整段丢进去靠谱。
重排序只能兜底,切分策略才是根子,表格图片得单独走OCR加结构化提取。
检索top5看着准不代表真准,先上reranker把干扰项压下去,再砍掉低分块试试,效果应该立竿见影。
表格图片多的文档,切分策略确实得推翻,建议按版面结构抽成markdown再切,否则语义碎了谁接都白搭。
重排序必须加,但你这切分策略也够呛,表格图片多的文档得按结构分段才行。
换bge-reranker试试,同时把512改成按语义切,低分过滤阈值也调一下,应该能救回来不少。
reranker真能救,但你这切法带表格图片确实得重搞,试试按段落结构切。
低分块过滤必须加,不然噪声全塞给模型,reranker治标不治本。