工作周报2024年 7 月 22 日 - 2024年 7 月 28 日

本周工作思考

凯西启尔畅 uShow 增加了误差范围的指标
这是在目前uShow参数小的情况下，对泛化能力的一种说明，调整AI的打分在和专家平均分的误差（AI打分 - 专家平均分）在人类专家打分的误差之内（专家最高分 - 专家最低分）
开场白和结束语基于大模型方法的优化
目前Prompt的优化的准确度和过往数据比较，准确率在60%以上，定性的看，会比现在方法要好一下，因为对数据安全问题的考虑，还在评估用更好的办法。下周找时间看下定量的效果，确定是否提测。
Web重点项目需求串联及Review学习
很高兴回到Web组，看到了很多好的变化，也看到了一些需要继续提升的地方，也开始准备接手Web类项目
把USE和其他的重点项目重新过了一遍。在我看来，USE是全新的产品理念和新的产品线方向，对它的理解和把握，需要继续学习一段时间。实现上还没有深入，不过看到了在代码复用上大家花了很多心思
python中的更换后redis，原计划是替换就可以了，在最近两周的uShow线下交付拟合中遇到多次服务失败的情况，经过排查发现都是redis连接的问题，刚开始思路在寻找代码实现对redis连接兼容上，在排查的时候发现redis里有大量的文本传输，由此最终确定是使用过程中超时，最终和devops的伙伴们确定更新用在腾讯云的redis以解决这个问题。

展开全文 >>

工作周报2024年 7 月 15 日 - 2024年 7 月 21 日

本周工作思考

uShow优化在实现上采用基于大模型的设计思路。迭代前的uShow的开场白，结束语中的自我介绍，感谢， 结尾的感谢都是基于传统的正则匹配算法， 主题介绍，引言，呼吁行动，议程，结尾总结，联系实际等都是基于小模型的文本分类算法。
基于正则匹配算法的缺点是匹配的准确性取决于匹配单词的多样性，就要要枚举所有表示感谢地词，正则能够覆盖60%的表达感谢地场景，但是对于有创意性的感谢表达缺乏足够的识别能力，另外就是 得分是0和1的离散值，在实际的联系，评估值要么得分，要么不得分。
文本分类小模型大部分是基于BERT的微调模型（CN和JP），确定是语义识别不准，BERT在文本分类上有较好的表现，目前的缺点是：
模型版本较低，在专业性表达上分类评估不好
需要自己找文本分类标签，在没有统一逐字稿的情况下，练习者的表达丰富多样，小模型不足以支撑这类文本分类的需求
多个模型并行，增加了程序的复杂度和计算资源
基于以上考虑，这次迭代在实现上，主要是验证大模型（GPT-4o，后续千问）的效果，主要思路如下：
基于测试数据，构造最优的多个Prompt，目标是利用大模型完成语言分类任务
利用大模型找到基于语义的各项分类，固定各维度权重
利用部分验证数据，微调分数分数维度权重
调整现有的架构，兼容以往小模型的情况下，加入大模型流程
构造验证数据，评估和微调新算法的效果

展开全文 >>

工作周报2024年 7 月 8 日 - 2024年 7 月 14 日

本周工作思考

uShow python开场白，结束语的算法调整
为了更好的解决和优化uShow的能力，我也认真的分析和很多练习者在练习过程出现的问题，如果我是每天任务繁重的医生，面对很多练习者的宣讲，我可能不会认真对待， 虽然我没有参加类似的科室会，不过尝试换位思考的话， 一次好的医药销售宣讲，会对药品的宣讲，循证，推进带来实实在在的有效缔结，会明显的提高销售效率；
uShow的开场白和结束语目前是基于传统NLP算法处理，灵活性不够。在uShow’的项目需要针对开场白中的自我介绍，表示感谢，介绍主题， 概括内容，引言，呼吁行动，议程等维度是固定的，在实际的演讲中，很多演讲者练习时会出现几个问题：
1，开场白啰嗦、模糊，主题介绍不清晰，甚至缺乏最基本的自我介绍，议程安排，引言更是缺乏；
2，开场白的基调和演讲氛围不一致，开场白需要简洁清晰，明确演讲内容，引起听众的兴趣和重视，铺垫听众情绪和后续的主要内容 ，甚至有些练习者开头很随意，直接Hi，或者口头语严重，啊，呢，一个，类似的词在开场白阶段就显露出来了，对有经验的职场人来说，这几分钟就决定了听众后面要投入怎样的情绪和精力来对待这样的分享；
逻辑性差，这个是大部分练习者存在的问题，主要表现在口头语过多，重复次过多，很少使用有效的关联词（比如，表示并列，因果，递进，时间等相关的词）
针对性指导不够，我对比了一个练习者多次的练习，我发现很多问题会重复出现，在有针对性的指导下，开场白和结束语是达到完美的状态
后续的迭代中，我们会利用AI提供针对的性的指导，针对千人千面的练习者，提供类似一对一的指导，这种指导效果会体现的练习次数的分数分布上。
CO AXA Life的uShow的分数随着练习次数的增多，分数逐渐增加，这个可能和日本用户的严谨的工作习惯有关，没有达标的练习者会持续的练习，但是在没有针对性辅导的情况下，每提高5分，要至少练习5次， 而且需要自己看回放，自己找问题所在， 如果有针对性辅导，可能最多3次，即可以提高到同样的分数。
uShow的练习是真正的提高能力的练习，这种能力即是通用能力，也是专业能力，特别对于销售人说，是沟通能力的重要组成部分。其中逻辑，产品，fab甚至是销售人员的商务沟通的核心能力。
这版uShow如果能够优化好，一定会是销售类组织销售赋能的一大利器。

展开全文 >>

工作周报2024年 7 月 1 日 - 2024年 7 月 7 日

本周工作思考

GE uShow的拟合度优化
最近uShow项目，包括GE 和 凯西宝丽亚项目，客户运营目标要求比过往的要求提高了很多，需要通过验证集和验证集的分数拟合才能继续推动项目进行，我们在保证现有项目的正常运营线，要对uShow里面涉及到的大部分算法做升级迭代。目前的主要问题是客户期望完全拟合测试集，但是难点在于：1 产品知识点拟合时间较长，一般的uShow有20张ppt，每张ppt抽取一个知识点，通过分数拟合策略，压缩到10-12个知识点之间，这个过程比较耗时，2 FAB基于微调的模型，目前很多FAB不能很好的识别；3是ASR质量较差，这个主要原因是uShow的内容都是非常专业的医疗医药知识，不同的销售代表口音比较严重，真多以上的问题，我们已经开始计划一系列优化改进上述问题
ASR数据预处理
第一次接触此类任务，耗时耗力但又非常重要的任务，找到ASR错误的句子和纠正后的句子，有点类似人工标注，但是需要高质量的标注，目前依赖大模型做初步的数据初筛，然后人工过一遍，去掉用户自己的发言错误的句子，留下纯属ASR自己的错误，ASR一般包括，插入错误，连贯性错误，口音和发音错误，同音异义词，背景噪音错误等等，这些错误有些是用户自己本身发言的问题，所以在人工筛选过程中需要识别出那些是人为错误。我们也希望在这个过程中能够积攒经验，总结经验，为数据与预处理做一些工程技术上准备。

展开全文 >>

工作周报2024年 6 月 24 日 - 2024年 6 月 30 日

本周工作思考

凯西宝丽亚数据调整
宝丽亚2套的数据断断续续调整了2周，始终没有100%拟合客户提供的训练数据，主要体现在FAB的泛化能力不高，ASR准确度需要提高，目前分数评价维度完全不能找到不同企业的专家评价特征，分数梯队不明显
针对以上问题，我们会做一些优化，使用大模型对文本的评价和目前的uShow评价做了对比，发现按照现有的评价维度，分数比较一致，解决不了分数梯度的问题，真正的问题是模型对专家打分的特点和要求没有学习到，只能适配一般的评分
稍微研究了一些现有大模型应用，比如基于AI作文评分系统，通用项上和uShow类似，但是uShow上很多专家更看重宣讲推介能力，以及分享过程中对听众的互动，共情的能力，不过有很多值得借鉴的地方，比如微调数据的整理，要重视训练数据的思想等。
正视问题，解决问题，改变协作方式，持续发展，提供对客户的有价值的解决方案
在Chatbot的迭代开发和交付上，我们犯了比较严重的错误，我们也做了几次深刻的复盘，犯错的代价很大，我们也会通过一些措施和机制来改变当前的问题，持续改进，改变协作方式， AI类项目产品化的过程任重道远，远非想象的那么简单， 我们会充分利用好团队的力量，聚焦于擅长的领域，切实做好技术改进，提高产品的技术价值和客户满意度。

展开全文 >>

工作周报2024年 6 月 17 日 - 2024年 6 月 23 日

本周工作思考

Chatbot增加命中后的提示功能开发
Python部分处理NLP相关的逻辑，Go/PHP/Node.js处理业务逻辑相关的职责。
原来我想的在Go中引入语言处理的相关的库，比如jieba，后来在不断思考这个事情，觉得不妥，原因是Go和Python的优势不同，Go的技术栈优势不在NLP上，而NLP恰恰是Python技术栈的优势。
Prompt管理设计思考
从架构上考虑，Prompt适合多层管理，系统层和业务层的分开，且可以支持非上线部署和测试评估，支持多模型的业务适配。
从工程上考虑，我个人认为Prompt的难点在评估数据的管理和应用，评估决定了Prompt的性能要求，评估指标的建立也是对AI能力理解应用的过程。
最近关注的行业相关的大会
最近Qcon北京，鸿蒙开发者大会，掘金社区的开发者大会，世界智能产业博览会等都有关注，大家都在谈论AI，但是我们感觉还没有现象级潜力的产品出现，很多是AI平台级的基础设施类产品，其实这个很好理解，这些产品的背后都是和学术圈接近或者从学术圈出来的研究人员主导参与的，他们对底层技术和基础设施更理解，很多的应该是感觉上是从实验室的流程标准化和产品化。
另外一个点是AI和大模型开始越来越快向传统细分行业渗透，比如中医，医疗，装备制造，电力，化工，汽车，兵工等，中石油的一款AR头盔已经投入使用，主要用于模拟训练虽然这类产品在其他行业早有落地，中石油作为央企的头部企业在使用这类产品，我觉得是对AR和VR有很大的促进作用，这个和东朔老师两三年前设想是一致的，未来的教育和培训必须是基于元宇宙的，让我们拭目以待。
我觉得大家都在探讨的话题是AI时代我们该做什么？随着C端用户和B端用户对AI的认知逐渐加深，他们对AI的需求和期望也越来越多，越来越高，很可能会体现企业的明年的采购预算上，体现在对在用产品在AI能力的表现上，以及对AI解决方案的预期上。
在AI的技术和产品上，我觉得有两类用法，一种现有业务形态加入AI能力，改善现有业务形态，另一种是AI产品乘以现有业务形态，创造新的业务形态，有点拗口，但确实是两个完全不同的思路。

展开全文 >>

工作周报2024年 6 月 10 日 - 2024年 6 月 16 日

本周工作思考

Chatbot增加命中后的提示功能开发
目前还在设计阶段，目前Chatbot的实现总体上说是比较乱的，在现有的实现基础上的扩展可能要要梳理清楚一些异常情况，比如一些未知的逻辑处理和潜在的bugs.
目前Chatbot的扩展的基本思路按照需求灵活扩展，使用最合适的技术完成功能，不能沿用原有NLP实现的传统思路。该功能是python部分的chat接口增加hit_tips字段，对应的go部分，node部分的protobuf都要增加对应的字段。
GE uShow
这套uShow的专家打分和AI比较相近，细调之后，相关系数接近0.9，方差也非常接近
在项目实践上，逐字稿的打分一般做基准来看。不同的专家打分对学员呈现的结果的思考不一样，一般要求简洁的开场，有些学员的开场比较长，但是具有较好的引导效果，专家的分也很高，当我们去拟合这类视频时，就会对其他简洁的视频的产生一定的影响。本质上客户提供的数据还不足以提炼出较好的特征分类标签。

展开全文 >>

工作周报2024年 6 月 3 日 - 2024年 6 月 10 日

本周工作思考

uShow项目的一些思考
本周重点还是在uShow上，相对于Chatbot，uShow的实现更加复杂一些，交付的情况也更加复杂一些。目前采用的一些方法，包括定期观察实施客户的分数情况，使用频率，通过和CSS伙伴了解一些客户的运营思路，来大概上摸清用户怎么理解uShow的，以及uShow在业务赋能的作用和潜力。
这一段时间以来，不知道大家有没有注意这样的情况，很多别的行业的公司在兴起一种探索的AI的潮流，各种评比，各种评选，内部技能大赛等等，都在重点强调要利用AI。我认识一些朋友是其他行业的一些员工，其实他们对于AI是什么，大模型是什么，它们能解决什么问题不是很清楚。通过一两个case，我有几个观察和思考：
1 要利用好AI首要要明确自己所在所在业务是什么，我的一位在鲁南医药的做质检的朋友，公司要求员工们积极进言献策，利用AI工具，做一些降本增效的事情。但实际情况并不是很美好，因为他们停留对大模型的简单使用上，只解决自己的效率的问题，比如出检验报告，比如核对正确性， 因为我这的这位朋友不是很清楚的知道他做在的岗位，他的上下游都存在什么的问题，他们也不是很清楚如果解决这些问题，对实现企业目标有和帮助，如果AI只是对个人效率的提升，对于很多流程线上的职员来说，这类工作没有办法标准化，可以说没办法可衡量化和绩效化， 这就很难计算它在企业整体中的成本和价值，我觉得这就没有充分发挥AI的价值。大模型的能够解决经营管理的问题，丰田公司的伟大之处，我觉得在于通过改进流程释放了巨大的生产力，SAP，Salefore之所以非常成功，是因为它们改进或者优化了生产流程和协作方式，提高了整个企业经营效率和生产效率，进而让企业获益；
2 AI/大模型解决思路和解决方案和应用AI的能力应该是从现实业务中长出来的，而不是种出来的，AI在业务的变现能力是在企业内部一次一次的微创新中成长起来的，中国软件的30年发展没有解决解决我们企业发展的所有问题，所以我也没有理由相信大模型会在几年之内解决企业发展中的所有问题，所以我认为对多很多行业来说，AI的能力成长是一个长期的剧烈的痛苦的变革的过程。同时未来很多业务类公司，管理咨询类公司，管理培训类公司，行业协会会大大增加 AI/大模型解决方案 这样的项目建设
3 另外一个问题是，软件和AI的关系怎么样的，如何让大模型利用现有的软件，如何让这些业务公司的已有的软件资产，软件数据，和大模型系统打通，如何让它们相互协作，在我目前的认知里，AI还不能单独存在，而Agent也是AI与现有环境协作的一种方式，也不是全部的方式。
4 结合上面的思考，uShow在本质上改变了培训部门和业务部门的协作方式，实际上是对业务流程的重塑，我觉得我们的探索的方向绝对的在赛道上，但是uShow还需要更深的嵌入在业务里，更广泛的利用客户已用的数据资源
uShow的项目上客户对uShow的泛化能力提出了更高的要求，这实际上对uShow各种算法提出了更高的要求，同时我们目前在交付流程上，对验收环节还缺乏标准化的指标和规范，对交付后的实施过程还缺乏有效的监控和管理，这些都有可能会影响续费和客户满意度，我想这可能是我们未来在这类项目上一个工作重点。

展开全文 >>

工作周报2024年 5 月 27 日 - 2024年 5 月 31 日

本周工作思考

uShow项目的一些思考
整体而言uShow的架构我认为还是不错的，特点是基于任务调度的，具有灵活扩展性的分布式微服务系统，这个架构和实现能够满足和覆盖现有的产品设计要求。 产品设计中的分数计算被细分成不同的维度，这些不同的维度被被被实现为不同服务，整体的分数计算可以理解为由消息连接的图计算系统，也可以看成是一个map reduce系统， 服务可以被方便的替换，新增，升级等。
从我的分析来看，uShow目前的工程架构目前不需要变化，在AI算法升级和交付工程化逐渐显露出一些需要解决的问题。
随着客户对uShow这种产品理念的理解的加深，客户的在训练上增加了更多的潜在的需求，比如逻辑关系，产品知识点的总结，FAB的提炼能力，另外客户uShow课程的运营思想和运营能力也在不断提高，也更加希望uShow能够提供更深入的分析和更多的产品价值，从这个角度出发，uShow需要提供对客户的PPT演讲内容更深入的分析，比如Logic，按照目前的算法，很多学员的知识点都能覆盖，但是知识点的表达方式去很大不同，有些学员的运用了一些演讲技巧，比如提问法，反问，转折，递进等等逻辑关系，但是目前算法实现上我们对这些比较好的演讲技法还缺乏有效的识别和分数计算逻辑。
在各种分数的计算上，uShow整体上经过了2个版本的迭代，目前算是比较稳定的版本，但是各个不同的算法上需要进一步的丰富，比如在开场白中引言处理，感谢处理，关系拉进处理，演讲背景处理，目前看还需引入新的算法和大模型工具做进一步的升级和完善。
在交付上，最近我们也在做一些推动和落地，在效率上比之前有了一些提高。uShow目前的交付上最大的难点是给Product,FAB等反向找出最恰当的分类标签，这个过程是和模型的训练的流程是基本一致的，要不断循环迭代调试那些文本最能适配训练视频中的专家分数，所以这个过程需要一些自动化的工具，提高效率和找出最佳文本标签。目前的工具能提高循环迭代的这个效率，但是如何找出最佳标签，这个还需要一些探索。

展开全文 >>

工作周报2024年 5 月 20 日 - 2024年 5 月 26 日

本周工作思考

在处理客户反馈问题时，小失误很可能会演变成大事故，这段的感受就是客户问题无小事，不管是开发客户需求优化点，处理客户问题，评估解决办法，都需要谨慎稳重。且需要考虑全部包括技术方案和业务解决方案，同时要权衡好短期利益和长期价值的平衡，比如一个客户反馈的问题，可以很快的解决，但是其他用户可能会遇到，但是理论上概率很少，我们该采取何种办法，或者哪些办法，我觉得这需要我们对客户，市场，产品，技术都要有较好的理解。这个过程也让我对PMF有了更深的了解和理解，也渐渐积累了一些实战经验。
经过最近的一些坑，我不端的反思和思考，一款优秀的产品的价值究竟体现哪里？同时我也逐渐认识到好的SaaS产品不仅仅提供软件，它是由一系列的服务构成的。站在客户的角度，客户需要在他所在行业求得生存，谋求更好的发展，同样的用户也需要在Ta所在的企业取得更好发展 ，如果在这个目标上给予客户和用户最大的支持，使他能够更好的发展，我认为这是产品的最有效价值，也是我们发展的最强动力。

展开全文 >>

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

程序员，关于技术我所知甚少，唯有探索，方得真知。