收益：
- 以数值方式评估块大小、重叠和语义分块权衡
- 为不同的文档类型（PDF、表格、代码、聊天日志）选择合适的分块策略
- 通过向每个块添加元数据来增强检索质量和过滤
这是 RAG 中最容易被忽视但最具决定性的步骤：如何分解文档。这称为分块。即使您将相同的文档提供给相同的模型，由于分块错误，检索会返回错误的部分，并且模型永远不会产生很好的答案。在本单元中，我们将介绍碎片策略、如何根据文档类型调整碎片策略，以及如何向每个碎片添加有意义的元数据。
我们为什么要撕碎？
有以下三个原因。首先，嵌入模型将一定长度的文本转换为有意义的向量；如果将整个 40 页的章节塞进一个向量中，含义就会变得“模糊”。其次，我们只想为模型提供上下文所需的部分；移交整个文件既昂贵又分散注意力。第三，为了检索精确，检索单位必须小而集中。
所以chunk是最小的检索单位。它不应该太大或太小——刚刚好。
块大小和重叠平衡
有两个主要设置：块大小（一个块中有多少个标记/单词）和重叠（相邻块共享的部分）。
非常小的块（例如 100 个标记）：重点突出，但与上下文脱节。他说“14天”，但是14天是什么，是在前一句中留下的。非常大的块（例如 2000 个标记）：保留上下文，但混合了许多线程；嵌入变得混乱，不相关的主题聚集在一起。
重叠解决了边界问题。如果一个句子正好落在两个部分的边界上，那么它就被分成两部分，没有重叠，它的意义就失去了。 50-100个令牌的重叠确保了在限制内的信息至少在一部分中保持完整。
块大小
优势
缺点
适当的内容
小（100-250 个代币）
高灵敏度、专注
上下文可能会中断
常见问题解答、短文、定义
中等（300-600 个代币）
平衡；大多数场景
—
程序、政策文本
大（800-1500 个代币）
上下文完整性
模糊嵌入
叙述性、长解释
提示：如果您不知道从哪里开始，请从 400-500 个令牌块和 50-80 个令牌重叠开始；然后根据自己的数据进行测量和调整。 “正确”的尺寸并不通用，它取决于具体情况。
分块策略
固定大小：每 N 个标记修剪文本。它简单快捷，但可能会打断句子。
基于分隔符（递归/分隔符）：按照段落划分，然后按照句子边界划分；它更好地保留了意义的完整性。大多数生产系统都是以此开始的。
语义分块：它查看句子的嵌入，并在主题发生变化的地方对它们进行划分。这是质量最高但最昂贵的方法；随着交易量的增加，交易成本也会增加。
结构感知：使用文档结构，例如标题、章节、表格。例如，按标题拆分 Markdown 文档可确保每个部分都有自己的标题。
按文档类型进行调整
并非每个文档都是相同的。策略因类型而异：
- PDF/政策文本：基于书签，中等大小。清除页面顶部/底部重复内容（页眉/页脚）。
- 表格：不要断章取义；保留每一行的标题信息（“商品：X，价格：Y，库存：Z”）。将原始表转换为纯文本通常是必不可少的。
- 代码：按函数/类边界分割；不要删掉某个功能。
- 聊天/工单记录：按消息或对话轮次分割；了解谁说了什么。
# 基于括号的分块（概念） chunks = bol( text, target_size=450, # tokenoverlap=70, # tokenbrackets=["\n\n", "\n", ". ", " "] # 段落在前，单词在后)
将元数据添加到每个轨道
分块不仅仅是“划分”，而是“划分”。就是要丰富每一个作品。您附加到曲目上的每个标签都具有同等价值，可用于将来的过滤和来源引用。
# 丰富块（概念）{ "text": "年带薪休假为 14 天，工龄 1-5 年...", "metadata": { "source": "ik_el_kitabi_v7.pdf", "section": "5.2 年假", "page": 23, "date": "2025-06", "department": "IK", "privacy": "internal" }}
另一种强大的技术是添加上下文标题：在每篇文章的开头写下它所属章节的标题。因此，即使是像“For 14 days”这样不连贯的作品，也比“Annual Leave - 14 days”更好地嵌入并且更有意义。
弱分块/强分块
弱（盲目硬切，无元数据）：
每 1000 个字符截断文本。只保留文本。#结果：表格被中间分割，“14天”仍然没有上下文，#不知道它来自哪个文档，无法进行过滤。
强大（结构感知+标头+元数据）：
按标题划分文档；为每个部分添加章节标题；附加来源、页面、日期和隐私元数据；将表格行及其标题转换为纯文本。# 结果：重点突出、上下文相关、可过滤、可来源。
三个迷你箱
案例1——绘画灾难。财务团队将200页的价目表进行盲目硬剪；表行被随机分割。 “产品 X 的价格是多少？”该模型读取了错误的行并给出了错误的价格（12 个案例中有 9 个是错误的）。当我将表行转换为格式为“产品：... | 价格：... | 单位：...”的纯文本时，错误减少到 0（满分 12）。
情况 2 — 非常大的块。在 wiki 中，每个页面都由单个块组成（有人说 3,000 个令牌）。嵌入模糊，因为一页上有“请假”、“加班”和“工资”；关于休假问题，工作时间部分也发挥了作用。当页面按标题分为中等大小时，recall@5 从 64% 增加到 91%。
情况 3 — 句子被截断，没有重叠。法律团队固定削减 250 个代币，无重叠。一个关键的定义正好落在两个部分的边界上并一分为二；两者都没有包含完整的答案。当添加 60 个标记重叠时，相同的定义保持完整，并返回正确答案。
常见错误
- 盲定切：从中间分割句子和表格；意义就失去了。
- 将重叠保留为零：落在边界上的信息被分割并丢失。
- 不添加元数据：过滤和源显示变得不可能。
- 让表保持原始状态：模型无法解析表结构；将行转换为纯文本。
- 实施一种策略：PDF、代码、表格不采用同一种方法拆分；适应流派。
注意：不要设置分块一次就忘记了。随着新文档类型的出现（来自新系统的票据、扫描的 PDF），重新衡量检索质量。错误的输入数据意味着错误的响应（“垃圾输入，垃圾输出”）。
综上所述
- chunk是检索的最小单位；既不能太大也不能太小——应该根据内容来平衡。
- 块大小表明焦点-上下文平衡；重叠管理边界损失。
- 基于括号和结构感知的分块是大多数生成系统的起点；语义分块质量很好，但价格昂贵。
- 像表格、脚本和聊天这样的类型需要它们自己的策略；将表格转换为纯文本。
- 向每个轨道添加来源/日期/章节/隐私元数据和章节标题；这是过滤和引用的基础。
应用任务
将您选择的文档部分分成三种不同的方式：(1) 200 个标记的小块，(2) 500 个标记的中块（70 个标记重叠），(3) 单个大块。针对每个策略提出相同的 3 个问题，手动标记要引入的部分，并写下哪种策略最适合该文档的推理。然后向每个轨道添加至少四个元数据字段和一个“章节标题”。如果文档包含表格，请将表格行转换为“字段:值”格式的纯文本。
清单
- [ ] 我可以看出，块是检索的最小单位，大小是焦点上下文平衡。
- [ ] 我知道为什么重叠可以防止边界丢失。
- [ ] 我可以区分基于括号的分块、语义分块和结构感知分块。
- [ ] 我可以调整表格、代码和聊天的策略。
- [ ] 我通过向每个曲目添加元数据和章节标题来加强检索。