EVERSEA

&ndsp;

当 AI 试图给自己 Debug 时，灾难才真正开始

当 AI 试图给自己 Debug 时，灾难才真正开始

在本地大模型（Local LLM）的极客圈子里，一直流传着一种迷思：官方原版模型（Official Weights）是带着“安全对齐”枷锁的舞者，而解除了审查（Uncensored）的微调版则是重获自由的天才。

最近，我在 M1 Max (64GB RAM) 的本地环境中，对 Gemma4-31B 及其 Uncensored 版本进行了一场深度的代码逻辑压测。原本我只是想探究模型在恢复了 <think> 标签后的表现，但这却意外演变成了一场极其硬核的“代码级尸检”。

实验的结果不仅彻底击碎了对 Uncensored 版本的盲目迷信，更揭示了一个令所有开发者脊背发凉的真相：在严密的数学逻辑面前，大模型依然只是一个“文本概率预测器”。当它试图进行自我逻辑修正时，真正的灾难才刚刚开始。

一、 为什么 Uncensored 恢复了思考，代码依然会翻车？

在之前的测试中，Uncensored 31B 在代码逻辑上跌跌撞撞，甚至出现了格式崩坏。这是一个非常具有极客精神的疑问：如果我们通过修改 Modelfile，强行给它装回 Thinking... 的脚手架，它能恢复原版那样的“一次通关”能力吗？

答案是：不能。

虽然修复模板解决了它“格式崩坏”（比如输出乱码）的表象，但无法修复它在被“解除审查”时遭受的底层逻辑损伤。大模型的“解除审查”在工程上绝对不是简单地拨动一个开关，而是使用一套不包含拒绝回答的数据集，对模型进行二次微调（SFT）或权重正交化处理。

在这个过程中，会发生两个致命的副作用：

这就是为什么你的 Uncensored 31B 虽然“脑子（模板）”转起来了，但在处理尼拉坎塔级数的分母累加等复杂逻辑时，依然会犯错。它的神经元权重已经被破坏了。

二、 原版 31B 的一次成功，是偶然吗？

看着 Uncensored 版本的挣扎，你自然会怀疑：原版 31B 的一次通关，到底是因为它真的牛，还是刚好撞大运（幸存者偏差）？如果你再用原版测试一次，会不会也翻车？

大概率不是偶然，而是谷歌砸了重金算力烧出来的必然。业界评估代码大模型有一个核心指标叫 pass@1（一次通过率）。官方原版 31B 经历了极其严苛的代码指令微调和人类反馈强化学习（RLHF），这意味着在它的概率空间里，“写出正确、无 Bug 且符合数学常识的代码”的概率权重被调教到了极致。

当面对“计算 PI 值的最佳实践”这种经典工程问题时，两者的表现截然不同：

如果再次进行压测，结果很大程度上取决于启动模型时的隐藏参数：Temperature（温度）。

但这是否意味着原版 31B 就无可挑剔了？好戏才刚刚开始。

三、 官方原版的“优雅幻觉”：一次极其隐蔽的代码翻车

为了打破迷信，我强制指令原版 31B 换一种算法（高斯-勒让德算法，Gauss-Legendre）来计算 $\pi$。原版模型表现得像一个极其自信的资深程序员，迅速给出了一段看似无懈可击、注释专业的 JavaScript 代码：

JavaScript

/**
* 使用高斯-勒让德算法 (Gauss-Legendre) 计算 PI
* 该算法具有二次收敛特性，极其高效。
*/
function calculatePiGaussLegendre(iterations = 4) {
  let a = 1.0;
  let b = 1 / Math.sqrt(2);
  let t = 0.25;
  let p = 1.0;

  for (let i = 0; i < iterations; i++) {
    const aNext = (a + b) / 2;
    const bNext = Math.sqrt(a * b);
    
    // 更新 t: t = t - (a-b)^2 / 4
    t = t - Math.pow(a - b, 2) / 4;
    
    // 更新 p: p = p * 2
    p = 2 * p;
    
    a = aNext;
    b = bNext;
  }
  return (a + b) * (a + b) / (4 * t);
}

这段代码能跑通，没有卡死系统，极其优雅。但当我把代码放入 V8 引擎执行后，终端输出了这样的结果：

Plaintext

内置 Math.PI: 3.141592653589793
算法计算 PI: 3.1410420453156243
迭代次数: 4次
绝对误差: 0.0005506082741688623
是否完全一致: false

打脸来得太快就像龙卷风！ 小数点后第三位竟然出现了漂移。经过极其锐利的代码审查，我抓到了一个极其经典的“大模型数学幻觉”。

高斯-勒让德算法的标准数学迭代公式如下：

$$a_{n+1} = \frac{a_n + b_n}{2}$$
$$b_{n+1} = \sqrt{a_n \cdot b_n}$$
$$t_{n+1} = t_n - p_n(a_n - a_{n+1})^2$$
$$p_{n+1} = 2p_n$$

仔细看原版 31B 写的更新 $t$ 的代码：它耍了一个非常聪明的代数小聪明，它知道 $(a_n - a_{n+1})^2$ 化简后正好是 $\frac{(a_n - b_n)^2}{4}$。

但是，它把公式里的权重变量 $p_n$（即代码里的变量 p）给彻底忘了！

正确的代码应该是：t = t - p * (Math.pow(a - b, 2) / 4);

因为第一轮迭代 $p=1$，错误被掩盖了。但从第二轮开始 $p$ 翻倍，由于漏乘了 $p$，导致减去的值太小，$t$ 偏大，最终算出来的 $\pi$ 值（分母偏大）也就偏小了。

这是一种**“优雅的幻觉”（Graceful Failure）**。对齐训练赋予了官方模型极高的工程健壮性（代码规范、无低级语法错误），但它记住了公式的“形状”，却弄丢了代数的“灵魂”。

四、 神级反转与最终暴击：当 AI 试图给自己 Debug

既然发现了 Bug，我决定给原版 31B 一次自我修复的机会。

令人啼笑皆非的是，这造就了本次评测中最具戏剧性的灾难现场。

这是 AI 自我 Debug 后的核心代码片段：

JavaScript

// 【关键修正点】更新 t: t = t - p * (a - b)^2
// 这里必须使用当前的权重因子 p
t = t - p * Math.pow(aPrev - bPrev, 2);

运行结果直接让我怀疑人生：

Plaintext

内置 Math.PI: 3.141592653589793
算法计算 PI: 4.379499436692017
绝对误差: 1.2379067831022237
是否完全一致: false

从 0.0005 的微小偏差，直接搞出了一个 $\pi = 4.37$ 的巨大灾难！这对于一个数学算法来说，是彻底的底线击穿。它到底干了什么蠢事？

它搞出了一个**“致命的代数缝合怪”**。

  1. 第一次犯错： 用了代数化简式 $\frac{(a-b)^2}{4}$，但漏了 $p$。

  2. 自我 Debug 时： 它被提醒“漏掉了 p”，于是它的注意力机制（Attention）全集中在填补变量 $p$ 上。它猛地把 $p$ 塞了进去，但在强行拼凑文本时发生了概率滑坡——它把化简公式里极其关键的 / 4 给弄丢了！

要么用定义式：t = t - p * Math.pow(aPrev - a, 2);

要么用化简式：t = t - p * (Math.pow(aPrev - bPrev, 2) / 4);

结果它把两种不同的代数表达像弗兰肯斯坦一样缝合在了一起。这导致 $t$ 减去了比正常值大 4 倍的数，分母极速变小甚至畸变，最终结果自然暴涨到了 4.37。

极客的最终结论：没有绝对的神明

这两次连环翻车，完美地扒掉了大模型在“逻辑推演”上的底裤，向我们极其直观地展示了 LLM 的底层物理逻辑：大模型本质上没有抽象的符号代数运算能力（Symbolic Reasoning）。

在生成需要极高容错率的核心算法时，永远不要盲目信任 AI 吐出的第一串代码，哪怕它的注释写得再专业。千万不要让一个大语言模型在没有代码执行环境（Code Interpreter / 沙盒）的情况下，去“肉脑”推演和修复严密的数学代数代码。

人类的编译器会报 Syntax Error，而大语言模型只会一本正经地给你输出一个 $\pi = 4.37$ 的宇宙！在这个被 AI 浪潮席卷的时代，人类的 Code Review 和单元测试，依然是我们坚守真理的最后一道防线。

“为什么它写贪吃蛇比算圆周率还顺手？”

测试到最后，我发现了一个荒谬的现象：这个在计算 $\pi$ 时被代数化简折磨得死去活来、把浏览器卡死的 Uncensored 模型，却在收到“写一个贪吃蛇”的指令后，行云流水地输出了一份单文件、零依赖、即刻可玩的 HTML/JS 游戏代码。

这揭示了大模型的本质底色：它是全人类代码库的‘高级统计学复读机’，而不是真正的‘逻辑思考者’。

它能极其优雅地输出贪吃蛇，是因为它在预训练的题海里做过十万遍这道题，它掌握了极强的工程积木拼装能力；而它算不对高斯-勒让德，是因为数学容不得半点概率学上的模糊与妥协。

不要被它流畅写出游戏的外表所迷惑，从而盲目信任它在严密科学计算上的输出。它是一个极具创造力的实习生，而不是一个严谨的数学家。

# # # #


发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注