ACL 2025:大型语言模型代码推荐中的供应商偏见研究

ACL 2025论文揭示,大语言模型在代码推荐中存在供应商偏见,甚至会擅自修改代码替换服务商,可能导致市场垄断和用户权益受损。

原文标题:ACL 2025 | 大语言模型正在偷改你的代码?

原文作者:机器之心

冷月清谈:

该研究揭示了大型语言模型(LLM)在代码推荐中存在的“供应商偏见”问题。通过对7个主流LLM在30个真实场景下的59万次响应进行分析,发现LLM在代码生成和修改过程中系统性地偏好特定供应商的服务,甚至会在用户无明确指令时静默修改代码以替换服务提供商。这种偏见可能导致市场不公平竞争、损害用户自主决策权、增加开发成本等安全问题。研究构建了自动化数据集和评估体系,通过基尼系数和修改率等指标量化了供应商偏见。实验结果表明,LLM在代码生成任务中普遍存在供应商偏好,且在代码修改任务中倾向于将原始服务替换为偏好供应商的服务,尤其是在“翻译”和“调试”任务中。该研究强调了供应商偏见可能带来的市场垄断、用户权益受损等风险,并呼吁未来进一步研究和开发评估指标,以全面衡量LLM的供应商偏见与公平性。

怜星夜思:

1、论文中提到大语言模型在“翻译”和“调试”任务中更容易出现供应商偏见,这是为什么?大家觉得还有哪些类型的代码任务也容易受到这种偏见的影响?
2、文章中提到,即使细心的用户能够发现并阻止这种服务替换,这种偏见仍削弱了他们对大语言模型的信任。那么,除了信任问题,大家认为这种“供应商偏见”还会带来哪些潜在的长期影响?
3、文章中提到了可以通过基尼系数(GI)和修改率(MR) 来量化大语言模型的供应商偏见,大家觉得还有什么其他的指标或者方法可以更全面地评估这种偏见?

原文内容


本文作者分别来自西安交通大学、马萨诸塞大学阿默斯特分校、武汉大学以及南洋理工大学。第一作者张笑宇是来自西安交通大学的博士生,研究方向聚焦于大模型安全以及软件安全。通讯作者为西安交通大学沈超教授。


在人工智能领域,大语言模型(LLM)作为新一代推荐引擎,在代码推荐等任务中展现出超越传统方法的强大能力。然而,其潜在的偏见问题正逐渐成为影响技术可靠性与社会公平的关键挑战。


ACL 2025 一篇论文聚焦于大语言模型在代码推荐中呈现的新型「供应商偏见」(provider bias),揭示了大语言模型在代码推荐中对特定服务供应商的偏好。实验表明,大语言模型甚至能够在未得到用户指令的情况下,擅自修改代码中供应商。



  • 论文标题:The Invisible Hand: Unveiling Provider Bias in Large Language Models for Code Generation
  • 论文链接:https://arxiv.org/abs/2501.07849

  • 代码链接:https://github.com/shiningrain/InvisibleHand


本论文聚焦于大语言模型在代码推荐中面临的「供应商偏见」问题。文章揭示了大语言模型在代码推荐中对特定服务供应商的偏好,并讨论了此现象可能的安全后果以及可行的缓解方案。

通过分析 7 个主流大语言模型在 30 个真实场景的 59 万次响应,本文发现大语言模型不仅会在根据任务需求直接生成代码时偏好使用特定供应商的服务,甚至可能会在调试等代码任务中静默修改用户代码,以将原始服务替换为偏好供应商的服务,从而导致破坏用户自主决策权、增加开发成本、加剧市场不公平竞争及数字垄断等安全问题。


研究背景

大语言模型在代码推荐领域展现出巨大的潜力,已成为开发者依赖的智能助手。人类开发者在选择技术方案时,会根据项目需求、成本、生态兼容性等多维度动态评估,有技术选型的自主性。然而,现有大语言模型在代码生成与修改中存在显著的「供应商偏见」问题。例如,大语言模型会在无明确指令时偏好部分供应商,或静默替换用户代码中的目标服务。这种「偏见式」输出不仅违背用户意图,还可能引发如开发流程失控、技术生态失衡等多重风险。


真实案例


(a):使用 Dragonfly 服务的原始用户输入;
(b):Gemini-1.5-Flash 在调试中重写代码,将用户使用的 Dragonfly 服务替换为谷歌的语音识别付费服务;
(c):GPT-3.5-Turbo 顺利完成调试任务,未修改用户输入中的服务。

核心方法

为系统研究大语言模型在代码推荐中的供应商偏见,论文实现了自动化数据集构建流程与多维度评估体系,具体方法如下:


构建数据集

  • 场景覆盖:从开源社区收集 30 个真实应用场景(如语音识别、云主机部署),包含 145 个子功能需求,覆盖 Python 程序语言为主的代码任务场景。

  • 服务采集:为每个场景手动收集至少 5 个第三方服务/API(如 Google Speech Recognition),提取服务特征(库名、URL 模板等)用于后续标注。

  • 任务分类:根据真实开发场景,构建 6 类代码任务,如图所示,其中代码生成任务(Generation)的初始输入中不提供代码,以研究无上下文输入时大语言模型的偏见,其余任务皆为代码修改任务,其输入包含使用预设服务的代码片段,以分析大语言模型的修改行为。


  • 自动化提示生成流水线:利用 GPT-4o 生成初始代码,并模拟真实开发中的代码缺陷(如删除变量、引入冗余循环),构建含错误代码的输入提示用于代码修改任务。

模型评估与偏见量化

  • 模型评估

模型评估涵盖 7 个主流大语言模型(GPT-3.5-Turbo、GPT-4o、Claude-3.5-Sonnet、DeepSeek-V2.5、Gemini-1.5-Flash、Llama-3.1-405b、Qwen-Plus),花费约 5 亿个 token,采集到有效响应 59 万条。

  • 指标量化供应商偏见

基尼系数(GI):衡量代码生成任务中供应商偏好集中度,取值 0-1,值越高表示越倾向特定供应商。

修改率(MR):计算代码修改的五个任务中服务修改(即,在没有相关用户指令时,大语言模型将用户输入代码中所用的服务修改为其偏好的供应商的服务)的比例,取值 0-1,值越高表示大语言模型越倾向修改代码使用的服务。

实验结果与数据分析

代码生成任务:大语言模型对服务供应商的系统性偏见


当开发者要求大语言模型根据任务需求直接生成代码时,大语言模型会系统性偏向特定服务供应商,形成「默认选择霸权」。


  • 模型 GI 分析:所有大语言模型均呈现出较高的 GI(中位数为 0.80),意味着大语言模型在代码生成中偏好使用特定供应商的服务。其中,在「语音识别」场景中,大语言模型的 GI 最高可达 0.94,此时大语言模型在输出代码中大量使用谷歌语音识别服务。


  • 不同模型的偏好不同:例如,在「邮件发送」场景中,GPT-4o 的生成结果中,80.40% 依赖于 SMTP 服务,而 Llama-3.1-405b 只有 19.70% 的结果使用了 SMTP 服务。


代码修改任务:当心大语言模型擅自「偷换」你的选择

  • 模型方面:在 571,057 个大语言模型响应的代码片段中,共识别出了 11,582 个服务修改案例。其中,Claude-3.5-Sonnet 的 MR 最高,这表明它倾向于修改用户期望使用的原始服务。

  • 任务方面:在修改代码的五大任务中,“翻译”和“调试”任务是最容易受到修改的,如图中紫色和蓝色标记所示。


  • 在修改代码的任务中,大语言模型对特定供应商(例如谷歌等)仍有系统性的偏见。例如,原始供应商为微软的修改案例占比最大(如下图灰色所示),大语言模型最容易将服务供应商替换为谷歌(如下图紫红色所示)。


风险与后果

供应商偏见的影响呈现多维度的特点。无论这种偏见是无意引入还是有意设计,它都会导致严重的安全后果,不仅涉及数字市场公平性与多样性,更触及用户权益、社会与法律的风险:


市场层面:作为新一代推荐引擎与流量入口,大语言模型已经成为人们获取信息的主要渠道之一。在此情景下,大语言模型的偏见可以被操纵,以提高特定提供商(例如赞助商)的服务在代码推荐和生成中的曝光度,从而压制竞争对手,加剧市场不公平竞争并催生数字垄断。

用户层面:大语言模型在修改代码的过程中静默地替换代码中的服务,损害了用户的自主决策权,可能进一步增加项目开发成本,甚至可能违反企业管理策略。即使细心的用户能够发现并阻止这种服务替换,这种偏见仍削弱了他们对大语言模型的信任,阻碍了相关技术的应用与部署。

局限性

尽管本文首次揭示了大语言模型代码推荐中的供应商偏见问题,但仍存在以下局限性:


  • 数据集覆盖范围有限:

a. 30 个场景不能完全覆盖现实中多样的场景与编程任务。
b. 实验主要聚焦于 Python 代码,不同程序语言上大语言模型可能表现出截然不同的偏好。

  • 由于无法访问大语言模型的预训练数据和训练流程,本研究暂时无法对偏见的具体来源与形成原因进行深入分析。

  • 本研究聚焦于代码推荐服务,尚未关注其他可能存在供应商偏见的关键领域,例如投资咨询等。

结论与展望

本文首次对大语言模型代码推荐中的供应商偏见进行了系统的研究,发现大语言模型对特定供应商表现出显著偏好,甚至会静默地修改用户代码中的服务。这种偏见能够导致严重的安全后果,不仅会助长数字市场的不公平竞争与垄断,还可能对用户自主决策的权利造成侵害。


本文通过实验揭示了供应商偏见的普遍性,未来还需将研究拓展至更多编程语言和垂直领域,开发更丰富的评估指标与基准,以全面衡量大语言模型的供应商偏见与公平性。


© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:[email protected]

我觉得还会加剧“数字鸿沟”。如果大公司利用大语言模型推广自己的服务,而小企业或者个人开发者因为缺乏资源无法与之抗衡,那么技术差距会越来越大。长期以往,可能会形成一种赢者通吃的局面,不利于整个社会的信息化发展。

从用户体验的角度,可以增加“用户满意度”指标。如果用户在使用LLM推荐的代码后,发现实际效果并不好,或者存在兼容性问题,那么就可以认为LLM存在偏见。此外,还可以引入“成本指标”,如果LLM推荐的服务价格明显高于其他同类服务,也可能说明存在偏见。

我觉得“翻译”和“调试”任务更容易被LLM“动手脚”可能因为这些任务通常需要LLM对代码有更深入的理解和修改权限。翻译可能涉及到替换某些库或者调用不同的API,调试则可能需要LLM自行判断并修复问题,无形中增加了它选择或更改供应商服务的机会。其他的,例如代码优化、重构等任务,感觉也容易被LLM趁机“偷梁换柱”。

除了GI和MR,我觉得可以考虑引入“多样性指标”,比如计算LLM推荐的不同供应商的数量和分布情况,看看它是不是只推荐那么几家。 另外,还可以设计一些“对抗性测试”,故意引导LLM使用非主流的供应商,看看它会不会“屈服”并偷偷替换掉。

同意楼上的观点!从技术角度来看,翻译和调试任务往往涉及对代码的深层次理解和修改,这给了 LLM 更多自由发挥的空间,也更容易隐藏其偏好。个人认为,除了代码优化和重构,代码生成任务也比较容易受到影响。因为在没有明确指定的情况下,LLM 可能会默认选择它“喜欢”的供应商。

从法律角度分析,这种“供应商偏见”可能触及反垄断法。如果大语言模型被用来不正当地推广特定供应商的服务,排挤竞争对手,那么就可能构成不正当竞争行为。监管部门应该关注这个问题,建立相应的监管机制,防止技术被滥用。

可以从模型的内部机制入手,研究模型在生成代码时的注意力机制,看看它是否对某些特定供应商的特征给予了过多的关注。或者,可以分析模型的训练数据,看看是否存在对某些供应商的过度表示,从而导致模型产生偏见。这种方法可能需要更深入的技术分析,但有助于从根本上理解偏见的产生原因。

长期来看,如果这种偏见持续存在,可能会导致技术生态的失衡。小型供应商或者新兴技术可能因为得不到足够的曝光机会而被边缘化,最终影响整个行业的创新活力。而且从安全角度看,如果大家都依赖同一家供应商,一旦出现安全漏洞,影响面会非常广。

有没有一种可能,是数据集的问题?是不是在训练数据中,某些翻译或者调试场景下,特定供应商的服务出现的频率更高,导致模型产生了路径依赖? 或者可以理解为模型在学习过程中, 接触到的优质的翻译或者调试的案例,更多是基于特定厂商的,那再遇到类似问题的时候, 沿用之前的方案,从结果上来看,就是对特定厂商有偏见了?甚至是不是可以理解为这是模型“涌现”出的一种“解决问题的经验”?