大多数 RAG 系统不是“效果不好”，而是“慢慢坏掉的”
如果你做过一段时间 RAG，你大概率会经历这样一个过程：
- 一开始效果不错
- 后来偶尔答歪
- 再后来开始靠感觉调参数
- 最后系统“还能用，但谁也不敢保证稳定”
而在这些系统里，几乎一定会出现同一组操作：
- 切分感觉不太对 → 切小一点
- 命中不稳定 → TopK 调大一点
- 再不稳 → 再切碎一点 + 再加 TopK
表面上看，这是在“补救”；
实际上，你正在同时拧动两个最危险的旋钮。
切分和 TopK，从来就不是两个可以独立优化的参数。
它们是一对会互相放大副作用的组合。
切分大小 × TopK 的风险矩阵图
一个必须先统一的认知：TopK 不是“兜底参数”
在很多团队里，TopK 被当成一种心理安慰：
“TopK 大一点，总能把对的东西捞出来吧。”
这是一个极其危险的直觉。
TopK 的本质不是“兜底”，而是：
你允许多少个候选证据，参与模型决策。
当你把 TopK 调大，你不是在提高“命中概率”，
你是在扩大模型的决策空间。
如果这些候选里，大多数是：
- 不完整的
- 泛化的
- 缺条件的
那你不是在帮模型，而是在逼它“猜”。
切分一旦变小，TopK 的含义就已经变了
这是很多人没有意识到的第一个关键点。
在切分较大的情况下：
- 一个 chunk 往往包含完整语义
- TopK=3，意味着 3 份“相对完整的证据”
但当你把 chunk 切得很小：
- 每个 chunk 只包含局部信息
- 同一个知识点被拆成多块
此时 TopK=3 的真实含义变成了：
3 个“语义碎片”，而不是 3 个答案候选。
如果你这时再调大 TopK，比如 Top10、Top20，
那模型面对的就不是“更多可能答案”，而是：
一堆彼此相关、但又都不完整的信息碎片。
一个非常真实的翻车场景：你以为是“召回不够”，其实是“证据被拆散了”
很多团队第一次明显翻车，都会遇到下面这种情况：
- 检索结果里“看起来有相关内容”
- 但模型回答时，总是缺关键条件
- 或者结论反了
于是工程师会很自然地想：
“是不是 TopK 太小了？”
然后把 TopK 从 3 调到 5，再到 10。
短期内，确实可能“看起来好了一点”，
但一段时间后，你会发现：
- 模型开始自相矛盾
- 回答越来越长
- 有时把例外当主规则
这是因为：
你解决的不是“召回不足”，而是“切分破坏了知识结构”。
TopK 放大了这个问题。
切分负责“知识是否完整”，TopK 决定“噪声是否进入决策层”
这是理解这对参数关系的核心。
你可以把它们的职责分成两句话：
- 切分：决定“单个 chunk 是否能作为独立证据”
- TopK：决定“有多少证据可以一起影响模型”
如果切分本身就不合格：
- chunk 不可独立理解
- 条件 / 结论被拆开
那 TopK 越大，
模型接触到的不合格证据就越多。
一个经常被忽略的事实：TopK 扩大的不是“信息量”，而是“冲突概率”
很多人调 TopK 时，脑子里想的是：
“信息不够 → 多给点。”
但模型接收到的并不是“线性增加的信息”，
而是指数级增加的冲突可能性。
举个非常真实的例子：
- chunk A：规则说明
- chunk B：例外情况
- chunk C：旧版本说明
在 Top3 的情况下，可能只命中 A；
在 Top10 的情况下，A、B、C 全进来了。
模型接下来要做的，不是“理解更多”，
而是在冲突中做取舍。
而这种取舍，往往不可控。
切分 + TopK 一起调坏系统的典型路径
几乎所有“慢性死亡”的 RAG 系统，都走过类似路径：
- 初始：chunk 较大，TopK 较小，效果尚可
- 中期：发现漏召回 → 切分变小
- 再中期：碎片化严重 → TopK 变大
- 后期：噪声爆炸 → 加 rerank / prompt
- 最终：系统复杂但不稳定
在这个过程中，没有哪一步是“明显错误”的，
但组合在一起，就是灾难。
RAG 参数恶化路径示意图
一个工程视角的判断标准：TopK 不该“补切分的锅”
这是我在项目里反复强调的一条原则：
如果你需要靠增大 TopK，来弥补切分带来的信息缺失，那切分一定有问题。
TopK 的合理用途只有一个：
- 在“合格 chunk”之间做选择
而不是：
- 在“不合格 chunk”里碰碰运气
一个很实用但很残酷的自检方法
你可以现在就用下面这个方法，判断你是否已经“切分 + TopK 一起调坏了”。
步骤非常简单：
- 固定一个真实问题
- 拉出 TopK 的所有 chunk
- 把它们按顺序贴出来
- 问自己一个问题：
如果我只能基于这些 chunk 回答，我会不会犹豫？
如果你的答案是“会”，
那模型也一定会，而且更糟。
为什么 rerank 也救不了“切分 + TopK”的根本问题
很多团队在这个阶段，会把希望寄托在 rerank 上。
但这里有一个必须说清楚的事实：
rerank 只能排序，不能让碎片变完整。
如果你的 chunk：
- 本身缺条件
- 本身语义不闭合
rerank 再强，也只能在“坏证据”里挑“相对不那么坏的”。
一个更健康的调参顺序（非常重要）
如果你非要调参数，我强烈建议你遵循下面这个顺序：
- 先固定 TopK（比如 3 或 5）
- 专注把 chunk 调到“可独立使用”
- 确保 TopK 里的 chunk，大多数是“可用证据”
- 再考虑是否需要增大 TopK
而不是反过来。
一个简化但很真实的示意代码
results = vector_db.search(query, top_k=5)
usable = []
for r in results:
if is_self_contained(r.text):
usable.append(r)
# 如果 usable 很少
# 问题不在 TopK
# 而在切分
你会发现，一旦你开始用“证据可用性”而不是“召回率”看问题，
很多调 TopK 的冲动会自然消失。
在调试切分与 TopK 组合时，最大的难点往往不是“怎么切、TopK 设多少”，而是很难系统性地对比不同组合在同一问题集上的真实效果。用LLaMA-Factory online先快速搭建多套切分策略 × TopK 的对照实验，直接看检索结果是否“可用”，比在一条路径上反复加参数，更容易发现你是不是已经把这对参数一起调坏了。
总结：切分决定你给模型什么，TopK 决定模型能被多少“坏信息”影响
如果要用一句话总结这篇文章，那我会写得非常直白：
RAG 里最危险的不是切分不好，也不是 TopK 不合适，
而是你用 TopK，掩盖了切分本身的问题。
切分，是知识工程；
TopK，是风险放大器。
当你开始意识到这一点，
你就已经从“调参数的人”，
走向了“为系统稳定性负责的人”。
