一百万token降到一杯咖啡钱之后，我重新算了一遍RAG的账
长上下文降价的效率冲击
过去一年，长上下文模型的价格曲线几乎是一条下坠的直线。以主流模型为参照：2023年前后，处理100万token输入的成本普遍在数美元量级；如今同等规模的输入，成本已经压缩到原来的十分之一甚至更低，部分模型厂商在价格战中把百万token输入压到了几十美分区间。缓存命中后的价格更是进一步下探，有的方案对缓存前缀只收原价的十分之一。
这个变化直接冲击了一个根深蒂固的架构判断：很多团队当初上RAG,不全是为了检索精度，而是为了省钱。把50万字的文档库切成chunk、建向量索引、只召回几千token塞进prompt——这套流水线本质上是一次“用工程复杂度换token预算”的交易。
现在交易条件变了，很多团队开始动摇：要不要干脆放弃RAG,把整个知识库直接塞进200K甚至1M的上下文窗口？
一笔具体的账：重构前后的时间与成本
以一个典型的企业知识问答场景为例：文档库约80万token，日均问答3000次，平均每次问答检索后注入约4000token的上下文。
传统RAG方案的隐性成本：
- 初始化工程：切片策略调优、embedding选型、向量库搭建、召回评估，一个熟练工程师通常需要2-4周
- 每次请求：召回约4000token,输入成本相对可控
- 持续维护：文档更新后的重新索引、召回badcase排查，每月约需数人日的运维投入
长上下文直塞方案：
- 初始化工程：几乎为零，几天内可上线
- 每次请求(降价前)：80万token输入，成本是RAG的百倍以上，完全不可行
- 每次请求(降价后)：即便按降价后的价格，无缓存场景下单次成本仍在RAG方案的30-80倍
看起来RAG仍然赢？但加入两个变量后结论开始摇摆：
变量一：Prompt缓存。 问答场景中，文档库前缀是高度稳定的。命中缓存后，那80万token的增量成本可能降至原价的10%以下，与RAG方案的每次召回成本差距缩小到个位数倍。对于日请求量在几百次量级的内部工具，这个差价可能每月只有几十美元——比排查一次召回badcase的工程师工时还便宜。
变量二：工程时间的机会成本。 一个中级工程师一天的人力成本，在多数公司折算后超过大多数应用一整年的模型调用费。如果RAG调优要吃掉他两周时间，而长上下文方案当天就能交付一个80分的结果，这笔账在中小流量场景下并不站在RAG这边。
分界线在哪里
综合成本曲线，可以画出一个粗略的决策边界：
- 文档库<50万token + 日请求<5000次 + 前缀稳定：长上下文+缓存直塞，总拥有成本大概率更低，且省掉2-4周工程时间。首版MVP强烈建议这条路。
- 文档库>200万token 或日请求>5万次：token成本重新压倒工程成本，RAG的召回裁剪仍然是省钱主力，但架构应简化——不必追求复杂的多路召回和重排，简单的混合检索往往就够了。
- 中间地带：混合方案正在成为主流。用粗粒度检索把80万token裁剪到10万token,再塞进长上下文让模型自己做精读。实测中这种方案在多跳问题上比纯RAG准确率提升明显，比纯长上下文便宜一个数量级。
另一个常被忽略的效率因素：长上下文的推理延迟随token数增长。80万token的prefill时间可能让首响时间从1-2秒劣化到10秒以上。对延迟敏感的对话场景，这比钱的问题更致命——省下的token费，可能赔在用户流失上。
对开发者的实际影响
接入层面：主流API的上下文窗口参数已经与价格解耦，开发者要做的是显式利用缓存——把稳定内容(系统提示、文档库)放在prompt前部，动态内容放尾部，否则缓存形同虚设。
成本层面：监控重点应从“每次调用token数”转向“缓存命中率×有效token单价”的组合指标。同一个模型，缓存命中的40万token和未命中的40万token，账单可以差出一个数量级。
模型选择层面：不要只看单价表上的输入价格，要看三行数字——常规输入价、缓存命中价、以及超长上下文档位(很多厂商对超过一定阈值的token收取加价档)。跨模型比价时用你自己的真实prompt长度算，不要用厂商宣传页的标准案例。
给开发者的应对建议
- 新项目先跑长上下文基准：上线前用真实文档直塞跑一遍，记录准确率、延迟、单次成本，作为所有后续优化的对照组。这个基准一两天就能建好。
- 把RAG重新定位为“优化手段”而非“默认架构”：只有当基准的延迟或成本被证明不可接受时，才引入检索裁剪。
- 缓存前缀结构从第一天就设计好：稳定的放前、多变的放后，这个习惯的价值可能超过任何检索算法调优。
- 建立每千次问答的成本看板：拆分模型费、缓存节省、工程维护工时三项，按月复盘——很多团队会发现人力成本才是大头。
- 多模型留退路：文档理解、精读、生成可以分配给不同价位的模型，通过统一网关管理比在代码里硬编码切换灵活得多。
长上下文降价没有杀死RAG,它杀死的是“不问流量规模就默认上RAG”的条件反射。架构决策回归到它本该的样子：一笔算得清的账。
如果你正在重新评估自己的接入架构，或者想用一个入口统一管理多模型调用与成本看板，可以看看 Thistoken 的聚合网关：https://api.thistoken.ai/register
---
想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。