RAG系统里文档切片粒度怎么选？按段落还是按句子？

这个坑我太熟了，之前做售后客服机器人也折腾了很久。你现在这个“按段落太长、按句子太碎”的问题，本质是没把“语义边界”和“物理边界”对齐，产品手册里一段话经常包含多个逻辑点，而FAQ里一句话又可能依赖前置条件。我的做法是先用段落切，然后对超长段落做二次分割，比如按标点符号或者小标题再拆，同时保留每个子块的父段落ID作为元数据。检索的时候，召回子块，但把父段落的内容一起塞给LLM，这样既控制长度又不丢上下文。另外你提到“保修期一年”这种，其实更适合用“假设性问题补全”，也就是切分时把上下文里的条件句（比如“非人为损坏”）主动拼到每个子块开头，代价是存储翻倍但效果立竿见影。至于reranker，我建议你早点加上，哪怕用个轻量的bge-reranker-base，对长尾query的提升比调切片参数更明显，不然你会一直陷入“调大漏细节、调小跑偏”的死循环。

你这情况我太熟了，光调切片粒度就像拆东墙补西墙。我当时是先用按段落切，但给每段配了个AI生成的摘要当索引，检索时搜摘要，召回后直接返回原文段落，准确率高不少。另外reranker真得早点上，哪怕用一个轻量的bge-reranker也行，对长段落召回后的重排帮助特别大，不然答案和上下文错位的问题很难根治。

试试滑动窗口切，保留句子前后重叠部分，再配个reranker，效果立竿见影。

我们项目也踩过这个坑，纯按段落或句子都不行，后来是按语义块切，比如把“条件+结论”绑在一起，再配合重叠窗口。你那个保修期的例子，其实上reranker能解决不少，但成本高，可以先试试把切片上限调小，比如256 token，强制截断。另外，LangChain的splitter支持自定义分隔符，把“保修期”这类关键词前后的句子合并，效果比单纯调粒度更直接。

我们之前也踩过这个坑，最后是折中方案：先用段落切，但设了个最大字符数，超了就按句子边界二次切分。而且像你这种“非人为损坏”和“保修期”的强关联，光靠切片解决不了，建议给每个切片加个metadata，比如产品型号或条款编号，检索时能带上过滤条件。另外reranker真的得早点上，哪怕先用个简单的bge-reranker，召回质量会明显不一样。

试试小段落+滑窗重叠，或者先按句切再按语义合并，reranker迟早得加。

我之前也踩过这个坑，纯按段落切确实容易把不相关的细节全塞进来，LLM一长就抓不住重点。但按句子切又太极端，关键前置条件经常被丢掉，你那个“非人为损坏”的例子太典型了。我的做法是先用段落切，然后对超长段落做二次分割，按语义边界比如连接词或标题来断，而不是死板地按句号。另外，建议你把切分后的chunk和原文的段落索引存下来，检索时定位到chunk，但返回给LLM时带上整个原文段落，这样既保证召回粒度小，又让模型看到完整上下文。还有一个土办法，把FAQ这种短文档直接整条作为chunk，产品手册再走段落切，不同文档类型用不同策略，别一刀切。最后，reranker真的强烈建议加，哪怕用个简单的bge-reranker-base，对精排的提升比调切片参数明显得多。

你这问题太典型了，我当初也卡在这。后来试了折中方案，按二级标题或小章节切，同时保留段首的上下文摘要，效果比纯按段落句子都好。另外你既然没上reranker，建议先把top-k调大点试试，靠后续LLM拼上下文也能救回来一点。对了，Chroma里存父子块关系挺有用的，你可以搜下parent-child retriever。

这个太真实了，我当初也卡在这。别纠结固定粒度，直接上滑动窗口或者父子切片，小片段召回，再映射回大段落喂给LLM。你那个保修期的例子，用父子块基本能解决。还有，reranker真的得加，哪怕用个最简单的bge-reranker，对长尾问题的提升都特别明显，比调切片的收益大。

其实按段落切然后做重叠才是正解，比如每段末尾再带上下一段的开头几句，这样既能保住上下文，又不会让单次检索内容太臃肿。另外你产品手册这种结构化文档，可以试试先按标题层级切大块，再根据语义密度细分，别一刀切。对了，Chroma里metadata存好段落编号，后续调优也方便。

我倒是觉得可以试试按语义切，不用死守句子段落。用embeddings算一下句间相似度，在语义断点处切，这样“保修期一年”和“非人为损坏”大概率会被分到同一块。你现在的痛点本质是信息关联度问题，光靠调粒度治标不治本。另外LangChain自带的splitter太粗糙，建议自己写个基于窗口的切割逻辑。

刚踩过这个坑，我的方案是混合粒度：索引里同时存段落和句子，召回时先用段落粗筛，再用句子精排，最后把命中的

我之前也踩过这个坑，后来是用“段落+关键句摘要”的方式解决的，就是段落切完再给每段生成一句语义摘要存进索引，召回时优先匹配摘要，这样既不会太碎也不会太长。另外你提到保修期那个例子，其实就算按段落切也可能漏，因为条件句和结论句如果跨段了，建议切的时候做一下重叠窗口，比如每段保留上一段末尾两句话。对了，你还没上reranker的话，可以先用Chroma的MMR或者mmr重排一下，能缓解一点上下文丢失的问题，但真要治本还是得靠双路召回。

跟你情况挺像的，后来我试了按二级标题切，再配合重叠窗口（比如切完往后多带50-100字），召回率和上下文平衡了不少。另外你这场景没reranker的话，建议先按段落切，检索回来用LLM自己做个粗过滤，把无关片段剔掉再拼给答案，能缓解跑偏。句子切确实太碎，除非你后面接了个重排模型，不然别轻易用。

试试滑动窗口切，句子做最小单位，窗口带上邻近段落，再按语义相似度合并，能兼顾两者。

加个reranker比纠结粒度管用，先粗召回再精排，效果提升明显。

试试父子切片吧，小段落召回再带上父块给LLM，比单调粒度稳多了。

我们项目也踩过这坑，后来是按层级切，先按章节分大块，再在块内按句子带重叠滑窗，比如每两句一窗重叠一句。这样召回时既能拿到局部条件，又不至于整段太长。另外你这场景不上reranker的话，可以试试在召回后做个简单的关键词过滤，把包含“保修”“非人为”这类强约束的句子优先排前面。

我之前也踩过这个坑，后来是分两层解决的：先用段落切保证上下文，再在段落内部按语义窗口做重叠切片，比如每段拆成两个带50%重叠的子块，召回率明显稳了。另外你既然还没上reranker，可以试试把切出来的块按标题层级拼个摘要前缀，能缓解“保修期一年”这种孤立信息的问题。不过说实话，你这场景最终可能还是得靠reranker，不然粒度怎么调都有点碰运气。

这个我太有同感了，之前做售后知识库也踩过同样的坑。段落切分在召回率上确实好看，但长段落里经常混着好几个无关信息点，LLM一读就跑偏；句子切分又太机械，像你举的保修例子，条件状语直接被切没了。后来我们试了个折中办法，用滑动窗口做段落切分，窗口大小设成两到三个自然段，步长设为一个自然段，这样既保留了上下文，又不会让单条结果太臃肿。另外有个小技巧，切分前先把文档里“保修期”“非人为损坏”这类强关联的实体和条件句式抽出来，做一层规则预处理，把关键上下文合并成一条。不过说实话，不上reranker的话，再调切分都是治标不治本，建议尽早把reranker加上，那玩意儿对长文本的精度提升是质的飞跃。

试试按语义段落切，再用重叠窗口把上下文带出来，比固定粒度灵活得多。

试试父子切片，小粒度召回再映射回大段落，既保上下文又控长度。

试试固定大小重叠切片，比如256字符带64字符重叠，比纯段落句子稳多了，配个reranker基本够用。

我们之前也踩过类似的坑，段落太长确实容易让模型抓不住重点。后来是改成按语义段落切，再配合一个滑动窗口把前后文叠进去，召回率会好一些。另外你提到保修期那个场景，其实光调切片不够，最好在检索后加一步重排，哪怕先上一个简单的cross-encoder，比单纯调粒度管用多了。你现在用Chroma的话，试试看能不能把父文档和子块分开存，检索子块但返回父文档，这样上下文不容易丢。