|你看到的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%的工作 , 也是真正决定产品价值的工作 , 都得开发者自己搞 。
他们会经历些什么?我随便举几个最简单的例子(行业外的朋友可以忽略):