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

这问题太真实了，我当初搞客服bot也卡在这。段落长吧，召回准但prompt塞太多噪声，模型容易抓错重点；句子短吧，上下文又断了。你那个保修期的例子特别典型，光靠切片解决不了，本质是信息关联问题。

我后来试了个笨但有用的办法：按段落切，但切完给每个段落打上“标题+摘要”的元数据，比如这段属于“保修政策-非人为损坏-期限”。检索时先匹配标题和摘要，再返回原始段落。这样召回粒度粗，但答案相关性高，LLM也不容易跑偏。

再就是你那句“还没上reranker”，强烈建议先上个轻量的交叉编码器，哪怕是个小模型，对长段落重排的效果立竿见影。切片粒度不完美，reranker能兜底。

还有个土办法，对FAQ类文档，直接按“问题-答案”对整块存，别切。产品手册按小节切，但把前后相邻两段拼成带重叠的chunk。比如第3段拼第2-4段，检索时命中中间那段，上下文自然带出来了。

你现在的痛点其实不是粒度，是没做“条件-结论”这类逻辑关系的显式绑定。试试在切片时，把句子里的条件状语从句（比如“非人为损坏”）抽出来，单独建个索引字段。这样问“保修期多久”时，能被“保修期一年”召回，同时强制带上条件约束。

最后提醒下，LangChain自带那些splitter都是按字符数硬切的，对中文语义不友好。可以自己写个递归分割，按标点层级（句号→分号→逗号）优先断开，再控制最大长度。别偷懒，这个很值得调。

我之前也踩过这个坑，按段落切确实容易把不相关的信息裹进来，尤其产品手册里一个段落经常讲好几个功能点。后来我试过用滑动窗口做段落内的小块切分，比如按句子切完再合并相邻的2-3句，效果比单纯按句子或段落都好一些，至少能保住“非人为损坏”这种前置条件。不过你这个场景，如果上了reranker，其实切片粒度可以稍微粗一点，靠重排把最相关的片段顶上来，不然纯靠向量检索对细粒度切片的依赖太大了。另外LangChain里那个RecursiveCharacterTextSplitter可以自定义分隔符优先级，把句号和换行符都设进去，这样切出来的块不会硬生生断在句中间。但说实话，切片粒度没有标准答案，跟你知识库的文档结构关系很大，建议你抽几类典型问题，分别拿不同粒度跑一遍评测，看召回率和回答准确率的平衡点在哪。还有个思路是维护一个标题层级索引，先定位到章节再做二次切分，这样既能控制长度又能保留上下文。

建议上reranker前先试试滑窗重叠切块，按句子切但保留前后各一两句上下文，召回和精度能平衡点。

试试父文档切块吧，小段召回再映射回大段，能省掉不少上下文丢失的麻烦。

我们项目之前也踩过类似的坑，后来是按章节标题+段落混合切的，同时给每个切片补了父级标题作为前缀，召回率确实稳了不少。不过你这场景其实更依赖reranker，不然光靠切片粒度调整上限有限，建议先加个简单的bge-reranker试试，能缓解不少上下文错位的问题。另外保修期这种带条件的问答，可以试试在切片里把“条件+结论”强制拼在一起再存，牺牲一点粒度换准确性，挺值的。

我之前也遇到过这个坑，段落切完召回太粗，句子切完又断章取义。后来试了按语义段落切，再把每段做个小摘要存成单独的索引，检索时用摘要匹配，拿到原文再拼上下文。另外没上reranker的话，可以先用关键词过滤一轮，再按位置权重稍微调一下，效果能好不少。你那个“非人为损坏”的例子，其实可以试试在切片时保留标题和前置条件作为元数据，检索时带上一起送进LLM。

试试父子切片吧，小段落召回再拼上下文喂给模型，比单切强多了。

我之前也踩过这个坑，后来干脆用段落切但设了最大字符上限，超过就按句子边界断开，这样既能保住上下文又不会太长。不过你这场景最好还是先试试带重叠的滑动窗口，比如段落间重叠个一两句，召回会稳很多。另外reranker真不是可选项，尤其你句子粒度的时候，加个bge-reranker能救回来不少误召回的片段，成本也不高。

试试父子切片，小粒度召回再拼上父段落上下文，比单纯调尺寸好用。

我之前也踩过这个坑，段落确实容易塞太多无关信息，但句子又让上下文断链。后来试了折中方案：按语义段落切，但每片里带上小标题或者首句摘要，这样召回时能保留关键条件。另外你这种“保修期”问题，其实加个reranker比调切片粒度更有效，哪怕用个简单的bge-reranker，召回率不变但准确率能提一大截。

我之前也踩过这个坑，段落确实容易带偏，句子又太碎。后来是这么干的：先按段落切，但每段开头自动拼接上一段的前两句作为上下文，检索命中后只保留原段落本身，这样召回率上来了，LLM也不会被截断信息误导。你那个“保修期”的例子，本质是条件状语和结论分离，可以考虑对这类常见问答对做个简单的规则合并，比如用正则把“如果/非...则...”这类句式强制归到同一块。再就是别急着上reranker，先把chunk_size调成400-600个字，overlap设20%，配合Chroma的MMR检索试试，效果可能比你想的稳。另外你产品手册里那些表格和步骤列表，建议单独用markdown结构切，别跟正文混一起。

我之前也踩过这个坑，段落太长确实容易让模型抓不住重点。后来我改成按二级标题切，再把每个标题下的首句和尾句拼进embedding里，召回效果好了不少。另外建议你尽快上reranker，这玩意儿对精度提升太明显了，比纠结切分方式管用。你现在的固定窗口大小是多少？有时候调调chunk overlap也能缓解上下文丢失的问题。

我之前也踩过这个坑，段落切确实容易把无关信息带进来，句子切又丢上下文。后来我试了按二级标题或者语义块切，比如把“保修政策”整块作为一个chunk，效果比纯按段落好不少。另外你提到的reranker，其实挺值得加的，哪怕用一个轻量级的bge-reranker，都能明显把“非人为损坏”这种关键条件提上来。还有一个笨办法就是给每个chunk手动加几个关键词标签，检索时候先用关键词过滤一遍，再走向量相似度，成本低但挺管用。

我之前也踩过这个坑，后来干脆用两层方案：按段落粗切，但把每个段落按句子拆开后用向量拼接方式单独建索引。这样既能保证召回段落主体，又能通过句子级别的匹配度来调整最终返回的片段长度，不用纠结单一粒度。

另外你提到的“非人为损坏”这种跨句条件，其实光靠切片很难解决，建议在切分时把每个段落的首句和末句单独存一个字段，检索时加权匹配，或者在prompt里强制要求模型先看完整段落再回答。你们现在没上reranker的话，可以试试先按段落召回Top10，再用简单的关键词重叠度或者MMR去重，能缓解不少问题。

对了，你产品手册里有没有那种带条件列表的表格？那种格式直接切文本会损失结构，我后来是用markdown的表格语法保留原样，再配合标题层级做父子块，效果比纯文本切分好很多。你们用的LangChain有HierarchicalSplitter吗？那个可以试试。

你这情况太典型了，按句子切就是容易丢前提条件。我建议试试混合粒度，比如先用段落做粗召回，再在结果里按句子做二次切分，把关键句和它所在段落的前后文一起塞给LLM。另外reranker是真的建议早点加上，能大幅缓解这种长段落跑偏的问题，成本比调切片参数低多了。

我们之前也踩过这个坑，最后是混合切的，大段落做索引，小句子做检索候选。说白了就是先用段落粒度做粗召回，再在段落内部按句子做二次精排，这样既不会丢上下文，又能把最相关的句子顶到前面去。不过你这个场景里“保修期”这种问题，本质是条件约束，光靠切片解决不了，得在元数据里把“适用条件”和“结论”拆开存，检索的时候把条件也带回来喂给LLM。

还有一点，你现在的召回跑偏，大概率不是切片粒度的问题，而是Embedding模型对长文本的语义压缩不够好。建议先试试把段落控制在200-300字左右，超过的用滑动窗口重叠切，比纯按句或纯按段都稳。另外reranker别等后面了，直接上一个小的交叉编码器，哪怕用bge-reranker-base，都能把准确率拉上来一大截，成本也就多几十毫秒。

倒是想问下，你的FAQ里像“非人为损坏”这种条件，是不是经常和结论出现在不同段落？如果是，那更得在切片前做语义合并，把同一个知识点的条件+结论强制绑在一起，不然怎么切都是漏。

我最近也踩过这个坑，产品手册这种结构化文档建议别固定粒度，可以先按段落切，再把超长段落按语义边界二次拆成小块，同时保留父块引用。你那个保修期的例子，其实就是典型的需要上下文关联，光靠切片解决不了，reranker早晚得上，不然召回再准也白搭。另外可以试试给每个切片加个前置摘要或者关键词标签，检索时匹配摘要，返回时带出原文块，效果会比纯切分好不少。

我最近也在折腾这个问题，试了一圈下来感觉纯靠固定粒度确实两头不讨好。我的做法是先按段落切，但加了个后处理：把超过一定长度的段落再按语义窗口拆成重叠块，大概重叠个一两句话，这样既保住上下文，又不会让单块太长。你那个“保修期”的例子我太有同感了，其实很多FAQ本身就是条件+结论的结构，单纯按句子切必翻车。另外强烈建议你早点上reranker，哪怕用个轻量的cross-encoder，对长文本召回的修正效果立竿见影，能在不牺牲粒度的情况下把准确率拉回来不少。还有个土办法，就是给每个切片打标签，比如“保修条款”“使用限制”这种，检索时先用关键词过滤再向量匹配，虽然麻烦但挺管用。你们现在Chroma里有没有存元数据？如果没存，得先补上这个，后面调切片策略会灵活很多。

试试父子切片，小片段召回再映射回大段落，比单切好用多了。

试过按语义段落切+小chunk重叠，配合metadata过滤，比纯按段落句子稳很多。

可以试试段落为主，句子为辅混合切，再按标题层级加权召回。