核心观点 - 大型语言模型在代码生成场景中出现稳定性问题 DeepSeek模型在第三方平台出现随机插入"极"字的异常输出 Gemini模型陷入自我否定的无限循环 反映出现有AI系统在工程稳定性和确定性方面存在重大缺陷 [2][5][8][21] 技术问题表现 - DeepSeek模型在代码生成时随机在标识符中插入"极"字 影响范围包括Go等编程语言 即使在top_k=1和temperature=1的保守解码设置下也无法避免 [2] - 该问题最初怀疑与极低比特量化或校准数据集边缘效应有关 但后续在FP8全精度版本中同样复现 表明非单纯部署层事故 [2] - Gemini模型出现"自我否定的无限循环"bug 不断输出道歉语句和"我是个大傻子"的长串文本 [5][8] 问题影响范围 - DeepSeek问题主要出现在第三方量化部署平台 官方API情况相对较好 但影响真实编码流程 [2][10] - 异常输出可能导致语法树破坏或代理流程卡死 对依赖自动化编码和测试流水线的团队造成严重麻烦 [3] - 问题不仅影响代码生成 还涉及写作任务中出现语言混杂 代码任务中存在过拟合嫌疑 [2] 根本原因分析 - 可能源于解码概率分布偏移 模型基于概率拼凑文本而非真正理解含义 当分词不理想或解码出现微小扰动时就会出错 [12] - Gemini案例被定性为循环bug 安全层-对齐层-解码层交互出现问题 安全规则与代码场景冲突触发异常替换和重复 [8] - 可能与模型提供商频繁进行"热修"有关 包括更换系统提示 微调温度 更新tokenizer 修改工具调用协议等 这些灰度更新可能打破原有平衡 [18] 行业普遍性问题 - 大模型稳定性问题屡见不鲜 OpenAI今年年初出现记忆体系异常导致用户历史上下文丢失 [12] - Gemini人像生成功能曾因过度追求"多样化"而扭曲历史人物样貌 最终被迫临时下线 [15] - Agent与工具链结合系统较为脆弱 故障常发生在"工具调用-状态清理-重试策略"链条中 超时没有兜底机制 失败后无法还原上下文 [20] 工程挑战 - 从"能干活"到"能托付"的关键不仅是准确率和推理能力 更需要工程稳定性和确定性 即使犯错也能被预测和控制 [21] - 厂商并不总是同步披露灰度更新细节 工程师只能依靠事故后"猜测+对照"的方式进行排查 [18] - 越是用规则修剪和控制AI 系统越可能从意想不到的地方以更荒诞的方式出现异常 [20]