AI调试过程中的漏洞

当AI算法在现场部署并给出一个意想不到的结果时，通常不清楚该结果是否正确。

到底发生了什么?错了吗?如果是，是什么导致了错误?这些问题通常不容易回答。此外，与所有验证问题一样，找到根本原因的唯一方法是将问题分解为可管理的部分。

半导体行业过去也面临过类似的问题。软件在硬件上运行，软件必须假定硬件永远不会出错。类似地，当将硬件映射到FPGA，期望FPGA面料永远不会出错。在这两种情况下，底层执行平台都经过了一定程度的验证，随着时间的推移，它们建立了信任验证在某些情况下，在他们身上进行的手术是不朽的。

芯片包括人工智能通常是使用大量异构处理器设计的，这些处理器没有得到很好的验证。通常，他们使用新颖的互连和内存架构。这些芯片通常部署冗余来解决产量问题，并执行大型而复杂的调度任务。此外，它们利用编译器/映射器，这些编译器/映射器采用在云中开发的算法，并对它们进行操作，使推理能够部署在任意硬件平台上。

与软件的编译器不同，使用AI编译器/映射器不是一个无损的过程。它输出的代码与输入的代码行为不一致。在树的顶端，人工智能本身是一个不精确的过程，当它的输入面临极其微小的变化时，可能会产生完全不同的输出。

通常由独立的团队处理这些阶段中的每一个。腾讯人工智能、软件和生态系统产品营销总监Nick Ni表示:“至少有三到四个不同的利益相关者参与其中。赛灵思公司．“他们在调试方面都有不同的关注点。从最顶层的人工智能科学家开始，他们的工作与硬件无关。然后是推论。现在你开始把AI科学家模型的快照放到要部署的东西上，你必须调试它。这里你至少有一个正确的答案参考。你正在根据AI科学家的结果进行调试。“如果这是输入数据集，那么这些就是预期的结果。’当你完成了所有的精度和准确性检查，看起来它可以在TPU、GPU或fpga上工作时，你就可以把它放在实际的硬件上，看看比特是否能正确返回。”

但是正确性有几个含义。“一般来说，神经网络既提供了答案，也提供了概率，”ibm机器学习小组的产品营销总监史蒂夫·斯蒂尔(Steve Steele)说手臂．“谁也不知道‘正确答案’是否得到了回复。如果结果是“有人在人行横道上”的概率是94.6%，你怎么知道你是对的还是错的?另一方面，调优ML性能更加简单。如果你每秒只能得到2个推论，但投影显示我应该每秒得到15个推论，工具可以提供这种水平的洞察力。”

从过去吸取教训
调试当现场出现错误，或者验证行为产生意想不到的结果时开始。通常，第一步是确定问题是在设计、测试中，还是在规范本身中。受控环境中的验证总是比较容易，因为它是确定的和可重复的。然而，仍然很难确定什么时候出了问题，这与问题变得可观察到的时候有很大的不同。

软件意味着涉及多个涉众。“你永远不会通过在处理器上启动Linux来验证它，”微软的首席执行官西蒙·大卫曼(Simon Davidmann)说治之软件．“你可以从最小的关卡开始测试。当我们构建处理器模型时，您需要非常详细地测试每一条指令。这是白盒测试。然后你建立下一层，在上面运行一个小程序，然后是另一个程序，你慢慢地一层又一层地建立信心。当你运行Linux时，你很快就会在硬件上得到20亿条指令，而且你无法调试。对于人工智能，你可能在谈论1000亿条指令。从这个层面上看是无法理解的。”

值得庆幸的是，商用cpu和gpu以及它们使用的工具链都经过了良好的测试。“假设软件堆栈和GPU得到良好的支持，将AI算法映射到GPU上几乎是微不足道的，”HLS平台项目总监Russell Klein说西门子EDA．“只有一行Python代码就可以做到，使用tf.device(' /gpu:0 ')。因此，在一个支持良好的平台上运行带有完整python/TensorFlow集成的嵌入式Linux的应用处理器是可行的，只要指定设备，它就会“正常工作”。英伟达和Arm将努力让它们的处理器得到所有流行的人工智能框架的良好支持。tpu有类似的使用模型。用户将使用CPU进行开发和调试，然后部署在GPU或TPU上。”

但并不是所有处理器都能得到很好的支持。Imperas的大卫曼说:“你购买Arm核心的原因是他们花了100亿次周期来测试它。“你所要做的就是整合它。但是现在很多人选择开发定制处理器，比如基于RISC-V架构的处理器，他们不太可能收到相同级别的验证。”

从单核到多异构核并不简单。“当然，gpu、tpu和多核处理器阵列是加速推理的可行方法，而无需开发任何定制硬件，”西门子的Klein说。“推理算法是令人尴尬的并行，所以它们是多核平台的良好候选者。传统上，多核系统很难调试，而桌面应用程序的调试主要集中在调试单线程程序上。虽然流行的桌面调试工具gdb和Eclipse已经为多核添加了一些功能，但在我看来，它们还有很多需要改进的地方。”

简而言之，设计工具需要跟上芯片架构的变化。Klein继续说:“在模拟设计中，用户需要调试器为任意数量的处理器(仅受计算资源限制)提供非侵入性的并发视图。”该设计可以通过ISA处理器模型(AFM、QEMU、Spike)或RTL运行来模拟模拟或模拟．一个重要的属性是在请求停止的时间和您可以查看核心的时间之间的倾斜量。大多数调试器在每个内核停止调试的时间之间都有一个不确定的延迟，所以你无法在各个内核之间获得一致的视图。”

寻求决定论
AI为调试问题增加了一个新的层次，即非确定性。“人工智能是关于概率的，它并不精确，”大卫曼说。“这还是在我们考虑量化之前。当使用32位精度时，所开发的算法可以以98%的概率预测给定的图片是一只猫。如果我们量化到16位，我们可能得到96%的概率。开车时，我不需要知道那是一只猫或其他看起来像猫的动物。知道它是一只猫，而不是一个人或一棵树就足够了，因为这样我就能做出不同的决定。”

这是一个重要的区别。Klein说:“人工智能加速器通常是为特定的推理应用定制开发的。“几年前，我数过几百家AI加速器初创公司——有些在开发IP，有些在开发离散设备——但所有这些公司的目标都是超越谷歌和英伟达的tpu。如今，人工智能部署平台似乎成了淘金热。OctoML刚刚获得了8500万美元的新融资。今天早上，通过LinkedIn，我又被介绍了三家公司，他们声称可以从“任何ML框架”到“任何目标硬件”采用推理算法。在这里，我认为翻译的正确性是人工智能部署软件提供商的责任，任何调试设施都应该来自人工智能加速器提供商。”

重要的是要了解非决定论在哪里。Arm的斯蒂尔表示:“一旦经过调试并在设备上运行，算法/网络的执行将是一致的。“然而，由于不可预见的输入和网络训练不足，网络本身可能会产生意想不到的行为。因此，良好的系统设计应该设置保护带，以检查网络输出是否在预期范围内。”

虽然如果这是真的就好了，但许多复杂的系统都因为时钟域交叉或时间竞赛等问题而失败。这些问题不会以一种确定的方式表现出来。

领域特异性可以促进算法的改进。“人工智能科学家处于持续的调试模式，或者更像是研究，他们不断地在不同的数据集上进行训练，试图找到新的极端情况，并使模型更准确，”Xilinx的Ni说。“在某种程度上，他们调试或验证数据集。他们通常有自己的方法来衡量它是否正确，它是否具有必要的图像识别精度或可接受的转录，诸如此类。还有很多秘方。没有很多事情是标准化的关于什么是对或错的。这是真正棘手的地方，因为在这个级别上，调试并不是提供正确的答案。当我们谈论FPGA调试，甚至C, c++调试时，有一个正确的答案，然后定期检查它。但在这里没有，有时它是一个移动的目标。”

人工智能算法的开发与硬件无关，这与对目标硬件的推断之间存在很大的差异。“将人工智能算法映射到特定的硬件是一个很大的挑战，大部分调试应该在设计过程的早期进行，以基于模型的方式考虑硬件限制，”位于美国麻省理工大学的高级混合信号自动化集团经理Benjamin Prautsch说弗劳恩霍夫IIS的自适应系统工程部。“与其将算法映射到某些硬件，然后调试硬件，不如使用模型尽早发现问题。支持工具可能是包含硬件约束的ide，这些约束已经以硬件感知的方式限制了AI开发。此外，模型的测试环境和实际硬件应该共同设计，以便在模型和硬件之间进行良好的比较，从而在出现问题时简化调试。”

从算法到硬件的步骤仍然有点像黑魔法。“当你采用一个模型并试图部署到fpga或asic中时，几乎100%的情况下，你都不能按原样部署它，”Ni说。“至少，你必须改变精度。即使使用gpu，你也可能需要从float32更改为bfloat。这里有一个级别的调试，即检查您的答案是否仍然合理正确。它不必完全正确，但在调优到特定的体系结构精度后可以合理地正确。有时你可以合并图层。当你部署到实际的硬件时，你经常会部署快捷方式，比如A B C层可以组合到D层，并一起执行。可以节省内存、延迟等。当你开始这么做时，调试又会变得更加困难。”

但这些层也使这个过程更容易一些。”神经网络它们非常复杂，但它们是由层组成的，每一层都相当简单，”克莱因说。每一层将执行一个函数，如卷积、矩阵乘法或最大池化操作。对于神经网络的所有实现，您需要能够捕获每一层的输入数组和输出数组。您还需要能够自动比较来自不同表示的输入数组和输出数组，并标记任何差异。这需要预先进行一些编程，但从长远来看会节省大量时间。有了这些，任何时候在c++或Verilog，您可以在ML框架中的原始网络上运行相同的推断，并比较结果。我将不同的表示集成到一个环境中，因此总是进行比较，任何错误都会立即被标记。这意味着使用Verilog模拟器或仿真环境上的DPI接口作为Verilog和任何c++或Python表示之间的桥梁。”

这是框架开始支持的。“好消息是大多数框架都支持这种级别的调试，”Ni说。“在TensorFlow中，有一种叫做Eager模式的东西。(TensorFlow的Eager执行是一个命令式编程环境，它可以立即评估操作，而不需要构建图。操作返回具体的值，而不是构造一个稍后运行的计算图。)你一层一层地执行，输入，然后马上得到输出。每一层都可以调试，以查看返回的答案是否与您从参考中所期望的完全一致。”

一如既往，越早调试越好。Klein补充道:“这使你能够立即看到不同版本推断的第一个分歧点。”这样就很容易看出哪一层出了问题。失败要么是输入不同，要么是输入相同，但输出不同。前者是层与层之间的数据传输问题。后者是该层本身功能的问题。了解故障的类型和位置会让修复变得相当简单。”

构建流程
验证一直都是关于建立一个限制bug逃脱可能性的过程。倪说:“人工智能领域必将走向成熟。“现有的方法是说，我的系统已经经过调试，在这些数据集、输入和校准措施中似乎是正确的，所以它已经准备好在现实世界中使用，看看有什么管用。”

我们都知道结局如何。大卫曼说:“在实地发现漏洞意味着你现有的流程有缺陷。“如果它在涉及20亿件事情时失败了，这意味着当你有2亿件、2000万件、200万件或20万件事情时，你没有正确地测试它。你可以在小关卡中进行测试，并确保你做对了。有时这意味着要找到正确的抽象概念。”

其他人也同意。“当验证推理引擎时，你必须从系统的高级模型开始，”Davidmann补充道。“这应该在任何人接触RTL之前就开发出来。你必须完全验证每一个小内核。它们是连接硬件和软件的基本构件。一旦它们在硬件的高级模型中运行，您也可以在RTL上运行它们。”

结论
虽然人工智能系统可能比过去的处理器更大，但大多数问题都是相同的。当在字段中发现错误时，验证不会开始。它需要一个过程，系统地确保算法或硬件的细化中的每一步，或数据的每一次转换，都可以独立验证。让人工智能更加困难的是，该行业尚未定义一致的指标，以确保端到端流程达到规定的质量水平。因为起始点本身是不确定的，所以这变得更加困难。

任何调试问题的第一步都是找到根本原因，这应该从系统地比较结果开始，从最高级别一直到分歧变得明显的点。好消息是，正在出现的工具让这变得更容易。