Jev 底层拆解：跳过逐字生成直接出概率，但量化回测为什么是负的

最近 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 做量化，可以检查一件事：你的决策日志里，每条判断对应的行情数据时间戳是哪个时刻的。如果回溯不了，那这条决策的可审计性是有问题的。

来源

1. TypeSafe 官方文档


2. archerhume.com Jev 架构逆向分析


3. APUS 开源复现报告


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


5. PearPages Jev 速度与成本独立分析


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


7. GitHub – egrm07/jev_bitcoin_backtest


8. GitHub – Waxmell114514/jev-trade


9. GitHub – justinhe16/trade-jev


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


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


12. arXiv 2501.19047: Understanding Model Calibration (2025)


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