Apache Solr 文本分析

Apache Solr 文本分析可用于消除术语之间的表面差异，从而解决更复杂的问题，并提供良好的用户体验，例如特定于语言的解析、词形还原和词性标注。我们将在后面更详细地讨论所有这些术语。 Apache Solr 具有一个广泛的框架，用于执行基本的文本分析，例如删除称为停用词的常用词和执行其他复杂的分析。为了发挥这种力量和灵活性，Solr 的文本分析框架对于新用户来说可能显得过于复杂和令人生畏。正如我们所说，Solr 使复杂的文本分析变得如此简单，但在这样做的过程中，它使简单的任务变得有些难以管理。这就是为什么 Solr 在其示例 "schema.xml" 中内置了如此多的预配置字段类型，以确保新用户在使用 Solr 时可以从文本分析开始。在学习本教程后，您将能够处理这种强大的结构，以分析我们将面临的大部分内容。

我们将演示文本分析的方法，并为我们的文件构建分析解决方案。为此，我们将解决一个复杂的文本分析问题，以获得成功所需的策略和机制。具体来说，我们将理解给定的 Solr 文本分析的基本元素

• Solr 的基本文本分析元素，包括分析器、分词器和分词过滤器链。
• 用于在索引、查询处理期间分析文本，并在 schema.xml 中定义自定义字段类型。
• 标准文本分析技术，例如小写、删除停用词、词干提取、同义词扩展和删除重音符号。

具体来说，我们将了解如何分析来自 Twitter 等网站的微博内容。 推文提出了独特的挑战，需要我们认真思考有多少用户会使用我们的搜索结果。具体来说，我们将看到如何

• 将重复字符折叠为最多两个术语 保留#hashtags 和@mentions
• 使用自定义令牌过滤器来解析缩短的 bit.ly 样式 URL

分析微博文本

让我们继续使用我们在本页介绍的示例微博搜索应用程序。在这里，我们将设计和实施解决方案，以搜索来自不同社交媒体网站（例如 Twitter、Facebook 等）的微博。由于本教程的基本重点是文本分析，让我们仔细看看示例微博文档中的文本字段。

这是我们要分析的文本

正如我们在引言中讨论的那样，文本分析的主要目标是允许您的用户使用自然语言进行搜索，而无需担心其搜索词的所有可能形式。在上图中，用户通过文本字段搜索了旧金山北滩咖啡，这对于考虑到北滩的所有很棒的咖啡馆来说是一个很自然的查询；也许我们的用户试图通过搜索社交媒体内容来找到在北滩喝咖啡的好地方。

我们声明，即使我们的示例推文中没有出现 north beach、旧金山和咖啡的确切文本匹配项，我们的示例推文也应该与此查询非常匹配。是的，我们的文件中包含 North Beach，但在搜索中区分大小写，除非您采取特定操作使您的搜索索引不区分大小写。我们断言，由于用户搜索查询中使用的术语与表中显示的文档中的术语之间的关系，我们的示例文档应该与此查询非常匹配。

基本文本分析

正如我们之前学到的，schema.xml 中的 <types> 部分为文档中的所有可能字段定义 <fieldType> 元素，其中每个 <fieldType> 定义了为查询和索引分析的字段的格式和工作方式。 该示例模式提供了适用于 Solr 广泛搜索应用程序的广泛字段类型列表。 如果任何预定义的 Solr 字段类型不符合我们的需求，我们可以借助 Solr 插件框架构建我们自己的字段类型。

假设所有字段都包含组织的数据，如时间戳和语言代码。 在这种情况下，我们可能不需要使用 Solr，因为关系数据库在结构化数据的搜索和索引编制方面是有系统的。 使用非结构化文本是 Solr 真正展示其功能的地方。 因此，示例 Solr 模式为分析文本预定义了一些强大的字段类型。 它提供了 text_general 的 XML 定义，这是更简单的字段类型之一，作为分析我们推文文本的起点。 本教程中的示例依赖于对 Solr 示例附带的 schema.xml 的一些小定制。 我们建议将 Solr 示例附带的 schema.xml 文件替换为 $SOLR_IN_ACTION/example-docs/ch6/schema.xml 中的定制版本。 具体来说，您需要通过以下方式覆盖 $SOLR_INSTALL/example/solr/collection1/conf/schema.xml

此外，您需要将 wdfftypes.txt 文件复制到 conf 目录

最后，为了从头开始（因为我们已经在前面的章节中索引了一些测试文档），您应该删除数据目录中的所有内容，以便从一个空的搜索索引开始

复制自定义 schema.xml 和 wdfftypes.txt 后，您需要从 Solr 管理控制台中的核心管理页面重新加载 collection1 核心或重新启动 Solr。

分析器

在 <fieldType> 元素内部，您应该定义至少一个 <analyzer>，它将确定如何分析文本。 在实践中，通常定义两个单独的 <analyzer> 元素：一个用于分析文本，另一个用于索引编制，用户在执行搜索操作时将输入索引编制。 "text_general" 字段使用此方法进行此操作。

花点时间思考一下为什么我们可能会使用不同的分析器进行索引和查询。您通常需要额外的分析来处理查询，而不是文档索引所需的分析。例如：同义词通常在查询文本分析期间添加，以避免仅膨胀我们的索引大小并使其更容易控制同义词。

但是，我们可以定义两个不同的分析器。应用于查询词的分析必须与索引期间分析文本的方式兼容。 考虑这样一种情况：分析器在索引时配置为太小的术语，它不会降低查询术语。 搜索 North Beach 的 Solr 用户将找不到我们的示例推文，因为索引包含“north”和“beach”的小写字母形式。

分词器

在 Solr 中，每个 <analyzer> 都将文本分析过程分为两个阶段

• 分词（解析）
• 分词过滤

还有一个允许在分词期间进行预处理的第三阶段，您可以在其中应用字符过滤器。 在分词阶段，文本将被拆分为带有解析的令牌流。 最基本的分词器是 WhitespaceTokenizer，它只能用于拆分空格处的文本。 另一个是 StandardTokenizer，它执行智能解析以在空格、标点符号上拆分术语，并正确处理 URL、首字母缩写词和电子邮件地址。 我们需要指定工厂的 Java 实现类，以便为我们的分词器定义分词器。 要使用常见的 Standard-Tokenizer，您可以指定 solr.StandardTokenizerFactory. <tokenizer class="solr.StandardTokenizerFactory"/>

在 Solr 中，我们可以指定工厂类而不是底层 Tokenizer 类（实现），因为许多分词器没有提供默认的无参数构造函数。 如果我们使用工厂方法，Solr 为我们提供了一种在 XML 中定义任何分词器的标准方法。 所有工厂类都知道翻译 XML 配置属性以创建特定 Tokenizer 实现类的实例的方法。 它们都产生一个令牌流，该令牌流可以由零个或多个过滤器处理以转换令牌。