详细内容或原文请订阅后点击阅览
RAG 正在烧钱 - 我构建了一个成本控制层来解决它
大多数 RAG 系统都是针对答案质量而不是成本进行优化的，而盲点的成本很快就会变得昂贵。在本文中，我分解了一个结合了语义缓存、查询路由、令牌预算和熔断的生产就绪成本控制层，在不牺牲答案质量的情况下实现了 LLM 成本降低 85%。 帖子《RAG 正在烧钱 — 我构建了一个成本控制层来修复它》首先出现在《走向数据科学》上。
来源:走向数据科学TL;DR
纯 Python 中的完整工作实现，以及本地设置的基准测试结果。
RAG 系统不仅仅在质量上失败。它们在成本方面也可能变得低效，而且通常以不立即可见的方式。
每个额外检索到的令牌都有成本。在我的系统中，上下文过度获取超出查询实际需要的范围 3 到 8 倍。
在许多基线实现中，重复的查询是独立处理的，不会重用以前的结果。
在单模型设置中，大部分简单查询可能由高成本模型处理，即使低成本替代方案就足够了。
通过语义缓存（在预先播种、预热的缓存基准中命中率高达 98.5%）、查询路由（基准组合中大约 81% 的请求转移到成本较低的模型）以及带有断路器的令牌预算层，系统在每天处理 10,000 个请求时实现了高达 85.8% 的成本降低，同时在评估的设置下保持了响应质量。
这些结果基于在下述基准配置下运行的本地基准测试。
运行良好的系统 - 却悄悄地耗尽了资金
我构建了一个运行完美的 RAG 系统，我通过相同的管道运行相同的查询，每次都得到相同的输出。在测试中，看起来没有任何问题，延迟稳定并且答案正确。
然后我查看了令牌日志。
在我的设置中，即使是简单的问题，例如“什么是 RAG？”或“定义语义搜索”。我们正在选择最昂贵的型号。每个重复的查询都会全额计费，即使我十分钟前回答了完全相同的问题。当两个请求正在执行实际工作时，每个请求都会检索十个块。
系统没有损坏。这只是经济上的盲目。从规模来看，这种区别就不再重要了。
这是我在顶部构建的成本控制层 - 包含可以运行的真实数字和代码。
为什么 RAG 在设计上就处于财务盲目状态
共有三种特定的故障模式。