RAG部署后检索结果总是不准，是分块粒度问题还是Embedding选型不对？

你这情况八成是分块太机械，bge对长文本确实也容易跑偏，建议先按章节切再试下混合检索。

说实话我觉得你这问题大概率出在分块粒度上，500字符固定切对中文技术文档来说太粗暴了，产品手册里“保修政策”和“安装步骤”往往就在相邻章节，硬切很容易把语义边界切断。bge-large-zh-v1.5本身不算差，但对这种长段落密集的技术文本，它的向量表示可能更偏向整体主题，而不是你问的那个具体意图。你top-k=5里混进不相关片段，恰恰说明召回阶段就没把候选范围锁对，而不是排序的问题。我建议你先按标题层级或者段落语义做自适应分块，至少保证一个块内只讲一个主题，然后再看检索效果。另外BM25+向量混合检索确实值得试，尤其你这种术语固定的场景，关键词命中往往比语义相似更可靠，成本也不高。还有个细节，query里“保修政策”这种偏口语的表述，跟手册里“保修期及责任范围”这种正式写法向量距离可能很大，做点query改写或者同义扩展会有帮助。你可以先拿十来个典型问题跑一下切块前后的召回对比，如果改善明显，那就基本坐实分块策略的问题了。

说实话你这情况我太熟了，之前做设备维修知识库也栽过跟头。固定500字符切分确实太粗暴，尤其产品手册里“保修政策”和“安装步骤”往往挨得近，但语义隔着一道墙，一个chunk可能同时截断了两块内容。我建议先按文档的标题层级做递归切分，比如用markdown头或者字体大小识别章节，至少把第一二级标题作为硬边界，这样至少能保住“语义完整段落”这个下限。Embedding方面bge-large-zh-v1.5本身不差，但2000页PDF总会有表格、多栏排版这些噪声，建议先做版面分析，把表格和正文分开处理，否则字符切分很容易把表头和数据拆散。另外混合检索值得试试，BM25对精确术语（比如型号、故障码）很管用，能补上纯向量检索对专有名词不敏感的短板。你还可以把top-k调小到3，先看前三段是不是真的围绕问题核心，如果还是偏，那多半是分块粒度的问题而不是模型选型。最后query改写别一上来就做，先记录用户真实问法，做几轮bad case分析，很多问题其实是检索排序没做好，不是query理解不行。

你这情况我也踩过坑，500字符固定切分确实容易把语义边界切碎，尤其技术文档里标题和上下文关联很强。建议先试试按Markdown标题或段落结构做递归切分，顺便把chunk size调大到800再看看。另外bge-large-zh对长文本检索还行，但query和doc长度差异大时效果会打折，混合检索BM25+向量基本是必加的，能兜底关键词精确匹配。你top-k里有没有观察过相关片段是排在后面还是压根没出现？这能帮判断是召回问题还是重排问题。

感觉问题大概率出在分块上，500字符对中文技术文档来说太粗糙了，很容易把“保修政策”和“安装步骤”硬塞进同一块导致语义互相干扰。bge-large-zh对长文本本身也不占优，你可以试试按标题层级先做语义切块，或者给每个块加上小标题前缀再embedding。混合检索值得加，BM25能帮你兜底那些关键词精确匹配的场景，但query改写可能优先级更低，先调检索源比改用户输入更直接。另外top-k=5不准的话，可以看看是不是chunk之间重复信息太多，试试降到3或者加个rerank。

你这个现象八成是语义检索的锅，bge对长文档细粒度信息本来就弱，换个BM25混合召回试试，分块倒是其次。

说实话我觉得你这大概率不是embedding的锅，bge-large-zh处理中文已经够用了，问题还是出在分块上。500字符固定切很容易把保修条款和安装步骤硬凑到一个块里，尤其产品手册这种结构化的文档，按标题或者章节去切会好很多。另外混合检索确实值得试，BM25能兜底关键词匹配，至少不会问保修政策给你返回安装步骤。你可以先拿几个失败case看看是召回就没召对，还是召对了但rerank没排好，这两条路排查成本都不高。

说实话，你这个症状我太熟了，我之前用固定窗口切PDF也栽过跟头。你那个“保修政策”返回“安装步骤”的例子，大概率是分块把同一个语义段落拦腰截断了，尤其产品手册里经常有表格和嵌套标题，500字符的硬切会把“保修范围”和“保修期限”这种强关联内容拆到两个块里，向量距离自然就远了。bge-large-zh-v1.5本身不差，但它是针对句子级语义优化的，对2000多页文档里那种段落级、跨页的指代关系，表现确实会打折。我当时的解法是先按文档结构做递归切分，比如把标题层级和表格识别出来当边界，再对每个块做小粒度补充，而不是一刀切。另外你说混合检索，我强烈建议你加上BM25，因为很多技术规范里的术语和型号，稀疏检索的精确匹配比向量靠谱得多，我试过RRF融合后，top-5的相关性提升非常明显。至于query改写，如果你用户输入比较随意，可以先用LLM做个轻量改写，把口语化的“保修咋算”转成“保修政策与期限”，但别过度依赖，否则延迟和成本都上来了。你现在的分块大小其实可以保留，但试试先按Markdown标题拆成章节，再对超长章节内部做滑动窗口，overlap调到100左右，我猜召回质量会好很多。

500字符固定切分对产品手册这种结构化的PDF来说确实太粗暴了，很容易把保修条款和安装步骤切到相邻块里，检索时语义边界模糊就会串味。bge-large-zh-v1.5本身中文能力不差，但长文本切碎后单块信息量太少，embedding反而抓不住核心意图，所以召回不相关片段很正常。我之前做技术规范库时也踩过这个坑，后来改成按标题层级+段落切分，再给每块加上章节路径的元数据，召回准确率提升挺明显的。你说的query改写和混合检索都值得试，BM25对“保修政策”这种关键词匹配很敏感，能补上向量检索漏掉的确切术语。不过建议先别急着上复杂方案，拿几十条badcase做个消融实验，分别换分块策略和加BM25看效果，不然容易一通操作下来不知道哪个起了作用。另外top-k=5可以试试先放大到10再用rerank精排，很多时候问题不在召回在排序。