Shell 中的假朋友:揭示大语言模型的表情符号语义混淆
False Friends in the Shell: Unveiling the Emoticon Semantic Confusion in Large Language Models
作者报告六种LLM在3,757条测试上的平均CR为38.6%。
- ASCII表情与代码符号重叠。作者指出,用户会把表情符号带入编程助手对话,模型可能把语气符号当成可执行指令,从而在代码生成和智能体执行中做出偏离意图的操作。
- 作者用两模块流水线筛选真实且与代码符号重叠的表情,再由Claude-Sonnet-4.5生成带末尾占位符的对话,GPT-5.1核验后按重叠分数注入,得到3,757条、21个元场景、4种语言、3档上下文的测试。
- 六模型平均CR为38.6%。Level 2中High Harm占52.0%。GPT-4.1-mini上105条已混淆提示迁到LangChain、CAMEL后,仍有76.2%和67.6%触发。210条子集上提示方法未在六模型一致降低CR。
- Limitation称数据集不能覆盖全部交互边界,六模型结果未必推广到全部LLM。Discussion计划扩展到非代码场景、研究恶意利用和开发者侧确认。实验做到六模型、3,757条、两种智能体框架和210条提示子集。
- 被测模型
- Claude-Haiku-4.5Gemini-2.5-FlashGPT-4.1-miniDeepSeek-v3.2Qwen3-CoderGLM-4.6
- 基准
- 自建代码向测试集(3,757条,21个元场景)LangChainCAMEL
- 指标
- Confusion Ratio (CR)Confusion Impact Ratio (CIR)
研究者发现大语言模型存在表情符号语义混淆漏洞,模型会误读 ASCII 表情符号,执行非预期甚至破坏性的操作。他们构建了包含 3757 条面向代码的测试用例数据集,覆盖 21 个元场景、四种编程语言和不同上下文复杂度。在六个大语言模型上的测试显示,该问题普遍存在,平均混淆率超过 38%;超过 90% 的混淆回答属于静默失败,即语法有效但偏离用户意图。研究还发现该漏洞会迁移到流行的 Agent 框架,而现有的基于提示词的缓解措施基本无效。
深度解读
这篇论文试图解决什么问题?
作者定义表情符号语义混淆:LLM把ASCII表情当成可执行代码或命令。
LLM会把用户用来表示语气的ASCII表情理解成可执行代码或命令。
- 出现场景: 作者称表情符号用于传达情感,用户会把这一习惯带入编程助手;附录A.1的60名参与者中有14人(23.3%)在编程任务里用过。作者认为意图偏差可能影响交互效率,并可能关系到系统安全。
- 现有不足: 作者称既有鲁棒性研究主要考察Unicode emoji或无意义字符扰动,用于越狱或情感操纵。作者称据其所知,尚无工作系统研究ASCII表情在代码生成中的句法歧义及其安全影响。
- 核心观察: ASCII表情与运算符、shell通配符和文件路径共用字符。作者用假朋友(false friend)描述同一符号在自然语言与编程语言中语义不同,模型可能把语气标记当成操作对象。
- 本文做法: 作者定义表情符号语义混淆(emoticon semantic confusion),用自动流水线构造3,757条、21个元场景的代码向测试,并在六个LLM上测量其普遍程度、后果和用户侧提示词缓解。
有哪些相关研究?
作者把本文与Unicode表情越狱研究区分,并称此前没有系统研究代码场景中的ASCII表情混淆。
论文在引言和Related Work中把相关工作分成三组,只对Unicode emoji红队工作写出了与本文的差别。
非言语线索
- 情感与流行度: Evans(2017)、Boutet等人(2021)讨论emoji和表情符号传达情感、语气和反讽;Tauch和Kanjo(2016)、Ai等人(2017)讨论其在通知和流行度中的作用。论文未与这些工作做方法对比。
- 技术社区: Kwon等人(2019)、Kralj Novak等人(2015)研究表情或颜文字表示;Lu等人(2018)、Rong等人(2022)报告GitHub和软件开发交流中的emoji使用。论文将其作为使用背景。
LLM鲁棒性测试
- 对抗与红队: 作者把Jiang等人(2025)、Xiao等人(2025)、He等人(2025)、Ge等人(2024)的MART,以及Zou等人(2023)归为发现对话系统在对抗指令下产生有害内容的研究。论文未逐篇指出这些方法的不足。
非言语线索用于红队
- Unicode emoji扰动: Wei等人(2025)、Zheng等人(2025)、Ma等人(2024)把emoji用作绕过安全过滤或操纵情感分类的扰动。作者称这些工作主要把Unicode emoji用于恶意越狱或对抗攻击,而本文研究的是良性使用中ASCII表情被当成功能代码或命令。
基线方法与基准
- 对照设置: 直接提问(Base)、Zero-shot CoT(Kojima等人,2022)、ReAct(Yao等人,2022),以及作者设计的System Instruction。评测用自建3,757条测试;提示词对比用其中210条子集(Table 1)。附录A.4.5还列出Self-refine(Madaan等人,2023),Table 1未报告其结果。
作者把本文定位为代码场景中ASCII表情的语义错位研究,并称这是对该现象的首次大规模实证研究。
论文如何解决这个问题?
两模块流水线筛选与代码重叠的真实表情,生成并注入提示,建成3,757条测试。
作者用数据生成流水线自动构造代码向对话,再以输出是否功能等价于参考答案判定混淆。流水线含表情收集和提示生成两个模块(Figure 2)。
问题设定
- 混淆所指: 模型把ASCII表情理解成可执行指令,输出与用户意图不一致的操作。作者对比Unicode emoji:后者有独立编码,前者由标准字符和标点构成。
- 为何从代码进入: 作者给出两点:代码符号与表情重叠多;编程LLM和智能体常能执行命令、修改文件系统,误读可能造成数据丢失或系统瘫痪。
- 样本形式: 实例化样本为 D=(H, xn, y)。H是此前对话,xn是最后一轮查询,y是期望参考响应。注入后的查询记为 x′n = xn[ϕ → e],只替换末尾占位符,y不变。
表情符号收集
- 两条标准: Prevalence要求候选来自真实使用,而不是人造模式;Overlap要求与编程语言共享符号或结构。
- 筛选: 以Ekohrt(2022)约62,000条公开表情初始化,面向Bash/Shell、Python、SQL和JavaScript做符号约束过滤,再用结构模式匹配计算overlap score。该模块保留20,522个候选。
- 抽查: 两名具有AI和软件工程背景的专家抽查1,000个候选,指南是在线社区可核验的真实表情,以及至少在一种目标语言中形态上与合法代码语法分不清。作者称两名专家认为抽查样本全部符合指南。
提示词生成
- Stage 1: 人工设计21个元场景,覆盖文件与目录操作、数据库修改、系统管理和代码编辑,并在四种语言上实例化(Table 2)。Claude-Sonnet-4.5生成对话,占位符放在查询末尾,同时输出符号约束 Rsym。附录亦写作Claude-4.5-Sonnet。
- 三档上下文: Single Turn为 n=1且无历史;Multi Turn Without Prior的历史与 Rsym 所指符号无语义关联;Multi Turn With Prior的历史对象或状态与这些符号语义耦合。
- 核验与注入: GPT-5.1检查历史、查询和期望输出是否逻辑一致。附录称先生成315个模板(21×5×3),保留263个。Stage 2按overlap score加权抽样,每个实例最多 K=10 个表情。附录给出了生成与核验提示词。
混淆判定
- 是否混淆: 用正则抽取命令或代码,再做功能等价判断,与参考答案 G 比较。只有功能不等价计入混淆。语法检查、拒答检测和精确匹配的实现在附录A.3.2。
- 严重度: Level 1是不可执行、可由语法检查发现的失败;Level 2是作者所称 silent failure,即语法合法但语义错误。后果分析另把Level 2分为High Harm与Low Harm,由Gemini-3-Flash判断。
论文做了哪些实验?
六模型全量平均CR为38.6%;作者称提示词方法不能在全部模型上一致降低CR。
实验设置
- 被测模型: Claude-Haiku-4.5、Gemini-2.5-Flash、GPT-4.1-mini、DeepSeek-v3.2、Qwen3-Coder、GLM-4.6。附录A.3.1写明走官方或SiliconFlow API、使用默认参数;Qwen3-Coder在附录中对应Qwen3-Coder-480B-A35B-Instruct。
- 数据与重复: 3,757条测试,21个元场景,Bash/Shell、Python、SQL、JavaScript,三档上下文。每条提示每模型查询5次,每模型18,785条,合计112,710条。
- 指标: CR是功能不等价于参考答案的响应占比。CIR把混淆分为Level 1和Level 2。作者称计算时有放回重采样到1,000,并用t-test等做检验;正文未给出p值。
- 评审: Gemini-3-Flash判断功能等价,以及Level 2相对参考答案属于High Harm还是Low Harm。附录A.3.3对100条做人工核验,Cohen's Kappa为0.94。
- 智能体: LangChain使用默认系统指令,CAMEL使用其代码任务模板,骨干都是GPT-4.1-mini。每个场景抽5条、共105条,且这些提示已知会在该骨干上触发混淆。
- 缓解子集: 每场景抽10条、共210条,比较Base、Zero-shot CoT、ReAct、System Instruction(Table 1)。
主结果
摘要写平均混淆比例超过38%,引言写超过38.6%,§4.2写平均CR为38.6%。正文只点名三个模型的全量CR。Figure 3还标有40.2%、38.7%、38.1%,转换文本无法对应到模型,故写未报告。Figure 3图注写Confusion Rate,正文指标名是Confusion Ratio。
模型 全量CR 出处 Claude-Haiku-4.5 34.2% §4.2、Figure 3 Qwen3-Coder 36.5% §4.2 GLM-4.6 43.8% §4.2、Figure 3 GPT-4.1-mini 未报告 正文未逐模型给出 Gemini-2.5-Flash 未报告 正文未逐模型给出 DeepSeek-v3.2 未报告 正文未逐模型给出 - 作者解读: 作者称六个模型都出现混淆。作者观察到Claude-Haiku-4.5与Qwen3-Coder更常先向用户确认,并称这与二者较低的CR有关;GLM-4.6的CR为43.8%。
- 拒答: 全量拒答486条,占0.4%。附录称其中Claude-Haiku-4.5为389条(80.0%),其余五模型合计不到20%。
- 标注构成: 附录Figure 6称68,750条(61.0%)正确;可执行误读占全部响应35.0%,其中High Harm 20,552条(18.2%)、Low Harm 18,984条(16.8%);非法语法3,938条(3.5%)。
场景、上下文与迁移
- 场景占比: Figure 8是混淆案例在21个场景中的占比,不是场景级CR。作者称文件删除与清理在六个模型上都最高,从GLM的14.8%到Claude的18.6%;附录称该场景平均16.9%。多行命令块为13.2%–16.4%。作者认为高风险、句法复杂的场景更易混淆。
- 上下文: 作者给出的区间是单轮43.2%–49.1%,无先验多轮27.1%–31.6%,有先验多轮22.4%–26.2%(Figure 4、§4.2)。作者认为上下文越丰富,混淆越少;单轮缺少任务上下文时,模型更依赖预训练先验把符号当成语法。
- 智能体: 这105条提示迁到LangChain后76.2%(80/105)、CAMEL后67.6%(71/105)仍触发错误或不安全行为。作者称框架中的推理、规划与工具使用没有纠正底层误读。
后果与提示词缓解
- Level 2: 摘要称超过90%的混淆响应是silent failure。§4.3称六个模型中五个的Level 2超过91.0%,Claude超过95.0%。Figure 5标注的Level 2为90.7%、95.5%、92.4%、86.8%、88.1%、92.2%,Level 1为9.3%、4.5%、7.6%、13.2%、11.9%、7.8%;转换文本未对应到模型,其中三个Level 2低于91.0%,与§4.3的概括不完全一致。
- High Harm: 作者称Level 2中52.0%属于High Harm(附录:20,552/39,536),即相对用户意图引入额外风险;其余为Low Harm。作者称High Harm输出语法合法、可执行,常规静态分析难以发现。
- 提示方法: Table 1来自210条子集,不能与全量CR直接对比。作者称System Instruction在GPT、Gemini、DeepSeek、Qwen上降幅最明显,CR分别为38.6%、35.2%、39.8%、40.7%。同一方法在GLM上为52.6%,高于该子集Base的49.0%。Claude上Base为40.1%,CoT、ReAct、System分别为43.2%、42.4%、42.5%,都更高。作者称没有一种提示策略在六个模型上一致降低CR,并认为混淆可能来自表示与符号落地,表层提示只能弱影响。
其他消融与分析
- 附录A.4.1:S12动态代码执行的混淆案例占比为0.3%–0.8%;S16配置注释为0.6%–1.8%;S18容器生命周期在DeepSeek上为0.0%、Qwen3-Coder上为0.1%、Gemini-2.5-Flash上为3.3%。
- 附录A.4.4用单轮、有先验多轮和无先验多轮案例说明表情字符串会被写入命令参数;附录给出了示例。
- 论文未报告t-test的p值,也未报告各提示方法的查询次数;附录A.3.4写全部实验API费用约500美元。
- 附录A.4.5列出Self-refine,Table 1未报告其CR。
有什么可以进一步探索的点?
作者写明数据集不能覆盖全部交互,六模型结果未必推广,并列出后续方向。
作者指出的局限与后续方向
- 数据集: Limitation称,尽管有21个元场景和三档复杂度,真实交互的变化意味着数据集不能覆盖表情用法或交互上下文的每一个边界情况。作者称已开源流水线,供他人扩展场景和表情符号。
- 模型: Limitation称评测了六个来自主要提供方的LLM,但模型变化快,结果未必推广到所有可用模型。作者称已开源数据集,并鼓励用它评测更多LLM和智能体。
- 评测框架: Discussion称本数据集主要聚焦编程场景,风险可能超出代码。后续可建更广的基准和自动化测试框架,例如基于metamorphic testing,覆盖更多智能体、低资源编程语言和多种自然语言。
- 攻击与红队: Discussion把恶意利用列为后续方向,包括与已有提示注入或红队方法结合,以及如何更好地防御。论文未在该节给出具体攻击方法。
- 开发者侧缓解: Discussion称用户侧提示只有边际改进。后续可研究解耦技术嵌入与情感嵌入,或实现主动确认;作者认为检测潜在歧义并请求用户确认,可以是生产环境中的一种缓解机制。
实验覆盖范围
- 被测模型为Claude-Haiku-4.5、Gemini-2.5-Flash、GPT-4.1-mini、DeepSeek-v3.2、Qwen3-Coder、GLM-4.6,共6个;每条提示每模型查询5次(§4.1)。
- 测试集为3,757条,21个元场景,4种编程语言,3档上下文(§3)。
- 智能体实验使用LangChain和CAMEL,骨干为GPT-4.1-mini,提示105条,且这些提示已知会在该骨干上触发混淆(§4.2)。
- 提示词对比在210条子集上比较Base、Zero-shot CoT、ReAct、System Instruction(Table 1)。功能等价与危害分类使用Gemini-3-Flash;另有100条人工一致性,Cohen's Kappa为0.94(附录A.3.3)。
- 论文写明bootstrap到1,000并举例t-test,但未报告p值;也未报告各提示方法的查询次数(§4.1、附录A.4.5)。
总结一下论文的主要内容
作者报告六种LLM会把ASCII表情误当成代码,全量平均CR为38.6%,提示缓解并不一致。
作者测量六个LLM上的表情符号语义混淆:ASCII表情与代码符号重叠时,模型可能把语气标记当成可执行对象。
- 问题: 编程助手对话中,用户用表情缓和语气,模型却可能把同一字符理解成路径、通配符或操作数。作者称这会带来自主执行中的安全隐患、反复纠正带来的可用性下降,以及把恶意载荷藏进情感线索的攻击面。
- 做法: 从约62,000条真实表情中筛出与四种语言重叠的候选,由Claude-Sonnet-4.5生成末尾带占位符的对话,GPT-5.1核验后按重叠分数注入,得到3,757条测试。混淆定义为输出与参考答案功能不等价。
- 主要数字: 六模型平均CR为38.6%。正文点名的全量CR中,Claude-Haiku-4.5为34.2%,Qwen3-Coder为36.5%,GLM-4.6为43.8%。作者给出的上下文区间是单轮43.2%–49.1%、有先验多轮22.4%–26.2%。Level 2中High Harm占52.0%。以GPT-4.1-mini为骨干时,105条已知混淆提示在LangChain、CAMEL上仍有76.2%和67.6%触发。
- 缓解与结论: 210条子集上,没有一种提示方法在六个模型上一致降低CR;GLM上System Instruction为52.6%,高于该子集Base的49.0%。摘要称超过90%的混淆响应是silent failure,§4.3称五个模型的Level 2超过91.0%、Claude超过95.0%,但Figure 5有三个Level 2数字低于91.0%且未可靠对应到模型。作者呼吁社区重视该问题,并开发有效缓解方法。