ビッグデータによるパーソナライズされた推奨に関する私の理解

この記事を書こうと思ったのは、一方では昨日、ようやくXiang Liang著の「推薦システム実践」を読み終えたのと、他方では私が担当している推薦システムプロジェクトがすでに複数バージョンの反復段階にあり、最近のABテストの結果から判断すると、新しく提出されたアルゴリズムモデルがある程度進歩し、現在すべてのトラフィックが新しいアルゴリズムに切り替わっているからです。

なので、読んで思ったことと実際の操作で感じたことを組み合わせて、表現したいこと、共有したいことが常にあるので、言わずにはいられません～～ハハ！

しかし、パーソナライズされた推奨事項について話す前に、2 つの余談をさせてください。

まず、読書というテーマに関しては、私の記事「これらの年月、これらの掘削アルゴリズム、これらの考察」の中で触れました。読書は、自分を磨く最良の方法の一つです。私はかつて、毎月本を一冊読み終えるという目標を自分に設定したと言いました。正直に言うと、その目標をやっと達成できただけです。しかし、本を読むことに対する考え方については、私は依然として自分の意見を貫いています。

まず、読書の時間をどうやって捻出するかです。1つは通勤時の地下鉄での断片的な時間、2つ目は就寝前、そして3つ目はコードを入力しブロックを動かすのに疲れたときです。私が言いたいのは、自分を向上させたいなら、本を読む時間を見つけなければならないということです。覚えておいてください、この時間は他人のために圧迫されているのではなく、将来あなたの給料が 1 段階または 2 段階上がるために圧迫されているのです。

次に、読み方についてです。以前、本を読むときは、著者の意図を理解し、そこから得られる知識を吸収しようとしていました。今では、読書をするときには、ペンを持って読みながら絵を描くのが好きです。

著者の言っていることを理解し、それを自分の認識と組み合わせて、自分の気持ちを書き、さらには自分の理解に基づいて著者の視点に反論し、後で検証するようにしています。よくわからないところについては、読んでみて思ったことを書きます。

そして、いくつかの章については、詳細に研究する価値がないと判断した場合は、すぐに飛ばします。結局のところ、時間はやはり貴重です。

それ以来、私が読んだ本には、落書きされた章や、まったく新しいページがある章がいくつもありました。まとめると、本を読むときは、ただ盲目的に読むだけではだめです。自分に合ったものを見つけて、そこから利益を得るためには、一定の効率と方法が必要です。

さて、本題から外れたことを長々と話しましたが、本題に戻りましょう。

1. この本から得たいくつかの考え

まずはこの本（レコメンデーションシステム実践編）の全体的な評価をしていきましょう。

この本についての私の個人的な見解は、これは推薦システムの参考書ではないので、推薦システムのアルゴリズムを詳しく紹介するものではないということです。むしろ、パーソナライズされた推薦システムを設計する際のいくつかの測定ポイントと考え方を説明することに重点を置いています (私はこれがより重要だと考えており、その理由は後で説明します。また、この本の実験的な参考文献のいくつかはオプションであると考えています)。

だからこの本のタイトルはちょっと無理がある気がします～～

さて、彼の本のタイトルについてはこれ以上考えずに、私が個人的に共有する価値があると思う本の内容についていくつか話しましょう。これらは、この本を読んで実際の業務と組み合わせた後の私の考えの一部です。

さらに、この章の内容は、決して本の内容の繰り返しではないことがわかります。掘削機を運転する人、特に推奨システムの掘削機を運転する人にとって、私の意見は役立つはずです。

（１）まず、推薦システムの評価についてお話しします。

まず、著者が挙げた評価指標を列挙します。ユーザー満足度、予測精度、カバレッジ、多様性、新規性、驚き、信頼性、リアルタイム性、堅牢性、ビジネス目標です。そして著者は、推奨システムを設計する際には、これらの指標を最大限考慮し、特に推奨結果は可能な限り多様で斬新、そして意外性のあるものにすべきだと述べました。

この点に関しては、私の個人的な意見は少し異なります。推薦結果を評価するのに十分な指標は1つだけであり、それは商業的価値であると考えています。商業的価値を高め、より多くの利益をビジネスにもたらすことができる推薦システムこそが、良い推薦システムです。

推薦の多様性と新規性については、多様な推薦結果が価値変換を向上させることができる場合、推薦システムを設計する際に多様性の重みを適切に高めます。同様に、新規なものが価値変換を向上させることができる場合、新規性の重みを高めます。これが回帰推奨システムの真髄です！

この時点で、実際の個人操作でもこれが実行されます。まず、コンバージョン率や収益変換率など、達成する必要のある目標を設定します。アルゴリズムを調整する唯一の基準は、コンバージョン率が向上したかどうかです。そうであれば、私たちのアルゴリズムの改善は効果的であり、そうでない場合は、この改善は失敗です。

この本のすべての実験がカバレッジ、多様性、その他の指標を評価しているという事実については、私の意見では、それは実際には必要ありません。

実際には、推奨カバレッジを増やすことでコンバージョン率が上がるという保証はありません。言い換えれば、ロングテールを活用することでコンバージョン率を上げることができるのであれば、適切にカバレッジを増やし、多様性をサポートするように努めます。しかし、実際のビジネスシナリオは非常に複雑であり、この保証は絶対的なものではなく、実際の状況、つまり実際の運用に基づく必要があります。

さて、実際の運用の話が出たので、評価方法に関する話をします。

この本では、オフライン実験、ユーザー調査、オンライン実験という 3 つの方法が紹介されています。

まず、オフライン実験についてお話しします。個人的には、レコメンデーションシステムにおいて、既存のユーザー行動の軌跡（レコメンデーションがクリックされたかどうかなどのデータ）を使ってレコメンデーションシステムを予測するのはあまり信頼性が低く、参考程度にしか使えないと思っています。

なぜなら、例えば推奨シナリオでは、分類のようなモデルではないからです。絶対的な値はありません。正しいものは正しく、間違っているものは間違っています。予測の度合いが向上しただけです。

第二に、ユーザー調査は一種の参考資料ですが、調査の量が十分であることが前提です。量が十分でなければ、その意義は小さくなります。したがって、これは莫大なコストを消費するプロジェクトであり、実際の運用には推奨されません。

したがって、個人的には、オンライン実験、厳密に言えば AB テストに重点を置くべきだと考えています。簡単に言うと、データを迂回させて、一部はレコメンデーションアルゴリズムAを経由し、他はレコメンデーションアルゴリズムBを経由します。そして、アルゴリズムAとBのレコメンデーション結果から生じるユーザー行動を収集し、コアバリューに基づいて結果を比較することで、一目でわかるようにします。

しかし、この場合、オンラインシステムは非常に深刻な問題であり、効果が不明なアルゴリズムの実験をオンラインでどのように実行できるのか、と異議を唱える人もいるかもしれません。

この問題に関しては、まず、アルゴリズムがオンラインになる前に、オフライン実験など、新しいアルゴリズムに関する一定の評価を実施することが絶対に必要です。絶対に信頼できるものではありませんが、参考として使用できます。

統計調査などの他の作業も不可欠です。データの量が多いと、いくつかの問題が反映される可能性があります。アルゴリズムの設計には常に基礎があり、これらが基礎です。言い換えれば、これらの前提条件により、新しいアルゴリズムが既存のアルゴリズムよりも優れていなくても、大幅に低下しないことが保証されます。

このようなことが起こった場合、それは最初の作業が非常に不十分で、アルゴリズムの設計が混乱していたことを意味するだけです。

第二に、私たちが設計した AB テストのメカニズムは、トラフィックの配分を調整できる必要があります。そうでない場合、デザイナーはただ壁に向かって進む必要があります。 AB テストの転換では、新しいアルゴリズムのトラフィックを完全に制御して、エラーが制御可能な範囲内であることを保証しながら、観測可能な効果を達成できます。

（２）コールドスタート、これは非常に深刻な問題である

推薦システムのコールドスタートに関しては、著者はこの問題に 1 章を割いています。ただし、本の最後で、推薦システムのコールドスタートの問題は無視する、推薦システムが十分に適切に設計されている限り、データの問題を心配する必要はない、という見解を提示しています。

しかし、私の意見では、コールドスタートは大きな問題であり、特にこの分野に不慣れな人にとっては避けられない問題です。コールドスタートの問題を解決するための適切なメカニズムがあれば、推奨システムは良好なスタートを切ることができます。

たとえば、レコメンデーションシステムにおける最も古典的な協調レコメンデーションアルゴリズムは、ユーザーの行動データに依存しています。レコメンデーションシステムの初期段階では、ユーザーの行動は非常にまれであるため、これは緊急に解決する必要がある問題です。

では、ユーザーの行動データをどのように蓄積すればよいのでしょうか?

また、ユーザーの行動データを蓄積するという前提のもと、レコメンデーションの効果を可能な限り確保する必要があることにも留意してください。つまり、ユーザーがレコメンデーションをクリックする可能性を高めることです。企業にとっては、可能な限り多くの価値を生み出すことができ、また、自社のビジネスにとっても、より多くのデータをできるだけ早く収集することができます。

簡単な例を挙げてみましょう。 Toutiao に似たアプリを作成して、パーソナライズされたニュースの見出しをプッシュしたいと考えています。一言で言えば、何をすべきでしょうか?

これはコールドスタートの中のコールドスタートです。システム全体が新しく、記事もユーザーも新しく、ユーザーデータも閲覧履歴も「いいね」や「嫌い」もありません。ユーザーの好みを反映できず、記事が話題になっているかどうかもわかりません。

こういう時どうすればいいでしょうか？同書によれば、ユーザーの登録情報を活用し、商品情報と組み合わせてレコメンデーションを行うという基本的な考え方には何ら問題はないという。ここでの商品は、実はさまざまなニュースの見出しです。

しかし、この方法にも大きな制限があります。一方では、登録時に得られる情報が限られており、その情報が偽りである場合が多いため、あまり頼りにすることはできません。

こういう時どうすればいいでしょうか？ユーザー向けのパーソナライズされた推奨事項は無視してください。全体的な傾向を把握するだけで十分です。では、全体的な傾向をどう把握するか。外部からの援助で！

先ほども言いましたが、Toutiao に似ています。 Toutiao も同様の作業を行ったはずです。たとえば、ログインしていなくてもおすすめリストを提供していたはずです。そして確かなのは、この推奨リストはデータによってサポートされており、ランダムにプッシュされたものではないということです。これは、この推奨リストが一般の人々により受け入れられやすいことを意味します。言い換えれば、クリック率を高めることができます。

それで、それをどのように活用すればよいのでしょうか?推奨リストをコピーしました。もちろん、これは他の人の記事をそのままここに投稿してよいという意味ではありません。そうすると、訴えられることになります。

類似度を計算し、Toutiao からの各プッシュごとに、独自の記事ライブラリ内で最も類似した記事を見つけて、一番上にプッシュすることができます。独自のデータに頼ることなく、推奨事項のリストが表示されます。

効率性の問題に関しては、実際にはニュースの見出しの推奨リストはリアルタイムで変更されないため、計算コストは完全に手頃です。

類似度を計算する方法については、別のカテゴリです。ここでは、アイデアのみを示します。

アイデアについて言えば、この例を通して私が表現したいことはほぼ同じです。つまり、この種のコールドスタートの問題に対処するための私たちのアプローチは、同様の製品の既存の結果を活用し、それを基礎として使用することです。

ちょっと悪党だけど、問題は解決できるから、悪党になろうよ〜〜

直接的な行動の軌跡を収集した後は、今後の作業がずっと簡単になります。必要なことだけを実行してください。

（３）文脈情報とルールスコアリングモデルの関係

この本では、いわゆるコンテキスト情報は主に時間コンテキストと場所コンテキストの 2 つの側面から構成されていると述べられています。

私の意見では、これでは十分とは言えません。結果に影響を及ぼす可能性のあるすべてのサードパーティ要因を考慮に入れる必要があります。いわゆるサードパーティ要因は、ユーザーのパーソナライゼーションと明確な相関関係がない要因として定義できます。例えば、上で述べた時間や場所、季節、天気などです。

これについて言えば、ルールスコアリングモデルについて話さなければなりません。

ルールスコアリングモデルについて簡単に説明しましょう。いわゆるルールというのは、自分たちで決めた一連の操作仕様のことで、スコアリングに関しては、特定の操作があった場合に、追加ポイントを与えるといったことです。最終的に、誰がより多くのポイントを獲得したかを見て、その人が選ばれます。より専門的な用語を使うと、ルールウェイトモデルです。つまり、実際にはウェイト計算です。

シンプルですよね？でもその重要性を過小評価しないでください。個人的には、協調推薦などのアルゴリズムによって推薦システムが表現されるとは考えたことがありませんでした。

レコメンデーションシステムは巨大なプロジェクトです。協調レコメンデーションに代表されるアルゴリズムは、あくまでも1つの要素に過ぎません。さまざまなものの組み合わせで成り立っているはずです。重みモデルは非常に単純かつ原始的かつ効果的な方法です。

さまざまな外部要因が推奨結果に与える影響を定義する方法、つまり、さまざまな外部要因に適切な重み比を割り当てる方法。これには統計が必要です!

特に、現在のビッグデータの状況では、この統計に基づくルール重みモデルはますます効果的になります。大規模なデータ統計がデータの傾向を反映できることは間違いありません。

はい、これがタイトルのデータに「単語」を追加した直接的な理由であることを認めます。

実際の運用では、多くの推薦システムの結果がルールベースの重みモデルを通じて提示されます。また、推薦方法が複数ある場合は、複数の方法の結果をルールベースの重みモデルを通じて統合し、最適な結果を実現します。

したがって、推奨システムのアルゴリズムがわからない場合は、ルールベースの重みモデルを試してみてはいかがでしょうか。重みモデルを使用して推奨結果を修正すると、驚かれることでしょう。

（４）普遍的なロングテールとマシュー効果

ロングテール分布またはロングテール効果、この用語を詳しく説明する必要はありません。実際、現実の生活では、これは非常によくある現象です。

そして、ロングテール分布の直接的な結果はマシュー効果であり、これは平たく言えば、強い者がさらに強くなり、弱い者がさらに弱くなることを意味します。

つまり、例えば、人気のある商品の場合、それに付随する行動データが多いほど、推奨される可能性が高くなり、表示される可能性も高くなり、再び推奨される可能性も高くなり、という悪循環に陥ります。他の商品が存在する必要があるのでしょうか? ！

したがって、正確さに加えて、著者が実験結果で常に強調してきたもう 1 つの指標は、カバレッジまたは多様性です (これが、著者の実験の説明部分があまり参考にならないと感じたため、常にスキップしてきた理由です)。

ロングテールを活用する必要があるかどうかについては、私の見解は前に述べたものと同じです。ロングテールを活用することがビジネス価値の向上に有益であれば、カバレッジを拡大する方法、つまりホットアイテムの重量を減らす方法を見つけるでしょう。ロングテールを活用することが価値変換に有益でないのであれば、なぜこれを行う必要があるのでしょうか。

極端な例を挙げると、毎日一定数のアイテムを推奨し、それらを変更しなくても、それらが生み出す価値が他の不正な推奨システムによって生成される価値よりも高い場合、それは良い推奨です。

これは、私が以前に指摘した点に戻りますが、推奨システムの品質を測定する唯一の基準は、価値変換を改善できるかどうかです。

では、ロングテールを掘り下げるべきでしょうか？誰もが掘り下げるべきでしょうか？この質問をする人はきっと愚か者だ。ロングテールを活用するかどうか、ビジネスシナリオを検討し、十分な AB テストを実施して、カバレッジと多様性を向上させるかどうか、またどの程度向上させるかを決定します。これらすべての唯一の基準は、それが私にさらなる収益をもたらすかどうかです。

もしそれが私にもっとお金をもたらしてくれるなら、それはロングテールであり、マシューだ、だから何？

2. 推薦システムに関する悲惨な経験

これを書く前に、私が企画し実装したレコメンデーションシステムはレコメンデーションシステムと言えるのか、とよく考えてみました。それから考えてみると、そうあるべきだとは思いますが、典型的なレコメンデーションシステムではありません。ただし、実装プロセス全体を通して、その考え方は依然として参考になります。

さらに、実際のエンジニアリング操作は教科書のようなものではなく、特定のシナリオと条件から生まれるものであることが予想されます。つまり、普遍的な推奨システムは存在せず、たとえ存在したとしても、それは決してあまり役に立たないでしょう。

プロセス全体を通して、問題に対処するいくつかの考え方や方法は、将来同様のプロジェクトを実施するすべての人にとって参考になる可能性があると思います。

そこで、書き留めることにしました。

（１）事業シナリオは以下のとおり

3月か2月だったと思いますが、私が勤めていたA社がオンライン教育チャンネルを立ち上げました。しばらくして、オンライン教育の運営を担当していたBさんが突然、「ブログチャンネルのアクセス数が多いので、もっとアクセスを集められないか？」と思いつきました。そこでそのタスクは私が勤務していたデータ部門に移管されました。

なお、A社は主にIT技術フォーラムコミュニティブログを運営しており、オンライン教育の顧客もプログラマーであるため、ビジネス上の競合はなく、このトラフィック生成のアイデアも正しいです。

話題に戻りましょう。

それを見たとき、これは推薦システムではないのかと思いました。では、よく見てください。これは推奨システムですか?はい、確かに少し混乱しますね。

まず、私たちの本格的な推奨システムがどのようなものかを確認しましょう。例を挙げてみましょう。動画サイトで動画を視聴すると、その下にたくさんの動画がおすすめされます。これはユーザーの好みに基づいている場合もあれば、サイトユーザーのデータに基づいている場合もあります。いずれにしても、これは本格的なおすすめシステムです。Taobao で何かを購入して商品を閲覧すると、その下にたくさんのものがリストされます。これは本格的なおすすめシステムです。

それでは、シナリオに戻りましょう。私は IT テクノロジーのブログを閲覧しており、あなたは私にオンライン教育ビデオをいくつか勧めました。これは何ですか！

上記のシナリオと私たちのシナリオの間に何か違いに気づきましたか?はい、彼らが宣伝しているものはすべて同じカテゴリですが、私たちのものはまったく異なる 2 つのセットです。1 つは IT 技術ブログで、もう 1 つは IT オンライントレーニングビデオです。これらは異なる属性を持っています。

オンライン教育事業を営むBさんが「blogchongさん、弊社のオンライン教育チャンネルで動画をお勧めしたいのですが、フルセットでお願いします」と言ったとします。

そして、喜んで業界標準に従い、レコメンデーションシステムを迅速に開発します。その後、アルゴリズムを段階的に調整し、結果を最適化して、これから幸せな生活を送ります。

しかし、事実は目の前にあり、私たちはこのビジネスシナリオに向き合う必要があります。よく考えてみると、これは推奨システムであり、それほど真剣ではない推奨システムです。

そして、計画の設計、スタッフの組織化、プロジェクトの推進という任務が私に課されました。これは神の計らい、私への試練なのでしょうか？実際、それは組織から与えられた取り決めであり、私にとってのテストでした。突然涙が溢れてきました〜〜

よし、やってみよう！

（２）ただそれだけ

それまでもデータマイニングの分野については多少の知識はあったものの、推薦という点では基礎的な理論理解のレベルに留まっており、現部門では他に参考になるものもあまりありませんでした。

私はこのビジネスシナリオを調査し始めましたが、残念ながら、業界内には基本的に同様のビジネスシナリオが存在しないことがわかりました。はい、X を Y につなげるとは誰が考えたでしょうが、それが現実です。

それから、ブログとビデオのつながりが何なのかを分析し始めました。 2 つの属性リストを 1 つずつ整理してみると、実際には共通点があることがわかりました。たとえば、主に IT の方向であり、すべて中国語のタイトル、タグ、および詳細な中国語の説明である des が付いています。

はい、業界を参照することはできませんし、ユーザーの行動を参照することもできません (かなりコールドスタート)。そのため、2 つの間の唯一のつながりはトピックです。

ユーザーの行動に関係なく、同じトピックまたは類似のトピックのコンテンツを推奨することは間違いではありません。これは、推奨システムの一般的な方法の 1 つです。

それで、このアイデアに従って、デザインを始めました。当初は考え方が未熟な部分が多かったため、マッピングは比較的単純で、ブログのタグから直接動画を検索していました。

計画は実行に移され、後期の動画コンテンツの増加を考慮し、ブログタグを利用して検索エンジンで動画を集約し、おすすめリストが誕生しました。

プロダクトマネージャー C は、ブログ投稿を通じて推奨を行うだけでは不十分で、人気の動画も考慮する必要があると述べました。では、追加してみましょう。視聴回数上位 N 件の動画をおすすめリストに追加しました。

C 氏はまた、ブログ記事や最も人気のある動画を推奨するだけでは十分ではなく、ユーザーのことを考慮する必要があると述べました。そこで、バッチデータ処理が得意なD氏と私は、過去1か月間の社内のアクティブユーザー全員のブログ閲覧行動を実行しました。実際には、ユーザーがどのブログ投稿を読んで書いたかを調べ、すべてのブログ投稿タグをさまざまな読み書きの重みに従って並べ替え、上位Nをユーザーのコアスキルとして選択しました。さらに、ユーザーポートレートのスキルフィールドを定期的に更新するために、スケジュールセンターにスケジュールされたタスクを設定しました。

さて、ユーザーのタグができたので、残りのプロセスはブログ投稿と変わりません。

次に検討する必要があるのは、3 つの方法で取得したリストをどのように配布するかということです。推奨位置は少ないため、いくつかのグループに分けましょう。

するとCさんは、「自分たちの考えで決めよう」と言いました。それで、自分たちの考えで重み付けを決めました。

若すぎて騙されやすく、何も知らなかった自分を責めるしかないよ〜〜

まあ、とにかく、レコメンデーションシステムの最初のバージョンが正式にリリースされ (オフラインで評価することは不可能でした)、その後、BI チームの G 氏に、Web ページにいくつかのドットを配置して結果を収集するように依頼しました。

BI レポートが発表されましたが、その結果は明らかに不十分です。

（３）仕事は継続しなければならない

データ分析チームの E と一緒に行動履歴ログを追跡したところ、多くのブログ投稿と多くのユーザーには実際にはタグがまったくなく、その結果、ホットデータがプッシュされることが分かりました。言い換えれば、その多くは単に無関係です。

そこで、私はこの問題を解決することにしました。タグがない場合は作成します。推奨を行う際には、ブログ記事のタイトルに基づいて単語を分割し、ストップワードを削除し、分割した単語を動画集約用の一時的なタグに埋め込みました。また、直感に基づいて次の 3 つの方法の重みをわずかに調整しました。

結果は少し良くなりました。

F 氏はこのことを知り、より客観的なブログ投稿トピックを取得したいのであれば、ブログ投稿全体からトピックを抽出したらどうかと言いました。なるほど！

D 氏と私はトピック抽出の調査を開始し、最終的に 800G の新しいブログ投稿を再度実行し、データセンターに新しいキーワード説明フィールドを追加しました。お母さんはもう私のタグについて心配する必要はありません！

つまり、私たちの結果は少し良くなりました。

しばらくして、データ分析チームの G が分析を通じて、多くのビデオコースがブログ投稿とあまり関連性がないことに気付きました。それは違うと思います。抽出したタグワードの中には無関係な単語もいくつかありますが、基本的に該当するスキルのほとんどは比較的信頼できるものになっています。

次に、タグを使用してビデオコースを集約するプロセスを確認したところ、コースがあまり一致していないケースが確かにいくつかあることがわかりました。

その理由は、主語抽出ではほとんどの場合対応するスキル語を抽出できるものの、正確な重み付けランキングを実現することが難しく、弊社の検索エンジンのマッチングはより多くの単語をマッチングした結果となるため、重みが高くなるためです。

したがって、キーワードはプライマリーカテゴリーとセカンダリーカテゴリーに分ける必要があると思います。たとえば、hadoop、アプリケーション、開発という 3 つのキーワードがあります。したがって、Hadoop が実際に最も重要な単語であり、他の 2 つは二次的なものであると私は完全に信じています。

例えば、Hadoop ビデオコースを一致させたいのですが、現在の結果では「XX アプリケーション開発ビデオチュートリアル」が 1 位になるという結果になっています。もちろん、「Hadoop アプリケーション開発チュートリアル」を完全に理解できればさらに良いでしょう。

私とG姉妹は、オンラインビデオ教育の技術的なポイントを整理し始め、その技術的特徴を反映できると思われる単語を数百語からなるコア単語辞書にまとめました。

そのため、集計ロジックとしては、コアワードのヒットを優先し、次にセカンダリワードを考慮することになります。したがって、私たちの結果は少し良くなったようです。

その後、いくつかの小さな変更を加えましたが、結果の改善はますます小さくなっていることがわかりました。

この道を進み続けるなら、結果は同じになると思います。

この節目は、私とF氏との徹底的な議論の中で起こりました。

（4）マイルストーン

議論の中で、私たちは自分たちが正しい道を歩んでいるのかどうか深く考えました。トピックワードが十分に正確に抽出されていると仮定すると、すべての単語がビデオマッチングにどのように貢献しているかを十分に考慮したでしょうか?

では、動画属性のヒットに関しては、ヒット位置の一致度への寄与は同じかどうかを検討していますか？

動画に関連する中国語の説明に加えて、おすすめの提案に貢献できる他の属性はありませんか?

そこで、Dさんにはトピック抽出の精度を継続的に最適化するよう依頼する一方で、新たな設計案を考え、当初の計画を覆すことも行いました。

従来の協調的な推奨アプローチが機能しない場合は、ルールベースの重みモデルを使用します。長い間この方向で取り組んできたので、私たちは常にそこから学ぶ必要があります。

そこで、モデルに貢献する可能性のある属性をいくつかリストし、2 つのネストされたレイヤーを持つルール重み付けモデルを予備的に設計しました。数回のチーム会議を通じて、いくつかの属性が追加および削除され、モデルがわずかに変更されました。

説明する必要があるのは、ブログ記事とはまったく関係のない属性をビデオにたくさん追加したということです。私たちの目的は、これらの属性が多かれ少なかれ影響力を持つようにすることです。

そこで私は、動画の公開時間の無限に増加する値や、有料かどうかといったバイナリ属性など、同じ統計属性を数値化し、0～1の間で数値化することに着手しました。

定量化により、E シスターはデータを分析して、どの指標がクリックスルー率と正の相関があり、どの指標が相関していないかを判断できます。さらに、無関係な統計属性をいくつか削除しました。

当初は重み設計の参考にできるデータがなかったため、慎重に検討した結果、ネストされた 2 層ルールモデルに妥当と思われる重み比率を設計しました。

次に、初期データ選別段階で、各キーワードを使用してビデオの N 値を抽出し、最初に選別された N * M のビデオの中で、ルールモデルに従って N * M のビデオにスコアを付けます (これによりパフォーマンスが多少犠牲になりますが、このアイデアは部門の内部検索最適化プロジェクトの参考になります)。後は必要な数に応じてインターセプトするだけです。

説明する必要がある点の 1 つは、このシナリオでは、ログインしているユーザーと訪問者の比率が 1/60 であるため、常にユーザーに焦点を当てているわけではないということです。これについては詳しく説明しません。

もうひとつの飛躍は、AB 転換テストメカニズムを設計したことです。思い返せば、汗だくでした。これまでもいろんなバージョンがあったのに、一気にやっちゃった。あれはオンラインシステムだったんです。問題がなかった大きな理由は、新しいバージョンに十分な検討を注いだことです。

さて、現在はAB転用メカニズムにより、システムに大きな影響が出ないようにしつつ、コンバージョン率が低下しても許容できる範囲内で、トラフィックの1/4を新モデルに割り当てています。この四半期のトラフィックを過小評価しないでください。これは数百万のトラフィックです。

Gさんに事前に埋めてもらうように頼んでおいたので、待つ時間はかかりませんでした。翌日には結果が出ました。具体的な数字についてはここでは触れません。私たちは思い切ってすべてのトラフィックを新しいモデルに切り替えました。

それ以降、私たちの仕事は、重量比をいかに効果的に最適化するかということに焦点を当てています。私はE姉妹とこの件について話し合い、最終的に彼女の機転で納得しました。

E姉さんは、データの傾向に基づいて体重の値を予測していると言っていました。これはロジスティック回帰ではないのですか？ロジスティック回帰のパラメータを計算することとどう違うのですか？いいえ、違いはあります。違いは、正のパラメータが必要であるということです。

まあ、これは単なる小説なので、続編についてはあまり語りません。

その後、私たちは別の考えもしました。たとえば、技術は高、中、低の 3 つのレベルに分けるべきだと考えました。ブログ記事に反映されている技術レベルが初歩的なものであれば、それに対応する中級レベルの技術ビデオを適切に推奨すべきでしょうか。

たとえば、テクノロジーは互いに関連しています。誰かが Hadoop に関するブログ投稿を読んだ場合、その人に Spark に関するビデオコースを勧めることができますか?この関係をどのように抽出するのでしょうか?

私はテクノロジーやその他のことについて詳しく説明しません。

（5）象徴的な要約をしましょう

それは本当に要約とは考えられません。しかし、何があっても、いくつかの見解はまだ意味があると思います。

まず、私たちは慣れていない領域で決定的に行動する必要があります。

第二に、新しいアルゴリズムの改善、さらにはその他の改善、またはその他のプロジェクトを行うときは、慎重に考え、計画を立ててから実装する必要があります。これはまた、ABテストメカニズムが発表される前に「勇敢に」製品を数え切れないほど発売し、問題なくオンラインバージョンをカバーし、効果が低下しなかった直接的な理由でもあります。

推奨システムの設計に関して、私が言いたいのは、主な矛盾を解決する必要があるということです。プロジェクトの実践のために、すべての取り組みは、ブログチャネルからオンライン教育チャネルへのトラフィックの変換率を高めることを目的としています。

ロングテールを活用しようとすることで、私たちはそれを試しました。また、私たちは推奨事項の多様性を提示しようとしましたが、これは私たちの目標ではなく、盲目的に多様性を高めるのではなく、最も適切な場所ではありません。前にも言ったように、あなたにもっとお金をもたらすことができる推奨システムは、良い推奨システムであり、誰が残りを気にしているのか！

推奨システムに関する別の提案は、特定のフォームに固執する必要がないことです。多くの解決策があり、何も不可能ではありません。試してみるだけで、結果がわかります。

プロジェクトのプロモーターおよびオーガナイザーとして、あらゆる側面から人々を自分の立場に導き、あらゆる側面の進歩をタイムリーに調整するなど、より多くの責任を引き受ける必要があります。これは非常に重要です。

チームの力は非常に強力です。

他の人とより頻繁に話し合い、コミュニケーションをとることができます。別の山からの石は、ジェイドを磨くために使用できます。

3。話題から、私の友達はどこにいますか？

私が注意深くそれについて考えるとき、ほぼ1年が一瞬で過ぎました。推奨システムプロジェクトはしばらく保留されており、私は他のプロジェクトで忙しいです。

タイムは、F氏を去ってから長い間、それを慎重に考えています。

D氏はF氏の直後に去りましたが、どちらも特定のテレビ局のデータクラウド部門に行ったと言われています。 D氏は現実的で勤勉な人であるため、彼と仲良くするのは楽しいです。

少し前に、シスターEも会社を去りました。私はまだE-Meiの素早い考えに深く感銘を受けました。

私は悲しみを感じ、去るのにとても恋しいです。

私は彼らが彼らの新しい会社でより幸せに生き、より多くのお金を稼ぐことを願っています。

この時点で、私は彼らがプログラマー、デザイナー、製品犬であろうと、動物園のすべての動物を望みます。連絡を取り続けて、時々テクノロジーについてチャットし、時々オリンピックの森林公園に行って3つの王国を一緒にプレイしてください、ハハ~~