本周工作思考

脚本编辑器
对这个项目做一些必要的总结
从去年9月份转岗到AI组，段君给我的主要任务之一就是Chatbot工程化专题，这个专题我们分两天条线走的，1是如何保证逐渐增加的Chatbo的交付速度，2是如何建设平台化能力。
从保证交付速度来说，AI这边最初的交付需要2位伙伴支持，sql和脚本分开，从我开始这项工作转到一个人身上，这样了减少协作和沟通时间，给了其他伙伴完整的专注时间， 起初熟悉整个Chatbot的工作机制，开始手写脚本，手写sql，后来基本了解了Chatbot的整体机制，开始利用一些其他伙伴写的工具，后来我继续补充小工具，可以实现根据google sheet的脚步自动生成脚本，并且能够对金句，关键词，近义词也有了一些工具处理，虽然没有形成工具链，总算有了比较完整的工具集，基本的流程和对脚本的形式上的梳理和定义，这个也是后来实习生伙伴@jihao快速接入的一个基础，以此为基础，@jihao对这些工具也做了一些补充和优化，到目前为止，@jihao作为一名具有初步编程经验和sql编写经验的伙伴，就能完全满足的现在的Chatbot脚本生成的产能，按照项目经验一天能完成平均30轮对话左右的UJT的完全的新脚本的生成。
从平台化建设的我们是按照长远的思路来考虑，现有的Chatbot的bot能力，我们也初步预想了按照现有的NLP技术的发展，我们下次大版本的Chatbot的能力应该需要什么样工程化，以此为出发点，我们如何搭建这个框架。实话说，起初我们走了一些弯路，缺乏全局的思考了，没有完全从市场侧和产品侧去考虑这类平台的产品价值和客户价值，我们的出发点是先把chatbot的数据，脚本，配置统一到一个平台，做到自动化，做的可以像admin一样，使用者限定在我们开发人员和对Chotbot的资深用户，甚至是想前端，后端，ai端我们全家桶一起做。随着我们客户的增多，和CSS伙伴的交流，和PM的交流，我们逐步认识到它的产品价值和客户价值，也就快速转变思路，专注与我们擅长的那部分，做到现阶段的最佳。这个项目的过程中间也是经历过一次错误的排期，这个责任主要在我，错估的主要是原因是缺乏了对大量隐藏需求的认知，就是不知道自己不知道，我当时预估应该会有很多坑，但是我不知道有哪些具体的坑。整体思路比较清晰，但是很多细节开发工作量不是很好评估，我当时就做了一个错误的决定，先评估我能明确知道的工作，并且低估了编码难度，随着开发的进行，问题是碰到很多，很多逻辑的复杂度和需要完备点需要的时间比我预估的多，而且投入时间也不能完全保证，还有别的工作要投入保证现有产品的正常使用。后来预定的联调阶段，我发现我认为写好的保存接口都还有很多依赖的接口有问题，我发现到重新评估排期的时候了，后来@新宇加入，我们充分吸取了之前的教训，加上我对这个项目的理解也更深刻了， 我们两个人用了2-3天的时间重新梳理一遍需求，数据，设计和接口，和前端重新同步了整体思路，这时候我对脚本生成的思路还是把python转为go，这样能节省我们很多时间，不过根据经验我们还是把整体的工作难度估高了一些，这样总时长就增加了一些，及时增加的这部分时间，加上@新宇帮我解决的了本地联调，并且传授给我go和服务端开发的一些技巧，让我们整体的开发时间比预期要少了一些，利用这两块时间，我完成了脚本生成器这快里没有确定导致的排期亏空。脚本生成器目前是存在一些遗留问题，脚本编辑器是go业务和AI bot业务的适配器，要依赖两头的能力，所以两头业务都要非常熟悉才行。我们这次的原则是关注go侧业务，尽量不动AI bot业务，这次脚本编辑器的开发，让我对我AI bot业务有了非常多的理解和认知，我想这也为后续AI bot侧的迭代打下了很好的业务上的基础。随着后续开发的迭代，我认为脚本编辑器也一定能够交付它应有的商业价值。

人到中年最可怕的事情是，没有信仰。

本周工作思考

渤健uShow建模
ASR数据准备和流程清理都很顺利，单项数据拟合不是不顺利。儿童领域的训练数据的开场白的专家打分和AI打分的拟合度不一致，AI打分的方差较大，比如有些学员的开场白缺少感谢的话，缺少明确的自我介绍，AI评分为0，但是专家整体上给分还是比较高，这种处理上就需要从整体分数上做补偿，所以不能太专注于打分细项的分数，目标是整体的打分拟合专家的打分。这个我在开始没有特别注意这一点，还是比较在意这些细项，实际实施起来难度较大，所以转换思路，先整体拟合，然后细项调优，包括配置调优和计算参数调优，然后在整体拟合。结合这周的经验和思考。下周用这个思路继续做下面的工作。
测试环境和训练目前都是基于人工把流程串联起来，辅助工具和评测，经验沉淀还没有固化成模式和平台，这其实很难定量的评估模型结构，这个作为重要的基础能力一定要构建起来，对于AI垂直类产品，需要突出三个产品工程优势，1是AI产品功能定义和业务融合，2是AI技术能力整合，3是AI功能测评和调优（反馈），第一个优势来自我们对行业的深刻理解对从业人员需求的细致把握，九年摸爬滚打的积累，我们天然的具备这个优势，这个我认为我们已经具备，现在要做的就是巩固和产品化，第二个我们对AI技术有了初步的工程应用和技术整合能力，比如我们初步构建起来AI技术的应用框架，也具有一些适合自己的开发模式，但第三个是我们目前的短板，同时这个也是最关键的，我们在未来的几个OKR周期里要逐渐构建起来。

本周工作思考

继续上周的脚步生成器的开发，本周有一半的时间用在了脚本生成的开发和完善了。测试的典型场景准备的4套，为了验证，json格式和yam格式都要写了一份。典型场景一般是多余2轮对话，所以上周设计的算法实现上问题不大，本周测试上数据比较极端，2轮对话都是自动回复，这个其实在真实的用户场景中不会出现，但是用户很可能会验证脚本编辑器和Chatbot的产品能力，可能会这么写，所以针对这些场景做了算法上的调整。之前的算法的思路是Flow，对话流的形式，把Bot和Human个字的对话分别放到队列了，因为所有的对话都是围绕人的对话进行的，所以转译的过程就是基于人类对话进行，简单说就是一个循环，Bot一句，Human一句，加上跳转结构，就形成了转译后的对话格式。这种算法比较简单，而且需要固定的对话写法，这种算法我用在了基于google sheet的脚步生成工具中，还能勉强用用，放在脚本编辑器里，就解决不了系统提示的位置问题。为了解决这个问题，把基于对话流的实现改成基于轮次流的写法，基本思路是把对话转成一个一个的对话组，这个一个对话组我称为轮次，其中包括一个对话的三个角色：Bot，Human，System，这样各种信息都存在在轮次里。总的来说，脚本转译要保留的信息包括：各个角色的对话顺序，对话内容，逻辑生成跳转关系，附加上每个对话的设置信息。
在开发过程我也遇到了一些不好解决的问题，主要有2个，Chatbot开发术语和脚本的文法。Chatbot开发术语是个统一规范的问题，本质上是开发生态的问题，这是个看起来没啥，有开发经验的伙伴都知道，关键术语的提炼和命名是系统设计的第一步，命名对了，后面的动作就都对了，这个确实十分重要的事。比如在开发过程中我经常会遇到一些命名，比如轮次，对话，场景，脚本，提示，对话失败提示等等，这些次在开发中意味概念，背后对应着开发设计思考，现在网上很难找到公认的叫法，也可能是各家的Chatbot的实现各不一样，提炼的术语也就不同。不过这也说明各家都在摸索前行，各家都各自的Chatbot的技术细节对外界都有所隐藏。
另外一个就是脚本的文法规范，定义哪些脚本是合法，哪些是不合法，各个关键词的用法如何， 比如2轮自动对话是否是对话引擎支持，一轮次对话怎么写，目前这些都还要再开发过程中逐渐完善和对齐。

本周工作思考

刘澜老师《学习力30讲》学习
春节前几个月实在是繁忙，很多工作要跟进，工作之外的时间都用来补AI技术栈上的短板，《30讲》这个课程的学习进度缓慢，利用假期时间，好好的学习了这门课，目前也还没有学完，不过受益颇多。这门课融合了很多学习方法论和思想，也凝结了作者的多年的思考和思想， 很多类似的课程在学习的“术”，刘澜老师在讲学习的“道”，学习起来确实很费力，看来要多看几遍了。看极简管理学的时候也是这样，我理解刘澜老师的主要思维模式是跳出问题看问题，细品深度较大，大处思考小处着手，有些是哲学性思考，确又给出了一些实操方法。跳出学习这件事看学习，跳出管理本身看管理，这样才能更接近事物的本质，因为这样才能看到学习和其他事物的关联，比如究竟什么是学习，学习到底是个什么事，怎么样把学习这件事做好，做好之后的结果是什么，这些问题都很不容易想清楚，做到知行合一更需要多学习几篇，再用课程里学到的内容学习课程，多多感悟。“学习”其实是自我的事情，更多的是高强度的心理活动，就像很多事是不能说清楚的一样，每个人感受到的苹果的味道大体一致，但是感受完全是自我的。这个可能就得需要多思考，多感悟，多切己。
脚本编辑器设计和开发
脚本生成服务总体上比较顺利。但也有一些麻烦的点，比如按照最初的设计，不动python的代码，从实际开发来看，我忽视了Chatbot系统配置文件是基于python的这个细节，用go修改pyhon后面不好阅读和维护，所以重新思考了这块设计，对话脚本的注册和更新统一放在python侧，归到对话管理中，这种设计其实是更合乎逻辑，符合我们对对话脚本管理的理解，道理很简单：谁用谁管理。

本周工作思考

脚本编辑器设计和开发
脚本格式转换服务开发是脚本编辑器依赖的服务，主要用功能是把脚本编辑器中存储的用户对话的JSON格式转化为对话引擎需要的YAML格式的脚本文件，并且实现脚本文件的注册和更新，涉及规则转换，文件修改，上传和下载，AI对话引擎的升级。这个功能相对独立，也是产品工程和算法的对接桥梁，考虑到开发难度和时间成本，设计思路上是尽量合理利用现有的能力，如AI对话引擎的更新脚本，现有的JSON脚本转化YAML的规则。在开发过程中我发现一个问题，就是AI算法设计和产品工程化之间的设计差异带来的复杂性，比如这个项目中，用户使用的对话是流式对话，用户一句，Bot一句，实现一轮对话，实际在AI Chat引擎一侧要加上上下文钩子，要明确说明一轮的意图和跳转的条件。我认为在未来的开发中我们要尽量的识别和消除这类差异，因为在弥合两者之间的设计差异，本身就是一件比较困难的事情，需要消耗较多开发成本，如果工程侧工程师不掌握AI侧的设计意图，就很难开发出可以持续迭代的代码，同样的AI算法侧工程师不熟悉工程侧的开发设计模式，也很难设计出易于工程侧整合的实现。

本周工作思考

脚本编辑器设计和开发
整体功能开发完成，但是还有很多不完善的地方，在联调阶段继续完善整个功能还是比较完整的现有Chatbot管理系统。为了统一设计、概念和后续迭代，我们把这套系统称之为后台系统，用户使用的Chatbot对应的为前台系统。脚本编辑器是整个后台系统中很中重要的组成部分，这个系统里包含模板和目录管理，场景管理，对话管理，部署管理，后台权限管理（目前是隐藏功能，简单处理）。后续迭代应该会有机器人管理，模型管理，积分和激励管理，话术策略（知识）管理，数据洞察管理。这10个管理模板完备之后，我认为就基本实现了UMU Chatbot的产品化过程，形成业务闭环。这个过程可能需要较长一段时间，且随着Chatbot的对话模型的迭代升级，部分相关模板也要跟进升级。 我们现在现实的脚本编辑器在可能要经过3个阶段的迭代过程，分别是研发辅助+脚本编辑器，客户界面CSS辅助 + 脚本编辑器，客户辅助设计+ 脚本编辑器+客户界面CSS辅助，之所以会长时间存在客户界面CSS辅助，是因为在数据洞察和话术策略上我们的优势会慢慢的高于客户的优势，那时候客户辅助设计的价值会得到很大凸显，Chatbot就会成为新的护城河。

本周工作思考

脚本编辑器设计和开发
随着AI开发组新伙伴的加入，人多力量大，很多工作量的进展推进的快了起来，我手里各项工作也慢慢的有序了，做模板管理的项目过程中，我对整个现在的Chatbot实现有了更多的认识，现在的设计思路，业务逻辑组织关系，模块结构和层次也有了新的认识，回过头来看之前脚本编辑器设计有点过于粗糙，比如没有考虑清楚部署里的流程，模板和大小关卡在实现上的依赖关系。其实整个脚本编辑器的整体业务复杂度不大，与过往的很多项目比，业务规模，业务复杂度和技术难度都属于中等，这个也是初期项目评估的出发点，在时间比较仓促的情况下，我过于乐观的估计了排期。经过这两周折腾的经验和思考，结合对go开发速度的认知，和新宇重新评估了后面的工作量和之前没有想到的问题。另外一个复盘得到的一个深刻认知是如何在自己优势不佳和资源不足的领域较快的取得有效结果，首先看机会，要谨慎珍惜，其次需要动脑子，想路子，多参考其他项目和其他人的经验，避免冒进，稳重求胜。在没有太多总结和认知的项目里，先慢后快节奏要优于先快后慢的节奏。另外就是对新的认知领域，能力迁移要限于认知重建和认知拓展，也就是要先认知重建，然后是认知拓展，再是能力迁移，再是能力发展，最后形成闭环。

本周工作思考

Chatbot模板管理本周底层实现重新写了一版
主要原因有4个，1是原来的实现的bug比较多，细节上不满足业务需求，2是原来的设计实现比较难维护和扩展，3是重新实现的成本相对于之前实现的维护和修复bug的成本，是可以接受的，且也方便脚本编辑器的开发，4使用新宇熟悉的权限设计思路，权限部分能较快实现，而且能和学习平台的设计思路保持一致。
这个项目我复盘了一下，1是我对Chatbot go的细节深入度不够，在细节实现上花费了不少时间，2是对go grpc缺乏经验，在上面踩了2个坑，花费数小时才搞定，3是决定重新实现的时间太晚了，上上周五就应该看到关键的问题，做出技术结论和决定，犹豫了一下，导致时间很紧张。
以后还要多花一些时间练习下go的大型产品类项目，对于技术决定一定要审慎思考，果断决定，当然这样也依赖于对整个项目和技术的掌握程度，所以在做好项目的同时，也要做好技术总结和思考。

本周工作思考

脚本编辑器接口的开发不是很顺利，开始设计了8个核心接口，在开发中发现有些功能需要单独的接口，或者以前的接口不能复用，随着开发接口增加到了14个，目前核心开发量比较大的Deploy的接口还在开发中，因为涉及chatbot的脚步的发布流程，需要串联go部分和python的异步任务，目前的单个流程可用，整合起来还是有较大的开发量和自测量。
Chatbot模板优化之前的伙伴开发了一版，我主要参与接口/proto设计，数据库设计和node
部分开发，目前看还存在不少问题，比如接口参数设计的不太合理，汇总数据不准确，模板数据的统计数据相似与企业的汇总数据，但是有很大的不同，比如完成场景数需要做多表的聚合计算，需要补充实现，另外现有库表中的数据需要较大的调整，以增加模版层数据。
随着需求的深入，系统设计上需要更细分domain，并且提供足够的基础方法，这部分是比较欠缺的很多应用层的工作量都是在补充基础方法，迭代新的设计和架构。