R

E03 一个 RAG Agent 产品的 unit economics 拆解

创建 2026-06-07 更新 2026-06-11 10 条双链 成本工程 专题 AI 整理

E03 一个 RAG Agent 产品的 unit economics 拆解

本节点解决的问题：一个”RAG + Agent”产品（知识库问答、企业内搜、客服 copilot 这一类）每服务一个用户一个月，到底花多少钱、毛利在哪里、什么时候为负？ 它不是再讲一遍”怎么降本”（那是 m209 - 推理成本控制手册 的事），而是把一个真实形态的产品端到端拆成 per-query → per-user → 毛利 的账单，并指出一个被系统性忽视的判断主轴：Agent 的复合调用结构，让 unit economics 极易在你没察觉时翻成负数。 视角/框架：用 SaaS 的 unit economics 三件套（COGS / 毛利 / 盈亏平衡）去算一个变动成本随用量线性增长的 AI 产品——而这正是 SaaS 直觉失效的地方。

§0 为什么用”per-query 成本树”这个框架，而不是”月度 API 账单”

多数 PM 算 AI 产品成本的默认框架是 m209 - 推理成本控制手册 给的那条月度公式：月度成本 = DAU × 会话数 × 轮次 × tokens/轮 × 单价 × 30。这条公式对单轮对话产品完全正确，但用在 RAG Agent 上会系统性低估，原因是它把”一次用户提问 = 一次推理调用”这个 SaaS 式的隐含假设带了进来。

RAG Agent 的真相是：一次用户提问，背后不是一次调用，而是一棵调用树。 用户问一句”上季度华东区的退款率为什么涨了”，系统内部可能发生：查询改写（1 次小模型调用）→ embedding（1 次向量化）→ 向量检索（1 次 retrieval，命中 8–20 个 chunk）→ 可选的重排（rerank）→ 把检索结果塞进 context 后的生成（1 次大模型调用，input 被检索结果撑大）→ 若 Agent 化还要加：工具调用决策、SQL 生成、结果反思、不满意则重试。月度公式里那个”tokens/轮”，在 RAG Agent 里本身就是一棵树的总和，且这棵树的形状随问题难度方差极大。 所以本节点改用 per-query 成本树做基本核算单元：先把一次提问的所有调用展开成一张可加总的成本表，再向上聚合成 per-user，再接到毛利。只有这样，你才能看见 Agent 那笔”看不见的复合成本”。

§1 per-query 成本树：把一次提问拆到分项

下面建一个可复算的参考模型。所有单价是占位参数，你换成自己的真实定价即可重算；本节点不把任何具体单价当确证事实写死（口径见 §6 与 R01 最小可运行·Token 成本计算器）。

设一次”典型中等难度”提问的成本树（单位：每千 token 单价记为 P_in / P_out，embedding 单价记为 P_emb）：

调用环节触发频率token / 调用成本构成
① 查询改写（小模型）1×in 300 / out 80小模型单价 ×（in+out）
② Embedding 向量化1×用户 query ≈ 60 tokenP_emb × 60
③ 向量检索 retrieval1×—向量库托管/自建摊销（≈ 接近 0，见 §2）
④ 重排 rerank（可选）0–1×候选 20 段rerank API 或本地模型
⑤ 主生成（大模型）1×in 2,500（system 800 + 检索 1,500 + query+史 200）/ out 500P_in×2.5 + P_out×0.5（成本大头）
⑥ Agent 工具调用回合0–N×每回合 in 2,000 / out 300每多一回合 ≈ 再过一次⑤的 input
⑦ 重试 / 反思0–M×同⑤失败一次≈整棵树重算一遍

关键观察一：成本几乎全部压在 ⑤ 主生成的 input 上，而 input 被检索结果（1,500 token）撑到了 query 本身（60 token）的 25 倍。 这是 RAG 的成本签名——你为”把知识喂给模型”付的钱，远多于”用户问题本身”。这条直接对照 A03 Token Economics 精算：检索结果是典型的”高 input、可缓存性差”负载，因为每次 query 命中的 chunk 不同，Prompt Caching 只能缓存固定的 system 部分（800 token），救不了浮动的 1,500 检索 token。

[!example] 一组带真实定价的算例（单价〔截至 2026-06 已核实，volatile 需定期复查〕） 用 Claude Sonnet 当主模型（$3/M input、$15/M output，output 单价是 input 的 5×；Claude 现役 Sonnet 档恒为此价，来源 platform.claude.com pricing〔截至 2026-06 已核实，单价 volatile 需定期复查〕），embedding 用 text-embedding-3-small（$0.02/M；来源 OpenAI 定价页 / 多源一致〔截至 2026-06 已核实〕，Batch API 半价 $0.01/M）。一次基础 RAG query（⑤：in 2,500 + out 500）：input 成本 = 2,500/1e6 × $3 = $0.0075，output 成本 = 500/1e6 × $15 = $0.0075，加 embedding（60/1e6 × $0.02 ≈ 可忽略）≈ $0.015 / query。注意两件事：(1) 虽然 output 单价是 input 的 5×，但 RAG 里 input 量是 output 的 5×（2,500 vs 500），两者各占一半——别只盯着”output 贵”而忽视被检索撑大的 input；(2) 这只是调用树的根，触发 4× 复合项的复杂问 ≈ $0.06 / query。月人均 100 次（§2 混合比）≈ 100 × (0.7×$0.015 + 0.3×$0.06) ≈ $2.85 / 用户·月 API 成本，再加检索基础设施摊销才是 C_u。换自己的模型/定价用 R01 最小可运行·Token 成本计算器 重算。

关键观察二：⑥⑦ 是 Agent 化引入的”复合项”，它们的频率不是常数而是分布。 一个非 Agent 的纯 RAG 问答，⑥⑦ 频率为 0，per-query 就是①②⑤之和；一旦做成 Agent（让它自己决定查几次库、调几个工具、不满意就重试），⑥⑦ 的期望值可能是 2–5，per-query 成本随之膨胀到基础 RAG 的 3–6 倍。这正是 m209 - 推理成本控制手册 §“PM 的成本直觉”表里那行”引入 Agent（10 步任务）→ 单任务成本可能是单次对话的 10–30 倍”的微观机制——本节点把那个区间拆开给你看：它不是一个常数倍率，而是调用树深度的期望 × 每步 input 重复送检索结果两个因子相乘的结果。

[!note] 本节点对 m209 的升级（不复述） m209 的”知识库问答助手”示例（DAU 5,000、月度 ≈ $15,750、优化后 $3,500–4,500、降幅 70–80%，Claude Sonnet/GPT-4o 口径，〔以 m209 原文记载·2024 口径·待按当前定价重核〕）算的是单轮 RAG 的月度总账。本节点不重复那条计算，而是做两件 m209 没做的事：(1) 把”轮次”展开成 per-query 调用树，暴露 Agent 的 ⑥⑦ 复合项；(2) 把成本接到 per-user 毛利与盈亏平衡（m209 停在 API 月账，没接到定价/CAC/LTV）。即 m209 答”这个产品一个月烧多少 API 费”，本节点答”这个产品每个用户赚不赚钱、什么时候赚”。

§2 从 per-query 到 per-user：被低估的两个聚合项

per-user 月成本不是 per-query × 人均月提问数 这么简单，有两个 SaaS 思维下容易漏的项：

(a) 向量库/检索基础设施是”半固定成本”。 retrieval 本身（③）的边际成本接近 0（一次 ANN 查询很便宜），但它背后的向量库托管、文档解析与重建索引、embedding 重算是随知识库规模而非 query 量走的成本。这部分要按”总成本 ÷ 活跃用户数”摊到 per-user。结论是反直觉的：用户越少，per-user 的检索基础设施摊销越高——这与”用户越多越烧 API”的变动成本方向相反，两者叠加形成一个 U 型 per-user 成本曲线（详细分层见 S01 AI 产品成本结构分层剖面）。冷启动期产品 per-user 成本高，不是因为用得多，是因为固定成本没摊薄。

(b) per-user 的”重度尾部”会拖垮平均数。 提问量在用户间是重尾分布（少数 power user 贡献大部分调用），而 Agent 的 ⑥⑦ 复合项让 power user 的 per-query 又恰好最高（复杂问题触发更多工具回合与重试）。两个重尾相乘的结果：算术平均 per-user 成本会被 top 5% 用户严重抬高，而你的定价往往按中位数用户设计。 这是免费额度/订阅制最容易爆雷的地方——见 §3 反例。

参考聚合：设人均月提问 100 次，其中 70% 是简单问（per-query 基础树）、30% 是复杂问（触发 Agent 复合项，成本 4×），则 per-user 月 API 成本 ≈ 100 ×（0.7×c + 0.3×4c）= 190c，即人均成本是”按基础 query 估算”的 1.9 倍——仅仅因为 30% 的复杂问触发了复合调用。把这个 190c 加上 per-user 摊销的检索基础设施成本，才是真实 per-user COGS。

§3 判断主轴：Agent 复合调用让 unit economics 极易为负

这是本节点的命门。90% 的 PM 在算 RAG Agent 账时会在这四个点上搞错，每个都能让一个看起来健康的毛利翻成负数。

错位一：用”一次提问 = 一次调用”估成本，漏掉调用树

  • 症状：PM 在定价会上报”我们每次问答成本约 X 美分”，X 是按单次大模型调用算的；上线后真实成本是 3–6X，毛利由正转负。
  • 为什么会错：SaaS 与单轮 ChatBot 的直觉是”一个用户动作 = 一次后端处理”。RAG Agent 打破了这个一一对应——一次提问展开成 §1 的调用树，且树深随难度浮动。PM 用了一个期望值，但用了树的根而不是树的总和。
  • 正确做法：成本估算的基本单元是 per-query 调用树（§1 那张表），且必须对树深做分布假设（简单/复杂问的混合比），而非取单点。把 ⑥⑦ 的期望频率显式写进模型，做敏感性分析（树深 +1 对毛利的影响）。
  • 真实反例：早期一批”AI 客服 copilot”创业公司在 2023–2024 普遍按”每次回复一次 GPT 调用”报价，实际产品里每次回复要先检索知识库、再生成、不满意自动重写、还调用工单系统 API，真实调用数是报价假设的数倍——这类产品大量在”用得越多亏得越多”中调整定价或关停（业界普遍现象，具体公司财务数据多未公开，〔待核实〕，此处作为模式而非点名个案）。

错位二：把 Agent 的”自主性”当免费，忽视重试是整树重算

  • 症状：产品上了”让 Agent 自己判断要不要重试 / 多查一次库”的能力，体验变好，但月账单无解释地涨了 40%。
  • 为什么会错：重试（⑦）在工程视角是”提升可靠性的好设计”，在成本视角是失败一次 = 整棵调用树重算一遍。Agent 的自主性意味着重试次数由模型自己决定，不在 PM 的预算控制内——这是成本失控从”分钟级”变成”按模型脾气”级。
  • 正确做法：给 Agent 的自主重试设硬上限（max retries）+ 成本预算熔断，把”自主性”约束在预算盒子里；对重试做归因监控（哪类 query 重试率高），这正是 S03 FinOps for AI·成本可观测与归因全景 的核心——没有自动负反馈回路（熔断/降级）的成本告警等于没有。
  • 真实反例：m209 - 推理成本控制手册 提到的语义缓存/对话压缩是降本手段，但若把它们用在一个没有重试上限的 Agent 里，缓存省下的钱会被一次失控的反思循环吐回去——这呼应总览 §6 调度的控制论框架：AI 成本失控是分钟级的，一个反思死循环就能烧光预算。

错位三：用 per-token 单价谈 per-user 盈利，跳过了所有放大系数

  • 症状：PM 看到”token 又降价了”，推断”我们的产品要赚钱了”，但毛利没改善。
  • 为什么会错：per-token 单价到 per-user 成本之间隔着一长串放大系数——检索 input 撑大（×25）、调用树深度（×3–6）、重尾用户（×1.9）、重试。降价只作用在最底层的单价上，上面的结构性放大系数一个没动。 这是 A02 成本对象层级辨析·per-token per-query per-task per-user per-seat 反复警告的口径错配在 Agent 上的极端版本。
  • 正确做法：建立 per-token → per-query → per-user 的完整换算链（即本节点的模型），降价时只更新底层单价、保留所有放大系数重算，看 per-user 真实变化。
  • 真实反例：见总览 §0 的 Jevons 悖论复演——token 降价往往伴随团队”既然便宜了，就多检索几个 chunk、让 Agent 多想几步、上 reasoning 模型”，放大系数不降反升，总账单不降反涨。降价不会让成本问题消失，只会让它换地方爆。

错位四：免费额度按中位数用户定，被重尾用户击穿

  • 症状：定了”免费版每月 50 次提问”，财务模型按中位数用户的 per-query 成本算，结果免费用户群整体亏损，且亏损集中在少数高频复杂提问者。
  • 为什么会错：免费额度的成本是额度 × 真实平均 per-query，而真实平均被重尾用户（§2b）抬高，PM 用中位数估算 = 用了一个比真实低得多的数。免费额度在 SaaS 里是”边际成本≈0 的获客”，在 RAG Agent 里是实打实的变动成本支出。
  • 正确做法：免费额度的成本要用真实平均 per-query（含复合项）× 额度算，并对 power user 单独设更紧的速率限制（A07 成本约束反向塑造产品 的核心：rate limit 不是体验设计，是成本止血）；把免费额度当作 CAC 的一部分计入 unit economics，而非”反正不花钱的拉新”。
  • 真实反例：E01 ChatGPT 与 Claude 的 context rate-limit 产品成本耦合剖解 拆的正是这类厂商为什么把 context 上限和 rate limit 卡得越来越细——那些”限制”是重尾用户成本倒逼出来的产品决策，不是产品经理拍脑袋抠门。

§4 接到毛利与盈亏平衡：一个可复算的最小模型

把上面聚合成毛利。设月订阅价 P、per-user 月 COGS（含 API + 检索摊销）为 C_u、获客成本 CAC、月留存导出的生命周期 L 个月：

单月毛利率 = (P − C_u) / P
LTV ≈ P × L × 毛利率 = (P − C_u) × L
盈亏平衡（含获客）：(P − C_u) × L ≥ CAC
即 用户至少要留存 L ≥ CAC / (P − C_u) 个月才回本

这张表的杀伤力在分母 (P − C_u)： 当 §3 的放大系数让 C_u 逼近甚至超过 P，分母趋零或转负，回本所需留存月数趋于无穷或永不回本。这就是”unit economics 为负”的精确含义——不是”亏一点”，是每多一个付费用户、每多一次使用，都在加深亏损，规模越大死得越快。这与 SaaS”边际成本≈0、规模即利润”的直觉完全相反，是 RAG Agent 产品最危险的认识论陷阱。

[!note] 必须做敏感性分析，不要给单点 C_u、L、CAC、复杂问占比、平均树深，在产品上线前全是估计值（Polanyi 默会知识与提示工程的认识论张力 调度：盈亏平衡点的精确小数位是认识论幻觉）。正确姿势是给区间 + 看哪个变量最敏感——通常平均树深（Agent 复合度）与复杂问占比是毛利的最敏感变量，比 token 单价敏感得多。完整模型见 R03 Unit Economics 模型·CAC COGS LTV 与盈亏平衡。

§5 产品 PM 视角补盲：三个非工程的”看走眼”点

  1. 用户心理 × 成本的恶性耦合：你想用”无限提问、想问就问”做体验卖点，但这恰好最大化了重尾用户的复合成本——体验承诺与成本结构在 RAG Agent 上天然冲突，“无限”是 SaaS 才负担得起的承诺。
  2. 商业模式错配：按 seat（席位）定价 vs 按 usage（用量）定价，在 RAG Agent 上不是偏好问题而是生死问题——seat 定价把重尾用户的成本风险全压给你，usage 定价把它转嫁给用户但伤获客。多数早期产品因为”seat 听起来更 SaaS”而选错（口径见 A02 成本对象层级辨析·per-token per-query per-task per-user per-seat 的 per-seat 行）。
  3. 合规边界的隐藏成本：企业知识库 RAG 往往要求数据不出域、审计留痕、可解释，这逼你用更贵的部署（私有云/端侧，见 A06 端侧与云端成本重构 与 E02 Apple Intelligence 与端侧推理成本剖解），C_u 再上一个台阶——合规不是免费的产品属性，它直接进 COGS。

§6 对手框架回应：接受”先上线再优化成本”，但标出它的边界

业界（尤其精益创业派 a16z 一类）的主流立场是：MVP 阶段过早优化成本会拖死迭代速度，应先验证 PMF 再谈 unit economics。 这条我接受它对的部分——过早上路由/缓存/自建推理确实会让一个还没验证需求的产品死于工程复杂度，早期最贵的是时间不是 token。

但本节点坚持的边界与赌注：可以延后”降本优化”，但不能延后”成本可观测 + 复合项熔断”。原因是 RAG Agent 的成本失控是分钟级、结构性的——一个没有重试上限的 Agent、一次 prompt 注入触发的反思死循环，能在你睡觉时烧光月度预算（总览 §6 控制论框架）。所以正确的边界是：优化可以等 PMF，可观测与熔断不能等。 这与 S03 FinOps for AI·成本可观测与归因全景 的判断一致：先装能看见和能刹车的仪表，再谈省油。

更深一层，我引入一个 Rick 较少调度的对手框架来逼问本节点自己的盲点——Baumol 成本病（服务业生产率难提升导致成本上升）。本节点全篇假设”成本会随技术进步下降”，但 Baumol 提醒：质量敏感的 RAG Agent 场景（医疗、法律、财务问答）不能用便宜模型兜底，这部分成本不随 token 降价而下降，反而因”必须用最强模型 + 必须重试到对”而成为成本刚性区。 这意味着 §3/§4 的”用路由降 C_u”在这些场景失效——本节点的降本乐观有一个被 Baumol 锁死的下界，质量敏感产品的毛利改善空间远小于通用问答。

§7 跨域呼应：把”复合错误数学”翻译成”复合成本数学”

c10 - Agent 技术栈与工具调用 给过一个 PM 应该背下来的判断：Agent 的复合错误数学——若单步成功率 0.95，10 步链式任务的整体成功率只有 0.95^10 ≈ 60%，可靠性随步数指数衰减。这是 0411 Agent 系统化专题（见 _Agent 系统化专题·总览）反复回灌的核心反例。

本节点做的是它的成本同构版：复合成本数学。 同一个”步数 N”的链式结构，在可靠性维度让成功率指数衰减，在成本维度让 per-query 成本随 N 线性—超线性增长（每步过一次 input、失败步触发重试整树重算）。两者是同一个 Agent 结构的两个投影：

[!note] 复合错误 × 复合成本的合谋 最毒的是这两条数学会合谋：可靠性低（复合错误）→ 触发更多重试 → 重试推高成本（复合成本）→ 为了降本换便宜模型 → 单步成功率更低 → 可靠性更低 → 更多重试。这是一个正反馈死亡螺旋。c10 的复合错误数学是”为什么 Agent 不可靠”，本节点是”为什么 Agent 在不可靠的同时还烧钱”，两者必须一起看——单看任一边都会低估 Agent 产品化的真实门槛。这也是 A04 推理成本三角·模型大小 延迟 质量 的三角在 Agent 上被放大的原因：质量（成功率）和成本不是 trade-off，在死亡螺旋里是同向恶化。

这条跨域呼应（其实是跨专题呼应）具体改变了什么判断：它让”per-query 成本”从一个静态分项加总，升级为一个会被可靠性反向驱动的动态量——你不能脱离 Agent 的成功率谈它的成本，提升成功率（更强模型/更多验证）本身就是在花钱买更少的重试。

§8 PM 决策启示

  • 面试桌：被问”怎么看一个 AI 产品赚不赚钱”，不要答 token 单价，直接画 per-query 调用树 → per-user COGS → (P−C_u)×L ≥ CAC，并点出”Agent 复合项 + 重尾用户让 C_u 被系统性低估、unit economics 极易为负”。这一套能讲 5 分钟且带毛利逻辑，立刻区别于只会背”output 比 input 贵”的候选人。
  • 选型/评审会：拿到任何 RAG Agent 方案，逐项质询调用树——每次提问触发几次大模型调用？检索结果多大、能不能缓存？Agent 重试有没有上限和预算熔断？免费额度用真实平均 per-query 算了吗？这四问能拆穿”我们成本很低”的乐观估算。
  • 复现台：用 R01 最小可运行·Token 成本计算器 把本节点 §1 的调用树参数化，再用 R03 Unit Economics 模型·CAC COGS LTV 与盈亏平衡 建 (P−C_u)×L 表，对”平均树深”和”复杂问占比”做敏感性分析——亲手确认毛利对 Agent 复合度的敏感性远高于对 token 单价的敏感性。

§9 与已有节点的关系

  • 对照 m209 - 推理成本控制手册（补缺 + 抽象层升高）：m209 停在”单轮 RAG 的月度 API 账 + 降本手段清单”，本节点补两块 m209 没有的——(1) 把”轮次”展开成 per-query 调用树、暴露 Agent 复合项；(2) 把 API 账接到 per-user 毛利与盈亏平衡。不复述 m209 的具体计算（$15,750 / 70–80% 降幅那条），只引用其”Agent 单任务 10–30 倍”那行作为本节点微观机制的宏观对应。
  • 对话 c10 - Agent 技术栈与工具调用（同构升级）：把 c10 的复合错误数学（可靠性指数衰减）做成成本同构版（复合成本增长），并指出二者合谋成死亡螺旋——这是 c10 没展开的成本维度。
  • 落地总览主轴：本节点是 A07 成本约束反向塑造产品（rate limit/免费额度是成本止血）与 A02 成本对象层级辨析·per-token per-query per-task per-user per-seat（口径错配）在一个真实产品形态上的合流验证，对应总览 §5 求职速通路径的终点案例。

§10 关联节点

核心（必读）

延伸（可选）