本周 Towards Data Science 上，Priyansh Bhardwaj 的一篇实务文章把一件事讲清楚了：生产环境里绝大多数 RAG 故障，其实是 chunking 故障，不是检索或生成故障。全文的锚句很好引：「LLM 不是瓶颈。瓶颈在于"上一块在哪里结束、下一块从哪里开始"这个决定。」文章没有停在抽象论证层面，而是给出四种具体故障模式和一套按文档类型来切块、可量化的改进。任何上过线、见过 RAG 系统返回"技术上说得通但就是不对"答案的人，看到这四种故障都会眼熟。

Bhardwaj 点出的四种模式都常见，都费时间去调。逻辑边界被切开是其中最糟糕的一种：一块在"承包商遵循第 4 节所述的标准入职流程"这里断掉，下一块从"除非被安排到被归入附件 B 的项目"开始，两个片段单独看都是错的，而检索器可能永远不会把它们拼回去。固定长度的 token 窗口（512 token + 50 token 重叠那一套，还活跃在太多 stack 里）对着"三段话的例外说明"或者"编号列表的第四步"照切不误，因为它压根不看结构。表格被压平之后，就成了一长串脱离了表头的孤立数值。再加上不看 layout 的 PDF 抽取，上面所有问题会叠加放大，因为底层文本流已经和作者所依赖的视觉结构对不上了。

建议的解法既不性感，也刚好对。按文档类型分流。结构化文档（spec、runbook）用层次化切块 + AutoMergingRetriever。叙事类内容（政策、指南、说明性文字）用 SentenceWindowNodeParser 配 3 句话的上下文窗口。混合或者非结构化内容用语义切块，并且诚实地把"延迟代价"说清楚。PDF 和幻灯片要先用 PyMuPDF 或 pdfplumber 做 layout 感知的预处理，再进 chunking。Bhardwaj 给出的叙事类文档基线升级结果不花哨但真：只是让切块器对上文档形态，context recall 从 0.72 升到 0.88，context precision 从 0.71 升到 0.83。这就是当你不再把 RAG 当作模型问题、而开始把它当作内容工程问题时，会拿到的那种数字。

如果你的 RAG 系统在生产，而且你从来没把 chunking 当作故障来源去做埋点，那就应该从这里开始查。具体动作：抽 50 条最近被答错或答得很薄的查询，手工读一遍被检索回来的那些 chunk，统计有多少根本从切块边界那一步就注定失败，不管你后面用哪个模型做生成。这个数字，几乎永远比团队预想的大。第二步是别再把你整个语料当成同质的；按文档类型分流，因为那个适合 200 页政策 PDF 的切块器，肯定不适合一个以表格为主的 SKU 目录。这一篇和昨天那篇 memweave 是一对：两篇都在从不同角度讲同一个更大的观点。那些看起来最刺激的基础设施决定，比如换更大的向量库、换更新的模型、换更长的上下文，多半不是你家质量问题真正住的地方。那些"怎么把数据切、怎么把数据编上索引"的无聊选择，才是。