作者：来自 Elastic Peter Straßer
复合词在文本分析和标记过程中给搜索引擎带来挑战，因为它们会掩盖词语成分之间的有意义的联系。连字分解器标记过滤器等工具可以通过解构复合词来帮助解决这些问题。
德语以其长复合词而闻名：Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz 是德语词典中最长的单词 —— 对于没有准备好处理复合词的搜索引擎来说是一场噩梦。许多其他语言如荷兰语、瑞典语等也都有这个概念。甚至英语中也有一些这样的词语，尽管程度较轻。想想 “sunflower” 或 “basketball”。
让我们讨论一下这些词语所带来的问题和挑战，为什么这是一个问题以及如何解决它。
问题
在进行全文搜索时，Elasticsearch 等搜索引擎会在查询和索引时分析文本并将文本转换为标记（tokens）。我们想要提取单词的含义，而不是完全匹配字符串。对于我们的搜索，我们不必担心兔子是在 “running” 还是在 “runs” —— 我们只是将单词简化为其词根形式：“run”。
当我们处理复合词时，如果我们不以某种方式解决它，这个阶段就会失败。假设我们有一个包含文档的索引：“Basketballs”。如果我们使用标准英语分析器来分析这一点，我们会得到：
1. GET _analyze
2. {
3. "text": "Basketballs",
4. "analyzer": "english"
5. }
响应：
1. {
2. "tokens": [
3. {
4. "token": "basketbal",
5. "start_offset": 0,
6. "end_offset": 11,
7. "type": "<ALPHANUM>",
8. "position": 0
9. }
10. ]
11. }
在这个例子中，复合词 “basketballs” 被标记化为 “basketbal”。虽然我们能够将其转换为小写并去除复数形式，但我们无法捕捉到 “basketball” 也是一种 “ball” 的含义。现在，如果我们在索引中搜索 “ball”，我们希望能够找到 “basketball”，但 “bal”（经过分析）并不匹配 “basketbal”，因此我们没有得到任何结果！
那么，我们该如何解决这个问题呢？
也许同义词有用？
我们首先想到的可能是尝试使用同义词将不同的子词与复合词关联起来。由于复合词的使用相当有限，这对于英语来说已经足够好了：
basketball => basketball, ball
现在我们来看看德语。语法的工作方式是将任意数量的单词组合起来形成一个更精确的单词。
Rind (cow - 牛) 和 Fleisch (meat - 肉) 变成 Rindfleisch (牛肉)。
Rind（cow - 牛）、Fleisch（meat - 肉）和 Etikett（label - 标签）变成 Rindfleischetikett（牛肉标签）。这个过程可以任意长，直到我们得到诸如 Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz 之类的可爱的词语。
为了用我们的同义词文件解决这个问题，我们必须对无限数量的单词排列进行建模：
1. # cowmeat, cowmeatlabel, meatlabel
2. rindfleisch => rindfleisch, rind, fleisch
3. rindfleischetikett => rindfleischetikett, rind, fleisch, etikett
4. fleischetikett => fleischetikett, fleisch, etikett
5. …
在德语等语言中，这很快变得不切实际。所以我们必须从相反的角度来看待这个问题。我们不是从复合词开始寻找其复合词，而是查看可用的复合部分并根据这些知识解构单词。
连字分解器 - Hyphenation Decompounder
连字分解器标记过滤器（Hyphenation Decompounder Token Filter）是一个 Lucene 标记过滤器，它依赖连字规则来检测潜在的单词拆分。规则文件（Rule files）以对象格式化对象 (Objects For Formatting - OFFO) 格式指定，我们也可以在其中找到一些示例文件。我们还需要一个单词列表，用于将复合词分解为其子部分。单词列表可以内联提供，但对于生产工作负载，我们通常还会将文件上传到磁盘，因为这些文件可能非常大，并且通常包含整个词典。
可以根据其许可证提供的德语示例文件可在此存储库中找到。
那么它有什么作用呢？
1. # word list: coffee, sugar, cup
2. # text: coffee cup
3. GET _analyze
4. {
5. "tokenizer": "standard",
6. "filter": [
7. "lowercase",
8. {
9. "type": "hyphenation_decompounder",
10. "hyphenation_patterns_path": "analysis/hyphenation_patterns.xml",
12. "word_list": ["kaffee", "zucker", "tasse"]
13. }
14. ],
15. "text": "Kaffeetasse"
16. }
19. Response:
21. # coffee cup, coffee, cup
22. [ "kaffeetasse", "kaffee", "tasse"]
这有助于确保搜索 “Tasse”（杯子）的用户能够找到包含较大复合词 “Kaffeetasse”（咖啡杯）的文档。
注意：
- 查看此文章，了解如何上传包以便能够在 Elastic Cloud Hosted 部署中访问这些文件。
- 还有 Dictionary Decompounder，它可以在没有连字规则的情况下执行相同的操作，而是强制执行单词检测。对于大多数用例，我们推荐使用连字分解器。
避免部分匹配
由于我们通常使用包含数千个单词的整本词典的单词列表，因此分解器可能会使用默认设置以非预期的方式拆分单词，从而导致不相关的匹配。
1. # word list: coffee, fairy, cup
2. # text: coffee cup
3. GET _analyze
4. {
5. "tokenizer": "standard",
6. "filter": [
7. "lowercase",
8. {
9. "type": "hyphenation_decompounder",
10. "hyphenation_patterns_path": "analysis/hyphenation_patterns.xml",
12. "word_list": ["kaffee", "fee", "tasse"]
13. }
14. ],
15. "text": "Kaffeetasse"
16. }
18. Response:
20. # coffee cup, coffee, fairy, cup
21. ["kaffeetasse", "kaffee", "fee", "tasse"]
此示例在 “Kaffee”（coffee - 咖啡）中检测到 “fee”（fairy - 仙女）。这当然是意外的，并非有意为之。另一个示例可能是 “Streifenbluse”（striped blouse- 条纹衬衫），其中会找到 “Reifen”（tires - 轮胎）。“Streifen”（stripe - 条纹）、“Reifen”（轮胎）和 “Bluse”（blouse - 衬衫）都是我们通常想要拆分的常用词。
我们的用户搜索 “fee”（fairies - 仙女）和 “reifen”（tires - 轮胎）时，现在会找到 coffee 和 blouses！这可不妙。
在 8.17 中，hyphenation_decompounder 中添加了一个新的参数 no_sub_matches 来解决此问题。
1. # word list: coffee, fairy, cup
2. # text: coffee cup
3. GET _analyze
4. {
5. "tokenizer": "standard",
6. "filter": [
7. "lowercase",
8. {
9. "type": "hyphenation_decompounder",
10. "hyphenation_patterns_path": "analysis/hyphenation_patterns.xml",
11. "word_list": ["kaffee", "fee", "tasse"],
12. "no_sub_matches": true
13. }
14. ],
15. "text": "Kaffeetasse"
16. }
18. Response:
20. # coffee cup, coffee, cup
21. ["kaffeetasse", "kaffee", "tasse"]
这可以防止创建 “fee”（fairy）标记并且我们的搜索按预期工作！
匹配所有查询 terms
根据我们目前所见，搜索德语文本的索引映射可能类似于以下索引定义：
1. PUT products
2. {
3. "mappings": {
4. "properties": {
5. "full_text": {
6. "type": "text",
7. "analyzer": "german_analyzer_with_decompounding"
8. }
9. }
10. },
11. "settings": {
12. "analysis": {
13. "analyzer": {
14. "german_analyzer_with_decompounding": {
15. "type": "custom",
16. "tokenizer": "standard",
17. "filter": [
18. "lowercase",
19. "german_stop_words_filter",
20. "german_decompounder",
21. "german_normalization",
22. "german_stemmer"
23. ]
24. },
25. "german_analyzer_without_decompounding": {
26. "type": "custom",
27. "tokenizer": "standard",
28. "filter": [
29. "lowercase",
30. "german_stop_words_filter",
31. "german_normalization",
32. "german_stemmer"
33. ]
34. }
35. },
36. "filter": {
37. "german_stop_words_filter": {
38. "type": "stop",
39. "stopwords": "_german_"
40. },
41. "german_decompounder": {
42. "only_longest_match": "true",
43. "word_list_path": "dictionary/dictionary.txt",
44. "type": "hyphenation_decompounder",
45. "hyphenation_patterns_path": "dictionary/hyphenation_patterns.xml"
46. },
47. "german_stemmer": {
48. "type": "stemmer",
49. "language": "light_german"
50. }
51. }
52. }
53. }
54. }
注意：在实际生产环境中，其中很可能会有围绕 asciifolding、表情符号过滤器（emoji filters）或同义词（synonyms）的过滤器，但这已经是一个很好的起点，应该会为德语文本获得良好的结果。
当搜索多个术语时，我们通常会期望（不考虑高级查询放松策略）我们指定的所有搜索词都包含在我们的结果中。因此，当在电子商务商店中搜索 Lederjacke（leather jacket - 皮夹克）时，我们希望我们的产品是皮革制成的夹克，而不是皮革制品和夹克的随机组合。
实现此目的的方法是将搜索查询中的运算符设置为 AND。所以我们这样做并在我们的产品中搜索 “Lederjacke”（皮夹克）：
1. GET products/_search
2. {
3. "query": {
4. "match": {
5. "full_text": {
6. "query": "lederjacke",
7. "operator": "and"
8. }
9. }
10. }
11. }
12. # returns all leather products and all jackets
令人惊讶的是，这并不像我们预期的那样。我们找到了所有含有皮革或夹克的产品。这是因为运算符在标记化之前进行评估，并且使用 OR 评估标记过滤器生成的标记。
为了解决这个问题，我们需要在应用程序中分解我们的术语。我们可以先调用 _analyze API，然后将分解后的术语传递给我们的搜索查询。因为我们已经分解了，所以我们在过滤器链中使用了没有分解器过滤器的搜索分析器（search analyzer）。
1. GET _analyze
2. {
3. "tokenizer": "standard",
4. "filter": [
5. "lowercase",
6. {
7. "type": "hyphenation_decompounder",
8. "hyphenation_patterns_path": "analysis/hyphenation_patterns.xml",
9. "word_list_path": "analysis/word_list.xml",
10. "no_sub_matches": true
11. }
12. ],
13. "text": "Lederjacke"
14. }
17. Response:
19. ["leder", "jacke"]
21. GET products/_search
22. {
23. "query": {
24. "match": {
25. "full_text": {
26. "query": "leder jacke",
27. "operator": "and",
28. "analyzer": "german_analyzer_without_decompounding"
29. }
30. }
31. }
32. }
33. # returns only leather jackets
搜索分解词的替代方法
虽然 Elasticsearch Serverless 具有根据负载动态扩展的能力，为搜索应用程序带来了许多巨大优势，但在撰写本文时，目前无法上传文件并在这些项目中使用连字分解器。
替代工具
可以在 Elastic 堆栈之外使用的替代方案是适用于 Java 的 JWordSplitter 和 CharSplit 模型或 CompoundPiece 模型，它们采用机器学习方法分解单词，而无需配置文件。
以下是如何将 CompoundPiece 与 Hugging Face 转换器库一起使用：
1. from transformers import pipeline
2. pipe = pipeline("text2text-generation", model="benjamin/compoundpiece")
3. result = pipe("Lederjacke", max_length=100)
4. print(result[0]['generated_text'].split('-'))
6. STDOUT: ['Leder', 'Jacke']
它支持 56 种语言，并且无需配置文件即可工作，这是实现多语言应用程序分解的好方法。
语义搜索
我们在这里的许多文章中都涵盖了使用文本嵌入模型的语义搜索。这些模型能够解释文本的含义，可以通过将文档和查询转换为向量并找到与查询最接近的文档来进行搜索。
将此处讨论的词汇搜索与向量搜索相结合称为混合搜索。这也有助于大大提高结果的质量并解释文本中复合词背后的含义。
结论
分解是构建有效的多语言搜索应用程序的重要工具 - 尤其是涉及德语等语言时。通过使用连字符分解器等工具，我们可以确保我们的搜索能够理解复合词背后的含义，为用户提供更好、更相关的结果。
与对搜索算法的任何调整一样，评估其对搜索性能的整体影响非常重要。通过浏览我们关于 _eval API 的文章，了解有关如何客观衡量搜索结果质量的更多信息。
Elasticsearch 包含许多新功能，可帮助你为你的用例构建最佳搜索解决方案。深入了解我们的示例笔记本以了解更多信息，开始免费云试用，或立即在本地机器上试用 Elastic。
原文：How to search languages with compound words - Elasticsearch Labs
