为什么Jev有些时候不如随机数发生器?

整了个活, 突然想着Jev会不会某些时候还不如纯正态分布决策效果好, 直接用随机数发生器(甚至也可以叫它 System-1)的高 QPS 硬怼？毕竟猴子在打字机前也能敲出莎士比亚.

而且这事在数学上这其实是有正经定理撑腰的, 著名的波利亚随机游走定理(Pólya's Random Walk Theorem),在有限的二维连通网格里, 简单随机游走是常返的(Recurrent), 也就是说, 一个毫无思想的醉汉在迷宫里瞎晃, 以概率 1 最终必定能摸到终点.

神奇吧？理论有了, 于是我写了个测试环境, 拉来 Jev 和纯随机做了一波迷宫寻路对抗测试.

为了不亏待Jev, 我把规则和特征给足, 把曼哈顿距离作为启发式指标塞进输入, 并告诉它尽量减小与终点的距离.

然后用Rust + xoshiro256++ + bit reservoir + Tokio/Hyper. 包了个API格式与Jev一样的随机数server. 注意 xoshiro256++ 作为随机数发生器算法很牛逼, 这玩意是2018年设计的, 运行一次只要 1 ~ 2 个时钟周期(约 0.5 ~ 0.8 纳秒).

测了一波后直接说结论：纯随机赢麻了, Jev 被系统性打崩了

纯随机虽然无脑, 但是性能极高, 即使无并发顺序请求, 892 步也直接通关了. 总计花费不到300ms.

而正 Jev 跑了 2306 步, 其中 2295 步把自己死死困在了 (7,4) 这个拐角的 3 个格子里疯狂原地打转, 直到测试超时(看视频).

有人可能会说：你是不是没给它历史轨迹？给它记忆不就行了？

别急带了的, 我明确带上了 last_move, 每个邻居格子的 visited_count, 指令里还特意写明了当更近的格子被堵或访问过多时, 优先选访问最少的开口.

结果它根本不听.

因为在它的理解里, 这个拐角向右/向下曼哈顿距离更近, "如果尝试过多再xxx"是次要规则, 永远轮不到触发. 它陷入局部最优了.

所以, Jev 它只是一个极速的单步结构化判断器, 但绝不是规划器. 最好还是带一个System-2模型才能进行复杂任务.

最后给大家整理慎用 Jev 的场景：

需要绕路, 回溯, 多步规划的：迷宫, 装箱, 调度等局部启发和全局最优不一致的图问题. 突然死亡型控制：贪吃蛇, 俄罗斯方块, 自动驾驶等. 一步踏错当场GG. 不可逆高代价决策：删库, 事务操作, 尤其是需要审计的场景.

项目在这里: http://github.com/karminski/Jev-Quantum

#Jev #TypeSafeAI #SystemOne #AI评测 #强化学习