最近在做一个垂直领域的RAG问答系统，数据主要是技术文档和操作手册，大概有5000多份PDF。用bge-large做embedding，chunk_size试了256和512，overlap设了20，但用户问一些稍微复杂点的问题，比如“xx模块的配置步骤和错误码是什么意思”，召回的前5个chunk里经常只有1-2个有用。是不是分块策略太死板了？还是说应该先做文档结构解析再分块？求有经验的大佬指点下思路，别让我一个人瞎调参数了😭
楼主
2026-07-17
RAG系统召回率上不去，是不是我分块策略有问题？
请 登录 后发表回复
全部回复
共 184 条
2楼
2天前
PDF不解析结构直接切就是白给，先按标题层级拆再合并试试。
3楼
2天前
先做文档结构解析吧，PDF按标题层级切比硬调chunk_size管用多了。
4楼
13小时前
你这情况我太熟了，去年做运维知识库的时候踩过一模一样的坑。说实话chunk_size调到256还是512根本不是核心问题，你那个query明显是复合型的，“配置步骤”和“错误码含义”大概率分散在文档不同章节里，靠固定窗口切出来的chunk天然就很难同时命中这两块内容。我建议你先别急着调参，把PDF的目录结构和标题层级解析出来，按章节+小节做语义分块，表格和代码块单独拎出来处理，效果会比现在好很多。另外bge-large对长文本其实没那么敏感，你可以在每个chunk前面拼上它所属的章节标题路径，相当于给embedding加了个上下文锚点，这个改动成本很低但提升挺明显的。还有一点，召回前5只有1-2个有用，你有没有试过加个rerank模型？bge-reranker对这种混合意图的query效果很直接，先粗召回20个再精排，比你在分块上死磕要快得多。5000份PDF量不算小，建议先拿一两百份做个评测集，不然你改了什么都不知道是好是坏。
5楼
12小时前
你这个情况大概率不是chunk_size的问题，5000多份PDF还带操作手册，文档结构解析这步基本绕不开。纯按字数切的话，配置步骤和错误码很容易被切到不同chunk里，用户问的又是组合型问题，召回自然拉胯。建议先按标题层级拆，把步骤和对应的错误码绑在一个chunk里，再考虑加个rerank或者查询改写，光调overlap救不了这种结构性丢失。