大模型原理 · 幻觉与三种应对概念

RAG 的成本、优化与替代方案

定义

RAG 会增加摄取、检索和上下文成本，而且并非所有问题都需要检索。优化顺序应是先判断是否需要 RAG，再评测路由、缓存与切块；有天然索引的资料也可直接用工具读取。

说明

不少请求不需要外部知识。先做意图判断，把闲聊、改写和模型已能稳定处理的任务留在普通链路；需要私有、最新或可引用资料时才进入检索。

进入 RAG 后，可按任务路由模型、缓存重复查询，并按标题与语义边界切块。块大小、召回数和重排策略都要用检索与答案评测调节，不能把固定 Token 数当成通用配置。

代码仓库、日志和本机文件有路径、函数名或错误码等天然索引，且变化频繁时，可让 Agent 用 grep、glob、read 等工具按需查找。无结构文档或跨资料语义查询则更适合建立检索索引。

边界与误区

为什么说 RAG 常把成本推到 Prompt 一侧： 检索结果会作为额外上下文进入模型，片段越多，每次请求重复处理的输入越长；实际占比应从调用日志中测量，不能用固定区间替代。
什么业务适合让模型自己翻文件，而不是先做 RAG： 代码仓库、日志和本机文件通常有路径、函数名、错误码等天然索引且更新频繁。模型用 grep、glob、read 可精确匹配，RAG 语义检索反而容易找不到具体编号。无结构的 PDF 和网页更适合先切块建索引。
精准切块为什么不要太大也不要太小： 块太大会带入无关内容，块太小会切断上下文。应从自然段或标题层级起步，再用检索与答案评测调节，而不是把某个 Token 数当作通用标准。