内容


使用 IBM OmniFind、IBM Classification Module 和 SchemaLogic 在企业搜索中应用分类法

体会分类法在集成的搜索解决方案中的作用

Comments

简介

随着企业中在线文档的数量不断增加,通过分类对企业内容进行系统化的组织变得越来越重要了。而且,以前独立的系统和复杂的企业搜索系统(比如 IBM OmniFind Enterprise Edition)需要进行高级集成,从而让最终用户能够通过一个单一访问点访问来自不同来源的文档。使用企业分类法(换句话说,一套以层次化方式组织的相关目录)和文档内容分类是一种满足这种需求的强大方法。

本文带领您学习使用以下工具成功地创建和部署一个高性能的企业分类法:

  • SchemaLogic Enterprise Suite,用来管理、建模和维护一个统一的企业分类法
  • IBM Classification Module for OmniFind Discovery Edition(ICM) ,用来对文档进行自动分类
  • IBM OmniFind Enterprise Edition(后面简称为 OmniFind),用来在文档搜索中利用目录信息

本文假设您具备企业搜索系统功能的基本知识,尤其是了解 OmniFind。本文主要关注 OmniFind 如何与 SchemaLogic Suite 和 ICM 集成在一起,形成一个真正的企业搜索系统,可以利用分类法和自动分类的强大功能。

本文的结构如下:

企业分类法的用途

企业分类法是一套词汇以及它们之间存在的关联关系。它可以仅仅是一个产品列表,也可以具有复杂的结构以支持公司、他们的供应商和客户之间的关系。企业分类法用来描述企业生成的内容。通过使用这些分类法中的标准语言,企业用户和支持他们工作的软件可以按照同样的方式描述相似的内容。

企业分类法的组成部分包括:

  • 一个多用途的词汇列表,用来描述内容,常常是层次化的。
  • 用一个强壮的管理模型进行集中的管理或发布

它通常包含以下内容的组合:

  • 受控制的词汇表
  • 允许用来定义元数据字段的值
  • 首选词汇
  • 同义词、首字母缩写词和缩写词
  • 属性
  • 标准词典关系
  • 其他命名的关系

企业分类法可以提供以下好处:

  • 分类法可以跨应用程序描述内容
  • 分类法没有确定的焦点;也就是没有明确的 “视角”
  • 分类法可以用来控制元数据中的值
  • 分类法可以通过添加同义词、首字母缩写词和缩写词,改进搜索查询
  • 分类法可以帮助站点导航

最近,企业分类法还用来增强企业搜索。新的搜索技术(比如语义性和可操作的搜索)通过添加企业分类法结构中的知识而大大增强了。

典型的示例包括:

  • 多方面导航(Faceted navigation):这是一种动态界面,是搜索和分类法浏览的动态组合
  • 搜索结果聚簇(Search results clustering):将文档自动地分组进具有自然的标签的目录
  • 分类的搜索结果(Categorized search results):搜索结果分组进分类法所定义的有意义且稳定的分类
  • 可操作的搜索(Actionable search):允许用户直接在搜索结果上进行某些操作
  • 语义性搜索(Semantic search):用来自不同来源的相关数据增强搜索;这些数据通过使用企业分类法来描述

分类法管理

设计分类法的方法是:查看内容并与领域专家进行会谈,从而创建一个适当的数据模型。通常情况下,分类法专家会研究现有的数据库、Web 站点、组织图表、产品线、其他遗留数据库、词汇列表和产品文档,从而了解现有的分类。良好的具有代表性的分类系统往往是从其他系统衍生出来的。

完成了这些前期分析并确定了企业分类法的需求之后,就需要一个分类法建模系统。在 20 世纪 90 年代晚期之前,大型组织要么是构建自己的分类法管理应用程序(这些应用程序依赖于各种系统提供的建模包,比如搜索引擎或自动分类系统),要么是使用简单的桌面应用程序,比如电子表格。这两种方式都给企业带来了难题。

自产系统的开发和维护非常昂贵,尤其是在依赖于复杂且动态的大型分类法的环境中,比如驱动高质量搜索结果或高质量自动分类的分类法。因此,组织要么继续投资他们自己的系统,要么(在不太重要的环境中)转向分类法项目。

一些系统(比如搜索系统或自动分类系统)包含建模工具,构建这种工具是为了更有针对性地与系统进行交互。因此,在这些系统特定的工具中进行管理的分类法模型不容易与其他系统进行集成,往往需要进行大量的定制软件开发工作。另外,这些工具往往比较简单,无法在复杂建模、大型系统或所有权分散的情况下使用。

但是,近来组织有了另一个选择。许多软件厂商已经开发和发布了分类法建模应用程序,这些应用程序是为通用企业应用设计的,并不仅限于特定的系统。这些系统的费用和功能差异很大,从单用户桌面建模应用程序,到健壮的企业级语义管理系统。设计这些系统的目的是为了进行建模,一般来说它们比系统特定的工具更有用。这些应用程序的真正价值在于,它们提供了一个集中的建模环境,整个企业中的许多用户、用户类型和系统都可以访问模型,包括建模和使用模型。

为您的企业选择合适的系统需要根据前期分析中收集的需求,评估每种系统的特性、功能和费用。

分类法系统特性

为了决定以哪种方式管理您的分类法(构建自己的系统、购买商用系统或者使用现有系统附带的分类法包),有许多因素需要考虑。决策的主要驱动因素应该基于组织的需要,以及您打算如何管理和使用分类法。

一般需求

一般需求包括技术需求、用户和易用性需求以及分类法方面的需求,比如分类法的规模和活跃程度。其中一些关键的需求包括:

  • 活跃程度:这描述分类法的动态程度有多大。变化非常少的分类法通常只有几个编辑人员或所有者,而且模型的更新不需要立即传播给其他系统。在这种情况下,一个简单的建模应用程序可能就足够了。但是,高度动态的分类法每天甚至每小时都会发生变化,它们需要性能足够好的系统,以便支持来自多个用户或多个系统的快速模型变化。
  • 词汇表的规模和复杂性:如果分类法包含大量词汇以及词汇之间的大量关系,那么就需要建模系统能够适应分类法的增长。
  • 分类法集成:使用集中式分类法模型的系统越多,分类法的创建和维护过程就越强大,其经济价值就越大。总的来说,其他系统以两种方式之一或组合与建模系统进行交互:
    • 订阅系统:这些系统使用整个分类法或其一部分。分类法的使用情况往往受到订阅系统如何使用它以及它们能够利用什么结构的限制。这些系统位于分类法系统的接收端,它们可能使用任何内容,从简单的列表,到复杂的层次结构。
    • 发布系统:在某些环境中,其他系统可能向建模应用程序进行发布。在这种情况下,整个企业分类法的某些子集的 “分类法记录” 可能在另一个系统中进行管理。例如,产品列表可能在 ERP 系统中进行管理,但是其他系统(比如 ECM、自动分类或搜索系统)可以利用这个列表。在这种情况下,建模应用程序可能作为 “信息交换所”,它们从 ERP 系统接收产品列表,然后将所有记录或子集重新发布给不同的系统。

      在另一种情况下,另一个应用程序可能会生成应该合并进企业分类法的词汇。这种系统包括高级的自然语言处理系统,它能够通过分析内容(比如 ECM 系统中的文档文本)发现新的词汇和关系。其他示例包括从社会性卷标(Social tagging)系统生成的词汇以及从搜索分析系统生成的词汇。

    • 订阅和发布系统:在某些情况下,一个系统可以同时向分类法建模系统进行订阅和发布。一个示例是自动分类系统,它可以使用分类法进行分类,也可以发现新的词汇和关系并将其反馈给模型。迭代式的分类法维护会帮助自动分类系统逐渐变得更精确。

    活跃的企业环境可能具有多个订阅系统和发布系统,这就要求建模应用程序能够轻松且可靠地以适当的方式连接多个系统。

  • 所有权的分布情况:模型的所有权在组织中的分布情况(包括地理分布和组织性分布)将决定建模工具必须具有多大的健壮程度,才能支持不同类型的用户。这包括让用户能够轻松地连接到系统,以及尽可能减少客户端应用程序的管理工作量。
  • 用户的数量和类型:除了模型的所有者和分类法编辑人员之外,企业还可能有许多其他用户,他们可能是对使用分类法或其子集感兴趣的相关人员,也可能对分类法的开发过程做出贡献。这些用户需要以适合自己的需要和权限的方式访问和查看模型。他们可能需要在订阅系统中直接对分类法的开发过程做出贡献。例如,一位作者在 ECM 系统中给文档加注解,他可能需要建议一个新词汇,希望分类法建模工具能够将它收入某个选项列表。在理想情况下,这个过程应该无缝地集成在 ECM 的用户界面中,这样的话,用户甚至不会意识到他们正在与分类法管理系统进行交互。
  • 用户使用工具的方式:不同类型的用户会以不同的方式使用分类法建模系统。分类法编辑人员需要强大的编辑功能,以便快速轻松地修改模型。他们需要强大的搜索和浏览功能,以便快速地找到词汇和分类法分支。分类法子集的业务所有者可能只需要查看他们自己的分类法部分,不需要太强大的功能。偶尔建议新词汇的其他相关人员和用户需要的功能可能更少。
  • 易用性:建模应用程序的图形用户界面必须容易使用,其功能必须与用户的角色匹配。搜索和浏览分类法、创建、编辑和删除词汇和分支的功能必须容易使用而且直观。
  • 技术体系结构:系统必须符合企业的技术体系结构方针,比如支持的平台和数据库。另外,如果企业要开发和维护到建模系统的定制连接,系统就必须提供具有良好文档的 API 和完整的 SDK。
  • 多语种功能:许多组织需要以多种语言维护其分类法。简单的多语种环境可能需要能够在语言之间进行映射。更复杂的环境可能需要对语言之间的相互关系进行精确的建模,比如将一种语言中的一个单一复合词转换成另一种语言中的多个词汇,甚至是 Boolean 类型的陈述。
  • 可伸缩性:建模系统可能需要以许多种方式进行伸缩,比如适应词汇量的增加、用户数量的增加和服务器地理分布的变化。
  • 安全性和权限:系统的安全模型必须满足组织的需要,包括连接到企业安全系统,比如 LDAP 系统。权限模型必须提供足够的拥有、查看、编辑和协作权限级别。

建模功能

第二类需求是处理实际的逻辑建模功能,以及模型的类型和复杂性。这些考虑因素包括:

  • 词汇关系:需要判断分类法的类型和词汇关系的复杂性。这些关系的差异很大,从简单的列表(没有关系),到简单的层次结构(例如,父/子关系),到词典关系(例如符合 NISO 构造的关系;参见 参考资料),直到特殊定义的关系和本体。
  • 定义分类法的子集:根据方面、词汇关系或其他属性定义分类法的子集。在与下游系统进行集成时常常需要这种功能,这些系统可能对所需的词汇或模型的复杂性有自己的限制。
  • 系统和用户定义的属性:对分类法进行管理常常需要支持词汇的属性,比如创建或修改词汇的时间、创建词汇的人等等。建模系统本身就提供大多数这些属性。但是,有时候需要创建和管理用户定义的属性,尤其是在分类法与其他系统进行集成时。用户定义的属性就是由客户建立和配置的属性。当与其他系统进行集成时,常常必须随词汇或分类法一起发布系统特有的信息。能够在建模系统中记录、存储和管理这些信息是非常有好处的。
  • 其他建模功能:另外,还要考虑许多与建模功能有关的其他因素。这些考虑因素应该基于已知的需求,包括:
    • 多重层次:词汇可以具有多个父词汇
    • 主题映射:能够对主题映射进行建模(比如符合 ISO/IEC 13250:2003 的映射)
    • RDF:能够以符合 RDF(Resource Description Framework,World Wide Web Consortium 的一套规范)的方式对信息进行建模
    • OWL(Web Ontology Language):能够以符合 OWL 的格式呈现分类法模型(参见 参考资料

分类法部署

分类法与其他系统的集成

对分类法和分类法子集进行集成的技术方法,通常取决于分类法建模系统和目标系统的功能。

通常情况下,集成分成两个类型,并在方式上有不同的变体。按照最简单最肤浅的方式,集成可以通过对文件进行转换和传输来实现,比如 XML 文件。大多数系统现在可以以 XML 格式导出分类法,订阅系统可以以 XML 形式导入分类法。

按照最深入的方式,建模系统可以使用 API 直接连接订阅系统。在建模系统上,这允许直接向其他系统暴露建模系统的功能,包括它们的用户界面。另外,这使订阅系统能够使用建模系统中存储的模型,而不需要存储模型的另一种表示形式,比如 XML 文件或数据库结构。每当订阅系统需要分类法或其子集时,比如为了进行显示、构建搜索索引或对查询字符串进行分析,它可以对建模系统中的数据进行实时访问。这样就避免了在不同系统中存在分类法的多个版本的问题,以及版本之间不同步的问题。

使分类法与其他系统保持同步

除了最深入的 API 到 API 集成方式之外,在所有集成方式中,都必须将建模系统中的修改传播到订阅系统。同步方法通常分为以下几类:

  • 手工的:一个由用户发起的批处理过程,通常要通过用户界面或命令行界面执行
  • 调度的:根据指定的调度计划自动执行的同步
  • 事件驱动的:每当模型中发生指定的变化时自动执行的同步

SchemaLogic Enterprise Suite

企业级的分类法管理系统之一是 SchemaLogic Enterprise Suite。

SchemaLogic Enterprise Suite 的核心是 SchemaServer,这是一个中心存储库,在其中收集、创建和整理业务模型标准,并从这里将标准发布给订阅系统。这个套件能够管理语义性(包括分类法)和结构性的模型。

对于语义性模型,SchemaServer 允许组织捕获和管理标准的业务词汇、编码系统以及必须作为词汇表、词汇和关系在整个企业中一致地使用的其他语义。这种强大且灵活的系统可以对各种模型进行建模,从简单但重要的列表(比如销售区域或市场分割模型),到复杂的多方面分类法、词典或本体,可以描述具有成百上千词汇的复杂业务系统或产品和服务网络。

另外,SchemaServer 描述了结构性模型,用来以信息类的层次结构形式存储和交换信息。这种逻辑建模功能允许捕获企业中所有信息系统的一致且容易理解的模型,而且容易查看和理解它们的相互关系。关系、面向对象、XML、SOA 和其他技术模型可以统一在一个面向业务的管理模型之下,适合业务和技术参与者使用。还可以捕获语义性和结构性模型之间的关系,从而实现全面的管理和影响分析。

通过强大的 GUI 来访问 SchemaServer,用户可以快速轻松地创建和维护分类法。Workshop 是一个强大的建模应用程序,建模专家和分类法编辑人员可以使用它管理公司的分类法。它包含强大的编辑工具,可以对模型进行大规模修改或批量修改,还可以导入和导出修改。

Workshop Web 是一个零内存占用的基于浏览器的 UI,用来管理 SchemaServer 中的对象。设计它是为了供系统业务用户进行日常操作。

图 1. Workshop Web 中的地理层次结构
Workshop Web 示例
Workshop Web 示例

SchemaLogic 解决方案的核心是四个关键的功能,它们使组织能够在日常操作的环境中管理业务语义和分类法:

  1. 对结构和信息关系进行建模
  2. 控制和管理修改
  3. 向订阅系统进行发布
  4. 通过协作进行扩展和维护

这些关键功能使参与和贡献过程能够跨越组织、公司和行业边界,从而支持在不断变化的动态环境中开发业务语义。

SchemaLogic Enterprise Suite:关键特性和功能

SchemaLogic Enterprise Suite 包含分类法开发和部署项目所需的许多关键特性:

  • 容易使用:Workshop Web 强调让一般业务用户容易使用系统,这些用户通常不具备丰富的分类法开发经验,因此 Workshop Web 是高度图形化的。除了 Workshop Web 中的功能之外,Workshop 提供了更多的编辑和管理功能。
  • 导入/导出:Workshop 用户可以利用 XML 或 CSV 格式的文件执行基于文件的手工导入和导出。可以针对整个模型或任何子集执行导入和导出。还可以用 API 或者通过产品适配器执行不基于文件的导入和导出。
  • 协作:SchemaLogic Suite 包含一个可定制的约束、权限和权力管理系统,使所有用户都能够参与语义性模型的开发。
  • 权限模型:权限模型允许对系统中的任何内容应用用户角色。用户可以建议修改,但是只有当适当的所有者和相关人员批准了修改时,才会提交修改。
  • 影响分析:影响分析特性使用户能够以图形化方式查看提议的修改会影响哪些对象,以及修改影响的所有者、相关人员和订阅者。
  • 定义的关系:客户可以定义任意数量的定制词汇关系,这使组织能够对全部语义关系进行建模,包括一般列表、简单的层次结构、词典和本体。
  • 可配置的属性:客户可以为系统中的任何对象定义任意数量的定制属性。这在分类法与其他系统进行集成时很有用,因为这些系统常常需要特定的词汇属性来集成分类法。
  • SDK:SchemaLogic Suite 包含一个具有完整文档的 Web 服务 SOAP API 和 Java API,允许客户针对建模服务器编写定制的应用程序。这使建模服务器能够与现有的业务线应用程序进行集成,从而通过业务线 UI 向用户提供建模功能。
  • 集成服务和适配器:SchemaLogic Suite 包含一个内存占用很少的集成服务器,这是一个可以通过 Web 服务访问的集成体系结构框架,它使组织能够快速地构建和部署 API 到 API 适配器,从而将分类法或分类法子集发布给订阅系统。另外,SchemaLogic 为 IBM Content Management 套件和 IBM OmniFind 套件等系统提供了预制的产品适配器。

集成 SchemaLogic Suite 和 OmniFind Enterprise Edition, Version 8.4

OmniFind Enterprise Edition V8.4 提供了许多功能,组织的分类法可以利用这些功能调整和改进搜索结果。

  • 基于规则的分类法:为了简化企业搜索部署,OmniFind Enterprise Edition V8.4 提供了配置分类法目录和目录规则的功能。分类法用于两个用途。首先,在创建搜索索引时,根据文档是否满足规则,将分类法目录应用于文档。其次,在将目录应用于文档之后,可以使用分类法为集合创建浏览界面。与许多纯导航式解决方案不同,OmniFind Enterprise Edition 不需要预定义的分类法也能够提供高度相关的搜索结果。但是,它可以利用分类法标记影响搜索应用程序的结果和界面。

    通过使用 SchemaLogic Suite,组织可以将 OmniFind 特有的规则应用于现有的分类法词汇,并将这些分类法或子集发布给 OmniFind。这使组织能够在 OmniFind 中利用现有的分类法,并在统一的分类法管理系统和过程中管理 OmniFind 分类法。

  • 语言学字典:OmniFind 允许组织管理许多不同的字典来优化结果。在 SchemaLogic Suite 中,可以在组织的总体分类法中无缝地管理这些字典,并定期向 OmniFind 发布。
  • 同义词:可以使用这个字典扩展发送给搜索引擎的查询字符串中的词汇,使其包含指定的同义词。例如,可以让搜索引擎搜索常见的首字母缩写词的全拼形式。如果用户搜索 “WAS”,那么搜索引擎也会自动地返回 “WebSphere Application Server” 和其他拼写形式的结果。
  • Boost 单词:这个字典指定的词汇和短语会影响出现这些词汇的文档的排名值。这使组织能够控制搜索结果的排名,向用户提供相关性更高的文档。
  • Stop 单词:这个字典指定一系列企业特定的词汇,这些词汇会从查询字符串中删除以改进搜索结果的相关性。通常,stop 单词是非常常见的单词或短语,把它们放在查询字符串中可能会导致出现大量的不相关结果。

自动文本分类

背景

有各种构建文档分类法的方式。一些方式是基于规则的,主要由专家创建和维护。其他方式依赖于自动文本分类技术。各种文本分类方法可以生成不同类型的 “模型”,即对真实环境的统计学描述。模型可能很简单,也可能很复杂。“分类器”(也就是判断文本是否属于某一目录的软件组件)的体系结构可能很简单,也可能很复杂。往往需要在复杂模型和简单模型之间进行折中。

Bayesian 网络或神经网络等技术使用表达能力非常强的模型,力求生成无偏向的分类器来 “描述” 文档集。它们的结果往往变动很大,只有通过大量的学习集和非常静态的数据,才能使结果稳定下来。但是,在大多数真实环境中,数据库(或文档集)是小型的、异构的而且往往变化很快,在客户交互环境中更是如此。因此,数据量不足以让这些 “复杂的” 结果趋于稳定,减少变动。这常常导致 “过分合身的” 系统,这些系统在人工测试中表现得很好,但在真实环境中就不行了。

ICM RME 方式

ICM 依赖于一种专有的独特的算法(Relationship Modeling Engine,RME)在两个极端之间取得最佳的平衡。这种方式倾向于 “复杂的” 方法,比如 Bayesian 网络或神经网络。ICM RME 的高明之处不在于分类器的体系结构,而在于实时地对这些分类器进行调优和构建。

在开发 ICM RME 时,大多数算法开发工作集中在如何自动地对分类器进行创建和调优。因此,ICM RME 分类器提供很高的精确性,而且可以通过小型学习集进行归纳和学习。另外,这些分类器非常智能化,可以通过不断的学习动态地创建和调优。

ICM RME 的算法基础设施是一个独特的自学习的引擎,即使在不完善且有噪声的场景中,也能够对文本信息进行分类。它会动态地吸收新知识,而不需要对系统进行重新配置或重新训练。ICM RME 的技术与标准的分类技术不一样;它强调干净和透明。通过使用概念建模(Concept Modeling) 技术,ICM RME 提供了用单一知识库为多个应用程序服务的独特功能。这正是知识管理的最初目标 —— 将知识从人为干预较多的通道自动地 传播到自动的或无人为干预的通道。ICM RME 提供了一种成熟的技术,它可以吸收真实环境中的变化,并一直提供很好的精确性,这使它在各种真实环境和任务关键应用程序中很有价值。

ICM RME 提供的服务使应用程序能够理解文本或文本和特定对象之间的关系(例如,个性化或一般数据分类应用程序)。

通常,应用程序将原始数据发送给 ICM RME 进行分析,并期望根据数据内容获得快速且精确的响应。注意,大约一半儿的内容与消息的实际分析无关,而且消息可能包含简写(缩写)、拼写错误以及其他不完善的特征。

ICM RME 接收这个消息并分两个主要阶段处理它:多语种的自然语言处理(Natural Language Processing,NLP)阶段,以及独立于语言的统计性的概念建模(Concept Modeling)阶段。NLP 处理的第一步主要是寻找文本中包含相关数据的部分,并从文本中提取出关键的特性或语言学事件,后面的概念建模阶段将使用这些信息(进行调用的应用程序也可能直接使用这些信息)。

无论通道是什么,NLP 引擎都处理输入文本,并创建一个概念模型(Concept Model)。概念模型是一个计算机可读的数据结构,其中包含原始文本中出现的主要概念以及它们之间的一些关系。然后,将这个结构送入概念建模引擎进行模式匹配。

同样的 “单词” 在文本中可能以多种形式出现,NLP 解决了这个难题。这些变体的一部分是语态变体(例如,“go”、“goes” 和 “went” 链接到同一概念),还有一些变体是由于拼写错误造成的,或者是表达方式中自然发生的其他变体。概念可以是单词、短句子、多单词的短语、数字、日期、URL、电子邮件地址或者文档中出现的任何有意义的东西。

ICM RME 的突出特性之一是:这个系统在更高级的语义结构中寻找模式,可以利用自动收集的领域知识和语言知识,而不是直接寻找文本模式。

ICM RME 处理的结果是原始文本中隐含的一系列目录或意图。系统还可能提取某些特性或模式,并创建元数据字段(如果这样配置的话)。系统还可以标出某些目录中超过预定义阈值的所有消息以便进行特殊处理。一定要注意,确定性因子实际上是一个统计学概率的估计值,表示正确识别目录的概率。这是另一个 ICM RME 特有的特性,这使它的配置更加直观,使公司能够更好地控制应用程序执行全自动操作的方式和时机;这在大多数环境中是一项重要的需求,而在客户交互中是绝对必须的。

注意,ICM RME 在多意图环境中表现得非常好;反馈可以是一个目录列表。另外,反馈过程对于进行调用的应用程序非常简单;它只需告诉 ICM RME 哪些目录是正确的 —— 系统会完成剩下的工作。不需要在反馈中说明原因或确信的程度。ICM RME 会自动地查明为什么有这样的反馈,而且在反馈错误的情况下,它会快速地消除这个反馈的影响(也就是不学习这个反馈提供的信息)。

ICM 服务器和工具

IBM Classification Module for OmniFind Discovery Edition

IBM Classification Module for OmniFind Discovery Edition 是一个跨平台的服务器应用程序,用来编写与 Relationship Modeling Engine 进行交互的客户机应用程序。Relationship Modeling Engine 是一整套语言处理技术,其目标是对自然语言的客户交互和其他类型的日常通信进行分析、理解和分类。这种功能嵌入在 Classification Module 中,可以为应用程序提供利用 Relationship Modeling Engine 所需的所有功能。Classification Module 提供几个客户机 API 库,支持用几种编程语言快速地开发客户机应用程序,尤其是用 Java。这个系统具有易用性、易维护性、高可用性和可伸缩性。它可以在多台机器上运行,并可以通过优化对硬件和软件资源的使用,根据客户负载进行伸缩。使用 Classification Manager 应用程序对这个系统进行配置和维护。

关于 Relationship Modeling Engine(RME)

Relationship Modeling Engine 使用自然语言处理和高级的语义分析技术对文本进行分析和分类。当应用程序将输入文本发送给 Relationship Modeling Engine 进行分析时,系统识别出最可能与此文本匹配的目录。Relationship Modeling Engine 使用一个适应性的知识库 —— 一组收集的数据,用于对文本进行分析和分类。这个知识库反映了系统期望处理的文本的种类。调用 Relationship Modeling Engine 的应用程序使用目录表示文本的意图。在将文本发送给 Relationship Modeling Engine 进行匹配时,使用知识库数据选择最可能与此文本匹配的目录。在知识库能够分析文本之前,必须用足够的正确分类的样本文本对它进行训练。经过训练的知识库可以接收文本输入,并计算出文本与每个目录的相关度数值。这个过程称为匹配或分类。产生的数值称为相关度。通过向知识库提供反馈(对当前的分类进行确认或纠正),知识库的精确性可以随着时间的推移得以维持和提高。使用反馈自动地更新和改进知识库。这个自动的自调整过程称为学习。

Classification Workbench

Classification Workbench 是一个用来创建知识库(KB)的应用程序,创建的知识库可供 IBM Classification Module for OmniFind Discovery Edition(ICM)使用;它还可以分析知识库,并使用报告和图形化的诊断信息来评估知识库的精确性。可以在利用 ICM 功能的应用程序中结合使用生成的知识库。

在使用 Classification Workbench 之前,要收集预先分类的样本数据(例如文档),这些数据应该反映将用 ICM 进行分类的数据的典型情况。将这些数据导入 Classification Workbench 来创建一个文集(corpus)文件。Classification Workbench 提供了许多特性和技术,可以对文集进行调优来优化知识库的精确性。以文集作为输入,可以创建和测试知识库。然后,可以使用 Classification Workbench 报告和图形化的诊断信息来评估知识库,并通过编辑创建知识库所用的文集来改进知识库的精确性。最终产生一个适合生产使用的知识库,供基于 ICM 的应用程序使用。

ICM RME 知识库表示为节点树,每个节点包含统计学知识和规则,用来帮助系统对文本进行分类。目录是知识库中节点的名称。对知识库中的节点进行组织的最简单方式是平面知识库(flat knowledge base) 结构,这种结构将所有节点都放在同一级上。Classification Workbench 可以从已经分类的文集自动生成这样的知识库,您不需要显式地指定它的结构。在某些情况下,可能需要构建层次化知识库(hierarchical knowledge base),这种结构将节点放在层次结构的多个级别上。

ICM RME 知识库的重要优点之一是,它能够将规则(rule)统计信息(statistic) 混合在一起。这样就可以在分类过程中应用业务逻辑,业务逻辑往往是通过元数据定义的外部非统计性信息。可以使用交互式的 Classification Workbench KB Editor 轻松地构建这样的知识库。另外,还可以在外部文本格式中指定知识库结构,并导入 Classification Workbench。

图 2 演示一个层次化的知识库结构。方框表示应用于元数据的规则节点(例如,“language = French” 或 “Products = Servers”)。椭圆表示统计节点。

图 2. 知识库结构示例
知识库结构示例
知识库结构示例

使用 Classification Workbench 创建知识库的典型工作流程如下:

  1. 收集预先分类的数据,它们将构成文集的基础。
  2. 将这些数据转换为 Workbench 能够识别的格式(例如,Workbench 能够识别符合特定模式的 CSV 或 XML)。让应用程序本身直接生成 Workbench 能够识别的格式会更好。
  3. 创建知识库结构。Workbench 能够识别知识库的 XML 格式。

然后使用 Workbench:

  1. 导入数据并创建一个文集文件。
  2. 导入知识库(如果有的话)。
  3. 根据需要,对文集条目进行编辑和分类。
  4. 创建和分析知识库,并生成分析结果。
  5. 通过查看汇总报告和图表,评估知识库的精确性。评估知识库精确性的最佳方法是使用 “KB Tune-Up Wizard”。
  6. 根据需要,通过编辑文集和重新训练来改进知识库精确性。
  7. 将知识库导出到 IBM Classification Module for OmniFind Discovery Edition(ICM)服务器

对于训练任务,Classification Workbench 会报告大量信息,包括总体知识库精确性和每个目录的精确性。评估应该从确认总体知识库精确性开始,这需要生成 “KB Data Sheet”、“KB Summary” 和 “Cumulative Success” 报告。“KB Data Sheet” 报告会突出显示潜在的问题。对于总体知识库精确性评估来说,“Total cumulative success”、“Top performing categories”、“Poorest performing categories”、“Categories that may be determined by external factors” 和 “Pairs of categories with overlapping intents” 等指标非常有意义,但是它们只能提供一些信息。最终的决策要由知识库管理员做出,因为他们了解项目的数据和业务逻辑。

“Categories that may be determined by external factors” 可能表明用户应该使用元数据和规则在知识库中添加外部信息,以便引用元数据。

“Pairs of categories with overlapping intent” 可能表明应该重新定义目录,包括将 “重叠的” 目录分割为几个不重叠的目录,或者将多个目录合并成一个。这些只是提示,必须根据项目的数据和业务逻辑需要做出决策。

如果数据的性质会随时间变化,那么可以定期使用 Classification Workbench 报告工具检查知识库的精确性。如果需要的话,可以进行重新训练。

总之,IBM Classification Module for OmniFind Discovery Edition(ICM)是一种强大的工具,它使用自然语言处理和高级语义分析技术对文本进行分析和分类。ICM 使用一个适应性的知识库/分类法(KB),从而用目录表示文本的意图。在将文本发送给 ICM 进行匹配时,使用知识库数据选择最可能与此文本匹配的目录。知识库可以是层次化的,并可以将规则和统计信息组合在一起。可以使用 Classification Workbench 工具根据代表性数据轻松地创建、分析和调优知识库数据。它的报告工具非常强大,可以对数据和知识库进行编辑和调优,从而改进分类的精确性。

集成 SchemaLogic Suite 和 ICM

通过使用 SchemaLogic Suite,组织可以将现有的分类法词汇发布给 Classification Workbench,导入 Workbench 的分类法子集会变成知识库结构,由此成为分类器所使用的目录集。

因此,自动分类器会用企业特定的目录对文档或文本流进行分类,而这些目录在组织中得到的管理和维护。这就确保为自动分类提供一套一致的得到企业认可的词汇。

搜索和分类常常集成在一个系统中。由于几个原因,搜索和分类可以很好地相互配合。

首先,它们提供了相互补充的文档描述机制。搜索根据用户提供的一小组单词(比如查询 “fat”)描述文档,而分类试图根据分类法提供的一套描述词汇(例如,在主题分类法中的一个主题)描述整个文档。这意味着,如果搜索引擎向用户提供目录,用户就很容易判断哪些搜索结果是真正相关的。例如,如果用户查询 “fat(肥胖)”,一部分结果标着 “dieting(食品)” 或 “nutrition(营养学)”,而其他结果标着 “file systems(文件系统)”(因为 FAT 也是 DOS 操作系统使用的 File Allocation Table 的缩写)。用户看到这样将不同主题混合在一起的结果,就可以调整查询,只选择他们真正要寻找的结果。

其次,搜索和分类所需的数据处理(换句话说,就是获取文档、识别符号、对变体进行规范化等等)在很大程度上是相同的。因此,系统将搜索和分类集成在一起,就能够共用这些处理步骤。

搜索和分类可以以许多方式进行组合:

  • 在目录中进行搜索:可以选择一个目录,然后只在这个目录中寻找与查询匹配的文档。
  • 指定方面的搜索:按照这种方法,可以为搜索引擎指定几个不同的文档方面(也就是文档的特征),例如,“搜索近几年关于数据库的所有 PDF 文档”。这实际上是 “在目录中进行搜索” 的一种泛化形式,其中组合了多个条件,这些条件可能是分类法中的目录,也可能不是。
  • 分类浏览:Web 站点上的一部分文档或所有文档根据分类法分类显示,每个文档都归属于分类法中的一个或多个节点,用户可以通过分类目录浏览文档。
  • 对搜索结果进行分类:搜索的结果与它们所归属的目录一起显示。可以使用目录对结果集进行分组或排序。

对这三个应用程序进行集成

为了以优化的方式满足这些使用需求,组织可以将这三个应用程序的功能结合在一起:使用 SchemaLogic Suite 集中地管理企业分类法,并将适当的子集发布给 OmniFind 和 Classification Workbench。这会为自动分类和搜索提供一套一致的得到妥善管理的语义,可以显著地改进分类和搜索的结果,并确保这些系统自动地随企业分类法的变化进行更新。

下一节演示如何进行实际的集成。

如何逐步地将系统集成在一起

本节给出对这三个系统进行集成的具体步骤,其大致情况如下:

  • 使用 SchemaLogic Suite 集中地管理分类法
  • 使用 ICM 根据分类法对自动分类所用的知识库进行训练
  • 在 OmniFind 中部署分类法,它在其文档处理管道中使用一个插件连接 Classification Module 服务器,并从分类法获得它处理的每个文档的分类

这里假设采用以下软件版本:ICM Version 8.3(以前称为 “IBM Classification Module for WebSphere® Content Discovery Version 8.3)和 OmniFind Version 8.4。请注意,这里的重点在于对这三个系统进行集成的步骤,而没有提供在工具中完成这些任务的细节。

设置集成

步骤 1:创建一个要在其上进行自动分类的 OmniFind 集合

用 “rule-based categorization(基于规则的分类)” 创建一个 OmniFind 集合。配置选项 “rule-based categorization” 允许将从 ICM 获得的目录存储在 OmniFind 索引中,并允许 Search Application 浏览目录树。

步骤 2:在 OmniFind 中部署 BNSCategoryAnnotator

正如前面提到的,对 ICM 服务器和 OmniFind 进行集成需要将一个扩展模块装载进 OmniFind 中。OmniFind 的可扩展性是由 Unstructured Information Management Architecture(UIMA)提供的(更多信息参见 参考资料)。在这个体系结构中,扩展模块(换句话说,是 UIMA 插件)也称为注解器。这里使用的注解器包含在 UIMA PEAR 包 BNSCategoryAnnotator.pear 中(下载 一节中提供了一个简化版本)。图 3 说明了这种集成方式的体系结构:

图 3. BNSCategoryAnnotator 提供了 OmniFind 和 ICM 之间的桥梁
BNSCategoryAnnator 是 OmniFind 中的一个 UIMA 插件
BNSCategoryAnnator 是 OmniFind 中的一个 UIMA 插件

这个包包含一个配置文件 BNS.xml(可下载版本中的 BNSSample.xml),其中包含许多配置参数,在部署这个插件之前需要设置这些参数。表 1 列出了最重要的参数。

表 1. BNSCategoryAnnotator 配置参数
参数意义示例
ServerURLICM 服务器的 URLhttp://127.0.0.1:8081/Listener/mod_gsoap.dll
KBNameICM 中知识库的名称EnterpriseTaxonomy
DefaultBodyFieldNameICM 中要包含在文档体中的知识库字段text
MinRelevanceScore一个 0 到 1 之间的浮点数;相关度低于这个阈值的目录会被忽略0.5
MaxCategories可以分配给一个文档的最大目录数量3

我们建议使用 UIMA SDK 附带的基于 Eclipse 的 Configuration Description Editor,根据自己应用程序的需要调整这些参数(UIMA SDK User's Guide and Reference 中描述了如何安装 UIMA SDK Eclipse 工具以及如何使用这个编辑器;参见 参考资料)。至少需要根据自己的 ICM 服务器调整 ServerURL 参数,从而使注解器能够连接到 ICM 服务器。另外,在简化版本中,需要将 CategoryDirectory 参数设置为以下路径,在这个路径中包含 OmniFind 控制器节点上的 CategoryTree.xml 文件:<ES_NODE_ROOT>/master_config/<CollectionId>.parserdriver/(在作为 OmniFind 管理员登录时,将 <ES_NODE_ROOT> 替换为对应的环境变量;在集合的 General 选项卡上可以找到 <CollectionId>)。

对于 DefaultBodyFieldName 参数,可以选择某个名称,比如 “text”、“body” 或 “contents”。在 Classification Workbench 中选择包含训练数据文档文本的字段的地方,必须同样使用这个名称。最后,KBName 参数的值应该保持默认值(空字符串)。这确保分类法的根节点名称为 KBName,对于用 Workbench 开发的知识库要求这样做。

图 4. 使用 UIMA SDK 的 Component Descriptor Editor 编辑 BNS.xml 中的参数
Component Descriptor Editor 视图
Component Descriptor Editor 视图

然后,必须将 PEAR 包上传到 OmniFind 控制器节点。在 OmniFind 管理控制台上,使用 System:Parse 页面在 Edit 模式下将 PEAR 包添加为新的文本分析引擎。关于在 OmniFind 中部署和使用定制分析引擎的细节,请参考教程 “Semantic Search with UIMA and OmniFind”(developerWorks,2006 年 12 月)。

步骤 3:将定制分析引擎与 OmniFind 集合关联起来

为了让集合使用自动分类器,需要将集合与新的文本分析引擎关联起来。这个设置在集合的 Text Processing Options 页面中(在 Edit 模式下查看集合的 Parse 页面)。关于对文本处理进行配置的更多细节,请参见教程 “Semantic Search with UIMA and OmniFind”。

步骤 4:用 SchemaLogic Enterprise Suite 创建和发布分类法

根据前面描述的设置,需要将分类法发布给 ICM 和 OmniFind。向 ICM 进行发布要使用 SchemaLogic Adapter for ICM,向 OmniFind 进行发布要使用 SchemaLogic Adapter for OmniFind。通过 Workshop UI 和 Integration Service 配置和运行这些适配器。在 ICM 适配器中使用 CSV 格式向 ICM 发布分类法(子集),并向 OmniFind 直接发布同样的分类法子集。

适配器的配置需要指定:

  1. 写入 ICM 服务器所需的 CSV 文件的目录,这应该对应于 OmniFind 控制器节点的连接信息
  2. SchemaLogic 建模服务器中要发布给 ICM 和 OmniFind 的分类法或分类法子集
  3. 应该根据词汇属性或词汇关系类型排除或包含的任何词汇

图 5 演示如何配置 SchemaLogic Adapter for OmniFind:

图 5. 编辑 SchemaLogic Adapter for OmniFind 的配置设置
Adapter for OmniFind
Adapter for OmniFind

可以通过以下任何方法运行适配器:

  1. 手工过程,即管理员通过 Workshop UI 执行发布
  2. 调度的过程,即把发布过程配置为按照指定的时间间隔执行
  3. 另一个应用程序或系统对适配器进行的 Web 服务调用

在成功的发布之后,分类法以知识库形式(只有结构)提供给 ICM,并可以在 OmniFind 中以目录树的形式浏览它们。

步骤 5:在 Classification Workbench 中,以知识库结构的形式导入分类法,并训练它以便执行自动分类

使用 Import Wizard,在 what to import 中选择 Knowledge base 选项,并在 what type of knowledge base 中选择 KB configuration 选项。在下一个屏幕上提供描述知识库结构的配置文件的路径,并点击 Finish(细节请参考 Classification Workbench User's Guide 的 “Importing and Exporting a KB Structure” 一节)。

为了获得高质量的分类器,一定要为分类法中应该识别的每个目录仔细地选择足够的训练样本。训练样本应该是纯文本,是从涉及的目录的样本文档中提取出来的。

因为用于自动分类的 OmniFind/ICM 集成要求在一个(NLP Body 类型的)字段中提供所有文档文本,所以每个训练样本也应该以这种方式构成:所有文档文本都包含在一个 Body 类型的固定字段中。为了简化文档文本的提取过程,OmniFind/ICM 集成可以运行在 “训练模式” 下(在示例注解器中不包含这个模式)。这个模式简化了用 Workbench 为知识库训练收集和预处理训练数据的任务,因为可以使用 OmniFind 爬行器获取训练文档,用 OmniFind 解析器进行文档预处理和内容提取,采用的方式与在分类之前进行的文档预处理相同。

在进行训练时,将训练样本导入 Workbench 中,并确保与样本相关联的目录是正确。关于如何训练知识库的细节,请参考 Workbench 文档。

步骤 6:将分类法导出到 ICM 服务器

如果对训练后的知识库的分类质量满意了,就需要将知识库导出到 ICM 服务器。

使用 Export Wizard 在 ICM 服务器中部署知识库:在 what to export 中选择 Knowledge base,并使用知识库格式 “IBM Classification Module”。

每当在知识库结构中进行任何修改时,比如添加目录或修改名称,都需要重复这个导出步骤。当用 SchemaLogic Suite 维护分类法时,不在 Workbench 中本地执行这些修改,而是在原始分类法上进行修改,然后要将它重新导入 Workbench,再进行重新训练。

现在,OmniFind 已经准备好处理文档了。开始爬行和解析,并构建索引。示例 OmniFind Search Application 允许浏览分类法,查看与任何目录相关联的文档。还可以使用 Search and Indexing API(SIAPI)对目录进行限制,从而改进复杂的查询。注意,在这种情况下,目录约束需要指定字符串 “rulebased” 作为分类法 ID。

完成开发周期

每当修改分类法时,必须重复第 4 步(发布到 ICM 和 OmniFind)、第 5 步(导入到 Workbench 中并进行重新训练)和第 6 步(导出到 ICM 服务器)。

注意,分类法的修改会使 OmniFind 以前所做的任何文档分类失效。因此,每当更新分类法时,OmniFind 索引中存储的文档目录可能不再正确,可能需要重新处理文档(换句话说,要重新爬行、重新解析和重新编制索引)。

结束语

本文希望能够促进在企业搜索应用程序中使用

  1. 集中维护和整理的分类法以及
  2. 自动文本分类

文中演示了如何将 OmniFind、SchemaLogic Suite 和 IBM Classification Module for OmniFind Discovery Edition 集成在一起来实现这两个目标。这种集成利用了 OmniFind 中内置的插件体系结构 UIMA(本文后面提供了所需插件的示例代码)。


下载资源


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=247831
ArticleTitle=使用 IBM OmniFind、IBM Classification Module 和 SchemaLogic 在企业搜索中应用分类法
publish-date=08132007