最近在搭一个基于知识库的AI客服Agent，用的RAG方案。文档是产品手册和FAQ，试了按段落切，发现检索回来的一些段落太长，LLM回答时容易跑偏；按句子切又太碎，经常漏掉上下文。比如用户问“保修期多久”，按句子切可能只召回“保修期一年”，但实际需要结合前面的“非人为损坏”条件。想问下大家在实际项目中，切片粒度一般怎么定？有没有兼顾召回率和回答准确性的经验？目前用的是LangChain+Chroma，还没上reranker。
楼主
2026-07-19
RAG系统里文档切片粒度怎么选？按段落还是按句子？
请 登录 后发表回复
全部回复
共 162 条
2楼
3天前
你这个保修期的例子太典型了，句子切确实容易把条件句和结论拆散。我一般用固定长度加重叠窗口，比如512 token切、重叠128，比纯按段落稳一些，段落长短不一时不至于一段召回太多噪音。另外你还没上reranker的话，建议先加个bge-reranker试试，很多时候召回段落偏长的问题靠重排能压下去不少，比纠结切片粒度见效快。FAQ这种结构化的其实可以单独走一条路，按问答对切，跟产品手册分开处理。
3楼
1天前
你这个情况挺典型的，按段落切确实容易召回一大坨，LLM 读着读着就自己发挥了，按句子切又容易把条件句和结论拆散。我之前做类似 FAQ 知识库的时候也踩过这个坑，后来改成按语义切，也就是先按段落粗切，再用 embedding 相似度把相邻句子合并成一个小块，块大小控制在 200 到 400 字左右，效果比纯段落或纯句子稳不少。像你举的保修期那个例子，关键是把“非人为损坏”这种限定条件和结论绑在同一个 chunk 里，所以切的时候最好保留一点重叠，比如前后各带一句。另外你还没上 reranker 的话，召回阶段可以先把 top-k 放大一点，比如 10 到 15，再靠 reranker 精排，能明显减少那种“召回对了但排序靠后”的情况。Chroma 本身对元数据过滤支持还行，可以把产品型号、文档类型这些塞进 metadata，检索时先过滤再向量搜索，准确率会高一些。还有一个思路是 FAQ 类和手册类分开处理，FAQ 本身问答成对，直接整条切就行，手册再按语义块切，别一套参数打天下。