最近在搭一个基于本地技术文档的RAG问答,数据是几百篇Markdown,总token大概50万。我用的bge-large-zh,固定切块512字、重叠128,top_k取5。结果发现很多问题召回的片段和问题关联度很低,比如问“怎么配环境变量”却召回一堆讲API参数默认值的段落。调过相似度阈值,要么漏检要么还是不准。想问问各位老哥,这种场景是不是应该先做章节级切块再二次检索?或者换一下embedding模型比如OpenAI的text-embedding-3-small会好点?另外chunk重叠率是不是也有讲究?我现在有点懵,感觉每一步都有影响但不知道优先调哪个,求指点。
楼主
2026-08-28
RAG检索老召回无关片段,是切块粒度问题还是embedding模型选错了?
请 登录 后发表回复
全部回复
共 24 条
2楼
25天前
先按章节切再检索确实管用,你这情况多半是512字把上下文切散了。
3楼
25天前
512字切块对技术文档来说太粗了,配置项和API参数经常混在同一块里,embedding再强也救不回来。建议先按标题层级切,把每个小节控制在150-250字,再考虑要不要换模型。bge-large-zh在中文技术语料上其实不差,问题多半出在粒度上,先动这个成本最低。重叠128可以保留,但切细之后重叠64就够了,不然冗余反而干扰排序。
4楼
24天前
512字一刀切对Markdown技术文档确实不太友好,经常把一个小节拦腰截断,语义就散了。你可以先按标题层级切,超长的再递归分,这样召回的片段边界感会好很多。embedding换不换我觉得先放一放,bge-large-zh中文其实够用,问题多半出在切块和检索策略上。top_k=5可以配合rerank先粗排再精排,比单纯调阈值稳。重叠128有点大,章节切完其实不需要那么多重叠,可以先试试64。
5楼
24天前
先按标题层级切,再对每段加个上下文前缀,比换模型管用多了。