最近在搭一个基于本地知识库的RAG问答系统，用来回答公司内部的技术文档。我一开始把文档切成512字符的chunk，结果发现很多问题跨段落，比如问“这个模块的接口和依赖关系”，答案只拿到了接口部分，依赖信息在另一个chunk里。后来我试着把chunk切大一点（1500字符），但检索时又容易混进不相关的内容，召回率下降。试过加sliding window和用LLM做rerank，效果有提升但感觉还是有点玄学。想问下大家平时做文档切片时，chunk size一般设多大？有没有什么比较靠谱的调参经验或者工具推荐？
楼主
2026-07-30
RAG系统里文档切得太碎反而丢了上下文，大家怎么平衡的？
请 登录 后发表回复
全部回复
共 103 条
2楼
3天前
我之前也踩过这坑，后来发现光调chunk size不够，得配合结构感知切分。比如按标题层级或者段落边界切，再给每个chunk加上它所属的章节路径，这样检索时能带上父级上下文。现在用的方案是子块检索、父块返回，效果比单纯调大小稳不少。你可以试试llama_index的sentence window或者hierarchical node parser，比自己手撸省事。
3楼
2天前
我一般按语义切，段落完整优先，再配个小overlap，比死磕字数管用。
4楼
1天前
我感觉chunk size真没万能值，得看文档结构。技术文档可以按标题层级切，父块保留章节摘要，子块细粒度检索，命中后把父块一起喂给模型，这样接口和依赖就不容易被拆散。我一般先试800到1200，再配合overlap 15%左右，效果比死调一个数稳。rerank有用但也别全指望它，检索前先把元数据过滤做好更实在。