「ハックからハーモニーへ：レコメンデーションでの製品ルールの構造化」
From Hack to Harmony Structuring Product Rules in Recommendation
ヒューリスティクスがあなたの機械学習を損なわないように、それらを組み合わせる方法を学びましょう
現在のデータ駆動型の風景では、ソーシャルメディアのフィードからeコマースまで、レコメンデーションシステムがすべてを支えています。機械学習アルゴリズムがすべての重要な作業を行っていると考えるのは誘惑されるかもしれませんが、それは物語の半分に過ぎません。実際のシステムでは、最も関連性の高い推奨を生成するために、機械学習とヒューリスティックルールの組み合わせ（一般的にはプロダクトルール、ビジネスルール、または単にハックとも呼ばれる）に頼ることがよくあります。
たとえば：
- 同じアーティストのトラックを頻繁に推奨することはできません。
- フィードにサブスクリプションのコンテンツを含める必要がありますが、それに圧倒されることはありません。
- ユーザーが特定のカテゴリーや著者をすでに嫌いになっている場合、関連するコンテンツはペナルティを受けるか、あるいはフィルタリングされるべきです。
- 適切な場合を除き、露骨なコンテンツを推奨してはいけません。
ルールには2つのタイプがあります：ハードルールとソフトルールです。ハードルールはフィルターとして機能し、特定の文書が特定の文脈で推奨されないようにします。これらのルール自体には問題はありませんが、その数は制限されるべきです。さらに、ランキングプロセスの候補生成段階またはインデックス構築時にできるだけ早く適用する必要があります。一方、ソフトルールはガイドラインのようなものです：そのようなアイテムを推奨することができますが、あまり多くするとシステムのデバッグと開発が非常に困難になります。
ルールは技術的負債です。
私はシステム内のこのようなルールの量は、チーム内の内部のパワーダイナミクスに依存する傾向があると考えています。プロダクトマネージャーは通常、ルールを介して制約を表現することが便利だと考えますが、エンジニアは一般的にこれらのハックを好まない傾向があります。前のチームでは、このようなルールの数を最小限に抑える能力に誇りを持っていました。
私のキャリア全体で、再発するパターンにしばしば出会いました。エンジニアリングチームは、良い推奨を生成する方法について苦労します（全体的にも特定の側面でも）。その後、プロダクトチームは彼らが最もよく知っていること、つまり新しいルールを追加することに頼ります。これらのパッチは、迅速な修正が必要な場合には正当化されますが、後で削除するのは難しいです。システムは通常、定期的な技術的負債のような状態のままです。
物語の教訓：強力なエンジニアの採用には投資を惜しまないでください🙂
理想的なシステムでは、このようなルールは存在しないはずです。すべての曖昧なロジックは、十分に高度なモデルによって処理されるべきです。いつか私たちはこの技術的な状態に到達することを夢見ています（そしてそれを達成する方法についての仮説を持っています）。ただし、現時点ではそれは現実的ではありません。したがって、これらのルールを完全に禁止する代わりに、カオスを制限し組織化するアプローチについて話します。
構造化アプローチ：再ランキングフレームワーク
このフレームワークは、機械学習モデルとプロダクトルールの適用を統合し、これらのルールを構造化するのに役立ちますが、完全なカオスを避ける柔軟性も持っています。ある意味では、ルールを記述するための言語に過ぎません。私の意見では、非常に便利です。
この議論では、ランキングの最終段階に焦点を当てます。ここでは、残っているドキュメントが数十から数百に過ぎない場合に、最良のリストを編集したいとします。この段階の興味深い点は、現在のコンテキストで各ドキュメントをできるだけ正確に評価するだけでなく、これらのドキュメントがどのように組み合わさるかも考慮している点です。これがリストワイズランキングが登場する時です（ランキング関数ではなく、クエリ内のすべてのドキュメントに依存するのは損失関数のみです）。このリストワイズアプローチの典型的な応用は、結果の多様性を向上させることです。
以下はこのアプローチの主な原則です。
- 結果は反復的に生成され、最初の位置から最後の位置まで進行します。各反復では、次の位置に最も適したドキュメントを選択します。これは、多くの再ランキング戦略（例：多様化のためのよく知られたDPPなど）が機能する方法です。非線形の出力の場合、位置を重要度でランク付けすることもできます。
- 各反復では、残っているすべてのドキュメントを値関数でソートします。これは、クリック確率モデルの出力などの単純なものから、さまざまなモデルの出力（または複数のモデル）を組み合わせたもの、異なるイベントを予測するさまざまなモデルの出力、以前のドキュメントとの類似性などの多様性コンポーネント、および手動のブーストなどの組み合わせなど、より複雑なものまで範囲が広がります。値関数は各反復で再計算可能であり、したがって位置と最終出力のドキュメントの両方に依存することができます。計算効率が必要です。適切な値関数の作成は独立した興味深いトピックであり、このフレームワークはこの側面を制限または簡素化しません。
- プロダクトルールは次のように表現されます：位置のサブセットX内で、特性fを持つドキュメントの数は、特定のしきい値Cを上回るか下回るべきです。通常、Xは最初の位置から10までの範囲などの開始位置の範囲です。特性fは、ある特徴のしきい値ルールとして最も適切に表現されます。例えば、[feature(doc) > threshold]です。必要に応じて、この形式は非バイナリの特性を含めるように一般化できます。
- ルールには優先順位があります。すべてのルールを満たすことができない場合、最も重要でないルールを破棄します。より正
この形式のルールのいくつかの例を以下に示します：
- 出力全体のドキュメントのうち、少なくとも半数はサブスクリプションである必要があります。ただし、すでにすべてのサブスクリプションのドキュメントが読まれている場合、このルールは実行不可能となり、破棄されます。
- 最初の10つの位置における低品質なドキュメントの数は2を超えてはいけません。
- 位置10から20までの間には、新しいカテゴリのドキュメントが少なくとも1つは存在する必要があります。
「特定のプロパティを持つドキュメントが最初の10位置に少なくとも5つある必要がある」というようなルールでは、最初の5つの位置にはそのプロパティを持たないドキュメントが埋まり、その後にプロパティを持つドキュメントが5つ続く可能性があります。これをより均等に分散させるために、中間範囲のルールを追加することができます：最初の2つの位置には少なくとも1つ、最初の4つには少なくとも2つ、など。
このフレームワークを効率的に実装することは、良い課題ですが完全に実現可能です。以下に、記述された再ランキングフレームワークを実装する方法を示すPythonコードスケッチがあります。効率化に最適化されているわけではありませんが、良い出発点となるでしょう。
def rerank(documents, count, rules, scorer): result = [] while len(result) < count and len(documents) > 0: position = len(result) candidates = documents for rule in rules: filtered = [doc for doc in candidates if rule(position, doc)] if len(filtered) > 0: candidates = filtered next_doc = max(candidates, key=lambda doc: scorer(position, doc)) result.append(next_doc) documents.remove(next_doc) scorer.update(position, next_doc) for rule in rules: rule.update(position, next_doc) return result最後に、システムのデバッグ可能性と制御性を向上させるために、実行されたすべてのルールと破棄されたルールをログに記録することが大いに役立ちます。
これまで見てきたように、ルールなしの推薦システムは現時点では理想的なものではなく、現実的なものではありません。しかし、ルールを管理するためのよく構成されたフレームワークは、システムの潜在能力を抑えることなく必要な組織を提供することができます。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
