最近 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( "/ai-market-guide/ 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( "/ai-market-guide/ 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 实际调用）