运行状态

近 30 天的调用量、延迟与成本

OPERATIONS CONCLUSION

当前 p95 样本不足,主要延迟来自外部模型 API

样本不足

外部嵌入、重排、生成与支持度审计占中位请求约 29.0%; 当前最慢 p95 阶段是 关键词召回(13.6s)。优化优先级应放在供应商往返、超时和降级,不是本地 SQL 微调。

¥20.57
产品运行成本 · 近 30 天
¥0.00
评测成本 · 不计入运行
10
问答次数
16.8s
p50 延迟
28.2s
p95 延迟 · 样本不足 / 30.0s
30.8s
p99 延迟

下一步:保持 SiliconFlow 嵌入/重排不变;生成模型记录在 数据库的单行配置里,换模型后新调用会带上新的价目快照, 与旧模型的成本、延迟和质量可以直接比较。

金额是怎么算的

金额是价目估算,不是供应商账单;token 与延迟是实测。V024 之后每次生成都会保存模型、配置版本和当时的输入/缓存/输出单价, 后续改价不会篡改历史。更早的 0 次调用没有价目快照,仍按 fallback (输入 ¥2/M · 缓存 ¥0.5/M · 输出 ¥8/M)回算,并在下表逐行标记。

命中缓存的输入 token 按更低费率计价,且它包含在输入 token 内——两者都按全价算会把缓存记成花钱而不是省钱。

按操作分解

操作调用输入 token其中命中缓存输出 token平均延迟估算成本每次价格口径
报告生成
deepseek-v4-flash
2,0438,636,9582,241,789
26%
705,4503.3s¥7.85¥0.0038调用时快照
¥1/M · ¥0.02/M · ¥2/M
内容结构化
deepseek-v4-flash
4,1527,353,3571,607,168
22%
1,786,0672.6s¥9.35¥0.0022调用时快照
¥1/M · ¥0.02/M · ¥2/M
推荐理由
deepseek-v4-flash
1,7522,886,13589,579
3%
173,3111.4s¥3.15¥0.0018调用时快照
¥1/M · ¥0.02/M · ¥2/M
RAG 问答生成
deepseek-v4-flash
10231,36319,072
8%
6,6644.2s¥0.23¥0.0226调用时快照
¥1/M · ¥0.02/M · ¥2/M

延迟去了哪里

外部 API 往返(嵌入 / 重排 / 生成 / 支持度审计)占 p50 的 29.0%,本地检索、融合、父块展开合计 13.5s。 直接后果:想压延迟只能动网络侧, 优化本地 SQL 一毫秒也省不下来;反过来,任何「多算几路」的本地实验成本可以忽略。
阶段样本p50p95 / SLOp99占单次请求比例位置
关键词召回
sparse
107.2s13.6s / 10.0s
样本不足
14.3s39.1%本地
稠密召回
dense
106.1s8.0s / 10.0s
样本不足
8.5s25.0%本地
生成回答
generate
103.2s6.5s / 15.0s
样本不足
6.8s16.8%外部 API
高风险数值关系审计
numeric_audit
51.1s1.4s / 15.0s
样本不足
1.4s5.9%外部 API
交叉编码器重排
rerank
101.0s1.2s / 10.0s
样本不足
1.2s5.5%外部 API
引用支持度打分
support
10213ms287ms / 10.0s
样本不足
302ms1.2%外部 API
temporal
temporal
4133ms246ms / 10.0s
样本不足
253ms0.6%本地
RRF 融合
fuse
1063ms112ms / 10.0s
样本不足
114ms0.4%本地
父块展开
parent
1047ms81ms / 10.0s
样本不足
85ms0.3%本地
证据选择
select
1034ms75ms / 10.0s
样本不足
91ms0.2%本地
查询规划
plan
100ms0ms / 10.0s
样本不足
0ms0.0%本地
问题嵌入
embed
100ms0ms / 5.0s
样本不足
0ms0.0%外部 API
阶段占比是怎么算的

阶段样本数可以少于问答总数:重排在 reranker 不可用时会被跳过并记为降级,把缺席当成 0 毫秒平均进去,会报出一次从未发生的提速。

比例是先按每次请求算、再取中位数,不是「阶段 p50 ÷ 总 p50」。后者拿两个不同样本群的中位数相除——支持度打分只在有引用的 请求上计时,生成在全部请求上——却把它们当成同一个整体的切片, 结果是几项加起来 122.7%。现在每一格单独成立: 「在中位数的那次请求里,这个阶段占了多少」。

缓存

0%
答案命中率
0%
嵌入命中率
0
精确命中
0
语义命中
3
未命中
2
近邻索引条目
语义缓存的三条约束(ADR-0017)

资讯语料不能无脑上语义缓存(ADR-0017)。三条约束:答案键里含语料指纹,且指纹粒度由 planner 的 `freshness_required` 决定——「最新动态 / 时间线」绑定到精确语料状态, 其余按天;近邻阈值取 0.97 而不是常见的 0.85, 因为「DeepSeek 发布了什么」与「OpenAI 发布了什么」在嵌入空间里很近, 阈值放松的后果是自信地回答另一家公司;拒答永不缓存,因为它的含义是「语料里还没有」。 答案 TTL 60 分钟。

答案命中率 0% 是设计结果,不是缓存坏了:键里含语料指纹, 而采集每 120 秒写一次,所以时间型问题几乎必然未命中——这正是它该有的行为。 对照之下嵌入命中率 0% 是真的在省钱: 嵌入是纯函数,同一段文字永远得到同一个向量,没有新鲜度可言。

线上检索行为

近 30 天 10 次真实提问、411 个候选的聚合。90 题黄金集回答不了这一节——那是事先选定的固定样本, 这里是总体。

15
仅稠密通道找到
2
仅关键词通道找到
7
两个通道都找到
7
被引证据融合名次中位数
7
融合名次在 10 名之后
被引证据中有 7.7% 只有关键词通道找到。这是混合检索在真实流量上的收益率,而不是一道示例题。
重排确实在干活。 被引证据的融合名次中位数是 7,最深到过第 60 名,其中 7 条融合后排在 10 名之外。 如果被引的都已经在前三,交叉编码器就不值它占的那 28% 延迟。
候选去向条数含义
dropped_source_cap245—
evidence_uncited67进入证据集,但答案没用上
dropped_budget47证据位已满(上限 10 条)
cited26进入证据集,且答案引用了它
dropped_document_cap17同一篇文章已超额(单篇霸榜保护)
dropped_story_fold9同一事件已有代表(四家媒体报道同一件事只算一条)

语料规模

14,303
内容条目
86,434
检索分块
100%
已向量化
131
ACTIVE 信源
1,101
已生成引用
125
多信源事件