大语言模型似乎非常不擅长解读汉字部首互换游戏

我常用相同的一个问题拷问各种版本的大语言模型。

这个问题是：

柏扳 讣裸 悦请 谅㤉 栍恪 褊但 镐措 镰贱 抟斩 沌结 谅㤞

上述词语其实是从真实存在、有意义的汉字词汇转化来的。

找出所有对应的原词语。

列出更多相同模式的转化词。

由于我自己的语文也不怎么好，我不知道怎么更好地向大模型描述这个问题。恐怕说中文的人也会花好一阵子才理解我在说什么。

各个模型稍早一些的版本都会开始胡说八道，或者喷出毫无意义的词汇。Deepseek会陷入穷举的深度思考，直到超时耗尽，且什么都没有输出。

于是我这时候提示大模型，这些词语属于部首互换（radical swap），由两个部首不同的字组成的常用词，将两字的部首互换¹，得到的新字组合即为转化词。形象一点列出：

这时候大模型都会恍然大悟，然后继续输出一些不符合规则的无意义汉字组合来作为答案。

在最新版本的各个模型中，有些大模型已经独立克服了需要被提醒的阶段，自行推理出明确的部首互换规则。

我还不清楚它们使用了什么训练数据，也许得到了更多符合规则的词汇，规律变得更明显。

事实上，之前列出的这一些词语中有几个确实是大模型灵光一闪给出了正确的答案，因而被采纳的。

但是，再继续输出新例子的时候，更多的错误产生，而大模型并不会检查且诚实地选择说“我不知道更多了”。

不过，这个任务显然对一般人来说也不简单，不然我就不会去请求大模型了。

这时候我就问大模型：

为什么你知道部首互换，但是提出的例子绝大部分都是不对的？你在处理汉字时是不是只能看到unicode而不是真实的字形和汉字数据中对应的部首信息，而要知道部首信息就必须进行大量的推理和检索mapping，因此这根本不是你擅长的？解释一下。

目前我问过的大模型都会顺着我的话头接下去解释，它们确实处理的是基于Token（词元/数值编码）的语义关联，是对Unicode处理，而非基于视觉字形的解构。因此它们就不能意识到汉字之间的形状关系。

那么，将汉字部首放进大模型的知识库中，可能会对它们解答类似问题有所帮助，或者考虑调用其他更好工具的汉字库元件来进行处理。

不过，随着大模型的版本更新，之后给出的答案必定会越来越准确。

下面也是大模型输出的一些新的词汇：

汉字还是太难了。