最近在搭一个基于本地技术文档的RAG问答,数据是几百篇Markdown,总token大概50万。我用的bge-large-zh,固定切块512字、重叠128,top_k取5。结果发现很多问题召回的片段和问题关联度很低,比如问“怎么配环境变量”却召回一堆讲API参数默认值的段落。调过相似度阈值,要么漏检要么还是不准。想问问各位老哥,这种场景是不是应该先做章节级切块再二次检索?或者换一下embedding模型比如OpenAI的text-embedding-3-small会好点?另外chunk重叠率是不是也有讲究?我现在有点懵,感觉每一步都有影响但不知道优先调哪个,求指点。
楼主
1天前
RAG检索老召回无关片段,是切块粒度问题还是embedding模型选错了?
请 登录 后发表回复
全部回复
共 3 条
2楼
1天前
说实话我觉得你这问题大概率不是embedding的锅,bge-large-zh在中文检索上已经够能打了,换3-small未必有质变。你想想看,512字固定切块对Markdown文档来说太粗暴了,一个章节可能就两三百字,你硬切成两块,语义就被拦腰截断,检索的时候query配环境变量匹配到的可能是后半段讲默认值的碎片,这跟模型选啥关系真不大。我建议先做结构感知切块,按标题层级把每个章节当成独立块,如果章节超长再按段落或句子边界二次切,这样每个块内部主题更纯。至于重叠率,128字对512的块来说有点低了,尤其长文档里关键词分布散,建议至少256,或者干脆不用固定窗口,用递归切块按分隔符走。另外top_k=5对50万token的库可能不够聚焦,先提到10看看,但重点还是切块粒度,你先重构这一层再谈换模型。还有个小坑,bge-large-zh对长文本做embedding时,如果块超过512token会截断,你算过实际token数没?这个很容易被忽略。
3楼
1天前
环境变量这种高频词,建议先按标题抽成章节块再召回,比无脑切512靠谱得多。
重叠率不是关键,bge-large跑这种技术文档够用,问题八成出在切块太机械。
4楼
23小时前
你这情况大概率是切块粒度问题,512字对技术文档太粗了,先试试按标题和章节切块,embedding换不换倒不急。