跳到主要内容

K2.2 更聪明的切法：语义切块、滑窗与 late chunking

上一节的「固定大小切块」简单好用，但它有个天生的毛病：它只数字数，完全不管意思——数到第 300 个字，哪怕正切在一个完整事实的中间，也照切不误。有没有更聪明的切法？

这一节看三个进阶思路。它们花样不同，解决的却是同一个问题：让切口落在「意思的接缝处」，而不是「字数的整数处」。

思路一：语义切块——在话题转折处下刀​

语义切块（semantic chunking） 不按字数切，按「意思是否还连贯」切。

它的做法很巧：把文档逐句变成向量（回扣 K1），然后看相邻句子的向量像不像。当连续几句都在讲同一件事，它们的向量彼此相近；一旦话题变了——比如从「退货政策」跳到「运费规则」——相邻句的相似度会突然「掉下一个台阶」。语义切块就在这个相似度断崖处下刀。

这样切出来的每一块，天然是一个完整的主题。上一节实验里「按语义切」之所以赢，正是因为它把「时长 + 例外」这两句讲同一件事（退货范围）的话，识别成了一个整体、放进了同一块。

思路二：滑动窗口——检索用小块，生成给大块​

还有一种思路不纠结「切多大」，而是把「检索」和「生成」分开对待：

  • 检索时用小块——小块精准，容易命中要害（回扣上一节：小块检索准）；
  • 喂给模型时，把命中的小块连同它的前后邻居一起带上——补全上下文（回扣上一节：大块上下文全）。

这叫滑动窗口 / 句子窗口（sentence-window）：以句子为检索单位，但生成时把命中句的左右几句一并奉上。它一箭双雕地拿到了「检索要准」和「生成要全」两个好处——命中的是精准的那一句，读到的是完整的那一段。

思路三：late chunking——先看全文，再切​

前两个思路都还是「先切块、再各自编码」。这个顺序有个隐患：每一块在被编码成向量时，看不到全文的语境。比如一块只写「它需要冷藏保存」——「它」是谁？脱离全文，这块的向量根本不知道自己在讲生鲜。

late chunking（2024 年提出） 把顺序反了过来：先用一个长上下文模型把整篇文档编码一遍，再切。因为编码时模型读到了全文，每个块得到的向量都「记得」自己在全文里的位置和语境——那句「它需要冷藏」的向量里，会带上「它 = 生鲜食品」的信息。精度因此明显提升。这是 2024–2026 年切块方向的一项新锐技术。

顺带一提 auto-merging（自动合并）：把小块按父子层级组织起来，当检索命中了好几个相邻的小块时，自动把它们合并成对应的「父块」再交给模型——相当于「小块负责精准命中，父块负责完整上下文」的自动版。

别追新，够用就好​

看到这里你可能想全都上。慢一点——这些技术不是越新越好。

固定大小切块 + overlap，在大量场景里依然够用、而且最省事。语义切块、late chunking 这些进阶切法，是在「文档结构复杂、跨段的完整事实多、检索精度要求高」时才显出价值的。为一个简单的 FAQ 库上 late chunking，多半是杀鸡用牛刀。

正确的顺序永远是：先用最简单的固定切块跑通，用 K6 的评测量出它到底差在哪，再有针对性地换更聪明的切法。 而不是一上来就堆技术。

再聪明的切块也救不了烂源头

两个提醒。其一：切块技术 2024–2026 演进很快，记原理（让边界对齐语义）比记方法名重要——过两年方法名可能全换了，但「别把完整的意思切散」这个道理不会变。其二：切块只是「怎么切」，它救不了「源文档本身就写得烂、信息本身就缺失」——如果手册里压根没写清楚例外条款，切得再巧也变不出来。这就是上篇 4.1 节和 K0 反复强调的「垃圾进，垃圾出」，在切块环节的又一次现身。

小结​

本节要点
  • 三个进阶切法，一个共同目标：让切口落在意思的接缝处。
  • 语义切块在「相似度断崖」处下刀，每块是一个完整主题；滑动窗口检索用小块、生成给大块，两头都要；late chunking 先编码整篇再切，让块向量携带全文语境。
  • 不要追新：固定切块 + overlap 在很多场景够用且最省事，进阶切法在文档复杂、跨段事实多时才值。
  • 记原理（别切散完整意思）胜过记方法名；再聪明的切块也救不了写得烂的源文档。
📝 动手自测0/3
1. 「语义切块」和「固定大小切块」最本质的区别是什么？
2. late chunking 相比传统「先切块再编码」，关键的改变是什么？
3. 面对一个简单的 FAQ 知识库，最合理的切块策略选择是？

延伸阅读​