Redis の創設者である Antirez は、2024 年に最初のブログ投稿を書きました。彼の功績は並大抵のものではありませんが、彼は普通のプログラマの観点から大規模言語モデルについての自分の気持ちを語りました。記事の中で、彼はGoogleエンジンがゴミの海になっていると鋭くコメントし、現在のAIGCの能力を客観的に評価した：愚かだが古代と現代についての知識がある。
長期的な使用を通じて、彼は、生成 AI の現段階では、すでに強力なプログラマーをさらに強化するだけであると信じています。現在、プログラミング作業の多くは繰り返し作業であり、大きなモデルに高度な推論は必要なく、「使ったら捨てる」プログラムには大きなモデルが非常に適しています。antirez のブログ投稿を翻訳し、著者の当初の意図を変えることなくいくつかの削除を行いました。
ChatGPT の誕生以来、生成 AI は、後にローカルで実行されるさまざまな大規模モデルを含め、広く使用されてきました。私の個人的な目的は、大規模なモデルに依存してコーディング能力を向上させることである一方で、退屈で価値が限られた作業から貴重なエネルギーを解放したいと考えています。多くの友人も私と同じで、つまらない技術文書の検索に数えきれないほどの時間を費やし、さまざまな複雑すぎる API を学習することを強いられ、短期間でゴミになってしまうプログラムを書いていると思います。仕事はこうあるべきではないし、開発もこうあるべきではない。現在、Google エンジンはゴミの海と化しており、私たちはその中から有用なコンテンツを見つけるために一生懸命働かなければなりません。
また、私自身プログラミングに慣れたわけではありません。外部リソースがなくてもコードは書けますし、ある程度の開発レベルはあるとさえ言えます。ただ、時間が経つにつれて、高レベルのコードの作成を支援するために大規模なモデルを使用することが多くなりました。Python コードが最も多く使用されていましたが、C ではあまり使用されませんでした。
大規模な言語モデルについて私が最も感銘を受けたのは、いつ使用できるようになるかを正確に認識できること、そして盲目的に使用すると進歩が遅くなるだけであるということです。また、大規模なモデルは、実際には Wikipedia や YouTube のさまざまなビデオ コースと非常によく似ていることもわかりました。これらは、意欲があり、有能で、より自制心のあるユーザーにとっては非常に効果的ですが、すでにビジネス能力が欠けている友人にとっては効果が不十分です。したがって、少なくとも現段階では、生成 AI はすでに強力なプログラマーをさらに強力にするだけではないかと心配しています。
段階的に議論を始めましょう。
大規模な言語モデル: 全知全能、
それともオウム?
機械学習の新しい波における最も懸念される現象の 1 つは、AI 専門家が大規模モデルに関する知識がまだ限られていることです。私たちはニューラル ネットワークを発明しましたが、実際に発明したのは、ニューラル ネットワークのパラメータを自動的に最適化するアルゴリズムにすぎません。ハードウェアは、処理対象のデータ (先験的資料) から抽出された統計的知識を使用して、さらに大規模なモデルをトレーニングし、多数の反復実験を通じてエラーを排除し、正解に近づけることができるようになりました。大規模なモデルは、過去の他のアーキテクチャよりも優れたパフォーマンスを発揮することを認めなければなりません。しかし全体として、ニューラルネットワーク自体は依然として非常に不透明なままです。
大規模モデルの新たな機能の一部を説明できないため、科学者はより慎重になることが予想されます。しかしその対極には、大規模な言語モデルを、せいぜいトレーニング セットで見られる限られた変更を再現できる程度の、より高度なマルコフ連鎖の一種にすぎないと信じて、大規模な言語モデルをひどく過小評価する人もたくさんいます。しかし、大量の事実証拠は、この大規模なモデルが単なる「オウム返し」であるという理論がまったく支持できないことを示しています。
また、大規模な言語モデルが実際には存在しない超自然的な力を獲得したと感じている熱心な人々もたくさんいます。それはそれほど不思議なことではなく、大規模なモデルが補間できるのはせいぜいトレーニング中に公開されたデータ表現空間だけであり、これは何も新しいことではありません。そして、補間単独に関しても、その機能はかなり制限されています (ただし、人間の予想を超え、驚きをもたらすには十分です)。さらに一歩進んで、これまで触れたすべてのコードで囲まれた空間内で連続補間を実行できれば、真に斬新なものを生み出すことはできなくても、大規模なモデルはプログラマーの 99% を置き換えるのに十分になります。
幸いなことに、現実はそれほど誇張されておらず、私たち開発者にはまだ生き残る余地があります。実際、大規模な言語モデルは、そのままでは公開されていないプログラム形式を記述することができ、また、トレーニング セット内で出現頻度の異なるアイデアを統合することで、開発の方向性を導く予備的な能力も示します。ただし、この能力には現時点では大きな制限があり、さまざまな微妙な推論タスクによって常に大規模な言語モデルが壊滅的な障害に見舞われることになります。ただし、大規模な言語モデルが AI テクノロジーの誕生以来の最大の成果を表していることは認められなければならず、これがすべての議論の前提となるべきです。
バカだけど昔も今も詳しい
これは真実です。大規模な言語モデルはせいぜい最も基本的な推論しか実行できませんが、これは十分に正確ではなく、多くの場合、事実上の幻想や捏造に満ちています。しかし、彼らは深い知識も持っています。
たとえば、プログラミングなどの高品質なデータが得られる分野では、大きなモデルは古代から現代までをすべて知っている愚かな学者のようなものです。そのようなパートナーとプログラムを組むのは賢明ではありません (まあ、私の意見では、誰かとプログラムを組むことさえ賢明ではありません)。彼らはばかばかしいアイデアを投げかける傾向があり、開発アイデアにおいて自分自身を強調するよう常に努力する必要があります。
しかし逆に、この博学な愚か者を自由に使えるツールとして扱い、そこから質問をインスピレーションの源として扱うと、その効果はまったく異なります。現在の大規模なモデルはまだ人間を知識のギャップを越えさせることはできませんが、慣れていない問題を解決したい場合、何も知らない状態から完全に自分で学習できる状態に迅速に移行するのに役立ちます。
プログラミングの分野では、過去 20 ～ 30 年前のプログラマは、大規模モデルの能力についてあまり高い評価を持っていない可能性があります。結局のところ、当時私たちがマスターする必要があるのは、いくつかのプログラミング言語、特定の古典的なアルゴリズム、および十数個の基本ライブラリだけであり、残りは純粋に自己表現、才能の活用、専門知識とデザイン スキルの適用に関するものでした。この能力がある限り、私たちはあらゆる問題を解決できる可能性を秘めた、当然のプロのプログラマーです。
しかし、時が経つにつれて、さまざまなフレームワーク、プログラミング言語、ライブラリが入れ替わり、その爆発的な成長は開発をより困難にし、プログラマーの日常業務に多くの不必要で理不尽なトラブルをもたらしました。このような現実と背景の下で、古代と現代の両方を知っているダモーのような愚かなチームメイトは、進歩のための最も貴重なガイドとなっています。
例: 私自身の機械学習実験は、Keras を使用して 1 年間完了しました。その後、さまざまな理由から、PyTorch に切り替えました。当時、私はすでにエンベディングと残差ネットワークが何であるかを学習していましたが、PyTorch のドキュメントを一字一句勉強することは本当にやりたくありませんでした (Keras を学習するときにこのように勉強しました。ChatGPT があれば間違いなくたくさんの辛い思い出を避けるのを手伝ってください）。大規模な言語モデルを用意したので、Torch を使用して Python コードを非常に簡単に作成できます。唯一の前提条件は、組み合わせたいモデルについて明確なアイデアを持ち、適切な質問ができることです。
ケースと話す
ここで話しているのは、「クラスはどう違うのか？」といった単純な要件ではないことに注意してください。対照的に、複雑なモデルでは、ほんの数年前には想像できなかった機能など、さらに多くのことが可能になります。
これで、GPT-4 に次のように伝えることができます。「ほら、これは私が PyTorch に実装したニューラル ネットワーク モデルです。これらは私が設定したバッチ タスクです。バッチ関数が「ニューラル ネットワークを作成すると同時に、この特定の方法で表現したいのですが、どのコードを書き直す必要があるか教えていただけますか?」 プロンプトが完了すると、GPT-4 がコードを書き込むので、私がしなければならないことは次のとおりです。 Python CLI でテンソル結果をテストします。ディメンションが要件を満たしているかどうか、またデータ レイアウトが正しいかどうかを確認します。
別の例を見てみましょう。少し前、ESP32 ベースのデバイス用の BLE クライアントを開発する必要がありました。いくつか調査した結果、ほとんどのマルチプラットフォーム Bluetooth プログラミング バインディングは直接使用できないことがわかりました。解決策は非常に簡単で、macOS のネイティブ API を使用して Objective C でコードを記述するだけです。そのためには、2 つの問題に同時に対処する必要があります。1 つは Objective C の扱いにくい BLE API を学習すること、もう 1 つはさまざまな無意味なパターンに適応することです (私はミニマリストであり、Objective C の BLE API は間違いなく「良い設計」のモデルです)。反例)。 Objective C でプログラミングする方法を学びます。最後にプログラミングしたのは 10 年前で、イベント ループや固有の管理などの技術的な詳細はずっと忘れていました。
最終結果は次のコードになります。これは、エレガントかつ簡潔ではありませんが、少なくとも機能します。大規模なモデルの助けを借りて、以前ではまったく想像もできなかった非常に短い時間で開発を完了しました。
https://github.com/antirez/freakwan/blob/main/osx-bte-cli/SerialBTE.m
コードは主にChatGPTで生成されており、やりたいけど実装方法がわからない要件を貼り付けるのが私の仕事です。このようにして、大きなモデルは、何が問題であり、それをどのように解決すべきかを説明してくれるのです。
確かに、この大きなモデルには実際には多くのコーディングは必要ありませんでしたが、開発を大幅にスピードアップするのに役立ちました。ChatGPT なしでプロジェクトを完了できますか? もちろんうまくいきますが、最も重要なことは、どれだけ余分に時間を投資しなければならないかということではなく、あきらめてしまうかもしれないということです。結局のところ、そのような面倒なことはもはやエネルギーを浪費する価値がありません。
私の意見では、これが本当の決め手です。大きなモデルがなければ、労力とメリットを天秤にかけてこのようなプログラムをまったく作成しなかったでしょう。大きなモデルは、プログラム自体よりも重要な微調整を行うのにも役立ちました。プロジェクトでは、マルチプレクサーで動作するように linenoise (私が使用しているライン編集ライブラリ) を変更しました。
使い捨てプログラム
上記のようなケースは他にもたくさんあるので、ここではあまり繰り返しませんが、結局のところ、似たようなストーリーには、基本的に同じルーチンと効果があります。日常の仕事では、検証可能な結果を迅速に取得するという別の種類の問題に直面することがよくあります。この場合、大規模なモデルを使用して探索効率を向上させることもできます。
このようなシナリオでは、私は大きなモデルにすべてのコードを書かせる傾向があります。たとえば、次のような使い捨てプログラムを作成する必要がある場合:
https://github.com/antirez/simple- language-model/blob/main/plot.py
小規模なニューラル ネットワークの学習プロセス中の損失曲線を視覚化したかったので、PyTorch プログラムで生成された CSV ファイル形式を GPT-4 に示し、コマンド ラインで複数の CSV ファイルを指定すると、さまざまな実験の結果を分析できるようになり、検証損失曲線が比較されます。上記のリンクは GPT-4 によって生成された結果であり、所要時間はわずか 30 秒です。
同様に、AirBnB CSV レポートを読み取り、アパートを月と年ごとにグループ化するプログラムが必要です。次に、清掃料金と予約した宿泊数を組み合わせて、年間のさまざまな月の平均レンタル価格を計算します。このプログラムは私にとってはうまくいきましたが、書くのは非常に退屈でした。新しいことも興味深いことも何もありませんでした。そこで、CSV ファイルの一部を選択して GPT-4 に貼り付け、大規模モデルで解決したい問題を記述しました。出力プログラムは 1 回だけ正常に実行されます。ただし、特定のデータのグループ化方法を正しく理解する必要があります。そうしないと、データが分散して無秩序に感じられてしまいます。
単純な推論により、大規模なモデルは明らかに公開されたトレーニング資料から単純にコピーされたソリューションではないと私は確信しています。はい、GPT-4 はトレーニング中に同様のプログラムを観察したはずですが、これらのプログラムに対応する特定のグループ化要件、特に特定の形式の CSV ファイルにグループ化するための要件は、私のプロンプトとは異なります。したがって、私の意見では、大規模なモデルは、トレーニング セット内のさまざまなプログラムによって記述された空間をある程度補間できるはずです。
このような単純なプログラムを書くのに時間を無駄にするのは賢明ではありません。大規模なモデルがそのようなタスクを引き受けることができるため、本当に重要な作業に集中することができ、間違いなくコードの生産性が隠れて向上していることがわかりました。
大規模なモデルでは解決できない典型的なタスク
: システム プログラミング
大規模なモデルのプログラミングへの私の試みはかなりの成功を収めましたが、C でプログラムを作成する場合、大規模なモデルはポータブルなドキュメント アシスタントとして機能することがわかりました。私自身はシステム プログラミングの専門家ですが、この種のユースケースでは、大規模なモデルには高度な推論機能がないため、ほとんど役に立ちません。私の友達もみんな同じような気持ちを持っていると思います。
この実験的なプロンプトを見てみましょう。
「ブルーム フィルターのエレガントで短く効率的な C 実装を生成します。ハッシュ関数の処理に焦点を当て、高品質の C で記述します。また、実装のサイズは 100,000 個の要素を格納できるようにする必要があり、誤検知の可能性が低いことも考慮してください。」 5% を超えています。追加された要素は NULL で終了する文字列です。」
GPT-4 の答えは良くありません。ブルーム フィルターは実際には非常に一般的であり、関連するデータ構造は特別なものではありません。しかし、適切なブルーム フィルターを作成するには、同じ文字列を N 回ハッシュする効率的な方法を見つけたり、各ハッシュ値が完全に非相関化されていることを確認したりするなど、より強力な抽象化機能が必要であることは明らかです。考えを変えて、N 個の非相関出力を生成するようにハッシュ関数を変更するように GPT-4 に明示的に要求すると、GPT が提供する解決策はより信頼性が高くなります。このアイデアを独自に発見できれば、単一のハッシュ関数を使用して一度に K ビットを設定するという、別の方法でブルーム フィルターを作成することになります。
実際のところ、GPT-4 は適切でより一般的なハッシュ関数を独立して作成できますが、ブルーム フィルターなどのより大規模なプロジェクトを作成する場合、優れた推論能力を発揮できませんが、異なる 2 つの非常に類似したハッシュ関数を提供します。
全体として、現在の大規模な言語モデルの推論能力はまだ弱く、さらに、この問題に関するリソースは比較的不足している可能性があり、さらには低品質のリソースが多数存在するため、満足のいく結果が得られない可能性があります。これは決して特殊なケースではなく、アルゴリズムやシステム プログラミングで大規模なモデルを使用しようと何度も試みましたが、結果も非常に貧弱でした。たとえ推論機能の期待値が下がったとしても、Python プログラミング環境でのコード生成のレベルを再現することはできません。
しかし同時に、GPT-4 は出力する関数を逆コンパイルすることができ (別のセッションが必要)、そうすることの意味を正確に理解することもできるため、大規模なモデルは依然としてシステム プログラミング シナリオにおいて一定の役割を果たしていますが、非常に限られています。
もう 1 つの興味深く有望な点は、上記の状況における小型モデルと大型モデルのパフォーマンスに大きな違いがあることです。
Mixtral はさまざまな目的に適した優れたモデルですが、大規模なモデルの本質的な推論能力の弱さを考慮すると、現時点で結論付けられるルールは、サイズが大きいほど効果が高いということです。さらに、ローカル デバイスのメモリではモデルをより高い精度で実行するには不十分であるため、ローカル モデルのディープシーク コーダーは 4 ビットの量子化精度に設定されます。それでも、パラメータが 340 億個あるため、同じ問題に対する推論能力は依然として強力です。
私の試みでは、問題に関するヒントを与えたところ、モデルは正しく答えを導き出し、問題の本当の原因を特定し、最終的には機能する代替案を思いつきました。この種のアプリケーションに対する直接的な答えは、どの文書、書籍、Google 検索にもありません。
オリジナルの補間の観点から見ても、他のアイデアの観点から見ても、モデルは何らかの推論能力を習得しています。この推論能力がなければ、AI は問題の根本原因を見つけ出し、潜在的な解決策を発見することができます。大規模な言語モデルはプログラマーにとって補助的な意味を持っています。
しかし同時に、過去数か月にわたる経験から、システム プログラミングの分野では、特に経験豊富なプログラマにとって、大規模なモデルがすぐに使えるソリューションを提供することはほとんどないことがわかっています。
私が現在担当している ggufflib プロジェクトでは、GGUF 形式ファイルを読み書きするライブラリを作成する必要があります。GGUF 形式ファイルは、量子化モデルをロードするために llama.cpp によって使用される形式です。最初は、量子化エンコーディングがどのように機能するかを理解するために ChatGPT を使用しようとしましたが、最終的には llama.cpp コードをリバース エンジニアリングすることにしました。そのほうが高速でした。
理想的な大規模言語モデルは、接触するデータ エンコードの「構造」宣言とデコード関数に基づいてデータ形式に関するドキュメントを復元できる必要があり、それによってシステム プログラマが設計アイデアを理解できるようにする必要があります。しかし、llama.cpp の機能はそれほど大きくなく、GPT-4 のコンテキスト ウィンドウに押し込むことができますが、出力される結論は意味がありません。
このような状況では、紙とペンを取り出し、コードを 1 行ずつ読み、デコーダーによって抽出されたビットがどこに登録されているかを確認するという、最も伝統的なプログラマーが行うことしかできません。
大規模な言語モデルの正しい見方
非常に遺憾ながら、現在のプログラミング タスクのほとんどは同じ作業をわずかに異なる形式で繰り返しており、高度な推論はまったく必要ありません。大規模な言語モデルはこの点で良好に機能しますが、依然としてコンテキストのスケールという厳しい制約を受けます。
そして、このことは私たちプログラマーにも、「そのようなプログラムは本当に時間とエネルギーをかけて書く価値があるのだろうか?」と考えるきっかけになるはずです。確かに、この仕事は私たちにかなりの報酬をもたらす可能性がありますが、大規模な言語モデルがこの部分の仕事を徐々に引き継いでいけば、5 年か 10 年も経たないうちに、多くの同僚のプログラマーが職を失うことになるでしょう。
さらに、大きな言語モデルはある程度の推論能力を持っているのでしょうか、それともまだオウムの真似をしているだけで、より鮮やかに学習しているだけなのでしょうか？場合によっては、彼らは推論する能力、つまり記号学者が「シニフィアン」と呼ぶ概念、つまり実際には存在しない意味を理解する能力を持っていると思います。
大規模なモデルを頻繁に扱う友人なら誰でも、その限界を理解し、そこに組み込まれた推論の力を感じることができると私は信じています。つまり、過去に接したコンテンツを統合する能力は、単語のランダムな出力をはるかに超えています。その学習プロセスは主に事前トレーニング段階で完了しますが、次のトークンを予測するとき、大規模モデルは依然として目標に基づいて何らかの形の抽象モデルを構築します。このモデルはまだ脆弱で不完全で完璧ですが、実際に観察することで、この能力が客観的に存在することがわかります。諺にあるように、聞くことは信じること、見ることは信じること、たとえそれが数学の決定論的原理に挑戦し、最も偉大な技術専門家の見解に反するとしても、私は依然として大きなモデルが示す認知レベルに自信を持っています。
最後に、皆さんが大きなモデルを積極的に取り入れて、それを使ってプログラミングのさまざまな問題を解決できることを願っています。大規模なモデルに対して適切な質問をすることは基本的な開発スキルとなり、練習すればするほど AI は作業を改善できるようになります。AI の要因が考慮されていない場合でも、問題を明確かつ明確に説明するこの能力は、他の人とのコミュニケーションを改善するのに役立ちます。結局のところ、私たちの思考プロセスに追いつけない会話オブジェクトは大きな言語モデルだけではありません。プログラマーの多くは特定の分野では優れているものの、コミュニケーション能力が低く、それがキャリア形成を制限するボトルネックになっているということは皆さんもお気づきかと思います。
今日の Google エンジンはすでに壊れているため、テキスト コンテンツを凝縮して洗練するという観点から見ても、大規模なモデルは実用的に非常に重要な意味を持つはずです。私個人としては、今後も大型モデルを使用して理解していきたいと思います。私は、あいまいな通信プロトコルの詳細を学ぶのが好きではなかったし、複雑で派手なライブラリの作成方法に取り組みたいと思ったこともありませんでした。私にとって、これは単なる時間とエネルギーの無駄です。大きな言語モデルのおかげで、私はこうした泥沼から救われました。
元のリンク:
http://antirez.com/news/140