アルゴリズム エンジニアはなぜ一日中データを扱うのでしょうか。また、どのような種類のデータを扱うのでしょうか。

[[353273]]

なぜ私たちはモデルをほとんど作らないのでしょうか?

アルゴリズムエンジニアの仕事は、おそらく誰もが想像する通り、今日論文を読み、明日それを実装し、明後日にはオンラインに公開することでしょう。そうすれば、会社の収益は急速に増加し、それに応じて私たちの給料とレベルも上がります。しかし、現実には、ほとんどのエンジニアの日常生活ではそうではありません。ある有名な外国人（名前は忘れました）が、アルゴリズムエンジニアは時間の 70% をデータに費やし、モデルとパラメータの調整に 20% 未満しか費やしていないと言っていました。

誰もがこの文章を多かれ少なかれ聞いたことがあるかもしれませんが、おそらく完全に理解しているわけではないでしょう。なぜでしょうか?モデルの作成にもっと時間を費やしてみませんか?理由は簡単です。やりたくないのではなく、できないのです。

これが機能しない理由は多数ありますが、ここでは最も一般的な理由をいくつか挙げます。

フレームワークの制限

モデルを自由に移動できない理由は多数ありますが、一般的に最も一般的な理由はフレームワークの制限です。この状況は、大企業でも小企業でも存在します。例えば、私が大企業にいた頃は、会社のフレームワークが非常に成熟していたため、モデルを実装するために書かれたコードはほとんどなく、ビジュアルインターフェースの接続や操作の設定に重点を置いていました。ここで問題が発生します。このシナリオでは、視覚化インターフェースで選択可能なモデルは固定されており、すべて基本チームによって開発されています。彼らは非常に多くのモデルを開発しており、プロセス全体から離脱しない限り、使用できるモデルは限られていますが、これは明らかに不可能です。

そのため、長い間、限られた数のモデルからしか選択できませんでした。その後、同社は、独自のニューラル ネットワーク コードをカスタマイズしてディープ モデルを実装できる新しいフレームワーク ツールを開発しました。これが包括的なアップグレードの始まりでした。

中小企業は、大企業のように成熟した変更が難しいフレームワークを持っていませんが、一般的に独自のプロセスセットを持っています。たとえば、同社の先人たちが残したリンクがオープンソースの xgboost をベースに開発されており、元の xgboost ではなく TensorFlow を使用してニューラル ネットワーク モデルをトレーニングしたい場合、一般的に言えば、これは間違いなく効果的であり、確実に改善をもたらします。しかし問題は、モデルのトレーニングとオンラインでのモデルの呼び出しのリンク全体を再構築する必要がある場合があることです。多くのアルゴリズムエンジニアは開発能力が強くなく、エンジニアリング再構築を行う意欲がありません。また、作業量も少なくないため、誰もがより良い方法を知っていることは明らかですが、投資額が高いため、誰もやる気がなく、作業は遅れ続けます。

効果を保証することは難しい

2 つ目の理由は、一部のモデルや実践の有効性を紙の上では実際に保証することが難しいことです。論文を読んでみると、論文の結論には多くの前提が含まれていることがよくあることに気づくでしょう。たとえば、特定のデータやシナリオ、初期段階での強力なリコールおよびフィルタリング システム、完全な機能の準備などです。この論文ではこれらすべてを列挙するのではなく、方法と結果のみを列挙します。この結果、論文では素晴らしいように思える多くの方法が、実際の適用ではあまり効果的ではない可能性があるという事実につながります。

これは新聞の自慢ではありませんが、あなた方は同じ条件を満たしていません。たとえば、Alibaba のデータ収集は非常に正確で、アプリを開いてから閉じるまでのユーザーのすべてのアクションと動作が記録されるだけでなく、各製品またはモジュールがユーザーに表示される時間、さらにはユーザーがページをめくる速度までも記録されます。この種のデータでは、中規模の中小企業では到底対応できません。このデータを取得できない場合は、論文に正確な特徴を記載できません。それでは、Alibaba のモデルを使用して同じ効果を確実に得るにはどうすればよいでしょうか?

優先課題

私たちは皆、物事は緊急性と重要性に応じて、重要ではないが緊急ではない、緊急だが重要ではない、緊急だが重要である、そして重要だが緊急ではないという 4 つのカテゴリに分類できることを知っています。最も重要なことは、重要かつ緊急でないことをきちんと行うことだということを、多くの人は知っています。誰もがこう言うでしょうが、実際には誰もがこれを選択するわけではありません。

KPI評価のプレッシャーに直面している場合、最前線のエンジニアは緊急の事項にしか集中できない可能性があります。パフォーマンス目標を達成するには、すぐに何らかの結果を達成する必要があるため、パフォーマンス目標を達成する最善の方法は、モデルをアップグレードまたは更新することではなく、取り組むべき機能を見つけたり、いくつかのトリックを使用して効果を改善できるかどうかを確認することです。モデルの更新に時間をかけるのは労力がかかり、必ずしも結果が得られるとは限りません。ただし、機能を作成するコストは非常に小さいです。 1 つの機能が機能しない場合は、別の機能を作成でき、反復も高速です。

これはエンジニアの近視眼だけによるものではなく、職場全体の雰囲気の影響による結果でもあります。誰もがパフォーマンスと結果を重視しているため、誰もが局所的な最適解にとらわれ、全体的な最適解からどんどん遠ざかっています。

この状況を回避するには、計画を調整し、モデルのアップグレードに伴うリスクのプレッシャーに耐えることができる、先見の明のある設計者またはリーダーが必要です。起こりうる状況と将来の対応について十分かつ詳細な計画を立て、さまざまな起こりうる状況に対処できる十分な経験を持っていること。しかし、職場でこのような能力を持ったリーダーが稀であることは誰もが知っています。大企業では稀であり、中小企業ではさらに稀です。

どのようなデータを扱うか

モデルの問題について議論したところで、データについて話しましょう。モデルは頻繁に変更できないため、エンジニアはデータに集中するしかありません。では、エンジニアがこれほど多くの時間を費やしているデータは何でしょうか?

トレーニングデータ

大企業には完全なプロセスがあります。プロセスを設計したら、トレーニングデータ、テストデータ、モデルのトレーニングと展開をワンストップの組立ラインで実行できます。しかし、中小企業ではこれが不可能な場合がよくあります。

元のデータを直接使用してモデルをトレーニングすることはできないため、複雑な処理フローが必要になります。まず、サンプリングが必要です。 CTR 推定シナリオを例に挙げます。一般的に、実際のシナリオでのクリックスルー率は 10% を超えることはありません。ただし、モデルのトレーニングにおける正のサンプルと負のサンプルの比率は通常 1:3 程度なので、負のサンプルをサンプリングする必要があります。

サンプルには汚れたデータや違法なデータが大量に含まれている可能性があるため、サンプルを直接採取することはできません。データがクリーンであることを確認するために、サンプリングの前にこれらの問題のあるデータを除外する必要があります。サンプリング後、機能とフィールドを検索して完了する必要があります。データは別々に保存されることが多いため、例えばユーザーの基本情報はテーブル、ユーザーの行動データは別のテーブル、商品情報はテーブルというように、さまざまな種類のデータがさまざまな場所に保存されます。サンプルを入手した後も、必要なすべてのフィールドを収集するために大量のデータを見つける必要があります。

必要なデータをすべて収集したら、実際のサンプルの作成、つまり、見つけて収集した生データを使用して入力モデルのサンプル機能の生成を開始できます。各機能には独自の生成ロジックがある可能性があり、これも大規模なプロジェクトです。このステップはまだ終了していません。データをモデルに必要な形式に変換する必要があります。たとえば、tfdata、tensor、json など。

このような一連の手順については、大企業では通常、完全な自動スケジューリング プロセスが用意されています。エンジニアはそれについて心配する必要はなく、それを使用するだけで済みます。ただし、中小企業では手動ツールしかなく、一部のタスクやスクリプトを実行するには必要なデータを手動で実行する必要がある場合もあります。実行プロセス中に障害が発生したり、さまざまな問題に遭遇したりする可能性があります。目立たず、あまり価値がないように聞こえますが、これらはすべて作業が必要です。

新機能

機能を作るには？ Kaggle のようなコンテストでは、pandas を使用して 2 つの関数を記述するか、数行の処理ロジックを記述するだけで完了する場合があります。しかし、現実はそれほど単純ではありません。

簡単な例を挙げてみましょう。たとえば、年齢を正規化して、標準化された年齢の特徴にします。これは簡単です。より単純な最大値と最小値の正規化方法を使用しましょう。式は次のとおりです。

アルゴリズム エンジニアはなぜ一日中データを扱うのでしょうか。また、どのような種類のデータを扱うのでしょうか。

正規化後、この固有値は 0 ～ 1 の範囲にスケーリングされます。ただし、ここで使用されるパラメーターは 2 つあり、1 つは最大値で、もう 1 つは最小値です。これら 2 つのパラメータはどのようにして得られるのでしょうか?これは簡単だと思うかもしれませんが、データを走査すればわかります。しかし、問題は、このデータを一度だけ使用しないということです。トレーニング データを生成するたびに、この機能を生成する必要があります。実行するたびに、手動でデータを走査して最大値と最小値を見つける必要がありますか?さらに、データは変化しています。ユーザーの最大年齢と最小年齢は毎日異なる場合があります。トレーニング データを数日間実行する必要がある場合はどうすればよいでしょうか。

新しい機能の設計は簡単ですが、その中のいくつかのパラメータによって物事が複雑になります。新しく完成した機能をプロセスに追加するには、複雑なメカニズムを設計する必要があることがよくあります。

効果分析

データ処理のもう一つの大きな部分は効果分析です。効果分析には2つの種類があります。1つ目は、以前は存在しなかったいくつかの指標と関連分析を行うこと、または上司の要請に応じて業績を達成するためにいくつかのビジネス指標分析を行うことです。

例えば、CTR、CVR、収益などといった最も基本的なデータもあれば、上司が気まぐれに見たいデータもあります。たとえば、特定の特徴の分布を分析したり、特定の集団内のサンプル数やデータの数を確認したりします。

2 つ目のタイプは、モデルを構築した後にその効果を分析することです。モデルが効果的であれば、それで問題ありません。効果が良くない場合、どこに問題があるのか​​をどうやって判断するのかという疑問が生じます。モデル自体の性能が足りないからでしょうか？それとも、機能が不十分なのか、機能に問題があるのでしょうか?それとも、データの質が高くないのでしょうか?それともどこかにバグがあるのでしょうか?

アルゴリズムは、ほとんどのことが確実なエンジニアリングとは異なります。結果が間違っている場合は、ロジックにバグがあるためです。慎重にテストして原因を分析すれば、必ず解決策を見つけることができます。再現が難しく、原因が不明な問題は非常にまれです。しかし、アルゴリズムは異なります。ほとんどの場合、絶対的な間違いや正しいこと、あるいは絶対的な理由さえ存在しません。私たちが果たす役割は探偵のようなものです。いくつかの手がかりに基づいて問題の原因を推測し、実験を通じて解決しようとします。このプロセスには、大量のデータ処理と分析が含まれます。

たとえば、モデルのパフォーマンスが低い原因が特定の機能の分布の問題であると思われる場合は、その機能の分布を分析する必要があります。データにバグがあると思われる場合は、計画を立て、データをフィルタリングし、データ内の問題を慎重に特定し、アイデアを検証する必要があります。トレーニングデータの量が十分でないと思われる場合は、トレーニングの量を増やして比較実験を設計する必要があります...つまり、トラブルシューティングには多くのデータ分析が必要であり、コードを見て考えるだけでは結論に達するのに十分ではありません。

考え

アルゴリズムに取り組みたいと考えている人の多くは、実際に取り組んでみると幻滅感を覚えることがよくあります。面接は航空母艦を建造するようなもので、仕事はネジを締めるようなものだという強い思いが湧いてくるでしょう。理由は非常に単純です。面接ではさまざまなモデルや高度な概念や手法について質問しますが、入社後に直面する業務はさまざまなデータ分析やデータ準備です。例えば、私はほとんどの時間をSQLを書いてデータを扱うことに費やしており、会社の仕事の取り決めに疑問を抱いたことがありました。

しかし、それがどのように機能するかを理解すると、私はそれを理解しました。実際の作業シナリオはオンラインアルゴリズム競技とは異なります。オンライン競技では、さまざまなトリックを使用してパフォーマンスを向上させることができます。さまざまなクロスボーダーミックスも可能です。たとえば、今年のTencentアルゴリズムコンテストの優勝者は、ユーザー行動分析のシナリオにBERTを適用しました。しかし、実際のシナリオでは、システムやさまざまな制約により、これらのアイデアを実現することは難しく、結果を保証することも困難です。最終的には、基本的なデータサポートに基づいて実装する必要があります。

不正確な例えですが、さまざまなアルゴリズム モデルはツールボックス内のさまざまなツールのようなものです。ツールだけを理解しても意味がありません。最も重要なことは、ツールが使用されるコンテキストを理解して、ニーズに最も適したツールを選択できるようにすることです。しかし残念ながら、データやシナリオの理解を定量化することは難しいため、面接ではツー​​ルの使用状況についてしか質問できません。長い目で見れば、多くの人が本末転倒でコア競争力を間違えているため、面接についてさまざまな批判があるのも不思議ではありません。