昨天我们给 Jev 做了一次真刀真枪的实测：拿苹果十年的年报当语料，让它和生产环境在用的召回判定 LLM 正面跑了一遍。先把结论放在这——准确率打平，速度差了 11 倍，单次判定成本约 $0.00018。
这篇文章交代一下我们测了什么、怎么测的，最后给出完整数据。
测的是什么：一份真实的财务语料
测试语料是 Apple 的 10-K 年报，FY2016 到 FY2025 共十年，HTML 原文来自 SEC EDGAR（AnnualReports.com 中途把我们限流了，所以直接用了官方源）。每年抽取两份文档：MD&A（管理层讨论与分析，含流动性章节）和 Business，一共 20 份，每份 8.5k–16k 字符。
选这个语料不是随便挑的。10-K 有几个很适合压测召回判定的特点：文档长、结构相似、年份敏感，而且相邻年份的内容大量重叠——同一套模板、同一批科目，只是数字换了。这正是召回系统最容易翻车的场景：检索回来的文档看着都对，但年份不对。
怎么测的：测试逻辑
我们设计了 25 个按年份锚定的问题，中英文混合，比如「FY2019 年报里，Apple 把某项收入重分类到了哪个科目」这类。每个问题在对应年份的文档里都锚定了一个可以直接验证的 evidence 子串——判对判错不靠感觉，看字符串。
样本一共 79 个 (question, doc) 对：
- 25 个 gold：问题配它真正所属年份的文档；
- 52 个 hard negative：同一个问题，配相邻年份的同类型文档——专门考「看着像但其实不是」；
- 2 个无关文档：非财务内容，凑个热闹。
有一个标注上的细节值得交代：10-K 的 MD&A 表格自带三年对比数据，所以 13 个名义上的「hard negative」其实真的包含所问的事实。这些样本没有一概标成 false，而是按 evidence 字面是否出现标成 expected_relevant=true。不这么修，两边的准确率都会被冤枉。
判定契约两边完全对齐：输出 yes/<0-10> 或 no/<0-10>，阈值 5。Jev 走 TypeSafe 的 /v1/systemone 线上接口（jev-1.13.0）；baseline 是 deepseek/deepseek-v4-flash，走 LLMManager/SimpleByzerLLM，gen.timeout=60s，6 个并发 worker——和生产配置一致。
数据
79 个样本跑完，核心结果如下：
| 指标 | Baseline LLM | Jev |
|---|---|---|
| 已判定 / 错误数 | 77 / 2 | 77 / 2 |
| 对 expected 的准确率 | 92.2% | 92.2% |
| Gold 保留（共 25） | 24 | 25 |
| Negative 拒绝（共 54 个非 gold） | 40 | 37 |
| 平均时延 | 11.3 s | 1.0 s |
| p50 时延 | 3.0 s | 0.9 s |
| 总输入 token | 280,856 | 333,103 |
| 总成本（估算） | — | $0.0140（约 $0.000177/次） |
两边都各错了 2 次，而且都是超时，不是判错：Jev 两次 JevRequestError 读超时，baseline 两次 60 秒 LLMRequestTimeoutError。没有任何一侧出现契约违规——所有返回文本都能按 yes/<n>/no/<n> 解析。
两个判定器的决策一致率 94.7%（75 个双方都判定的样本里只有 4 个分歧），分数 MAE 0.95。4 个分歧全部出现在 hard negative 上：
| id | 期望 | LLM | Jev | 判读 |
|---|---|---|---|---|
| q09-neg2 | T | no/3 | yes/5 | Jev 对——FY2020 文档确实含 FY2019 的重分类说明 |
| q14-neg2 | T | no/2 | yes/6 | Jev 对——FY2021 文档讨论了 COVID-19 的持续影响 |
| q11-neg1 | F | no/3 | yes/7 | LLM 对——Jev 在相邻年份分红文档上误报 |
| q17-neg2 | T | yes/6 | no/2 | LLM 对——FY2018 文档保留了 $250B 计划数字，Jev 漏报 |
Jev 占优 2 例、baseline 占优 2 例，分歧是对称的，不是系统性偏差。
顺手算一笔账：成本
上面表里 baseline 的成本栏是空的，这里补上。DeepSeek 官方定价页上，我们这次用的 deepseek-v4-flash 现在由 V4.1-Flash 承接：cache miss 输入 $0.15/百万 token（off-peak）、$0.30（peak）；输出 $0.6 / $1.2；cache hit 输入几乎免费（$0.003 / $0.006）。
这次评测跑在周日，全天按 off-peak 计：28.1 万输入 token 全按 miss 算是 $0.042；输出侧没有单独记录 token 数，但它是个 reasoning 模型，按每次几百到上千 token 估算再加 $0.01–0.04——合计约 $0.05–0.08，单次判定 $0.0006–0.001。
对比 Jev 的 $0.0140 总价、$0.000177 单次：Jev 便宜 3.5–5.6 倍；如果 baseline 按 peak 价算，差距拉到 8 倍左右。值得注意的一点：Jev 的输入 token 反而更多（33.3 万 vs 28.1 万），总价却更低——它一次前向只出概率分布，没有 reasoning 输出这条计费线。
怎么看这份数据
第一，准确率打平这件事本身就值钱。Jev 不生成文本，一次前向只出 yes/no + 分数 的结构化判定，在这条语料上做到了和生产 LLM 相同的 92.2%，而平均时延只有对方的 1/11，单次成本约 $0.00018——召回判定这种高频调用，成本和时延就是产品体验本身。
第二，弱点和 LLM 是同一个：边界情形的相邻年份、对比数据文档，两边都容易踩，谁也没有系统性优势。这说明瓶颈在任务本身的难度，不在 Jev 的能力上限。
第三，Jev 的 gold 召回是完美的 25/25。baseline 唯一漏掉的 gold 是超时不是误判，但在线上，超时和误判对用户的观感差不多。
数据、样本、语料抽取器和评测脚本都留在仓库里：evaluation_financial_results.json、samples_financial.jsonl（79 条）、evaluate_financial_recall.py，可以复跑。