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

我之前也踩过这个坑，后来试了混合粒度：主切片用段落，但给每个切片额外拼接前后两句关键上下文，这样既避免太碎又不会太长。另外没reranker的话，可以试试切完按句子级相关性先粗筛，再取top-k段落做精排，效果会好不少。你产品手册的章节结构明显吗？如果明显，按标题层级切可能比纯按段落更稳。

这个问题我最近也踩过类似的坑。我自己的做法是先用段落切，但给每个段落加了个动态摘要，就是把段落里的关键实体和条件句单独抽出来作为元数据存进Chroma，检索的时候用摘要去匹配，召回的是段落但过滤条件能提前筛掉不完整的上下文。比如“保修期一年”那段我会把“非人为损坏”作为条件标签存进去，这样用户问保修期时召回的基本都是带条件限定的段落。另外你提到按句子切容易丢上下文，其实可以考虑用滑动窗口的方式，比如相邻的两个句子作为一个chunk，这样既不会太长又保留了前后关联。不过你这还没上reranker确实有点难搞，我觉得至少得加个简单的重排序，哪怕用个cross-encoder的轻量模型跑一下，能把那些长段落里真正相关的片段提出来，回答准确率能提升不少。你产品手册里有没有那种带表格或列表的文档？那种结构化的内容我试过按表格行切效果反而比段落好，因为表格本身就有明确的边界。

试试按章节或语义段落切，再配合滑动窗口保留上下文，召回率会好不少。

我最近也掉进过这个坑，试了一圈发现切片粒度真没标准答案，得看文档类型和查询意图。比如产品手册里那些独立的技术参数或规格说明，按句子切反而好使，因为答案很直接；但像FAQ这种包含条件逻辑的，按段落切更靠谱，哪怕段落长一点，只要关键条件没丢，LLM反而能通过prompt约束来筛选信息。你提到的“非人为损坏”和“保修期”绑定的场景，我后来用了滑动窗口切片，比如段落切完后，把前后相邻的段落或句子重叠一部分合并成一个chunk，这样既保持粒度又保留上下文。另外你还没上reranker的话，可以先用LangChain的MultiQueryRetriever试试，它能把用户问题拆成多个子查询去召回，再合并结果，能缓解句子切片漏上下文的问题。不过最终我觉得还是得结合业务测试，比如手工标注一批典型问题，对比不同切片策略下的召回率，别太迷信理论最优解。

我是直接用滑动窗口加段落边界对齐来做的，比如设成256个token，但切的时候强制在段落结尾断句，这样既不会太碎又能保留上下文。另外你这个场景其实挺适合先按句子召回再用LLM做一次上下文合并的，我试过准确率能提不少。reranker早晚得加，不然长文档里关键信息容易被埋掉。

这个问题我也纠结过很久，最后发现没有银弹，得根据文档类型和查询场景动态调整。我现在的做法是混合切片：对产品手册这种结构化强的，用段落+重叠窗口（比如每段前后多保留20%的相邻内容），这样既能保持逻辑完整性，又不会让LLM读太多无关信息。但像FAQ这种问答对明确的，按句子切反而好用，前提是给每个片段手动打上“前提条件”标签，比如“非人为损坏”单独存一个元数据字段，检索时通过关键词匹配强制关联。你提到没上reranker，其实可以先用LangChain的MultiQueryRetriever试试，把用户问题拆成几个子问题分别召回，再合起来排序，能缓解碎片化的问题。另外切片粒度跟embedding模型也有关，有些模型对短文本理解差，句子级别召回率会暴跌，这个得自己跑实验验证。最后想问下，你目前用的Chroma有没有试过调整chunk_overlap参数？我试过设成50%以上，有时候歪打正着能补上上下文断裂的问题。

我之前也踩过类似的坑，后来试了个折中方案：按段落切，但每个段落前面加一个语义更完整的“小标题+摘要”作为元数据，检索时优先匹配摘要，再返回完整段落。这样召回率没掉，LLM也能拿到上下文。另外你提到“保修期”那个案例，我建议对关键实体做显式标注，比如用正则把“保修期”“非人为损坏”这类条件拆成结构化字段存到metadata里，检索时直接过滤，效果比纯靠切片粒度靠谱。还有一种思路是按语义边界切，比如用NLP模型找“自然段落结束点”，而不是死板按句号或换行，虽然麻烦点，但长文档里召回率能提不少。你目前用的Chroma其实支持自定义metadata过滤，可以优先试试这个，比调切片粒度更灵活。对了，不上reranker的话，可以先用BM25和向量检索做个加权融合，很多场景下能缓解句子太碎的问题。

我最近也在折腾这个，试了一圈发现按段落切但加上滑动窗口效果还行，比如每段保留前后两句话作为重叠，这样既能控制长度又能保住上下文。另外你提到没上reranker，其实可以先搞个简单的关键词匹配或者基于向量的粗排，把召回结果再精筛一遍，能明显改善跑偏的问题。对了，你产品手册里有没有表格或列表？那种结构化的内容我建议单独处理，混在段落里容易把LLM搞懵。

试试滑动窗口切片，句子为主，前后补几个句子做上下文，效果比固定粒度好不少。

试试按章节分段然后加个滑动窗口，能兼顾上下文又能控制长度。

我之前也踩过这个坑，后来折中用了混合策略：段落做基础单元，但把段落里关键句单独抽出来做索引，检索时同时匹配段落和句子权重。不过数据量大了之后维护成本挺高的，你现在这个场景有没有考虑过加一个滑动窗口式的切片，比如相邻段落重叠20%？另外没上reranker的话，可以试试调高chunk overlap参数，至少能补回一些上下文连续性。

说实话我觉得你这个问题卡在“段落”和“句子”之间很正常，我自己试下来最稳的反而是“语义块”——就是按文档里的标题层级和列表结构去切，比如一个二级标题下的内容，如果包含多个并列条件，就单独拆成一个块。像你举的保修例子，其实“非人为损坏”和“保修期一年”大概率会在同一个二级标题下，这时候按段落切可能太粗，但按句子切又会把因果拆开。我目前的做法是先用段落切，然后对超长段落做二次切分，切分点选在“但是”“前提是”“以下情况”这类转折或条件词前面，这样既保住了上下文，又不会让单个块超过500个token。另外你说没上reranker，我强烈建议你先加一个，哪怕是最简单的bge-reranker-base，对长文档的召回精度提升特别明显，尤其能解决“召回太长但相关片段在中间”的问题。还有个小技巧，检索时可以同时返回相邻的前后块，比如命中第N块就顺带把N-1和N+1也塞给LLM，这样即使切片有点碎，上下文也能补全。最后想问你一下，你们产品手册里有没有那种跨章节的引用？比如“详见第3章”这种，如果有的话，切片策略得额外处理，不然召回率再高也白搭。

我之前也踩过这坑，后面直接按段落切但加了滑动窗口，比如相邻段落重叠个一两句，这样既不会太碎也能保住上下文。不过你这场景光调切片可能不够，建议把reranker加上，Chroma配个交叉编码器，召回质量能提升一大截。另外保修期这种问题，其实可以在切片时把条件句和结论句打成一个块，或者干脆用LLM做一次关键词抽取来辅助切，效果比纯按固定粒度稳。

试试按章节切，再让LLM自己判断相关段落，或者先按段落召回再用句子定位，比单一切法稳。

我之前也踩过这坑，后来是折中搞的：按段落切，但给每段加了个“前置摘要”字段，手动把关键上下文条件写进去。这样召回段落长度可控，LLM也不会瞎联想了。另外你提到的reranker，真得早点上，之前我用bge-reranker-base，召回top20再重排，准确率提升挺明显的，Chroma里也能直接配合用。

我之前也踩过这坑，后来是这么干的：主切片用段落，但额外把每个段落里的关键条件句（比如“非人为损坏”）抽出来做成小索引，检索时两个粒度一起查再合并。另外你既然还没上reranker，可以先用关键词过滤把长段落里跟问题无关的句子砍掉再丢给LLM，效果会好很多。对了，你试过把FAQ单独切成QA对，产品手册按段落切吗？混合粒度有时候比统一粒度更省心。

我们项目也踩过这个坑，后来是按章节二级标题切，再保留标题和首段作为上下文，效果比纯段落或句子好不少。你这情况建议先试试滑动窗口，比如按段落切但重叠200字，能缓解上下文断裂。另外reranker真得早点上，能过滤掉不少长段落里的噪声，召回率上来后切片粒度就不用那么纠结了。

试试父子切片，小块召回、父块送LLM，能兼顾上下文又省token。你这场景最好加个reranker，效果立竿见影。

说实话我最近也卡在这个问题上，试过好几种方案，最后是拿段落切但加了比较重的overlap，大概20%到30%的样子。你那个保修期的例子特别典型，光靠切粒度解决不了，本质上是信息关联度的问题，建议先别急着定死，能不能在切完以后给每个块生成一个摘要或者几个关键词，然后检索的时候把摘要和原文一起embedding，这样召回的时候更偏向语义相关性而不是纯字面匹配。另外你还没上reranker确实是个关键点，我觉得就算切片粒度不完美，reranker能救回来不少，特别是你这种产品手册FAQ，很多问题本质上是同一个答案的不同问法，第一轮召回粗一点没关系，reranker把真正相关的top3捞出来就行。我自己现在的做法是：小段落（三到五句）为主，但把文档里那种带条件的条款单独抽出来做成一个“前提-结论”结构，比如“非人为损坏+保修期一年”这种组合块，这样既不会太碎也不会太长。你可以试试看，顺便问下你Chroma那边距离函数用的啥？之前有人跟我说cosine和dot在长文本上表现差异挺大的，我也在调这个。

你这问题太典型了，我当初做客服RAG时也卡在这。段落长导致跑偏，句子碎又丢上下文，本质是“检索单元”和“生成单元”没解耦。我的做法是：切片按段落走，但给每个切片打上结构化前缀（比如产品型号、章节标题），同时把段落内部的逻辑块用空行再拆细一点，这样召回时能拿到“保修期一年”这句，但前面那句“非人为损坏”也会跟着前缀一起带回来。另外，你提到的漏上下文，其实不全是切片粒度的问题——Chroma的向量检索对短句太敏感了，建议把FAQ类的高频问答单独建一个索引，用关键词+向量混合检索，命中率会明显提升。reranker真得加上，哪怕用个简单的bge-reranker-base，能把“保修期”相关的候选重新排序，比单纯调切片参数省心得多。最后提醒一点，产品手册里很多条件状语（比如“在正常使用下”）经常被切到上一个段落里，如果你用LangChain的RecursiveCharacterTextSplitter，记得把分隔符优先级调成“先按句号断句，再按段落合并”，这样能保住因果逻辑。