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

说实话你这情况太典型了，我当初做售后知识库也卡在这。建议先别纠结固定粒度，试试分层切片：按段落切，但给每段加个“前置条件摘要”，比如把“非人为损坏”这种限制条件提取出来塞进metadata里，检索时当过滤条件用。

另外你提到没上reranker，这其实比调切片粒度更关键。先粗召回按句或按小块，再用reranker把包含完整上下文的长片段排前面，效果立竿见影。我这边用Cohere Rerank之后，准确率能拉高十几个点。

还有个土办法：手动给FAQ类文档做“问题-答案-条件”结构化模板，切的时候按这个三元组走，保修期这种就不用担心漏条件了。产品手册这种长文本才用段落切，但段落内部用\n\n再分块，配合overlap。

试试父子切片，父块保上下文，子块做召回，配个简单的重排就能解决。

我这边是固定300字带50字重叠，召回率还行，不过还是得看文档结构微调。

试试父文档切块吧，按句子召回再映射到段落，上下文保住了，长度也可控。

我们之前也踩过这坑，后来改成按标题层级切，配合重叠窗口效果不错，你可以试试。

我之前也踩过这个坑，段落切确实容易把无关信息带进来，句子切又丢上下文。后来我是按标题层级+小段落（大概3-5句）做混合切，再给每个块补一个“前置摘要”字段，把关键条件写进去。你那个保修的例子，切完块之后人工标注一下“非人为损坏”作为元数据，检索时用filter过滤，比单纯调粒度管用。另外reranker真的建议早点上，哪怕先用一个简单的cross-encoder，提升比调切片参数明显。

我之前也踩过这个坑，段落确实容易带偏，句子又太碎。后来折中了一下，按小标题或语义块切，大概2-4句话一组，再给每段补一句摘要性的元数据，召回时先匹配摘要，效果比单纯切粒度好不少。另外你提到的保修期这个例子，本质是上下文依赖问题，建议在切片时把条件句和结论句强制放一起，或者干脆用滑动窗口重叠切，比如句子A+B、B+C这样，能缓解漏上下文。还有，reranker真的建议早点上，哪怕用个轻量的bge-reranker，对长文档的排序提升比调切片参数直观多了。

试试重叠切片加父子分块，小片段召回，大段落喂给LLM，能缓解这问题。

我之前也踩过这个坑，段落切太粗确实容易让LLM抓不住重点。后来我是按“语义块”切的，比如FAQ里把问题和答案绑在一起，产品手册按标题+段落组合，这样既能保住上下文，召回又不会太散。另外你提到的reranker，强烈建议早点加上，我试过用bge-reranker-base，召回率提升特别明显，能缓解不少切片粒度的问题。

你这情况太典型了，段落切确实容易带偏，句子又丢上下文。我建议试试按语义切分，比如用LangChain的RecursiveCharacterTextSplitter，把chunk_size调在300-500之间，同时让上一段末尾和下一段开头有20-50字符的重叠，这样既能保留条件信息又不至于太长。另外reranker强烈建议加上，哪怕用个简单的bge-reranker，召回质量能明显上一个台阶，不然你切得再细也容易翻车。

我之前也踩过这个坑，段落切完召回一堆废话，句子切又断章取义。后来试了折中方案：按段落切，但用滑动窗口把相邻段落拼一块存，检索时只匹配一个段落，返回时带上前后文。这样召回精度和上下文兼顾，就是存储会翻倍。另外没上reranker之前，可以试试把切分重叠设大点，比如100字，能缓解不少。你那边文档结构如果比较固定，也可以考虑按标题层级做父子块，父块存上下文，子块做检索。

试过按语义段落切再叠个重叠窗口，召回和上下文平衡不少，你也可以试试。

我们项目也踩过这个坑，后来是按语义段落切，再给每个块生成摘要当索引，检索时先匹配摘要再取原文。你这情况建议先上reranker，比纠结粒度见效快，Chroma里直接配个Cohere的rerank就行。

我试过按固定长度切，1500字左右带重叠，效果比按段落稳一些。但关键还是你那个例子，上下文断裂的问题，得靠检索后合并相邻块来解决，LangChain里有现成的parentDocumentRetriever。

其实你这个问题本质是“召回粒度”和“生成粒度”不一致，我最近的做法是切小块的存向量库，但关联到大块的文本给LLM，中间用元数据映射。你可以试试，召回率会好很多，但代价是存储和检索复杂度上去了。

建议先按段落切，再上reranker，比纠结粒度性价比高多了。

我们之前也踩过这个坑，后来试了按二级标题切块，再配上50%重叠的滑窗，召回和回答都稳了不少。你这个场景其实核心问题是条件与结论被拆开了，建议先按段落切，但把段落里首句或末句的限定词（比如“非人为损坏”）提取出来，跟正文一起塞进chunk里。另外LangChain的Splitter可以自定义分隔符，把“保修期”这种关键短语前后文强制绑一起。没上reranker的话，可以先用bm25和向量检索各跑一遍，再交叉过滤，能缓解不少。你们现在召回结果里，大概多大比例是这种“带条件但条件丢失”的情况？

我之前也遇到过这个坑，段落切出来太长确实容易让模型跑偏。我的做法是先用句子切，然后再按标题或章节把相邻的句子拼回去，这样既保留了上下文又不会太碎。另外你既然还没上reranker，可以试试在召回时多加几个候选片段，用LLM自己挑最相关的部分，效果会比单纯调切片粒度明显。保修期那个例子，其实可以试试在元数据里存一下“适用条件”字段，检索时做个简单的规则匹配。

我之前也踩过这个坑，段落粒度确实容易让LLM被无关信息带偏，但句子级又太依赖embedding的匹配能力。我的做法是先用段落切，然后根据段落内部的语义连贯性做二次分割，比如按二级标题或者逻辑转折点拆，而不是死板地按固定长度。你试过用重叠窗口吗？比如段落切完，每个chunk带上前后各一两句话的上下文，这样能缓解句子级丢失条件的问题。另外你提到没上reranker，我强烈建议先加一个轻量的，比如bge-reranker-base，它对“保修期”这种多条件约束的query提升特别明显，基本能解决你描述的那种召回片段不全的情况。还有个土办法，就是把FAQ里的常见条件句式（比如“如果...那么...”、“非...情况下”）手动标注成元数据，检索时做关键词加权，成本低但有效。你现在的Chroma里有没有存文档标题或章节路径？有时候把父级标题拼进chunk内容里，比单纯调切片粒度更管用。

这问题太真实了，我之前做客服问答也卡在这。建议试试分层切片，比如先把文档按段落切，然后再给长段落加个按句子切的小块索引，检索时优先匹配小块但返回父段落。

另外你提到保修期那个例子，其实用metadata把“适用条件”和“具体时限”绑在同一个chunk里比纠结切法更省事。还有既然都上LangChain了，先加个简单的similarity score阈值过滤，再考虑reranker，性价比高很多。

对了，你产品手册里有没有表格？那玩意儿按段落切基本必炸，得单独处理。

建议先按段落切，再配个reranker，效果立竿见影，不然句子切召回太飘。

我们项目也踩过这坑，最后是混合切的：先按段落切，段落超过500字再按句子切，但会把相邻两句拼成一组。另外你举的保修期例子，本质是依赖关系问题，光调粒度不够，最好在切片时保留小标题或者元数据，比如把“保修政策”这个字段跟着内容一起存进去。还有你们现在没上reranker，检索完可以先用关键词做一轮粗过滤，把明显不相关的段落踢掉，再送LLM，准确率会稳很多。

我之前也踩过这个坑，后来是按层级切，比如大段落为主，同时把每段拆成带重叠的句子块，再在embedding前把“非人为损坏”这种前提条件拼回去。你可以试试固定窗口+重叠，比如每300字一段，重叠50字，比单纯按段落或句子都稳。另外强烈建议上reranker，哪怕用个小的，召回质量会明显改善，不然切片调参真的能折腾到怀疑人生。

说实话你这个情况挺典型的，段落粒度其实还得看文档结构，产品手册里那种带编号的条款段落就特别适合按小节切，FAQ反而可以按问答对整体存。我这边之前试过混合策略，正文按段落，但把每段首句抽出来单独加个索引，召回时候先看首句再拉全文，比单纯调粒度效果好。另外你既然都想到reranker了，不如先把chunk size调到500-800字符，overlap设个50-100，配合LangChain那个ParentDocumentRetriever试试，能缓解上下文丢失问题。