成本最大的操作
RAG 评测（非线上）：¥10.88 / 486 次。 离线 RAG 评测与线上问答分开统计，不再把测试预算算成用户流量。
运行状态
近 30 天 · 真实调用 token 与延迟 · 成本按调用时的模型价目快照估算
OPERATIONS CONCLUSION
当前 p95 达标，主要延迟来自外部模型 API
外部嵌入、重排、生成与支持度审计占中位请求约 99.4%； 当前最慢 p95 阶段是 生成回答（9.5s）。优化优先级应放在供应商往返、超时和降级，不是本地 SQL 微调。
¥32.65
估算总成本
214
问答次数
10.9s
p50 延迟
15.6s
p95 延迟 · 达标 / 30.0s
34.8s
p99 延迟
价格可追溯覆盖
108 次使用调用时模型价目快照；3,352 次旧记录只能使用历史 fallback。旧金额只适合看趋势， 不能当供应商账单。
建议动作
保持 SiliconFlow 嵌入/重排不变；在 模型配置中切换 DeepSeek 生成模型后，用新调用积累可比较的成本、延迟和质量快照。
金额是价目估算，不是供应商账单；token 与延迟是实测。V024 之后每次生成都会保存模型、配置版本和当时的输入/缓存/输出单价，后续改价不会 篡改历史。更早的 3,352 次调用没有价目快照，仍按 fallback （输入 ¥2/M · 缓存 ¥0.5/M · 输出 ¥8/M）回算，并在下表逐行标记。
按操作分解
| 操作 | 调用 | 输入 token | 其中命中缓存 | 输出 token | 平均延迟 | 估算成本 | 每次 | 价格口径 |
|---|---|---|---|---|---|---|---|---|
| RAG 评测（非线上） | 486 | 7,429,604 | 4,013,056 54% | 255,541 | 5.2s | ¥10.88 | ¥0.0224 | 历史 fallback |
| RAG 问答生成 | 469 | 6,724,598 | 3,794,048 56% | 278,822 | 6.2s | ¥9.99 | ¥0.0213 | 历史 fallback |
| 内容结构化 | 1,672 | 2,379,113 | 736,000 31% | 727,956 | 4.0s | ¥9.48 | ¥0.0057 | 历史 fallback |
| 推荐理由 | 725 | 1,001,963 | 232,320 23% | 60,437 | 2.4s | ¥2.14 | ¥0.0029 | 历史 fallback |
| 内容结构化 | 60 | 95,162 | 74,368 78% | 31,924 | 3.9s | ¥0.09 | ¥0.0014 | 调用时快照 |
| 推荐理由 | 32 | 44,601 | 17,408 39% | 2,619 | 1.8s | ¥0.03 | ¥0.0010 | 调用时快照 |
| 报告生成 | 15 | 42,673 | 8,704 20% | 3,903 | 3.9s | ¥0.04 | ¥0.0028 | 调用时快照 |
| RAG 问答生成 | 1 | 14,384 | 14,336 100% | 350 | 2.9s | ¥0.00 | ¥0.0010 | 调用时快照 |
命中缓存的输入 token 按更低费率计价，且它包含在输入 token 内—— 两者都按全价算会把缓存记成花钱而不是省钱。
延迟去了哪里
外部 API 往返（嵌入 / 重排 / 生成 / 支持度审计）占 p50 的 99.4%，本地检索、融合、父块展开合计 88ms。 直接后果：想压延迟只能动网络侧， 优化本地 SQL 一毫秒也省不下来；反过来，任何「多算几路」的本地实验成本可以忽略。
| 阶段 | 样本 | p50 | p95 / SLO | p99 | 占单次请求比例 | 位置 |
|---|---|---|---|---|---|---|
| 生成回答 | 206 | 5.9s | 9.5s / 15.0s 达标 | 28.1s | 54.3% | 外部 API |
| 高风险数值关系审计 | 3 | 3.8s | 4.0s / 15.0s 样本不足 | 4.0s | 26.9% | 外部 API |
| 交叉编码器重排 | 206 | 2.7s | 3.8s / 10.0s 达标 | 5.5s | 25.9% | 外部 API |
| 引用支持度打分 | 91 | 1.7s | 3.6s / 10.0s 达标 | 4.8s | 16.2% | 外部 API |
| 问题嵌入 | 206 | 1.7s | 2.1s / 5.0s 达标 | 2.5s | 14.2% | 外部 API |
| 稠密召回 | 206 | 49ms | 188ms / 10.0s 达标 | 344ms | 0.4% | 本地 |
| 关键词召回 | 206 | 22ms | 97ms / 10.0s 达标 | 139ms | 0.2% | 本地 |
| 父块展开 | 206 | 6ms | 18ms / 10.0s 达标 | 25ms | 0.1% | 本地 |
| RRF 融合 | 206 | 5ms | 11ms / 10.0s 达标 | 14ms | 0.0% | 本地 |
| temporal | 6 | 3ms | 7ms / 10.0s 样本不足 | 8ms | 0.0% | 本地 |
| 证据选择 | 206 | 3ms | 8ms / 10.0s 达标 | 10ms | 0.0% | 本地 |
| 查询规划 | 206 | 0ms | 0ms / 10.0s 达标 | 0ms | 0.0% | 本地 |
阶段样本数可以少于问答总数：重排在 reranker 不可用时会被跳过并记为降级， 把缺席当成 0 毫秒平均进去，会报出一次从未发生的提速。
比例是先按每次请求算、再取中位数，不是「阶段 p50 ÷ 总 p50」。 后者拿两个不同样本群的中位数相除——支持度打分只在有引用的 36 次请求上计时， 生成在全部 151 次上——却把它们当成同一个整体的切片， 结果是几项加起来 122.7%。现在每一格单独成立： 「在中位数的那次请求里，这个阶段占了多少」。
缓存
0%
答案命中率
0%
嵌入命中率
0
精确命中
0
语义命中
1
未命中
1
近邻索引条目
资讯语料不能无脑上语义缓存（ADR-0017）。三条约束：答案键里含语料指纹，且指纹粒度由 planner 的 `freshness_required` 决定——「最新动态 / 时间线」绑定到精确语料状态， 其余按天；近邻阈值取 0.97 而不是常见的 0.85， 因为「DeepSeek 发布了什么」与「OpenAI 发布了什么」在嵌入空间里很近， 阈值放松的后果是自信地回答另一家公司；拒答永不缓存，因为它的含义是「语料里还没有」。 答案 TTL 60 分钟。
答案命中率 0% 是设计结果，不是缓存坏了：键里含语料指纹， 而采集每 120 秒写一次，所以时间型问题几乎必然未命中——这正是它该有的行为。 对照之下嵌入命中率 0% 是真的在省钱： 嵌入是纯函数，同一段文字永远得到同一个向量，没有新鲜度可言。
线上检索行为
近 30 天 92 次真实提问、3744 个候选的聚合。90 题黄金集回答不了这一节——那是事先选定的固定样本， 这里是总体。
235
仅稠密通道找到
3
仅关键词通道找到
112
两个通道都找到
8
被引证据融合名次中位数
155
融合名次在 10 名之后
被引证据中有 0.9% 只有关键词通道找到。这是混合检索在真实流量上的收益率，而不是一道示例题。
重排确实在干活。 被引证据的融合名次中位数是 8，最深到过第 52 名，其中 155 条融合后排在 10 名之外。 如果被引的都已经在前三，交叉编码器就不值它占的那 28% 延迟。
| 候选去向 | 条数 | 含义 |
|---|---|---|
dropped_budget | 1067 | 证据位已满（上限 10 条） |
dropped_document_cap | 803 | 同一篇文章已超额（单篇霸榜保护） |
evidence_uncited | 548 | 进入证据集，但答案没用上 |
dropped_source_cap | 509 | — |
cited | 350 | 进入证据集，且答案引用了它 |
ranked_out | 264 | 重排后排名不够靠前 |
dropped_story_fold | 203 | 同一事件已有代表（四家媒体报道同一件事只算一条） |
语料规模
1,931
内容条目
7,271
检索分块
100%
已向量化
105
ACTIVE 信源
913
已生成引用
33
多信源事件