很多人做检索问答，账单出来只看到一个总数，不知道钱是被切文档的嵌入吃掉了，还是被最后那段生成吃掉了，于是优化全靠猜。这篇给一套拆账思路：先分清两段各按什么口径计费，再用日志把用量归到两段上，最后看比例落在什么区间该往哪边动手。不报具体数字，具体单价和倍率请到站内价格页面按当时的表核对。
很多人做检索问答，月底账单出来只看到一个总数，不知道钱是被切文档的嵌入吃掉了，还是被最后那段生成吃掉了。于是所谓优化全靠猜：要么盲目换便宜模型，要么乱砍召回条数，结果该省的地方没省，答案质量先掉了。这篇给一套拆账思路，不报任何具体数字——单价、倍率、套餐换算都请到站内价格页面按当时的表核对。
核心就三步：先分清两段各按什么口径计费，再用日志把用量归到两段上，最后看比例落在什么区间该往哪边动手。下面逐节拆。
先分清哪段按什么计费
| 对比项 | 嵌入段 | 生成段 |
|---|---|---|
| 计费口径 | 按输入 token 计 | 输入输出两头都算 |
| 发生时机 | 建库和更新时 | 每次提问都发生 |
| 支出性质 | 一次性或增量，偏沉没成本 | 随提问量线性增长的经常性支出 |
| 主要变量 | 语料总量、切片粒度、更新频率 | 召回条数、片段长度、输出长度、模型档位 |
最大误区是把两段放在同一个天平上比大小。嵌入是建库时砸下去的一笔，摊到后续成千上万次提问上，单次成本会被摊得很薄；生成是每问一次都要付一次的钱，提问量一涨它就直接涨。所以看到「嵌入这次花了挺多」先别慌，要看它对应的语料能支撑多久的问答量。
- 嵌入段：把语料切块送进嵌入接口，只在建库和更新时发生，通常没有输出侧费用
- 生成段：检索到的片段加问题一起作为输入，再产出答案作为输出，两头计费且每次提问重复发生
- 中间还有一层容易被忽略：重排、多轮改写、查询扩写，这些常被误记进生成段，实际算检索侧
- 先把口径对齐再去 /tools/token-price-calculator 估一遍，不然估出来的比例是错的
把用量归到两段：日志要拆开记
- 建库调用单独立账把切文档、批量嵌入的调用打上 ingest 标签，单独放一个 key 或项目，别和线上问答混在一起。验证方式：月底能一眼拉出建库总消耗。
- 线上问答按次记三类量每次请求记录检索片段拼成的输入 token、用户问题本身的 token、模型输出的 token。验证方式：任取一天的日志能复算出当天的输入输出分布。
- 把检索侧动作单列重排、查询改写、多轮扩写单独记一栏，不并入生成。验证方式：调出一次带重排的请求，能看出各段各自花了多少。
- 核对粒度到 /usage 看一眼系统实际能给的粒度，缺哪项就补埋点，先能分账再谈优化。
日志拆不开，后面全是空谈。最常见的坑是同一条流水线用一个 API key 到底，建库和问答的消耗搅在一起，事后想分就算不出来。另一个坑是只记总 token 不记输入输出拆分，而生成段的两头计费方式并不一样，只看总数根本看不出该砍哪头。
看到比例之后，先判断属于哪种形态
| 形态 | 典型特征 | 该往哪边动手 |
|---|---|---|
| 语料大、提问少 | 嵌入那一下可能反超生成 | 先别为它换模型，它是沉没成本，摊到长期提问里往往不显眼 |
| 语料小、提问多 | 生成段通常占绝对大头 | 着力点在召回条数、片段长度、提示词瘦身和模型档位 |
| 两头都高 | 语料大又高频提问 | 才值得同时动：控制召回条数、砍重复语料、给固定前缀上缓存 |
- 先算清嵌入那笔能不能被后续提问量摊薄，摊不薄才值得回头看切片策略
- 再看生成段的输入里有多少是真正有用的片段，混进来的无关片段就是白付的钱
- 如果你走的是按次计费或订阅套餐，token 口径根本对不上，这套拆账要换成按次或按套餐额度来估
- 比例只是线索，别把它当成硬指标，召回质量不达标时任何省钱动作都要先让路
按段动手：哪些动作动哪一段
- 动嵌入段：去重、合并过碎的切片、增量更新而不是整库重建，省的是重复嵌入的调用量
- 动生成段：限制召回条数与片段长度、过滤无关片段、把高频问题做缓存，直接砍输入 token
- 动输出侧：约束答案长度、让模型别复述问题，输出往往是比输入更贵的部分
- 两边都别乱动的信号：召回质量本来就在及格线附近，为了省钱砍片段数会把准确率一起砍掉
分完账之后，建议按这个顺序排查：先确认召回质量达标，再动生成段的片段长度和条数，最后才回头评估嵌入侧的切片策略。顺序反了，容易先省了钱再花更多钱去补准确率。核算时用 /tools/model-cost-calculator 按任务跑一遍，再和 /usage 的真实记录对一次，估算和实际对不上就说明埋点还缺东西。
下一步拿你自己最近一周的用量日志，按上面的字段拆一遍，看两段各自占多少；再去站内价格页面按当时的表核对单价，把比例换算成钱。→常见问题
我怎么知道自己的钱到底花在嵌入还是生成上？
最直接的办法是建库和线上问答分开记：建库调用单独用一个 key 或加 ingest 标签，线上请求另算。再看每次问答的输入输出 token，算累计值。两段分开统计一个月，比例自然出来。混在一起记的话，只能靠估算，误差会很大。
嵌入模型便宜，是不是可以随便重建库？
单价低不等于总量低，语料大的时候整库重建的调用量很可观，而且重建期间通常还得双份存着。更稳的做法是只对新增或改动过的文档做增量嵌入，定期全量重建当作例外而非常规操作。要不要重建，看你语料更新频率和当时的单价。
生成段太贵，砍召回条数有用吗？
有用，但要看召回质量。每次多召回几条，输入 token 就多一截，而模型可能根本没用到其中大多数。先把片段按相关度排序、只留高分的那几条，再观察答案质量有没有掉。如果本来召回就不准，先解决检索问题，别用砍条数来省钱。
