最近自己在搭一个RAG知识问答系统,用的langchain+chroma。遇到个头疼的问题:文档切得太碎(比如每段200字),检索出来的chunk往往信息不全,回答容易断章取义;但切得太大(比如1000字),又感觉召回率下降,很多不相关的内容混进来。尝试了重叠切分和不同embedding模型,效果都不太理想。想请教一下大家,在实际项目中,chunk size一般怎么设置?有没有什么合理的策略或者评估指标能指导这个调参过程?先谢过各位大佬了。
楼主
2026-07-19
RAG系统里文档切得太碎,检索反而变差了,怎么平衡?
请 登录 后发表回复
全部回复
共 147 条
2楼
2026-09-12
别光调chunk size,试试按语义或标题切,再给小块加点上下文摘要,效果会好很多。
3楼
2026-09-14
我一般按语义切,段落完整比固定字数重要,再配个检索命中率评估就行。
4楼
2026-09-16
我踩过这个坑,后来发现关键不是死磕chunk size,而是按文档结构来切。比如技术文档按标题层级切,FAQ就一问一答切,比固定字数靠谱多了。另外可以试试在小chunk检索后做上下文扩展,召回相邻段落再喂给LLM,这样既保住了精度又补全了信息。评估的话我一般看hit rate和最终回答质量,单看召回率容易跑偏。
5楼
2026-09-17
我一般按语义段落切,再设个token上限兜底,比死磕字数管用。
6楼
2026-09-20
我一般不会全局用一个固定chunk size,而是按文档结构走:FAQ、条款类保持小块,叙述性内容放大到500-800字,再配10%-20%重叠。你说的召回变差,很多时候不是size本身,而是embedding把整段语义平均掉了,可以试试小块检索、大块喂给LLM的parent-child方案。评估上别只看命中率,拿几十条真实问题做人工打分,看答案是否完整、有没有引入无关信息,这比盲目调参靠谱。
7楼
3天前
我一般按语义段落切,再用小模型给chunk打分筛一遍,比死磕size管用。
8楼
1天前
我一般按文档结构切,标题段落优先,再配合小比例overlap,比死磕固定字数靠谱多了。