论问责制
摘要
一篇关于软件工程和大型语言模型开发中缺乏问责制的反思文章,源自ICST 2024的一个主旨演讲,该演讲呼吁应像其他工程领域一样承担责任。
<p><a href="https://lobste.rs/s/mwelmm/on_accountability">评论</a></p>
查看缓存全文
缓存时间: 2026/07/24 04:58
# 论问责 · Addison Crump
来源:https://addisoncrump.info/research/on-accountability/
2024年,我参加了多伦多的ICST会议。我去参加了首届"软件测试中的人工智能"研讨会(AIST),在那里我介绍了一个可能的竞赛,并参与了一场关于该领域的小组讨论(后来变成了圆桌讨论)。当时我们主要关注的是大语言模型,有两个突出疑问:"我们如何可靠地研究这个?"以及"我们能合理预期从中得到多少?"
以前访问过的读者会知道,至少可以说,我并不是LLM的最大粉丝。反对它的许多论点已经让人厌倦到需要反复重复,而我也厌倦了重复它们。早在2024年,这些危害的规模尚未被充分理解,因此小组讨论主要关注的是我们实际上无法研究LLM本身,而只能研究其应用的可行性。关于有效性的任何实证结果都无法泛化,任何事情都可以通过简单声称研究针对了错误目标或以错误方式应用来否认(无论是支持还是反对LLM)。
具有讽刺意味的是,虽然我参加ICST是为了参加AIST,但它对我而言并不是会议中最有影响力的部分。这个头衔属于主会议轨道的第二场主题演讲——Mike Hoye的"我们建造了我们所衡量的世界"。讽刺的是,这场主题演讲主要不是关于衡量,而是关于其后果。演讲者谴责了行业对客户福祉的完全漠视,以及软件公司缺乏问责制。最终,他呼吁软件工程中的问责制,类似于其他工程领域已经实施的措施,这一切都基于一个简单的事实:软件在我们的日常生活中太过核心,后果也太过重大。
我几乎不记得我参加的那个研讨会了,但我记得我在主题演讲时坐的位置、具体的幻灯片、房间的形状、观众全神贯注的安静状态,以及之后我与演讲者简短的交谈。*我还*记得两位谷歌工程师(一位高级,一位初级)——相当强硬地——加入了对话,声称问责是有毒的,与软件开发自由背道而驰。我记得他说这话时脸上的得意神情,以及他声称这点的确定性,以及他除了重复这个主张本身或主题演讲中已经提及的借口之外,无法证明这一说法。
当时,我只觉得这令人愤怒。这是一种典型的自我暴露,表明他们想逃避对自己开发的软件的责任,而明明知道人们依赖它。现在,我在LLM的背景下记起了这件事。
我们的行业被这样一种想法毒害得太深:同意是可选的;责任是可以被免责声明中的限制所打发的东西;疏忽可以以进步的名义被原谅;功能比稳定性更有价值;可用性次于可商业化;不知何故,没有哪一种金钱收益小到可以忽视对用户的侮辱。公司对其创建和分发的软件不负责任的想法普遍存在并被正常化,而人们的生活却围绕着程序按预期运行,往往没有替代方案。
这些天我越来越多地回想起那场主题演讲的思想。对于许多人来说,LLM催生了程序开发方式的激进转变——大多数情况下是变得更糟。现在,正是那些几十年来一直逃避其程序后果责任的同一批公司,正在使用这些工具以牺牲可维护性、理解和问责性为代价来增加代码产出。
任何程序员都可以用LLM生成能够完成可商业化任务的代码。我看到我们的领域从一个已经有问责问题的地方转变为一个根本没有问责的地方。我看到这样一个世界:个体程序员——也许在历史上对他们所从事的工作有足够的投入以确保其质量——变得与他们负责的代码脱节,被分配到巨大的工作量,这些工作量只能通过减少关心并更多地依赖代码生成器来完成。而这些相同的程序员在出现问题时会被"问责"——通过被替换的方式;毕竟,既然几乎任何程序员都能操作实际生成代码的工具,我们就变得更容易被舍弃、更容易被替换。对我来说,当然也对那些真正从软件商业化中受益的人来说,这个开发者听起来像一个完美的替罪羊,可以为那些危害负责而不让系统或真正导致这些危害的人承担后果。
在传统工程领域,当某件事造成伤害时,公司会面临严厉的处罚,并且会进行适当的调查以确定失败的原因。很少有仅仅因为个人失误造成的,而是因为导致它的系统性失误。当软件工程中造成伤害时,公司完全放弃责任,很少面临任何后果,如果有任何事发生来"问责"某个人,最常见的就是解雇相关的程序员。而现在,我们正在进入一个范式,开发者既被鼓励也被期望不为自己的工作感到负责;尽可能多地将责任推给一个工具。也许有一天,我们进入一个范式,产品设计师直接生成代码,完全不需要程序员参与;没有人感到任何个人责任,也没有人为任何失败单独负责。它变成了"本来就是这样";软件被期望失败,即使对用户来说是关键的。诚然,对于许多用户来说,我们已经感觉身处其中了。唯一的区别是,也许曾经有一段时间,那家公司雇佣了一些对代码按预期工作感到个人自豪或负有责任的人。
创建和分发人们依赖的软件的公司必须被追究责任。长期以来,它们一直需要被问责。软件之所以还能保持一定可用性,是因为这些公司的程序员在追求实际质量,但功能失调已经成为常态——而且已经持续了好几年。用户*现在*正在因疏忽行为而受苦,而软件正在退化以及未来会退化的程度几乎难以想象。而公司只是耸耸肩。
没有真正的问责,我只能想象它会变得更糟。
相似文章
LLM编码时代的软件工程最佳实践
一篇讨论软件工程最佳实践如何随着LLM编码工具的整合而发展的文章,为开发者提供指导。
代码成本崩溃后的工程管理
一位工程总监反思了LLMs导致代码生产成本崩溃如何动摇了传统管理假设,主张根据底层假设而非年代来审计实践。
@_avichawla: https://x.com/_avichawla/status/2053049489963811135
本文概述了2026年大语言模型(LLM)工程的路线图,详细阐述了包括提示词工程、RAG系统、上下文管理在内的八大关键支柱,并为每项支柱提供了精选的免费及开源资源。
引用Kyle Kingsbury
Kyle Kingsbury讨论了机器学习系统中人类问责的新兴角色,包括内容审核员、法律代表和合规官员,这些人可能对AI系统的故障承担责任。
Martin Fowler:技术债、认知债与意图债
Martin Fowler 反思 AI 对代码质量的影响,指出人类的“懒惰”反而促成清晰抽象,而 LLM 则可能用不必要的复杂性把系统拖胖。