首页  思维导图  详情



 



Chunk 切分基本思路

2026-03-25 16:22:37   5  举报





AI智能生成

RAG 系统中最"接地气"的环节

chunk

RAG

Chunk 切分

模板推荐

作者其他创作

大纲/内容

历史版本

V1：固定长度切分

按 512 token 一刀切，加 100 token 的 overlap

问题

保险条款"第 3 条 保险责任：本保险承保……但以下情况除外：（1）战争……（2）核辐射……"被从"但以下情况除外"的地方截断，承保范围和免责条款分到了两个 Chunk 里。

用户问免责相关的问题时，系统只召回了前半段（承保范围），给出了完全错误的答案。

V2：基于句子边界的切分

改用句号、问号等标点作为切分点，确保不在句子中间截断。每个 Chunk 累积句子直到接近 512 token 上限。

<br>

问题

列表项"（1）战争（2）核辐射（3）核爆炸"会被拆到不同 Chunk——每个列表项都是一个"句子"，但脱离了前面的"以下情况除外"就失去了语义。

章节标题"第 3 条 保险责任"可能跟下面的正文被分开。

最终方案

V3：基于文档结构的语义切分

核心思想

不是"把长文本切短"，而是"识别文档的语义单元，按单元切分" 。

先识别文档结构（章节标题、子标题、段落、表格、图片）

按语义单元切分——一个章节就是一个 Chunk（如果不超长的话）

超长的章节再递归按子标题或段落切分。

表格整块保留，列表项跟前导句合并。

核心逻辑

第一步：识别文档层级结构

先理解文档结构，再决定在哪切。

多策略融合

# 策略1：正则匹配常见编号模式<br>

<br>

# 第三条

# 1.1.1

# （一）

# 1.

# 策略2：利用解析模块输出的样式信息

# font_size, bold, indent_level

# 策略3：训练一个轻量级层级分类器

# 特征: 编号类型、字体大小、是否加粗、缩进、位置

在 500 份标注数据上训练了一个 XGBoost 分类器，层级识别准确率达到 94%。纯规则只有 77%——因为有 23% 的文档编号不规范（跳号、重复、混用）。

第二步：按语义单元切分

识别出层级结构后，切分逻辑变成了递归：

token 数 

如果一个章节的 token 数 ≤ 1024，整个章节作为一个 Chunk，不切。

如果一个章节超过 1024，看有没有子标题。有的话按子标题切分，每个子章节再递归判断。

有子标题

有的话按子标题切分，每个子章节再递归判断。

无子标题

没有子标题，按段落累积——段落逐个加入，直到接近 1024 token 就封一个 Chunk。

如果单个段落就超过 1024（极端情况），最后才按句子边界切分。

表格和代码块作为不可拆分单元——无论多长，不在中间截断。如果单个表格超过 1024 token，单独作为一个 Chunk。

第三步：语义完整性检查

切完之后不是直接用，还要做一轮检查——相邻的两个 Chunk 之间是不是被错误地断开了。

经典场景

# 场景1：chunk1 以冒号结尾 → 后面大概率是列表

# 场景2：chunk2 是列表项编号开头

# 场景3：chunk2 以转折词开头

'但', '然而', '除外', '不包括'

智能 Overlap

固定 overlap

可能在句子中间截断。"本保险承保意外伤害导致的身故或残"——overlap 从"残"字开始，语义不完整。

基于句子边界的 overlap

找到前一个 Chunk 末尾最近的句号位置，从那之后开始 overlap。

每个 Chunk 的 overlap 部分都是完整的句子。

特殊元素的处理

表格

小表格

（3 行 5 列，300 token）直接整块作为一个 Chunk

大表格

（50 行 10 列，5000 token）远超 Chunk

如果表格有分组

按分组切分，每组带上完整表头

如果没有分组

按固定行数切分，但每个 Chunk 都复制表头

图片

流程图和示意图用多模态模型生成文本描述

数据图表用 chart-to-text 模型提取结构化数据

纯装饰图片直接跳过

列表项

必须跟前导句合并

"以下情况除外：（1）战争（2）核辐射（3）核爆炸"——如果把每个列表项单独成 Chunk，每个 Chunk 都缺少"以下情况除外"这个关键前导句。

识别列表结构后，将前导句和所有列表项合并为一个 Chunk。

如果合并后超长，至少保证前导句出现在每个子 Chunk 的开头。

Chunk 的元数据设计

每个 Chunk 都应该带上丰富的元数据

{     "content": "保险金额为50万元...",     "metadata": {         "doc_id": "contract_123",         "chunk_id": "chunk_045",         "page_num": 5,         "section_path": "第二章 保险条款 > 2.1 保险责任",         "content_type": "text",         # text/table/image         "is_key_clause": True,          # 关键条款加权         "prev_chunk_id": "chunk_044",   # 上下文扩展用         "next_chunk_id": "chunk_046",         "confidence": 0.96              # 解析质量分数     } }

section_path

答案溯源——"根据第二章 保险条款 > 2.1 保险责任，保险金额为……"

is_key_clause

检索时给关键条款（责任、免责、费率）的权重 ×1.5，因为这些内容被问到的概率最高。

prev/next_chunk_id

如果检索到的 Chunk 语义不完整（比如只检索到了"但以下除外："），自动拉取前后 Chunk 补充上下文。

<br>

实际踩过的五个坑

坑一：chunk_size 设太小导致语义残缺

初版设了 512 token，一些复杂保险条款被切碎——"本保险承保意外伤害（定义见第 X 条），包括但不限于……，但以下情况除外：……"这种复合长句被切成 3 个 Chunk，LLM 看不到完整逻辑。

解决： 整体提升到 1024 token，对关键条款（责任、免责）允许更大的 max_size（1536）。

坑二：表格被切分后表头丢失