很多 RAG 项目，在“切文档”这一步就已经失败了
如果你认真复盘过几个 RAG 项目，会发现一个非常残酷、但又极其真实的现象。
很多 RAG 系统：
- 架构看起来没问题
- 模型选型也不差
- embedding、向量库、prompt 都配置齐全
但效果始终“说不上来哪里对”。
而当你真正把检索出来的 chunk 拿出来，自己一条一条读的时候，
你往往会冒出一句话：
“这切的是什么玩意？”
这不是玩笑。
在真实工程里，文档切分，几乎决定了 RAG 的上限。
而且非常反直觉的是：
它往往也是被最随意对待的一步。
一个必须先建立的共识：RAG 检索的最小单位不是“文档”，而是“chunk”
这是理解“为什么切分这么重要”的第一步。
在 RAG 系统里，模型永远不会看到“完整文档”。
它看到的，永远只是你切出来的一小块文本。
也就是说：
- 模型是否能答对
- 不取决于你“有没有这份文档”
- 而取决于：你有没有切出一个“能独立支撑答案”的 chunk
如果 chunk 本身是残缺的、断裂的、缺上下文的，
那后面再强的 embedding、rerank、模型，都只能在“信息碎片”上发挥。
为什么“切小一点方便检索”是一个危险的直觉
这是我见过最多人踩的第一个坑。
很多人切文档时的第一反应是：
“切小一点，检索更精确。”
于是你会看到：
- 固定 300 / 500 token 切
- 不管段落、不管语义
- 表格、列表被直接截断
这种切法，在技术上完全可行，
但在效果上，几乎必然翻车。
因为你忽略了一件事：
检索精确 ≠ 信息完整。
模型不是搜索引擎，它无法在多个 chunk 之间自动“拼上下文”。
RAG 里最常见的失败 chunk：看起来相关，但什么也说明不了
这是你在调试 RAG 时，一定会遇到的一类 chunk。
它们通常有这些特征：
- 包含了关键词
- embedding 相似度不低
- 排名还挺靠前
但你自己读完之后，会发现：
- 没有结论
- 没有条件
- 没有上下文
这种 chunk，对模型几乎没有任何帮助。
模型在这种情况下，要么拒答，要么开始“自由发挥”。
为什么“语义完整性”比“长度控制”重要得多
在 RAG 切分中，有一个优先级经常被搞反。
很多人关注的是：
- chunk 多长
- token 会不会超限
但真正应该优先考虑的是：
这个 chunk 能不能作为一个“完整信息单元”存在。
一个好的 chunk，至少应该满足一件事：
如果你只看到这一段文字，你能不能理解它在说什么。
如果答案是否定的，那这个 chunk 基本就不合格。
语义完整 vs 语义残缺 chunk 对比
表格、列表、步骤说明：RAG 切分的“重灾区”
这是 RAG 项目里翻车率极高的一类内容。
很多知识文档里，真正关键的信息，往往藏在：
- 表格
- 列表
- 步骤说明
但如果你用“纯文本 + 固定长度”的方式切分，结果往往是：
- 表头和内容分离
- 步骤被拆散
- 条件和结论不在一个 chunk 里
最终检索出来的，是一堆结构被破坏的残片。
一个非常重要的认知：chunk 是给“生成模型”用的，不是给“检索模型”用的
这是很多人一直没想清楚的一点。
在 RAG 里，有两个模型：
- embedding 模型
- 生成模型
embedding 模型关心的是“语义相似度”；
但生成模型关心的是：
这段文字能不能直接用来回答问题。
你在切 chunk 时，如果只从 embedding 的角度考虑，
很容易得到一堆“相似但没法用”的结果。
切分的终极评判标准，不是“好不好搜”，
而是：“好不好答”。
为什么切分错误，会让你误以为“embedding 不行”
这是一个非常典型的误判路径。
RAG 效果差 → 检索不准 → embedding 不行 → 换模型
但在很多情况下，embedding 模型本身没有问题，
真正的问题是：
你让 embedding 去比较的是“被切坏的文本”。
你用再好的 embedding，
也很难让它在语义已经破碎的情况下，给你奇迹。
一个真实的工程现象：切分方式一换，模型“突然变聪明了”
这是很多工程师第一次真正意识到“切分重要性”的时刻。
你什么都没换：
- 模型没换
- prompt 没换
- embedding 没换
只是调整了切分方式：
- 按段落切
- 保留标题
- 合并相关说明
然后你发现：
RAG 效果明显提升了。
不是模型变聪明了，
而是你终于把“对的信息”，以“对的形态”给了它。
切分优化前后 RAG 效果对比
一个非常实用的切分自检方法：把 chunk 当“答案草稿”看
这是我个人在做 RAG 时，最常用的一个判断方法。
对每一种切分策略，你可以问自己一个问题：
如果模型只能照抄这个 chunk，它能不能给出一个“勉强可接受的答案”？
如果不能，那这个 chunk 本身就不具备“生成价值”。
这个方法非常原始，但极其有效。
不同内容类型，切分策略本来就不该一样
这是很多 RAG 系统做不好的根本原因之一。
你很难用一种切分策略，同时处理：
- 产品说明
- 操作步骤
- FAQ
- 技术规范
- 故障案例
但很多系统就是这么干的。
更合理的做法是：
- 识别文档类型
- 为不同类型采用不同切分策略
一个简单但有用的代码示例：段落级切分 vs 固定长度切分
下面这段代码不是“最佳实践”，
而是用来直观说明：
切分策略，会直接影响 chunk 的可读性。
def naive_chunk(text, size=500):
return [text[i:i+size] for i in range(0, len(text), size)]
def paragraph_chunk(text):
return [p for p in text.split("\n\n") if len(p.strip()) > 0]
你会发现：
naive_chunk更均匀，但语义经常断裂paragraph_chunk长短不一，但语义完整度更高
在 RAG 场景里，后者往往效果更好。
为什么“切得刚刚好”几乎不存在
这是一个很多人不愿意承认的事实。
文档切分，本身就是一种妥协：
- 切太大 → 检索不精确
- 切太小 → 信息不完整
不存在一个“万能长度”。
真正成熟的系统，往往是：
- 接受这种不完美
- 用 rerank、query rewrite 来弥补
- 而不是幻想“一刀切解决所有问题”
切分错误，会直接污染你的评估结论
这是一个后果非常严重、但经常被忽略的问题。
如果你的 chunk 本身不可用，那你在评估 RAG 时：
- 会误以为模型不行
- 会误以为 prompt 不行
- 会误以为架构不行
最终，你在错误的方向上不断加复杂度。
切分错误 → 评估误导的链式反应
一个现实建议：先把切分当成“核心工程”，而不是预处理
在成熟的 RAG 系统里，文档切分从来不是“顺手做一下”的步骤。
它应该是：
- 可迭代的
- 可回滚的
- 可评估的
否则，你永远不知道：
效果变化到底是模型、检索，还是切分导致的。
在探索阶段，小规模反复试切分，比一开始就做全量索引更重要
这是一个非常务实的工程建议。
在 RAG 初期，与其：
- 一次性切完所有文档
- 建一个巨大索引
不如：
- 选一小部分核心文档
- 多试几种切分方式
- 直接看检索结果和生成效果
在反复验证切分策略是否合理时，使用 LLaMA-Factory online 快速跑通 RAG 流程、对比不同切分方式下的效果，比一次性投入全量工程更容易找准方向。
总结：RAG 的成败，往往在“切文档”那一刻就已经决定了
如果你只记住这一篇里的一句话，那应该是这句：
RAG 的 80% 问题，不是模型、不是向量库，而是你切出来的 chunk 本身。
模型并不会帮你修复被切坏的信息。
它只会在你给它的文本上，尽力发挥。
真正成熟的 RAG 实战，不是“怎么调模型”，
而是怎么把知识切成模型真正能用的形态。
