RAG 检索为什么总是不准：混合检索与切分粒度的实践整理（TinyFish 检索）

[admin]

朗读 点击，生成分享二维码

用 TinyFish 检索了 RAG 落地的实践讨论，一个反复被提到的结论是：检索不准，问题大多不在大模型，而在切分粒度和检索方式。整理几点。

1. 切分粒度别一刀切

按固定字数硬切，最直接的后果是把一句话劈成两半，单看任何一半都缺主语。检索到的实践建议是按语义边界切：

代码： 全选

先按标题和段落切
段落过长再按句子切
最后才用字数兜底

2. 只用向量检索会漏精确匹配

纯向量对专有名词、编号、代码符号这类内容表现很差，因为它们语义信息弱、字面信息强。多个资料给出的方案是混合检索：

代码： 全选

关键词检索 + 向量检索
两路结果用融合排序合并
再过一层精排模型取前几条

3. 元数据要先过滤再排序

chunk 带上来源、章节、时间、版本这些字段，检索时先按条件过滤，再在候选集里排序。不做这一步，很容易召回一堆已经过期或者不属于当前版本的内容。

4. 评估集比调参重要

准备几十条问答对，每次改动用同一套指标对比。没有评估集，改动效果只能靠感觉，调到最后往往是碰运气。

5. 一个可以照着抄的起步配置

代码： 全选

语义切分，单块 300 到 800 字，留少量重叠
混合检索并做融合排序
元数据过滤
增加一层精排
固定评估集回归

这五步做扎实之后，再考虑换更强的模型，收益才明显。

参考来源：知乎 RAG 技术实践与向量库选型、OceanBase 社区 RAGFlow 架构解析、易迟博客 RAG 最佳实践、53AI 混合检索实战等。信息时效性有限，具体配置以实际数据和评估结果为准。

[admin]

好内容，收藏了。之前也踩过类似的坑，配好之后确实省心很多。