为什么CloudSearch不会在文件名文本字段中找到子字符串匹配？

Question

我有一个带有filename文本字段的CloudSearch域。我的问题是文本查询不会匹配（某些）文档与我认为（逻辑上）应该的文件名。如果我有这些文件名的文件：

1. '汽车'
2. 'Cars Movie.jpg'
3. '或者rs。 pdf'
4. '或者rs＃。 jpg'

我执行'汽车'的简单文本查询，我得到文件＃1，＃2和＃4，但不是＃3。如果我搜索'cars *'（或使用前缀进行结构化查询），我可以匹配＃3。这对我来说没有意义，特别是＃4匹配，但＃3没有。

Answer 1

TL; DR这是因为标记化算法处理周期的方式。

执行文本搜索时，您将对已处理的数据执行搜索，而不是对文字字段执行搜索。 （也许这应该是显而易见的，但这不是我之前的想法。）

documentation概述了文本的处理方式：

在索引期间，Amazon CloudSearch根据为该字段配置的分析方案处理文本和文本数组字段，以确定要添加到索引的条件。在应用分析选项之前，文本将被标记化并标准化。

最终导致此行为的进程部分是标记化：

在标记化期间，使用Unicode文本分段算法中定义的分词规则，将字段中的文本流拆分为可检测边界上的单独标记。

根据单词break规则，由空格分隔的字符串（如空格和制表符）将被视为单独的标记。在许多情况下，标点符号被删除并被视为空格。例如，字符串按连字符（ - ）和at符号（@）分割。但是，空格不跟随的句点被视为标记的一部分。

我之所以看到问题中描述的匹配是因为文件扩展名包含在它们之前的任何内容中作为单个标记。如果我们回顾一下这个例子，并根据这些规则建立一个索引，那么为什么搜索'cars'会返回文档＃1，＃2和＃4而不是＃3。

#    Text                Index

1    'cars'              ['cars']
2    'Cars Movie.jpg'    ['cars', 'movie.jpg']
3    'cars.pdf'.         ['cars.pdf']
4    'cars#.jpg'         ['cars', '.jpg']

Possible Solutions

看起来设置自定义分析方案似乎可以解决这个问题，但那里没有任何选项（停用词，词干，同义词）可以帮助您克服标记化问题。我认为，获得所需行为的唯一可能解决方案是在上载之前对文件名进行标记（使用自定义算法），然后将标记存储在文本数组字段中。虽然设计支持多种语言的自定义标记化算法是一个大问题。