← 返回概念解读

Concept Fable精修版

滑动窗口分块

Sliding Window Chunking · Retrieval preparation

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

巡夜人每次多看一段路

城墙很长,巡夜人最早按固定路段交接。第一队守东门到钟楼,第二队守钟楼到粮仓。地图干净,责任也清楚。

问题总出在交界处。有人在钟楼前埋下火种,东门队说那已经靠近下一段;钟楼后的脚印被粮仓队发现,却不知道前面发生了什么。

城主先把路段切得更短。巡夜更细了,交接次数也多了,记录簿堆成小山。很多人只知道自己那十步路,仍然看不出前后连起来的动向。

后来他又把路段切得更长。上下文是够了,可每队背的范围太大,真正异常的几步反而淹没在长报告里。短有短的盲点,长有长的负担。

一位老巡夜人提出一个朴素办法:每队仍走固定长度,但下一队从上一队尚未走完的地方提前开始。两队之间保留一段重叠,边界就不再是黑洞。

这样一来,钟楼附近的火种会同时出现在两份巡夜记录里。东门队能看到它的来处,粮仓队也能看到它的去向。重复是有代价的,但比漏掉边界上的危险便宜。

城主担心记录变多。老巡夜人说,重叠不能贪多,窗口也不能任意大。路越复杂,重叠要能覆盖一件事跨段延续的最小长度;否则只是制造纸面安全感。

后来城墙、河道和仓库都用这种巡查法。每份记录独立可读,又和前后记录咬住一点,足够让调查员还原连续事件。大家才明白,边界要被设计,而不是假装不存在。老巡夜人还提醒,重叠段必须被认真读取。若下一队只是机械抄一遍,纸多了,眼睛却没多。真正有用的重叠,是让两队都能理解边界附近发生了什么,而不是把同一句话重复写进簿子。城主后来把这种办法用在案卷和账本上。只要一件事可能跨过边界,就给它留一点重叠,让下一段接得住上一段。后来复盘时,众人把这条经验写进日常规矩:先看现场哪里真正改变了结果,再决定该保留什么、修补什么、限制什么。

揭示

这个故事讲的是:滑动窗口分块

滑动窗口分块(Sliding Window Chunking)用固定大小的窗口切分长文档,并让相邻 chunk 之间保留一定 overlap。它的目标是减少语义或事实刚好跨越分块边界时被切断的风险。窗口大小决定每个 chunk 的信息容量,重叠长度决定跨边界上下文的保留程度。它实现简单、稳定,适合许多早期 RAG 系统和结构不稳定的长文档;缺点是会增加索引体积、重复召回和上下文浪费。生产系统通常会结合去重、reranking、parent-child chunking 或 semantic chunking 来控制噪声。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 固定路段交接:固定长度 chunking
  • 问题出在交界处:重要语义跨 chunk 边界导致断裂
  • 切得更短:chunk 变小提升局部精度,但上下文不足、数量变多
  • 切得更长:chunk 变大保留上下文,但检索变粗、噪声增加
  • 下一队提前开始:滑动窗口里的 overlap
  • 同一火种出现在两份记录里:重复存储换取跨边界信息保留
  • 窗口不能任意大、重叠不能贪多:chunk size 与 overlap 的工程权衡
  • 共同视野:RAG 系统为连续语义预留的上下文缓冲

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

chunk overlapchunk size

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。