RAG 检索链路的三个隐性成本：分块、重排与上下文膨胀

RAG 的效果差距很少来自向量库选型，多半来自检索链路上三处没人记账的成本：分块、重排、上下文膨胀。它们不出现在架构图里，却同时决定 P95 延迟、token 账单和答案的可靠性。

分块：切得越碎，召回越多，噪声也越多

固定长度切分（512 字符或 512 tokens）是最常见的默认值，也最容易埋雷。中文被硬切后，单块 embedding 只覆盖局部语义，query 与块的相似度被稀释；为了把正确答案捞回来，只能把 top_k 从 5 加到 20，噪声跟着一起进来。

具体做法：

• 结构优先：Markdown 标题、代码块、表格作为硬边界，不允许跨边界切分。
• 块大小 300–500 中文字（约 256–512 tokens），overlap 10%–15%。overlap 超过 20% 只增加索引体积和重复召回，对召回率没有正收益。
• small-to-big：用 200 字左右的小块建索引做检索，命中后回溯 800–1200 字的父块送进上下文，检索精度和上下文完整性可以同时拿到。

一个判断标准：改完分块后 hit rate@5 提升不到 3 个百分点，说明瓶颈不在分块，别继续调 overlap。

重排：收益和延迟都随 top_k 线性增长

cross-encoder 要对每个 query-doc 对跑完整前向，耗时与 top_k 成正比。top_k=100、每块 500 tokens 时，单次查询的重排开销常常是向量检索的十倍以上，QPS 上到几十就变成主要延迟来源。

先量化再上线：对比重排前后的 hit rate@5 和 MRR。提升低于 5 个百分点时，把预算放回分块和 embedding 模型，回报通常更高。

上下文膨胀：token 成本只是账单上看得见的部分

把 32k 窗口塞满不会让答案更准。位于中间位置的文档容易被忽略，TTFT 却随输入长度线性上升——用户感知到的是“变慢了”，不是“变准了”。

• 设总预算：进 prompt 的检索内容控制在 2k–4k tokens，超出部分按相关性截断，而不是按召回顺序拼接。
• 去重合并：同一文档的多个块合并成一个片段，避免同一段话被重复计费。
• 相关性阈值：分数低于阈值直接丢弃，宁可少给两条，也不给模型凑数的素材。

落地建议

1. 建一条 100–200 条真实 query 的离线评估集，标注答案片段，每次改分块、重排或上下文预算都跑一遍 hit rate@5 与 MRR，用数字决定是否上线。
2. 以 chunk=400 中文字 / overlap=12% / top_k=50 / top_n=6 / 上下文 3k tokens 为起点，一次只动一个变量做单向调参。
3. 在召回、重排、prompt 组装三段打耗时埋点；P95 超 800ms 时优先降 top_k 或跳过重排，而不是急着换更快的模型。
4. 线上记录每次回答实际用到的 chunk id，统计零命中率和重复命中率——这两个指标比分块参数更早暴露链路问题。