Lichess 分析漏掉了什么
简而言之
- Lichess 用一次一百万节点的服务器分析来标记你的着法。我把 300 局随机对局按两千万节点重跑了一遍,并逐个比对了标记。
- 十个标记里有一个会变。不稳定的那个是「不准确」:57% 站得住,28% 在深搜下根本不算问题,15% 其实更糟。
- 每二十局就有一局存在完全没被标出的错误,大多落在半个兵到三个兵之间,而对局正是在这一区间被决定的。
- 其中三十二个未被标出的错误,取自有头衔棋手的对局,已整理成一套习题研究。
上周一局快棋里,Lichess 标了我八个着法。第 20 着不在其中,而它是个错误,是这局中报告完全没提到的三个错误之一。服务器给出 20.Qd1 之前 +1.2、之后 +0.9,落差太小,不足以标记。而给 Stockfish 二十倍的时间,它给出之前 +2.0、之后 +0.7。
同一局棋评估了两次。Lichess 的曲线就是它图上显示的;圆点是它标记的着法,双方都有。圆圈是深搜判为错误而它没有标出的三个:20、24 和 26。
我想知道这种情况有多常见,于是按服务器预算的二十倍重新分析了 300 局随机对局,又按四倍分析了九位有头衔棋手的 800 局,并逐个比对标记。十个里有一个会变。最不该信的标记是「不准确」。而每二十局就有一局存在完全没被标出的错误,习题正是从这里来的。
标记是怎么产生的
服务器分析(fishnet,跑在捐赠 CPU 上的 Stockfish)对局中每个局面评估一次,每着 1,000,000 节点,大约是单核一秒。每个标记都是两个数字之差,即你走子前的局面和走子后的局面,换算成胜率,这样在 0.00 处失掉半个兵就比在 +5 处更严重。胜率下降 0.1 为不准确,0.2 为错误,0.3 为严重错误。
所以标记只看得到一百万节点看得到的东西,两端都是如此。如果搜索始终找不到反击手段,「之前」那个数字就从未知道你手里有什么,于是你的着法相对于它也就没有损失。我的 20.Qd1 就是这种情况:更好的格子只差一路,而惩罚要在三着之后才开始,超出了一秒搜索的视野。
两千万节点下会变什么
在 300 局随机等级分对局(1600 到 2400,取自 2026 年 8 月数据库)上,用同一套公式按 20,000,000 节点重新评估:
- 十个着法里有一个标记会变。 变化在两个方向上数量相当,所以对局总结里的总数几乎不动,而底下的着法却在变。
- 不准确是那个不稳定的标记。 在 1,805 个 Lichess 标记的不准确中,57% 在深搜下仍是不准确,28% 根本不算问题,15% 其实是错误或严重错误。严重错误的标记有 84% 站得住。
- 每二十局就有一局存在完全没被标出的错误,每八局就有一局被标为错误的着法在深搜下根本不算问题。两者都集中在半个兵到三个兵之间,也就是对局被决定的区间。
对九位有头衔棋手各约一百局自己的着法做同样的分析:Lichess 扣在 Magnus Carlsen 头上的错误中,有四分之一在深搜下并不是错误,而对其他人则相反,每五个真正的错误里就有一个被贴了比它应得的更轻的标记。
| 棋手 | 对局数 | Lichess 判的错误+严重错误 | 标记偏轻 | 标记偏重 |
|---|---|---|---|---|
| Magnus Carlsen | 104 | 195 | 18 (11%) | 50 (26%) |
| Alireza Firouzja | 104 | 215 | 45 (20%) | 35 (16%) |
| Eric Rosen | 102 | 225 | 45 (20%) | 43 (19%) |
| Jerry (ChessNetwork) | 104 | 287 | 45 (16%) | 46 (16%) |
| Oleksandr Bortnyk | 102 | 184 | 51 (25%) | 30 (16%) |
| Sergei Zhigalko | 103 | 218 | 53 (22%) | 29 (13%) |
| Dmitry Andreikin | 104 | 165 | 33 (19%) | 26 (16%) |
| Ediz Gürel | 61 | 117 | 37 (27%) | 15 (13%) |
| Anish Giri | 20 | 12 | 3 | 1 |
五个被分析放过的漏判
每个局面都出自上述对局。棋手走了图示的着法,分析没有给出任何标记,而两千万节点的搜索判定它是错误或更糟,相对的最佳着法是唯一的。棋盘从走子前的局面打开,你可以先自己找更好的着法;往前一步就会看到对局中的着法以及它本应得到的标记,反击手段则是研究里的变例,就在每个棋盘下方一点即可。
Zhigalko,黑方走。 白方刚走 Be5,攻击 c7 的后,黑方做了最自然的事:20…Qd7,把后撤出攻击。分析给出之前 −1.38、之后 −1.30,毫无损失。可是这个后并不需要救。20…Rxd2!弃掉车换子,21.Rxd2 之后兵走 21…c3!同时捉住 b2 的后和 d2 的车。白方把后吃回来(22.Bxc7 cxb2 23.Rxb2 Rxc7),最后是一车对黑方的双象加一马:深搜下 −3.2,而回撤只有 −1.3。反击手段以一个亏子的着法开头,这正是一秒搜索永远看不到它的原因。
Bortnyk,黑方走。 20…b5 攻击 c4 的象,分析从 −0.63 变到 −0.41。f5 的象本可以直接吃马:20…Bxe4!21.dxe4,这时另一只马落到 f4,随后 …e5 把象从 d4 赶走。黑方五着之内赢子,深搜 −2.7;次佳着法即立即 20…Nf4 只有 −0.6。
Bortnyk,黑方走,后的残局。 后加马对后加车,白方唯一的资本是 a 路兵。黑方走了 54…Qf6;分析说从 −1.58 到 −1.03。深搜下 Qf6 之后的局面是死和。54…Qa7+!55.Kg3 Qxa4 带将吃掉那个兵,残局是 −2.1,是胜势。
Carlsen,黑方走。 白后在 g4,马在 e4。Carlsen 走了 15…Ne5 攻击后,分析从 −0.94 变到 −0.43。兵走 15…f5!同时攻击两者:16.Qh3 fxe4 17.Bxe4 之后,黑方以一兵换得一马,评估 −1.9,而次佳着法(15…g6)落后一个半兵。浅层搜索把 …f5 读成松动王翼、把马的回撤读成安全,两种读法都是错的。
Gürel,白方走。 车的残局,各有一马;黑方 a3 的马无根,白方 d 路兵在 d5。白方走了 31.Nd4,分析从 +1.42 到 +1.06。31.d6!才是正着:车必须挡兵(31…Rxd6),然后 32.Nxa3 白吃一马。深搜 +3.9,而对局着法之后只有 +0.9。
全部 32 个都在这套研究里,按习题形式编排:先给局面,标出对局中的着法,反击手段作为变例并附上引擎的数值,此外对局后面每一个被 2000 万节点搜索判定的着法都带有自己的标记,旁边是引擎的变例。逼着性的解法排在前面,因为超出浅层视野的长战术是人能找到的;平静的那些排在后面。
读懂你自己的报告
「零错误」意味着在一百万节点下看不到错误。严重错误是真的,不准确有一半是真的,而那些让对手重新回到你已多一两个兵的局面里的着法,恰恰最有可能不带任何标记。如果某局棋很重要,就用你自己的引擎去跑,让它在 +0.5 到 +3 之间的局面上搜过 25 层再停。
测量方法
随机样本取自2026 年 8 月 Lichess 数据库中每第十局已分析的对局,且双方等级分都在 1600 到 2400 之间:共 300 局,20,227 个带服务器评估的着法。每个局面都经过 Stockfish 18(fishnet 所用的主版本)在单线程、20,000,000 节点下的分析,再用 lila 自己的公式(Advice.scala:胜率落差 0.1、0.2、0.3)生成第二套标记。这套公式用在 Lichess 自己的评估上时,能以 99.07% 的比例复现 Lichess 自己的标记,所以比较的两边都用它。两端存在必然杀的 842 个着法被排除,lila 对它们用另外的规则判断。节点预算写在 lila 的 Work.Origin 里:请求分析为 1,000,000,官方转播为 5,000,000,自动分析为 300,000 和 100,000。
| Lichess 标记 | 20M 下无标记 | 不准确 | 错误 | 严重错误 |
|---|---|---|---|---|
| 无 | 15,281 | 496 | 13 | 2 |
| 不准确 | 504 | 1,033 | 233 | 35 |
| 错误 | 27 | 190 | 367 | 151 |
| 严重错误 | 12 | 18 | 134 | 889 |
这九位棋手的对局是他们在公开 API 上最近一百局已分析的等级分快棋和慢快棋(其中七位在 2026 年仍活跃;Carlsen 和 Firouzja 今年没有已分析的 Lichess 对局,所以他们的分别回溯到 2021 年和 2023 年),用更省的 4,000,000 节点分析。在随机样本上,4M 能找到 20M 所找到的略过一半,所以棋手的比率是下限。一个习题要留下来,必须满足:所走着法在 20M 下相对最佳着法至少损失 0.2 胜率,且该最佳着法比第二变例好 0.1 以上,搜索三条变例;之后还要满足:对该局面进行第二次独立的 20M 搜索仍判对局着法为错误。第一道关通过 35 个,第二道通过 32 个。这就是 20M 搜索中噪声的量级,也是为什么把更深的分析当作比真相近二十倍、而不是当作真相本身。
相关资源:
- 这套研究:全部 32 个习题,附解法和引擎数值
- lila
Advice.scala:判定阈值 - lila fishnet
Work.scala:各分析来源的节点预算 - Lichess 公开数据库:每月数据转存