AI时代,从需求思维方式到专家系统实例解析

2018年05月28日 人人都是产品经理



———— / BEGIN / ————


AI系统经过近70年的发展,积累了浩如烟海的知识和成果,得到了广泛的应用;其中专家系统是人工智能领域中发展最为迅速、应用最为广泛的一个技术方向。


将社会专家的专业领域知识进行了充分的整理和浓缩,使专家系统成为人工智能在产品实际应用中最具实用价值的人工智能技术之一。


专家系统处理的主要是行业专家的或书本上的知识,正像在数据处理中数据是处理对象一样,所以它又称知识处理学。


其内容主要包括知识的获取、知识的表示以及知识的运用和处理等三大方面。


但是传统专家系统在实际需求中,存在推理效率比较低、知识规则少、开发比较困难等缺点,影响了专家系统应用的普及。


绝大部分专家系统都是讲如何进行各行业内特有需求的分析与决策,从人类的观点来看,所有这些领域内的需求都具有相同的抽象描述,即一般需求的分析与决策。


所以,产品经理理解掌握适合一般需求分析与决策的专家系统及开发工具,具有较大的产品落地意义和实用价值。


正如专家系统的先驱费根鲍姆所说的那样:


专家系统的力量是从它处理的知识中产生的,而不是从某种形式主义及其使用的参考模式中产生的。


因此,专家系统应该更强调行业知识本身力量的发挥,更强调对用户思维过程的支持。


一、首先,一般产品需求的思维方式


专家系统的种类比较多,其中应用较多的专家系统是需求分析与决策专家系统,其应用对象是各个应用领域内的需求分析与决策需求。


例如:凝血检测智能专家系统,如图1:



Expert Module最多同时可以管理四台血凝仪,包括STA R Max和STA Compact Max, 组成软性流水线,实现所有血凝仪同屏操作,数据统一管理,有效整合;全面管理所有标本和实验项目,增加仪器的处理能力;实现标本的自动审核,缩短标本周转时间;降低实验室人员的工作量,提高单位时间内的产出;整体提高实验室的血凝诊断水平,让临床更加满意,大幅提升综合效率。


* 注:笔者专家系统所要解决的不同行业的各类问题统一抽象为一般需求;如不特别说明,以后讨论的需求就是指一般需求,简称需求。


产品经理常常擅长通过增加功能来满足需求,在长期的产品设计中总结了许多行之有效的方法,甚至已经形成了一种产品思维定势,这些解决需求的方法具有一定的共性,具有普遍意义。


一般来说,产品经理在解决需求时主要运用以下需求思维方式:


1. 发现了什么需求?


2. 这些需求与哪些用户群有关?


3. 根据这些需求可以挖掘出可能出现什么潜在需求?哪些需求是伪需求?


4. 为什么会出现这些需求,它们的内在原因是什么?


5. 怎样去找证据证明自己的猜想,或者否定伪需求?


6. 需求出现了,它会带来什么样的影响,即会对其他的非此需求的用户产生怎样的影响,或产生新的需求?


7. 怎样处理已经出现了的需求?


8. 怎样预防一些伪需求的发生?


产品经理就是通过反复地思考这些需求,不断地对相关需求进行分析与决策,最终达到需求的解决。


显然,无论产品经理需要解决的具体需求是怎样的,解决需求的总体思路总是一致的。


所以在AI时代,产品经理可将专家系统的任务都归结为对一般需求的分析与决策。


二、其次,传统专家系统


2.1 专家系统的结构与运行


产品经理先来回顾一下传统专家系统,不同的专家系统,其功能与结构都不尽相同,但一般都包括人机接口、推理机、知识库及其管理系统、数据库及其管理系统、知识获取机构、解释机构这六个部分。


传统专家系统如下图2:



专家系统各部分模块的功能阐述如下:


2.1.1 知识库


即规则库,主要用产生式方法记录各种规则。


知识库是专家系统的基础,负责存储和管理专家系统中的知识。


简单介绍一下产生式方法的原理:


产生式表示法已经成了人工智能中应用最多的一种知识表示模式,尤其是在专家系统方面,许多成功的专家系统都是采用产生式知识表示方法。


产生式的基本形式 P→Q 或者 IF P THEN Q:


P是产生式的前提,也称为前件,它给出了该产生式可否使用的先决条件,由事实的逻辑组合来构成;


Q是一组结论或操作,也称为产生式的后件,它指出当前提P满足时,应该推出的结论或应该执行的动作。


产生式的含义:如果前提P满足,则可推出结论Q或执行Q所规定的操作。


2.1.2 推理机


它是专家系统的核心,由一组计算机程序组成,主要功能是决定如何选用知识库中的知识以推出新知识。


2.1.3 综合数据库或全局数据库


综合数据库存放专家系统中反映系统当前状态的事实数据,它们是系统操作的对象,是在推理过程产生的中间数据。


综合数据库中,数据的表示和组织与知识库中知识的表示和组织具有相容性,使推理机能方便地使用知识库中的知识和综合数据库中的事实对问题求解。


2.1.4 人机界面


它是人与计算机交互的通道,负责将用户输入的信息转换成系统内规范化的表示形式,并将这些内部表示交给相应的模块去处理,同时将推理的结果及时反馈给用户。


传统产品经理尤其是PC互联网和移动互联网时代产品设计型产品经理最擅长的点。


2.1.6 知识获取程序


主要用于知识库的构建,即将知识转换为计算机可利用的形式送入知识库。


2.1.7 解释程序


用于对推理行为作出解释,主要回答用户提出的“为什么”等问题。


一般是通过跟踪并记录推理过程来实现解释功能。


2.2 传统专家系统的主要缺陷


传统的专家系统是从人工智能的一个主要组成部分,特别强调从数学和计算机理论角度上考虑系统的结构和运行机制,而基本没有融合用户处理一般需求方法的角度来设计专家系统。


2.2.1 知识表示和管理缺陷


人员要求缺陷


专家系统一般采用产生式知识表示方法进行描述,虽然大多数专家系统的开发可以采用许多性能优良的专家系统开发工具,但仍然要求系统开发者具备较强的人工智能理论水平和计算机开发应用水平,熟悉人工智能语言如Lisp 、Prolog语言。


系统的开发也离不开知识工程师,从而极大地限制了专家系统的应用。


知识库管理缺陷


使用这些人工智能开发语言也不利于知识的管理。


系统开发者必须仔细地构建知识库,维护知识库的一致性,减少知识之间的冲突。


虽然目前已有许多系统采用数据库系统进行知识的管理,但大部分仍然仅用于简单存储规则知识,不能有效发挥数据库的功能。


从应用的效果看,专家系统的规则数量不宜太多。


知识关系缺陷


一般情况下,是不区分问题的现象与因果关系之间差别的,它们都被统一称为知识库中的规则或知识。


事实上,问题的因果关系才是真正影响问题的产生和变化的主要因素,而现象只是问题的表现,只有抓住了因果关系才可以正确、有效、高速地解决问题。


2.2.2 推理缺陷


过分强调计算机的能力


推理过程中,知识的匹配和冲突消解问题是专家系统中推理的根本问题,直接影响了推理的效率,甚至使系统陷于瘫痪,这也是目前专家系统不容易解决较大问题的一个重要原因。


这个问题是专家系统的固有问题,也是人工智能所固有的问题——因为推理本身就是知识的搜索、匹配过程,容易出现组合爆炸。


笔者实地走访多家人工智能创业企业,其产品应用在金融行业时没有问题,当转移到教育行业、转移到医疗行业时产品初期经常出现Bug的原因,在目前的人工智能水平上完全的机器推理仍然是一个难以解决的问题。


不支持思维过程的反复性、跳跃性


将推理过程分为正向推理和反向推理以及混合推理,过分强调推理的形式,不区分问题的现象和原因,从而加大了用户的使用要求和系统的开发难度。


而事实上,人类的思维过程是一个不断反复的过程,强调的是问题之间的因果联系而不是推理形式。


缺乏强有力的解释功能


一般来说:推理的运行是一种黑箱操作过程,用户完全在计算机的引导下进行操作不明白系统究竟是如何运行的,只有在推理结束后才能通过解释机制获得问题的解答。


这样进行推理对许多用户来说,很多步骤其实是没有必要的——既增加了系统开发难度,又浪费了用户的宝贵时间。


例如:就像做应用题。结果是答案,推理就是计算过程,解释就是对计算方案的说明。

一道题可以有多种计算方案,或者说计算方法,但结果可能是一样的。


三、重新定义专家系统的产品架构


3.1 产品设计需求思维


时下产品经理对专家系统运用时应该从两方面着手:


一方面将专家系统的处理能力定位在专用的问题分析与决策功能上,而不是通用的人工智能问题的分析与求解,这样便于专家系统应用领域的知识系统构建。


例如:做金融领域的理财顾问机器人,跟做健康管理领域的机器人客服服务系统,从需求期望上就区分开来。


另一个方面(也是时下产品经理应该重点发挥产品设计功力的点)就是:明白人工智能是属于做可能性的事情即人工智能是存在概率和逼近完美的过程,产品设计合理的产品运行机制,使专家系统更符合人们的使用习惯。


设计思想的核心是:必须充分考虑与用户痛点与人工智能求解方法有机结合,发挥用户的主观能动性。


在设计面向一般需求分析与决策专家系统时应该重点考虑以下内容:


1. 确定需求对象;


2. 确定需求所涉及的用户和需求场景发生时所出现的现象;


3. 确定需求用户与所涉及用户和需求现象之间的关联关系;


4. 确定需求用户之间的因果关系;


5. 提供基于需求用户和需求因果关系的推理机制;


6. 支持现象对需求的辅助推理机制;


7. 提供与推理过程相伴的解释机制;


8. 适合一般需求的分析与求解。


3.2 新专家系统产品模块


主要由以下模块组成:


(1)用户需求,用于描述客观存在的需求


需求的对象可以是具体的,也可以是抽象的。本系统中所有的知识或规则表示和推理均是以需求对象为基本单元建立的,即知识系统或知识库中知识的核心表现形式是需求对象。


(2)基本对象,也称需求主体对象


任何需求都是在一定数量的基本对象上发生的,而每一个基本对象又存在若干个不同需求。在一般情况下基本对象不可再分。


(3)需求现象对象,简称需求现象


描述需求发生时应该会出现的现象。需求现象是需求的表现形式,也是人们对需求的最基本认识。在许多情况下也是人们对需求进行诊断的依据。


(4)因果关系


需求对象之间存在因果关系,因果关系是需求产生的根本原因。


知识系统中的因果关系是一种复杂的网状结构,但对于某一个具体需求对象来说,因果关系表现为一棵树,所以常常被称为因果树。同样也是由于因果关系才使现象具有一定的继承性,即在许多情况下需求对象。


一般也具有它的原因对象所具有的现象:


  • 需求处理方法或措施:每一类需求都有对其进行处理的方法或措施。这里将对某类需求进行处理的方法或措施分为两类:正确的处理方法或措施,也称为预防措施;产生后应该采取的方法或措施,也称为补救措施。


  • 需求事实:如果一个需求存在了,则称该需求为需求事实,即已经确定的需求。需求事实是推理的出发点和归结点。


  • 过程知识:主要用于描述需求分析与决策先后次序的知识。


  • 原理叙述性知识:也是知识的主要组成部分,由于专家系统解决需求的针对性,不可能将所有的知识全部需求化处理,只能以叙述性方式(如文件、音像、动画、三维造型等)展现。


所有这些基本组成对象都是系统知识的基本组成部分。其中因果关系描述的是知识之间的动态组成关系,用因果网络来记录,而其余各种组成部分构成描述知识系统的静态特性,则统一存放在知识字典中。


3.3 产品重新定义总体结构


产品总体结构如图3所示:



产品架构分为上下两层:


  • 上层是系统交互层,主要是供用户【含其他维护人员】和领域行业专家使用。


  • 下层是系统支撑层,提供基础知识表示和推理功能。


支撑层各模块功能如下:


  • 需求对象模块:用于管理智能系统中的核心对象即需求对象。


  • 基本对象模块:管理需求对象所涉及的相关基本对象。


  • 需求现象模块:管理需求所表现的现象。


  • 因果关系模块:用于管理需求对象之间存在的因果关系。


  • 处理方法模块:提供针对某类需求所应该使用的处理方法


  • 辅助知识模块:用于描述在解决需求过程中可以作为参考的知识。


  • 过程知识模块:提供对于特定应用领域需求分析与决策的过程知识,以利于用户尽快发现问题。


交互层主要提供与用户交互的各类模块,并通过与支撑层核心模块进行数据交换来进行需求的分析与决策。


交互层的主要模块有:


  • 需求分析模块:描述需求的因果关系、相关影响对象(包括基本对象和需求对象)、相应的处理方法等。


  • 需求决策模块:通过对需求的分析及获得的已经存在的需求信息,求解出将会出现的需求,并提出应该采取的措施。


  • 知识录入和维护模块:知识录入就是将新的领域行业专家知识加入到智能系统中,主要指智能系统初始化阶段的数据处理和知识的添加处理。知识维护主要提供当智能系统中知识发生改变时保证知识之间的一致性和完整性的一些操作。


  • 知识发现模块:用于新知识的发现。


  • 应用定制模块:当系统应用于不同领域时用于修改交互界面,使之符合新的应用要求。


  • 辅助功能模块:提供问题分析与决策的辅助功能,如基本原因查找、推理过程的解释、报表打印等。


3.4 运行机制


人工智能系统的核心是:推理。


即:如何通过已有的知识推出新的知识。也称为知识的求解。


在专家系统中,已知前件得到后件的推理称为正向推理,反过来则称为反向推理。


然而,人类的推理过程并不是简单的正向或反向推理。


如前所述,人类的推理或思考过程其实是一个复杂的反复过程,即不断交替进行正向推理和反向推理的过程。


推理的复杂性主要来源于两个方面:


1. 实际需求的复杂性;


2. 推理方式的复杂性。


在思维过程中,一般的推理都包含正向推理和反向推理过程,而且正向推理和反向推理的切换是随机的;单纯的正向推理或反向推理一般出现在证明过程已经完成以后的表达中,如定理的证明通常只写出最后的证明过程,无须写思考过程。


推理的复杂性,极大地降低了专家系统推理效率。


对于专家系统而言,克服推理复杂性的最有效方法是:使专家系统的运行与人们在日常生活中处理需求的分析与决策方法一致,即提供面向需求分析与决策的支持。


系统提供需求分析机制、需求决策机制、解释机制和其他机制,通过可视化交互界面实现自由的推理过程,完成需求的分析与决策。


简单说就是:就像做应用题。结果是答案,推理就是计算过程,解释就是对计算方案的说明。

一道题可以有多种计算方案,或者说计算方法,但结果可能是一样的。


3.4.1 需求分析机制


需求分析机制是系统提供的帮助用户对需求进行深入了解的运行机制。主要过程包括:


  • 了解需求的症状:揭示需求发生和不发生时的现象。


  • 了解需求的成因:告诉用户为什么会发生这样的需求,具有哪些影响因素,这些因素是怎样起作用的等等。


  • 了解需求的预防措施:采用什么样的方式可以预防需求的发生。


  • 了解需求的补救措施:当需求发生以后应该采取什么样的补救措施,又会形成哪些新的需求。


需求分析过程是一个递归过程,直到用户满意为止。显然,需求分析过程也是一种学习过程,是对需求的一种了解,无须对需求作决策。


3.4.2 需求决策机制


需求决策机制是帮助用户对需求进行决策的运行机制,即通过对需求进行分析或者采集需求事实,最后推出新的需求事实。因此推理过程又可称为获得需求事实的过程。


需求决策机制如图4:



需求事实的产生可以有以下三种方式:


1. 分析事实:用户通过使用需求分析机制确定某项需求的出现。


2. 输入事实:是用户输入的已经发生的需求对象,或传感器等采集并直接转换的需求事实。


3. 生成事实:由系统经过推理得到的新需求称为生成事实。生成事实来源有两个,一个是某个需求的所有现象得到满足;另一个是因果关系得到满足。当产生生成事实的原因不存在时,该生成事实也应该被删除。


3.4.3 解释机制


解释机制是对推理过程和结果的解释。


可以有两种方式:即将推理过程的全部过程按顺序展现出来和按因果关系展现出来。


前者可以通过记录所有的推理过程得到,这样得到解释可能会显得比较零乱;


后者则忽略具体的推理过程,而只是对推理的结果加以解释。


这是一种经过整理后的解释,对整理思维过程比较好。


此架构主要支持后一种解释机制,因为用户在进行需求分析及决策的过程中已经对自己的推理过程比较熟悉,而对推理结果的解释则有利于用户整理思路,抓住需求的本质。


四、专家系统实例解析


4.1 H2O.AI


非技术人员应用专家系统的例子:H2O.AI


降低数据科学工作难度的机器学习专家系统,Driverless AI ,该人工智能专家系统让非技术人员也能应用机器学习解决研究阶段复杂、难预测,并集合生成对抗网络(GANs)和强化学习的应用问题;帮助用户针对特定的问题选取已组建好的合适的机器学习算法,例如准备数据,校对参数,决定优先算法等。


该系统实现了特征工程自动化,并以GPU加速运算,从而降低数据科学在企业环境下的应用门槛,并有一些常见应用场景的预测模块。


例如,在销售及人力资源相关流程中,用户可以使用相应场景模块或者机器学习基础的数据分析结果,并获得创新见解。


界面如图5:



4.2 Querium 


个性化教育的例子:Querium


帮助青年及成年学习者掌握关键的STEM(科学、技术、工程、数学)技能,以实现大学或职业目标,为熟悉数据技术的人设计的Querium专利产品,通过专家系统提供个性化/小巧的课程,分步辅导,激励学习者取得成功。


用户在手机上手写数学步骤,获取全天候的及时反馈,我通过授权的方式,让用户使用其基于云托管的人工智能软件。


界面如图6:



4.3 法狗狗


预测系统及插件:法狗狗


将公开的判例数据结构化,利用机器学习的技术,学习其中的规律,并对新的案件作出预测。


采用了与IBM Waston Rose 相同的专家系统与概率分析相结合的方式。但IBM沃森所在的美国是判例法系,律师对判决结果影响明显,中国则是成文法系,律师对结果的影响要弱很多;因此在实际业务落地中,法狗狗采用了与IBM Waston Rose不同的路径,重点用来提升律师的效率和扩大案源。


开发了一套应用于刑事案件的案件预测系统,只需简单的选定罪行分类,并提供伤亡人数,案发地点等简单信息,即可以获得安全的预测结果及历史案例。


普通用户可以通过简单输入信息,快速获得专业精准的案情预测,律师可以通过详细的深度案情分析,快速掌握切入点,提高接单成功率。


案情预测系统扩大到了劳务纠纷,婚姻家事,交通事故场景,提供专属定制服务。


其公司产品在不同应用领域知识迁移可以在2-3周内完成,未来的效率还可以进一步提高,这套安全预测专家系统被做成了机器人插件的产品形态。


界面如图7:



五、最后


专家系统是人工智能系统的一部分,在产品落地应用中没必要同NLP、机器学习、深度学习等人工智能技术区隔开来;相反专家系统,配合NLP的先验数据,模式识别能做到一个更加真实的系统。


笔者认为:AI时代,适合做产品的只有产品经理——因为产品经理才有正常的工作时间研究如此多的AI技术特点、技术成熟度,同时不需要考虑系统工程师的Coding。


在人工智能热火朝天的当下,产品经理应该看到AI技术的本质,然后了解这个技术的成熟程度和校验的概率,迅速在当前概率水平上输出MVP产品,并随着AI技术概率的提升,持续迭代AI产品设计体验。


———— / END / ————


点击“阅读原文”下载APP

收藏 已赞