为了使CBR的方法被有效且广泛地应用,学者们基于其核心思想构建了模型框架以实现其通用性。例如,Hunt^{[ 12]}于1995年提出了基于评估改进策略的Hunt模型, Leake^{[ 13]}将CBR看作是“记忆和适用”的过程,并将CBR的应用周期表达成Ref,提出了分类求解型CBR模型。

除了上述两个案例推理模型,被大多数学者接受认可的则是Aamodt和Plaza^{[ 14]}所构造的R4循环模型,此模型展现了对案例推理思想更好的理解,在应用方面更具通用性,成为案例推理应用系统开发的主流结构框架。R4将CBR过程划分为Retrieve(检索相似的旧案例)、Reuse(重用旧案例的解决方案)、Revise(对旧案例的解决方案修改调整)和Retain(保存新案例)4个阶段。

R4模型如图1所示:

图1

	Figure Option ViewDownloadNew Window
	图1 R4模型

然而,以上案例推理模型存在一个共同缺陷就是默认案例和案例库已经存在,而忽视了构建案例库对于案例推理是一项重要的前提条件。因此,本文参照由Finnie等^{[ 15]}提出的R5模型如图2所示,即在R4的所有步骤之前增加案例再分配(Repartition),强调了案例库构建是案例推理在应用中的重要组成部分。此步骤也可被理解为对案例进行表示的任务,其中Wp(the possible world of problem)和Ws (the possible world of solution) 分别表示此领域下的问题和解决方案,即每个案例都由问题描述和解决方案这两部分组成,形成结构化的案例。

图2

	Figure Option ViewDownloadNew Window
	图2 R5模型

本文参照R5模型中的任务流程,针对菜谱知识特性对菜谱推荐系统进行功能模块策略设计,明确各任务阶段应用的技术,用以解决菜谱的知识表示、知识利用和知识学习等方面的问题,旨在实现以下功能:根据用户所提交的食材,提供合适的菜谱,同时以营养价值为参考推荐其他相似菜谱。其工作原理为:首先,将菜谱文档按照知识层次框架进行规范化和统一化的知识表示,形成菜谱案例存入案例库;然后,用户可限定某些检索条件作为问题描述部分,案例推理系统则通过相似性运算检索出与当前问题相匹配的菜谱案例,如两者问题描述部分完全相同,则输出该菜谱案例,否则推荐相似度较高的菜谱案例;用户可参考经过增、减的推荐菜谱直接执行,或酌情参考相似食材形成的菜谱案例,以此形成新的菜谱案例;最后由用户反馈新案例是否具有可行性,再决定是否作为新案例加入案例库,以便为以后问题的求解使用。其系统模型如图3所示:

图3

	Figure Option ViewDownloadNew Window
	图3 菜谱推荐系统模型

由于菜谱知识的特性,本系统的推理功能可以细分为两种:

(1)以食材为主要搜索条件,若存在与搜索条件完全一致的菜谱案例则直接返回案例结果;若不存在,系统则推荐包含但不止于搜索条件或部分包含搜索条件的菜谱,并按相似程度排序。

(2)以菜名作为主要搜索条件,若存在完全符合的菜谱案例则直接返回结果。另外,此时系统还会进一步以案例中包含的食材为搜索条件,执行第一种推理功能以防用户食材准备不充分。

(1)菜谱文档的知识表示

案例表示是案例推理实现的基础,实际上就是将过去解决问题的文档表示成案例的形式,存储在案例库中。一般的案例表示应至少包括问题描述和对应解决方案,即<问题,解决方案>的二元组形式^{[ 16]},这也便明确了案例检索和案例修正的执行部分。

本文以中华烹饪文化知识库中的文档为实验对象。中华烹饪文化知识库包含各类菜谱、美食典故、相关名人等内容,通过对其中的菜谱知识分析发现具有如下特征:

①菜谱文档涉及的领域知识较多,每个领域的知识体系和数据类型具有很大的差异:包括食材、功效、营养、菜系、烹饪手法等。其中食材领域的数据量大、层次关系复杂,具有较强的逻辑规则;而功效领域,因数据量有限而多采用枚举方式表达;烹饪过程以文字描述为主。

②菜谱文档的结构性差、概念不规范。现存的菜谱文档一般多是基于文本的非结构化形式,因此需要把这种结构化差且概念不规范的文本表达为统一格式的规范化案例,以便于案例库的存储、标识和推理功能的实现。

常见的案例表示方法有案例特征属性、框架表示、基于XML的表示和面向对象法等。其中,案例特征属性表示法^{[ 17]}是一种比较简单的表示方法,将案例的特征属性组成一个集合,该集合则用来表示相应的案例,即Case={属性1,属性2,…,属性n},这种表示方法简单明了,但不能有效体现属性之间的结构关系和上下文语境。因此,本文将引入菜谱的本体结构与案例特征属性表示法结合,利用本体具有良好的概念层次结构,弥补案例特征属性表示法的缺陷,帮助建立属性之间的关系结构和规则定义。

通过对菜谱的多个特征属性聚类分组,可以发现菜谱文档基本是菜名、菜系、食材、辅料、调味品、烹饪过程和功效等内容的综合,以上7方面基本可以完成对菜谱文档的规范化和完整化描述。因此本文以上述7个特征属性将菜谱文档处理为XML文档。XML在描述数据的性质时使用标志和属性,不但能描述数据之间关系还能够对数据进行存储。XML技术在对象描述与可计算性方面均具有优势,便于在各个系统中使用。XML菜谱文档如图4所示:

图4

	Figure Option ViewDownloadNew Window
	图4 XML菜谱文档

(2)菜谱知识的本体构建

本文通过本体技术关联菜谱案例中的领域知识,形成层次化的知识体系,体现彼此之间的逻辑关系。本文参考本专题中《中华烹饪文化领域本体构建及其应用》一文中的本体构建的策略,采用自顶向下(先设计顶层概念,再逐步细分)与自底向上(先从领域文档中搜集尽可能多的领域概念,再逐步归纳)相结合的方法,使用OWL构建本体。首先对菜谱的知识边界和范围进行界定,菜谱主要包括菜名、菜系、食材、辅料、调味品、烹饪过程和功效这7部分内容,这便明确了菜谱本体构建的知识范围。在使用OWL情况下,第一步需要构建本体类(Class)层次结构,Thing是所有Class的基类,如图5所示:

图5

	Figure Option ViewDownloadNew Window
	图5 菜谱本体模型

在“Thing”这个超级父类下——即菜谱,构建上述7大类特征属性,这一步骤中存在特征属性转换为类的概念替换,后文仍将这7部分作为案例的特征属性进行案例推理设计。每一个大类下又分为若干个子类以及子类的子类。这样就构成了一个本体的骨架,即基本的本体类层次结构。接下来,OWL中使用属性对类进行具体描述。属性有两种类型:数据属性和对象属性。本文使用数据属性连接类和XML文档之间的关系,也可以理解为基于本体对案例进行XML处理过程,见图4。类之间的逻辑关系则由对象属性定义。上述7类彼此之间的对象属性一般为Disjoint,“食材”、“辅料”、“调味品”与Thing存在使用关系。

除了对菜谱文档进行知识表示之外,作为主要搜索条件的食材部分,本文也对其进行规范化的处理。食材领域的数据量庞大,并且存在一个概念由多个名词表示的现象。因此本文根据《中国食物成分表》2012版^{[ 18]}明确每一种食材的科学名称,以本体Label例举其他同义名词以防案例查询无法执行。

案例的检索与匹配是利用检索条件即问题描述部分,从案例库中检索尽可能相似的旧案例。目前案例推理的知识检索主要有最近相邻策略、归纳推理策略、知识引导策略、模板检索策略等, 并且最近相邻策略和归纳推理策略是目前较为普遍的检索方法^{[ 19]}。归纳推理策略通过提取案例间的特征,根据这些特征将案例组成一个类似判别网络的层次结构,检索时采用决策树策略进行检索。最近相邻法则适合于案例特征属性为数值型的情况,定义和计算案例之间的相似度。两者推理策略的方法不同,导致在适用对象和优劣势方面各有偏重,如表1所示:

表1

表1

表1 归纳推理策略和最近相邻策略比较 推理策略 基本方法 适用对象 特点 归纳推理 策略 提取案例特征,组成类似判别 网络的层次结果,采用决策树策略 案例特征相互独立,差异显著 需构建决策模型,推理结果针 对案例的单一特征属性 最近相邻 策略 定义和计算案例之间的相似度, 相似度最大的案例为匹配案例 案例特征可被数值表示 每一特征的相似度均使用相似函数进行运算, 便于多个特征综合,运算过程简单而直接

表1 归纳推理策略和最近相邻策略比较

(1)单个属性相似度计算

组成菜谱案例的各个属性的数据类型和知识特征都不同,因此对各个属性采取不同的相似度计算方法。根据菜谱推荐的功能,本文选取菜名、食材、功效作为计算相似度的对象。

食材以Taxonomy进行知识建模,其数据类型为symbol。本系统参照食物的科目属性和Cook’s Thesaurus^{[ 20]}的分类,构建食材的层次结构,分别为:肉类、蔬菜类、豆制品类,水果类、水产类,并在此基础下细化各类目的子类并添加实例。一方面可以保留食材实例之间的科目属性和层次关系,另一方面可以通过数值来表现食材实例之间的相似程度。

另外,由于本系统旨在推荐更具营养价值的菜谱,因此对食材实例之间相似度设定方面除了依据类目属性之外,也将营养价值作为参考指标,参与相似计算。鉴于营养成分对人体的必要性,选取《中国食物成分表》中:“碳水化合物”、“脂肪”、“蛋白质”、“维生素”、“矿物质”和“纤维”作为计算指标。

根据专家建议更具营养价值的菜谱,并非单单强调营养成分含量高,而应该理解为在满足基本营养摄入量的基础上,维持营养成分摄入比例的适当。因此,本系统以人体每日所需营养成分的数量为基准,对营养成分的相似性计算进行如下设计:若食物所含的营养成分与基准值相差越大则相似度越低,呈线性递减。如图6蛋白质为例,根据专家设定的每日摄入量25g为case,食材本身的蛋白质含量作为query,越接近每日所需的数量,其相似度越高。

图6

	Figure Option ViewDownloadNew Window
	图6 食材的蛋白质含量相似度计算法

综合以上两方面的设计,食材实例的运算公式为:

其中: sim(X_i, Y_i)表示食材实例X_i 和Y_i的第i个确定数属性的相似度;x_i、y_i分别表示实例X 和Y的第i个属性的值;max_i和min_i分别表示第i个属性的最大和最小值,一般设置为1和0;i为科目层次和营养价值。

功效,本系统将其等同为“适用人群”理解,数据类型为String,属于枚举式。在功效下例举可能的实例“素食”、“低胆固醇”等,定义实例之间不存在任何相似关系,相似度计算公式为:

菜名,数据类型为String,针对文本数据类型本文设定完全匹配作为推理计算方法,与功效的相似度计算方式相同。如若不存在完全匹配的菜谱,更推荐用户选择以食材检索的方式利用本系统。

(2)全局属性相似度计算设计

根据最近相邻算法的概念,本文采用全局相似度计算(Global Similarity Measure),公式为:

其中: sim(X_i, Y_i)表示案例X和Y在交集属性集中第i个属性上的局部相似度,Sim (X, Y)表示菜谱案例X和Y的案例全局相似度;Wi为菜谱案例X和Y交集属性集中的第i个属性在全局相似度中所占的权重,具体权重数值由专家设定。

本系统参考Ref模型设计案例修正策略,设置“一般修改”和“专门修改”两种功能。前者依据Ref模型中的解释型,对问题部分进行调整,直至与旧案例的问题匹配——即首先通过检索获得相似食材,再根据相似食材推理菜谱案例。后者依据Ref模型中的解决型,对旧案例的解决方案进行修正——即对已存菜谱案例的烹饪过程进行修改,将搜索食材替代原有菜谱中的既定食材。

(1)“一般修改”:首先,若存在与用户所定义的食材条件完全一致的菜谱案例,菜谱推荐系统即返回该案例。如果用户想要选择类似但更具营养的菜谱,则可以选择其他修正后的相似案例。对案例的修正行为体现在前期,将搜索食材替换为菜谱案例库中已有菜谱的相似食材。根据相似食材推理而得的相似案例,并不单纯以“一对一”的形式替换原菜谱案例中的食材,而是在满足搜索条件的基础上,推荐已经过验证的菜谱案例中的食材组合。

(2)“专门修改”:适用于用户要求搜索食材不被替换的情况下,若存在与搜索条件完全一致的菜谱案例则直接返回。若不存在,本系统则对检索得到的相似菜谱案例中烹饪过程进行调整,将烹饪过程中所使用的食材调整为搜索食材,此行为的可行性是基于食材之间科目属性、营养价值存在较高相似性。在这个过程中,新的食材组合将产生新的菜谱。考虑到需要经过实际操作才能证明其合理性和可行性,因此是否将新的菜谱作为案例添加至案例库中,本文认为,需要专家和用户参与评估。

例如:用户以“菜瓜,鸡蛋”为搜索条件,若执行“一般修改”,则系统会基于食材相似性和案例库中菜谱案例匹配的检索,将“菜瓜”替换为“西葫芦”,推荐菜谱“西葫芦炒蛋”。若执行“专门修改”,系统则将相似菜谱“西葫芦炒蛋”烹饪过程中的食材调整为“菜瓜,鸡蛋”形成“菜瓜炒鸡蛋”的新菜谱案例。

根据所设计的模型和各阶段任务方法,本文将利用myCBR软件构建菜谱推荐系统,以验证基于案例推理的菜谱推荐的有效性。myCBR工具由德国人工智能研究中心开发^{[ 21]},具有简单、易用、可扩展性强等特点,能够对局部相似性和总体相似性进行建模,并内置了基于最近邻等多种匹配策略的案例检索引擎,可支持快速原型构建。myCBR可以完成案例库建模、相似性计算设置、案例库案例导入等多项操作,并具备检索和计算案例相似性功能。总体来说,myCBR基本可以支持案例推理R5模型中的从案例表示至案例保存各项流程的构建。因此,my CBR 可以便捷且有效地测试案例推理方法在菜谱领域应用效果。

首先根据菜谱案例知识表示方法,在myCBR中根据图5构建菜谱案例的知识模型,如图7所示:

图7

	Figure Option ViewDownloadNew Window
	图7 myCBR案例库构建

基于此知识模型,将菜谱的XML文档转换为myCBR可导入的CSV数据,如图7所示为myCBR中的案例手动输入和显示界面。遵循3.4节中的案例检索策略,针对每个属性的数据类型,在myCBR中选择和设定相似度计算方法。以“食材”为例,在myCBR中完成Taxonomy构建后,对每个层次下的食材个体进一步利用Table形式,从科目属性和营养价值两个角度设置个体之间的相似数值,如图8所示:

图8

	Figure Option ViewDownloadNew Window
	图8 myCBR中食材实例的相似度计算设置

其他属性则各自依据4.2节中的相似度计算策略设定相对应的计算方法,见图6。最后利用欧氏距离综合各单项属性,完成全局相似度计算,计算检索出多维度空间下与搜索条件距离最相近的菜谱案例。

本次实验收录的菜谱案例共115个,涵盖了各种食材科目和菜系。以食材作为推理条件,设定“南豆腐”和“瘦肉”为搜索条件并执行“一般修改”,分别从查全率和查准率进行测评,然后与人工设置的推理结果进行比较检测其案例推理效果。另外本次实验还设置一组比较组,比较组对菜谱不进行任何知识表示、检索策略处理,仅以全文检索方式进行菜谱检索。两组实验结果如图9和图10所示:

图9

	Figure Option ViewDownloadNew Window
	图9 菜谱推荐系统实验测评结果

图10

	Figure Option ViewDownloadNew Window
	图10 比较组测评结果

从图9与图10比较可以看出查全率方面,相比于比较组的9个菜谱结果,菜谱案例推理系统共检索出与搜索条件相关的菜谱共15个,根据人工检查可以确定其已将案例库中同时包含“豆制品”和“肉类”食材的菜谱案例查全。从查准率——推荐效果来看,菜谱推荐系统最相似的前4位菜谱与人工建议的推荐菜谱相同,相似性顺序方面仅cooking #7(肉末蒸豆腐)与cooking #6(肉末香菇豆腐)的顺序交换。cooking #6(肉末香菇豆腐),cooking #7(肉末蒸豆腐),cooking #8(香菇肉丝豆腐汤)即为推荐菜谱案例。比较组所呈现的结果不但相似性与人工建议存在差距,也未能将完全匹配的 cooking #3(酱香肉末豆腐)置于首位,而且相似度也不如菜谱推荐系统以数值型给予用户直观的认识。

基于“南豆腐”和“瘦肉”的搜索条件,菜谱推荐系统为用户提供其他具备相似食材和营养的菜谱,如cooking #6推荐用户也可将“瘦肉”替换为“猪肉糜”同时添加“香菇”进行烹饪,丰富了用户的口味和食材选择。用户一方面可参考推荐菜谱的烹饪方法,另一方面可根据实际情况,参考推荐菜谱调整食材搭配。但同时实验测评也发现,在菜谱案例修正方面的局限性,仅仅针对食材而忽视了菜谱案例的其他属性也应为适应搜索条件而进行一定的修正,这也是日后需要改善的部分。

总体而言,通过实验结果可以发现,此菜谱推荐系统基本可以为用户提供相似度高、值得参考的菜谱和烹饪方法。