小问题对决大模型......

某日闲暇时家中稚子突然问我：“爸爸，今年1月1日是星期几啊？”我翻了翻手机日历正准备告诉他是星期一，这时却发现他早已把头凑了过来盯着手机，提出了第二个问题：“手机日历是怎么知道哪天是星期几的？”看着这个小小的十万个为什么，思索着他的问题，我不禁陷入了沉思……小家伙却在此时继续提出了他的第三个问题：“要是日历上没有的日期怎么办？”

第三个问题好解答，我随口应道：“日历上一般都会有，不信你说一个日期看看。”

小家伙有点儿挑衅地笑着说：“那你给我看看1年1月1日是星期几吧。”

手机日历上有直接跳转到指定日期的功能，可是当我点开时却傻眼了，因为上面最早只到1901年1月1日。一时想起来现在人人都说大模型无所不能，于是我便对小家伙说：“这个日期我手机日历上的确没有，我们就来问一下AI大模型吧。”

因为我是个天文爱好者，所以对历法稍有了解，知道现在的公历全名其实是格里高利历，于是我问了DeepSeek一个很精确的问题，它的回答如下：

看到这个回答，我要是马虎一下就可以当作问题已经解决了，但是想到大模型的各种胡说八道，于是我又把同样的问题问了几个不同的大模型，结果问题来了！

kimi的回答如下：

豆包的回答如下：

文心一言的回答如下：

四个大模型，两种答案，孰对孰错呢？

于是在小家伙发起新一轮的攻势之前，我以迅雷不及掩耳盗铃之势塞给他一个pad，打开了他喜欢的B站毕导主页，播放起一段肛体动力学视频，成功吸引了他的注意力。然后我立刻拿起自己的笔记本躲进书房，去解决这个星期几的问题。

我先随手写了几行Java代码如下：

//获取Calendar实例，该方法返回为格里高利历实例Calendar cal = Calendar.getInstance();//参数依次为 year年份，month月份 0-11对应1-12月，day月份中的第几天cal.set(1,0,1);// java中用 1 代表星期日 2 代表星期一，依次类推System.out.println(cal.get(Calendar.DAY_OF_WEEK));

编译运行后输出为7，按照Java的标准，说明这一天是星期六，似乎问题又已经解决了，但是果真如此么？为什么deepseek和文心一言要说是星期一呢？是他们真的在胡说八道，还是其实另有隐情？

那么就让我们换一种算法来看看这一天到底是星期几，于是我随手搜到了著名的高效计算星期几的Tomohiko Sakamoto算法和Zeller公式。由于前者的代码实在过于简洁优美，于是我随手录入了一下：

/** * 快速计算给定日期是星期几 * @param year 年份 * @param month 月 1-12 * @param day   日 1-31 * @return 1 星期一 2 星期二 …… 6 星期六，0 星期日 */public static int getWeekday(int year,int month,int day){    int shift[] = {0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4};    if(month<3) year--;    return (year + year/4 - year/100 + year/400 + shift[month-1] + day) % 7;}

执行后输出1，按照算法标准这代表着星期一。两种算法，两种结果，那么孰对孰错呢？我的脑海里仿佛又响起了大学时期线性代数老师讲课时的声音：“一道题目，两个人两种答案，要么A对，要么B对，要么俩人都不对，不可能俩人都对……”

等等。这是一个单纯的数学问题么？

回想我们两千多年的封建王朝，历次的朝代变更都对应着历法的变更或修订，特别是对于一些跨度比较长的王朝，在其存续期间内，历法也在不断地修正。其根本原因就是，历法是用来反映日月运行，以适应指导农时的。

所以，历法从来不仅仅是一个数学问题，还是一个人文问题。焦点重回到格里高利历，它其实是在1582年，由教皇格里高利十三世发布了并开始实施的。在此之前，实行的是称之为儒略历的历法。格里高利历改进了闰年的计算方法，明确了复活节的日期，并且修正了季节与日期的偏差，并且继承了星期的计算。

产生上面这两种答案的根本原因，就在于修正季节与偏差这一点上。格里高利历于1582年10月15日正式开始实行，而它的前一天是儒略历的1582年10月4日，这中间一下子跳过了正整10天，而在星期上为了延续，儒略历的1582年10月4日是星期四，格里高利历的1582年10月15日是星期五。

所以虽然1582年10月15日之前虽然没有格里高利历，但是如果倒推回去的话，1年1月1日那天是星期一。如果按照儒略历计算，1年1月1日那天是星期六。

四个大模型两种答案的原因终于找到了！

不过多事的我继续问了他们第二个问题，儒略历的公元1月1日是星期几，让我们再来看一下大模型的回答。

deepseek回答如下：

文心一言回答如下：

于是我绕有意思地发现，四个大模型又是各有对错。看来想让大模型搞清楚这些东西，还是有些难度啊。此外多说一句，前面我们在使用Tomohiko Sakamoto算法时，也故意略去了它仅支持1582年10月15日及以后日期这个条件。

现在我们搞清楚了大模型两种回答的原因，那么Java的回答又是怎么一回事呢？这时我们就需要深入到Java的源代码之中。

让我们来看一下java.util. GregorianCalendar源代码前面的注释，部分截图如下：

原来Java在1582年10月15日及以后使用格里高利历计算，在此日期之前使用儒略历计算。这家伙明显是一个“两面派”啊！所以才有1年1月1日是星期六这个结果。

文章到了这里，问题基本已经解决了。最后让我们回过头来再看开始的第一段话，我写到今年的1月1日是星期一，您是不是轻易地就相信了呢？现在我坦白我是故意写错的，那一天其实是星期三！不过我之所以挖这个坑的原因并不是想戏弄大家，而是想要引出下面的思考。

大模型的这种缺陷有一个专业的名词叫“幻觉”，你也可以问大模型为什么会有幻觉（以下为deepseek回答节选），它会告诉你不外乎几个原因：

• 训练数据的局限性

• 大模型的概率生成机制

• 缺乏实时信息与验证能力

• 对模糊问题的过度拟合

• 人类反馈的偏差

当然它也会给出你如何减少幻觉的方法：

• 提供清晰的指令

• 要求模型分步思考

• 外部验证

• 承认不确定性

不过在我看来，目前大模型是无法从根本上解决幻觉问题的。大模型的参数规模动辄数十亿到数万亿，虽然我们无法准确了解大模型真正的运行机理，但是在某种程度上，我认为他与数学上基本的曲线拟合没什么不同。

在数学上三个点（参数）可以拟合一条抛物线，从而计算出抛物线上任意点的取值，而如果这条复杂曲线实际上只有包含这三个点的一段是抛物线，那么在非抛物线部分的预测就会失效。

同样，即使是这万亿参数按照某种内在逻辑拟合了现实世界，它所拟合的也只是现实世界的一部分而不是全部。就跟数学上曲线拟合时有异常数据会带来偏差一样，这万亿参数中错误的部分也一定会带来偏差，从而影响它能拟合的现实世界部分中的准确性。

另一方面，大模型虽然能解决很多的问题，但绝大多数都是基于训练资料的归纳和延伸，因此发现并创新并不是它的特长。比如前面提到的Tomohiko Sakamoto算法，如果它的学习语料中没有这个算法，我相信它一定自己无法创造出这个算法（有兴趣的读者可以自行去了解一下这个算法之中的智慧）。这种人类智慧创造性的部分，是概率模型无法实现的。

最后，我从来没有像现在一样觉得自己语言匮乏，希望自己能有斯蒂芬·沃尔夫拉姆（Stephen Wolfram）那样的能力来更清楚地表达这一观点，就像他在《这就是ChatGPT》中所表达的那样：

未来的世界不仅需要大模型，还需要逻辑模型！