AI客服预算应按单次对话拆账

AI 客服机器人的账单，最容易被误判的部分，是大家以为「把网站内容喂给 AI」很贵，真正持续花钱的却是每轮回答携带的上下文。作者运营 ChatNory，踩过优化错方向的坑，给出的建议是：先算清每次对话的成本，再决定怎么报价、怎么优化。

这套拆账方法值得借鉴，但文中的数字主要是运行经验和示例，没有完整的账单对照。其中「解决一次咨询要花多少钱」的计算还存在一处明显矛盾，落地前需要纠正。

建索引很便宜，内容过期才容易吃亏

作者把成本拆成四项：内容索引、问题向量化、模型生成，以及托管、数据库、带宽和人工维护。

前两项都涉及嵌入（embedding），也就是把文字转成便于检索的向量。它不等于重新训练一个模型：网站内容变化时更新索引，用户提问时再把问题转成向量，两者匹配后取出相关资料。

作者估算，一个有 200 个页面、每页平均 800 个单词的企业网站，大约包含 210,000 tokens。嵌入模型每 token 的价格通常比生成模型的输入便宜一到两个数量级，整站首次向量化只需几美分。用户问题通常只有 10–30 tokens，向量化费用更低。

这些都是作者给出的量级判断，不是可以直接套用的报价。原文刻意没有列具体 token 单价，要求读者用供应商当日价格重新计算。

它真正支持的是一个工程决策：别因为担心嵌入费，就让知识库长期不更新。作者建议每晚重新抓取，页面变化后及时重建对应索引。机器人还在引用去年的价格，往往是因为更新机制没做好。

不过，抓取、清洗、识别页面变化也需要资源。「嵌入便宜」不能直接推导成整条更新流水线都没有成本。

每轮发给模型多少内容，比回答多长更关键

RAG，即检索增强生成，会先找到资料，再把资料连同用户问题一起交给模型。作者给出的典型请求约有 4,500 个输入 tokens、200 个输出 tokens，输入量约为输出的二十倍。

原文在介绍请求结构的位置缺少了具体展开，因此无法核对这 4,500 tokens 分别来自哪些部分。但判断方向很清楚：输出单价虽然可能更高，输入量足够大时，输入仍可能占据生成费用的大头。

真实客服对话通常有 3–6 轮，不能把一次模型调用当成一次完整咨询。下面是作者用于估算对话成本的公式：

cost per conversation
  = turns × (input_tokens × input_price + output_tokens × output_price)

要留意 input_price 和 output_price 的单位。如果拿到的是每百万 tokens 报价，需要先换算成每 token 价格；如果各轮输入长度不同，则应逐轮计算后求和。

历史消息是另一个增长源。第一轮发送 4,500 tokens，第二轮再附上上一轮问答，第五轮可能已经达到 8,000 tokens。持续重发全部历史时，在每轮新增内容大致稳定的前提下，累计输入成本会随轮数呈二次增长。

作者用这段代码限制历史长度，同时保留最早的用户消息：

// 1. Cap history by tokens, not by message count, and always keep the
//    first user message — it usually holds the actual intent.
function trimHistory(messages, maxTokens = 1200) {
  const first = messages[0];
  const rest = [];
  let used = estimateTokens(first);
  for (const m of messages.slice(1).reverse()) {
    const t = estimateTokens(m);
    if (used + t > maxTokens) break;
    rest.unshift(m);
    used += t;
  }
  return [first, ...rest];
}

注意 maxTokens = 1200 控制的是历史预算，不是整个请求的预算；estimateTokens 也需要自行实现。代码默认 messages[0] 就是首条用户消息，而且首条消息自身超限时仍会保留，接入现有消息结构前要检查这些前提。

另一个办法是每轮重新检索。第三轮已经开始问物流，就不该继续把第一轮的价格资料堆在提示词里。新问题取新资料，能减少检索片段持续累积，但仍需配合历史裁剪。

真正该动的三处，和容易漏算的固定开支

作者优先推荐三个优化方向。

首先是提示词缓存（Prompt caching）。把系统提示词、少样本示例等稳定内容放在前面，把问题、检索结果等变化内容放在后面，争取复用输入前缀。作者称这是最大的节省机会，但没有给出缓存命中率或前后账单，收益不能直接照搬。

其次是减少检索片段。把 10 个 chunks 减到 5 个，可以让这部分输入量减半。作者建议先用重排序（re-ranking）筛出更相关的资料。不过，减半的是检索片段部分，并非整个请求；重排序自身的开销也应计入。

最后是按任务选模型。判断问候、问题或辱骂，把追问改写成独立查询，判断是否转人工，这些小任务可以尝试更便宜的模型。复杂回答再使用能力更强的模型，避免所有调用都走同一档。

先测量上下文的构成，再决定优化哪一段。

相比之下，作者认为少写几句系统提示词、缩短回答或更换嵌入模型，通常不是大头。这是针对其业务成本结构的经验，不能推广到所有应用。

小规模部署还要看固定费用。托管向量库可能有存储费，以及维持索引服务的月度底价，即使没人聊天也要支付。作者认为，单个企业网站可以先用已有 Postgres 加 pgvector，或者 SQLite 加向量扩展；几十万条向量未必需要独立托管服务。

除此之外，widget、管理后台、webhooks 的托管和出站流量都要算。若接入 WhatsApp，作者提醒 Meta 的消息费用独立于 AI 账单，可能成为最大开支。每月花三十分钟查看未回答问题，也属于维护成本，不能只盯着 token。

我的判断

我认同作者先拆账、再优化的顺序。对于基于企业资料回答问题的客服，检索质量、历史管理和内容更新，往往比反复压缩几句话更值得投入。

但原文没有展示模型、请求分布、缓存条件和完整账单。「缓存节省最多」「五个片段比十个更准确」「便宜模型足够处理小任务」，都需要拿自己的问题集验证。与直接换更便宜的生成模型相比，这些方法可能更容易保住回答质量，却没有对照数据证明它们在所有团队里更划算。

还有一处必须纠正：作者说，如果 40% 的对话最终仍需人工介入，每次成功分流的成本就是表面成本的 2.5 倍。按这个表述，成功分流率应为 60%，成本应除以 0.6，约为 1.67 倍；只有成功率为 40% 时，才对应 2.5 倍。若还要计入转人工后的处理费用，需要另算，原文没有交代。

每次对话成本衡量怎么收费，每次解决成本衡量是否值得运行。

后者还依赖「解决」的定义。没有转人工，不一定代表问题已解决。比较人工工单成本时，需要先统一统计口径，否则便宜的账单也可能掩盖糟糕的服务。

能拿来做什么

• 给现有 Node 客服接口补充逐轮用量记录，区分输入、输出、缓存用量和对话轮数，用一周真实流量核对估算，再向客户报月费。
• 检查请求组装逻辑，为历史设置 token 预算，每轮只携带当前相关资料，并确认首条用户意图不会因裁剪丢失。
• 用同一组客服问题比较缓存、减少片段和任务分流的费用与回答质量，同时把数据库、托管、渠道消息费和人工维护纳入成本表，避免只得到一份便宜的 token 账单。