  |
はてなキーワード: エンジニアリングとは
競プロ楽しそうだけど、参加したら臆病な自尊心を傷つけられそう。Googleに入社する直前にTopCoderに一度参加したことがあって、それを同期が見つけられた。で、「ひどいコード」だなと言われたから「営業で採用された」と返したら「やっぱり！」と言われて以来競プロには近づいてない🥲
一般社団法人「ソフトウェアエンジニアリング協会」では、ソフトウェアエンジニアリングの基礎を学びたい方向けに、教育カリキュラムを提供してます。内容は知識・技能・精神性の指導です。費用は無料。どなたでも参加可能です。ご希望の方は DM でご連絡ください。
やはり競プロやるとアレになるの…………
は事実だし、その上で
からな。彼が守りたいのはエンジニアリングでも本来の意味での競技プログラミングでもなく、Atcoderというサービスと自分の財布に過ぎない。
カルトと同じだよ。
そもそもの論点として競プロがちょっとできてもエンジニアとしては「ハイスキル」ではないってことなんだよね
もちろん日本のSWEは、昔の自分もふくめて、アルゴリズムとかデータストラクチャなんか知りませんやってこともありませんという人が普通にいるし、ひょっとしたら大部分だけども
競プロは少なくともその二つとか計算量のBigOはわかってないと出来ないという意味で比較で言えばハイスキルではある
ただ、実際のシステムの開発では例えばダイクストラをA*にしましょうなんてことはないわけで、アルゴリズムいるなら自作だし
そういう場面も滅多にないのでOOPとかDDDとかの「実践」、後で機能つけるとか変えるときに数十数百億円流れてるってプレッシャーの中どれだけ簡単に早く確実にやれるかという技術と経験と実績が大事なんだよなあ
世の中の「エンジニア」のほとんどがソフトウェアエンジニアリングというよりはちょっとDayforceのレポートの設定がうまいくらいを求められてるのはその通りなんだけどね
職場の友達にゲーム超うまいやつがいてコンテスト？競技？みたいなのでそこそこ勝っちゃうくらいで超難しいと思うし俺は絶対無理だけど
だから仕事でどうかってキーボード打つのが速いくらいなんだよね
仕事は仕事なんだから仕事ができなきゃ「俺は難しいことをやってきた！」とか言っても全く意味ないわけで
ソフトウェアエンジニアリングってアルゴリズムを知ってる、その場でかける、なんて超狭い部分だから
例えばウチの職場で競プロが！っていったら「おおすごいじゃん」くらいには言ってもらえると思うけど「まだまだだな」ってのは全員の目に明らかだと思う
競プロでGAFA入れないしその競技で億かせげるわけでもないし
まだゲームのが稼げるよね
やはり休日は暇つぶしが必要だと思い、Kaggleでmovielensデータセットで実験を行った。
最もシンプルなモデルとして、ユーザー×アイテムの行列に対する類似度を算出する方法で、類似ユーザーTop n人のレートの平均値を算出し、Top mのアイテムを出す。
これでNDCG@100で0.36ぐらいなので、ベースラインとしてはまあそのぐらいだろう。
実際、SOTAモデルを見ても、NDCG@100=0.4253ぐらいしか達成していない。
https://paperswithcode.com/sota/collaborative-filtering-on-movielens-1m?metric=nDCG%40100
Kaggleでのコンペは、精神を疲弊しそうだし、自信もないので参加する気はない。
こう、なんというか、それなりの精度のベースラインモデルをササッと作るぐらいで丁度いい。
ところで、自分の7年の業務経験のスキルセットがどの程度なのかというのを視覚化してみたら、多分以下のようになると思う。
| genre | level |
| コーディング | ★★★★ |
| アルゴリズム | ★★★ |
| インフラ | ★★ |
| 機械学習 | ★★★ |
| コミュニケーション | ★★ |
| ビジネス理解 | ★ |
| データ視覚化 | ★★ |
| 統計学 | ★★ |
実のところ「機能要件をどう実現するか」というエンジニア思考なので、あまり統計科学的な思考は身についていない。
といっても薬学研究の発表があれば「薬の作用・副作用の効果なのか、病気の症状によるものなのか区別がついていない」ということを指摘できる程度の批判的思考は持っているので、
「科学」と名のつくところに科学とは程遠い政治が存在することは知っている。
つまりエンジニアリングが好きで、科学が嫌いなのは、その政治性である。エンジニアリングは、作って見せればそれで実証できるのが好きである。
「ビジネス科学」と言われることがあるが「科学的手法を使うから科学である」というのは少し違う気がしている。
最後に、定量化するのが最も難しいが、それに劣らず重要な改善のカテゴリーを紹介しよう。
難しい数学の問題を解くように言われたとき、頭に浮かんだことを即座に答えなければならないとしたらどうだろう。最も単純な問題を除いて、苦労するのは明らかだろう。しかしつい最近まで、LLMにはそうやって数学の問題を解かせていた。その代わり、私たちのほとんどはスクラッチパッドで段階的に問題を解いていき、その方法ではるかに難しい問題を解くことができる。「思考の連鎖」プロンプトは、LLMのそれを解き放った。生の能力は優れているにもかかわらず、明らかな足かせがあるため、LLMは数学が苦手なのだ。
私たちはここ数年で、モデルの「足かせを外す」ことに大きな進歩を遂げました。これは単に優れたベースモデルをトレーニングするだけでなく、アルゴリズムの改良によってモデルの能力を引き出すものです：
足場作り。CoT++について考えてみよう：ただ問題を解くようモデルに求めるのではなく、あるモデルに攻撃計画を立てさせ、別のモデルに可能性のある解決策をたくさん提案させ、別のモデルにそれを批評させる、といった具合だ。例えば、HumanEval（コーディング問題）では、単純な足場作りによってGPT-3.5が足場なしのGPT-4を上回った。SWE-Bench（実世界のソフトウェアエンジニアリングのタスクを解くベンチマーク）では、GPT-4は~2%しか正しく解くことができませんが、Devinのエージェントの足場があれば14-23%に跳ね上がります。(後ほど詳しく説明するが、エージェントのアンロックはまだ初期段階に過ぎない。)
ツール：もし人間が電卓やコンピュータを使うことを許されなかったらと想像してみてほしい。まだ始まったばかりだが、ChatGPTはウェブブラウザを使ったり、コードを実行したりできるようになった。
エポックAIによる研究によると足場作りやツールの使用など、これらのテクニックのいくつかを調査したところ、このようなテクニックは多くのベンチマークで通常5～30倍の効果的な計算量の向上をもたらすことがわかった。METR（モデルを評価する組織）も同様に、同じGPT-4ベースモデルからのアンホブリングによって、エージェントタスクのセットで非常に大きなパフォーマンスの向上を発見しました。
https://situational-awareness.ai/wp-content/uploads/2024/06/metr_gains_over_time-1024x597.png
これらをコンピュートとアルゴリズムの効率で統一した実効的なコンピュート規模に当てはめることは困難ですが、少なくともコンピュート規模の拡大やアルゴリズムの効率とほぼ同規模の大きな進歩であることは明らかです。(また、アルゴリズムの進歩が中心的な役割を担っていることも浮き彫りになっています。0.5OOM/年の計算効率は、すでに重要なものではありますが、ストーリーの一部に過ぎません。）
「アンホブリング」こそが、実際にこれらのモデルが有用になることを可能にしたのであり、今日多くの商業アプリケーションの足かせとなっているものの多くは、この種のさらなる「アンホブリング」の必要性であると私は主張したい。実際、今日のモデルはまだ信じられないほど足かせが多い！例えば
ここでの可能性は非常に大きく、私たちはここで急速に低空飛行の果実を摘んでいる。これは非常に重要です。"GPT-6 ChatGPT "を想像するだけでは完全に間違っています。 GPT-6＋RLHFと比べれば、進歩は段違いだ。2027年までには、チャットボットというより、エージェントのような、同僚のようなものが登場するだろう。
続き I.GPT-4からAGIへ：OOMを数える(8) https://anond.hatelabo.jp/20240605210232
社会人になってからのぼんやりした目標でITを極めたいという思いがある。
一分野に特化したタイプではなくIT領域におけるオールラウンダーのような総合格闘家のような存在。
まずITを極めるとは具体的にどういう状態なのか。そのためには何をすればいいのかを考察する。
まずITを主要トピックに大別する。必ずしもMECEではない。
そしてどういうことができたらITを極めたと言えるかを思いつく限り列挙してみる
次は具体的に列挙した例について解像度を上げてどの要素に分類されるものかを考えた上で、それを極めるには何をすればいいかを考える。
あまりに理不尽なことでクライアントと言い合いになったので、多少ボカして顛末を記す。
私の会社でとある商品をオンライン販売しており、その在庫管理システムのようなものを必要としていた。
それでネットで検索して「システム構築はお任せください」というシステムインテグレータに見積もりを依頼し、発注することになった。
概ね順調にシステムが出来てきたころ、私と先方のシステムエンジニアとの会話でこのようなことがあった。
先「それなら良かったです」
私「一点いいかな？受注してから発送作業者が作業に取り掛かるまで、現状だと手動で見に行かなければならない。ここも改善したいのだがいけるかな？」 ※特定を避けるためボカしてます
先「なるほど・・・その場合は人が常駐している必要がありますね」
私「その作業、君がやってくれるかな？」
先「えっ？」
私「えっ？」
となって空気がおかしくなった。私の言い分はこうである。「システム」は業務の工程全体を表すのであって、ソフトウェア的な部分だけを表すワードではない。
だから「システムエンジニア」を名乗るなら、ソフトウェア面以外の箇所も改善するのが当然ではないか、というのが私の理屈である。
しかし先方の言い分はそうではない。システムエンジニアはソフトウェアシステムだけを改善し、それ以外は関与しない。
だからソフトウェア改善で対応できない箇所は「システムエンジニア」だから対応しないというわけである。
私にとっては、一体何を言っているんだという話である。システムという言葉を軽視しているというか、濫用しているのではないか。
ソフトウェアも立派なシステムであるが、これは株式会社と株式会社のやりとりである。
ビジネスがシステムの根幹であって、ソフトウェアはその内部のいち部分でしかないことは明白ではないのか？
結局そのシステムインテグレータは、ソフトウェア以外のシステムは対応しませんということだった。私にとっては片手落ちの気分である。
システムエンジニアはソフトウェアだけしかエンジニアリングしなくて良いと思っている人。
インパラ・・・ウシ科に分類される偶蹄類。本種のみでインパラ属を構成する。
インパラ・・・ゼネラルモーターズ (GM) がシボレーブランドで販売している大型乗用車
インペラ・・・液体・気体用の遠心力ポンプや発電機等に使用される羽根車
インペラトル・・・ローマにおける軍指揮者、凱旋将軍・大将軍、元首・皇帝
オンプレ・・・オンプレミス（自社サーバーでシステムを運用する形態）
（追記）
現代分類学の秘孔を突く新機軸エントリに思いのほかトラバブクマ集まったな。みんなサンキュー。
みんな知ってるか？インパラってめちゃ育てるのが難しくてどうもたぶんおそらくだけど日本の動物園にはいないっぽいぞ！？
「あーインパラねハイハイ見たことあるある」みたいに思ってるあなたのそのインパラっぽいイメージのやつ！、それ、「オリックス」ですから！！「アラビアオリックス」ですから！！「シロオリックス」ですから！！！「エランド」ですから！！！！
どうせ想像の中では雑魚モンス扱いなんだろ？ライオンチーターゴリラゴリラゴリラに見劣りするからな。でもな、敢えて言う実物を見てみろ！もも肉の感じとかサア！マジで生命感ハンパないぞ！見たことないが。
フリーレンが集めてるしょーもない魔法は、pipとかnpmに上がってるしょーもないパッケージ
っていうのを集めてる
魔法の解析はリバースエンジニアリングのことで、フリーレンはその天才
で、魔法は単純なプログラミングコードではなくてLLMをベースにしたコードになっていて
魔力っていうのはそのLLMのモデルの大きさ
長い年月をかけてLLMを追加学習させることで魔力を増やしていくが人間はそのモデルの大きさを誇ろうとしない
魔力の揺らぎはLLMの出力の微妙な違いのことで、LLMのモデルが大きいと
「単純な答えのように見えるけど微妙に違っていて実は大きなモデルなのでは？」
と気付く
AIなのでLLMしか取り柄が無く、モデルの大きさでマウントを取り合うのが魔族
ただ人間と違って死ぬことがないので魔族の使うプロンプトエンジニアリングはまるで理解できず
人間が再現できないLLMベースのプログラミングコードは「呪い」として扱われてる
