登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  人工智能

RAG 文档分块怎么设置 chunk_size 和 overlap

来源:17golang原创

时间:2026-09-06 07:35:56 192浏览 收藏

RAG 文档分块没有一组对所有知识库都适用的固定数字。比较稳妥的起点是先把 chunk_size 当成单块的最大长度,把 chunk_overlap 当成相邻块之间保留的上下文,再用真实问题检查“命中的块是否讲完整了”。对中文说明文档,可以先试 600~900 个字符、重叠 10%~20%;手册章节很长时再增大块,定义和条件经常跨段时再增加重叠。

要点速览
  • chunk_size 决定单块上限,chunk_overlap 只负责缓冲边界,不是越大越好。
  • RecursiveCharacterTextSplitter 默认优先保留段落和换行;中文文本应补充句号、逗号、顿号等分隔符。
  • 最终参数要看固定问题集的召回完整度、重复块比例和上下文预算,而不是只看切出了多少块。

先把 chunk_size 和 chunk_overlap 分工

RecursiveCharacterTextSplitter 是 LangChain 文档推荐用于通用文本的切分器。它按分隔符列表递进尝试,默认顺序是空段落、换行、空格、空字符串;长度由 length_function 衡量,常见默认值是 Python 的 len。因此这里的 800 更接近 800 个字符,不应直接理解为 800 个 token。

chunk_size 解决“一个块最多放多少内容”,过小会让一个定义、条件和例外被拆开;过大则会让一次检索带回许多无关段落。chunk_overlap 解决“边界附近保留多少上下文”,它只能缓冲切点,不能替代合理的分隔符。重叠越大,索引体积和重复检索内容也会一起增加。

RAG 文档分块中原始文档、递归分隔符、chunk_size、chunk_overlap、Document 块与检索上下文的静态关系图
图1:把原始文档、切分参数与最终 Document 块放在同一张静态关系图里,先分清两个参数各自控制什么。
现象优先调整判断依据
答案被拆在相邻块先补分隔符,再小幅增加 overlap命中块能否同时包含定义和限制条件
每次召回内容过宽减小 chunk_size 或提高检索过滤上下文中无关段落是否明显增多
单个块经常过短增大 chunk_size一个主题是否被切成多个孤立短句

用一个可解释的配置建立起点

不要一开始就把参数写死在所有数据源共用的配置里。先为同一类文档准备一组小样本,记录标题、正文和来源页,再把切分参数集中在一个函数中,后面才能比较不同版本。

from langchain_text_splitters import RecursiveCharacterTextSplitter

# 中文技术文档优先按段落、句号和逗号保留语义边界
separators = ["\n\n", "\n", "。", "!", "?", ",", "、", " ", ""]

# 先用中等块和适度重叠,避免上下文成本一开始就过高
splitter = RecursiveCharacterTextSplitter(
    separators=separators,
    chunk_size=800,
    chunk_overlap=120,
    length_function=len,
    is_separator_regex=False,
)

# create_documents 会保留后续检索需要的 Document 结构
documents = splitter.create_documents([text])

这里的 800 和 120 只是起始配置。官方示例用更小的数值演示接口,并明确说明 chunk_overlap 是相邻块的目标重叠量。实际项目还要结合嵌入模型的输入限制、检索条数和最终提示词预算。如果只需要字符串,可以调用 split_text;需要把内容交给后续 RAG 链路时,通常使用 create_documents 更方便。

中文文档要补分隔符

英文空格可以帮助切词,中文却经常没有词间空格。只沿用默认分隔符,长句可能一路回退到字符级切分,导致人名、接口名或“条件—结论”关系被切开。更合适的做法是把中文句号、全角逗号、顿号等放在字符回退之前,让切分器优先寻找自然边界。

中文 RAG 文档分块中段落换行、中文标点、字符回退、语义块和嵌入检索的静态关系图
图2:中文分隔符层决定语义块边界,字符回退只是最后兜底;这也是中文知识库不宜只沿用空格分隔的原因。

需要注意,加入标点并不等于每块都完整。标题、列表、代码块和表格往往有自己的结构,遇到这类文档可以先按 Markdown 标题或 HTML 节点做父级切分,再在过长的父块内部使用递归切分。不要为了追求块数少,把整章手册直接塞进一个向量。

用检索问题反推参数,而不是盯着块数量

准备 10~20 个真实问题,给每个问题标出应该命中的段落。分别用 600/80、800/120、1000/150 这样的少量组合试跑,比较三个结果:命中块是否包含完整答案,前后块重复是否过多,以及拼进提示词后是否挤压了模型真正需要的上下文。结果只支持当前文档类型,不代表换一批资料仍然最优。

如果定义和限制条件常常分离,先检查分隔符是否过早切断,再考虑把 overlap 从 120 调到 160;如果命中块包含很多相邻主题,则先把 chunk_size 降到 600~700,或增加元数据过滤。只有当切分质量稳定后,才值得继续讨论向量模型、重排器和召回条数。

常见问题

chunk_overlap 可以设置成 chunk_size 的一半吗?

可以作为实验值,但通常成本偏高。只有当答案强依赖跨段上下文,且检索预算允许大量重复内容时,才值得测试这么大的重叠。

chunk_size 用字符还是 token 更合适?

取决于 length_function。默认示例按字符衡量;如果你的模型上下文限制按 token 计算,应在实验中用与目标模型更接近的长度函数,并保留安全余量。

为什么切分后中文句子还是被拆开?

检查中文标点是否出现在分隔符列表中、顺序是否早于空字符串,并确认原文是否包含不可见字符或超长无标点段落。必要时再针对该文档类型增加标题和列表规则。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>