【发布时间】:2016-11-09 23:55:00
【问题描述】:
我正在使用德语分析器来标记一些内容。我知道它基本上是“lowercase”、“german_stop”、“german_keywords”、“german_normalization”、“german_stemmer”的宏过滤器。
我的问题与规范化过滤器有关。这是过滤器的Elasticsearch Documentation 和Lucene Implementation。问题在于 ae ue 和 oe 被视为德语字母 ä,ö 和 ü,因此转换为 a,o,u。
第二个转变很好,但第一个导致的问题比它解决的要多。德语文本中通常没有真正代表ä、ü、ö的ae、ue、oe。大多数情况下,它们实际出现在外来词中,源自拉丁语或英语,例如“Aearodynamik”(空气动力学)。然后过滤器将“Ae”解释为“Ä”,然后将其转换为“A”。这会产生“arodynamik”作为令牌。通常这不是问题,因为搜索词也使用该过滤器进行了标准化。但是,如果与通配符搜索结合使用,这确实会成为一个问题:
想象一个像“FooEdit”这样的词,它会被标记为“foodit”。搜索“edit OR *edit*”(这是我在用户搜索“edit”时的正常搜索)不会产生结果,因为“edit”的“e”丢失了。因为我的内容有很多这样的词,而且人们正在搜索部分词,所以它不像看起来那么极端。
所以我的问题是有什么办法可以摆脱 'ae -> a' 转换?我的理解是这是German2 snowball algorithm 的一部分,因此可能无法更改。这是否意味着我必须摆脱整个标准化步骤,或者我可以提供我自己版本的雪球算法,我只是去掉我不喜欢的部分(没有找到任何关于如何使用自定义的文档用于标准化的雪球算法)?
干杯
汤姆
【问题讨论】:
标签: elasticsearch lucene snowball