伦理即服务:科技伦理与可信AI的下一个浪潮( 二 )


同时 , 作者在论文中认为 , 除了伦理定义上的模糊 , 在实现AI伦理与技术耦合过程中 , 还存在着一些技术限制:
首先 , 伦理转译的工具和方法大多不具有强检验性(extra-empirical) 。其主要体现在伦理标准的选择上 , AI实践者会倾向于选择与自身价值观和理解认识相一致的伦理工具 , 而不是与社会的主流偏好相一致的伦理工具 , 这意味着开发者可以自主制定算法实践的评估标准 , 但自身却不受社会价值的约束 , 导致这些转译工具可能面临人为操纵的风险 。
其次 , 许多既存的转译工具和方法都属于分析和判断型(diagnostic) , 而非规范和确定型(prescriptive) , 使得大部分的伦理工具欠缺实效性 。例如 , 在算法偏见的场景中 , 伦理工具虽然能够提示是否存在偏见问题 , 但却无法提供解决偏见的路径 。
最后 , 伦理转译工具通常会被开发者用于完成某些程序的一次性测试(one-off test) , 只能在系统设计之初对其合乎伦理性进行检测 , 而无法在之后对其进行贯穿生命周期的重复审查 。
因此 , 作者认为 , 有必要定期检查算法系统的伦理影响 , 至少经过三个阶段的检验程序:确认、验证、评估 。确认程序旨在检验算法系统的性能是否良好;验证程序旨在检验算法系统是否遵循了正确的开发流程;评估程序旨在检验算法系统在部署期间是否能保持正确的运行状态(Floridi, 2019) 。有学者(Arnold & Scheutz, 2018)认为 , 除非伦理评估成为算法系统的必备选项 , 否则难以使伦理转译工具(pro-ethical translational tools)对AI系统的伦理影响(ethical implication)产生积极作用 。
【伦理即服务:科技伦理与可信AI的下一个浪潮】此外 , 上述对伦理工具的批判也引发了人们对伦理工具的质疑 , 认为伦理难以甚至不可能嵌入算法的设计、升级、部署以及使用等算法流程 。然而 , 诸如医疗伦理、搜索伦理等算法应用领域的经验表明 , 将伦理原则付诸AI实践并非不切实际 , 而且有利于保护个人、团体、社会以及环境免受算法伤害 , 激励AI产出最优的算法结果 。
作者在文中认为 , “伦理即服务”是可实现、可操作的 , 但在研发思路上要满足以下两种标准:一是在抽象的伦理概念和具象的技术措施中达成妥协 , 也即 , 伦理原则不必过于抽象 , 也不必过于具体 , 伦理转译工具不能过于严格 , 也不能过于宽松;二是摒弃一次性、一揽子测试的伦理审查机制 。
AI伦理服务是一项长期性、持续性的活动 , 不应以暂时性的审查结果为目标 。同时 , AI的开发机制应当是可回溯、可反思的(reflective) , 因为这种开发理念能够助益AI从业人员(practitioner)理解自身在特定环境下的主观目的(subjectivity)以及潜在偏见 , 从而揭示有悖于伦理的算法结果为何出现 , 也有利于对此类结果制定合适的解决方案 。上述思路对于伦理服务工具的设计、开发以及应用而言 , 也极具启发意义 。
AI伦理服务产业方兴未艾 , 为AI产业补上缺失的一环 , 助力可信AI发展
开发伦理工具是提供伦理服务的基础 , 也是让抽象的伦理原则操作化的重要方式 。为此 , 在国内 , 谷歌、微软、IBM等头部科技公司开始积极研发伦理工具 , 越来越多的初创公司也开始投身于AI伦理市场 , AI伦理开启了由框架到工具、由工具到服务的产业化道路 。谷歌、微软、IBM等科技公司不仅主动研发伦理工具 , 而且通过将伦理工具开源化 , 或者在云服务上集成化来促进行业践行AI伦理 。
例如 , 在算法模型安全领域 , 微软公司发布了一项名为Counterfit的对抗性技术开源化项目 , 旨在帮助开发人员测试AI系统和机器学习的安全性问题 , 在不同环境中针对合作伙伴机器学习模型展开测试 , 继而为AI企业的算法安全提供合适的风险评估工具 , 以确保AI业务的稳健性、安全性以及可靠性 。