“纸上得来终觉浅，绝知此事要躬行。”——陆游
上篇文章，我讲到了如何学习成为一个 AI 时代的产品经理，这篇文章，我想结合我自己的工作，跟你分享一些我在做人工智能相关产品时的实践和思考。我进这一行的时间其实不长，而且目前的主要工作都集中在 NLP 领域，所以难免会有一些局限性，希望你批判地听。
产品经理应当把大颗粒的整体性领域算法拆成小颗粒的算法单元，并在此基础上寻找产品化可能。这句话的意思是说，我们不能给算法团队提出一个很大的领域型需求，然后就坐等算法的突破，产品经理应当更小粒度地看待每个具体算法过程和环节，并评估是否有能够被产品化的成果。
比如，我们不能要求算法团队交付一个“聊天机器人”，这个需求粒度太大了，彻底完成会受制于各种因素，更是一个长期的过程。产品经理应该深入到领域内，比如看到自然语言理解（NLU），甚至看到其中本体库搭建和句子的语法树等等，可能部分完成的本体库已经可以包装为一个初级的人机交互引导产品。
我们在无码科技做 Readhub.me 时，产品经理会尽量避免提出像实现命名实体识别（NER）或实现信息抽取（IE）之类，这样大而化之的需求；而是尽量参与到算法过程中，分步去看过程产出。
比如命名实体识别过程中我们需要分词，分词作为一个中间算法，是否可以被直接产品化；再比如信息抽取需要先找到大信息量的文本片段，这个过程的产出，是否可以作为文章摘要或文本标签等等。
过去产品和技术泾渭分明，但在 AI 时代，我认为这个界限应该被打破，产品经理要融入到技术过程中去，不止关注需求，更要关注供给，这样才能做出真正的好产品。
当我们说人工智能的时候，总是希望算法可以解决所有问题，给出一个干净而准确的结果。吴恩达教授在去年神经信息处理系统大会（NIPS）上也提到深度学习会向端到端的方向发展。
这句话什么意思呢？
就是说，比如我做一个语音交互的机器人，过去的思路可能是人说话，先经过语音识别的算法变成文字，然后再用自然语言处理的过程去理解这些文字的意图，最后做出反应；而端到端的思路是直接把输入，也就是人的说话声音灌到算法盒子里，算法输出的直接就是最终的反应，不去编排中间过程。
但是，完全端到端在工业界有效程度没那么高，我们还是需要大量的工程工作去对算法模块做衔接，对算法的输入输出做清洗和筛选。我们不能在工业界套用学界的做事方式和标准，比如算法能做到 63 分，这时我们继续拼命优化算法，努力提升到 65 分，这就不如找个皮实一点的 60 分的算法，加上工程手段，或许可以快速做到 70 分甚至更高。
工程至少可以在三个方面快速提高产品的价值分值，一是通过规则在算法的基础上对输入和输出数据做筛选和过滤（很多时候体现为大量的正则表达式）；二是通过工程帮助算法做降维，比如做人脸识别，我们不用把摄像头拍下的整张图片送进神经网络，而是通过工程的方法把图片中的脸截出来并且特征化之后再往算法里送；三是协助算法的训练，比如做手写数字识别，样本量不够的情况下，可以用工程的方法添加旋转和噪点，生成一些新的训练数据。
产品经理的职责是用产品为用户创造价值，至于这个价值有多少分来自算法，其实并不是成功的核心（除非你是做纯算法产品，比如一些对外提供算法接口的纯技术性公司）。刚才我们提到可能算法做到 60 分，加上工程可以做到 70 分，而一个常见的问题是，产品经理将一个 70 分的能力用到了 90 分或者 50 分的场景中，结果是造成用户的失落或技术能力的浪费。
比如，我们都知道自动驾驶有几个不同的级别，从完全不能自动化的 L0 到完全自动驾驶的 L5。如果现在我们的技术做到了 L4，非常牛了，这个级别下，大部分情况下都可以达到完全自动驾驶。
结果产品经理在此基础上，做了一个没有方向盘和窗户的产品，用户吃着火锅唱着歌把车开到村里，结果在田间地头，车翻了；又或者，产品经理做了一个传统的汽车模式，有方向盘有档把，还需要人来操作，完全没有把 L4 的技术能力用上，浪费了技术的输出。
所以说， AI 时代的产品经理应该非常了解算法的能力边界，并设计出恰如其分的产品，同时也要管理好用户的期望值，既不让用户觉得失落，也要发挥算法的最大价值。
人工智能产品经理还有一个非常重要的职责，就是规划、收集以及组织算法所需要的数据。如何保证训练、测试集中的数据特性分布和最终场景中的数据一致；如何获取足量的数据，并对它们进行低成本高效率的标注；用什么样的方式清洗数据，甚至基于数据做出统计学分析，为算法提供参考，这一切内容都需要产品经理去完成。
业内有一种说法是：当前的人工智能效果，2 分靠算法，8 分靠数据（剩下的 90 分靠运气，开玩笑的）。尤其是大量的深度学习应用，对数据的质和量提出了很高的要求。
产品经理应该要理解算法的数据输入要求和未来的算法应用场景，找到合适的数据源，合理合法地把这些数据收集下来，清洗干净；并有规划地划分开发、训练和测试集，以保证数据价值的最大化。
当然这个过程不能单靠产品经理一个人，需要有配合的工程团队一起。在无码科技，我们有一个兄弟算是半个全栈工程师，专门跟产品经理配合做这个事情，他能写脚本、能做数据、还懂业务，但愿你也能遇到这样的特种部队型选手。
另外产品经理还应当想办法在业务中设计数据的闭环，通过产品的持续运转，不断生成更多数据提供给算法做训练。目前。大部分的训练过程还是离线的，但如果未来在线学习持续发展，通过这样的业务流程设计，就可以做到在线算法迭代更新。
最后还有一个经验是，盲目扩大数据量并不总是有用的，如果数据的多样性得不到保证，扩大数据规模对算法结果没有太大帮助，甚至如果数据特性分布出现问题导致训练数据有偏，还可能会造成算法的过度拟合和表现下降。
从某种意义上说，机器学习的不确定性是必然的，它跟传统的面向流程和规则的思路截然不同，在这样的框架下，就需要转变产品设计的思路，摒除完美主义，利用产品机制去消化算法带来的不确定性。
比如，机器学习用在反欺诈或垃圾邮件监测上，就是存在概率的。一封邮件是否是垃圾邮件，在算法完成推理前（尤其是深度学习），即便算法的作者恐怕也无法给出准确的预测。
算法有可能会错判和漏判，这都是产品经理需要理解和考虑的场景，并且要去通过产品设计去消化它。比如反欺诈要准备申诉的流程和入口，垃圾邮件可能需要提醒机制和独立的文件夹等等。
除此之外，我们评价一个算法有效性的方式，也要从局部转向宏观，不能通过一条数据的推理结果去评价一个算法。
有时算法迭代升级，可能整体效果更好了，但单看某一条具体的测试数据，却可能比原来糟糕。比如我们做命名实体识别，算法升级之后，在测试集中跑出来的 F 值更高了，但可能某一条升级之前能够正确识别的语料在升级之后却不能识别了。
这是很正常的现象，尽管有点反直觉，但我们必须要把思维模式转变过来。
随着这个领域的实践和积累，我越来越相信人工智能的发展一定会给这个行业带来颠覆性的变化，就如同 08 年左右的移动，从最初的自成领域，到如今渗透至所有领域之中。我认为人工智能也是一样。
现在，我们看人工智能觉得它只代表智能音箱、智能助理、人脸识别、下棋之类相对独立的应用场景，但在不远的将来，它一定会被打散，渗透到各种各样的应用和场景中，成为新的基础设施，作为产品经理，你不要错过这一波机会。
回顾一下我今天的五点思考。
第一点是产品经理要能够深入理解小粒度的算法，并将其产品化；第二点要重视工程的力量，不要追求完全纯净的算法输出；第三点是利用产品设计，最大化算法和工程的产出；第四点是提到人工智能时代的产品经理一个特殊的职责，就是对数据的规划；最后第五点我说到机器学习算法带来的思维模式变化。
你有没有在这个行业中的实践经验可以分享呢，或者今天提到的经验对你有没有什么启发？欢迎留言跟我分享或交流，谢谢。
评论