すべてのダイアグラムをインデックスします。辞書を使用する場合は、その維持に多くの作業が必要です。また、これは他の言語にもうまく対応できません。この方法の欠点は、部分的なトークンヒットが発生し、精度が低下することです。ただし、通常、「well being」や「wellbeing」を探している人は、ドキュメント内で「well*」を検索することは期待しないでしょう。データ内の結果を測定する必要があります。明らかな例としては、名前の最初と最後の名前があります。

トークンのストリームごとに：t1 t2 t3...tn、t1t2やt2t3...tn-1tnも通常のトークンとしてインデックスします。それらを別の非保存フィールドにインデックスし、クエリ時に制御できるようにします。

二つのケースがあります。

1. インデックスに「well being」があり、クエリが「wellbeing」の場合。これにはシングルフィルタを使用することで解決できます。これにより、多くの意味のない複合語が生成されますが、実際のクエリには一致しません。ほとんどの場合、一致しません。

2. インデックスに「wellbeing」があり、クエリが「well being」の場合。これを最適に解決する方法は、インデックス作成時に同義語の展開を使用することです。はい、その同義語のセットを維持する必要がありますが、リストはすぐに多くのケースをカバーするように成長します。これらは一方向のマッピング、例えば「wellbeing => well being」のようにし、同義語フィルタを設定して元の用語を保持します。

これは、Solrが新しかった頃（バージョン1.3）のNetflixで私が行った方法です。同義語は「superman」、「babysitter」、「manhunt」、「fullmetal」などをカバーしていました。最後のものは「Full Metal Jacket」と「Fullmetal Alchemist」のためのものでした。同義語は約300個でした。

また、ハイフン付きのバージョン（例:「Spider-man」）も考慮する必要があるかもしれません。

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)

ありがとう、Timさん、Walterさん。

シングルとエッジngramを使ってうまく動作させることができました。最初は多くの誤検出がありましたが、パラメータを調整し、通常のマッチよりも低いブーストを持つ別のコピー フィールドに分割することで、それを軽減することができました。