DeepSeek澄清“串台”事件：特殊字符触发模型异常响应，数据安全机制未受影响

DeepSeek团队在4月10日发布了一则技术说明，解释此前用户反馈的“信息串台”现象即某位用户输入的内容意外出现在另一位用户的响应中。这不是数据泄露，也不是系统被入侵，而是一次由特殊字符触发的模型内部状态异常，属于典型的推理阶段幻觉（hallucination）行为。该问题仅影响极少数使用特定非标准Unicode字符（如组合变音符号、零宽空格、私用区码位等）进行长文本输入的场景，且全程未涉及用户原始请求内容的跨会话存储或复用。

问题定位：不是“记忆错乱”，而是“状态污染”

模型本身不保存用户历史，但推理过程依赖上下文缓存（KV Cache）。当输入中混入未被tokenizer充分归一化的特殊字符时，部分底层计算单元可能误判token边界，导致注意力机制在解码阶段错误关联前序batch中的残余状态。这种现象在v3版本中已被复现并定位到FlashAttention-2的一个边界case：当序列中存在连续多个U+2060（Word Joiner）或U+FEFF（BOM）类控制符时，动态padding逻辑可能引入微小的内存对齐偏移，进而扰动位置编码的相对距离建模。

验证路径：三步闭环确认无隐私风险

1. 调取全量日志审计：确认所有受影响请求均未触发任何跨session的context reuse逻辑，所有输出生成均基于当前请求的独立KV Cache；

2. 抽样回溯测试：对过去72小时内全部报障案例做输入-输出映射反向追踪，100%确认无原始query片段被直接复制或拼接至他人响应；

3. 沙箱隔离重放：在离线环境中构造含57类非常规Unicode组合的测试集，验证漏洞仅在单次推理链路内发生，不具传播性与持久性。

需要注意，该BUG不会导致训练数据泄露，也不涉及任何用户身份标识（UID、IP、设备指纹）的混淆。DeepSeek明确表示，其服务端严格遵循“请求即销毁”原则：每个HTTP请求生命周期结束后，对应的所有中间状态（包括logits、attention weights、hidden states）均被立即清零，不存在任何形式的跨请求残留。

修复方案：从Tokenizer层切入，而非简单过滤字符

团队并未采用粗暴的字符黑名单策略，因为这会误伤合法用途（如学术论文中的IPA音标、古籍OCR后的异体字标记）。实际修复包含两个层面：

① 在tokenizer预处理阶段增加Unicode规范化层（NFC→NFD→NFC），强制将组合字符展开为标准序列；

② 修改FlashAttention内核，在计算前插入轻量级边界校验，当检测到连续控制符密度超过阈值（>3个/128token）时，自动启用冗余padding对齐模式，牺牲约0.8%吞吐率换取状态稳定性。

目前补丁已部署至全部生产集群，灰度验证周期为48小时，错误率从初始0.023%降至0.0001%以下。用户无需主动操作，旧有API调用方式、参数格式、返回结构均保持完全兼容。

给开发者的实操建议

若你正在集成DeepSeek API并处理多语言混合文本：

1. 建议在发送请求前对input字符串执行unicodedata.normalize('NFC', text)，尤其注意处理从PDF、网页爬虫、OCR引擎获取的原始文本；

2. 避免手动拼接U+200B（零宽空格）、U+2063（无形分隔符）等非显示字符用于“隐藏提示词”，这类技巧在v3模型中已失效且易触发异常；

3. 对于需要高确定性的工业级应用，可启用strict_mode参数（即将上线），该模式下服务端将主动拒绝含非常规控制符的请求，并返回标准化错误码及清洗建议。

以上是DeepSeek针对此次特殊字符引发模型幻觉事件的技术解析与应对细节，希望对你有所帮助。