反思复盘Astellas Chatbot项目反馈问题
问题有四类，1是我的Chatbot掌控不足造成的，2是客户的需求，3是Chatbot的待提升的地方，4是脚本创作上，也就是提供给客户的Chatbot解决方案上的漏洞，下面分别说说
提升TTS的准确率，专业术语符合医疗专业的发音要求，优化现有生成工具，使用生成脚本和手写脚本时增加TTS发音纠正
平假名和片假名只能出现在TTS里，日文书写习惯汉字
CO的Chatbot在实施时要考虑ASR的词汇表更新，目前这块需要人工导入
系统提示，金句和关键词命中错误提示使用给定格式，优化现有生成工具
多学习日语语法和文法相关的知识，提升日语文本语法分析能力
提升Chatbot的可配置能力，目前客户提出的一部分看似简单的文本配置要求，现有实现化不能快速实现
持续完善自动化脚本生成的规则，包括TTS和给定读音的映射，还原文本格式，关键词和近义词的映射，ASR识别的历史存留及分析
对Chatbot研发侧2024的思考
建立Chatbot高质量交付框架，提升Chatbot项目脚本交付的专业性，减少客户问题的反馈，提升客户满意度
解决已知的关键问题，包括提升Chatbot的企业自主管理性 ，如企业灵活多样的配置，多维度的数据洞察，灵活的脚本创作管理（如基于AI生成式的脚本，基于规则约束的脚本，基于限定主题的脚步），场景部署管理，灵活的对话纠正机制（管理者对训练者的每一个对话进行点评，类似导演对演员的的点评指导）
整合到UMU学习平台，如数据看板，任务分配，协同管理，脚本创建，权限管理，Chatbot小节化，Web端Chatbot
提升对话灵活度和上下文串联度，现有框架下对话的灵活度取决于脚本，实际上是取决于脚本创作者对客户预训练对话场景的理解和设计能力，未来我们提供脚本创作工具，更取决于客户对脚本的创作能力，所以要提供一种新方式，降低对客户创作能力的要求，比如像uShow一样提供一些素材，我们就能做出评分，当然Chatbot难度比uShow要大一两个数量级，uShow本质上是分类，Chatbot本质上是基于主题的有序生成，不可控的因素更多，但我认为这个这个课题是未来我们赢得客户的关键
持续思考可定义的对话管理框架的建设，比如场景情绪模板，对话风格模板，灵活对话， 在脚本配置过程中，我发现不同的企业中在不同的对话的情绪，语调，人物都有巨大的不同，有的是零售店里导购和年轻妈妈，导购和中年健身达人，经理对下属的指导，医药代表对普通医生，医药代表对科室主任等等，这些场景其实是不同的情绪，不同的语境。这些其实都是对应着销售能力的中的不同部分
我相信Chatbot是让企业内的普通销售成为金牌销售的关键一步，这也是Chatbot的最重要的价值体现，优秀的销售在和关键客户见面之前，都是在心里预演了很多次。如果我们能够让普通销售也能够像金牌销售那样，因为用Chatbot预演了很多次，所以面见客户时更具推介力，说服力，谈判力和领悟力，所以更多的企业会因此而赢得市场
uShow的问题的思考
从UTJ伙伴和客户反馈的问题看，AXA Life这类保险类的销售话术在FAB上打分过低，之前我们从分数分布上做了抬分计算，但由于FAB整体得分较低，抬分计算还是有些局限。后续需要从模型训练和分数计算两个维度上做一些针对性的调整。
本周的排期十分紧凑，Chatbot的项目基本都是Deadline的项目，虽然Chatbot的部署过程已经非常熟悉，也有部分脚本和工具的支持，但是整个过程还是依赖人工，也有点手忙脚乱，还是会时不时的出现小状况，最近这一段时间遇到了好几个简单的问题，如数据闭合数据错误，robot的男性和女性的设置错误，robot头像URL多了空格等问题。犯过这些错误，才更深的领悟“简单的事情重复做不出错，才是不简单”这句话背后的道理，重要的事情就是那些真的要去加快做的。做技术工程的工作应该把“预防和防范”的工作做好，大部分技术工程上遇到“紧急重要”的工作，都是在为过去的不及格的工作埋单。由此出发，把当前工作做得极致就是为了让未来更轻松，有更多的时间考虑更重要的事情。多年以前我就在想如何判断当前的工作我是做到极致了呢，现在我想，当我开始问自己这个问题的时候，我的思维就陷入一种定势思考，不同的工作，在不同的认知层次，在不同的维度，其卓越度和完美度怎么会有统一的标准来衡量，最近在阅读日本企业文化关于“师匠精神”的解读时，才真正有所领悟，当工作结果和自身人格荣辱直接相关时且又拥有极强的自尊心时，这种情况下往往能得到工作结果的极致状态。
持续完善Chatbot项目的工程侧实施过程。 诺和诺德东南区Chatbot的项目做的不太顺利，最初的计划是按照老数据升级到新数据， 在UCS-v2版本上部署，基础数据准备好了，我们却低估了数据切换这个事的难度和时间。在不同的数据结构上切换数据有很多细节确实主要，@寅涛在这个该过程中做了很多细致的工作，比如勋章，积分，老的库表结构没有记录那么多的信息，需要老数据的拆分填充在现有的数据结构中。这个项目要改进的点有四个：
（1）虽然现在Chatbot的部署上线比较快，但是还是不能大意的预估时间， 这个项目和客户推迟了一次时间，那时就应该想到立即解决客户的需求的问题，而不是依赖内部的UCS的切换；
（2）早做准备，全面计划完备，虽然对脚本做了Review，上线后却发现客户提供的账号没有Chatbot权限，关卡的设置没有确认， 当天晚上又和年兰沟通确认，耽误了一些时间；
（3）代码的历史还是需要再深入理解一些，最后在老脚本上写的SQL脚本，我不得不把那个库表结构彻底的整体分析完整了，才完成脚本的编写，如果这个之前有了解，不至于当晚做的很匆忙。
（4）随着经验的积累和对Go代码，Python代码的熟悉，基于目前版本的Chatbot部署的自动化的思路也逐渐清晰，有了更深入的把控。
数据切换会让Chatbot彻底甩掉老版本兼容的这个包袱
建设和完善uShow实施部署的Master Doc。 AXA Life uShow的项目整个跟进下来，我基本掌握了整个部署和实施的基本过程，也在逐渐的建立和完善Master Doc，另外随着对uShow过程和Chatbot的理解的理解的深入，对整个架构体系有了一些初步的认知和理解，并已经开始独立承担具体AI业务的开发，思维模式也逐渐的切换回到了服务端开发角色，对与安全，性能，日志，监控，稳定性更加敏感。前端功能在架构和设计上更侧重扩展性，敏捷性和具象性，而服务端更侧重鲁棒性，可靠性和适度的抽象性，特别是AI类服务端开发对于性能，模型选择有更多的要求，比如HuggingFace有数万的模型可供选择，如何选择迭代最优的模型，如何评测模型效果，如何设计最优的模型组合，还都要不断的实践和学习。
在编写Chatbot脚本时学到了很多沟通的技术和一些固定话术，这些都是我以前不曾注意过的，之前也不曾总结过沟通的模式，联想到之前曾学过如何提问或者探询的书籍，但是确实没有掌握书中所讲的技术的，这其实也说明，我读的并不深刻：记忆，理解，应用，融会贯通这四个层次中，我似乎只在第一二个层次徘徊。回到Chatbot上的对话式训练，我理解背后其实是认知模式的固化，当时第一要形成嘴巴的肌肉记忆，训练达到在与客户的谈判和沟通中“信口拈来”，例如一个场景中AI说：医院管理政策限停了某些药物，而我们的药恰在其中。在遇到客观的障碍和限制时，如何应对，这是在不同的场景下，不同的企业里，不同的团队文化里，都是经常遇到的问题，且立场都是很不同的，有些要虎口夺食，有些要立即改弦更张，有些要长线跟进，这时候就特别需要Chatbot的这种剧本式的对话，在对话实操中将认知和价值观渗透到对话了。在深入思考Chatbot的对话形式时，我现在还没有想明白的一件事，在技术上如何将人的信念和立场统一的嵌入到对话过程中。
本周集中处理UTJ团队反馈的一批Chatbot上的问题，主要是性能，响应度的问题，有些是持续一段时间了，有些是新近发现的，针对这些问题我也做了一些总结和复盘，压测和性能监控已经在进行中了，常规的自动化测试和巡检需要运行起来，另外就是完善问题跟踪机制，提升对Chatbot运行状态的把控度。
这周排查了AI微课/AI字幕/Chatbot等三个大功能的相关问题，问题各不相同，因为一部分问题的原因还没有最终确定，问题原因先不做复盘总结，不过可以复盘下自己在排查过程中的反思和总结：
在排查过程，我发现自己对服务端很多解决问题的心智模型缺乏足够的理解，也不够丰富，比如在任务调度，微服务架构实践，Devops实操等存在不少知识盲区，所以后续一段时间一定要把这些内容快速补齐。
和AI相关的业务比较复杂，和非AI业务相比，AI业务多了一层AI异步任务及其调用，为了有效的解耦AI服务层和具体的业务层，中间增加了基于Go的Gateway层，AI服务层天然的具有服务自治要求（安全，性能，稳定性，成本构成，第三方服务隔离等等），服务扩展需求高，AI算法服务的独特性，服务部署灵活高等隐性的架构需求；当AI服务需要依赖其他非AI类基础服务时，比如用户，业务权限等，基于Go的Gateway层又是聚合层。用户端侧因为要整合不同的业务接口（包括AI类接口，其实在用户端侧无需区分是AI类接口还是非AI类接口），所以增加了对用户端友好的Nodejs层作为BFF层。BFF是Backend for Frontend，字面意思能够很好说明其在整个架构中的作用，接近前端的后端层，说它接近前端指说它转为前端提供服务，对前端足够友好。这里所说的前端是指Web，APP，微信小程序，钉钉/企微Hybird及小程序、客户服务对接层等，从这些前端的种类就可以得知，这一层的职责主要是适配，整合，路由等。用户端侧目前需要的服务调用方式有两类，1是Restful的http接口调用，2是websocket的长链接类的调用，但Nodejs层目前没有提供websocket类的调用能力，所以部分基于长链接的AI服务时通过Go层直接对外提供的。这里其实有两个重要的关于架构选型的上技术实践讨论，1是AI的gateway层为什么是Go而不是PHP，2是PHP层为什么不直接做BFF层。坦白说，要搞明白这两个架构问题非常之难，显然这些问题没有标准答案，甚至也没有参考答案，实际上我们在摸着石头过河，也就说我们在探索。脱离现实的业务和约束条件谈架构设计都是无意义的，实际上我们很难找到一个即懂AI及工程，又要懂PHP，又要懂GO，还要懂Nodejs，还必须理解我们的业务场景和既有的条件约束，更重要的是还要理解未来产品发展路径。所以当大家讨论这个问题，总是站在一个这样的位置：对某个或者某两个领域非常熟悉，对其他几个了解的基本情况下讨论这些问题，这样就会造成每个决策理由都很充分，但是整合起来的架构又不足以解决所有的需要被关注的关键问题，所以最好的方案是先关注优先级最高的关键问题，在迭代过程中不断丰富知识和总结经验，探索最佳方案，以解决所有的关键问题，这个其实很像寻路算法，在探寻中才能找到下一步，而且不管正确或者错误，必须前进一步。
在@柳祎的细心的指导下，比较全面的掌握了目前uShow产品的数据拟合和打分系数调校的整个流程，虽然对逻辑细节和服务端部署过程还不是很清晰，至少可以承接部分uShow项目中比较繁琐的工作，方便后续把这块工作自动化的设计开发。
近期uShow项目及Chatbot项目，也让我的成长的压力和动力越来越大，一个是要在比较短的时间内让自身的知识结构和能力需要发生剧大的变化的要求，从一名前端工程师要快速转变为擅长后端工程及业务且熟悉AI算法的优秀工程师。我印象最深的一次排查问题，从Flutter，Nodejs，Php，Go，一直看到Python，这里面我觉得最难的是理解每个技术栈背后的思想和要我们要解决的问题以及其独特的设计特点；另一个压力是基于目前的Chatbot和uShow产品形态，要建设比较完善的工程能力的紧迫性，每个自动化能力的建设都会比较有效的提升整个团队的效能，但是又要保证目前日渐增长的产能需求。我觉得要适应各种约束条件下继续保持专注的态度，以创业的心态，聚焦在当下投入产出比最高的事情上，给重要的紧急和重要不紧急的事情分配好时间，保持自律，把全部的精力放在低头做事上。“悲观者或许正确，但乐观者才能创造未来”。
最近几周最有震撼的书籍：《美丽的化学结构》。
最近断断续续读了很多书，因为大部分是在地铁上断断续续读的，很多书没有读完。小部分的在精读，但是能够分给读书的时间又实在太少了。
坦白说，地铁上只能使用泛读。我曾经尝试在地铁上精读，我发现非常不爽，手写笔记就不说了，当你长时间思考，联想时，总是被打断。特别是读到精彩处，到了下车的地点，这时候真的是讨厌的很。
《美丽的化学结构》是那种特别适合泛读，但是有很大程度上改变认知的这种书，看到这些奇妙的化学结构，无与伦比的美感冲击你的脑海，那种认知震撼真的太爽了。
对于这本书，我觉得任何的读书笔记都是多余的，因为他里面都是化学结构的图片，一个结构一个图片。我们看不见的神奇分子，蛋白质都在他们那个度量尺寸上表现的有序而完美，真的感叹造物主的神奇与伟大。
当你看到这篇唠叨的文章时。我推荐你去看一看。
模型训练
标签数据
模型管理平台
推理SDK
业务后台
tag:
缺失模块。
1、请确保node版本大于6.2
2、在博客根目录（注意不是yilia根目录）执行以下命令：
npm i hexo-generator-json-content --save
3、在根目录_config.yml里添加配置：
jsonContent:
meta: false
pages: false
posts:
title: true
date: true
path: true
text: false
raw: false
content: false
slug: false
updated: false
comments: false
link: false
permalink: false
excerpt: false
categories: false
tags: true