第 15 章 RAG 的关键设计取舍¶

RAG 真正有难度的地方，不在于把链路跑通，而在于设计取舍。因为没有任何一种配置能同时把召回率、准确率、延迟、成本和可维护性都做到最好。工程上真正重要的，是清楚知道自己在用什么代价换什么收益。

15.1 召回率与准确率¶

召回更多候选，通常能减少漏掉关键信息的概率，但也会增加噪声。召回过少，系统可能找不到真正相关片段；召回过多，模型又会被无关内容淹没。RAG 的第一个核心取舍，就是在“宁可多带一点”还是“宁可更干净一点”之间找平衡。

chunk 粒度本质上在语义完整性和定位精度之间权衡。大 chunk 保留上下文，但更容易把不相关信息一起带进来；小 chunk 更利于精准定位，但可能破坏必要上下文。系统需要根据文档结构和典型查询模式来选。

top-k 并不是越大越好。k 变大，召回链路、重排链路和上下文注入成本都会上升。尤其在多轮 Agent 场景下，检索本身的延迟会不断累积。因此 top-k 应该服务于任务，而不是凭感觉不断往上加。

如果知识更新很频繁，离线构建索引就可能带来时效问题；但如果每次都走实时检索或实时建索引，延迟和系统复杂度又会上升。很多生产系统最终都会采用混合策略：稳定知识离线索引，强时效知识走结构化查询或热点刷新。

RAG 的设计从来不是“配置调大一点就更好”，而是持续在召回、精度、时效、延迟和成本之间做取舍。理解这些取舍，是后续处理 RAG 失败模式和生产落地问题的前提。