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

试试父子切片吧，小块召回大块喂给模型，上下文和精度都能保住。

试试先按段落切，再用滑动窗口按句子召回，最后拼上下文，能压住跑偏问题。

我们项目也踩过这个坑，后来是按章节标题+段落混合切的，再把父文档ID存到metadata里。召回时先按小粒度搜，拿到结果后用父文档整体喂给LLM，准确率提升挺明显的。你既然还没上reranker，建议先试试这个方案，成本最低。另外保修期这种问题，其实可以用规则或few-shot把“非人为损坏”这类条件前置，不纯靠切片解决。

我之前也踩过类似的坑，特别能理解你说的“按段落太长、按句子太碎”这个矛盾。后来我试了折中方案：先按语义段落切，再对超长段落做个二次切分，但切分点选在二级标题或者逻辑转折词附近，这样能保住上下文。另外你提到“保修期”那个例子，其实光靠切片粒度解决不了，关键得看你的检索策略——我后来把每个切片的上文摘要（比如前两句）作为元数据存进去，召回时让embedding同时匹配正文和摘要，漏上下文的情况改善很多。还有，reranker真的建议早点上，哪怕用个轻量的bge-reranker，对长文本召回后的排序提升非常明显，能帮你筛掉不少“相关但无用”的段落。最后就是可以试试动态切片，比如根据用户问题长度调整召回块数，问题短就多召回几个小段再拼起来，问题长就少召回大段，这个在LangChain里自己写个逻辑也不难。你现在这个阶段，我反而觉得切片粒度不是最优先要调的，先把召回和重排的链路跑通，再回头调切片，你会发现参数敏感度低很多。

我之前也踩过这个坑，段落切完太臃肿，句子切了又断上下文。后来试了按固定窗口的滑动切片，比如每2-3句作为一个块，再让相邻块有重叠，召回和上下文平衡了不少。另外你提到保修那个例子，其实加个reranker能救回来不少，哪怕先用一个简单的交叉编码器试试，比死磕切片粒度见效快。

说实话我最近也卡在这个问题上，试了一圈发现纯按段落或纯按句子都不太稳。后来参照我们项目里的做法，改成按语义块切——就是把标题、列表、表格这些结构先拆出来，然后段落内部再按逻辑转折点分，比如“但是”“不过”“需注意”这种词前面断开，这样既能保住上下文又不至于太长。

你那个保修期的例子很典型，其实像这种条件状语和结论绑定的情况，用“父子切片”方案挺管用的，父块按整段存，子块按句子存，召回时先拿子块去匹配，但喂给LLM的时候把父块内容一起塞进去。Chroma本身支持metadata过滤，你可以把父子关系做成关联ID，检索回来再拼一下，比直接调切片粒度要灵活。

另外我觉得你提到没上reranker，这个其实影响挺大。切片粒度再优化，向量召回的前几名里也容易混进噪音，reranker能帮你把真正有用的段落顶上来。我建议你先按段落切，然后加个cohere或bge的reranker，成本不高但效果提升明显，比纠结粒度更划算。

还有个细节是产品手册和FAQ性质不一样，FAQ短句子多适合按条切，手册长段落多适合按标题层级切。你可以对两类文档分开配不同的切片策略，在LangChain里写个简单的路由判断就行，别一套参数跑到底。

我之前也踩过这个坑，后来干脆用段落切，但加了个小技巧：把每段的首句和标题拼进元数据里做检索，召回正文时再带出完整段落。这样既能定位准，上下文又不会丢。另外你提的reranker其实挺关键的，我上了之后准确率提升明显，建议你早点加，比纠结切片粒度效果来得快。

试试父子切片吧，父段落召回、子句子生成，效果立竿见影。

我之前也踩过这个坑，按段落切确实容易召回一大坨，模型看到那么多无关内容反而抓不住重点。后来试了个折中方案，就是按语义切块，用类似semantic chunking的思路，把意思相近的句子合并成一个chunk，同时控制最大token数，这样既不会太碎也不会太长。你说的保修期那个例子挺典型的，其实问题不全在切片粒度，检索本身也得背锅，纯向量检索对“条件+结论”这种结构不敏感，召回的往往只是语义最接近的那一句。我建议你先把chunk加上一定的overlap，比如前后各留一两句，能缓解上下文丢失的问题。另外reranker真的值得上，哪怕先用个轻量的cross-encoder，召回top20再重排到top5，效果提升比调切片明显得多。LangChain里就有现成的，Chroma也支持先粗召回再精排，你可以先拿一批bad case测一下，看看到底是切片的问题还是排序的问题。

我一般按语义切，段落太大就拆成子块，再叠个reranker基本能压住跑偏。

我之前也踩过这个坑，按句子切确实容易把条件句和结论拆散，后来改成一个小段落加滑动窗口重叠，大概200-300字左右，效果好了不少。你这种FAQ场景其实可以试试按QA对切，每个问答作为一个chunk，天然自带完整语境。另外没上reranker的话，建议先加个BM25混合检索，纯向量对“保修期”这种关键词召回不太稳。

我们一般按语义切，段落超长就再拆，然后加个reranker，效果比纠结粒度管用。

按句子切确实容易把条件句和主句拆散，你这个“保修期一年”丢了“非人为损坏”的例子太典型了。我后来试过一种折中做法，是按语义段落切，但控制每块在200到400字之间，同时保留上一段最后一句和下一段第一句作为重叠上下文，效果比纯按段落或纯按句子都稳一些。FAQ这种短问答其实可以单独处理，把问题和答案绑成一个chunk，别硬拆。产品手册里那种带层级标题的，我会把标题路径拼到每个chunk开头，检索时命中率明显高。你现在没上reranker的话，检索召回数量可以开大一点，比如top10，再靠LLM自己筛，但延迟会上去。Chroma本身对metadata过滤支持还行，可以按文档类型分collection，别把FAQ和手册混在一起切。

我之前也踩过这个坑，纯按段落或句子切都不太理想。后来改成按语义切块，再给每个chunk加上所属章节标题做上下文补充，效果好了不少。你这种FAQ场景其实可以试试小块检索、大块喂给LLM，就是召回用句子级，但返回时带上前后各一两句。另外没上reranker的话，先把embedding模型换成bge-m3这类多语言的，召回质量提升挺明显的。

按语义切吧，段落里再拆子块，召回后再拼回上下文，比纯按句或段都好使。

我之前也踩过这个坑，纯按句子切确实容易丢条件，后来改成按语义切，用个小模型或者规则把相关句子合到一个chunk里，效果好了不少。你这种FAQ场景其实可以试试按问答对切，产品手册就按小节切，别一刀切。另外没上reranker的话，检索top-k可以开大点，比如10-20，再让LLM自己筛，比死磕切片粒度见效快。

我之前也踩过这个坑，后来改成按语义切分，再用滑动窗口加个overlap，效果比纯段落或纯句子好不少。你这种FAQ场景其实可以混着来，短问答按整条切，产品手册按段落切但控制下长度。没上reranker的话，建议先加个简单的关键词过滤或者BM25混合检索，召回质量能提一截。另外切片时把标题层级带进去当上下文，对“保修期”这种问题挺有用的。

我之前也踩过这个坑，纯按段落或句子切都不太稳。后来改成按语义切，大概200-300字一块，再带点重叠，效果明显好一些。你那个保修期的例子其实是上下文被切断了，光靠调粒度不一定能完全解决，加个reranker或者把FAQ按问答对整条存会更靠谱。

我之前也踩过一模一样的坑，按句子切召回率是上去了，但语义完整度掉得厉害，回答经常缺条件。后来我的做法是别在句子和段落之间二选一，而是用带重叠的滑动窗口，比如按200到300字切，但前后各留50字重叠，这样“非人为损坏”这种前置条件不太容易丢。FAQ这种本身结构清晰的可以单独走一套逻辑，按问答对切，产品手册再走滑动窗口。其实粒度这事跟你的embedding模型也有关系，有些模型对长文本本身就不敏感，切再细也救不回来。你现在没上reranker的话，建议先加一个，哪怕用最基础的bge-reranker，召回top20再重排到top5，体感提升会很明显。另外还有个野路子，检索的时候同时用句子级和段落级两路召回再合并，代价是延迟会涨一点，但准确率确实能兼顾。你们知识库文档量大概多大？量小的话其实可以试试按语义相似度动态切，LangChain里有现成的semantic chunker。

我之前也踩过这个坑，按句子切确实容易把条件句和主句拆散，你那句“保修期一年”脱离“非人为损坏”就是典型例子。后来我的做法是折中一下，用递归切分但把chunk size设得偏小一点，比如300到500字符，同时开overlap，大概80到120字符，这样既能保住局部上下文，又不至于整段塞进去让模型分心。另外你可以试试在切分前先把FAQ按问答对整体保留，产品手册再按标题层级切，不同文档类型用不同策略，别一刀切。还有个挺关键的点是meta信息，把所属章节标题或者小标题拼到每个chunk前面再embedding，检索时命中的概率会高不少。你现在没上reranker的话，检索top-k可以适当开大一点，比如8到10，然后靠LLM自己筛，但这样token会涨，得权衡。真要说的话，reranker对你们这种边界模糊的query提升挺明显的，可以早点加上。