最近在做一个人事政策问答的RAG,用的bge-m3做embedding,chunk大小设的512,重叠64。检索出来的top5片段相关性看着还行,但拼在一起喂给qwen2.5-7b之后,回答经常前后矛盾,比如前面说年假5天,后面又说10天。我怀疑是切片把完整的制度条款拦腰截断了。试过调小chunk到256,但召回率又掉了。也试过让LLM先总结每个片段再合并,速度慢得没法用。有没有大佬遇到过类似情况?是应该改切片策略(比如按markdown标题切),还是换rerank,或者干脆改生成端的prompt?求个实操思路。
楼主
2026-08-26
RAG检索到的文档太碎,直接拼给大模型效果反而变差怎么办?
请 登录 后发表回复
全部回复
共 23 条
2楼
24天前
人事政策这种文档确实容易踩这个坑,条款之间经常有“除……外”“符合以下条件之一”这种交叉引用,512切完正好把前提和结论分到两个chunk里,检索出来看着都相关,拼一起就打架了。我建议先别急着换rerank,那个解决的是排序问题,解决不了片段本身语义不完整。你可以试试按markdown标题或者条款编号做父块切分,检索还是用小的子块去匹配,但喂给模型的时候把整个父块带上去,这样既保住了召回精度又保住了上下文完整。另外重叠64对政策类文档可能不够,条件句往往跨得比较远,加到128试试。还有个偏方是在prompt里明确让模型遇到冲突时以更具体的条款为准,或者干脆要求它把冲突点列出来别硬答,能减少那种自相矛盾的输出。qwen2.5-7b本身指令跟随还行,但上下文一长容易丢中间信息,top5拼起来要是超过三四千token,考虑砍到top3加父块展开可能比top5碎片更稳。
3楼
20天前
按markdown标题切确实管用,我人事政策库这么改完矛盾少多了。
4楼
15天前
按markdown标题切+加个rerank基本能解决,条款被拦腰截断是元凶,拼之前去个重也管用。