阿波罗13号（Apollo 13）成立50周年，为AI和包括自动驾驶汽车提供课程。
美联社
是时候执行任务了。
我保证会有重要的教训。
时光倒流至1970年4月11日。
那天，肯尼迪航天中心发射了阿波罗13号登月任务。
美国人和世界已经对登月感到有些放心，他们在阿波罗11号登月升空时高举，后来由于阿波罗12号的成功而习惯了月球漫步的“平凡”（是的，它降落在月球上月亮！）。las，除了能够从根本上证明阿波罗11号不是偶然事件之外，没有多少人能背诵阿波罗12号任务。
对于阿波罗13号来说，如果一切顺利的话，很可能今天我们将不再讨论这个旅程，因为它“只是”另一次登月。
1970年4月13日，完全改变了这一历史轨迹。
让我们简短地讲述一下4月13日这一决定性时刻的关键时刻。
日期是13 日，航班号是13，这让人有些担心，可能会导致运气不佳（另外，如果您将发布日期04-11-70的数字加在一起，就会得出数字13，因此有很多理由感到潜在的不良共鸣）。
机组人员在1970年4月13日飞行大约55个小时后进行了电视广播，但收看电视的人数很少，因为主要的广播网络决定改为运行常规节目。
这是要提交到内存的数字：55:54:53。
那是确切的时间，登月任务变成了拯救宇航员生命的任务。
大约一分钟左右之前，位于休斯顿的任务控制部要求杰克·斯维格特“搅拌”冷冻箱。这些是航天器上的重要储罐，由两个氧气罐和两个氢气罐组成，用于多种目的，包括向机组人员提供氧气，并且还产生了飞行所需的电力。
搅拌过程是例行的，本质上并不特别明显，并且预计会不时地进行搅拌，以使用内置风扇使罐保持新鲜。
只需拨动开关即可搅拌一个水箱。
按下搅拌开关后不久，机组人员听到了爆炸声和意外声音。
在55:55:42的时间戳记中，阿波罗13号的指挥官詹姆斯·洛威尔上尉向地球广播了有史以来最著名的外层空间之一：“休斯顿，我们遇到了问题。”
当然，今天的报价单有更多的模因，远不能撼动。
简而言之，坦克中发生了爆炸，炸毁了飞船的其他各个关键方面，使宇航员陷入了可怕的境地。
由汤姆·汉克斯（Tom Hanks）主演的关于阿波罗13号（Apollo 13）的颇受欢迎的电影相当准确且戏剧性地描绘了飞船内部爆炸后的惨痛努力。
在电影中引起特别注意的一个方面涉及需要飞速寻找一种方法来处理开始在飞船内部积累的二氧化碳（这最终会击垮宇航员并用碳杀死他们。二氧化碳中毒）。美国国家航空航天局（NASA）的工程师的任务是弄清楚如何处理将气体过滤罐装入特殊的通风孔，并且仅限于使用已经在飞机上飞行的物品。
在空间郊区找不到漂浮的便捷五金商店的机会很小。
设计了一种临时方法，涉及使用从机上操作手册撕下的盖子，并使用胶带（再一次证明胶带的价值）以及其他各种物品，然后作为指示进行广播，直至船员。
机组人员接受了即兴演奏，幸运的是，它奏效了。
在那次飞行中还发生了许多其他同样令人振奋的时刻。
美国人和全世界都对阿波罗13号的状态着迷，直到南太平洋安全降落之前，没有人松一口气。
爆炸事件发生在1970年4月17日。
对于那些你想庆祝50 次事件的周年纪念日，您可以使用4月11日（正式发布日期），4月13日（发生事件的日期），或4月17日（安全溅落），但大多数人会正式说任务开始日期是正确的日期。
使用您喜欢的任何日期，并从中汲取宝贵的经验教训。
除了明显的英雄主义外，还有许多其他敏锐的见解需要收集。
机组人员和地面控制人员组成一个团队，彼此进行认真周到的协调。
为团队合作的价值打分。
考虑到宇航员的生命是在线的，他们都系统地工作并且没有失去头脑，这很容易做到。此外，您可以合理地推断出登月任务的未来也是在线的，因为公众可能已经决定“足够了”，如果机组人员丢失了，便不再有进行更多飞行的愿望。
保持头脑冷静并保持稳定。
回收罐的问题是重返地球期间出现的许多此类问题之一，所有这些问题都是逐步解决的。尽管已制定并实施了一系列应急计划，但大多数奥秘问题并非以前曾考虑过的问题。
为创造力和创新打分。
由于这些及其他相关原因，可以将Apollo 13描述为“成功失败”。
失败方面与月球着陆的擦洗有关，因此无法执行预期的任务。
成功的方面在于能够处理容易导致飞船及其乘员丧生的混乱局面。
由于没有人丧生，有些人对此表示不满，尤其是他们都平安无事地回家。
无论如何，让我们换档并完全考虑关于阿波罗13号任务的不同观点。
储罐中的爆炸是如何发生的？如果有的话，它展示了什么？
安装过程中的教训
鲜为人知的是，一系列事件是如何导致违规坦克预示该任务的无害“滴答定时炸弹”的。
作为我将要描述的内容的背景，有一个流行的寓言叫做“上游寓言”（请参阅此处的分析），断言我们的注意力通常在下游事件上，而我们没有意识到上游因素导致了首先是灾难。这是有道理的，因为当您尝试解决问题时，您通常将精力集中在眼前的问题，下游危机上，而无力应对其发展（上游）。
最终，向上游看通常是有利的。
如果是坦克爆炸，您必须回到过去，这要在Apollo 13任务执行之前的一段时间。
坦克首次制造时，注定要继续使用阿波罗10号。
不管你信不信，根据美国航空航天局的调查，以及每一个迷人的采访为50的言论吉姆·洛弗尔日周年（见这里的链接），坦克基本上是由坦克的制造者下降（而在货架上） ，遭受内部损坏。
一系列后续方面几乎注定了坦克成为一种定时炸弹。详细信息相当技术复杂，因此如果您需要这些细节，请务必参考Lovell的访谈或NASA的调查报告。
简而言之，这是一系列按时间顺序排列的关键操作：
·最初有一个错误，就是油箱掉落。
·尝试查看水箱是否仍能正常运行，但是此尝试并不全面，并且未测试某些关键功能以确保其仍能正常工作。决定继续使用该坦克，选择的是阿波罗13号而不是阿波罗10号。
·在执行阿波罗13号飞行任务之前，一项包括该坦克在内的倒计时演示测试表明该坦克不会像往常那样排水。不经意间，人们就为什么无法正确排放坦克做出了错误的猜测，因此使用了另一种方法来排放坦克，但这是“政变”，使坦克成为严重危险。
·尽管可以更换该油箱，但会导致发射的严重延误，大约报告了数月，因此决定继续进行，因为否则它似乎可以正常工作。
·在发射前，储罐中充满了液氧，此时，一旦将其连接到电气系统，适度的火花（例如电弧）可能会使储罐着火并导致爆炸（请注意未损坏）坦克就不会那么敏感）。
·滴答定时炸弹随后被装载到阿波罗13号航班上，等待可能发生不愉快事件的时刻，例如杰克·斯威格特（Jack Swigert）对坦克的不适当搅拌，似乎引起火花并引爆了坦克，尽管斯威格特没有办法知道所有其他一系列事件都是事先发生的，并且将它们都置于动荡的边缘。
一个相当不错的故事，以及一系列看似“未发生”的事件，它们是相对隐蔽的。
我之所以说“无懈可击”，是因为在为完成如此大规模的活动而做的数千件事中，毫无疑问，它是无数任务和子任务中的一个细微线程，而不是当时任何人都拥有的给予特别或过度的关注。
您可能会说有趣，但是除此之外，您对制造和掉落的氧气罐有什么看法呢？
让我们来上课。
首先，发生了最初的错误，即油箱掉落。
这显然很糟糕，这本身就是一种教训，不要破坏那些本不该被破坏的东西。
其次，最初的错误是由于缺乏充分和适当的测试来确保坦克按预期工作而变得更加复杂。
这可以适用于发生初始错误的任何情况，但是不幸的是，缺少尝试完全解决或修复错误的情况。
一个半生不熟的修复程序可能是阴险的。
为什么？
因为知道问题的人会因此认为问题已得到解决，并且不会寻求解决问题，因为他们错误地认为问题已得到解决。
可能是扭曲的逻辑，但是是正确的。
如果根本没有人试图修复它，并且知道它可能有错误，那么那些有意识的人会将其保留在要处理的事情清单上，最终要么修复它，要么决定将其丢弃完全。
但是，通过半熟半熟的修复，参与其中的人员错误地认为它实际上已修复，并且被误认为该项目现在已经准备就绪。
正如我所说的那样阴险。
第三，一旦坦克准备好执行任务，它便不愿排水，这是另一个潜在时刻，有人可能已经意识到事情已经到来。
部分由于储罐内组件的复杂性，参与其中的人员提出了关于可能存在的问题的理论，因此采取了另一种方法（错误的方法），这似乎导致了正确的结果，但实际上是使事情变得越来越糟
因此，这第三个教训是，有时复杂性超越了我们考虑所有途径的能力，并且可能在当前的压力下，退缩和重新考虑问题的开放度降低了。
第四个教训是，宇航员依靠飞行器的系统和子系统，并假设它们会按预期工作，这当然是有道理的，因为在不假设其他人都做过的情况下，您还能进行如此大规模的操作吗？工作正常吗？
您几乎别无选择，只能希望并祈祷其他人都做了自己的工作。
作为关键课程的回顾：
a）不要犯最初的错误
b）出现初始错误后，请勿半烤
c）有时，复杂性使得很难找出解决方案或知道解决方案有效
d）系统的最终用户通常受制于系统的最终用户
故事中还嵌入了其他课程，但对于本文而言，这些课程就足够了。
将这些教训应用于AI系统
这些课程都适用于AI系统。
并且，尤其是对于大型和复杂的AI系统。
因此，我恳请所有的AI开发人员，请注意这些教训，同样，所有正在构建和部署AI系统的公司也是如此。
我什么意思
在制作AI系统时，很容易在系统编码内部产生细微的错误（请参阅我对著名的失败编码错误的讨论，该错误仅因语法错误而破坏了整个系统，请参见此处的链接）。）。
这包括您是否要通过常规编码来设计系统，无论是以Python，C ++，LISP之类的编程语言，还是可能使用的任何方式。
对于那些使用机器学习（ML）和深度学习（DL）的用户，不要以为如果使用的是ML / DL程序包，它可以完成“编程”工作，那么您就不用担心了。
您用来训练ML / DL的数据的性质可能不足，并导致ML / DL系统中的“错误”一开始并不明显。
一旦变得显而易见，您就可以通过半掩饰的修补程序轻松地尝试“解决”问题，例如确定如果数据包含导致问题的异常，则只需剪切异常数据并进行处理即可。它。
不幸的是，奇怪的数据可能实际上是您的ML / DL应该处理的所谓拐角或边缘情况的明显迹象，但具有讽刺意味的是，您现在已经切除了这些明显的信号。
根据有关Apollo 13的课程，您可能会认为自己已解决了该问题，并将其传达给其他人，然后所有其他人将不再需要任何关注而将其解决。
同时，滴答定时炸弹已被放置。
对于可能执行平凡动作的AI系统，错误及其导致的结转可能不会造成灾难性的后果。
考虑一下生死攸关的AI系统，例如基于AI的自动驾驶汽车。
假设位于自动驾驶汽车上的AI内部存在一些初始错误，并且该错误会自动操作汽车控件。
想象一下，在早期测试阶段，也许当AI被用于在特殊测试轨道或试验场上进行测试的自动驾驶汽车上时，问题就出现了，并且在当时的压力下，AI团队半生半熟固定。
自动驾驶汽车似乎仍在继续增长。
批准然后在公共道路上进行试验。
您可能会认为，只要在公共道路试验中车辆中有一名驾驶员作为安全监控器，随时准备接管控制装置，那么是否存在半熟的修复方法都没关系。尽管要意识到，也许错误只会在蓝色的月亮中出现，这是罕见的，并且在公共道路上行驶的里程数可能不足以解决特定的错误。
可能是由于公共道路试验似乎进行得很顺利，因此在没有任何人工监督的情况下允许进行绿灯。在某个时刻，潜伏的错误正坐在那里并且将要到达，潜在地导致乘客和附近任何行人的生死时刻。
有人说，好吧，我们已经使用OTA（空中下载）电子通信功能将补丁下载到AI系统中，以修复所有错误。
尽管可能是这种情况，但这有点像是在马匹已经离开谷仓后对马进行畜栏。
换句话说，假设自动驾驶汽车由于隐藏的错误而进入汽车残骸，造成人员受伤或死亡，然后仅会进行错误搜索。
同时，可能是该AI自动驾驶汽车的所有模型都具有相同的嵌入式错误（一个定时炸弹），直到AI开发人员弄清问题所在为止，才提出了可靠而全面的解决方案。 -修复，然后将其发布给该AI自动驾驶汽车制造商的所有车队。
结论
无论您是构建复杂的AI系统还是构建简单的AI系统，发生某种“初始错误”的机会都是相对充实而严重的。
令人遗憾的是，在匆忙地将奇特的AI系统推向户外的过程中，随着时间的压力，有时甚至是公司的成败，没有那么多真正的软件工程在进行。
随着AI系统的不断扩散，以及我们所有人越来越多地使用它们，我们变得像宇航员一样，只希望切换开关，并期望系统已被适当地适当设计和部署。
诸如灾难性故障之类的意外事件是不可能的。
人工智能，我们有一个问题，这取决于人工智能开发人员和人工智能提供商，以确保顺利飞行和安全通过。
网友评论