大多數(shù)語言的單詞都可以 詞形變化 ，意味著下列單詞可以改變它們的形態(tài)用來表達(dá)不同的意思：

• 單復(fù)數(shù)變化 ： fox 、foxes
• 時(shí)態(tài)變化 ： pay 、 paid 、 paying
• 性別變化 ： waiter 、 waitress
• 動(dòng)詞人稱變化 ： hear 、 hears
• 代詞變化 ： I 、 me 、 my
• 不規(guī)則變化 ： ate 、 eaten
• 情景變化 ： so be it 、 were it so

雖然詞形變化有助于表達(dá)，但它干擾了檢索，一個(gè)單一的詞根 詞義 （或意義）可能被很多不同的字母序列表達(dá)。 英語是一種弱詞形變化語言（你可以忽略詞形變化并且能得到合理的搜索結(jié)果），但是一些其他語言是高度詞形變化的并且需要額外的工作來保證高質(zhì)量的搜索結(jié)果。

詞干提取 試圖移除單詞的變化形式之間的差別，從而達(dá)到將每個(gè)詞都提取為它的詞根形式。 例如 foxes 可能被提取為詞根 fox ，移除單數(shù)和復(fù)數(shù)之間的區(qū)別跟我們移除大小寫之間的區(qū)別的方式是一樣的。

單詞的詞根形式甚至有可能不是一個(gè)真的單詞，單詞 jumping 和 jumpiness 或許都會(huì)被提取詞干為 jumpi 。 這并沒有什么問題—?只要在索引時(shí)和搜索時(shí)產(chǎn)生相同的詞項(xiàng)，搜索會(huì)正常的工作。

如果詞干提取很容易的話，那只要一個(gè)插件就夠了。不幸的是，詞干提取是一種遭受兩種困擾的模糊的技術(shù)：詞干弱提取和詞干過度提取。

詞干弱提取 就是無法將同樣意思的單詞縮減為同一個(gè)詞根。例如， jumped 和 jumps 可能被提取為 jump ， 但是 jumping 可能被提取為 jumpi 。弱詞干提取會(huì)導(dǎo)致搜索時(shí)無法返回相關(guān)文檔。

詞干過度提取 就是無法將不同含義的單詞分開。例如， general 和 generate 可能都被提取為 gener 。 詞干過度提取會(huì)降低精準(zhǔn)度：不相干的文檔會(huì)在不需要他們返回的時(shí)候返回。

詞形還原
原詞是一組相關(guān)詞的規(guī)范形式，或詞典形式?—?paying 、 paid 和 pays 的原詞是 pay 。 通常原詞很像與其相關(guān)的詞，但有時(shí)也不像?—?is 、 was 、 am 和 being 的原詞是 be 。
詞形還原，很像詞干提取，試圖歸類相關(guān)單詞，但是它比詞干提取先進(jìn)一步的是它企圖按單詞的 詞義 ，或意義歸類。 同樣的單詞可能表現(xiàn)出兩種意思—例如， wake 可以表現(xiàn)為 to wake up 或 a funeral 。然而詞形還原試圖區(qū)分兩個(gè)詞的詞義，詞干提取卻會(huì)將其混為一談。
詞形還原是一種更復(fù)雜和高資源消耗的過程，它需要理解單詞出現(xiàn)的上下文來決定詞的意思。實(shí)踐中，詞干提取似乎比詞形還原更高效，且代價(jià)更低。

首先我們會(huì)討論下兩個(gè) Elasticsearch 使用的經(jīng)典詞干提取器 — 詞干提取算法 和 字典詞干提取器 — 并且在 選擇一個(gè)詞干提取器 討論了怎么根據(jù)你的需要選擇合適的詞干提取器。 最后將在 控制詞干提取 和 原形詞干提取 中討論如何裁剪詞干提取。

詞干提取算法

Elasticsearch 中的大部分 stemmers （詞干提取器）是基于算法的，它們提供了一系列規(guī)則用于將一個(gè)詞提取為它的詞根形式，例如剝離復(fù)數(shù)詞末尾的 s 或 es 。提取單詞詞干時(shí)并不需要知道該詞的任何信息。

這些基于算法的 stemmers 優(yōu)點(diǎn)是：可以作為插件使用，速度快，占用內(nèi)存少，有規(guī)律的單詞處理效果好。缺點(diǎn)是：沒規(guī)律的單詞例如 be 、 are 、和 am ，或 mice 和 mouse 效果不好。

最早的一個(gè)基于算法的英文詞干提取器是 Porter stemmer ，該英文詞干提取器現(xiàn)在依然推薦使用。 Martin Porter 后來為了開發(fā)詞干提取算法創(chuàng)建了 Snowball language 網(wǎng)站， 很多 Elasticsearch 中使用的詞干提取器就是用 Snowball 語言寫的。

使用基于算法的詞干提取器

你可以使用 ?porter_stem? 詞干提取器或直接使用 kstem 分詞過濾器，或使用 snowball 分詞過濾器創(chuàng)建一個(gè)具體語言的 Snowball 詞干提取器。所有基于算法的詞干提取器都暴露了用來接受 語言 參數(shù)的統(tǒng)一接口： stemmer token filter 。

例如，假設(shè)你發(fā)現(xiàn) 英語 分析器使用的默認(rèn)詞干提取器太激進(jìn)并且你想使它不那么激進(jìn)。首先應(yīng)在 language analyzers 查看 英語 分析器配置文件，配置文件展示如下：

PUT /my_index
{
  "settings": {
    "analysis": {
      "filter": {
        "english_stop": {
          "type":       "stop",
          "stopwords":  "_english_"
        },
        "english_keywords": {
          "type":       "keyword_marker", 
          "keywords":   []
        },
        "english_stemmer": {
          "type":       "stemmer",
          "language":   "english" 
        },
        "english_possessive_stemmer": {
          "type":       "stemmer",
          "language":   "possessive_english" 
        }
      },
      "analyzer": {
        "english": {
          "tokenizer":  "standard",
          "filter": [
            "english_possessive_stemmer",
            "lowercase",
            "english_stop",
            "english_keywords",
            "english_stemmer"
          ]
        }
      }
    }
  }
}

• keyword_marker 分詞過濾器列出那些不用被詞干提取的單詞。這個(gè)過濾器默認(rèn)情況下是一個(gè)空的列表。
• english 分析器使用了兩個(gè)詞干提取器： possessive_english 詞干提取器和 english 詞干提取器。 所有格詞干提取器會(huì)在任何詞傳遞到 english_stop 、 english_keywords 和 english_stemmer 之前去除 's 。

重新審視下現(xiàn)在的配置，添加上以下修改，我們可以把這份配置當(dāng)作新分析器的基本配置：

• 修改 english_stemmer ，將 english （?porter_stem? 分詞過濾器的映射）替換為 light_english （非激進(jìn)的 kstem 分詞過濾器的映射）。
• 添加 asciifolding 分詞過濾器用以移除外語的附加符號(hào)。
• 移除 keyword_marker 分詞過濾器，因?yàn)槲覀儾恍枰＃ㄎ覀儠?huì)在 控制詞干提取 中詳細(xì)討論它）

新定義的分析器會(huì)像下面這樣:

PUT /my_index
{
  "settings": {
    "analysis": {
      "filter": {
        "english_stop": {
          "type":       "stop",
          "stopwords":  "_english_"
        },
        "light_english_stemmer": {
          "type":       "stemmer",
          "language":   "light_english" 
        },
        "english_possessive_stemmer": {
          "type":       "stemmer",
          "language":   "possessive_english"
        }
      },
      "analyzer": {
        "english": {
          "tokenizer":  "standard",
          "filter": [
            "english_possessive_stemmer",
            "lowercase",
            "english_stop",
            "light_english_stemmer", 
            "asciifolding" 
          ]
        }
      }
    }
  }
}

• 將 english 詞干提取器替換為非激進(jìn)的 light_english 詞干提取器
• 添加 asciifolding 分詞過濾器
• filter stop
• filter stemmer
• filter asciifolding
• tokenizer standard

english_stemmer： 這是英語詞干分析器，它用于將英文單詞轉(zhuǎn)換為它們的詞干形式。詞干是單詞的基本形式，通常是其詞根形式，可以用于搜索和匹配。例如，將“running”、“runs”、“ran”等單詞轉(zhuǎn)換為其基本形式“run”。

english_possessive_stemmer： 這是英語所有格詞干分析器，它與英語詞干分析器類似，但專門用于處理所有格形式的單詞。在英語中，所有格形式通常以撇號(hào) 's 結(jié)尾，例如“John’s car”。該分詞器會(huì)去除所有格形式中的 's。例如，“John’s”會(huì)轉(zhuǎn)換為“John”。

因此，主要區(qū)別在于英語所有格詞干分析器會(huì)去除所有格形式中的 's，而普通英語詞干分析器不會(huì)。

GET _analyze
{
  "tokenizer": "standard",
  "filter": [
    {
      "type": "stemmer",
      "language": "english"
    }
  ],
  "text": "the John's foxes jumping Quickly"
}

GET _analyze
{
  "tokenizer": "standard",
  "filter": [
    {
      "type": "stemmer",
      "language": "possessive_english"
    }
  ],
  "text": "the John's foxes jumping Quickly"
}

結(jié)果分別是

the John' fox jump Quickli
the John foxes jumping Quickly

字典詞干提取器

字典詞干提取器 在工作機(jī)制上與 算法化詞干提取器 完全不同。 不同于應(yīng)用一系列標(biāo)準(zhǔn)規(guī)則到每個(gè)詞上，字典詞干提取器只是簡單地在字典里查找詞。理論上可以給出比算法化詞干提取器更好的結(jié)果。一個(gè)字典詞干提取器應(yīng)當(dāng)可以：

返回不規(guī)則形式如 feet 和 mice 的正確詞干
區(qū)分出詞形相似但詞義不同的情形，比如 organ and organization
實(shí)踐中一個(gè)好的算法化詞干提取器一般優(yōu)于一個(gè)字典詞干提取器。應(yīng)該有以下兩大原因：

字典質(zhì)量
一個(gè)字典詞干提取器再好也就跟它的字典一樣。 據(jù)牛津英語字典網(wǎng)站估計(jì)，英語包含大約75萬個(gè)單詞（包含變音變形詞）。電腦上的大部分英語字典只包含其中的 10% 。

詞的含義隨時(shí)光變遷。mobility 提取詞干 mobil 先前可能講得通，但現(xiàn)在合并進(jìn)了手機(jī)可移動(dòng)性的含義。字典需要保持最新，這是一項(xiàng)很耗時(shí)的任務(wù)。通常等到一個(gè)字典變得好用后，其中的部分內(nèi)容已經(jīng)過時(shí)。

字典詞干提取器對(duì)于字典中不存在的詞無能為力。而一個(gè)基于算法的詞干提取器，則會(huì)繼續(xù)應(yīng)用之前的相同規(guī)則，結(jié)果可能正確或錯(cuò)誤。

大小與性能
字典詞干提取器需要加載所有詞匯、 所有前綴，以及所有后綴到內(nèi)存中。這會(huì)顯著地消耗內(nèi)存。找到一個(gè)詞的正確詞干，一般比算法化詞干提取器的相同過程更加復(fù)雜。

依賴于不同的字典質(zhì)量，去除前后綴的過程可能會(huì)更加高效或低效。低效的情形可能會(huì)明顯地拖慢整個(gè)詞干提取過程。

另一方面，算法化詞干提取器通常更簡單、輕量和快速。

Hunspell 詞干提取器

Elasticsearch 提供了基于詞典提取詞干的 hunspell 語匯單元過濾器（token filter）. Hunspell hunspell.github.io 是一個(gè) Open Office、LibreOffice、Chrome、Firefox、Thunderbird 等眾多其它開源項(xiàng)目都在使用的拼寫檢查器。

可以從這里獲取 Hunspell 詞典 ：

• extensions.openoffice.org: 下載解壓 .oxt 后綴的文件。
• addons.mozilla.org: 下載解壓 .xpi 擴(kuò)展文件。
• OpenOffice archive: 下載解壓 .zip 文件。

一個(gè) Hunspell 詞典由兩個(gè)文件組成?—?具有相同的文件名和兩個(gè)不同的后綴?—?如 en_US—和下面的兩個(gè)后綴的其中一個(gè)：

.dic
包含所有詞根，采用字母順序，再加上一個(gè)代表所有可能前綴和后綴的代碼表 【集體稱之為詞綴( affixes 】
.aff
包含實(shí)際 .dic 文件每一行代碼表對(duì)應(yīng)的前綴和后綴轉(zhuǎn)換

安裝一個(gè)詞典

Hunspell 語匯單元過濾器在特定的 Hunspell 目錄里尋找詞典， 默認(rèn)目錄是 ./config/hunspell/ 。 .dic 文件和 .aff 文件應(yīng)該要以子目錄且按語言/區(qū)域的方式來命名。 例如，我們可以為美式英語創(chuàng)建一個(gè) Hunspell 詞干提取器，目錄結(jié)構(gòu)如下：

config/
  └ hunspell/ 
      └ en_US/ 
          ├ en_US.dic
          ├ en_US.aff
          └ settings.yml 

• Hunspell 目錄位置可以通過編輯 config/elasticsearch.yml 文件的： indices.analysis.hunspell.dictionary.location 設(shè)置來修改。
• en_US 是這個(gè)區(qū)域的名字，也是我們傳給 hunspell 語匯單元過濾器參數(shù) language 值。
• 一個(gè)語言一個(gè)設(shè)置文件，下面的章節(jié)會(huì)具體介紹。

按語言設(shè)置

在語言的目錄設(shè)置文件 settings.yml 包含適用于所有字典內(nèi)的語言目錄的設(shè)置選項(xiàng)。

---
ignore_case:          true
strict_affix_parsing: true

這些選項(xiàng)的意思如下：
ignore_case
Hunspell 目錄默認(rèn)是區(qū)分大小寫的，如，姓氏 Booker 和名詞 booker 是不同的詞，所以應(yīng)該分別進(jìn)行詞干提取。 也許讓 hunspell 提取器區(qū)分大小寫是一個(gè)好主意，不過也可能讓事情變得復(fù)雜：

• 一個(gè)句子的第一個(gè)詞可能會(huì)被大寫，因此感覺上會(huì)像是一個(gè)名詞。
• 輸入的文本可能全是大寫，如果這樣那幾乎一個(gè)詞都找不到。
• 用戶也許會(huì)用小寫來搜索名字，在這種情況下，大寫開頭的詞將找不到。

一般來說，設(shè)置參數(shù) ignore_case 為 true 是一個(gè)好主意。

strict_affix_parsing
詞典的質(zhì)量千差萬別。 一些網(wǎng)上的詞典的 .aff 文件有很多畸形的規(guī)則。 默認(rèn)情況下，如果 Lucene 不能正常解析一個(gè)詞綴(affix)規(guī)則， 它會(huì)拋出一個(gè)異常。 你可以通過設(shè)置 strict_affix_parsing 為 false 來告訴 Lucene 忽略錯(cuò)誤的規(guī)則。

自定義詞典
如果一個(gè)目錄放置了多個(gè)詞典 (.dic 文件)， 他們會(huì)在加載時(shí)合并到一起。這可以讓你以自定義的詞典的方式對(duì)下載的詞典進(jìn)行定制：

config/
  └ hunspell/
      └ en_US/  
          ├ en_US.dic
          ├ en_US.aff 
          ├ custom.dic
          └ settings.yml

• custom 詞典和 en_US 詞典將合并到一起。
• 多個(gè) .aff 文件是不允許的，因?yàn)闀?huì)產(chǎn)生規(guī)則沖突。

.dic 文件和 .aff 文件的格式在這里討論： Hunspell 詞典格式 。

創(chuàng)建一個(gè) Hunspell 語匯單元過濾器

一旦你在所有節(jié)點(diǎn)上安裝好了詞典，你就能像這樣定義一個(gè) hunspell 語匯單元過濾器：

PUT /my_index
{
  "settings": {
    "analysis": {
      "filter": {
        "en_US": {
          "type":     "hunspell",
          "language": "en_US" 
        }
      },
      "analyzer": {
        "en_US": {
          "tokenizer":  "standard",
          "filter":   [ "lowercase", "en_US" ]
        }
      }
    }
  }
}

• 參數(shù) language 和目錄下對(duì)應(yīng)的名稱相同。

你可以通過 analyze API 來測試這個(gè)新的分析器， 然后和 english 分析器比較一下它們的輸出：

GET /my_index/_analyze?analyzer=en_US 
reorganizes

GET /_analyze?analyzer=english 
reorganizes

• 返回 organize
• 返回 reorgan

在前面的例子中，hunspell 提取器有一個(gè)有意思的事情，它不僅能移除前綴還能移除后綴。大多數(shù)算法詞干提取僅能移除后綴。

Hunspell 詞典會(huì)占用幾兆的內(nèi)存。幸運(yùn)的是，Elasticsearch 每個(gè)節(jié)點(diǎn)只會(huì)創(chuàng)建一個(gè)詞典的單例。 所有的分片都會(huì)使用這個(gè)相同的 Hunspell 分析器。

Hunspell 詞典格式

略

選擇一個(gè)詞干提取器

在文檔 stemmer token filter 里面列出了一些針對(duì)語言的若干詞干提取器。 就英語來說我們有如下提取器：

english
porter_stem? 語匯單元過濾器（token filter）。
light_english
kstem 語匯單元過濾器（token filter）。
minimal_english
Lucene 里面的 EnglishMinimalStemmer ，用來移除復(fù)數(shù)。
lovins
基于 Snowball 的 Lovins 提取器, 第一個(gè)詞干提取器。
porter
基于 Snowball 的 Porter 提取器。
porter2
基于 Snowball 的 Porter2 提取器。
possessive_english
Lucene 里面的 EnglishPossessiveFilter ，移除 's
Hunspell 詞干提取器也要納入到上面的列表中，還有多種英文的詞典可用。

有一點(diǎn)是可以肯定的：當(dāng)一個(gè)問題存在多個(gè)解決方案的時(shí)候，這意味著沒有一個(gè)解決方案充分解決這個(gè)問題。 這一點(diǎn)同樣體現(xiàn)在詞干提取上?—?每個(gè)提取器使用不同的方法不同程度的對(duì)單詞進(jìn)行了弱提取或是過度提取。

在 stemmer 文檔 中，使用粗體高亮了每一個(gè)語言的推薦的詞干提取器， 通常是因?yàn)樗峁┝艘粋€(gè)在性能和質(zhì)量之間合理的妥協(xié)。也就是說，推薦的詞干提取器也許不適用所有場景。 關(guān)于哪個(gè)是最好的詞干提取器，不存在一個(gè)唯一的正確答案?—?它要看你具體的需求。 這里有3個(gè)方面的因素需要考慮在內(nèi)： 性能、質(zhì)量、程度。

提取性能

算法提取器一般來說比 Hunspell 提取器快4到5倍。 “Handcrafted” 算法提取器通常（不是永遠(yuǎn)） 要比 Snowball 快或是差不多。 比如，porter_stem 語匯單元過濾器（token filter）就明顯要比基于 Snowball 實(shí)現(xiàn)的 Porter 提取器要快的多。

Hunspell 提取器需要加載所有的詞典、前綴和后綴表到內(nèi)存，可能需要消耗幾兆的內(nèi)存。而算法提取器，由一點(diǎn)點(diǎn)代碼組成，只需要使用很少內(nèi)存。

提取質(zhì)量

所有的語言，除了世界語（Esperanto）都是不規(guī)范的。 最日常用語使用的詞往往不規(guī)則，而更正式的書面用語則往往遵循規(guī)律。 一些提取算法經(jīng)過多年的開發(fā)和研究已經(jīng)能夠產(chǎn)生合理的高質(zhì)量的結(jié)果了，其他人只需快速組裝做很少的研究就能解決大部分的問題了。

雖然 Hunspell 提供了精確地處理不規(guī)則詞語的承諾，但在實(shí)踐中往往不足。 一個(gè)基于詞典的提取器往往取決于詞典的好壞。如果 Hunspell 碰到的這個(gè)詞不在詞典里，那它什么也不能做。 Hunspell 需要一個(gè)廣泛的、高質(zhì)量的、最新的詞典以產(chǎn)生好的結(jié)果；這樣級(jí)別的詞典可謂少之又少。 另一方面，一個(gè)算法提取器，將愉快的處理新詞而不用為新詞重新設(shè)計(jì)算法。

如果一個(gè)好的算法詞干提取器可用于你的語言，那明智的使用它而不是 Hunspell。它會(huì)更快并且消耗更少內(nèi)存，并且會(huì)產(chǎn)生和通常一樣好或者比 Hunspell 等價(jià)的結(jié)果.

如果精度和可定制性對(duì)你很重要，那么你需要（和有精力）來維護(hù)一個(gè)自定義的詞典，那么 Hunspell 會(huì)給你比算法提取器更大的靈活性。 (查看 控制詞干提取 來了解可用于任何詞干提取器的自定義技術(shù)。)

提取程度

不同的詞干提取器會(huì)將詞弱提取或過度提取到一定的程度。 light_ 提取器提干力度不及標(biāo)準(zhǔn)的提取器。 minimal_ 提取器同樣也不那么積極。Hunspell 提取力度要激進(jìn)一些。

是否想要積極提取還是輕量提取取決于你的場景。如果你的搜索結(jié)果是要用于聚類算法，你可能會(huì)希望匹配的更廣泛一點(diǎn)（因此，提取力度要更大一點(diǎn)）。 如果你的搜索結(jié)果是面向最終用戶，輕量的提取一般會(huì)產(chǎn)生更好的結(jié)果。對(duì)搜索來說，將名稱和形容詞提干比動(dòng)詞提干更重要，當(dāng)然這也取決于語言。

另外一個(gè)要考慮的因素就是你的文檔集的大小。 一個(gè)只有 10,000 個(gè)產(chǎn)品的小集合，你可能要更激進(jìn)的提干來確保至少匹配到一些文檔。 如果你的文檔集很大，使用輕量的弱提取可能會(huì)得到更好的匹配結(jié)果。

做一個(gè)選擇

從推薦的一個(gè)詞干提取器出發(fā)，如果它工作的很好，那沒有什么需要調(diào)整的。如果不是，你將需要花點(diǎn)時(shí)間來調(diào)查和比較該語言可用的各種不同提取器， 來找到最適合你目的的那一個(gè)。

控制詞干提取

開箱即用的詞干提取方案永遠(yuǎn)也不可能完美。 尤其是算法提取器，他們可以愉快的將規(guī)則應(yīng)用于任何他們遇到的詞，包含那些你希望保持獨(dú)立的詞。 也許，在你的場景，保持獨(dú)立的 skies 和 skiing 是重要的，你不希望把他們提取為 ski （正如 english 分析器那樣）。

語匯單元過濾器 keyword_marker 和 stemmer_override 能讓我們自定義詞干提取過程。

阻止詞干提取

語言分析器（查看 配置語言分析器）的參數(shù) stem_exclusion 允許我們指定一個(gè)詞語列表，讓他們不被詞干提取。

在內(nèi)部，這些語言分析器使用 keyword_marker 語匯單元過濾器 來標(biāo)記這些詞語列表為 keywords ，用來阻止后續(xù)的詞干提取過濾器來觸碰這些詞語。

例如，我們創(chuàng)建一個(gè)簡單自定義分析器，使用 porter_stem? 語匯單元過濾器，同時(shí)阻止 skies 的詞干提?。?/p>

PUT /my_index
{
  "settings": {
    "analysis": {
      "filter": {
        "no_stem": {
          "type": "keyword_marker",
          "keywords": [ "skies" ] 
        }
      },
      "analyzer": {
        "my_english": {
          "tokenizer": "standard",
          "filter": [
            "lowercase",
            "no_stem",
            "porter_stem"
          ]
        }
      }
    }
  }
}

• 參數(shù) keywords 可以允許接收多個(gè)詞語。

使用 analyze API 來測試，可以看到詞 skies 沒有被提?。?/p>

GET /my_index/_analyze
{
  "text": ["sky skies skiing skis "],
  "analyzer": "my_english"
}

• 返回: sky, skies, ski, ski

雖然語言分析器只允許我們通過參數(shù) stem_exclusion 指定一個(gè)詞語列表來排除詞干提取， 不過 keyword_marker 語匯單元過濾器同樣還接收一個(gè) keywords_path 參數(shù)允許我們將所有的關(guān)鍵字存在一個(gè)文件。 這個(gè)文件應(yīng)該是每行一個(gè)字，并且存在于集群的每個(gè)節(jié)點(diǎn)。查看 更新停用詞（Updating Stopwords） 了解更新這些文件的提示。

自定義提取

在上面的例子中，我們阻止了 skies 被詞干提取，但是也許我們希望他能被提干為 sky 。 The stemmer_override 語匯單元過濾器允許我們指定自定義的提取規(guī)則。 與此同時(shí)，我們可以處理一些不規(guī)則的形式，如：mice 提取為 mouse 和 feet 到 foot ：

PUT /my_index
{
  "settings": {
    "analysis": {
      "filter": {
        "custom_stem": {
          "type": "stemmer_override",
          "rules": [ 
            "skies=>sky",
            "mice=>mouse",
            "feet=>foot"
          ]
        }
      },
      "analyzer": {
        "my_english": {
          "tokenizer": "standard",
          "filter": [
            "lowercase",
            "custom_stem", 
            "porter_stem"
          ]
        }
      }
    }
  }
}

GET /my_index/_analyze
{
  "text": ["The mice came down from the skies and ran over my feet"],
  "analyzer": "my_english"
}

• 規(guī)則來自 original=>stem 。
• stemmer_override 過濾器必須放置在詞干提取器之前。
• 返回 the, mouse, came, down, from, the, sky, and, ran, over, my, foot 。

正如 keyword_marker 語匯單元過濾器，規(guī)則可以被存放在一個(gè)文件中，通過參數(shù) rules_path 來指定位置。

原形詞干提取

為了完整地 完成本章的內(nèi)容，我們將講解如何將已提取詞干的詞和原詞索引到同一個(gè)字段中。舉個(gè)例子，分析句子 The quick foxes jumped 將會(huì)得到以下詞項(xiàng)：

Pos 1: (the)
Pos 2: (quick)
Pos 3: (foxes,fox) 
Pos 4: (jumped,jump) 

• 已提取詞干的形式和未提取詞干的形式位于相同的位置。

Warning：使用此方法前請(qǐng)先閱讀 原形詞干提取是個(gè)好主意嗎 。

為了歸檔詞干提取出的 原形 ，我們將使用 keyword_repeat 過濾器，跟 keyword_marker 過濾器 ( see 阻止詞干提取 ) 一樣，它把每一個(gè)詞項(xiàng)都標(biāo)記為關(guān)鍵詞，以防止后續(xù)詞干提取器對(duì)其修改。但是，它依然會(huì)在相同位置上重復(fù)詞項(xiàng)，并且這個(gè)重復(fù)的詞項(xiàng) 是 提取的詞干。

單獨(dú)使用 keyword_repeat token 過濾器將得到以下結(jié)果：

Pos 1: (the,the) 
Pos 2: (quick,quick) 
Pos 3: (foxes,fox)
Pos 4: (jumped,jump)

提取詞干前后的形式一樣，所以只是不必要的重復(fù)。

為了防止提取和未提取詞干形式相同的詞項(xiàng)中的無意義重復(fù)，我們?cè)黾恿私M合的 unique 語匯單元過濾器 ：

PUT /my_index
{
  "settings": {
    "analysis": {
      "filter": {
        "unique_stem": {
          "type": "unique",
          "only_on_same_position": true 
        }
      },
      "analyzer": {
        "in_situ": {
          "tokenizer": "standard",
          "filter": [
            "lowercase",
            "keyword_repeat", 
            "porter_stem",
            "unique_stem" 
          ]
        }
      }
    }
  }
}

• 設(shè)置 unique 類型語匯單元過濾器，是為了只有當(dāng)重復(fù)語匯單元出現(xiàn)在相同位置時(shí)，移除它們。
• 語匯單元過濾器必須出現(xiàn)在詞干提取器之前。
• unique_stem 過濾器是在詞干提取器完成之后移除重復(fù)詞項(xiàng)。

原形詞干提取是個(gè)好主意嗎

用戶喜歡 原形 詞干提取這個(gè)主意：“如果我可以只用一個(gè)組合字段，為什么還要分別存一個(gè)未提取詞干和已提取詞干的字段呢？” 但這是一個(gè)好主意嗎？答案一直都是否定的。因?yàn)橛袃蓚€(gè)問題：

第一個(gè)問題是無法區(qū)分精準(zhǔn)匹配和非精準(zhǔn)匹配。本章中，我們看到了多義詞經(jīng)常會(huì)被展開成相同的詞干詞：organs 和 organization 都會(huì)被提取為 organ 。

在 使用語言分析器 我們展示了如何整合一個(gè)已提取詞干屬性的查詢(為了增加召回率)和一個(gè)未提取詞干屬性的查詢（為了提升相關(guān)度）。 當(dāng)提取和未提取詞干的屬性相互獨(dú)立時(shí)，單個(gè)屬性的貢獻(xiàn)可以通過給其中一個(gè)屬性增加boost值來優(yōu)化(參見 語句的優(yōu)先級(jí) )。相反地，如果已提取和未提取詞干的形式置于同一個(gè)屬性，就沒有辦法來優(yōu)化搜索結(jié)果了。

第二個(gè)問題是，必須搞清楚 相關(guān)度分值是否如何計(jì)算的。在 什么是相關(guān)性? 我們解釋了部分計(jì)算依賴于逆文檔頻率（IDF）—— 即一個(gè)詞在索引庫的所有文檔中出現(xiàn)的頻繁程度。 在一個(gè)包含文本 jump jumped jumps 的文檔上使用原形詞干提取，將得到下列詞項(xiàng)：

Pos 1: (jump)
Pos 2: (jumped,jump)
Pos 3: (jumps,jump)

jumped 和 jumps 各出現(xiàn)一次，所以有正確的IDF值；jump 出現(xiàn)了3次，作為一個(gè)搜索詞項(xiàng)，與其他未提取詞干的形式相比，這明顯降低了它的IDF值。

基于這些原因，我們不推薦使用原形詞干提取。文章來源地址http://www.zghlxwxcb.cn/news/detail-848547.html

到了這里，關(guān)于使用阿里云試用Elasticsearch學(xué)習(xí)：3.4 處理人類語言——將單詞還原為詞根的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！