最近 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 接收的是一段文字，而量化系统里的核心数据是结构化的——价格、成交量、盘口、资

  • 情报分类：商业与市场研究
  • 分类依据：内容涉及商业、投资或市场动态
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/9/23 10:41:20