最近 GitHub 上出现了几个用 Jev 做量化回测的项目，结果基本都是负的。

BTC/USD 五道验证门回测，holdout AUC 0.471–0.503 ，等同随机猜测。NQ 订单簿模拟，339 次决策命中率 67.8%，扣手续费后净亏 -62.69 。

我翻完这些回测，觉得问题不在 Jev 本身，在于很多人把它放在了交易系统里错误的位置。

这篇文章拆三件事：Jev 底层到底在算什么、为什么校准概率对量化是双刃剑、以及一个大多数人接进系统后才意识到的问题——你的行情数据，时间戳对得上吗？

一、Jev 是什么：三种问法，没有"写作文"这一步

先看它的 API 。只有三种问法：

问法 |
怎么用 |
返回什么 |
量化场景 |

选择题 |
从预定义选项里选一个 |
选项、概率、置信度 |
新闻利好利空、标的排序 |

打分题 |
按评分标准打分 |
分数、概率、置信度 |
财报语气、风险等级 |

判断题 |
判断一句话是真是假 |
0 到 1 之间的概率 |
是/否过滤、条件触发 |

没有格式需要修复，没有文字需要解析，没有 token 需要逐个生成。

答案空间本身就是模型输出的一部分。 选项不是提示词里的一段文字，是模型计算图里的一个维度。

你让大模型判断一条新闻对某标的是利好还是利空，它的做法是：读提示词，逐字生成 {"sentiment": "positive"}，再解析这段文字，取出 positive。

三选一的判断，它写了十几个字，每个字都要走一遍完整的生成过程。

Jev 把这一步砍掉了。

二、底层机制：一次算完，不再逐字生成

传统大模型慢在哪？很多人以为是计算量大。不准确。

真正的瓶颈在数据搬运。

大模型逐字生成答案的过程：先处理你的问题，建一个缓存。然后生成第 1 个字，把缓存搬来搬去，算一次，输出。再生成第 2 个字，把缓存搬来搬去，算一次，输出。循环几十次。

每次循环的瓶颈不在算得快不快，在数据搬来搬去太慢。

Jev 的机制是：一次算完，共享缓存，直接出结果。

根据 archerhume.com 的逆向分析和 APUS 的开源复现报告：

- 所有问题共享同一份缓存，数据只处理一次

- 每个问题只额外加载自己的指令和选项

- 多个问题同时计算，直接输出概率

- 输出通过一个数值读取头完成，再做概率归一化

还有一个细节值得注意：Jev 的选项之间不是独立打分的。 新增一个无关选项，会影响其他选项的概率。这说明它在处理阶段就对完整选项集做了整体计算，而不是逐个打分再归一化。

这个行为模式更像一个分类器——把数据映射到预定义的决策空间上，每个决策的概率是联合计算出来的。

它的速度优势不是"模型调优了所以快"，是"计算路径本身短了一个数量级"。

三、校准训练：让"说 70%"真的等于"70% 正确"

速度的故事讲完了，现在讲一个更重要的。

TypeSafe 把 Jev 的训练方法叫 RLCD——面向校准决策的强化学习。

和传统训练方法的区别在哪？

对比维度 |
传统训练（ RLHF ） |
校准训练（ RLCD ） |

优化目标 |
人类觉得回答好不好 |
说 70% 时现实中约 70% 是对的 |

信号来源 |
人类偏好比较 |
校准误差 |

模型学到 |
怎么让人类满意 |
怎么让概率说实话 |

量化适用性 |
低——置信度是语言现象 |
高——置信度是统计声明 |

为什么这对量化是致命的区别？

因为大模型的置信度本质上不是一个有数学依据的数字。它来源于文字预测概率分布，而不是对"这个判断本身正确率"的估计。一个模型在完全不确定的情况下，照样可以输出 置信度: 0.95——它只是在预测"下一段文字看起来像不像一个高置信度的回答"。

校准训练试图把"置信度"从一个语言现象变成一个统计声明。

独立测试的数据支持这个方向：

测试来源 |
测试内容 |
置信度偏差 |
准确率 |

webofmike |
60 个工具调用风险案例 |
0.0712 （最新版）/ 0.0505 （预览版） |
91.7%（ 55/60 ） |

archerhume.com |
MMLU 1,200 道题 |
0.0313 |
MMLU-Pro 84.6% |

置信度偏差衡量的是"模型说 70% 的时候，实际情况偏离 70% 有多远"。0.05 到 0.07 的偏差意味着校准误差大约在 5 到 7 个百分点。

但这里必须说清楚一个边界：校准训练的具体方法没有公开。 方向是对的，独立测试的校准指标表现良好，但底层实现方式目前不可验证。如果你要用 Jev 的概率做仓位管理，这件事得自己保持警惕。

四、亏钱的人做错了什么：回测数据不会说谎

Jev 发布之后，一批人立刻把它接进交易系统，然后亏钱了。

4.1 比特币回测：五道验证门，结论是随机

GitHub 项目 egrm07/jev_bitcoin_backtest，方法论设了五道验证门：```
五道验证门：
1. 随机置换检验
2. 多重比较校正
3. 留出验证（样本外测试）
4. 夏普比率置信区间
5. 买入持有对比
```数据：币安 BTCUSDT 5 分钟 K 线。开发窗口 2026/3/1–7/15 ，留出验证窗口 2026/7/15–9/19 （约 65 天）。

测试了 10 种数据表示方式——原始 K 线、收益率、技术指标、文字叙述、字符图表等。

指标 |
结果 |

留出验证区分度 |
0.471–0.503 （ 0.5 为随机基准） |

预测准确度指标 |
全部为负 |

最好策略收益 |
-15.73%（原始 K 线 + 线性策略） |

同期买入持有比特币 |
+25.55% |

模型 API 总成本 |
$2.5848 |

结论 |
无可交易的统计显著性优势 |

4.2 订单簿模拟：高命中率仍然亏钱

GitHub 项目 Waxmell114514/jev-trade，合成订单簿数据加真实 Kraken 数据回放。

指标 |
数值 |

决策次数 |
339 |

命中率 |
67.8% |

毛盈亏 |
+28.90 |

扣除手续费 |
-91.60 |

净亏损 |
-62.69 （-0.825% 风险资本） |

盈亏平衡所需手续费 |
低于 0.316 个基点 |

关键发现：盈亏平衡需要手续费低于 0.316 个基点。 这个数字超过了大多数真实交易环境能提供的费率。

高命中率不等于盈利。交易成本是致命的。

4.3 核心判断

Jev 输出的是一个概率，不是一个策略。

强制每次决策都必须出手，本质上是在用一个校准概率做随机交易。

Zerve.ai 在量化研究报告中写过一句话：

大模型不产生超额收益。它们不会提出能产生真正信号的新研究方向。

arXiv 上还有一篇 2026 年 8 月的论文，核心发现更直接：大模型特征经过统计校正后，预测贡献归零——原话是"校准后所有大模型权重归零"。一个近乎零成本的替代方案（标题计数）效果反而更好。论文因此提出"校准可行性检查点"：在正式推理之前，先验证大模型特征是否真的有预测力。

Jev 不是交易 AI 。它是一个被确定性代码包裹的判断原语。

五、行情数据才是真正的瓶颈

那 Jev 应该放在哪？

我的判断：Jev 应该坐在信息处理层，而不是决策执行层。

层级 |
适合做的事 |
不适合做的事 |

信息处理层 |
新闻方向判断、财报语气打分、候选标的排序 |
— |

决策执行层 |
— |
每个 tick 输出方向判断直接下单 |

但这里有一个更隐蔽的问题。

Jev 接收的是一段文字，而量化系统里的核心数据是结构化的——价格、成交量、盘口、资金流。

Jev 本身不接行情接口。 它不知道集合竞价期间开盘价字段是缺失的，不知道美股延长时段的日线口径和盘中不一样，不知道港股午休期间数据会有一段空洞。

如果你的 Jev 判断流程在盘中运行，每次决策的输入数据来自不同时刻的行情快照，它的概率输出就会失去可归因性。它说 72% 是基于哪个时间点的数据得出的？那个数据里的"当前价格"是几点几分几秒的？

5.1 一个字段存在性决定代码对错

后来在做多市场研究时，我遇到了一个具体问题：美股盘前盘后的数据，和正常交易时段的数据，字段结构不一样。如果用本地时间判断"现在是不是盘中"，遇到节假日调休或者半日市，就会判断错。```
import requests

取美股交易时段

resp = requests.get(
"https://api.tickdb.ai/v1/market/trading-sessions",
params={"market": "US"},
headers={"X-API-Key": "your_key"}
)

返回：

{

"market": "US",

"trading_sessions": [

{"begin_time": 400, "end_time": 930, "trade_session": 1}, # 盘前

{"begin_time": 930, "end_time": 1600}, # 正常交易（无 trade_session ）

{"begin_time": 1600, "end_time": 2000, "trade_session": 2} # 盘后

]

}

```美股正常交易时段（ 09:30–16:00 ）没有 trade_session 字段。 盘前（ 04:00–09:30 ）的 trade_session 是 1 ，盘后（ 16:00–20:00 ）的 trade_session 是 2 。

这意味着不能用字段的值来判断当前时段，必须用字段的存在性。

时段 |
trade_session 字段 |
正确判断方式 |

盘前 04:00–09:30 |
= 1 |
字段存在且值为 1 |

正常交易 09:30–16:00 |
不存在 |
字段不存在 |

盘后 16:00–20:00 |
= 2 |
字段存在且值为 2 |

如果代码写的是 if trade_session == 0 来判断盘中，就会在正常交易时段拿不到字段而报错。正确的写法是判断字段是否存在。

5.2 多市场时段不是一套规则

同一套逻辑放到港股和 A 股，字段结构又不一样。

市场 |
上午场 |
下午场 |
特殊规则 |

美股 |
09:30–16:00 （连续） |
— |
盘前 04:00–09:30 ，盘后 16:00–20:00 |

港股 |
09:30–12:00 |
13:00–16:00 |
午休 12:00–13:00 |

A 股 |
09:30–11:30 |
13:00–14:57 |
14:57–15:00 集合竞价收盘 |

三个市场，三种时段结构。 如果 AI 决策系统跨市场运行，数据层必须能区分"当前是哪个市场的哪个时段"，而不是用一个本地时间统一判断。

5.3 Jev 的数据里，行情的时间戳来自哪里

回到那个核心问题。

Jev 判断的输入是文字，文字有生成时间，行情数据有采集时间。这两者之间的差异，在日频研究中可能不重要。但如果系统在盘中运行，每次决策的输入数据如果来自不同时刻的行情快照，Jev 的概率输出就会失去可归因性。```

取 AAPL 日 K 线

resp = requests.get(
"https://api.tickdb.ai/v1/market/kline",
params={"symbol": "AAPL", "interval": "1d", "limit": 3},
headers={"X-API-Key": "your_key"}
)

返回：

{

"symbol": "AAPL",

"type": "stock",

"interval": "1d",

"klines": [

{"time": 1789531200000, "open": "332.53", "high": "335.48",

"low": "330.70", "close": "332.41", "volume": "35981000"},

...

]

}

``每根 K 线的时间以 Unix 毫秒 time` 字段承载。如果要把行情数据喂给 Jev ，这个时间字段就是数据里"当前价格"的时间证据。

这不是一个"用哪个数据源更好"的问题，是一个"你的 AI 决策能不能被审计"的问题。

Jev 给了你一个带概率的决策，但没有给你数据来源的时间证据。那个证据得你自己在数据层准备好。

六、那 193 倍的数字，和正确用法

TypeSafe 自测的 193.6 倍更快、444.6 倍更便宜，基准是 GPT-5.6 Terra——一个最慢、最贵的对比对象。

来源 |
对比基准 |
速度倍数 |
成本倍数 |

TypeSafe 自测 |
GPT-5.6 Terra |
193.6x |
444.6x |

PearPages 独立分析 |
同等智能基准 |
约 25x |
约 76x |

Near Here 独立测试 |
Mistral Small 4 |
约 5x |
约 8.6x |

官方的端到端延迟声明是 70 到 500 毫秒。webofmike 的独立实测 p50 延迟是 421.6 毫秒。

5 倍到 25 倍，取决于对比对象。这个区间比 193 倍更接近现实。

但速度不是重点。

重点是：Jev 给了你一个带校准概率的判断原语，但没有给你数据来源的时间证据。那个证据得你自己在数据层准备好。

如果把 Jev 放在信息处理层，用它做新闻分类、财报打分、候选排序，它可能是一个高效的判断工具。如果把 Jev 放在决策执行层，让它每个 tick 都输出一个方向判断然后直接下单，你会在手续费和噪音里亏掉本金。

如果你也在用 LLM 做量化，可以检查一件事：你的决策日志里，每条判断对应的行情数据时间戳是哪个时刻的。如果回溯不了，那这条决策的可审计性是有问题的。

来源

- TypeSafe 官方文档

- archerhume.com Jev 架构逆向分析

- APUS 开源复现报告

- webofmike 60 案例工具调用风险基准

- PearPages Jev 速度与成本独立分析

- Near Here 50 次真实内容审核决策独立测试

- GitHub – egrm07/jev_bitcoin_backtest

- GitHub – Waxmell114514/jev-trade

- GitHub – justinhe16/trade-jev

- Zerve.ai: LLMs in Quant Research (2026)

- arXiv 2608.20304: LLM Calibration-Induced Degeneracy in Financial Forecasting (2026)

- arXiv 2501.19047: Understanding Model Calibration (2025)

- TickDB API 实测数据（ 2026-09-21 实际调用）