精华内容
下载资源
问答
  • 过程异常处理程序
    2021-02-27 16:36:54

    过程异常处理程序

    时间:2017/12/1 10:43:00

    1.

    目的

    针对过程中不同的异常情况,分析潜在的质量隐患,并通过对期间生产板质量的确认及可能的质量波及性分析,追溯并控制问题的影响范围,以防止不合格品的再次出现、转序及流出。

    2. 适用范围

    适用于dpec 各工序过程异常时的处理。

    3. 过程异常的定义

    3.1 生产过程中的重点设备发生故障时,且无法直接判定波及产品

    是否为合格品时。

    重点设备包括:内层前处理、des 、黑化、棕化、钻孔、水平去钻污、化镀、板镀、外层前处理、外层粗化、超粗化处理、电镀、填孔电镀、ses 、浮石粉刷板、化学锡、化学镍金、喷锡前处理、喷纯锡、防氧化、压机。

    3.2 生产过程中的工装、夹具异常(断冲头等);

    3.3 生产过程中的槽液异常(包括槽液浓度、ph 值、比重、颜色

    等);

    3.4 工艺参数的改变(温度、速度、压力、吸真空强度等超出作业

    要求);

    3.5 设计方面的问题:如ppe 设计方面的问题;

    3.6 突发事件(如突然停电、停水、停气、水混等);

    3.7 产品缺陷异常为过程异常的体现, 以下几类重要缺陷定为产品

    异常: (详见附件一《dpec 工序异常缺陷对照表》) 3.7.1 孔方面的问题

    如孔壁破洞、孔径超差、多孔、少孔。 3.7.2 结合力方面的问题

    如电镀、化镀、化学镍金、化学沉锡、阻焊油墨等出现结合力不良的问题。 3.7.3 固定点问题

    a. 20%以上板在同一位置上出现同样的问题;

    b. 2pcs 或2pcs 以上板在同一位置出现开短路问题。

    3.8 出厂检验时发现的可靠性问题。

    4. 异常批次的定义

    出现过程异常并导致产品质量异常时,所覆盖的批次定义为异常批次;出现产品缺陷异常时,缺陷所在的批次为异常批次。

    5. 职责

    5.1 工厂负责及时准确的将过程异常及产品缺陷异常情况反馈给

    相关职能部门,对过程期间的批次做好隔离及标识; 负责对因管理漏洞所导致的异常进行改善。

    5.2 设备部负责对设备方面的问题及时修复解决并确认修复结果;

    对频繁发生的问题及时分析,并做好定期的监控及预防性维护。

    5.3 技术部负责对异常的原因的查找并解决, 对问题可能的波及性

    给出相应的分析,并提出处理意见;对需要返工处理的给出返工处理流程;实验中心负责将过程异常产品进行相关可靠性实验并及时准确的通报相关部门。

    5.4 品质负责异常期间产品的确认并下发《异常批次跟踪表》;负

    责进行相应的追溯;对不合格品进行返工/报废处理;负责《质量异常反馈单》(q/r-qa058)的存档、改善内容执行情况的监控;负责《异常批次跟踪表》(q/r-qa110)的存档保管。 6. 管理内容与控制要求

    过程异常处理程序的流程框图 6.1 设备故障 设备处置

    产品处置

    6.2 产品缺陷异常 原因分析

    (质量异常反馈单)

    产品处置

    7. 具体要求

    7.1 设备故障的《质量异常反馈单》由发现异常的人员按要求进行

    填写,并依照《设备故障报修维护标准规程》(q/ms-066)进行erp 录入、填写报修单通知设备部进行维修,同时通知技术部、品质部相关人员,由技术、品质相关人员给出异常处理过程的意见。

    产品异常的《质量异常反馈单》由发现过程异常或缺陷异常的

    人员负责通知qc 人员按要求进行填写并负责整个处理过程的跟进。

    7.2 波及性分析及处置

    问题的波及性分析必须由技术部给出,同时对已加工的产品及未加工的产品同品质部共同给出处理意见。 7.3 对重点设备、产品缺陷异常的追溯要求 7.3.1 对经过分析后可确定异常发生时间范围的,要求追溯整个期间

    所有已加工的生产型号, 同时确认待加工的生产型号状态。

    7.3.2 对无法确定具体发生时间的,要求从异常发生时的生产型号开

    始追溯,并一直追溯到无产品质量问题的前两批生产板; 7.3.3 问题可能的波及范围确认后,品质部及时将相应的型号、批次

    进行暂停,并组织对产品质量进行确认。

    7.4 对重点设备、产品缺陷异常的处置

    通过以上的追溯,对已经确定并需要后序重点关注的异常批次,还需要填写《异常批次跟踪表》(q/r-qa110),将缺陷的不良率进行统计,以方便后序对异常缺陷的继续跟踪;如波及到的批次在后序仍旧出现同样的缺陷,则需要技术部对波及性分析及处置意见重新核实。《异常批次跟踪表》在批次异常的发现工序由品质部填写并发出,装订在生产流程卡上随流程卡一起下转,对于《异常批次跟踪表》中需要特别控制的工序由品质人员结合技术部的分析给出,并由品质人员和生产人员在控制工序共同确认。到目检工序时由品质人员回收并存档。 7.5 对重点设备的异常修复后启动时的要求

    参照《设备故障报修维护标准规程》(q/ms-066)要求,通过

    设备部对重点设备进行维修后,需要由技术部、品质部以及工厂相关人员一同确认设备修复状态,一同判定设备是否可以正常开启。在无法直接判断时,可先启动制作首件或首架板进行验证,合格后批量加工,若验证仍存在产品缺陷时,需要由设 备部、技术部、品质部重新对设备进行诊断,再由设备部进行 维修。

    7.6 原因分析及改善措施方面要求

    7.6.1 要求针对产生原因、流出原因及改善措施方面分别进行分析; 7.6.2 永久性改善措施方面要求最终体现在工程指示、作业标准书、

    可接收标准及控制计划上。

    7.7 异常期间产品质量的检验及结果要求及时录入到erp 系统的

    ipqc 中,类别选择“异常”;《质量异常反馈单》最终由品质部回收存档。

    8. 相关文件及记录

    8.1 《质量异常反馈单》 q/r-qa058

    8.2 《异常批次跟踪表》 q/r-qa110 8.3 erp系统中的ipqc

    8.4 《设备故障报修维护标准规程》 q/ms-066

    质量异常反馈单

    q/r-qa058c

    dpec 内部文件更改记录

    问题推荐

    更多相关内容
  • 生产环境出现问题-定位问题-解决问题-原因复盘-问题定级-划分责任人(每次都希望不会是自己的问题) 无休止的测试-回归-再测试-再回归测试-已经投入了很大精力,但仍对项目质量不信心(每次都在祈祷上线顺利) 我...

    前言:不知道大家有没有遇到下面两个场景,我是遇到了,还为此召开了RCA会议——复盘会议!

    一、熟悉的场景

    • 生产环境出现问题-定位问题-解决问题-原因复盘-问题定级-划分责任人(每次都希望不会是自己的问题)
    • 无休止的测试-回归-再测试-再回归测试-已经投入了很大精力,但仍对项目质量不信心(每次都在祈祷上线顺利)

    我相信很多人都会遇到上面两种情况吧,如果自己所负责或参与的项目经常遇到上面的两种情况,不妨从项目测试流程角度,去思考原因以及破开瓶颈的方法,从根本上去解决问题,或者减伤出现问题的频率。

    二、测试流程拆解分析

    在这里插入图片描述

    1、需求评审

    需求评审流程:
    需求背景–>需求价值–>需求带来的收益–>用户场景与需求–>功能模块及操作–>流程讲解–>原型演示–>迭代计划及项目排期–>与各方确认是否有疑义

    人人都是产品经理,需求评审对于测试来说就是项目最初的“产品测试”,在理解的基础上发现产品设计缺陷,其中包括逻辑错误,功能缺失,细节问题等等,这样就会有效的在前期规避很多后期开发中产生的bug,减少了很多后期返工的成本。可偏偏需求评审往往是最不重视的一环,甚至可以说是没有这个环节,追其原因无非因为项目时间紧迫或者觉得没有必要,其实这是本末倒置和得不偿失的。

    产品需求作为程序的源头,只有控制好最开始部分,才不会到最后去亡羊补牢。我有过很多血的教训,所以才深深的体会到需求评审的重要性。举个栗子

    记得有一次由于项目时间比较紧迫,没有对需求进行评审,当开始测试的时候发现需求的优惠券计算逻辑有一个重大的错误,经过和产品经理讨论后发现是需求设计有缺陷,需要重新设计一套优惠券计算逻辑。于是改完需求后反馈到开发这里的时候,开发原来的代码不能处理这种逻辑,只能把代码逻辑重新写一遍,最后又花了好几天重构代码,项目就延迟了一周上线。

    后来回头想想如果当时在需求评审的时候把这个问题抛出来,开发就不需要编写错误的代码,测试也不需要再多测试一遍,项目也不会延迟那么久才能上线。类似的教训还有很多,都是由于不重视需求评审造成的,虽然大多数问题还是可以通过后期的测试来弥补的,但这样反正折腾真的是累人累己,如果可以有好的方法来优化,为什么不用呢?

    说了需求评审的重要性,接着就来谈谈如何进行需求评审,总的来说分3步走:

    • 第一步就是要完全读懂产品需求,这个过程只需要理解而不是去挑刺,因为要明白这个需求的目的是什么,为什么这样做,怎么做等等,只有在理解的基础上才能去发现问题,而不是一知半解的去挑毛病,有些需求设计的是不合理,但也许有其特殊的用意,或者只是没有更好的方案,不能为了挑毛病而去挑刺。
    • 第二步就是分析和找问题,这就有点类似写测试用例的时候设计测试方案了,把逻辑梳理出来,看看有没有不对或者遗漏的点,整理出来反馈给产品经理。除了考虑有问题的地方,没问题的地方也是需要分析的,比如有些设计非常合理,但会增加代码的复杂度或者不利于后续的扩展和修改,同时也可能会给测试带来成倍的工作量,这些也是需要指出的,因为测试要考虑的东西一定要比产品经理多,用户使用习惯,程序复杂度,与线上系统的兼容性等等,不然直接让产品经理做测试不就好了吗?
    • 第三步就是细节问题的纠正,可以是界面,可以是文字,开发一般都是复制黏贴或者照着样子画葫芦,这些小问题后期其实也可以测试出来的,但其锅不在于开发,早点发现问题早点解决也是好事一件,至少不用提bug走一套bug处理流程了,也算给大家省点工作量,积少成多也是极好的。

    当然需求评审能解决的问题也是有限的,一方面计划往往赶不上变化,中间会有部分需求的改动,另外一方面有些深层次的问题只有在测试之后才会发现。但无论如何对于测试来说还是非常有必要的,大家一定要积极的参与进去,而不是像听故事一样啥问题都没有,如果能重视起来不仅仅对项目的效率提高不少,而且也能让后期测试压力减小,何乐而不为呢?

    2、技术设计评审

    **通过参与技术设计评审,可以为测试方案提供依据。**例如:核心业务是否需要接口测试、新老数据兼容问题、测试场景的数据构造以及测试所需的工具等,都可以在这个阶段进行思考和产出。另外,可以有效的评估需求影响范围和风险点,避免遗漏。

    此阶段是质量的基石,通过测试左移,尽早发现需求设计缺陷、技术方案风险、关联方依赖影响等方面,了解测试关注点,需求可测试性以及预留排期等问题。

    例如:

    • 接口测试:会员权益核销&&优惠券核销&&退款,接口都需要对前端传入的参数进行校验
    • 新老数据兼容,比如说小程序的发版,一般会滞后于接口发布,一定要测试旧版本的兼容性

    3、测试方案设计

    1. 测试用例设计
      需要从整体入手,而不仅仅局限于待测功能本身的业务逻辑。 好的测试用例,是质量保证的核心
    2. 测试用例评审
      避免三方需求不一致,减少测试执行阶段做无效工作,如执行无效用例、提交无效BUG等
    3. 测试数据准备

    此阶段是质量的骨架,通过测试设计,覆盖更多的测试点、模拟更多的场景、做好更充分的测试准备,为质量保驾护航,为测试赢得更多宝贵的时间。

    测试用例这一步不能忽略,即使改动很小,排期很紧,也建议要画出思维导图;要想提高测试用例设计能力,就需要平时就要多积累,对常见的缺陷模式、典型的错误类型以及遇到过的缺陷,要不断地总结、归纳,才能逐渐形成体系化的用例设计思维。

    同时,对于高质量的测试活动,用例设计不仅需要考虑明确的显式功能性需求,还要涉及兼容性、安全性和性能等一系列的非功能性需求。

    那好的测试用例是如何定义的呢?我在这里说说个人的见解:

    • 不应该从是否能发现BUG的维度去定义,而是应该从集合的完备性角度去思考,也就是测试用例是否能够覆盖所有等价类以及各种边界值为维度去衡量。

    • 如果把被测系统看作一个池塘,BUG是池塘中的鱼,设计测试用例集的过程就像是在编织一张捕渔网。好的用例集就是一张能够覆盖整个池塘的大渔网,只要池塘里有鱼,这个大渔网就一定能把鱼给捞上来。如果渔网本身是完整的且合格的,那么捞不到鱼,就证明池塘中没有鱼,而渔网的好坏与池塘中是否有鱼无关。渔网眼就是测试用例的粒度,粒度越大,意味着网眼越大,这就只能捕捞大鱼,一些小鱼就会漏网。这也是一些项目通用的现状,测试活动由于受限于时间成本和经济成本,只能采用基于风险驱动的模式,选择合适的测试粒度,即有所侧重地选择测试范围和设计测试用例,以寻求缺陷风险和研发成本之间的平衡。

    我个人从下面3个维度出发:

    • 整体完备性: “好的”测试用例一定是一个完备的整体,是有效测试用例组成的集合,能够完全覆盖测试需求
    • 等价类划分的准确性: 指的是对于每个等价类都能保证只要其中一个输入测试通过,同子集下其他输入也一定测试通过
    • 等价类集合的完备性: 需要保证所有可能的边界值和边界条件都已经正确识别。做到了以上三点,就可以肯定测试是充分且完备的,即做到了完整的测试需求覆盖

    4、线下测试(含灰度)

    1. 横向覆盖:
      对于一个场景,从开始到结束涉及到的关键节点,都要进行检查点覆盖,包括功能实现、数据读取、数据计算、数据写入等的正确性
    2. 纵向覆盖:
      正常场景、异常场景、补偿场景都要覆盖
    3. 探索性测试:
      凭个人经验进行探索性测试
    4. 回归测试:拉取回归测试集,手动测试和自动化测试相结合,在测试环境验证新功能对原有功能是否产生影响;

    此阶段是质量的成型,通过测试设计的充分准备、线下测试的严格、立体的执行,发现和解决绝大部分问题。

    在这里我把探索性测试单独拉出来讲一讲:
    根据需求描述来设计最初的测试用例,然后执行测试;在执行过程中,如果得到的输出和预期输出不完全一致,于是会猜测这种不一致是否可能是软件的缺陷造成的;为了验证想法,你会根据错误输出,设计新的测试用例,然后采用不同的输入再次检查软输出。经过几轮这样的猜测和验证,进行反复“探索”,最终确定了一个软件的缺陷。

    但是识别缺陷的思路和测试用例的设计,并没有出现在最初的测试设计和测试用例文档中。探索性测试是一种测试风格,并且强调依据当前项目上下文选择最适合的测试技术。同样的测试风格,由不同的人来具体执行,得到的结果可能会差别巨大,一直强调测试分析能力是最重要的技能。

    5、线上测试

    1. 回归测试:
      拉取线上回归测试集,并结合自动化测试,保证核心流程测试通过
    2. 新功能测试:
      拉取新功能快速验证测试集,并确保覆盖新功能核心测试点

    此阶段是版本质量终态,线上测试主要是为了确保代码部署、生产配置、生产环境对质量的影响。

    6、测试复盘

    在发布上线后,对测试过程进行复盘,总结遇到的问题,对当时的解决方案进行探讨。通过复盘,从而达到指导后续工作,减少重复踩坑。并在可以在个人复盘完成后,在部门内进行信息共享。每个人负责的项目虽然不同,但是测试思想确有共通之处。通过复盘分享,可以有效提升团队整体测试经验。

    此阶段是测试经验累积阶段,也是容易被忽略的阶段。通过信息共享,大大降低重复踩坑的概率。

    7、线上监控

    通过选取业务流程中优先级高的测试用例,作为心跳测试用例定时运行,并持续进行补充完善。

    接口测试用例的开发进度落后于新功能的发布节点。自动化不是跟着新需求走,而是测变化的东西对不变东西的影响。

    此阶段是测试活动右移,质量补偿,快速响应和解决,降低生产事故造成的损失。

    三、总结

    1. 通过规范测试流程,全覆盖产品生命周期,量化测试产出,在有限测试资源下的提升产出
    2. 推动力是衡量测试角色能力的重要指标,特别是一些需求不明确的项目,在各个阶段都要保证信息在团队成员间的一致性

    目前的不足之处:

    • 测试用例评审流程:邮件or会议, 需要产研给出积极响应;
    • 测试各阶段的准入准出条件模糊:进入开发、进入测试,要有基本的要求,一环连着一环,在某些阶段确实可以加入一些提交基线,比如进入测试阶段之前增加提测基线(类似冒烟)
    • 技术沉淀不足,异常场景模拟依赖开发人员

    我觉得作为一个测试,一定要多学、多问、多思考,只有这样,你才能快速成长,拥有全局思维,做到比产品更了解产品!

    在这里插入图片描述

    展开全文
  • 自然语言处理中的分词问题总结

    千次阅读 2018-10-29 13:47:46
    自然语言处理中的分词问题总结   众所周知,英文是以词为单位的,词和词之间是靠空格隔开,而中文是以字为单位,句子中所有的字连起来才能描述一个意思。把中文的汉字序列切分成意义的词,就是中文分词,有些人...

    自然语言处理中的分词问题总结

     

    众所周知,英文是以词为单位的,词和词之间是靠空格隔开,而中文是以字为单位,句子中所有的字连起来才能描述一个意思。把中文的汉字序列切分成有意义的词,就是中文分词,有些人也称为切词。本文 转载自明略研究院的技术经理牟小峰老师讲授的语言处理中的分词问题。


    如何界定分词  


    中文分词指的是将一个汉字序列切分成一个一个单独的词。分词就是将连续的字序列按照一定的规范重新组合成词序列的过程;在英文中,单词之间是以空格作为自然分界符,汉语中词没有一个形式上的分界符。 (见百度百科) 正因为缺乏形式上的分界符,导致我们对词的认定会出现很大的偏差。1996 年 Sproat 等通过对 6 个母语为汉语的人进行调研,让这 6 人对同一篇中文文本进行人工切分,文本包括 100 个句子,最后统计认同率,见下表:


     


     
    不仅普通人有词语认识上的偏差,即使是语言专家,在这个问题上依然有不小的差异,这种差异反映在分词语料库上。不同语料库的数据无法直接拿过来混合训练。


    以前曾经出过分词规范 (GB13715),以“结合紧密,使用稳定”作为分词建议,后来发现这个建议弹性太大,不同的人有不同的理解,无法有效实施。


    为了统一对词语的认识,现在主要通过 “分词规范、词表、分词语料库”来使得词语切分可计算,例如北大的“词语切分与词性标注”规范。基于上述种种工作,可以把词语切分问题变得可操作和标准化,大家在统一的平台上进行实验和比较。


    对分词的诉求是什么? 


    从已有工程经验来看,几乎不存在通用而且效果非常好的分词系统,例如:在人民日报上训练的分词系统,在二次元的魔幻小说上切分效果不佳。每个领域有其独特的词汇表示,这很难通过有限的训练数据捕捉到所有语言现象。


    不用使用场景对分词的要求差异很大。在搜索的索引阶段,往往会召回所有可能切分结果,对切分准确率要求不高,但对分词速度有很高的要求,例如某中型搜索系统,每天 4000 万篇文章入库,每秒要处理 500 篇文档,每秒处理的文档字节数约有 50MB;如果分词系统太慢的话,需要开大量线程才能处理这些文档。


    在问答系统中,需要对文本实现较为深入的理解,对分词和实体识别的准确性要求很高。


    不用的使用场景,对分词提出了不同的要求,不需要片面地追求高准确率。


    别家系统的准确率怎么这么高? 


    在分词系统研发中,最容易产生误解的就是比较系统准确率。系统准确率与训练数据非常相关,脱离数据而谈论准确率无异于 “刷流氓”。2003 年 863 分词评测中就出现了 98% 的准确率,2007 年 Sighan 评测中最高准确率是 97%,在最近某司组织的评测中,最高准确率下降到了 94%。所有不同数据下的评测结果都不能直接比较高低。
     
    现在吹嘘分词准确率的公司和单位越来越少了。


    分词稳定性很重要 
    分词稳定性是指分词系统的输出在不同上下文下都比较稳定,不会出现明显被上下文影响的情况。例如,在下面句子中, “黄代恒”有时识别为人名,第二次出现未识别出来:
    实战 分享 三 黄代恒 /nr 与 轨道 交通 : 软硬 结合 到 人机 结合  黄代恒 “ 在 不同 的 客户 场景 下 , 我们 用 三 种 技术 实现 轨道 交通 的 数据 洞察


    一般纯统计分词系统的稳定性比不上基于词典实现的分词系统。在搜索中,分词稳定性非常重要,否则极容易出现查询不到的情况。


    已有分词系统小结  


    分词大概是投入人力非常大的 NLP 方向,几乎每一家“有追求”的公司都有员工实施过类似的任务,而且反复迭代更新;在 NLP 研究界,这个问题从上个世纪 80 年代就已经开始探索,一直到 ACL 2017 仍然有这方面的论文 (有 4 篇丛神经网络角度探索分词的文章)。


    如此多的人力投入到分词理论研发和工程研发中,产生了一批各有特色的分词系统。下面仅仅就本人接触到的系统作说明 (排名无先后),比较“古老”的系统不在此罗列:
     
     

     


    IK 系统 


    该系统采用 JAVA 开发,实现逻辑不复杂,由于对 Lucene 和 ES 支持较好,因而得到了比较普遍的使用。该系统可以实现英文单词、中文单词的切分,OOV 识别能力不强。该系统有几种使用模式,分别对应不同的使用场景,如索引、查询等。


    IK 有些功能比较贴心,比如热更新用户词典,支持用户自定义词典非常方面,对搜索工程师比较友好。


    IK 的代码实现上优化不够好,甚至能发现 BUG。我们发现的 BUG 会导致 ES 中长 Query 无法实现精准匹配。


    对于中小企业的内部应用来说,使用 IK 足够了。在商业系统上使用的话,要非常慎重,参与优化的人员太少了。

     


    Jieba 系统 


    Jieba 大概是最好用的基于 Python 实现的分词系统了,2-3 行代码就可以实现分词调用和词性标注,速度还不错。基于 HMM 模型实现,可以实现一定程度的未登录词识别。


    Jieba 有精确模式、全模式、搜索模式三种。全模式是找到所有可能词语;搜索模式是在精确模式的基础上对长词进行切分,提高召回率。
     
    支持繁体分词;支持自定义词典;支持并行分词,方便实现加速。


    在分词速度上,精确模式能达到 400KB/ 秒,全模式下能达到 1.5MB/ 秒。


    Jieba 除了 Python 版本外,还有多种语言实现的版本,包括 C++, JAVA, Golang 等。


    Java 版本的 Jieba 功能上受限,仅面向搜索使用。明略 SCOPA 产品中使用了 Java 版本的 Jieba 作为分词组件,替换了 IK。

     


    Hanlp 平台 


    Hanlp 是一个功能非常全面的 NLP 平台,它的分词接口借鉴了 Ansj 的设计,形式上和命名上都非常像。


    Hanlp 有“简约版”和“加强版”,简约版的模型参数较小,分词能力还可以;加强版在模型参数上扩大了若干倍,分词能力进一步提升。


    Hanlp 支持基于 HMM 模型的分词、支持索引分词、繁体分词、简单匹配分词(极速模式)、基于 CRF 模型的分词、N- 最短路径分词等。实现了不少经典分词方法。


    Hanlp 的部分模块做了重要优化,比如双数组,匹配速度很快,可以直接拿过来使用。


    Hanlp 做了不少重现经典算法的工作,可以去 GitHub 上看一下!

     


    ICTCLAS 系统 


    ICTCLAS 大概是“最知名”的分词系统了,从参加 2003 年中文分词评测,一直延续到了现在。现在已经是商业系统了 (改名 NLPIR),需要 License 才能运行。


    从未登录词识别准确率上说, ICTCLAS 已经明显落后于基于 CRF 的分词系统了。


    尽管如此,它的优点仍然比较明显:很少出现 “错得离谱”的切分结果,这在基于 CRF 模型的分词系统上不少见,尤其是迁移到其它领域时;模型和库不大,启动快;基于 C++ 实现,能够很快迁移到其它语言。


    从分词稳定性上来说, ICTCLAS 值得信赖,从分词准确率、分词速度等方面来考量,有不少分词系统超过了它;NLPIR 的源代码已经不再开放,这让用户很纠结。

     


    交大分词 


    所谓 “交大分词”,是指上交大赵海老师个人主页上的分词系统。该系统在 2007 年 Sighan 评测中拿到了多项第一。


    该系统基于 CRF 模型构建,在模型特征提取上做了大量工作,分词准确率比较高。目前可用版本支持简体、繁体分词,也支持不同分词标准。该系统被常常用来比较分词准确率。


    该系统的问题是不开源,只有 Windows 上的可执行文件,C++ 源码需要向作者申请。虽然该系统不开源,但作者的一系列论文基本上揭示了其原理,复制起来并不难。


    从工程角度来考虑,该系统只适合做 DEMO 组件,不适合大规模工业化使用。

     


    Stanford 分词 


    Stanford 分词系统的优点是准确率高,未登录词识别能力比较强;缺点非常明显,模型很大,约 300MB-400MB,启动非常慢,大概需要 10 秒 -20 秒。在所有分词系统中,没有比 Stanford 启动更慢的系统,分词速度也不快。代码优化的空间比较大。
    Stanford 系统支持自定义训练,只要用户提供训练数据,该系统可以训练新的模型参数。


    Stanford 分词系统只是验证作者论文的一种手段,为了非常微小的分词准确率提升,导致了模型参数膨胀。
    在 Demo 环境下可以使用 Stanford 系统,在大规模数据环境下不适合使用该系统。

     


    GPWS 系统 


    GPWS 是北京语言大学语言信息处理研究所研发的分词系统,2001 年对外发布。该分词系统是 2000 年后唯一一个基于大规模规则 + 统计的分词系统(仅限个人所知),在 2004 年非常低的硬件配置下,分词速度也能达到 3MB-5MB/ 秒,对系统资源的消耗很低。后来授权给了新浪、微软等公司使用,被应用在了信息检索中。


    GPWS 可以实现中文人名、外国人名、日本人名的识别,其它分词系统几乎都没有做到这个程度;对通用领域的文本切分效果较好,支持自定义词典;很少出现切分“离谱”的情况。该系统适合大规模数据处理的场景。


    上述所有系统几乎都依赖于训练数据,而 GPWS 没有这方面的问题。GPWS 依赖于高质量分词词典和歧义切分机制,采用基于可信度的人名识别方法,不依赖于公开的训练数据。


    GPWS 最大的问题在于很难复制,代码没有公开;在分词准确率上,GPWS 已经比不上字本位的分词系统;但从分词稳定性上,GPWS 仍然非常出色,比纯统计分词系统明显要好。

     


    分词的难点在哪里? 


    歧义  


    歧义问题与词长非常相关,词语越短,发生歧义的可能性越大,词语越长,发生歧义的可能性越低,很少出现成语与其他词发生歧义的情况。歧义问题在分词中不是罪严重的问题,仅占分词错误数的 10% 左右。歧义分类包括:


    交集型歧义
    abc -> 可以切分为 ab c 和 a bc,占所有歧义总量的 95%,也就是说歧义问题主要是指交集型歧义
    例如:
    研究生命的起源 | 研究生 命 的起源
    这种环境下 工作 |  这种环境 下工 作
    化妆 和 服装 |  化妆 和服 装
    这群 山里的娃娃 |这 群山 里的娃娃
    进书店 跟 进超市一样 | 进书店 跟进 超市一样


    组合型歧义
    abc ->可以切分为 abc 和 a bc 或 abc。
    组合型歧义一般要通过前后邻接搭配的可能性大小来判断。
    他从 马上 下来 | 他从 马 上 下来
    这个门 把手 坏了 | 这个门 把 手 坏了


    基于马尔科夫模型计算邻接搭配可以消除绝大部分歧义。


    通过计算词语搭配的概率估计句子的概率,选择概率最大的结果即可。
     
     

     


    分词错误的主要来源 


    未登录词 - 不在词典中的词,该问题在文本中出现频度远远高于歧义。


    未登录词的类型包括:人名、地名、机构名、公司名、数字、日期、专业术语、新词、产品名等。一般把人名、地名、机构名、公司名叫命名实体,例如:
     
    卢靖姗一夜爆红 (人名)
    在东四十条站台见面 (地点)
    银联的小兄弟网联成立了 (机构名)
    公元 2017 年 8 月 24 日发生一件大事(日期)
    中国外汇储备达到三点 94 万亿美元(数字)
    在明略软件做大数据处理 (公司名)
    基于暗网数据买牛股 (专业术语)
    招行发布了朝朝盈一号的理财产品(产品名)
    让你见识什么叫冻龄 (新词)


    不同类型的命名实体还可以细分,比如人名可以分为中文人名、藏族人名、维族人名、日本人名、欧美人名等。


    地名可以分为典型地名和非典型地名,典型地名如国、省、市、县、乡、村等;非典型地名还包括路、居委会、大厦商场、门牌单元、图书馆、门面等。理论上,只要是有经纬度坐标的实体,都可以纳入地名识别范畴。在实际工作中,这方面的识别需求非常强烈,比如在公安领域的线索或案情信息,往往涉及到这种非典型地名。


    机构和公司的类型也多种多样,除了行政机构外,还有各种社团、 NGO 组织、基金会、校友会等等;公司名涉及到公司全称和公司简称的识别,例如:
    明略软件系统科技有限公司(全称)
    明略软件(简称)
    明略数据(简称)
    全称识别相对容易一点,简称识别非常困难,比如:小米、滴滴、凡客、 OFO 等。


    机构公司名与地名之间存在很大的交集。理论上,一个机构或公司往往会有办公地点,有时也会用机构公司名来称呼该地点,这样的话机构公司名也就有了地点属性。例如:
    小明在明略软件上班(公司名)
    把球踢进了明略软件的门前(看做公司名还是地点?)
    在实际工作中,命名实体的关注程度最高,因为这些实体往往是知识图谱的节点。其它未登录词中,专业术语的提取会对文本分类和文本理解有重要帮助。

     


    分词中的语料问题 


    基于统计模型的分词系统,在分词结果上出现差异的一个原因是对语料的预处理差异导致。相当多的分词系统没有对训练数据进行一致性校验,认为训练数据是无差错的。在实际调查时发现,训练数据包含了不少标注不一致的情况。例如人民日报中的例子:
    自认倒霉 | 自 认 倒霉
    倒霉 鬼 | 倒霉鬼


    除了切分一致性外,词性标注的不一致性更严重一些,如: “自认倒霉”有时标注为 l、有时标注为 lv;“难能可贵”有时标注为 i、有时标注为 iv。


    分词语料的选择范围有限,主要包括北大人民日报标注语料、微软标注语料、社科院标注语料、 CTB 语料、OntoNotes 语料、城市大学繁体语料、中研院繁体语料等。一般选择一种数据即可,数据需要购买。


    分词语料之间在词语颗粒度上有一定差异,一般不混用进行训练,例如:
    承租人、承租者 (北大)  | 承租 商 (微软)
    高 清晰度 彩电 (北大) | 高清晰度电视 (微软)

     


    分词的理论解决方案  
    分词的理论解决方案是采用统计模型,基于切分语料进行训练。该方案在学术界和工程界都很常见,也是学术界的研究热点。方案的差异主要是模型和特征工程不一样。模型差异非常常见,比如隐马尔科夫模型、最大熵模型、条件随机场模型、结构感知机模型、 RNN 模型 等。


    特征提取 
    特征提取的第一步是选择单元:基于字还是基于词。从实践来看,基于字的模型对未登录词识别能力较强,但基于词的模型很少会出现切分“离谱”的情况。采用什么颗粒度单元,取决于具体任务。
    特征工程会对最终分词结果产生很大影响。字本位分词的常见分词特征是:
     
     
    Unigram 是单字特征模板,当前字的前一个字、当前字、后一个字。Bigram 是邻接字组合特征模板,包括前一个字与当前字、当前字与后一个字的组合。Jump 是把前一个字与后一个字组合。


    其它特征主要是关于字的属性,如是否数字、标点、字母等。这些特征都是形式上的特征,没有歧义。


    每一个特征实例在 CRF 模型中有一个权重。由于特征越多,模型参数越大,在实际工程应用中资源消耗越大,因此在实际任务中会有一定取舍。

     


    理论解决方案的问题 


    训练数据规模有限
    北大人民日报的原始语料的词语数为 2800 万;CTB9.0 词语数为 200 万;国家语委数据为 5000 万字。
    标注语料是一个非常消耗人力的事情。北大 1998 年人民日报的标注共持续了 3 年时间才完成。CTB1.0 的标注持续了约 2 年时间。


    领域迁移性不佳
    其他领域实施时,分词准确率下降很快。由于标注语料的词语使用无法覆盖实际语言现象,因此基于标注语料训练的分词系统在差异较大的领域会出现准确率降低的情况,例如基于北大语料训练的分词系统在微博上的切分准确率就不是很高。


    模型越来越大,速度越来越慢
    早期使用 HMM 模型训练分词系统,在北大数据上训练大概需要 1-2 分钟,内存消耗很小。现在使用 CRF 模型训练大概需要 3 天左右,内存大概需要十几 G。CRF 模型在训练分词系统时,其参数数量跟特征数量直接相关,训练数据越多,特征数量越大,模型也就越来越大。导致系统调用存在困难,运行速度下降。

     


    如何工程解决?
     
     


    能用规则解决的,就不要靠模型了 


    针对文本中有规律的部分,可以利用规则或者正则表达式来识别,例如数字、标点、时间、日期、重叠式等,如笑一笑。

     


    扩大训练语料  


    扩大训练语料的一种办法是购买更多语料;另外一种办法是利用其它分词系统来切分数据,对数据进行清洗,形成新数据。


    这些不同的分词系统依赖的训练数据尽量不要相同,例如 Stanford 系统是基于 CTB 语料,LTP 系统是基于人民日报,这两个系统的切分结果就可以考虑混用。在混用前,要进行一定程度的预处理,比如保持切分一致性。


    明略的分词系统通过使用多款不同分词系统的分词结果,扩大训练数据,在人名识别上大幅度提高了召回率。

     


    增加词表 


    增加词表是提高切分准确率 “立竿见影”的办法。在自然语言处理中,只要是封闭集合的词语或实体,可以考虑利用词表来切分,例如成语。该方法简单有效。


    在明略分词数据中,集成了全国所有的地名、公交站名、路名等,精确到村和居委会,对国内地名识别上有很高的准确度。对机构名和公司名,集成了经常出现的国内行政机构、上市企业等名字。
    在 Bosen 系统的演示中,对公司名识别准确率非常高,例如:“明略数据、明略软件”这种公司简称也能识别出来,即使没有上下文也能识别。这应该跟其后台的公司名数据有关。

     


    最大匹配 + 大词表 


    从诸多实践来看,最大匹配分词策略 + 大词表的方法非常有效。在《中文分词十年回顾》中作者提到了最大匹配和大词表的效果:
    Ftop 行表示没有未登录词的情况下,仅使用最大匹配达到的 F 值(准确率 + 召回率)。


    实用的分词系统,都带有大量通用词表和领域词表。


    收集整理领域词表,对迁移分词系统至关重要。这对统计分词系统比较困难。

     


    结合深度学习? 


    ACL 2017 年有 3 篇跟分词相关的文章,都是深度学习 (神经网络) 和分词结合的内容。分别是:
    Neural Word Segmentation with Rich Pretraining
    Adversarial Multi-Criteria Learning for Chinese Word Segmentation
    Fast and Accurate Neural Word Segmentation for Chinese
    从明略的实践来看,深度学习应用到分词任务中的优点在于:模型非常小。在约 200MB 的语料上训练得到的模型只有 5MB。分词准确率接近历史上最佳评测结果,但是分词速度太慢。


    从最新文献来看,利用神经网络来做分词,训练效率和运行效率都比较低,慢得无法忍受,不适合工程上部署,也不适合做 Demo。


    在《 Fast and Accurate …… for Chinese》中提供了运行速度对比,测试数据为 170k 左右,2015 和 2016 年的 6 项分词结果中,切分测试数据的时间从 28 秒到 125 秒。在传统方法上,比如基于 CRF 分词,运行时间大概只要 1 秒。

     


    根据个人经验,神经网络在 NLP 上的成功应用的领域往往是准确率不高或者运行效率很低的场合,例如问答系统、机器翻译、句法分析。在准确率比较高或者运行效率不错的场景下,利用深度学习会得不偿失。

     

    来自 “ ITPUB博客 ” ,链接:
    http://blog.itpub.net/31524777/viewspace-2217608/,如需转载,请注明出处,否则将追究法律责任。

     

     

    展开全文
  • 所谓 5WHY 分析法,又称“5问法”,也就是对一个问题点连续以 5 个“为什么”来自问,以追究其根本原因。 虽为 5 个为什么,但使用时不限定只做“5 次为什么的探讨”,主要是必须找到根本原因为止,有时可能只要 3 ...

    1、什么是 5WHY 分析法

    所谓 5WHY 分析法,又称“5问法”,也就是对一个问题点连续以 5 个“为什么”来自问,以追究其根本原因。

    虽为 5 个为什么,但使用时不限定只做“5 次为什么的探讨”,主要是必须找到根本原因为止,有时可能只要 3 次,有时也许要 10 次。

    如古话所言:打破砂锅问到底。

    5WHY 法的关键所在:

    鼓励解决问题的人要努力避开主观或自负的假设和逻辑陷阱,从结果着手,沿着因果关系链条,顺藤摸瓜,直至找出原有问题的根本原因。

    这种方法最初是由丰田佐吉提出的;后来,丰田汽车公司在发展完善其制造方法学的过程之中也采用了这一方法。作为丰田生产系统(Toyota Production System)的入门课程的组成部分,这种方法成为其中问题求解培训的一项关键内容。

    丰田生产系统的设计师大野耐一曾经将五问法描述为:“……丰田科学方法的基础……重复五次,问题的本质及其解决办法随即显而易见。”

    目前,该方法在丰田之外已经得到了广泛采用,并且现在持续改善法(Kaizen),精益生产法(lean manufacturing)以及六西格玛法之中也得到了采用。

    在出现质量问题的时候,很多企业强调多问几个为什么,以找到问题的根本原因,深层次原因。5why 要问到什么时候,是不是一定要问5个呢?问4个行不行呢?问6个,问10个行不行呢?每个why应该找出几个原因呢?5个why是串联关系层层递进的?还是可以呈树形关系呢?

    针对产品质量问题的原因分析,提出了四个层面的原因分析的理论。用来明确原因分析应该覆盖哪些方面,应该深入到什么深度。

    这四个层面分别为:

    产品层面;

    过程层面;

    控制方法层面;

    管理层面。

    怎么来理解这四个层面呢?

    1)产品层面的原因分析

    客户的期望,是由产品的功能来满足的。

    面向产品的最终用户的功能,是由产品的下级系统的功能、子系统的功能来满足的。

    层层向下,作为最底层的功能组件的功能,是由各个零部件的产品特性,例如长度、距离、位置、硬度、粗糙度、圆度、材料疲劳强度、电阻、电压、焊接强度,等等,具体的产品特性来实现的。

    最终产品所要求的功能、上级系统所要求的功能,如果不能被可靠地实现、如果不能满足功能在量化程度上的要求,这类质量问题我们明确为功能适用性问题。

    功能适用性问题,我们也称为功能障碍问题。它一方面的表现是我们所期望的功能不能实现,或者不能满足要求,另一方面的表现是客户不期望的功能的出现。例如噪音、异响、断裂、漏油等等,都是功能障碍问题。

    而可能引起功能障碍的产品特性的不符合,是符合性问题。例如粗糙度超差,可能会引起异常磨损。异常磨损是功能障碍,而粗糙度超差是符合性问题。

    如果产品功能要求是函数Y,保证功能的相关产品特性就是自变量X。可以有函数关系式y=f(x1,x2,x3,x4...)。大写的X、Y代表多个变量组成的向量,或者变量组。小写的x,y代表具体的单个变量。从产品的功能障碍出发,即y不符合要求。找到是哪个相关的产品特性x所带来的影响,这个层面的原因分析,就叫做质量问题的产品层面的原因分析。

    例如某个零件的密封螺纹处漏水,漏水是密封性功能要求出现障碍。其产品层面的原因是密封螺纹孔和螺柱的压型不匹配。再例如缸体的油道泄露,泄露是功能障碍,其产品层面的原因是铸造油道孔壁有疏松。再例如某发动机异响,其产品层面的原因是凸轮轴基圆上有加工振纹,导致滚子摇臂在运行时产生振动。

    因而说产品层面的原因分析,要从产品的功能障碍出发,具体到具体零部件上的具体产品特性。有可能是某产品特性设计选择不好,也有可能是该产品特性加工制造时不符合图纸要求。

    2)过程层面的原因分析

    针对产品特性在加工制造时不符合要求,也即符合性问题,我们就需要进入第二个层面的原因分析,过程层面的原因分析。如果是生产制造过程的产品检测环节发现了某产品特性不满足要求的问题,那就直接是符合性问题了,也就可以直接进入过程层面的原因分析了。

    概括地说,过程层面的原因分析,是需要从产品特性的不符合出发,寻找到具体的生产线、具体的工序、工位、工步的具体的过程特性的原因。这个时候生产加工过程结果,也就是产品特性,就可以当做函数Y了。而过程的输入——过程特性,和和影响本工序加工结果的上游工序所产生的产品特性,作为自变量X。那么过程层面的原因分析就又是个由某个y的不符合,寻找相关的x及合适的x的取值范围的过程了。

    例如图纸要求的密封螺纹牙形被错误地加工成为紧固螺纹牙形,其过程层面的原因是孔的螺纹加工刀具型号使用错误;产品产生铸造疏松是因为产品的机构上存在热结,而热结作为最后冷却的部分,而且没有铝水的补充通道,造成最后凝结部分冷却收缩后疏松;凸轮轴加工振纹是因为精磨工位砂轮动平衡不好,而且砂轮主轴间隙过大,导致砂轮在加工过程中振动。

    过程层面的原因,可能是工艺设计选择没有设计好;也可能是工艺设计没问题,而过程特性没有控制好而不符合工艺要求了。

    3)控制方法层面的原因分析

    过程层面的原因找到了,接下来就要考虑控制方法层面的原因。

    所谓控制方法是我们在现场质量控制过程中为保证产品质量所采取的方方面面的所有活动。主要包括两个方面:一是对过程各项输入——人、机、料、法、环境、物流等各个方面技术特性的管控方法,以保证过程输入的稳定;以及对过程输出,也即产品特性的检测方法,以便在过程输出发生波动时及时调整过程的输入。

    因而控制方法层面的原因要考虑两个方面,对过程输入的管控,和对过程输出的检测和监控。

    例如螺纹牙形加工错误问题,对螺纹孔加工刀具的型号在换刀图中没有明确的规定,换刀作业指导书中没有要求核对刀具型号;对产品螺纹形状没有明确的检测要求;对螺纹止通规牙形的选择也没有明确,止通规选择错误。再例如产品铸造疏松,对模具热结处没有强制冷却要求,没有产品审核解剖检验工件内部的疏松;再例如凸轮轴振纹问题,对砂轮的动平衡没有明确的规定,在砂轮修模时没要求检测动平衡;对砂轮主轴的间隙、跳动没有在设备预防性预见性维护保养中规定定期检测;对凸轮轴有粗糙度检测,但没有波纹度检测和振纹检测(沿着圆周方向)。

    4)管理层面的原因分析

    管理层面的原因分析,在上图中就找不到相关的转换关系了。管理层面的原因分析就是要找到保证这些基础的上层建筑方面的原因了。

    管理层面的原因,就是要找到于前三个层面的原因相关的:

    流程、制度是否未策划或策划不完善;

    质量工具、质量方法是否被应用,是否被正确地应用;

    部门和岗位职责是否明确,清晰,有无交叉和重叠;

    人力资源、物的资源是否配备到位;

    人员能力是否满足要求;

    执行力是否足够,激励绩效和执行性的管控是否方法合适

    例如螺纹密封问题,由于产品设计人员不了解紧固螺纹和密封螺纹的差别,产品设计人员的经验和能力不足;企业未建立起典型密封结构的设计指南。

    产品缩孔问题,企业在项目阶段未开展产品设计的工艺性分析,未能识别出热结的影响;铸造过程设计和模具开发阶段未使用模流分析等模拟计算验证手段来分析识别铸造冷却过程中的疏松等风险。

    凸轮轴振纹问题,产品设计人员经验不足,未识别出对凸轮轴振纹的要求;工艺设计人员开展PFMEA分析过程中未能识别高速旋转件(砂轮)的动平衡要求;未能识别出磨床主轴跳动和主轴间隙的要求,工艺设计人员能力不足;PFMEA采用头脑风暴法和经验积累方法,未使用功能树分析和质量功能展开来支持PFMEA,方法不够好,需要提高。

    四层分析法的优点:

    这里所说的四个层面的分析,就是把5why的方法具体化套路化了。而且比5why更明确,更细化。利用原因分析的四个层面的指导思想,就更容易帮助普通工程师在质量分析中做到深入分析系统性原因了。

    一个点上的产品质量问题,如果按照四个层面的原因分析的方法,就可以找到某些管理方面的问题。在线上甚至面上做改进,就可以避免以后一系列的相似的问题,就可以逐步把企业的整体质量体系建设逐步完善起来了。所以我在工作中更喜欢强调四个层面的原因分析,而不太喜欢讲5why。

    2、实施方法

    5WHY 从三个层面来实施:

    1) 为什么会发生?

    从“制造”的角度。

    2) 为什么没有发现?

    从“检验”的角度。

    3) 为什么没有从系统上预防事故?

    从“体系”或“流程”的角度。

    每个层面连续 5 次或 N 次的询问,得出最终结论。

    只有以上三个层面的问题都探寻出来,才能发现根本问题,并寻求解决。

    经典案例:

    丰田汽车公司前副社长大野耐一曾举了一个例子来找出停机的真正原因:

    ★问题一:为什么机器停了?

    答案一:因为机器超载,保险丝烧断了。

    ★问题二:为什么机器会超载?

    答案二:因为轴承的润滑不足。

    ★问题三:为什么轴承会润滑不足?

    答案三:因为润滑泵失灵了。

    ★问题四:为什么润滑泵会失灵?

    答案四:因为它的轮轴耗损了。

    ★问题五:为什么润滑泵的轮轴会耗损?

    答案五:因为杂质跑到里面去了。

    经过连续五次不停地问“为什么”,才找到问题的真正原因和解决的方法,在润滑泵上加装滤网。

    如果员工没有以这种追根究底的精神来发掘问题,他们很可能只是换根保险丝草草了事,真正的问题还是没有解决。

    3、解决问题步骤

    第一部分

    :把握现状

    ★步骤1:识别问题

    在方法的第一步中,你开始了解一个可能大、模糊或复杂的问题。

    你掌握一些信息,但一定没有掌握详细事实。

    问:我知道什么?

    ★步骤2:澄清问题

    方法中接下来的步骤是澄清问题。为得到更清楚的理解,问:

    实际发生了什么?

    应该发生什么?

    ★步骤3:分解问题

    在这一步,如果必要,需要向相关人员调查,将问题分解为小的、独立的元素。

    关于这个问题我还知道什么?

    还有其他子问题吗?

    ★步骤4:查找原因要点(PoC)

    现在,焦点集中在查找问题原因的实际要点上。你需要追溯来了解第一手的原因要点。问:

    我需要去哪里?

    我需要看什么?

    谁可能掌握有关问题的信息?

    ★步骤5:把握问题的倾向

    要把握问题的倾向,问:

    谁?

    哪个?

    什么时间?

    多少频次?

    多大量?

    在问为什么之前,问这些问题是很重要的。

    第二部分

    : 原因调查

    ★步骤6:识别并确认异常现象的直接原因。

    如果原因是可见的,验证它。如果原因是不可见的,考虑潜在原因并核实最可能的原因。依据事实确认直接原因。问:

    这个问题为什么发生?

    我能看见问题的直接原因吗?

    如果不能,我怀疑什么是潜在原因呢?

    我怎么核实最可能的潜在原因呢?

    我怎么确认直接原因?

    ★步骤7:使用“5个为什么”调查方法来建立一个通向根本原因的原因/效果关系链。

    问:处理直接原因会防止再发生吗?

    如果不能,我能发现下一级原因吗?

    如果不能,我怀疑什么是下一级原因呢?

    我怎么才能核实和确认下一级有原因呢?

    处理这一级原因会防止再发生吗?

    如果不能,继续问“为什么”直到找到根本原因。在必须处理以防止再发生的原因处停止,问:

    我已经找到问题的根本原因了吗?

    我能通过处理这个原因来防止再发生吗?

    这个原因能通过以事实为依据的原因/效果关系链与问题联系起来吗?

    这个链通过了“因此”检验了吗?

    如果我再问“为什么”会进入另一个问题吗?

    确认你已经使用“5个为什么”调查方法来回答这些问题。

    为什么我们有了这个问题?

    为什么问题会到达顾客处?

    为什么我们的系统允许问题发生?

    ★步骤8:采取明确的措施来处理问题

    使用临时措施来去除异常现象直到根本原因能够被处理掉。问:

    临时措施会遏止问题直到永久解决措施能被实施吗?

    实施纠正措施来处理根本原因以防止再发生。问:

    纠正措施会防止问题发生吗?

    跟踪并核实结果。问:

    解决方案有效吗?

    我如何确认?

    为什么一为什么分析法检查清单

    为确认你已经按照问题解决模型操作,当你完成问题解决过程时,使用这个检查清单。

    4、询问回答技巧

    通常情况下,在询问为什么的时候,因为是发散性思维,很难把握询问和回答者的在受控范围内。

    比如:这个工件为什么尺寸不合格?因为装夹松动;

    为什么装夹松动?因为操作工没装好;

    为什么操作工没装好?因为操作工技能不足;

    为什么技能不足?因为人事没有考评

    类似这样的情况,在 5WHY 分析中,经常发现。

    所以,我们在利用 5WHY 进行根本原因分析时,一定要把握好一些基本原则:

    1)回答的理由是受控的;

    2)询问和回答是在限定的一定的流程范围内;

    3)从回答的结果中,我们能够找到行动的方向。

     

     


    refer:

    https://baike.baidu.com/item/5why%E5%88%86%E6%9E%90%E6%B3%95/575907?bk_share=wechat&bk_sharefr=lemma

    展开全文
  • 检测中质量监督常见的数个问题

    千次阅读 2020-09-26 22:46:26
    小析姐总结了11个实验室质量监督的常见问题,看看你们是否也这样的问题。 1、监督走过场,形式化 实验室设置的质量监督员往往为本科室成员,在履行监督职责时抹不开面子,对不合理不正确的做法不能及时指出,或者...
  • 人(Man):操作者对质量的认识、技术熟练程度、身体状况等; 机器(Machine):机器设备、测量仪器的精度和维护保养状况等; 材料(Material):材料的成分、物理性能和化学性能等; 方法(Method):这里包括生产...
  • MODIS产品质量控制文件使用方法

    千次阅读 2020-05-18 00:51:13
    官方关于产品质量控制的说明(机翻) 质量指标 在生产过程中生成的CoreMetadata.0全局属性QA 中的元数据对象以及质量控制(QC)SDS中给出,或者在数据产品产品后科学和质量检查中给出。CoreMetadata.0中的 QA元数据...
  • 图像质量评价方法介绍

    千次阅读 2019-10-26 20:12:29
    然而,图像在获取、压缩、处理、传输、显示等过程中难免会出现一定程度的失真。如何衡量图像的质量、评定图像是否满足某种特定应用要求?要解决这个问题,需要建立有效的图像质量评价体制。目前,图像质量评价从方法...
  • 「创作中心」的初衷是尽可能让CSDN博主们创作的优质...质量分,故名思义,就是博文内容质量分,它是系统进行质量识别后给出的创作维度分,考验的是博主的创作水准。 1、发文环节增加质量分检测 博文内容编辑完成后,
  • MODIS数据产品及其HDF文件处理

    千次阅读 2020-02-23 17:20:17
    基本的土地覆盖分为IGBP(International Geosphere Biosphere Programme,国际地圈生物圈计划)定义的17类,包括11类自然植被分类,3类土地利用和土地镶嵌,3类无植生土地分类。  Modis Terra数据1KM土地覆盖...
  • 软件质量控制问题质量控制技术

    千次阅读 2021-09-19 21:51:53
    如果输入产品有缺陷,那么这些缺陷不仅不会在后续产品中自动消失,甚至它比对后续阶段产品的影响将成倍放大,当发现产品质量与预想的很大差别时,要反馈到前面的过程并采取纠正措施。这是产品的一个重要特性,也...
  • 如果还在质量圈,就会面临一个问题质量哪些岗位可供选择?这些岗位又什么要求?人总结了质量部27个岗位职责,供参考! 很多单位规模都不大,就算是不大的单位,一个部门两三人,作为质量管理人员还是要...
  • 计算流体动力学(CFD)数据的后处理是从模型中准确得出正确结论、向决策者展示结果、确保产品设计最佳化的关键步骤。CFD模拟生成的输出文件通常很大,这使得高效地创建有用的可视化结果成为一项艰巨的任务。设计...
  • 今天就说说近期大家比较关心的话题,根据自己多年的测试经验,对于一个企业能否很好的生存下去,四个核心指标,产品质量Q、服务质量S、产品价格P、响应时间T,在我看来,属于技术范畴的2个最核心的指标是:一是...
  • 摘要:品质人员的工作职责之一就是要及时发现反馈生产中的品质异常状况,并督促现场执行改善措施、追踪其改善效果,保证只有合格的产品才能转入下一道工序,生产出高质量产品。品质人员的工作职责1、熟悉所控制...
  • 目录 Bug属性规范及流程1 1.目的2 2.范围3 3.工具3 4.角色和职责3 5.Bug属性定义3 5.1.bug类型4 5.2.bug严重性4 ...6.5.2产品发布后发现的bug8 6.6bug分析8 目的 本文档定义bug的整个生命周期,...
  • 长生生物事件的反思:质量是生命

    万次阅读 2018-08-06 18:42:58
    一个问题,需要专家学者、监管机构和业内人士研讨,那就是未来如何避免类似事件的发生,这是最为重要的根本问题。 曾几何时,多少企业的口号是“质量是企业的生命”,最近这些年,似乎因为这句话太平淡了,已经很...
  • 软件质量是软件特性的综合,指软件满足规定或潜在用户需求的能力,其主要从内部质量、外部质量、使用质量和过程质量这四个方面来衡量。 2、软件质量模型 测度与度量:在软件质量中用于测量的一种量化的标度和方法即...
  • 我们一直都知道,高质量交付从来都不是一件轻松容易的事情,所以当每开启一个项目的时候,三个问题要问自己:1、项目的验收标准是否确立并得到共识?不成熟的委托方会希望验收标准是模糊的,大致上会两种原因,...
  • 如何高质量的完成产品需求开发

    千次阅读 2016-10-26 09:07:17
    这期间,实现了很多的产品需求,也积累了一些经验。这里稍作总结,希望能给新入行的前端小伙伴们一些参考。 1.做好需求的关键点 要说如何做好一个需求,展开来讲,可以写好几篇文章,这里只挑重点来讲。 最基本的,...
  • 浅谈安防监控中视频图像处理技术

    千次阅读 2019-08-16 08:48:45
    随着计算机软件、硬件技术的日新月异的发展和普及,人类已经进入一个高速发展的信息化时代,人类大概80%的信息来自图像,科学研究、技术应用中图像处理技术越来越成为不可缺少的手段。安防行业已经进入一个崭新的...
  • 6个质量特性和21个质量子特性

    千次阅读 2019-11-22 13:07:39
    六个特性:功能性、可靠性、易用性、效率、维护性、可移植性1、功能性:当软件在指定条件下使用时,软件产品提供满足明确和隐含要求的功能的能力 1.1、适合性:软件产品为指定的任务和用户目标提供一组合适的功能的...
  • 引自:itongji 研究称,整个人类文明所获得的全部...人说大数据是黄金、是竞争力,然而在这一切谈论的背后却鲜人关注数据质量这个最根本的问题。普元数据产品总监王轩认为,大数据处理的关键就是解决数
  • 质量免费--读书笔记(上篇)

    千次阅读 2018-10-10 18:50:22
    推荐序:韦恩.考斯特 克劳士比非常想让人们知道:质量的定义是符合要求,而不是好;质量的系统是预防,而...是用质量文化把质量融入日常的业务和关系中,或者说,已变成了一个组织管理中重要的思想和实质的成分。...
  • 测试完成后还有bug,测试人员肯定是责任的,第一时间要赶紧处理而不是着急甩...所以出现bug后,不要直接甩锅,这样让人感觉在逃避问题。第一要紧事情是处理bug,尽量减少对用户的影响;只要用户影响不大,即便责任
  • 1)本PA的名字虽然称为过程质量保证,但是实际上仍然是包含过程的质量保证与产品质量保证。 2)过程是历史经验教训的总结,是对这些历史财富的规范化,标准化,是为了避免错误的重现。而质量保证则是监督这些历史...
  • 项目管理:项目质量管理

    千次阅读 2021-01-15 10:09:41
    “规划质量管理”、“管理质量”、“控制质量”相互影响、交叠进行,没有先后顺序。 “管理质量”的重点是审计,需要对“规划质量管理”的结果和“控制质量”的结果都审计。 管理质量是所有人的共同职责,包括:...
  • 文章目录数据源分类按获取方式分按表现方式分4D产品-从应用来分空间数据采集与处理的基本流程数据源选择数据采集方法的确定数据的编辑与处理数据质量控制与评价数据入库 【GIS】整个地理信息系统就是围绕 空间数据...
  • 2.采用E-C方法的好处:经验的工程师,并不是因为比其他人聪明,其实是遇到的问题多,处理的多,善于学习、触类旁通,知道的就多了,设计的时候就知道要干什么,最终减少网上问题,提供产品质量。 3.如何采用E-C...
  • 五步玩转质量回溯

    千次阅读 2020-07-09 14:57:08
    **回溯目的:**通过问题定位、根因分析、措施改进,预防同类问题再次发生,提高产品质量水平。 **回溯导向:**质量回溯不是追责和考核,而是自省和改进。 质量回溯理念的宣贯是思想的松土,埋下了一颗持续改进的种子...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 240,068
精华内容 96,027
关键字:

产品出现质量问题怎么处理