elasticcsearch(with JLH score)을 이용한 고품질의 추천시스템

elasticcsearch(with JLH score)을 이용한 고품질의 추천시스템

2022. 3. 30. 11:07ㆍ검색

728x90

技術書にはネタバレが含まれている可能性があることをご存知ですか？私たちもそうですし、ネタバレ注意もあります。私たちは本「Relevant Search 」を閉じて、検索エンジン技術が推奨事項を提供するための優れたプラットフォームであると主張しています。私たちは、推奨事項と検索は同じコインの両面であると主張します。どちらも「関連性」に基づいてユーザーのコンテンツをランク付けします。唯一の違いは、キーワードクエリが提供されているかどうかです。

検索エンジンは、調整しやすい推奨事項を実装するための理想的なフレームワークを提供すると主張します。実際、私はLucene Revolutionでこのアイデアについてすぐに話します（ Elastic {On}でのこのテーマに関する私の共著者の話も参照してください）。

Relevant Searchでは、Elasticsearchアグリゲーションを使用して推奨事項を実装します。これらのアイデアを紹介するだけです。私たちはからかいます:)。このブログ記事では、いじめを超えて、Elasticsearchで優れた推奨事項を提供する方法を模索し始めたいと思います。

（注：読む必要はありませんが、詳細については、バスケット分析に関する以前の記事を必ず確認してください。）

Recommender Systems 101: Basket Analysis - OpenSource Connections

You’ve probably seen “buyers also bought” recommendations. To drive more sales, you highlight items that are frequently purchased together. For example, the screenshot below shows “frequently bought together” for...

opensourceconnections.com

Aggregrations：この映画が好きな人が好きなものを見つける

さあ、掘り下げましょう！あなたは映画のwebsiteを運営しています。一連のユーザーがいて、それらに何を推奨するかを知りたいと考えています。さて、あなたが持っているかもしれない1つのアイデアは、各ユーザーをドキュメントとしてインデックス付けすることです。たとえば、movies_likedここではキーワード分析フィールドとして設定されていますが、これは省略しています）。

PUT recs/user/1{
 "movies_liked": ["Forrest Gump", "Terminator", "Rambo", "Rocky", "Good Will Hunting"]}
PUT recs/user/2{
 "movies_liked": ["Forrest Gump", "Terminator", "Rocky IV", "Rocky", "Rocky II", "Predator"]}
PUT recs/user/3{
 "movies_liked": ["Forrest Gump", "The Thin Red Line", "Good Will Hunting", "Rocky II", "Predator", "Batman"]}
PUT recs/user/4{
 "movies_liked": ["Forrest Gump", "Something about Mary", "Sixteen Candles"]}

ターミネーターが好きなユーザーにおすすめをしたいと思います。言い換えれば、ターミネーターが好きなユーザーが何を好きか知りたいのです。これは非常に基本的な「バスケット分析」であり、推奨事項の基本的な構成要素です。この名前は、ユーザーの買い物かごを見て、統計的に興味深い関係を見つけるというアイデアに由来しています。有名なことに、食料品チェーンは、おむつを購入した人がビールも頻繁に購入することを知りました。このような洞察は、ユーザーや企業にとって非常に価値のあるものになります。ここでは、ターミネーターに焦点を当てて、ターミネーターの視聴者にとって統計的に興味深いものを見つけます。

ユーザー履歴を保存するドキュメントを使用して、ターミネーターの視聴者が何を望んでいるかをどのように把握しますか？さて、あなたに思い浮かぶかもしれない最初のアイデアは、用語の集約を実行することです。用語の集約は、従来の側面です。これは、現在の検索結果のフィールドの用語のrawカウントを提供します。一般的なアプリケーション用語では、おそらく映画IDですが、ここではタイトルを使用します。「ターミネーター」を検索し、「movies_liked」フィールドで集計して、ターミネーターと一緒に頻繁に発生する映画の生のカウントを取得します。基本的にそうです：

POST recs/user/_search{
    "query": {
        "match": {
            "movies_liked": "Terminator"
        }
    },
    "aggregations": {
        "movies_like_terminator": {
            "terms": {
                "field": "movies_liked",
                "min_doc_count": 1
            }
        }
    }}

最終結果は、集計に焦点を当てると、次の内訳になります。

"movies_like_terminator": {
        "doc_count_error_upper_bound": 0,
        "sum_other_doc_count": 0,
        "buckets": [
        {
            "key": "Forrest Gump",
            "doc_count": 2
        },
        {
            "key": "Rocky",
            "doc_count": 2
        },
        {
            "key": "Terminator",
            "doc_count": 2
        },
        {
            "key": "Good Will Hunting",
            "doc_count": 1
        }}

上記のユーザーレコードをスキャンすると、ターミネーターが好きなユーザーは、フォレストガンプが好きな2人のユーザー、ロッキーが好きな2人のユーザーなどと一致していることがわかります。余談ですが、これをすべてのお気に入りの映画に対して繰り返します。「ターミネーター」、「プレデター」、「Say Anything」、およびすべてのお気に入りの映画も検索すると、協調フィルタリングが適用されます。検索を発行して、あなたと同じ映画が好きなユーザー。次に、生のカウントを調べて、見たことのない映画が好きな映画と頻繁に共起することを確認します。

しかし、このrawカウントアプローチは良いアプローチですか？関連検索とバスケット分析のブログ記事の両方で、生の共起カウントは推奨を行うには本当に不十分な方法であると説明しました。生のカウントは、ここで興味深いものよりも世界的に人気のあるものを優先します。たとえば、この例では、誰もがフォレストガンプが好きです。したがって、これを推奨の方法として使用した場合、すべてのユーザーにフォレストガンプが推奨されます。この問題を「オプラブッククラブ」問題と呼びます。これは、特に有用ではない、横断的な人気への偏見です。

ここでさらに興味深いのは、ターミネーターの結果に含まれる映画の相対的な数です。たとえば、ロッキーを見てください。ロッキーが好きなすべてのユーザーはターミネーターも好きです-彼らは正確に100％オーバーラップしています！別の言い方をすれば、ロッキーはここで100％フォアグラウンドで発生し、グローバルでは50％しか発生しません。バックグラウンドで発生します。これは、ターミネーターが好きなユーザーにとっては素晴らしい推奨事項のようです。

重要な用語を使用した意味のあるユーザーアイテムの接続の測定

rawカウントの問題を超越するには、重要な用語の集約が役立ちます。この集計は、意味のある推奨事項を提供するために必要な統計的に有意な関係の種類を測定します。生のカウントではなく、バックグラウンドのコーラップと比較した場合の現在の結果の用語の統計的有意性を計算するのが仕事です。私のバスケット分析の記事では、重要性をスコアリングするさまざまな方法の長所と短所について説明しました。重要な用語が何をするのかを調べてみましょう。

しかし、あまりにも批判的に考える前に、それを試してみましょう：

POST recs/user/_search{
    "query": {
        "match": {
            "movies_liked": "Terminator"
        }
    }
,
    "aggregations": {
        "movies_like_terminator": {
            "significant_terms": {
                "field": "movies_liked",
                "min_doc_count": 1
            }
        }
    }}

上記で異なるのは、significant_terms計算を使用することだけです。min_doc_countを1に設定して、非常に小さなデータセットで適切に機能するようにします。

そして確かに、これは当面の問題を解決します。フォレストガンプはどこにも見当たらず、私たちの推奨事項がより適切に見えることがわかります。

"buckets": [
            {
               "key": "Rocky",
               "doc_count": 2,
               "score": 1,
               "bg_count": 2
            },
            {
               "key": "Terminator",
               "doc_count": 2,
               "score": 1,
               "bg_count": 2
            },
            {
               "key": "Rambo",
               "doc_count": 1,
               "score": 0.5,
               "bg_count": 1
            },
            {
               "key": "Rocky IV",
               "doc_count": 1,
               "score": 0.5,
               "bg_count": 1
            }
         ]

JLH有意性スコアリングについて批判的に考える

それだけですよね？さらに飛び込む必要はありませんか？静かではありません。データのコンテキストでこのスコアリングがどのように機能するかを理解する必要があります。本当に優れたレコメンデーションシステムを構築するには、使用されるスコアについてより深く考えることができる必要があります。重要な用語はどのようにしてこのランキングに到達しましたか？バスケット分析の記事で見たように、重要性スコアリングのさまざまな形式には、独自の長所と短所があります。間違った方法を選択すると、推奨の品質に悲惨な結果をもたらす可能性があります。

この記事で得点する重要な用語のすべての形式を分解するつもりはありませんが（多くのオプションがあります）、これらの問題をどのように考えるかを自分自身に教えるためにデフォルトの方法に飛び込みましょう。デフォルトはJLHと呼ばれます。2つの値を乗算します

(foregroundPercentage / backgroundPercentage)  *
    (foregroundPercentage - backgroundPercentage)

ここでの「前景」とは、現在の検索結果でこのアイテムが発生する割合を意味します（ユーザーは私たちのアイテムのようにそれを取得しました）。たとえば、ターミネーター映画でのランボーの前景の割合は100％でした。バックグラウンドパーセンテージは、コレクション全体のグローバルパーセンテージです。上記のランボーの場合は50％です。

非常に一般的なアイテムのJLHスコアリング

このスコアリングが推奨のユースケースに適切かどうかをどのように評価しますか？いくつかの架空のシナリオを考えてみましょう。これらにより、いくつかの架空のシナリオの周りのスコアリングメカニズムを分解することができます。次に、実際のデータでそれらがどれほど現実的に機能するかについて批判的に考えることができます。私たちは映画を使い続けていますが、ここでは架空のシナリオで遊んでいます。これを、NetflixやMovielensなどの実際のデータセットに対するJLHスコアの適切性の分析と間違えないでください。

すでに説明した最初のシナリオは、誰もが好きな映画です。私たちのデータセットでは、これはフォレストガンプです。フォレストガンプのようなユーザーの99.999％。

確かに、そのような非常に人気のある映画は、JLHスコアリングでは特にうまくいきません。この(foreground/Background)用語を使用すると、フォレストガンプが達成できる最高の結果は100 / 99.999で、ほとんど1を超えません。同様に（前景–背景）または（100 – 99.999）は1をわずかに下回ります。以下に示すように、これはJLHのかなり低い数値です。

しかし、これは公正なシナリオですか？ほとんどのドメインで、100％近くのユーザーがアイテムを高く評価することはめったにないと思います。はるかに少ない数が映画に対して測定可能な好みを持っている可能性が高いです。たとえば、おそらく誰もがフォレストガンプを気に入っていることは確かですが、明示的な評価や暗黙のウォッチ/クリックなど、「いいね」を検出するほとんどの方法では、フォレストガンプを操作しているユーザーが100％表示されません。確かに、私はフォレストガンプが好きですが、前回見たのはおそらく10年前のことです。それは少し受動的な好みです。私はそれを見ました、それがNetflixに現れるのを見るとき、私は興奮する可能性が低いです。

より可能性の高いシナリオは、最も人気のある映画やショーであり、たとえば、ユーザーの20％が好きなものです。ここでのJLHスコアリングの運賃はどうですか？この映画、たとえばグッドウィルハンティングがこのユーザーのセットに100％好かれている場合、最高スコアは（100/20）*（100 – 20）または5*80または400になります。おそらく非現実的なものよりもはるかに高いです。フォレストガンプシナリオ。

平均的な人気のアイテム

ほとんどの映画は、映画が好きなユーザーの1桁の割合を示しています。平均的な映画に移りましょう。ロッキーIVは、ユーザーの4％が気に入っています。

Rocky IVはJLHとどのくらいうまくやっていますか？JLHムービーを繰り返しますが、ロッキーのようなフォアグラウンドユーザーの100％の場合、（100/4）*（100 – 4）または25 * 96 = 2400になります。これは、グッドウィルハンティングが推奨される可能性を大幅に上回っています。

より「通常の」偏差

人気のGoodWillHuntingで400の最高スコア、平均的な人気のRocky IVで2400のスコアで、JLHは推奨事項としてはひどいようですよね？完全ではありません。これらの「ベストケース」シナリオの可能性について考えてみましょう。あるアイテムが好きなユーザーの100％が別のアイテムを好きになるのはどれほど合理的ですか？アイテムを高く評価する前景の確率が、背景の好みから大幅に逸脱する可能性はどのくらいありますか？

それは、データ内のアイテム設定の相対的な分布に大きく依存します。たとえば、ロッキーIIIが好きなら、ロッキーIVも好きになる可能性が非常に高いと主張することができます。おそらく100％に近いオーバーラップです。

ただし、バックグラウンドデータセットとフォアグラウンドデータセットの間でデータがそれほど変化しない傾向がある場合は、おそらくこれはそれほど大きな問題ではありません。たとえば、前景の期待値が、背景のパーセンテージを中心とした正規分布に基づいている場合を考えてみましょう。背景と前景の間の仮想的な一定の変化が約75％の変化であると考えてみましょう（ロッキーIVは7 +/- 3％、グッドウィルハンティングは20 +/- 15％になる可能性があります）。これらのおそらくより現実的なシナリオでは、スコアが期待されます。

ロッキーIVベストスコア：（7/4）*（7-4）= 5.25
グッドウィルハンティングのベストスコア：（35/20）*（35 – 20）= 26.25

言い換えれば、均等に比例したシフトは、人気のある映画よりも人気のある映画にはるかに多くの報酬を与えます。最初の用語（分割）は、2つの映画の間で同等になります。ただし、他の用語（減算）は、シフトを考えると、人気のある映画にはるかに高い倍数を提供する可能性があります。

なぜこれなのか？JLHの作成者であるMarkHarwoodは、これがまさにJLHが行うように設計されていることであると指摘しています。JLHは、多くの推奨データセットに見られるパターンを反映しています。人気のあるアイテムの人気は劇的に変化しません。他の一見関連するアイテムにスコープを設定した場合でも、背景の人気からの逸脱ははるかに少なくなります。バスケット分析の記事で、誰もが卵を購入すると述べました。ほとんどすべての人が卵を購入する場合、他のオメレテ成分に卵の購入をスコーピングすると、卵の購入の合計割合がわずかに増加するだけである可能性があります。しかし、私たちはこれらのオムレツシェフに合理的な推奨事項を求めています。したがって、卵の人気がわずかに増加したとしても、それは重要であると見なされるはずです。

これを考えると、Good WillHuntingがバックグラウンドから+/-25％しかずれていないのがより一般的かもしれません。たまたまそうです。これにより、Good Will Huntingの最高スコアは、あまり人気のないRockyIVと同じになります。

(25 / 20) * (25 - 20) = 6.25

言い換えれば、たとえばSense and Sensibilityを調べると、Good Will Huntingの人気スコアは25％増加し、仮想のRocky IVは75％増加します。

推奨事項のJLH有意性スコアリングに関する最終的な考え

今見たものを考えると、JLHは、人気の低いアイテムは、バックグラウンドのパーセンテージよりもフォアグラウンドの確率を上げる可能性が高いと想定しています。

2つのアイテム間で突然100％のオーバーラップが発生することはないため、通常の前景のパーセンテージは背景のパーセンテージにかなり近いままになる傾向があります。
人気のあるアイテムの前景のパーセンテージは、あまり人気のないアイテムの前景のパーセンテージよりもはるかに小さくなります。

最も重要なポイントは、この基準がデータの統計パターンによって決定されることです。データの典型的なパターンを評価する必要があります。典型的な好みに焦点を当てるとき、前景と背景のパーセンテージの関係は何ですか？これは、優れたレコメンデーションシステムを構築するために追求する必要のある、難しいドメイン固有の作業です。

しかし、私たちがまだ検討していない1つの悪質なケースがあります。たまたま重なっている非常に珍しい映画はどうですか？バスケット分析の記事で、これがJaccardの類似性のアキレス腱であることがわかりました。それでは、そのようなシナリオの1つを考えてみましょう。これには、たまたま非常にまれに1人のユーザーに好かれている2つの映画が含まれます。

ダム映画と奇妙な芸術映画の2つの映画はそれぞれ2回発生します。そして、たまたま、DumbMovieとWeirdArt Filmの両方が、あいまいな映画や悪い映画が好きな1人のユーザーに好かれていました。

PUT recs/user/2124{
    "movies_liked": ["Weird Art Film", "Forrest Gump"]}
PUT recs/user/2125{
    "movies_liked": ["Weird Art Film", "Dumb Movie"]}
PUT recs/user/2126{
    "movies_liked": ["Dumb Movie", "Rambo"]}

これらの映画のバックグラウンドパーセンテージは非常に低いです。おそらく0.001％。奇妙な芸術映画が好きな人に映画を推薦するとき、「ダム映画」の前景の割合は50％になります。突然非常に一般的です！このスコアはどうですか？

(50 / 0.001) * (50 * 0.001) = 2499950.0

Eeegads！それはハイスコアです。

テッド・ダニングのサプライズと偶然の一致に関する論文で説明されているように、この結果は不当に高いと言えば十分です。これらの映画を気に入っているユーザーはごくわずかです。おそらく、有意性について統計的に確固たる結論を出すには十分ではありません。前景と背景のパーセンテージが互いにどれだけ離れているかを考えると、これを確認できます。データが+/-25％を示している場合、この珍しい映画の前景のパーセンテージは、0.001未満から0.001をわずかに超える値になると予想されます。間違いなく50ではありません。この値は、データに見られる典型的なパターンについての私たちの信念に反している可能性があります。

したがって、上記の推奨事項に加えて、重要性スコアリングの形式を適用するときに評価する別の重要な基準があります。

前景と背景の関係の間の典型的な統計的有意性を反映し始める、いいねの数の妥当な下限を見つけます。fgのパーセンテージが背景を中心に+/-3％であることがより一般的であるが、1つのまれな映画が大きな偏差を示している場合は、それを外れ値と見なし、妥当な最小値を設定します。

（ドキュメントの最小頻度の下限を高くすることは、パフォーマンスのためにとにかく良い考えです。発生するすべての偽の用語に対してこれらの高価な計算をすべて実行しないようにしてください）。

重要なポイントは、重要性を測定する方法で重要なのはデータです。典型的な関係は何ですか？そして、その顔には何が期待に大きく反するように見えますか？

ベイジアンアプローチに向けて

今後の記事で、検索エンジンでの共起をスコアリングする方法を模索し続けたいと思います。しかし、私が魅力的だと思う1つの領域を探索して、あなたを離れたいと思います。前景と背景のパーセンテージに関するこのすべての話では、ベイズの公式について考えざるを得ません。

P(A | B) = P(B | A) * P(A) / P(B)

私たちがやろうとしていることについての別の考え方は、別のアイテムを好きになる確率を前提として、あるアイテムを好きになる確率を理解しようとしていることです。それがまさにP（A | B）が表現していることです。B（おそらく「ターミネーター」）が好きなすべてのユーザーを対象とし、A（おそらく「ランボー」）が好きになる確率はどれくらいですか。

P(Rambo | Terminator) =
     P(Terminator | Rambo) * P(Rambo) / P(Terminator)

さて、P（ランボー|ターミネーター）は前景のパーセンテージに対応します。一方、P（Rambo）はバックグラウンドパーセンテージに対応します。言い換えると：

foregroundRambo =
     ( P(Terminator | Rambo) / P(Terminator) ) * backgroundRambo

私はあなた自身のデータ分析作業を実行することをほのめかしました。フォアグラウンド確率とバックグラウンド確率の間のこの関係を見つけようとしないでください。しかし、前景と背景のパーセンテージの間の典型的な関係を理解するようにしてください。次に、一般的な一般的な関係を使用してスコアリング方法を評価し、スコアリングの統計パターンに自信があると感じる適切な下限を見つけることができます。ベイズの公式についてもう少し一般的に考えると、一般的な変換が行われていることがわかります。1つの例から離れて、これらの関係を取得するために確率（つまり確率分布）を返す関数を考えることができます。

ForegroundDistribution(item A, item B) = 
    transformation(item A, item B) * background( item B)

私はまだこれを頭の中でマッピングし終えていませんが、このアイデアはベイズフォーミュラの根底にあります。「バックグラウンド」分布は、ベイジアン事前分布に対応しているようです。それは、証拠なしで、どのような典型的なバックグラウンド確率分布を期待できるかを示しています。バスケット分析の記事では、パターンを購入するためのべき乗則またはジップの法則について議論しました。古典的なベイズ分析の「変換」は、尤度関数に対応します。ここでは、他のBを考えると、Aの相対的な可能性です。これは、AとBの相対的な共起に基づいて、バックグラウンド確率を縮小または拡大する定数を出力することとして想像できます。いくつかのAとBのペア–前景の割合を増やします。または、0.5を吐き出し、縮小します。

三次元で想像できる「変形」機能。x軸とy軸は、項目aとbに対応し、z軸は、前景を取得するために背景を乗算する量に対応します。P（B | A）（Ramboをスコープとするターミネーター）をサンプリングするには、Ramboユーザーを検索し、ターミネーターユーザーのrawカウントをカウントします。同様に、Ramboユーザーの総数を取得することで、P（Rambo）を検索できます。これらの値から、変換のポイントごとの値を計算できます。

この変換を数式に導き出すことはおそらくできないでしょう。ただし、データを使用してグラフを描くことはできます。ターミネーターとランボーなど、任意のアイテムの組み合わせで、この値を計算できます。ペアリングごとにこれを計算する必要はありません。あなたの目標は、すべての可能な値を見つけるのではなく、あなたの評価を導くために典型的なものを理解することであることを忘れないでください。

この変換をサンプリングし、値が0.9から1.1の間に留まる傾向がある場合、前景と背景のパーセンテージが大きく外れることはないことがわかります。人気のあるものが人気のないものよりも成長/縮小しない場合は、JLHがうまく機能する可能性があります。このパターンに反する激しい変動がある場合は、JLHのようなものがデータに適していない可能性があると感じるかもしれません。

私は実際、これらのアイデアをさらに追求することに本当に興奮しています（そして、あなたがそれらで遊んでいるなら、何が起こるかを私に知らせてください）。たとえば、これは特に古典的なベイズ分析ではなく、一部のモデルパラメータ（コインのバイアス、ダイの重量、コーパス内のトピックの分布など）に自信を持たせようとしています。代わりに、2つの値（アイテムAとB）と変換の間の関係を決定しようとしている回帰のようなものです。おそらく、パラメーター化されていない（つまり、基になるデータが1つの式に正確に適合するとは想定していない）レス回帰のようなものです。おそらく、私が本当にすべきことは、変換プロセスでベイズ分析を実行して、任意のAアイテムとBアイテムの間の関係にある潜在的なパラメーターを見つけようとすることです。あなたのアイデアを聞いてみたいです！連絡するこれらのアイデアをより深く探求することに興味がある場合、またはすでにこれらのアイデアを探求している知恵を私に示したい場合。

実用的なElasticsearchとデータモデリングの考慮事項

アグリゲーションアプローチでは、優れた推奨事項を作成するための実用的な考慮事項がいくつか残っています。さらなる調査の領域として、ここでそれらに注目する価値があります

通常の検索スコアと一緒に集計からの有意性スコアを使用することはできないため、1つのクエリだけでリリース日などの要因によって直接バイアスをかけることはできません。パーソナライズされた検索を行うために、「検索」と一緒に「推奨」を単純に行うことはできません。残念ながら、集計と検索は2つの異なるユニバースに存在します。

これを回避する1つの方法は、サンプラー集約も使用することです。サンプラーアグリゲーションは、上位N個の最も関連性の高いドキュメントに対してアグリゲーションを実行します。たとえば、検索結果で最近の映画に優先順位を付けてから、上位100件の検索結果を「フォアグラウンド」セットとして扱うことができます。これにより、有意性の計算に対する間接的な関連性の影響が提供されます。

また、おそらく、重要度スコアリングを通常のクエリプロセスと統合する方法があります。私は、通常のクエリプロセスで発生する可能性のある新しいSimhash機能を介して、MoreLikeThisまたは局所性鋭敏型ハッシュを使用して遊んでいます。しかし、私はこれらの方法についてかなりの留保を持っていますが、ここでは取り上げません（申し訳ありませんが、この記事はおそらく他の10の記事のルートです:-)）

ElasticGraphを使用したグラフベースの推奨事項

Elasticは、2次および3次の有意性にナビゲートする機能とともに、サンプリング/有意性の集計を行う興味深いグラフ製品をリリースしました。たとえば、上記の演習に加えて、推奨事項を生成し、どのジャンルまたは味覚プロファイルが私にとって重要であるかに気づき、それらの味覚プロファイル全体で何が重要であるかを見つけることができたらどうでしょうか。これは一種のグラフナビゲーションであり、ユーザーに多くの価値を提供し、レコメンデーションシステムの作成を劇的に簡素化できます。

実際、Elasticのグラフ製品を使用して、この記事の内容を超える推奨事項について、いくつかの興味深いデモを作成しています。Elasticのグラフ製品で行っていることの概念実証に興味がある場合は、お気軽にご連絡ください。私たちが積極的に開発しているにもかかわらず、アイデアと概念実証をご紹介できることをうれしく思います。フィードバックをお待ちしております。

検索エンジンは推奨事項の未来です

SolrやElasticsearchなどのオープンソース検索エンジンにより、検索の実装が非常に簡単になりました。レコメンデーションシステムでは、複数の分散システムを統合し、Rを学習し、データサイエンティストの巨大なチームを雇う必要があります。非常に難しいですね。数日で妥当な検索に立ち向かうことができますが、レコメンデーションシステムにはさらに多くの労力が必要です。

私たちはそれを変えることを推進しています。SolrとElasticsearchが箱から出してすぐに優れた検索を可能にするのと同じように、現在の体制よりもはるかに低い所有コストでレコメンデーションシステムの構築を支援したいと考えています。検索エンジンは、数十の機械学習ライブラリや分散システムを操作するよりも、保守が簡単で、調整が簡単で、展開が簡単なため、レコメンデーションシステムを明示的に実装するのに理想的な場所です。

SolrまたはElasticsearchがレコメンデーションシステムの開発を簡素化する方法を探求することに興味がある場合は、ご連絡ください。ぜひ一緒に探求してください。

この記事のレビューに協力してくれたElasticのMarkHarwoodに特に感謝します。

SolrおよびElasticsearchベースの検索エンジンの関連性を調整する方法に関するトレーニングコースを提供していることをご存知ですか？