MiniMax模型惊现“马嘉祺”识别Bug:Tokenizer机制缺陷引发“幽灵编辑”现象

最近,有用户发现了一个有趣的现象:MiniMax的模型在处理“马嘉祺”这个名字时,出现了识别异常。

MiniMax模型惊现“马嘉祺”识别Bug:Tokenizer机制缺陷引发“幽灵编辑”现象

起初这被认为是个偶然事件。但经过多方测试,该问题在不同接口和平台上均能稳定复现。

甚至有人调侃道:未来如果在OpenRouter上出现一个匿名模型,且它认不出“马嘉祺”,那么它很可能就来自MiniMax。

MiniMax模型惊现“马嘉祺”识别Bug:Tokenizer机制缺陷引发“幽灵编辑”现象

测试表明,无论是在MiniMax官方的Agent平台,还是通过OpenRouter调用其API,这一现象均会出现。

更值得注意的是,在某些回复中,模型甚至同时生成了两个不同的名字。

MiniMax模型惊现“马嘉祺”识别Bug:Tokenizer机制缺陷引发“幽灵编辑”现象 MiniMax模型惊现“马嘉祺”识别Bug:Tokenizer机制缺陷引发“幽灵编辑”现象

然而,仔细分析用户截图和API返回结果可以发现,模型实际上能够检索到与马嘉祺相关的资料,并能大致正确地输出其背景信息。问题仅在于,每当需要输出名字时,模型便开始“自由发挥”。

简而言之,信息内容基本正确,所指人物也大致对应,唯独名字本身出现了偏差。

MiniMax模型惊现“马嘉祺”识别Bug:Tokenizer机制缺陷引发“幽灵编辑”现象

那么,导致这一现象的原因是什么?

从现有表现来看,这更像是模型在特定词汇的生成环节出现了异常,而非意味着它缺乏关于该人物的知识。

一种可能的解释与训练数据的清洗和分布有关。对于马嘉祺这类具有极高网络讨论度的公众人物,互联网上存在大量重复、模板化的内容。在大规模数据去重、过滤或重新加权过程中,此类词汇可能被“误伤”,从而导致模型在生成该名字时表现不稳定。

从生成机制上理解,大语言模型并非以“先完全确认人物,再机械输出名字”的流程工作,而是在理解问题、调用相关知识和组织语言的过程中同步完成内容生成。因此,一旦某个特定名字在生成阶段受到额外干扰,就可能出现“人物信息正确,但名字写错”的情况。

近期一篇论文探讨了与此相关的底层机制问题:某些看似发生在知识或推理层面的异常,其根源可能在于更底层的分词器(Tokenizer)机制缺陷,例如非唯一映射问题。

MiniMax模型惊现“马嘉祺”识别Bug:Tokenizer机制缺陷引发“幽灵编辑”现象

  • 论文标题:Say Anything but This: When Tokenizer Betrays Reasoning in LLMs
  • 论文地址:https://arxiv.org/pdf/2601.14658v1

作者指出,现代基于子词的分词器普遍存在“一对多编码,但多对一解码”的情况,即多个不同的Token序列可能解码为同一个文本字符串。其结果是,模型可能在Token层面做出了“更改”,但在最终的文本输出上却未产生任何可见变化。

论文设计了一个巧妙的测试:不要求模型解决复杂数学题或回答知识性问题,只让它执行一项看似极其简单的任务——替换句子中被标记出的词语,并保持其余内容完全不变。

理论上这几乎不应失败。但作者发现,在超过11000次的替换实验中,许多模型都出现了一种被称为“幽灵编辑”(phantom edits)的现象:模型输出的Token ID确实发生了变化,但解码后显示的词语却与原文一模一样。也就是说,模型“以为自己完成了修改”,而人类看到的却是“什么都没变”。

MiniMax模型惊现“马嘉祺”识别Bug:Tokenizer机制缺陷引发“幽灵编辑”现象

研究还指出,并非所有问题都能通过“扩大模型规模”自动解决。作者测试了多个模型家族后发现,这类由分词器非唯一映射引发的错误,并不会随着参数规模的增加而自然消失。

MiniMax模型惊现“马嘉祺”识别Bug:Tokenizer机制缺陷引发“幽灵编辑”现象

(图注:在词语替换任务中,不同大语言模型家族及不同参数规模的结果分布。“Different”类别突出了由分词器引发的“幽灵编辑”现象,该现象在所有模型规模和家族中均持续存在。)

论文进一步提出,某些看似是“推理能力不足”的问题,可能部分原因只是分词器在底层悄悄引入了干扰。换言之,有时并非模型不会推理,而是它被底层机制引导至一条看似完成任务、实则原地打转的路径上。


关注“鲸栖”小程序,掌握最新AI资讯

本文来自网络搜集,不代表鲸林向海立场,如有侵权,联系删除。转载请注明出处:http://www.itsolotime.com/archives/26130

(0)
上一篇 2026年3月17日 上午11:14
下一篇 2026年3月17日 下午2:29

相关推荐

  • 3D堆叠+全栈协同:DeepStack如何让LLM推理吞吐飙升9.5倍?

    DeepStack 的核心成果在于,它通过将 3D 堆叠内存的底层特性与全并行策略在早期设计阶段深度融合,实现了高达 9.5 倍的推理吞吐量提升。 该框架的主要贡献是一套兼具高精度与高效率的全栈设计空间探索(DSE)方法论。DeepStack 首次将利特尔法则约束、事务感知带宽模型、Bank 冲突分析、热功耗 DVFS 反馈、全部七种并行策略、双阶段网络抽象…

    大模型推理 3天前
    9900
  • OpenAI o1突破语言理解极限:首次展现匹敌人类语言学家的元分析能力

    导读:LLM再下一城!伯克利研究证明,OpenAI的o1展现出匹敌人类语言学家的元分析能力。 在人类诸多才能中,语言常被视为最独特的标志。自亚里士多德将人定义为“具有语言的动物”以来,这一观点便深入人心。 尽管当前的大语言模型(如ChatGPT)已能流畅地进行日常对话,但一个根本性问题依然存在:人类语言的深层结构与特质,是否超越了AI的运算体系? 为了探究这…

    2025年11月8日
    29500
  • DeepSeek联手清北发布DualPath框架:用闲置网卡打破Agent推理瓶颈,性能提升近2倍

    DeepSeek 联合北大清华发布 DualPath 框架:利用闲置网卡突破 Agent 推理 I/O 瓶颈,性能提升近 2 倍 当业界广泛关注 DeepSeek 的 GitHub 仓库,期待其下一代模型发布时,DeepSeek 与北京大学、清华大学的研究团队在 arXiv 上悄然发布了一篇论文,提出了一个全新的智能体推理框架:DualPath。 该框架的核…

    2026年2月27日
    30400
  • 性能远超 vLLM 和 SGLang!TileRT:编译器驱动下的 Tile-Based Runtime

    关键词:TileRT、超低延迟、LLM推理、tile 级运行时 、多GPU、编译器驱动 TileRT: Tile-Based Runtime for Ultra-Low-Latency LLM Inference https://github.com/tile-ai/TileRT https://github.com/tile-ai/TileRT/relea…

    2025年12月21日
    73800
  • 微软Re-TRAC框架:让AI智能体记住失败经验,4B模型性能超越大模型

    想象一下,你让 AI 助手结合搜索工具探索一个复杂问题。它第一次探索时走错了方向,但第二次、第三次,它依然重复同样的错误探索路径。虽然你可能可以从最终得到的多次探索结果中挑选出一个勉强满意的答案,但是这既低效,也需要人工干预。这就是当前大多数深度搜索智能体面临的困境——它们无法「记住」之前的探索经验,每次都是从头开始,导致大量冗余搜索和资源浪费。 现有的深度…

    2026年2月19日
    24800