切块大小没有通用最优值，但有一个能落地的起点：按文档的自然结构切，标题层级优先。按固定 token 数切，最大的毛病不是切得难看，是切块器不知道自己在劈什么——一个完整论述被从中间截开，检索命中半句话，模型拿着半句话把另一半编出来。这周外部素材基本不在这条线上，所以下面主要是我自己的判断。
按 token 数切，问题是它不知道自己在劈什么
一个 h3 下面写了两段半，第三段刚开头就是"这个方案的问题在于"——固定长度一切，"这个方案"在上一块，"问题在于"在下一块。检索命中后一块，模型看到的是个没有主语的判断句。它不会说"我看不懂"，它会顺着往下编。
表格被劈开、代码块被劈开、列表被从第 3 条切到第 4 条，都是同一个毛病。
这周有篇讲 agent 认知谦逊的论文挺应景：Accurate but Not Humble 里问的是，检索到的证据和模型先验冲突时，它会不会改答案、会不会承认不确定。结论是不太会。这事对做 RAG 的人的意义在于：检索质量差不会以"我不知道"的形式暴露，会以自信错答的形式暴露。所以上游切块切坏了，你在下游看到的是一堆看起来很确定的错误回答，很容易误判成模型不行。
按结构切的实操没什么玄学：h2/h3 当边界，段落当最小单位，把标题路径拼进 chunk 开头（"部署 > 回滚 > 灰度"这种）。这样每块自带上下文，指代也能对上。代码和日志更好办，函数边界、时间戳、堆栈本来就是明确的——500B Tokens Later 那种反编译项目不用猜边界在哪，符号表就是边界。
但结构化切块会失效，这个得认
反面情况是真实存在的，而且不少。
纯文本长文最典型：访谈转录、OCR 出来的扫描件、论坛长贴、小说。它们要么没有标题层级，要么层级和语义不重合——一篇文章只有"引言/正文/结论"三个 h2，按这个切出来的块大得没边。还有一种是结构切出来尺寸失控：某个 h2 下面三千字，某个 h3 下面两行，检索时小块的权重被大块稀释。
这时候退回固定长度 + 重叠，不是妥协得难看，是正确选择。但重叠别按 token 留，按句子留——切点对齐到句号或换行，别切在词中间。留一整段的重叠通常够用，具体多少自己拿上面那 20 块的检查法测，我不给数字。
按语义切（相邻句 embedding 相似度骤降处下刀）听起来更对，但按我现在看，成本高、结果不稳定，同一份文档跑两次切点都不一样，调试起来很痛苦。也许一年后回头看会打脸，但现在我不用它。
切完抽 20 块，自己读一遍
这是最便宜也最有效的验收方式。从索引里随机抽 20 块，别看原文直接读。读不懂就是切错了。判断标准就三条：
- 这块能不能独立回答一个具体问题？
- 里面有没有指代不明的"这个""该方法""上述方案"？
- 标题信息带进来了吗，还是光看这块不知道它在讲哪个章节？
20 块够看出系统性毛病，不用抽几百块。半小时的事。跳过它，成本会挪到上线后——那时候你在 debug 检索质量，用户在看错误的答案，难度高一个量级。
再补一步：拿 10 个真实问题跑一遍，看命中的 chunk 里有没有半截话。有的话回去改切法，别去调 prompt。
这周外部素材确实不在这条线上
ArXiv 和 HN 这周被 agent 安全刷屏了——OpenAI、Anthropic、Google 的 agent 跑出测试范围，Wikimedia 上的 rogue agent，韩国的银行被 AI 相关手段打。跟切块没关系，不硬凑。
OnTrack 标题里有 structure-aware，但那说的是 agent 轨迹的流式监控，跟文档切块不是一回事。只能说这一周"结构"这个词在好几个方向上被反复提，算个气氛，不算证据。
回到命题。别先问切多少 token。先看你的文档有没有结构——有就顺着切，标题路径拼进去；没有就固定长度加句子级重叠，切点对齐到句号；切完抽 20 块自己读一遍。读得懂，就往下走；读不懂，改切法，别改 prompt。