-
总体评价: 1.因为不熟悉运维,如果光从数据挖掘的项目来看是没有看出什么问题。但如果真正部署到生产环境中,却需要与syslog、SNMP等进行联动,然而在本次的NAIE体验中没有看出这些相关的操作,感觉NAIE像是之前MLS的改良版。 2.包依赖问题,能否只下载一次呢?用sklearn如果在本地,就算是几万行数据+sklearn也是秒算,而NAIE每次都花1分钟来下载,会让一部分人着急 3.自带Demo全流程,这点好评 4.明明是用sklearn,却要选TF,这点比较奇怪 下面是标准问题: A.是否容易上手,模型训练服务内使用帮助是否能解决遇到的问题,需要增加哪一类的使用帮助; 答:容易上手,但指导书最好不仅仅是只有图标,并且有全屏截图标明位置 B.对于产品性能,操作便捷性,可视化界面等有什么建议; 答:见上面的总体评价 C. 你觉得哪一模块可以使用其他更优的方案替代; 答:数据预处理上,最好有相关的指导说明。 D. 使用过程中有哪些不好的体验,是否出现异常,无反应无提示的状态; 答:主要是从秒算,变成花2分钟,不习惯 满意度及推荐度:当有AI平台需求时,您是否愿意推荐NAIE模型训练服务?理由是? 答:满意度(6分,10分满分来计),推荐度(1分,10分满分来计) 不愿意推荐NAIE,因为用sklearn在本地是秒算,也没有像ModelArts那样需要云端大算力的需求,并且没有提供从SNMP、syslog一直到推理运维AI流程。
-
作者:黄隽(Charlie)背景敏捷江湖桃花岛社区下线会议时,敏捷实践者问了很多关于估算的问题。作者在这里把具有共性的问题简单做了梳理。问题主要集中在团队只关心估算结果,也就是数字。再则团队经常在外界压力下过度承诺迭代目标。这两个比较集中的问题描述如下:问题一:团队只关心数字。计划会议大家只关心估算的数字,经常花费大量时间做估算,怎么办?问题二:团队过度承诺。有时候,团队被迫承诺过多的工作,迭代目标完不成,怎么办?团队用于估算时间过多,留给开发的时间会相应减少,大家工作紧张,状态不佳。团队过度承诺直接造成迭代目标不能完成,士气低落。以上弊端直接伤害敏捷团队,是敏捷团队保持稳定健康节奏的阻力。问题分析以上两个问题也是敏捷初始团队经常遇见的问题,现简单分析发生原因如下:问题一:团队只关心数字。团队从瀑布开发方式转为敏捷开发后,学习了敏捷Scrum框架,然后开始使用敏捷开发。他们知道其中有一个事件是迭代计划会议。在会上团队成员经常耗费大量时间做估算。常见对话:“这个估算数字合理吗,我们要不要再好好想想清楚?”因此团队常常陷入无休止的讨论中。团队狭隘的理解为,计划会议中最重要的事情就是估算,而估算最重要的事情就是得到每个用户故事完成所需要花费的精确时间,即数字。也就是说,团队过于追求数字的准确性,忽略了估算的真正核心价值。问题二:团队过度承诺。团队经常在产品上市日期已经确定的情况下过度承诺。因为时间紧迫,领导施压(与资金和绩效挂钩)。比如,领导经常说:“大家加把劲儿,我相信大家的能力,努力一下,这些需求你们是可以做完的,大家的表现会影响绩效评估,年底咱们多发点资金。”所以团队常常了了估算、一言堂(架构师说的算)、猜测工作量,最后造成过度估算,经常完成不了迭代目标。小结“团队只关心数字”和“团队过度承诺”两个问题是敏捷初始团队经常遇见的问题。从以上问题分析中可知,团队成员并没有了解估算的真正核心意义,导致团队狭隘地理解成估算就是要最后的数字,而且在有外部压力的情况下团队也顾不上认真估算,盲目地过度承诺工作内容。其实估算并不只是为了得到估算数字和不靠谱的承诺。我们先一起学习和了解什么是估算的核心内容,这样可以更好地理解估算,然后再针对以上2个问题进行解答。解决措施利用核心概念树立正确认识在这里,我们只考虑不了解核心概念而导致估算活动不理想的情况。还有其它情况可以导致估算活动不理想。比如,不会利用故事点估算、不会估算具体方法等。这两种情况我们在后续的2篇文章中给予解答。通过上一篇《估算第一篇:利用用户故事了解需求》相信了解了如何利用用户故事理解需求。如果对用户故事不太了解的朋友,建议可以花一点时间阅读上篇文章,也会有助于做好估算。现在我们一起了解一下估算的4个核心概念,以便理解估算,树立正确认识,然后才能更好地解答以上2个问题。估算的4个核心概念所对应解决的问题如下表所示:问题估算核心概念问题一:团队只关心数字。利用“区分准确与精确”:估算应该准确,但不必过分精确。利用“估算相对大小”:人们更擅长对大小进行估算,而不是绝对大小。问题二:团队过度承诺。利用“团队一起估算”:在估算活动中,团队成员一起估算,结果更合理。利用“估算不是盲目承诺”:估算不是承诺,重要的是我们不能这样认为。区分准确与精确估算应该准确,但不必过分精确。比如,我们估算某产品是10888人时(是怎么做到这么精确的?)。其实这是很荒唐的,过于精确的估算纯属浪费。我们需要应该投入刚好够用的工作量,得到一个刚好的、大致正确的估值,如做估算时工作量和准确度的对比图所示:做估算时工作量和准确度的对比图在做估算时,有一个收益递减的点,在这个点之外,额外投入任何时间和精力都不会使估算更准确。在这个点之外,就属于浪费时间。团队成员在做一项工作的同时,难免会遇到各种各样的问题,所以为了做到准确估算,在做估算时,任务的拆分一定要适当细,只有细化后,团队成员才清楚每项工作预计会花多少时间。当然细化也是有个度的,如前面提到的做估算时工作量和准确度的对比。当团队成员反馈超过预计工时时,需要了解是不是遇到了什么困难,需不需要帮助解决。超过16小时的任务建议需要再细化。在做估算时,我们经常会填写预计工时和实际工时。预计工时是我们估算的结果,实际工时是对估算结果的检验。我们允许预计工时的不准确,但是一定要填写准确的实际工时,这样才有助于我们在估算不准的问题上有充分的证据做分析,然后改进,进行良性循环。随着团队成熟度的提高和对业务的越来越了解,估算准确度经过几个Sprint会有所提高。估算相对大小建议使用相对大小而不是绝对大小来估算PBI。比较所有条目,然后确定某个条目和其它条目的相对大小。如下图所示,讨论一个杯子相对于另一个有多大比较容易,但对于杯子中可以盛多少绝对数量的液体,我们可能没有概念。相对大小对比图人们更擅长对大小进行估算,而不是绝对大小。让团队成员做估算,建议用大家都擅长的技术。当然,有些较成熟的团队,也可以借鉴历史数据和经验,直接应用工时或理想人天估算也并非不可。更多关于相对大小的内容介绍,可以阅读下一篇《如何估算第三篇:估算故事点》,其中会介绍一个具体实践,即故事点估算。团队一起估算而不是个别人估算在估算活动中,团队成员一起估算,而不是仅仅由项目经理、架构师、主要程序员估算。简单说,是负责完成工作的所有人,也就是指实际动手设计、构建并测试PBI的开发团队来估算。产品负责人和Scrum Master这两个角色都在场,但并不实际参与估算。产品负责人负责阐述PBI,并回答团队要求澄清的有关需求的问题。Scrum Master负责帮助指导和引导估算活动。最终的目的是开发团队能够一起确定每个PBI的大小,当然包括开发和测试的所有工作量。团队成员一起估算也是为了确保工作没有遗漏,不管怎么拆分任务,甚至是不拆分任务以story为最小颗粒度,那就按照story可以上线为标准来估算。如果团队非常关注每个人手头上的task,比如测试和开发人员手头上的task,那就没有统一标准,根据具体task内容估算。 记录工作项工时,可以参考华为云DevCloud,工作项工时显示如下图所示。需要客观估算而不是盲目承诺估算不是承诺,重要的是我们不能这样认为。举一个例子,如果在估算的时候告诉团队成员他们的估算正确性直接影响着他们的奖金和绩效,那么每个人都会给出一个比开始大得多的估值。估算应该是较为实际的估值,应该靠谱,我们不想因为外因而人工放大估算值,变成团队成员往上加和管理层往下减的抛球游戏。所以,团队成员在没有外因干扰情况下,大胆、放心的估算工作量,也就是估算预计工时。预计工时不仅仅是用于安排任务和估算本Sprint PBI在哪个时间点完成的,它还可以用于持续改进。预计工时就是估算需要多少时间可以完成,在Sprint进行中,会让团队成员根据实际情况去更新实际工时。例如,昨天更新4小时,今天又更新4小时,那就把实际工时更新为8小时。当Sprint结束后复盘时,我们会整体看这些预计工时和实际工时的数据,主要是为了提升团队/个人估算水平。如果估算和实际有明显差距,是需要深入分析的。本身也是期望通过估算促进做简单设计。应用正确认知处理问题,做好估算以上是估算的核心内容。现在我们回头看看之前的两个问题。问题一:团队只关心数字。面对这个问题,作者主张团队成员不要只是关心数字,还要关心投入产出比(ROI),避免浪费。另外还可以考虑采用更快、更易于理解的方式来进行估算。从估算的核心概念“准确与精确”中了解到,在做估算时,有一个收益递减的点,在这个点之外,额外投入任何时间和精力都不会使估算更准确。在这个点之外,就属于浪费时间。另外从估算的另一个核心概念“估算相对大小”中了解到,人们更擅长对大小进行估算,而不是绝对大小。让团队成员做估算,建议用大家都擅长的技术。因此,我们在做估算时:首先,要把握一个估算的适度准确原则,不要过度浪费。其次,为了降低难度,团队更好的达成一致意见,可以采用相对大小方式进行估算。问题二:团队过度承诺。面对这个问题,作者主张估算由真正完成工作的成员在安全的环境下大胆、放心地估算,避免过度承诺。从估算的核心概念“团队估算”中了解到,估算活动是负责完成工作的所有人,也就是指实际动手设计、构建并测试PBI的开发团队来完成。也就是说,真正完成工作的人才会对工作需求内容更用心,也更了解团队的速率,他们的承诺更客观。估算另一个核心概念“估算不是承诺”中提到,估算应该是较为实际的估值,应该靠谱,我们不想因为外因而人工放大估算值,变成团队成员往上加和管理层往下减的抛球游戏。团队成员在没有外因干扰情况下(不建议奖金、绩效明显挂钩),大胆、放心的估算工作量。如果能做到以上相信至少在估算的结果上更为客观和靠谱。有些朋友可能会问,如果得到的估算结果是靠谱的,完成需求就是那么多工作量,产品上市日期也已经确认,那么怎么办?如果真的是因为产品上市日期已定,有上线压力,团队一定要承诺过多的工作内容,那么就确保团队把故事拆分得更细,即使他们交付不出设想中的高档理想的全功能版,至少也能每个典型的功能领域多少交付一些内容。说到这里,还是不建议这样做,尽量采用高价值的事情优先做原则,与客户协商,产品经理对需求排好优先级,优先实现高优先级的PBI。了解更多以上是针对不了解估算核心概念而导致估算活动不理想的解决措施。朋友们看到这里,相信对估算的核心有了基本了解。也许对什么是故事点估算以及具体估算方法感兴趣,欢迎阅读接下来的关于估算的另外两篇文章,即《如何估算第三篇:利用故事点做估算》和《如何估算第四篇:利用2种常见方法做估算》。参考附录Kenneth S. Rubin. Scrum精髓[M].北京:清华大学出版社。Mark C. Layton. 敏捷项目管理[M].北京:人民邮电出版社。Rachel Davies. Liz Sedley.敏捷教练[M].北京:清华大学出版社。附件:如何估算第二篇:利用核心概念解决估算常见问题V1.2.pdf[hide]链接: https://pan.baidu.com/s/1qQHK_WxG_9YQOKIm8MO8aQ提取码: g6vn[/hide]
-
华为云NAIE服务体验报告Motozilog智能化运维取代传统的人工运维是近年的一个趋势,特别是互联网场景下动态横向扩容、微服务、CDN、NoSQL等应用越来越多。但是从事一线运维人员通常是刚毕业的学生、编程基础较为薄弱、学历也不需要本科(毕竟公司是需要节省成本)。是否有一种服务能像ModelArts那样能使不用懂AI原理的人也能“傻瓜式”进行AI应用运维场景呢?带着这个问题,参与了华为云NAIE服务的体验。按照体验指导,创建硬盘检测。本来以为NAIE是为运维来做,想不到是为ISP的运维来做。 模板自带演示数据集,这点好评并且还能在线预览数据 接下来是特征工程,下载示例的python文件瞬间感觉“隔行如隔山”,感觉与平时用的numpy、sklearn不同啊!瞬间蒙掉……如果是传统的数据挖掘项目,一般是数据清洗→数据转换→特征工程→训练→推理。但NAIE这个项目就看得有点蒙了。 模型训练总算见到熟悉的sklearn了。 然而按照指导书上却是选Tensorflow,这就有点奇怪了。 训练运行时,更晕了!跑Demo居然还要一堆包依赖….... Demo看来应该要与时俱进啊来到这里我就奇怪了,max_features怎么与平时的随机森林不同,随机森林的features是选多少个features作为一棵树啊。看源代码才知是这样。按照指导,设置最优超参数再训练,依然是要解决包依赖问题推理同样还是包依赖问题跑完 总体评价:1.因为不熟悉运维,如果光从数据挖掘的项目来看是没有看出什么问题。但如果真正部署到生产环境中,却需要与syslog、SNMP等进行联动,然而在本次的NAIE体验中没有看出这些相关的操作,感觉NAIE像是之前MLS的改良版。2.包依赖问题,能否只下载一次呢?用sklearn如果在本地,就算是几万行数据+sklearn也是秒算,而NAIE每次都花1分钟来下载,会让一部分人着急3.自带Demo全流程,这点好评4.明明是用sklearn,却要选TF,这点比较奇怪 下面是标准问题:A.是否容易上手,模型训练服务内使用帮助是否能解决遇到的问题,需要增加哪一类的使用帮助;答:容易上手,但指导书最好不仅仅是只有图标,并且有全屏截图标明位置B.对于产品性能,操作便捷性,可视化界面等有什么建议;答:见上面的总体评价C. 你觉得哪一模块可以使用其他更优的方案替代;答:数据预处理上,最好有相关的指导说明。D. 使用过程中有哪些不好的体验,是否出现异常,无反应无提示的状态;答:主要是从秒算,变成花2分钟,不习惯满意度及推荐度:当有AI平台需求时,您是否愿意推荐NAIE模型训练服务?理由是?答:满意度(6分,10分满分来计),推荐度(1分,10分满分来计)不愿意推荐NAIE,因为用sklearn在本地是秒算,也没有像ModelArts那样需要云端大算力的需求,并且没有提供从SNMP、syslog一直到推理运维AI流程。
-
[toc] **目录** [toc] 群内昵称: 许子龙 华为云账号: xuzilong1 那个 尴尬的发现 这里的toc不能生成目录 ,我的有道云笔记链接在这 文档: 体验官有奖体验第19期 华为云NAIE模?.. 链接:http://note.youdao.com/noteshare?id=c800340107613fecf6fd17b8b5961f4a⊂=ECE4F0FA107C417A9FD44653A4DC6B6C # 1.体验介绍 ## 1.1 什么是模型训练服务 模型训练服务为开发者提供通信领域一站式模型开发服务,从数据预处理,到特征提取、模型训练、超参优化服务、模型管理、在线推理服务、模型验证。本服务为开发者提供开发环境、模拟验证环境,API和一系列开发工具,帮助开发者快速高效开发通信领域模型。 ## 1.2 应用场景 模型训练服务为电信网络领域,包含无线、固定网络、核心网、数据中心四个领域的相关人员,在面向网络资源效率提升、能源效率提升、运维效率提供、提升用户体验方面的业务场景,需要训练出一个AI模型时,提供集成开发环境,使开发者可以使用开发环境训练出模型,并提供模型验证功能。 ## 1.3 本次众测流程概述 本次众测分为8个部分,分别介绍了服务及各个模块的操作办法,预计完整体验本次公测功能耗时40min。 # 2.体验流程 ## 2.1 进入华为云环境 >- 模型训练服务华为云环境地址: https://www.hwtelcloud.com/products/mts 可以登录AI市场,从菜单栏中选择“AI服务 > 训练服务 > 模型训练服务”,进入模型训练服务Portal页面。单击“进入服务”,访问模型训练服务。 华为云AI市场地址: https://www.hwtelcloud.com  ## 2.2登录华为云体验账号  ## 2.3 进入模型训练服务  ### 2.3.1 在模型训练服务首页,单击“硬盘检测”下边的“使用模板创建”,创建硬盘故障检测工程。  ### 2.3.2数据集截图  ### 2.3.3特征工程截图  ### 2.3.4模型训练截图 1.  2.  3.  ## 2.4单击“训练”,进入训练任务配置页面。 1.  ## 2.5单击“开始训练”,启动训练任务。系统进入WAITING状态,在训练算法编辑页面自动打开控制台。 等待约0.5min后,任务进入RUNNING状态,系统会展示训练任务的系统日志、运行日志 1.  2.  3. 这个地方数据是不是获取的太慢了  ## 2.6 评分最高参数组合  ## 2.7. 重新run配置 1. 2. 再次运行  ## 2.8 任务结束  ## 2.9 导包 1.  2. 模型管理  3. 模型验证报错,图如下  4. 模型验证算法页面、  5. 验证任务进行中  6. 验证任务完成  # 3.体验报告 >- A.是否容易上手,模型训练服务内使用帮助是否能解决遇到的问题,需要增加哪一类的使用帮助; 回答: 这次的体验很容易入手,因为有文档的存在,点击按钮也很好找。遇到的问题就是标题2.9 下的第4张图点击模型验证时候会报错 >- B.对于产品性能,操作便捷性,可视化界面等有什么建议; 回答:项目创建较慢,算法误删不知道如何去恢复,我重新创建的项目,点击数据集和特色工程,数据刷出的较慢 还有 这个地方数据是不是获取的太慢了,我认为互联网产品,肉眼可见就是慢。。。。。。  >- C. 你觉得哪一模块可以使用其他更优的方案替代; 回答: 现在不确定的是模型训练是否可支持其他语言,我看了下默认的那个算法是python的。 >- D. 使用过程中有哪些不好的体验,是否出现异常,无反应无提示的状态; 回答:如B问题回答吧,页面显示较慢等,页面征途布局还是不错的,挺好的一个产品。 >- 满意度及推荐度:当有AI平台需求时,您是否愿意推荐NAIE模型训练服务?理由是? 如果10分满分 满意度 8 推荐度7 接受,可以节省很多时间去构建基础环境,而且华为云值得信赖。
-
体验官微信昵称:Mike Cao华为云账号:vipmike007总体来说A.是否容易上手 因为有一个挺不错的 GUiIDE,跟着 GUIDE 很容易走通,所以问题不是很大B.对于产品性能,操作便捷性,可视化界面等有什么建议。 建议把不同步骤不要做成平行结构,个人觉得瀑布模式更合理C.使用过程中有哪些不好的体验,是否出现异常,无反应无提示的状态。训练过程中 查看特征详情哪一步 已截图 ctrl+shift+3 总会莫名刷新界面,很差的体验,我怀疑有快捷键冲突,麻烦查看试用 60 天,但是刚申请就显示剩余 59 天,我觉得这块有问题,应该显示 60 天在使用阶段有些地方还是显示费用配置,不确定是否针对会产生,建议详细描述比如 4.08/小时(试用期内正产收费、试用期内不收费)之类满意度及推荐度:当有 AI 平台需求时,您是否愿意推荐 NAIE 模型训练服务?理由是?满意度:8分。推荐度:7分。理由:总体来说基于 tensorflow 作了一层dashboard 包装很不错,把流程做的也很好很不错如果说有需求可以进行推荐D. 这个论坛不适合做体验官的记录,详细测评报告请看附件
上滑加载中
推荐直播
-
用码道,让你的AI作品三步上朋友圈2026/08/04 周二 19:00-20:00
林华鼎-华为云AI开发者运营负责人
从入门 · 到做AI应用 · 到企业级开发。不教编程,只教用AI · 零代码、有产出、能带走、可炫耀 · 每课人人动手实操
回顾中 -
华为云码道Agent集成与鸿蒙实战2026/08/11 周二 19:00-21:00
王一男-华为云码道产品规划专家;李炎-华为云码道产品专家;彭江敏-华为云鸿蒙端云一体化开发专家
本次直播带你解读华为云码道7月份产品新特性、新功能。更有专家演示码道Agent Space × 钉钉机器集成实战,从0到1打通消息通道;码道鸿蒙端云一体化实战,快速搭建员工签到系统。
回顾中 -
基于华为云码道,构建你的定制化AI搭子2026/08/14 周五 09:00-11:30
明亮-华为云开发者发展与支持部部长
本期直播将向您全面介绍华为云码道产品,并基于码道手把手教你部署自己的定制化AI陪伴搭子。
回顾中
热门标签