|你看到的AI与智能无关( 二 )

“ 对话AI产品的管理方法 ”
先给结论：如果还想沿用管理GUI产品的方法论来管理对话智能产品，这是不可能的。
从行业角度来看，没有大量成功案例，就不会有流水线；没有流水线，就没有基于流水线的项目管理。

也就是说，从1886年开始第一辆现代汽车出现，到1913年才出现第一条流水线——中间有27年的跨度。再到后来丰田提出The Toyota Way ，以精益管理(Lean Management)来快速迭代（类似敏捷开发）以尽量避免浪费，即Kaizen(改善) ，这已经是2001年的事情了。
这两天和其他也在给大企业做对话的同行交流的时候，听到很多不太成功的产品案例，归结起来几乎都是因为 “产品Scope定义不明” ，导致项目开展到后面根本收不了尾。而且因为功能之间的耦合紧密，连线都上不了（遇到上下文对话依赖的任务时，中间环节一但有缺失，根本走不通流程）。这些都是行业早期不成熟的标志。
“ 对话AI产品的Design Principle 尚未出现 ”
对话智能领域相对视觉类的产品，有几个特性上的差异：
1）是产品化远不如视觉类AI成熟；
2）深度学习在整个系统里扮演的角色虽然重要，但是还是很少，远不够撑起来有价值的对话系统；
3）产品都是黑箱，目前在行业中尚无比较共同认可的设计标准。
APP发展到后面，随着用户的使用习惯的形成，和业界内成功案例的“互相交流” ，逐步形成了一些设计上的共识，比如下面这一排，最右边红圈里的 “我”：

但是，从2007年iPhone发布，到这些移动产品的设计规范逐步形成，也花了近6、7年时间，且不提这是图形化界面。
到如今，这类移动设备上的产品设计标准已经成熟到，如果在设计师不遵循一些设计思路，反而会引起用户的不习惯。只是对话系统的设计规范，现在谈还为时尚早。
到这里，结合上述两个点（对话AI产品的管理方法、设计规范都不成熟），也就可以解释为什么智能音箱都不智能。因为智能音箱的背后都是一套“技能打造框架” ，给开发者，希望开发者能用这套框架来制作各种“技能” 。
而“对话技能类平台” 在目前根本走不通。任何场景一旦涉及到明文识别以外的，需要对特定的任务和功能进行建模，然后再融合进多轮对话管理里的场景，以现在的产品成熟程度，都无法抽象成有效的设计规范。现在能抽象出来的，都是非常简单的上下文管理（还记得Part 2里的“填表”么？）。
我就举一个例子，绝大部分的技能平台，根本就没有“用户生命周期管理”的概念。这和服务流程是两码事，也是很多机器人智障的诸多原因之一。因为涉及到太细节和专业的部分，咱们暂且不展开。
也有例外的情况：技能全部是语音控制型，比如“关灯开灯” “开空调25度” 。这类主要依赖明文识别的技能，也确实能用框架实现比较好的效果。但这样的问题在于，开放给开发者没有意义：这类技能既不需要多样的产品化；开发者从这类开发中也根本赚不到钱——几乎没有商业价值。
另一个例外是大厂做MLaaS类平台，这还是很有价值的。能解决开发者对深度学习的需求，比如意图识别、分词、实体提取等最底层的需求。但整个识别部分，就如我在Part 3&4里提到的，只应占到任务对话系统的10% ，也仅此而已。剩下的90%的工作，也是真正决定产品价值的工作，都得开发者自己搞。
他们会经历些什么？我随便举几个最简单的例子（行业外的朋友可以忽略）：