推理成本审计 是做什么的？
大多数生产环境中的LLM调用实际上返回的是标签，而不是文本——例如一个路由、分数、是/否、或类别。这些调用为它们并未使用的自回归生成能力付费。本审计旨在找出这些调用并评估替换成本。
交付物：一个包含实测差异的候选排名表。可作为OneWave的可销售服务内容；与marketing-brain形式相同——每个客户可重复执行的审计流程。
1. 寻找候选调用
搜索LLM调用，然后筛选出那些输出为标签的调用：
grep -rnE "messages\.create|chat\.completions|generateText|\.invoke\(|anthropic\.|openai\." \
--include=*.{ts,tsx,js,py} . | grep -v node_modules
当所有以下条件成立时，该调用即为候选：
- 提示词要求从一个已知的、有限的答案集中选择（≤255个）
- 调用方解析响应——JSON.parse、正则表达式、枚举查找、
.trim() - 下游没有任何地方向人类展示模型的推理过程
- 该调用经常执行，或者用户正在等待它
提示词文本中的强烈信号："respond with only", "return JSON", "classify", "choose one of", "rate from 1 to", "answer yes or no", "do not explain"。
排除条件：输出向用户展示、被用作内容、需要引用或解释、或者答案集是开放式的。
2. 衡量当前成本
不要估算。进行测量：
- 每日调用次数 —— 来自日志或计数器，而不是猜测
- p50和p95延迟 —— p95是用户实际感受到的
- 每次调用的输入/输出令牌数 → 按提供商标价计算的当前每千次调用成本
- 是否有任何操作被阻塞 —— 用户、页面渲染、代理的下一个步骤
3. 评估替换成本
使用来自该调用真实流量的标注数据集进行基准测试（参见jev-eval）。切勿使用供应商基准进行预测。
参考数据（基于真实记录测量，每个记录4个问题）：
| 延迟 | 成本/千次 | 准确度 | |
|---|---|---|---|
| Jev托管 | 399 毫秒 | $0.023 | 在15条记录集上与Claude匹配 |
| Von本地 | 174 毫秒 | $0.00 | 仅在编写良好的标准下匹配 |
| Claude Haiku 4.5 | 2,322 毫秒 | ~$0.55 | 基准线 |
Jev定价：$0.042/百万输入令牌，输出免费。
4. 按回报排序，而非按难度
对每个候选进行排序：
- 调用量 × 单位节省 —— 实际美元金额
- 是否有用户等待 —— 在面向用户的路径上，延迟改进比成本节省更有价值
- 出错的影响范围 —— 路由错误的支持工单代价小；评分错误的交易则不然
- 标注集上的准确度差异 —— 任何低于持平准确度的方案都需要置信度门控，而门控本身也有成本
排除调用量低的候选。每天几百次调用的节省几乎为零，而且你还增加了供应商。
5. 撰写报告
每个候选：文件和行号、决定内容、每日调用次数、当前延迟和成本、预计延迟和成本、实测准确度差异、推荐的门控机制，以及一个通过/不通过及原因。
报告开头应总结预计的月度总节省和最大的单点延迟改进。
始终包含限制：评估集大小、Jev为早期访问且无SLA、必须保留对现有调用的回退机制。
在OneWave栈中的适用场景
- Sage小组件路由 —— 应当构建。访问者在等待；400毫秒 vs 2.3秒是天壤之别。
- RB2B访问者数据流 —— 应当构建。唯一具有数据量的流，24倍成本节省效果显著。
- 线索摄入分类 —— 先测量。虽然正确，但每天只有少量线索。
- 线索看门狗 —— 保留原样。夜间定时任务，无需等待。
相关内容
jev-eval生成此审计所需的准确度数据。jev-integrate是为通过审计的替换项提供集成工作流的工具。