面向 RAG 与大模型的文本切块：长度、重叠与边界怎么选才管用

RAG 会在无声中失败——往往因为块切错了。 太小丢上下文，太大则向量语义被稀释还吃光 token。按固定 512 字符硬切会把句子拦腰斩断，用户问的那一段永远进不了 Top‑k。

本文说明 RAG 里的切块角色、重叠权衡、结构感知切分，以及如何用 Safe Local Tools 在本地试验，再把专有文档送去嵌入 API。

切块在 RAG 流水线中的位置

典型路径：

1. 摄入文档（PDF、HTML、工单）。
2. 切分 为块。
3. 每块 嵌入 向量库。
4. 查询时取 Top‑k。
5. 塞进 LLM 提示词。

检索天花板由块质量决定；换再强的模型也救不了「从没召回到正确段落」。

按 token 还是按字符

嵌入常按 token 计费；存储可能按字节。粗起点：

内容	块大小（token）	备注
带标题的技术文档	400–800	尊重章节
聊天记录	200–400	按发言人
法律长文	800–1200	重叠很重要
代码	函数/类级	勿拦腰切块

务必在自己的语料上实测——法律与 API 文档差别很大。

重叠：为何 10–20% 常有效

块 N 与 N+1 共享尾部句子：

• 跨边界的句子至少完整出现一次。
• 边缘语义在多个向量里保留。

代价：存储与嵌入费用上升；检索可能重复，需去重。

可从 块大小的 10–15% 重叠 起调，用标注问答集看召回。

结构优先于纯长度

推荐边界顺序：

1. Markdown/HTML 标题（##）
2. 段落（空行）
3. 句号
4. 空白
5. 硬截断（最后手段）

代码按函数切；表格保持行完整或每行带表头重复。

每块应带的元数据

• source_file、page、section_title
• updated_at（新鲜度）
• 多租户 acl
• chunk_index / total_chunks

无元数据时模型难引用出处，易胡编。

评估：别靠感觉

准备 30–50 个真实问题，标金标准段落。看：

• Recall@k
• MRR
• 回答是否忠实（人工或 LLM 评判）

一次只改一个变量；记录嵌入模型版本。

常见失败

1. 导航栏、页脚进块——污染向量。
2. 重复 boilerplate 主导相似度。
3. 多语言混索引未检测语种。
4. 大表拍平——数字语义差。
5. 索引陈旧——仍召回旧 API。

预处理：剥模板、去重页眉、版本化索引。

混合检索仍依赖好块

BM25 + 向量时，产品型号被切断（PT-2048-A）两种检索都吃亏。

检索之后的 token 预算

k=8、每块 600 token → 仅上下文就 4800，还没算系统提示与用户问题。可先粗排再精排，Top 3–5 进模型。

隐私与本地试验

企业手册不应上传到陌生切块演示站。Safe Local Tools 在浏览器处理文本，可在离线环境调参。

按场景配方

内部 Wiki： 按标题、约 600 token、重叠 80、去掉导航。

工单： 按会话段；元数据带 ticket id。

合同： 按条款标题；高重叠；关键回答人工抽检。

API 文档： 按端点；块前缀含 method + path。

何时不必 RAG

总语料能塞进单次上下文的小 FAQ，直接注入即可。切块增加运维——别为演示而上向量库。

迭代

把 chunk_size、overlap、splitter 版本化进 Git；非高峰重嵌入。

父子块（parent-child）

检索用小粒度高召回，生成时把命中块关联到更大「父段落」一并送入模型，兼顾精度与上下文。

合规删除

源文档因 GDPR 等被删除时，应同步删除向量与元数据，避免孤儿向量泄露已下架内容。

收尾

烂块是 RAG 演示「笔记本里行、上线不行」的静音杀手。先修检索，再争论模型谁更会说话。

想在上传前预览长文档的切分边界，试用文本切块工具 →