なぜ「ハイエンド」アルゴリズムエンジニアはデータ移民労働者になったのでしょうか?

なぜ「ハイエンド」アルゴリズムエンジニアはデータ移民労働者になったのでしょうか?

まず、Zhihu の「アルゴリズム エンジニアになるのはどんな感じか」という質問に対する私の回答を共有します (このアイデアはオリジナルではなく、シンガポールの大学の定量投資コースの PPT からコピーしたものです)

[[145905]]

理想的なアルゴリズム エンジニア: 仮説を提案 -> データを収集 -> モデルをトレーニング -> 結果を説明する。
実際のアルゴリズム エンジニアは、仮説を提案 -> データを収集 -> 前処理 -> 前処理 -> モデルのトレーニング -> デバッグ -> デバッグ -> 再度データを収集 -> 前処理 -> さらにデータを収集 -> デバッグ -> デバッグ -> デバッグ -> … -> 諦めます。

この回答は数十件の「いいね!」を獲得し、24件の回答のうち2位にランクインしており、ある程度の普遍性があることを示しています。最初の投稿には 100 件以上のいいねが付いており、彼の見解は「毎日最も重要なことはデータを実行することです!」です。

これは冗談ではなく事実です。なぜ「高尚な」アルゴリズム エンジニアは実際にはデータ出稼ぎ労働者なのでしょうか。理想と現実のギャップの理由を見つけるには、まず 1 つの事実を理解する必要があります。データを理解できるのは人間だけであり、機械には理解できないということです。

LR、SVM、k-means、EM など、どのような機械学習アルゴリズムを使用する場合でも、入力データは一連の浮動小数点数で構成された行列です (より根本的に言えば、単なる 01 シーケンスの集まりです)。 「時間」という特徴があり、それが 25 回出現した場合、通常の IQ を持つ人間であれば、これが間違いであることを理解し、データ クリーニング中にそのようなデータを除外できます。しかし、機械はこれを理解できません。時間の概念を持ち、時間とはどのようなものか、1 日には何時間あるかを理解する必要があります... 機械はどのようにしてこのようなデータ クリーニング作業を自動的に完了できるのでしょうか?さらに、「時間」機能のデータのほとんどが 0 から 12 で、少量の 13 が混ざっている (ただし、13 の数は外れ値として除外できないほど小さいわけではない) ことがわかった場合、人々は 12 時間制が使用されており、13 は間違いであると疑うでしょう。現時点では、マシンはこれを実行できません。

人間の肉体の特徴について話しましょう。 1 つは特徴変換です。たとえば、特徴は 2 つのデータ列の比率である場合があります。このような分割は線形モデルではカバーできません。もちろん、モデルの仮説空間を増やすことはできますが、仮説空間が小さすぎると必要な変換をカバーできず、仮説空間が大きすぎると簡単に過剰適合してしまいます。もう 1 つは機能を追加することです。たとえば、クリックスルー率は画面解像度に関係していると思います。そこで、機能に追加するための画面解像度データを探しに行きましたが、それが入手できない場合は、それを収集する方法を見つける必要がありました。これらのマシンのどれもそれを実行できません。

しかし、人間がデータを準備したら、機械学習アルゴリズムが活躍する時が来ます。しかし、ソフトウェアはほぼ無償でコピーできるという特性があるため、アルゴリズムエンジニアの主な仕事はここにはありません。 LR を実装した人が世界中に一人でもいれば (知的財産権の問題はここでは考慮されません。オープンソース ソフトウェアがたくさんあることは言うまでもありません)、LR を必要とする他の人は誰でもそれを使用できます。どうやら、アルゴリズムエンジニアがまさにそれをやったようです。

しかし、アルゴリズムが結果を出力した後は、その結果をどのように活用して実際の問題を説明し、ビジネスに適用するかという人間の作業が再び必要になります。明らかに、このプロセスは、以前のデータクリーニングや人間の特徴分析に似ています。これらは、人間だけが実行でき、機械では実行できないタスクです。

数学的モデリングを行ったことがある学生は、問題を数学的な問題として記述し、その結果を実際の問題に適用するプロセスに精通している可能性があります。これは、バックボーン ネットワークの光ファイバー構造は非常に強力であるものの、エンド ユーザーのアクセスが面倒になるという、通信における「ラスト マイル」問題に似ています。機械学習の応用問題の場合、アルゴリズムと対応するソフトウェア パッケージは、バックボーン ネットワークのように標準化され、汎用的ですが、データに「アクセス」する方法は人間だけが実行できます。データを理解できるのは人間だけだからです。

テクノロジーと技術者

この問題はコンピュータ分野全体に広がる可能性があります。アルゴリズム エンジニアをプログラマーに、機械学習アルゴリズムをソフトウェアに置き換えると、次のようになります。ほとんどのプログラマーは、一般的なコンピューター ツールと特定の実用的なビジネスとの間の「ラスト マイル」アクセスの問題を解決します。

なぜそう言うのでしょうか? まず歴史を見てみましょう。コンピューター技術は何十年にもわたって発展し、プログラマーの参入障壁は徐々に下がってきました。最初のプログラムはベアメタル上でアセンブリ言語で記述する必要がありました。その後、Unix と C 言語の登場により、少なくともプログラマーはプロセスを自分でスケジュールする必要がなくなりました。 Java の登場以降、メモリについて心配する必要さえなくなりました。世界最高峰のPHPの登場以降、ネットワークプログラミングの敷居はさらに下がり、誰でも短時間でWebサイトを構築できるようになりました。

元々の問題はどこに行ったのでしょうか?これは、オペレーティング システム、コンパイラ、仮想マシン、ランタイム環境、フレームワークなどを作成した少数のプログラマーによって「車輪の再発明」によって解決されました。この傾向は続いており、Rust や Golang などの新興言語は、マルチコア時代に生じる並行性の問題を解決しようとし、Hadoop、Spark、Mesos は分散システムの基盤となる詳細を隠そうとしています。今後、並列プログラミングと分散プログラミングの敷居は大幅に下がることが予想されます。技術の開発は、より多くの人々がより便利に使用できるようにするためであるため、このプロセスは避けられません。

コンピュータは人間の言語を理解できないため、これらのコンピュータツールをビジネスに直接適用することはできません。そのため、人間の言語をコンピュータ言語に「翻訳」するプログラマーが多数存在します。これらのプログラマーは「ホイール」を使用します。もちろん、これは白か黒かということではありません。ソフトウェアがどの程度ホイールと呼べるかは、その再利用性によって決まります。コードが 1 か所でしか使用できない場合は、明らかにホイールとは言えません。実際のところ、特定のビジネス ロジック用に記述されたコードのほとんどは、再利用度が低いです。

一般的なコンピュータ ツールを特定のビジネスに適用する場合、本質的に技術的な問題はどれくらいありますか?技術的な問題のほとんどは、オペレーティング システム、コンパイラ、仮想マシンによって解決されます。残っているのは主に、大規模なソフトウェア (大規模なソフトウェアの場合) の複雑さの制御です。この問題は、主に少数の高レベルのアーキテクトの責任です。実際のコードを書くプログラマーにとって、技術的な困難はほとんど残っていません。

私が働いていた会社を例に挙げてみましょう。その会社はインターネット会社で、ウェブサイト全体のコードの 99% は PHP で、基本的に Java はありませんでした。専任のフロントエンドエンジニアはおらず、PHP、HTML、JavaScript のコードが混在しています。テストはほとんど行われず、ほとんどのテストは開発者自身によって行われます。リリースプロセスは単なる形式的なものです。品質管理部門の役割は、コードをサーバーに同期し、事故が発生した後に開発者に責任を割り当てることだけです。以前、別の部門で働いていたとき、私が提供したインターフェースを呼び出しましたが、私のインターフェースがオンラインになる前にオンラインになり、事故が発生しました。私はもともとアルゴリズム エンジニアで、PHP を書くのはゲスト ロールにすぎませんでした。このプロセス中、オンラインの依存関係を制御することはできず、プロンプトさえ表示されず、オンライン プロセスについてトレーニングしてくれる人もいませんでした。しかし、同社は10年以上にわたり発展を続け、その市場セグメントでトップシェアを占め、すでに株式を公開している中規模のインターネット企業です。

この例を挙げたのは、それを否定するためではなく、上記の点を事実で裏付けるためです。ほとんどのプログラマーと、いわゆる「テクノロジー」企業のほとんどが直面する技術的な問題は、想像されているよりもはるかに少ないのです (これが、その企業に CTO がいない理由かもしれません)。

これは孤立したケースではなく、ほとんどの企業が同様の問題を抱えています。技術的な観点から見ると、これは非常にひどい問題であり、なぜいまだに解決されていないのかと驚くでしょう。しかし、実際には、死んでいないどころか、健在であり、市場に上場さえされています。会社のオーナーたちは、美人でお金持ちで可愛い女の子と結婚するという夢をずっと実現してきたが、彼らを侮辱したプログラマーたちは、いまだに住宅ローンや頭金の支払いに苦労している。いずれもテクノロジー企業を名乗っていますが、ここでは技術的ではない要素が重要な役割を果たしています。

テクノロジーの限界を認識する人が増えています。今年の初め、クラスメートの一人が就職活動をしていました。彼はずっと「純粋な技術系」エンジニアでした。彼は優れた技術ブログをいくつか書いていて、オープンソース プロジェクトを立ち上げたこともありました。しかし、今回は「もう低レベルのエンジニアにはなりたくない」と言い、「プロジェクト全体を見渡せるような高レベルの仕事」や「人と接し、自分のアイデアを世に広め、価値を創造する」仕事に就きたいと考えている。そこで、彼は数人の弟たちを率いるために会社に行きました。このことを別のクラスメイトに伝えると、「私も最近同じことを考えていた」という返事が返ってきました。別のクラスメートは、数年間 C++ を書いていたが、技術的なことはあまり学ばず、代わりにビジネスに関する知識を多く身につけたと話していました。たとえば、数学の博士号を持っていた私の前のリーダーは、かつてはアルゴリズムに対してほとんどナイーブな信念を持っていましたが、私が去る頃には、ビジネスと製品志向の人物に完全に変貌していました。しかし、数年前からテクノロジーを軽視し始め、パーティーでは「ソフトパワー」についてよく話していた同級生は、すでに BAT のチームリーダーになり、快適な生活を送り、一日中ランニングを楽しんでいます。なぜ?理由は実は非常に単純です。会社には解決すべき技術的な問題がそれほど多くないからです。

「Code Complete」には比喩があります。犬のために小さな巣を作るのが問題なら、とにかくやってみてください。何かがうまくいかなくても、最悪の場合、やり直しになるだけで、せいぜい午後を無駄にするだけです。超高層ビルを建てるのは違います。では、「ドッグハウス」レベルのプログラムを書く場合、アルゴリズム、データ構造、デザイン パターンの意味は何でしょうか? DRY 原則に違反していても問題ありません。いずれにしても、コードは 1 回以上コピーすることはできません。バグがある場合は修正するだけです。せいぜい 1 回書き直すだけで、午後 1 日を無駄にすることになるでしょう。さらに、プロジェクトは2週間以内にキャンセルされる可能性があります。あなたの仕事が犬小屋を建てることなら、たとえ超高層ビルを建てる技術を持っていたとしても、その技術とドラゴンを倒す技術との間に何の違いがあるのでしょうか?唯一の「メリット」は、上司にさらなる昇給を要求し、上司があなたを見る目が変わることです。

プログラマーは、テクノロジーに関する非現実的な幻想を捨て去るべきです。これは、テクノロジーが重要ではないという意味ではなく、犬小屋を建てる仕事、普通の建物を建てる仕事、高層ビルを建てる仕事を現実的に区別すべきだという意味です。

もう一度アルゴリズムについて話しましょう

同様に、アルゴリズム エンジニアは、アルゴリズムに関する非現実的な幻想を捨て、データの理解、クリーニング、前処理、人間の特徴、ビジネス アプリケーション (敗者や惨めななどの形容詞と関連付けられることが多い) に重点を置く必要があります。

今後、機械学習ツールはより標準化され、プラットフォームベースで、汎用的になり、利用の敷居はさらに下がるでしょう。データ保存方法、勾配降下法、並列化、分散コンピューティングなど、アルゴリズムの本質とは無関係なエンジニアリングの詳細は、「車輪」を作るプログラマーによってブロックされます。アルゴリズム エンジニアは、モデルのトレーニング、相互検証、パラメータの最適化などのタスクを完了するために、Hive のような方法を使用し、いくつかの SQL のようなステートメントを記述するだけで済む場合があります。

機械が置き換えることのできない唯一のものはデータの理解であり、それがアルゴリズム エンジニアの価値です。データはビジネスと密接に関連しており、アルゴリズム エンジニアはプログラマーよりもプロダクト マネージャーの役​​割に近いものになります。データ、ビジネス、製品に対する深い理解、そしてモデルとその交差点を見つけることが、アルゴリズム エンジニアのコア競争力になります。

ちなみに、この記事の見解と比較すると、Deep Learning はある程度例外です。特徴エンジニアリング、つまり人間の代わりにある程度特徴を抽出するという問題を解決しようとします。もちろん、これはまだ比較的初歩的なものであり、せいぜい特徴変換の問題しか解決できず、データのクリーニングや前処理でドメイン知識が必要な状況には対応できません。

ここで劉氏は、アルゴリズムエンジニアはアルゴリズムをどの程度理解する必要があるのか​​、という疑問を提起しました。実際のところ、エンジニアはアルゴリズムの適用から始めても、モデルの長所と短所、適用可能なシナリオ、モデルの選択、パラメータの調整などの技術を習得する必要があります。これに疑いの余地はありません。この観点から見ると、アルゴリズム エンジニアには、プロダクト マネージャーとは異なる特定の技術的能力が必要です。

しかし、これにより別の疑問が生じます。モデル選択とパラメータ調整の手法は普遍的なものなのでしょうか?それとも特定のデータと深く関連しているのでしょうか?たとえば、同じチューニング技術が(たとえば)電子商取引データではうまく機能するが、ソーシャルデータでは失敗する、といった現象はあるのでしょうか?この質問に対する答えはまだありません。もし知っている人がいたら教えてください。しかし、機械学習モデルに関連するプロジェクトを改善する際、基本的に試行錯誤のアプローチを採用しているという現象があります。つまり、最初に変更を加えてから、それをオンラインにして効果を観察し、良くない場合は別の方法を試します。効果が向上しても、その理由がわからないことがよくあります。モデルの品質を判断するための普遍的な手法があるのなら、なぜ私たちは依然としてこのほぼ徹底的なアプローチを取らなければならないのでしょうか?

「ITエリート」から「IT移民労働者」や「コードファーマー」への称号の変化は冗談ではなく、コンピュータプログラミングの分野における敷居が徐々に下がっていることを真に反映している。したがって、高尚な響きを持つ「アルゴリズムエンジニア」や「データサイエンティスト」には、「データ出稼ぎ労働者」「機械農家」「ニンニク農家」など、似たようなニックネームを付けるべきである。そうすれば、真実を知らない子供たちが「高尚な」肩書きに惹かれて道を踏み外すことがなくなる。

他の

私は比較的純粋な技術者であると思われるかもしれません。なぜなら、非技術的な事柄について十分な知識がなく、それが何であるかを言うことができないからです。それらを「その他」という言葉でまとめることしかできません。

ここでの「その他」とは、基本的には「人」の問題です。たとえば、前述の「自分のアイデアをどのように宣伝するか」や「ソフトパワー」など、機会のような大きなものから「電子メールのコピーを誰に送るべきか」のような小さな詳細まで多岐にわたります。

もちろん、テクノロジーそのものに興味がある人にとっては、テクノロジーそのものは手段ではなく目的であるため、これらの議論は当てはまりません。ここでの視点は、あくまでも社会全体の意味でのキャリア開発の視点です。社内で昇進したい場合でも、転職して昇進したい場合でも、人生の目標を達成するために自分のビジネスを始めたい場合でも、テクノロジーはスキルの 1 つにすぎません。ほとんどの企業が「犬小屋建設」レベルのポジションを提供しているという事実を考えると、このスキルはどの程度の役割を果たすのでしょうか?

しかし、プログラマーに「テクノロジーに興味を持つこと」や「余暇の楽しみとしてコードを書く」ことを要求するのはまったくばかげていると付け加えなければなりません。想像してみてください。営業職の採用時に、求職者に「お酒を飲んだり社交したりすることに興味がある」と尋ねる人は誰もいません。金融職の採用時に、「数字の足し算や引き算に興味がある」と尋ねる人は誰もいません。外科医の採用時に、「趣味で人体を解剖すること」を尋ねる人は誰もいません。なぜプログラマーという職業は特別なのでしょうか?

その理由はおそらく、誰もが依然としてテクノロジーに対する不合理な崇拝に浸っているからでしょう (もちろん、崇拝と冒涜はしばしば共存します)。よく「テクノロジーは世界を変える」という言葉が使われます。この発言は正しいが、「テクノロジーが世界を変える」ということは、「あらゆるテクノロジーが世界を変えることができる」ということではなく、「あらゆる技術者が世界を変えることができる」ということでもないことを理解しなければならない。実際、プログラマーであることは、専門的なスキルを必要とする他の業界と何ら変わりありません。それは単に生計を立てるための手段にすぎません。

いわゆる「テクノロジー企業」のほとんどは本当のテクノロジー企業ではなく、せいぜい「テクノロジーを利用する企業」です。実際、金融分野では、IT に対する要求ははるかに高くなっています。大手銀行にも独自のソフトウェア開発部門がありますが、誰もそれを IT 業界の一部として分類せず、むしろ金融業界の一部として分類しています。しかし、お店やレストランを開いたり、家を売ったり、仲人をしたり、資金調達をしたりする人は、ウェブサイトを作れば「テクノロジー企業」になるようです。これはおかしくありませんか? (もちろん、書店として始まり、後にクラウドコンピューティング、推奨システム、無人航空機などの技術革新に取り組んだAmazonのような企業は、このリストには含まれていません。)これらの企業において、テクノロジーはどの程度の役割を果たしているのでしょうか?

おそらく、かなりの数のプログラマーが、テクノロジーを非常に重要だと考えています。彼らはテクノロジーへの憧れと信念に浸り、技術力を向上させることで、より高い地位を獲得し、人生の頂点に到達できると心の底で固く信じています。しかし、ほとんどの場合、これは単なる自己欺瞞的な幻想です。中国のプログラマーは矛盾した考え方を持っています。一方では、彼らは自分たちを「出稼ぎ労働者」と呼び、プログラミングは30歳以下の若者にのみ適した肉体労働であると考えています。他方では、彼らは技術を非常に重視しており、暇なときには技術について語ったり、他のプログラマーが使用している技術を攻撃したりすることを楽しんでいます。彼らがテクノロジーにそれほど執着するのは、テクノロジーが大好きだからではなく、テクノロジーしか知らないからだ。誰も他人の前で自分の弱点を見せたくはありません。技術の地位が上がるほど、技術の重要性が増す一方で、対人コミュニケーション、自分のアイデアの推進、製品マネージャーとの要件の議論などの能力の低さは重要ではないようです。

これは人間の本質の弱点です。自分の能力に盲目的かつ過度に自信を持ち、それを自分の精神的な支柱とさえ考えてしまうのです。もしかしたら彼は本当にこれが得意なのかもしれないが、彼の自己評価は実際の状況よりも高い。確かに、自信は必要であり、人間の生存と発展のための精神的な基盤の 1 つです。しかし、自信は諸刃の剣です。非現実的な自信(傲慢と呼ぶべきかもしれません)は人々の目をくらませ、事実を歪めてしまいます。

それで私たちは何をすべきでしょうか?第一の悲観的な点は、技術的に「犬小屋建設」レベルの仕事に従事している場合、残念ながら、技術レベルを向上させても社内でのキャリア開発には役立たない可能性があるということです。

テクノロジーに本当に興味がある人であれば、「ハッカーと画家」に出てくる「本物のプログラマー」のようなタイプの仕事方法を検討することができます。つまり、彼らは生きていくためだけに「日中の仕事」を探し、余暇に「本当に価値のある」コードを書きます。

残念ながら、ほとんどのプログラマーはテクノロジーに興味がないのではないでしょうか?キャリア開発が目標なら、人と付き合うか、ビジネスを始めるかの 2 つの方法しかありません。人と付き合うと、社内で昇進したり、転職したりすることができます。前者では、上司にあなたが素晴らしいと思ってもらう必要があります。後者では、他の会社の上司にあなたが素晴らしいと思ってもらう必要があります。ここでのキーワードは「信じる」であることに注意してください。なぜなら、人々の主観的な印象と客観的な事実の間には常にギャップがあり、このギャップは人々の想像を超えることが多いからです。つまり、ポイントは「すごい」という印象を与えることですが、実際には、すごいかどうかは問題ではありません。すごいことは良いことですが、すごいことでなくても問題ありません。

技術的な道に進みたい場合は、製品の成功または失敗を決定する主な要因がテクノロジーとなる「建物を建てる」レベルの仕事を探すことを検討してください。このレベルのプロジェクトは、通常、大企業でしか実行できません。コードが存在し、実行すればそれが素晴らしいかどうかが判断できるため、上司が従業員の技術的能力を客観的に評価するのは比較的簡単です。しかし、いわゆる「ソフトパワー」は、非常に主観的なため、判断が難しい場合が多い。

このため、多くの人は、自分はとてもすごいと思っているのに、上司はそう思っていない(上司が悪いのではなく、本人が傲慢なだけかもしれない)ので、怒りながら起業の道を歩み始める、ということがよくあります。自分が上司になれば、上司の印象と事実のギャップを心配する必要がなくなります。しかし、この道はより困難な場合が多く、個人に比較的高いレベルの総合的な品質を要求します。プログラマーが職場で同僚と円滑に連携できないのであれば、起業家に求められるさまざまな資質を満たすことができるとは考えにくい。したがって、この道を進みたいのであれば、心の準備が必要です。

要約する

テクノロジーは人々に役立つものです。IT 業界の発展により、コンピューターの使用ハードルは徐々に下がり、ますます多くの人がこのツールを利用できるようになりました。これは良いことですが、プログラマーという職業の技術的な内容も低下します。本当にテクノロジーをやりたいなら、本物のテクノロジーをやってください。そうでなければ、テクノロジー以外のことにもっと注意を払う必要があります。テクノロジーに頼るだけでは、自分を慰めることにしかならず、本当のキャリア開発にはつながりません。

<<:  ショアのアルゴリズム: RSA 暗号解読の「不滅の神話」

>>:  Playgroundで数値アルゴリズムを学ぶ

ブログ    
ブログ    

推薦する

GACの第2世代Trumpchi GS4が発売され、WeChat車載バージョンは安全で効率的な車内通信を実現

11月15日、WeChat車載バージョンを搭載したGACの第2世代Trumpchi GS4が発売され...

LangChain と DeepInfra を使用してカスタマー サポート チャットボットを構築するためのガイド

翻訳者 |ブガッティレビュー | Chonglou日常のオンラインのやり取りの中でチャットボットを目...

...

...

衝撃の2017年!この10日間は中国の人工知能の時代

2017年にはすでに「残高不足」が発生。今年、中国の人工知能開発は多くの進歩を遂げ、実りある成果を達...

2024 年にソフトウェア開発の生産性を向上させる 10 のベスト AI ツール

2023年までに、AIは複数の業界で広く採用されるようになります。 2024 年までに、ソフトウェア...

新しいAIは「人間の脳に潜り込み」、どんな外見が最も魅力的かを理解できる

北京時間3月11日、外国メディアの報道によると、科学者らは最近、「人間の脳に潜り込み」、どのような顔...

光量子コンピュータ「九章3号」が発売されました!スーパーコンピューターの1000億倍の速さ、USTCのパン・ジアンウェイ氏のチームより

私の国の量子コンピューティングは新たな進歩をもたらしました。 USTC公式ウェブサイトからのニュース...

落とし穴を避けよう!ニューラルネットワークの欠点と短所を数え上げよう

最近、ディープラーニングが大々的に宣伝されており、人々はニューラル ネットワークをあらゆる場所で使用...

Python でよく使われるアルゴリズム - 貪欲アルゴリズム (別名 greedy algorithm) をご存知ですか?

貪欲アルゴリズム (または貪欲アルゴリズム) とは、問題を解決するときに、その時点で適切と思われる選...

GPT ストアは来週開始され、OpenAI アプリケーションの爆発的な増加が目前に迫っています。最も完全なGPTビルダーユーザーガイドはここにあります

これから起こることは、やがて起こるでしょう! OpenAIが開発者会議で正式発表した「GPTストア」...

機械知能に取って代わられない5つのスキル

「機械知能が人間のために行っている 5 つのこと」という記事では、機械が常に新しい奇跡を生み出してい...

...

人工知能が世界をより安全な場所にする4つの方法

わずか数週間で、COVID-19パンデミックは私たちの日常生活を完全に変えてしまいました。多くの企業...

...