‍♂️ 个人主页小李同学_LSH的主页✍ 作者简介LLM学习者 希望大家多多支持我们一起进步如果文章对你有帮助的话欢迎评论 点赞 收藏 加关注目录一、先说结论RAG 的第一道门槛不是模型而是文档颗粒度1. 你“拿什么去检索”2. 你“拿什么去喂模型”三、Chunk 到底怎么切先搞清楚“切分目标”是什么1. 足够短便于检索2. 足够完整保留语义闭环3. 足够独立脱离上下文也能大致看懂四、Chunk 太大和太小分别会出什么问题1. Chunk 太大典型症状2. Chunk 太小典型症状五、Chunk Size 到底怎么定1. 先看你的文档类型2. 再看你的问题类型3. 一个工程上可用的起点七、TopK 到底怎么调不是越大越保险1. TopK 太小典型症状2. TopK 太大典型症状八、Rerank 为什么经常决定了 RAG 的上限九、Chunk、Overlap、TopK、Rerank 应该一起看而不是分开调1. Chunk 越小TopK 往往要更大2. Chunk 越大TopK 可以更小但噪声可能更高3. Overlap 越大冗余越多TopK 和 rerank 压力也会增大4. TopK 越大越需要 rerank做 RAG 的人最后几乎都会被同一个问题折磨为什么文档明明入库了检索也能命中答案还是不准很多人第一反应会去怀疑embedding 模型不行向量库不行大模型不行prompt 不行但真正做过几轮调试之后你会发现一个特别容易被低估、却又特别关键的环节往往是文档分块。因为 RAG 不是“把整篇文档塞给模型”而是先把文档拆成 chunk再去做向量化、召回、重排和生成。一旦 chunk 切得不合理后面每一层都会跟着出问题chunk 太大召回不准chunk 太小语义不完整overlap 太少关键信息被切断TopK 太大噪声太多TopK 太小关键信息漏掉没有 rerank最相关的内容不一定排在前面所以这篇文章我想只讲一件事RAG 的效果上限很大程度上取决于你怎么切文档以及怎么把召回结果控制在合适范围内。这篇会把 4 个最核心的问题讲透Chunk 到底怎么切Overlap 为什么重要TopK 到底怎么调Rerank 为什么经常是效果分水岭一、先说结论RAG 的第一道门槛不是模型而是文档颗粒度很多人把 RAG 想成这样一条链用户提问 - 检索 - 大模型回答但真正工程里更准确的链路是原始文档 - 清洗 - 切分 Chunk - 向量化 - 检索 - 重排 - 生成也就是说检索并不是从“文档”开始的而是从chunk开始的。后面无论是 embedding、召回还是 rerank操作对象都不再是原始文档而是这些 chunk。所以你可以把 chunk 看成 RAG 里的“最小检索单元”。1. 你“拿什么去检索”检索不是在文档级别做的而是在 chunk 级别做的。所以 chunk 的颗粒度直接决定向量表示的语义粒度。如果 chunk 太大一个 chunk 里可能同时包含定义举例额外说明无关背景旁支内容这样 embedding 后向量语义会被“平均化”最后检索就会变成它大概相关但不够精准。2. 你“拿什么去喂模型”即使召回命中了如果 chunk 太乱、太长、太碎模型也很难用得好。所以 chunk 的质量本质上同时影响召回质量生成质量如果把整体效果粗略写成一个函数可以写成chunk 质量是后续所有阶段的起点。三、Chunk 到底怎么切先搞清楚“切分目标”是什么很多人上来就问chunk size 设 200 还是 500overlap 设 50 还是 100其实这些数字都不是第一问题。第一问题应该是你希望每个 chunk 具备什么样的性质一个理想的 chunk通常应该同时满足这 3 点1. 足够短便于检索不能太长否则向量会变钝召回精度会下降。2. 足够完整保留语义闭环不能太短否则一句定义、一条因果链、一个表格说明会被切碎。3. 足够独立脱离上下文也能大致看懂因为检索命中后模型看到的往往不是整篇上下文而是几个分散 chunk。所以 chunk 设计本质上是在平衡标准解释反面表现短便于精准召回一块内容太杂语义被平均完整一个 chunk 尽量表达一个完整意思句子、定义、因果关系被切断独立单独拿出来也能看懂大意严重依赖前后文才能理解四、Chunk 太大和太小分别会出什么问题1. Chunk 太大比如你把一个 chunk 切成 1500 到 2000 token可能会出现一个 chunk 里塞进多个主题query 只和其中一句相关但 embedding 表示被整段稀释检索看起来“差不多”其实不够准喂给模型时上下文噪声变多典型症状检索能召回“相关文档”但答案总是绕模型会抓错重点引用来源虽然对但不够“贴题”2. Chunk 太小比如每块只切几十个 token可能会出现定义被切成两半一个结论和它的前提分开表格说明不完整模型拿到碎片拼不回完整意思典型症状检索片段很准但答得还是不完整模型总缺最后半句关键条件跨句依赖很弱五、Chunk Size 到底怎么定没有一个“万能数字”但有一套很实用的判断逻辑。1. 先看你的文档类型不同文档适合的 chunk 颗粒度不一样。文档类型推荐思路原因FAQ / 短问答一问一答一个 chunk结构天然独立产品说明 / 手册按标题 段落切章节结构清晰技术文档 / 博客按小节切再限制长度通常有完整逻辑块法律/制度文档按条款切每条天然是一个最小规则单元论文按段落或小节切保留标题跨段依赖强但章节边界也重要表格型文档表格与说明一起保留单独拆表容易丢语义2. 再看你的问题类型如果用户问题大多是精准查一句定义找某个字段找某个条款那 chunk 可以偏小一些。如果用户问题大多是问原理问因果问总结问跨段关系那 chunk 不能切得太碎。3. 一个工程上可用的起点如果你完全没有经验可以先从这组起点试技术文档 / 博客 / 手册300800 tokenFAQ / 短问答一个问答为一块论文 / 制度文档按结构切必要时再做长度限制你不用执着某个数字而要盯着检索出来的单块能不能刚好回答一个子问题。很多人第一次看到 overlap会觉得这不就是重复吗表面上是。但工程上它非常必要。如果一个 chunk 边界正好切在关键信息中间比如定义在上一块解释在下一块问题在上一块结论在下一块主语在上一块谓语在下一块那单独检索某一块时语义就会断掉。所以 overlap 的本质是让相邻 chunk 在边界处共享一部分内容防止关键信息被切断。情况结果overlap 太少关键信息容易被边界切断overlap 合适边界语义更连贯召回更稳overlap 太多冗余变多入库量和检索噪声都会上升一个实用经验是overlap 常常设为 chunk 的10%20%如果文档句子特别长、段落依赖特别强可以再高一点如果文档本身结构清晰、每段独立性强可以低一点七、TopK 到底怎么调不是越大越保险召回阶段最常见的一个参数就是TopK。意思是先从向量库里取回最相关的前 K 个 chunk。很多人会想既然怕漏掉那我把 K 调大一点不就好了问题是TopK 不是越大越好。1. TopK 太小如果 K 太小会出现关键信息漏召回只召回局部片段缺少补充上下文多跳问题答不全典型症状模型答得很肯定但其实漏了关键条件问题看似简单答案却总缺一块2. TopK 太大如果 K 太大也会出现问题无关 chunk 混进来重排压力变大prompt 上下文变脏模型容易被噪声带偏成本上升典型症状检索看起来“很全”但答案反而更散模型开始引用无关背景token 消耗明显上升TopK 状态常见现象调整方向太小答案不完整、漏关键信息适当调大合适信息刚好够回答噪声不多保持太大噪声多、答案发散、成本高适当调小一个比较实用的工程起点是简单问答TopK 35稍复杂问题TopK 510跨段或跨文档问题TopK 可以更大但最好一定配 rerank八、Rerank 为什么经常决定了 RAG 的上限如果只做向量召回你拿到的是“大致相关”的候选集但真正生成答案时你最需要的是“最适合回答问题”的上下文这两者不是一回事。向量召回擅长做粗筛优点是快但它不一定擅长区分哪一段最关键哪一段虽然相关但只是背景哪一段才是最适合喂给模型的答案支撑这就是rerank存在的意义。如果给候选 chunk 重新打分可以写成然后按得分重新排序你可以把它理解成Retriever先把候选人都叫进来Reranker再决定谁坐到前排模块目标特点更关注什么Retriever把相关内容先找出来快、范围广、偏粗筛召回率Reranker从候选里挑最适合回答的更细致、通常更慢排序质量很多 RAG 项目做不出明显效果不是因为“没检索到”而是因为检索到了但最该排前面的没有排前面。这时候 rerank 往往就是分水岭。九、Chunk、Overlap、TopK、Rerank 应该一起看而不是分开调这 4 个参数不是独立的它们会互相影响。1. Chunk 越小TopK 往往要更大因为单块信息更碎回答一个问题可能需要更多块拼起来。2. Chunk 越大TopK 可以更小但噪声可能更高因为单块信息更多但语义也更杂。3. Overlap 越大冗余越多TopK 和 rerank 压力也会增大因为相邻块内容重复召回结果可能更像。4. TopK 越大越需要 rerank因为候选一多不重排基本很难稳定。你可以把它们的关系粗略写成参数建议起点Chunk Size300800 tokenOverlap10%20%TopK35 起步RerankTopK 变大或问题复杂时尽早加入症状优先排查答案不完整Chunk 太小 / TopK 太小答案发散Chunk 太大 / TopK 太大引用来源不稳Chunk 边界设计不合理 / 缺 rerank经常漏条件Overlap 太少检索结果很多但答得更差TopK 太大 / 缺 rerankRAG 的效果不是“检索一下就行”而是由 chunk 颗粒度、overlap 边界策略、TopK 候选规模和 rerank 排序质量共同决定的。决定而且往往比你一开始想象得更大。