开发者是保护代码道德的最后防线？_语言 & 开发_Anne Currie

【AICon】如何构建高效的 RAG 系统？RAG 技术在实际应用中遇到的挑战及应对策略？>>> 了解详情 



 写点什么

关键要点

我们可以将技术道德定义为发现 IT 系统可能出现的问题（如个人或团体的劣势或伤害），并采取切实步骤避免这些问题。

对于开发人员来说，合乎道德行事的关键是要保护人们免受软件系统给我们带来的危害。

复杂的道德问题，比如避免使用有偏见的机器学习训练数据或让用户免于政治操纵，这些都是普通职业行为的延伸。

作为工程师，我们有权力有所保留，但这对于推动变革来说作用不大。

我们正在制定一些简单的清单和流程来支持道德决策，可以在 GitHub 上获得它们。

3 月份，Stack Overflow 发布了他们的 2018 年开发者调查报告，并首次提出了有关道德的问题。对于“开发人员是否有义务考虑代码的道德影响”这个问题，有近 80％的人回答“是”。不过，只有 20％的人认为他们最终在为不道德的代码负责，40％的人会在被要求的情况下写不道德的代码（大多数人会说“这取决于”，我姑且把他们的回答解读为“是的，但我感觉不好”），只有 50％的人表示在发现不道德的代码时会举报。

如果代码对世界的影响不大，那么这也许就不成问题。如果我写了一个对 100 个人不利的算法，虽然很糟糕，但影响也是有限的。但是，如果我在拥有数十亿用户的 Facebook 或 Google 上做同样的事情，结果会很严重。扩大规模虽然有好处，但也可能带来同样多的坏处。

我们大多数人不为超大规模公司工作，但目标通常也是要增长，这样的文化很难发生改变。在开始时，投机取巧的做法可能有一定作用（例如优步决定测试没有牌照的自动驾驶汽车），但之后很难让滑坡的道德归位。

我们可以做很多事情，作为开发人员，我们设计、编写和部署代码。如果我们愿意，就可以成为防止不道德代码上线的最后一道防线。我们都听到过这样一句话：“你建造它，你运行它，你拥有它”。那么我们是否也应该承担起道德责任？在法律上，我们可能已经这样做了。我不希望自己在法庭上、在每日邮报的头条上或其他任何地方说这样的话：“我只是遵命行事”，但怎样才能真正避免这样的情况？

那么到底什么是道德？

我们不必拿有轨电车问题来做说明，技术道德并不是哲学的一个晦涩分支。道德代表了专业、合理的行为。我们可以将技术道德定义为发现 IT 系统可能出现的问题（如个人或团体的劣势或伤害），并采取切实步骤避免这些问题。

这在实际当中意味着什么？我们亲身遇到的这种道德问题通常都是非常普通的：

资源严重不足的项目。一个交付的项目不具备过关的质量，因为它没有得到足够的资源。
数据安全性不足。保护客户数据的措施还不够好，这可能会因为暴露个人信息而伤害了用户。
过度的数据收集。应用程序保存超出实际需要的用户数据，因此承担了不必要的风险。
备份不足。如果发生故障，用户可能会因为丢失重要数据或服务而受到损失。

这些道德问题都不是什么深不可测的新生事物。它们不像是邦德勇闯恶棍盘踞的巢穴，也不是要揭穿邪恶的政府计划。它们是大多数公司每天都在与之斗争的问题，沉闷却无比重要，开发者甚至因此无法睡上一个安稳觉。我敢肯定，我们之前都遇到过这样的事情，并感觉非常糟糕。

我们不能说出错就是不道德的——软件总会出错。但如果我们不做出合理的努力来避免问题的出现，或者在发生问题时没有指出来，或者在遇到问题是没有去解决问题，那就只是不道德的（或者说是不专业的）。

处理更复杂的道德问题只是普通职业行为的延伸，例如避免使用有偏见的机器学习训练数据或让用户不受政治操纵。从我们都有资格讨论的一般性问题（如备份）到需要博士学位来解决的哲学问题，它们之间并没有天壤之别，它们存在于同一个连续的频谱上。一方面，对于熟悉的问题，我们有定义好的最佳实践（比如备份），另一方面，我们面临新的技术，对于它们的故障模式我们并不熟悉，而且缺乏相应的指南（如机器学习）。

例如，让我们来看看一个真实案例——在星巴克等美国公司中非常流行的 Kronos 调度软件。 2014 年，纽约时报披露，通过 Kronos 算法来提升门店效率对员工的生活产生了非常负面的影响。我确信 Kronos 的开发者不是故意要这么做，他们只是没有预见到会发生这些问题，也没有现成的指南可用。

这里的道德问题并不是开发者的错。人们没有意识到，因为没有历史可循，所以就有可能会发生错误，需要在没有国家报纸这类实体干预的情况下发现并纠正这些错误。就观察工具来说，纽约时报通常不是最好的选择。问题不在于开发人员缺乏同理心，而是他们并不知道软件在已知和未知问题频谱中处于什么样的位置，并据此采取行动。他们没有进行足够的测试和监控，所以这属于专业性问题，而他们原本不需要心理学硕士学位就能完成这些事情。

我们最终将为机器学习、个性化算法等技术总结出最佳实践。只是现在我们还没有这么做，暂时还处在混乱的状态。这与 20 年前刚出现安全性或可访问性时的情况并没有本质的区别，但在数量上却十分不同，因为如果现在搞错一些东西，就会有很多人受到影响。这意味着我们需要更快地采取行动，并定义和分享好的行为。自我监管的能力必须赶上创新的速度。

作为开发者，关键在于保护人们免受软件已知问题的伤害。无论这种伤害是来自可怕的 AI 还是未经测试的备份操作，我们都需要最佳实践来指导我们。目前，关于软件工程师的道德或专业行为准则应该按照自上而下（政府立法或专业团体）还是自下而上（自主发起）的方式来定义存在很多争论。在我看来，最重要的是我们能够快速创建、分享和遵循指导方针，并快速解决问题，因此我们需要由软件工程师自己推动一种开创性的方法。自上而下的方式效率太低了。

当然，说起来容易做起来难。过去，我们都接受不道德的东西。如果我们总是无法获得足够的灾难恢复预算，那么我们将如何确保有足够保资源来监控具有种族偏见的算法？更何况我们有可能不知道如何做到这些！或者说服我们的雇主为我们提供源源不断的资金？这似乎是不可能的事情！这些事情已经注定了！

任何事情都比“注定的”要好，我倾向于从最简单的事情开始。很多公司都可以保证做到最基本的道德，如应用安全补丁，因此要强制推行责任行为不是不可能的。那么在现实中，开发人员可以做哪些道德的行为？

释放你的力量

如果一个软件工程师看到某些不道德的东西或者某些可能不道德且缺乏监管的东西，他可以做些什么？当你这样问一个典型的工程师时，可能会得到三个答案：

发出警报，然后继续工作（警报可能无效，因为管理层已经知道它们的行为存在问题）。
离开项目（或业务）！
成为一名举报人（最难的选择，你可能会获得一些感激，但可能需要在俄罗斯度过余生）。

所以，开发者认为其中的一种选择不太可能（成为举报者），而另外两项代价也很高，他们也不太可能接受。这些就是 Stack Overflow 问卷调查的结果吗？难怪他们都是失败主义者。

当然，上述这些并非唯一的选项。开发人员比我们意识到的要强大得多。具体来说，我们有消费权力和专业力量。我为什么这么说？

消费者权力

所有工程师都有权力保留他们的预算（消费者权力）。如果你对此持怀疑态度，请想想那些技术大会上的女性演讲者。十年前，几乎没有女性在大型科技会议上发言。而现在，该行业中女性的比例占到大约 15-20％。这并不是因为会议组织者是一群嬉皮士，也不是因为她们可以轻而易举地赢得话语权。会议委员会之所以接受女性演讲者，是因为如果他们不这么做，就会遭到与会者的投诉。这是一个简单的例子，开发者购买了大会门票，那么就有权获得他们想要的东西。

消费者权力是推动变革最简单的方式。只要工程师购买或使用高科技产品和服务，他们就可以行使这项权力。例如，开发人员询问云供应商的可再生能源政策，以此来改善它们，或者从一个你认为不道德的供应商转换到另一个你认为相对较好的供应商——只要你告诉他们为什么要这么做！

专业力量

开发者拥有的第二种力量就是他们的专业知识。技术人员供不应求，公司热衷于雇用他们，并且想方设法留住他们。如果工程师期望雇主具备明确的道德技术流程，他们就会如愿以偿。

什么是道德技术流程？

我已经说过，我们应该对道德技术流程有所期待，但到目前为止还没有这样的流程！我们需要与软件工程师一起来制定这样的流程，原因有三：

我们可以知道和避免其他人已经遇到的问题。
通过一个清晰的流程，可以更容易地确认一个功能及其监控级别是否符合道德标准。
一旦达成一致的流程，我们就可以对它们进行自动化。

让我们从定义一些简单的检查清单开始，并尝试实施它们，看看它们是否有效。检查清单虽然技术含量低，但在航空业，它们在提高安全性方面却非常有效。学习现有的最佳实践是一个很好的策略。

因为必须扩展到我们正在构建的所有新事物上，所以我们需要在前期和回顾过程中思考如何在新领域中应用最佳实践，并分享我们的想法。考虑使用测试驱动开发，并尽早考虑故障模式，这样做通常都很有效。我们不喜欢在不经测试的情况下使用开源代码，不过我们目前允许在没有作者或其他用户给出道德指南的情况下使用开源代码。也许我们不应该这样？

为了实现这一目标，我们为开发者开通了一个 GitHub 账号 https://github.com/coed-ethics/coedethics.github.io ，列出了符合道德规范的资源清单。我们还与英国科技智囊团 Doteveryone 及其他人合作，创建一些基本的道德检查清单和流程，我们将分享给大家。有一些行业组织对这些流程给出了反馈。

我们将在 7 月举行的伦敦 Coed:Ethics 大会上讨论这些结果，InfoQ 将会报道这些大会内容。如果你不能参加我们的会议，仍然可以通过其他方式参与。

请加入并帮助我们一起实现我们的目标。为你的开源代码编写道德指南，为我们的道德检查清单和指导方针做出贡献，或者将你遇到的违背道德的案例告诉我们。没有人是这方面的专家，因为这是一个全新的领域。我们只能依靠自己的判断力，并坚持下去，让开发者成为防御不道德代码的最后防线。

关于作者

Anne Currie 在技术行业工作了 20 多年，从 90 年代的微软后台办公室服务器到 00 年代的国际在线内衣网站，再到 10 年代的尖端 DevOps 及容器编排。Anne 在生产力、零售和 DevOps 领域创办了初创公司。她目前在 Container Solutions 伦敦办公室工作。