AI 怎么切分你的网页，你怎么控制切法——内容切块策略
在 RAG 系统的「入库四步」里，切块（Chunking）是第二步——爬虫抓完你的页面之后，系统要做的第一件事就是把长文档拆成小块。
为什么要拆？两个原因。第一，LLM 的上下文窗口装不下整个互联网，只能送最相关的"片段"进去。第二，向量嵌入需要语义足够聚焦的文本才能产生精准向量——一篇 5000 字的文章塞给 Embedding 模型，出来的向量会变成一个"什么都沾一点但什么都不精确"的模糊点。
切块方式直接决定你的内容在 RAG 检索里的表现。 切得好，每个 chunk 都是一个独立、完整、语义聚焦的知识单元，检索时精准命中；切得差，chunk 要么信息残缺、要么主题混乱，在向量空间里位置模糊，reranker 打分也上不去。
坦白说，我们没法直接控制 AI 搜索引擎用什么切块算法。但完全可以通过内容结构来"引导"切块结果——就像我们控制不了裁缝用什么剪刀，但可以在布料上画好辅助线。
读完这篇你会搞清楚：
- 切块在 RAG 系统里的位置和作用——为什么说它是"隐形但关键"的环节
- 主流切块方法有哪些——固定长度、递归分割、语义切块、结构化切块的区别
- Chunk 大小怎么影响检索效果——太大和太小分别有什么问题
- 怎么写出"切块友好"的内容——五条从切块机制推导出的结构化原则
- 怎么测试你的内容的可切块性——一套实操检查流程
什么是切块——RAG 系统里的"隐形裁缝"
切块的定义很简单：把一篇长文档拆成多个短片段（chunk），每个片段分别做向量化和索引。
在 RAG 的「入库四步」（爬取 → 切块 → 向量化 → 入库）里，切块是承上启下的关键环节。上游爬虫抓到的是完整的 HTML 页面，下游 Embedding 模型需要的是语义聚焦的短文本。切块就是把前者变成后者的过程。
爬虫抓取的完整页面（可能 3000–10000 字）
│
▼
切块算法按规则拆分
│
├── chunk 1（约 200–350 字）→ 向量化 → 入库
├── chunk 2（约 200–350 字）→ 向量化 → 入库
├── chunk 3（约 200–350 字）→ 向量化 → 入库
└── ... 以此类推
为什么不把整篇文章当一个 chunk？ 因为一篇文章通常覆盖多个子话题。整篇当一个 chunk 的话，它的向量会是所有子话题的"平均值"——跟每个具体问题都"有点关系"但跟每个都"不够近"。拆成小块之后，每个 chunk 只讲一个点，向量在语义空间里的位置就精准得多，被特定查询命中的概率也高得多。
我们为什么要关心切块？ 因为切块是我们能通过内容结构间接控制的环节。AI 搜索引擎的切块算法我们改不了，但可以通过段落结构、标题层级、段落长度来"暗示"算法在哪里切——就像在纸上画好虚线，方便对方沿线裁剪。
主流切块方法——AI 系统怎么拆你的内容
不同 AI 搜索引擎用的切块策略不一样，但主流方法大致分四类：
固定长度切块（Fixed-size Chunking）
最简单粗暴：按固定 token 数切割。比如每 500 个 token 切一刀，不管内容讲到哪。
- 优点：实现简单，chunk 大小统一，方便批量处理
- 缺点：可能在一句话中间切断，导致 chunk 信息残缺。比如"GEO 的核心原则是让内容在 RAG 管道的每个环节都"——切到这里就断了，后半句在下一个 chunk 里
- 常见改进：加 overlap（重叠），每个 chunk 和前一个 chunk 有 50–100 token 的重叠，减少边界信息丢失
递归分割（Recursive Text Splitting）
LangChain 等主流 RAG 框架的默认方法。思路是：先尝试按最大的结构单元（段落）切割；单个段落超长就往下一级（句子）切；还是太长就按字符切。
- 优点：尽量在自然边界（段落、句子）处切割，保持语义完整性
- 缺点：依赖内容结构质量——段落很长又没分段的话，算法被迫在句子层面切，chunk 质量会下降
- 这是目前最常见的切块方法，大多数 RAG 系统都在用递归分割的某种变体
语义切块（Semantic Chunking）
更聪明的方法：先用 Embedding 模型算每句话的向量，然后在语义变化最大的地方切割。比如前五句话讲"向量嵌入"，第六句突然跳到"robots.txt"——算法检测到语义跳变，在第五句和第六句之间切一刀。
- 优点：切出来的每个 chunk 在语义上高度连贯
- 缺点：计算成本高（每句话都要做 embedding），处理速度比递归分割慢得多
- 目前状态：高端 RAG 系统和企业级应用在用，大规模公共搜索引擎可能用简化版本
结构化切块（Document-structure Chunking）
按文档的标题层级（H1/H2/H3）和 HTML 结构来切。遇到一个 H2 标题，就开始一个新 chunk；chunk 一直延续到下一个同级或更高级别的标题出现。
- 优点：最大程度尊重内容的原始结构，chunk 的语义边界和作者的意图一致
- 缺点：H2 小节特别长（超过 1000 token）的话，还是会被二次切割
- 对 GEO 的含义：这种方法意味着你的标题层级直接影响切块结果。清晰的 H2/H3 结构等于给算法画好了裁剪线
各方法对比：
| 切块方法 | 切割依据 | chunk 语义质量 | 对内容结构的依赖度 | 你能通过写法影响多少 |
|---|---|---|---|---|
| 固定长度 | token 数 | 低——经常切断语义 | 无 | 几乎不能 |
| 递归分割 | 段落 → 句子 → 字符 | 中——尊重段落边界 | 中 | 能影响——段落长度和分段质量很关键 |
| 语义切块 | 向量语义变化 | 高——每个 chunk 语义连贯 | 低 | 间接影响——主题清晰的内容切得更好 |
| 结构化切块 | H2/H3 标题层级 | 高——完全按作者意图切 | 高 | 非常能影响——标题结构就是切块指令 |
实际情况：大多数 AI 搜索引擎用的是递归分割 + 结构化切块的组合——先按标题结构切，某一节太长再用递归分割做二次切割。也就是说，你的标题层级和段落长度对最终切块结果影响很大。
Chunk 大小怎么影响检索效果
Chunk 不是越小越好，也不是越大越好。太小和太大都有问题：
| chunk 太小（< 100 token） | chunk 太大（> 800 token） |
|---|---|
| 信息残缺，一个 chunk 说不清一件事 | 主题混杂，向量位置漂移到"中间地带" |
| 检索时即使命中了，LLM 也提取不出有用信息 | 被精排淘汰——reranker 发现信息密度低（大量无关内容稀释了有用信息） |
| 引用时没有足够的上下文支撑一个完整观点 | 在向量空间里缺乏清晰的**「语义锚点」** |
业界共识的 sweet spot：300–500 token（中文约 200–350 字）。 这个范围刚好够容纳一个完整的论点或知识点，同时又足够聚焦让 Embedding 模型产生精准向量。
重叠（Overlap）的作用
大多数切块系统会在相邻 chunk 之间设置 50–100 token 的重叠区域。为什么？因为如果恰好在一个关键信息点中间切了一刀，这个信息在两个 chunk 里都只剩一半——两个半截 chunk 单独看都不完整。有了重叠，边界附近的信息会同时出现在两个 chunk 里，至少有一个能提供完整上下文。
对 GEO 写法意味着什么：别在段落结尾放最关键的信息——它容易成为某个 chunk 的末句，而且可能被截断。关键结论放在段落中间靠前的位置（第二句或第三句），或者更好的做法是按**「首 chunk 原则」**，直接在段落第一句就写完核心结论——这样即使被切，第一句的结论句大概率在 chunk 前部，reranker 权重最高。
怎么写出"切块友好"的内容——五条结构化原则
搞清楚了切块的机制，可以反推出五条写作原则。这些不是"写作技巧"——是从 RAG 的切块机制直接推导出来的结构化要求。
原则一：每个 H2 小节只讲一件事
这是最重要的一条。一个 H2 小节 = 一个话题 = 一个高质量 chunk（或少数几个紧密相关的 chunk）。
一个 H2 小节里塞三个不同话题的话，结构化切块会把它当作一个大 chunk——向量位置发散，三个话题都不精准。即使递归分割把它拆成了几个 chunk，每个 chunk 里可能混有其他话题的片段——检索精度照样受影响。
改写前：一个 H2 叫"SEO 和 GEO 的注意事项"，里面同时讲了 robots.txt 配置、Schema 标记、内容写法。三个话题完全不同，但挤在一个小节里。
改写后：拆成三个 H2——"robots.txt：确认 AI 爬虫能访问你的网站"、"Schema 标记：给 AI 系统提供结构化信号"、"内容写法：怎么写出 AI 愿意引用的段落"。每个小节聚焦一个话题，切块后每个 chunk 都有清晰的**「语义锚点」**。
原则二：H2 小节长度控制在 200–350 字
这个数字不是随便说的——它对应 300–500 token 的理想 chunk 大小。H2 小节恰好在这个范围内的话，结构化切块会把它完整地当一个 chunk，不需要二次切割。
超过 500 字的 H2 小节几乎一定会被切成两个或更多 chunk。如果控制不了小节长度（有些话题确实需要展开），至少确保在自然的语义断点处分段——让算法在你预设的位置切，而不是在信息中间硬切。
原则三：首句写结论
结论先行这条原则我在站内其他文章里讲过很多次，但从切块角度有个新理由：chunk 的前几句话在 reranker 打分中权重最高。
段落第一句是"关于这个问题有很多值得讨论的方面，接下来的文字我们细说"——reranker 看到这种开头会判断"信息密度低"，打低分。如果第一句是"AI 搜索引擎平均每个回答引用 21.87 个来源（Perplexity 数据）"，reranker 立刻识别到"有具体数据，信息密度高"，打高分。
**「首 chunk 原则」**的切块版本：chunk 的前 50 个 token 决定了它在精排里的命运。
原则四：段落自包含——通过「200 字独立测试」
「200 字独立测试」也是我们在多篇文章里反复提到的原则。切块之后，每个 chunk 会脱离原文上下文独立存在。一个以"如上所述"或"综合前面的分析"开头的段落，被切成 chunk 后对 LLM 来说就是一段莫名其妙的话——因为 LLM 看不到"上面"说了什么。
「200 字独立测试」的具体操作：
- 随机选你文章里的任意一个段落
- 复制出来，单独粘贴在空白文档里
- 不看原文上下文，只看这一段
- 问自己：这段话能独立传达一个完整的信息点吗？
- 如果需要"参考上文"或"参考下文"才能看懂 → 需要重写
常见不合格写法和修复方式：
| 不合格写法 | 问题 | 修复 |
|---|---|---|
| "如上所述，这很重要" | "上面"说了什么？chunk 里看不到 | 直接重述核心观点，不引用上文 |
| "这个方法的三个步骤如下" | "这个方法"是什么？上下文丢失 | 明确写出方法名称 |
| "它的性能提升了 30%" | "它"是什么？ | 写出完整主语 |
| "同理，B 也适用" | "同理"于什么？A 在哪个 chunk 里？ | 直接说"B 的原理是……" |
原则五：标题层级就是切块指令
在结构化切块中，H2 和 H3 标题就是切块的分界线。这意味着：
-
H2 标题本身要有语义信息。"概述"、"注意事项"、"总结"这些标题在向量空间里几乎没位置——它们不包含任何具体的话题信号。相比之下，"向量嵌入怎么影响 AI 检索精度"就是一个有明确语义位置的标题。关于标题和列表的 AI 提取优化，后续有更详细的展开。
-
H3 只在 H2 内部使用。跳级（H2 直接到 H4）会让切块算法犯迷糊——它不确定这是新主题还是上一个主题的延续。
-
不要用加粗文字代替标题。HTML 的
<strong>和<h2>对切块算法来说是完全不同的信号。加粗文字不会触发新的 chunk 边界，标题会。
测试你的内容的"可切块性"
理论讲完了，这里给一个实操的检查流程。我把它叫做**「切块预演」**——模拟 AI 系统的切块过程，在发布之前预判你的内容会被怎么切。
「切块预演」操作步骤
第一步：标记切块边界。 打开你的文章，在每个 H2 标题前画一条线——这就是结构化切块的主要切割点。
第二步：检查每个"准 chunk"的长度。 每条线之间的内容就是一个准 chunk。数一下字数（中文字数，不含标点）：
- 200–350 字 → ✅ 理想范围
- 350–500 字 → ⚠️ 偏长，可能被二次切割，确保有清晰的段落分隔
- 500 字以上 → ❌ 太长，几乎一定会被切成多个 chunk，建议拆 H2
第三步：对每个准 chunk 做「200 字独立测试」。 把这段文字单独拎出来读，能不能独立传达一个完整的信息？不能就改。
第四步：检查首句。 每个准 chunk 的第一句话是不是有信息量的结论句？如果是"关于这个问题"、"接下来我们看看"这类空话开头，改成具体结论。
第五步：检查标题语义。 每个 H2 标题是不是包含了具体的话题信号？能不能被当作一个搜索查询？如果标题是"第三部分"或"其他注意事项"，改成有语义的表述。
这五步做下来大概 15–20 分钟（一篇 3000 字的文章）。我自己在写 GEO 内容时，发布前都会跑一遍这个流程。
常见问题
切块大小到底应该多大？
业界共识是 300–500 token，中文约 200–350 字。这个范围刚好容纳一个完整的知识点，同时语义足够聚焦。过小（< 100 token）会导致信息残缺，过大（> 800 token）会导致主题混杂、向量位置发散。你无法直接设置 AI 搜索引擎的 chunk 大小，但可以通过控制 H2 小节长度来间接引导。
我能控制 AI 搜索引擎怎么切我的内容吗？
不能直接控制，但可以间接引导。大多数系统用递归分割 + 结构化切块的组合，会优先在标题边界和段落边界处切割。你的 H2/H3 标题层级和段落结构就是给算法的"暗示"。内容结构清晰、段落长度适中的话，切块结果通常跟你预期的很接近。
FAQ 和 Q&A 格式为什么对切块特别友好？
因为每个 Q&A 对天然就是一个自包含的 chunk。问题提供了明确的查询匹配信号，回答提供了完整信息——两者组合在一起，既有清晰的「语义锚点」，又通过了「200 字独立测试」。这就是为什么有 FAQPage Schema 的页面 AI 引用率是无 Schema 页面的 2.7 倍。
长篇深度文章会不会因为切块而吃亏？
不会，反而可能更有优势——但前提是结构好。一篇 5000 字的深度文章如果结构清晰（每个 H2 小节 200–350 字、首句写结论、段落自包含），会被切成十几个高质量 chunk，每个都有机会在不同查询中被命中。相比之下，一篇 500 字的短文只能产生一两个 chunk，覆盖面窄得多。深度内容 + 好结构 = 更多高质量 chunk = 更多被引用的机会。
Overlap（重叠）是什么意思？我需要关心吗？
Overlap 是切块系统在相邻 chunk 之间保留的重叠区域（通常 50–100 token），用来避免关键信息被切到两个 chunk 边界上。你不需要主动做什么来"配合" overlap——只要段落结构合理、关键信息不集中在段落首尾极端位置，overlap 机制自然能覆盖到。