私の「AI」活用法

xguru · 2024-08-06T11:03:01+09:00

この1年ほど、毎週何時間も大規模言語モデルとやり取りしながら、ますます難しい作業をこなす能力に継続して感銘を受けてきたその結果、研究プロジェクトや個人プロジェクトでのコード作成速度が少なくとも50%向上したオンラインでLLMの有用性について語る人の多くは、たいてい過度に楽観的か、過度に悲観的である将来についての議論よりも、この1年でLLMを活用して研究能力を高め、コーディングプロジェクトを助けるために使った50の対話例を示したい私のLLM活用例これまで使ったことのない技術で、Webアプリ全体を構築したさまざまなフレームワークの使い方を、実際に最初から触らなくても学んだ何十ものプログラムをCまたはRustに変換し、性能を10〜100倍改善した大規模なコードベースを削減して、プロジェクトを大幅に単純化したこの1年で、ほぼすべての研究論文の初期実験コードを書いたほぼすべての単調な作業や使い捨てスクリプトを自動化した新しいパッケージやプロジェクトのセットアップ・設定のためのWeb検索をほぼ完全に置き換えたエラーメッセージのデバッグのためのWeb検索の約50%を置き換えたこれを分類すると2つになる学習の補助: 以前なら難しかったことができるようになる退屈な作業の自動化: 自分が最も得意なことに集中し、難しい問題を解けるようにする最も重要なのは、これらの事例が実際にLLMを活用して助けを得た方法だという点である印象的な機能を見せるためではなく、実際の業務を処理しなければならない自分の必要から生まれたものだ Nuance インターネットがあまり得意ではないことのひとつは、ニュアンスである。私は、今日のLLMが世界を支配するようになると主張したり、将来のモデルが何をできるかについて語ったりするつもりはない単に、今日のモデルが自分にとって役立つかどうかだけを論じるつもりであるなぜ言語モデルが有用だと正当化するために文章を書くのか、不思議に思うかもしれない。しかし、学術界、ソフトウェアエンジニアリング分野、メディア領域には、LLMは何の貢献もせず、単なるまたひとつの誇大広告サイクルにすぎず、数年後には世界に何の影響も与えずに消えると広く断言する人々がいるように見える私は、現在のLLMはすでに有用であるため、彼らは間違っていると主張するつもりだ逆に、今日のモデルはすべてのプログラマーを置き換えられ、人々はプログラミングを学ぶべきではないと主張する人たちもいる私は彼らの主張を明示的に反論しようとしているわけではない私は、LLMが多くの有害な影響をもたらしうることを十分に理解している。偽情報、虐待、監視、雇用の代替など、あらゆることを意味する。近いうちに、LLMの有害な影響についての考えを扱う文章を書く予定である。しかし、それは言語モデルが有用でありうるかどうかとは別の問題である私は、LLMが幻覚を起こし、事実を繰り返し、堅牢性に欠け、失敗する可能性があるため、使いたくないと思う理由をよく理解している。しかし、この記事はそれについてではない私は、このような失敗にもかかわらず、モデルは有用でありうると考えているこれらのモデルを訓練することの倫理性には疑問の余地がある。本人の許可なくその人のデータで訓練されていたり、モデルを明示的に訓練するために低賃金で働く人々のことを考えることができる。私は、これが問題であることに同意するこの記事はそれについてのものではない何度も言ってきたように、この記事は現在存在するモデルが有用かどうかだけを扱う私の背景私は基本的に、何かを簡単に信じるタイプではない。10年前、セキュリティコミュニティで暗号資産の誇大広告を目にしたが、ブロックチェーンに関する論文を書くことは完全に避けてきた。ビットコインを所有したこともない。あらゆる主張に懐疑的である誰かがこのAI技術は非常に有用で、日常の働き方を大きく変えるだろうと最初に言ったとき、私の反応は「自分の目で見るまでは信じない」だった私はセキュリティ研究者である。この10年間、AIモデルが訓練されていない環境に直面したときに、どれほどひどく失敗するかを示すのが日常業務だった。機械学習モデルへの入力を少し乱すだけで、出力を大きく誤らせたり、ほとんどの機械学習モデルが訓練データセット内の特定の例を記憶し、利用時にそれを繰り返すことを示したりしてきた。私は、こうしたシステムの限界を完全に理解しているそれにもかかわらず、私は現在の大規模言語モデルが、インターネットが作られて以来、最も大きな生産性向上をもたらしたと言っている。今日、ランダムに選ばれたプログラミング作業に対して、インターネットへのアクセスか最新の言語モデルへのアクセスのどちらかひとつを選ばなければならないなら、半分以上では言語モデルを選ぶだろう [ 私がLLMを使う方法 ] 自分のために完全なアプリケーションを構築する昨年、私はGPT-4が少数のタスクを解く能力をどれほど正確に予測できるかを試すクイズを作った。そのクイズはかなり人気を集め、1,000万回を超えるページビューを記録した。 GPT-4に、このアプリケーションの初期バージョンの大部分を書かせた。アプリケーションの基本構造を求めるところから始め、さまざまな機能を少しずつ構築していく一連の質問を通して進めたこの対話は合計3万語に達し、当時の最新GPT-4モデルの能力をフルに使った [実際のプロンプトと回答は省略します] 私はGPT-4との対話で、さまざまな形で依頼をした言葉で欲しいものを説明し、モデルに実装全体を求めるメッセージから、特定の変更を求めるメッセージ（"平均スコアと比較するのではなく、KDEを使ってパーセンタイルを示せますか？"）までエラーメッセージをコピーして貼り付けるだけの、まったく不完全な質問をするメッセージ（例: "Plotting: numpy.linalg.LinAlgError: singular matrix"）や、簡単な使い捨ての回答を求める場合（"文字列から読み込んだ内容を持つiframeをJavaScriptでページに追加するにはどうすればよいですか？"）も含まれる言語モデルが効果的な理由言語モデルは、人々が以前に解いたことをうまく解決するため、このやり方が有効なのであるこのクイズの99%は、他の誰かでも書ける、PythonのWebサーバーバックエンドを持つ基本的なHTMLにすぎなかったこのクイズが興味深く、人々に好まれた理由は、その背後の技術ではなく、クイズの内容にあった。そして、退屈な部分をすべて自動化すれば、クイズを作るのはとても簡単になる言語モデルの助けがなければ、おそらく私はこのクイズを作らなかったと確信している最初からWebアプリケーション全体を書くことに時間を費やす気がなかったからであるしかも、これはプログラミングのやり方を知っている人間の話である！私は、現在のモデルでさえ、大多数の人が解決策を求めるだけで、以前なら決してこなせなかった意味のある作業を実行できるほど十分だと信じている今後、モデルが私のためにアプリケーション全体を書いた事例をさらにいくつか紹介する予定であり、それらを公開するときには、言語モデルの助けで作られたことを明確にするつもりである新しい技術のためのチューターとしての役割以前は新しいフレームワークに追いつこうと努力していたが、一人の人間が使える時間には限りがある仕事柄、ほとんどの時間を最新の研究の進展を追うことに使っており、最新のJavaScriptフレームワークの進化までは追っていない。特定の研究領域以外で新しいプロジェクトを始めるとき、一般的には2つの選択肢がある 1つ目は知っているものを使うこと、 2つ目は新しい（たいていはより良い）方法を学ぶことだここで言語モデルが役に立つ。Docker、Flexbox、Reactのような新しいフレームワークやツールの大半は、他の人にとっては新しいものではない。世界にはそれらを徹底的に理解している人が数万から数十万人はいるはずだ。現在の言語モデルも同様だ。特定の読者を想定し、特定の目標達成を目指す静的なチュートリアルを読む代わりに、言語モデルと対話しながら、作業を解決するのに必要なことを学べる。今年の初めにLLM評価フレームワークを構築していたとき、LLMが生成したコードを制限された環境で実行したかった Dockerはこの作業に最適なツールだったが、以前に使ったことはなかった。 Dockerを使うこと自体がプロジェクトの目的ではなく、あくまで目的達成に必要な道具だった可能な限り最も基本的なやり方で安全に使えているという確信を持つために、Dockerの10%だけ理解したかった 90年代なら、基本原理からDockerの使い方まで説明した本を買い、最初の数章を読んでから飛ばし読みしつつ、やりたいことの方法を見つけ出していただろうこの10年ほどで、Dockerの使い方を説明するオンラインチュートリアルを検索して試し、エラーメッセージを検索して他の人も同じ問題に遭遇しているか確認する、という形に改善されただが今日では、言語モデルにDockerを教えてくれと頼めばよい Dockerをセットアップして動かしたあと、Linuxで実行すると権限の問題があることに気づいた。この問題を解決したくて、モデルに助けを求めたその過程でPodmanを知り、モデルにDocker専用コードを同等のPodman版へ書き換えてくれと頼んだそしてDockerコンテナにホストのGPUを渡す方法を知りたいときにも頼んだ新しいプロジェクトを始める子どものころ、最初のプログラミング言語はJavaだった。プログラミング自体は大好きだったが、新しいプロジェクトの空白の画面を見るのが本当に嫌だった。特にJavaでは！ Hello Worldプログラムをコンパイルするだけでも、public static void main string argsが何をするのか、括弧はどこに置くのか、どの文字をまた大文字にするのか、中括弧や角括弧がなぜあちこちにあるのかを理解するのが難しかっただから子どもなら誰でもやりそうなことをした。父に代わりにやってくれと頼んだ 20年たった今でも、慣れていないフレームワークで新しいプロジェクトを始めるのはやはり嫌いだボイラープレートを取り除くのに時間がかかりすぎるし、自分が何をしているのか理解できないたとえば最近、誰かの効率的で最適化されたCPU実装と比較して、GPU上でいくつかの素朴なGreedy探索の性能をベンチマークするためにCUDAコードを書いてみたかったしかし、CUDAプログラムの書き方がわからない Cの書き方は知っているし、GPUの動作やカーネルの仕組み、メモリレイアウトなども理解しているしかし実際にGPUへ仕事を送るコードをどう書けばいいのかはわからないそこでモデルに、CUDAプログラムの最初のパスを書いてくれと頼んだ完璧か？まったく違う！だが、それは出発点になる。そしてそれこそが自分の求めているものだここではコードに多くの誤りがあることがわかる実際、それはまったく問題ではない完璧な解決策を探しているのではなく、出発点を探しているからだ今後モデルがさらに良くなれば、それは素晴らしいことだろうだが、いま手元にあるものだけでもすでに大いに助けになっている。それとはまったく別に、家で進めている別の個人プロジェクトではRaspberry Pi Pico Wを使っているこれを使うのは初めてだった特にネットワーク関連の作業をさせたかったもちろん、やりたいことを実現する方法を説明した良いチュートリアルをオンラインで見つけることはできるだろうしかし最近インターネット検索をすると、上位5件はたいてい2008年のバグ入りコードを載せたゴミのようなコンテンツファームで、SEOのためだけに更新されていて、しかもいまだに動かないそこで代わりに、言語モデルに自分のやりたいことの方法を教えてくれと頼んだ以前にマイクロコントローラを扱ったことがあるので、それがどう動くかは大まかに理解しているしかしPico Wを触ったことはないすべての依存関係を含めて、始めるのを助けてくれるものさえあれば、残りは自分で何とかできた新しいマイクロコントローラでいつも最初に書く"hello world"プログラムは、LEDを点滅させるものだこれによって、そのデバイス向けにコードをコンパイルしてアップロードできるか、すべてのピンが正しく設定されているか、基本的に自分が何をしているのかを確認できるだから単に点滅プログラムを頼めばいい。（繰り返すが、こういうものはインターネット上にあるのか？ほぼ確実にある。だが、その場合は自分で探さなければならない。）このコードを動かせば、次に何をすべきかがわかる Pythonがどう動くかは知っている（信じるかどうかは別として！）だから特別なMicroPython作業を済ませて、そこからそのまま編集を続けられるそして特別な扱いが必要な別の問題にぶつかったら、モデルに助けを求めればいいたとえばここでは、モデルにWiFiへ接続するスクリプトを書いてくれと頼む流れになるさらにMQTTサーバーへ接続しなければならないなど、また行き詰まるたびにモデルへ助けを求めればよい今ではこれを継続的にやっている。このセクション冒頭の例でさえ仮説ではない HTMLレイアウトを学ぶ新しい方法が、テーブルではなくdivを使うことだったので、Flexboxの使い方を尋ねているコードを単純化するセキュリティ研究者として、私はしばしば他人の数千行に及ぶ研究プロジェクトを含む新しいリポジトリを受け取り、それがどう動くのかを把握して攻撃しなければならない状況に置かれるみんながきれいなコードを書いてくれればそれほど難しくはないのだが、現実はそうではない研究者にはきれいなコードを公開するインセンティブがないそのため、しばしば人は動くゴミコードを提出する。（私もそうする）ここで共有できる研究関連の例はないが、自分が取り組んでいる個人プロジェクトの例なら共有できる私はコンウェイのライフゲームに不健全なほど執着している最近、Pythonでいくつかのライフパターンを評価する高速な方法を探していたこれを行う優れたC++ツールとしてgollyがあるが、PythonコードをC++に書き直したくはなかった gollyには、やりたいことを実行できるCLIツールがある必要だったのは、それを正しく呼び出す方法だけだったそのための第一歩は、約50種類のコマンドラインオプションをサポートするC++コードを取り出し、自分のやりたい1つの処理だけを正確に行うようにすることだったそこで500行のC++コードを丸ごとLLMに投入し、同じ作業をするもっと短いファイルを頼んだそれでどうなったか？完璧に動いたそのあと、そのC++コードを包むPythonラッパーも頼んだ。それもやはりうまく動いたこれは面倒すぎて、著者自身なら絶対にやらなかったであろう作業の1つだだが今では、ただ頼めばよいので、元のPythonコードより100倍速いものを手に入れた私はこういうことをかなり頻繁にやっている。Pythonでまったく同じことをする別の例もあるこれらの作業はどれも難しくないだが、こうするたびにかなりの時間を節約できるそしてこれこそが、今日のLLMが驚くべきものだと私が思う理由の1つだ派手ではないし、「人生を楽にするためにLLMを使った退屈な方法です」と言ってもインターネット上のポイントはあまり稼げないだろうが、これが実際に起きていることだ単調な作業を自動化する考える必要はなく退屈だが、やらなければならない仕事はたくさんある作業を先延ばしにする主な理由のひとつは、それをやり遂げるのがイライラして苦痛だと分かっているからだ LLMはこうした苦痛を大幅に減らしてくれるし、面白い問題だけを解けばよいと分かっているので、何かを始めるのがずっと簡単になるここでは、LLMに依頼して解決したごく日常的な問題を見ていくたとえば最近、Python 3.9で書かれたPythonプログラムを逆アセンブルしなければならなかったほとんどのPythonディスアセンブラはPython 3.7以前でしか動作せず、3.9のバイナリでは実行できなかった逆アセンブルは本当に難しい作業というわけではない。主に goto を追いながら制御フローを再構成し、ミスをしないことが大半だ何百行ものコードについて何千ものop-codeを手作業で変換するのに時間を費やす代わりに、LLMに代わりにやってもらうよう頼んだすると本当にうまくやってくれた。できると思っていたより、はるかにはるかに良かった別の例として、非構造化データを持ってきて構造化された形式に整形しなければならないときがあるたとえば、あるプロジェクトをしていて、著者名付きの書名リストが必要だったそこでオンラインで非構造化形式のデータを見つけ、LLMに整形してもらうよう頼んだあるいは最近、ある防御を突破した方法についてのブログ記事を書いていて、変更しなければならなかったコードの完全なdiffを見せたかったそこで、(1) diff と (2) diffをHTML化する方法についての以前の例を貼り付け、LLMにこのdiffを以前の形式で提示してくれと頼んだもうひとつの例として、仕事の一環でよく使うリソースの引用文を生成しなければならないことがある Google Scholarは論文についてはこれを簡単にしてくれて、引用文をコピーして貼り付けるだけでよいしかし、ウェブページを引用するのは少し面倒だ最近ではLLMに引用文を生成してくれと頼むことがある。（念のため言うと、私はこれが正確かどうか確認している！）こういう例なら、少なくともあと100個は挙げられるだろう。だが要点は伝わったと思う誰かが見て「それだけ??」と言うかもしれないタイプの仕事だということは十分に理解しているしかし5年前には、彼らはせいぜい一貫した段落をつなぎ合わせることしかできず、問題全体を解決してはくれなかったことを覚えておいてほしいすべてのユーザーを「パワーユーザー」にする自分よりずっと不慣れな人が何かの道具を使っているのを見たことがあるなら、それはかなりつらいものになりうるある種のマクロや並列アプリケーションを賢く使えば自動化できる作業に、何分も、ときには何時間も費やしているのを見ることがあるしかし、それを行うのに必要な呪文を覚えるには時間がかかるし難しいたとえば最近、Apple Lisaのキーボードでキーボード入力を処理するPythonプログラムを書こうとしていたオンラインでこれをCで行うものを書いた人を見つけたが、#define KEYNAME key_code のような文がたくさんあったこれを、整数コードを対応する文字列にマッピングするPython辞書に変換したかった私はEmacsユーザーだ。Emacsでこの問題をどう解くかは知っている。そんなに難しくはないはずだ。次は、この効果を出せた直後に記録した主なキーストロークだ: C-h C-s #def [enter] M-f [delete] C-d M-f C-[space] M-f C-w C-a C-y : " M-f ", C-g C-] } C-[ { これは私にはほとんど自然なことだが、これが自然になるまで、私は人生の半分以上をEmacsに十分習熟するために費やしてきた。だが今、もしLLMがエディタにつながっていたら、何を入力するだろうか？ C-h C-h rewrite these #defines to a dictionary of {keycode: string, ...} すると突然、目の前でテキストが書き換わるこのような場合、LLMの潜在的な有用性は、専門家よりも非専門家にとっての方が高いと思うモデルは誰にとっても基準を引き上げてくれ、以前はまったくできなかったことが、突然ずっと多くできるようになる APIリファレンスとして使う本物のプログラマーは、道具の動作を知りたいときにはリファレンスマニュアルを読むしかし私は怠け者のプログラマーなので、ただ答えをそのまま教えてほしいだから今では言語モデルに聞くこういう例を見せると、防御的に反応して「LLMは、あなたがすでに持っている道具でできないことは何もしていない！」と言う人がいるそして彼らは正しいしかし、物理的な本でできないことで検索エンジンにできることはなく、ソースコードを読めばできないことで物理的な本にできることもないしかし、それぞれは順に前より簡単になっているそして何かが簡単になると、それをより頻繁に、質的に異なるやり方で行うようになるプロンプトを含む事例「Bashでは、残りのすべての引数を表す $ はどれか」と尋ねて答えを得る。（その直後に「これをどう使うのか」という別の質問が続く！）あるいは、LaTeXでテキストを赤くする方法を知りたいとき、もはや検索したり文書を読んだりせず、モデルに尋ねるそして、さまざまなGDBコマンドに対応するLLDBコマンドが何かを知りたいときも同じようにするあるいは、一部の find コマンドがどう動作するのかを知りたいときも lpr の使い方も LaTeXコマンドを再バインドする方法も実際、これは私がLLMを最も頻繁に使う方法のひとつだこうした例をさらに何千個も並べられない唯一の理由は、EmacsにもシェルにもLLMに問い合わせるツールが組み込まれているからだだから90%の場合、この種のことをやりたいときには、エディタを離れる必要すらない見つけにくいものを検索するインターネットでコンテンツを検索することは、以前は苦労して身につけた技術だったクエリに含めたい特定の単語は何か？複数形にすべきか？単数形か？過去形か？ページに現れてほしくない単語は何か？ X AND Y が欲しいのか、それとも X OR Y なのか？もうそうではない Google で OR を使ったクエリを最後に書いたのがいつだったか思い出せない結果のサブセットを除外するためにマイナス（-）を使った最後の時期も思い出せない今日ではたいていの場合、探したいものをそのまま書けば検索エンジンが見つけてくれる。しかし検索エンジンは、依然として100%自然言語のクエリではないいまだに Reverse-Jeopardy のゲームをしているような感じで、質問ではなく答えに使うキーワードを使おうとしているこれは、私たちのほぼ全員が身につけたことを忘れてしまった技術だ言語モデルは、今日ではいくつかの単純な作業については、ただ単により優れている（そして時間がたつほどそうした作業は増えている）ただ「では + が add に相当するのは分かったけど、~ は何？」と入力すれば、inv という答えを教えてくれるこれは標準的な検索エンジンでは検索するのが非常に難しいことだ答えを見つける方法があることは分かっているおそらく「python documentation metaclass add」と入力して、それからページ内で ~ を検索すれば答えが得られるはずだしかし、LLM に自分の質問をそのまま尋ねるのもうまくいくこうすることで節約できるのは一度にせいぜい数秒にすぎないが、何かコーディング作業を解決していて、すでに一度に何百万ものことを処理しようとしているときには、解決したいことをそのまま吐き出して一貫した答えを得られるだけでも驚くほど助かるとはいえ、今日の時点で彼らがこの仕事に完璧だというわけではない言語モデルは、オンライン上にあるものが十分な頻度で繰り返されているときにしか知らない「十分な頻度」が何を意味するかはモデルによって異なるので、モデルに聞くべきかインターネットに聞くべきかを考えるのに、何度か思考のサイクルを使わなければならないしかしモデルはこれからも進化し続けるだろうあるいは、ランダムな衝突が起きるたびに、見えているものをモデルにそのまま投げて説明を求めることもあるここで「Remote wildcard transfer issue」と入力しているのはそういうことだまったく別の例として、昨年ブログ記事を書いているとき、最初の単語の最初の文字を大きくして、その周りに残りのテキストを回り込ませたいと思っていたこれはドロップキャップと呼ばれる。しかしそのことを知らなかった欲しい効果だけは分かっていたので、言語モデルに「テキストが O の周りを回り込む、素敵な本みたいに見せたい」と尋ねたら、まさに欲しかったものをくれたこの作業もまた「LLM があったからこそやった」というカテゴリに入るこれをどうやるかを突き止めるのに多くの時間を使う価値はないと思っていただろうしかしモデルに聞けたのでそうしたし、そのおかげで私の投稿は少しだけ見栄えが良くなった単発作業を片づけるプログラムには2種類ある第一に、きちんと作りたいプログラムがある。これらはしばらく存在し、何年にもわたって保守しなければならないので、整然としていることが重要だ第二に、25秒だけ存在するプログラムがある。これらは何らかの作業を完了するのを助け、すぐに捨てられるコードの品質をまったく気にせず、プログラムが完全に独立しているこういうケースでは、今ではほぼ全面的に LLM を使って書いている注意: こうしたケースの大半もやはり「それだけ？」と言いたくなるようなものだしかし先ほども言ったように、あるプロジェクトに投じられる1日の時間には限りがあるそして二度と使わないプログラムを書く時間と精神的エネルギーを節約できるなら、そうする最もよくある例は、おそらく何らかの研究実験の結果として生成したデータを可視化するプロットを作るのを助けてもらうことだろうこういう例は何十個もある。たぶん 0 より 100 に近い。どれも基本的に同じように見えるので、ここでは1つだけ書いておくもう1つ似た例は、ある形式のデータを持っていて、それを別の形式のデータに変換したいときだたいていこれは一度だけやればよく、終わったら結果のスクリプトは捨てる欲しいスクリプトが十分に単純なら、LLM に全部書いてくれるよう頼むことが多い例えばここでは、LLM に論文を音読するスクリプトを書いてもらい、ばかな文法上の問題がないか確認できるようにしているたいていの場合、欲しいものがまだはっきりしていないときは、まずモデルに初期コードを頼み、そこから反復していく例えば、ここにデータをすばやく処理しなければならない単発作業がある 2022年なら、これを Python で書くのに2分使い、一度しか実行しないのだから何時間も走るのを待いていただろう最適化するのにかかる時間のほうが、その Python プログラムの実行時間より長くなるはずだしかし今は？私は同じ2分を、自分のデータ処理をやってくれる Rust のコードを頼むことに使うはずだと確信しているあるいは別の例として、モデルにデータセットをダウンロードして初期処理をしてくれるよう頼むこともある自分でやるのは簡単か？おそらくそうだろうしかしこれは、自分が考えたい作業ではない私は、そのデータセットで行う研究について考えたい気を散らす要素を取り除くことは、節約できる数分以上の価値があるまた別のときには、小さなキューブでピクセル化された画像を3Dプリントできるようにするプログラムを書いていたそのために PNG を STL ファイルに変換したかったが、これはプロジェクトの本題ではなかったただ途中で発生しなければならないことにすぎなかった。だから LLM にこれを解決してくれと頼んださらに別の例として、最近 Docker Compose を使って新しいプロジェクトを設定したいと思っていた問題が起きていて、何が何でもとにかく動かしたくて、何が悪かったのかは後で調べるつもりだったそれで結局、エラーメッセージを1つずつコピーするだけで何度もやり取りし、最終的には動く解決策を得た。また、多くの場合、完全な解決策を頼むことから始めて、その後でそれをどう修正するかのヒントを求めている自分に気づくここのこの会話では、HTML を解析するプログラムを頼むところから始めて、そこから API リファレンスや改善方法のヒントを求めているまた別のときには、コンピュータが時間とともにどれだけメモリと CPU を使うのか追跡したいと思った適切なコマンドを見つけ出して、自分の望むことをするスクリプトにまとめるのに数分使うこともできただろうが、代わりに言語モデルにやってもらうよう頼んだ最近、少し電子工作をしようとしていて、Arduino で動く C のプログラムがあったのだが、それを MicroPython の Raspberry Pi Pico で動かしたかったこの変換プロセスには興味深いものは何もない。ただ完了されるべきものだだから自分で作業する代わりに、言語モデルに代わりにやってもらうよう頼んだ別のプロジェクトでは、ある対話ループ向けの素敵な ML モデルでいくつかの画像を分類する必要があった自分で書くこともできただろうが、単にモデルに代わりにやってもらうよう頼むこともできた私に何かを説明してくれること私は最近、電子工作に興味を持ち始めた。子どもの頃に電子機器をいじっていて、大学でもいくつか授業を受けた。しかし、いざ実際にプロジェクトをやろうとすると、知らない何千もの細かなことのせいで、何かを作るのが難しい。実用電子工学の本を読むこともできるし、そうすればその分野をちゃんと理解できるのだろうが、勉強しているような形で時間を使いたくはない。電子工作をやる理由の半分は、一日中論文を読んだり書いたりすることから離れるためだからだ。ここでLLMのよいところは、世界で最も物知りな人ほど博識ではないにせよ、私が持ちうる電子工作関連の質問の答えを知っている人が何千人、何百万人もいるということだ。だから言語モデルも、おそらくその答えを知っているはずだ。しかも、あらゆる質問に喜んで答えてくれるので、細部と格闘せずに自分が求める楽しさを味わえる。インターネットで検索すれば、もう少し手間をかければ答えにたどり着けるのだろうが、複雑な研究コードに一日中取り組んだあと、モデルに頼むだけで済むという便利さはとても快適だ。そこで、ここに言語モデルへ電子工作の仕組みに関する基本的な質問をした例をいくつか載せておく。これらの答えは完璧か？さあ、どうだろう。でも、何も知らないよりはましではある。（この記事はかなり長くなってきたし、このあたりまで来ると読むのと同じくらい書くのにも疲れているはずだ。なので、説明抜きでこれらの例だけ置いておく。） PCB設計に関する基本的な質問はんだ付けに関する基本的な質問コンデンサに関する基本的な質問 LEDに関する基本的な質問フロッピーディスクに関する基本的な質問まだ続けられるが、要点は伝わったと思う。既知の解決策で作業を片づける誰かがすでにやっていることが、ほとんどすべてだ。本当に新しいことをやろうとしている場合はほとんどない。そして言語モデルは、以前に見たことのあるものに対する解決策を提示するのが非常に得意だ。最近のプロジェクトでは、Pythonコードの一部の性能を改善する必要があった。 (1) LLMにそれをCに書き直してほしいと頼み、さらに (2) PythonからCコードを呼び出せるインターフェースを作ってほしいと頼んだ。これらの作業は「難しい」わけではない。 PythonからCへの変換は、1〜2時間もあればできるはずだ。そしてPython->C APIがどう動くのか正確には知らなくても、ドキュメントを読めば理解できるだろう。しかし、自分でやることになっていたら、絶対にやっていなかった。重要な経路にあるわけではないので、頻繁に実行する必要のない処理を速くするために時間を使うくらいなら、待ってコンピュータに仕事を片づけさせたほうがよい。しかし、単純なプログラムなら、PythonからCへの変換は（ほとんど）機械的な作業であり、標準のPython->C呼び出し規約も実質ひとつしかない。だから、代わりにLLMにやってもらえばよい。それ以来、これは自分にできることだと期待するようになり、基本的に高速なコード片が必要になるたび、Pythonでやりたいことを説明して最適化されたCを求めるようになった。別の場面では、Cの出力と比べたときにRustの出力の正確さのほうが判断しやすそうなら、Cの代わりにRustの出力を求めることもある。別の例として、multiprocessingライブラリを使ってPython関数を並列化するのは難しくない。少し定型コードを書けば、基本的にはそれだけで動く。しかし、そのコードを書くのは少し面倒で、本当にやりたい作業の邪魔になる。今では、これが必要になるたびに、代わりにLLMにやってもらっている。あるいは、何らかのAPIをテストするとき、最初は curl リクエストを書いて、とりあえず動かすことがよくある。そしてそれが動き、プログラムから繰り返し実行したくなったら、Pythonに変換する。以前はたいてい本当にひどいやり方をして、単に os.popen() を呼び出して curl コマンドを実行していたが、これはよくない。 Pythonの requests ライブラリに変換したほうがよい。しかし、それには時間がかかるので、やらない。けれど今では、代わりにLLMにやってもらえば、よりきれいなプログラムをより速く手に入れられる。ここで、おそらく今後話すことになるプロジェクトのために、人々が簡単な無線送信機でどんな種類のものを使っているのか知る必要があった。私が本当に欲しいのは、ほどほどに詳しい人間の答えなので、LLMは完璧な選択だった！よくあるエラーを修正する 2022年以前は、有名なツールやライブラリでエラーメッセージが出たら、次のような手順を踏んでいた。エラーメッセージをコピーする Googleに貼り付ける一番上のStack Overflowリンクをクリックするその質問が自分の聞きたいことか確認する。違えば2に戻る一番上の解決策を自分の作業に適用する動かなければ2に戻って検索語を変え、祈るなどする正直に言えば、たいてい壊れるツールは、最終的に解決したい作業から5段階くらい離れていて、実際どう動いているかなど本当は気にしておらず、とにかく動いてくれればよい。では2024年の今はどうか？エラーメッセージをコピーする LLMに「このエラーはどう直せばいいですか？ [エラー]」と尋ねる LLMが提案した段階的な解決策を適用する動かなければ「動きませんでした」と伝えるこれに関する例として見せられる記録はない。（あるいは1時間探しても見つからなかった。）しかし、これには実際ちゃんとした理由がある。これをワークフローに直接組み込んだからだ。私はEmacsユーザーだ。プログラムを実行して、0以外のステータスコードで終了するたびに（つまり問題が起きたという意味だ）、自動的に最新かつ最速クラスのLLMを呼び出して、その回答を説明させると同時に、コードのバグを修正するためにそのまま適用できるパッチも求めるよう、環境を設定してある。現在のモデルは、まだほとんどの場合この作業で作者を上回るほど十分によくはないが、だんだん近づいてきている。そして時おり、どこかのタイプミスのせいで追跡が悪夢になりそうだと分かっているバグをLLMが直してくれると、うれしい驚きがある。まとめ上でリンクした会話はすべて、昨年私がLLMと交わした会話全体の2%未満にすぎない。他の会話をリンクしなかったのは、そのモデルが失敗した事例だからではなく（もちろんそういう事例も多いが）、 (1) すでにリンクした会話と同じパターンの繰り返しになるか、 (2) 何が起きているのか説明しにくく、なぜ有用なのかを直接確認するのが難しいからだ。今後もこうしたモデルの利用は増え続けると予想している。参考までに、2023年と比べて2024年にはWebインターフェース経由のLLMクエリを30%多く実行しており、APIクエリの増加は集計できていないが、少なくとも2倍か3倍にはなっていると思う。 LLMにできないことではなく「できること」を評価するべき面接で候補者を評価する際には、彼らができないことよりも、できることに注目すべきである LLMに些細な質問を投げると、無能に見えることがある。たとえば、10億人が使う中国語で質問したとしても、うまく答えられないかもしれないコンピュータ工学の中でも、SQLのSELECT文くらいしか分からないなど、知らない分野は多いオンラインで、LLMが特定のtaskを実行できないことを理由に誇大宣伝だと主張するのは理解しがたい文の単語数を数えられないすべての単語がaで始まる詩を書けない 2桁の掛け算ができないリストからランダムな要素を選べないしかし、こうしたことを実際にやるときに、LLMが適した道具だと思ったことがあるのか疑問である 64ビット整数の除算を暗算でできないからといって人間が役に立たないとは言わないのと同じで、LLMが解けない問題を作ったからといってLLMを軽視するのは妥当ではない重要なのは、LLMが価値を提供できるtaskがあるかどうかであるプログラマーは、目的によって異なる言語が有用であることをすでによく理解しているオペレーティングシステムを書くには、PythonよりCのほうが適している Pythonが変数を32バイト境界に整列できないとは言わない。単に抽象化のレベルが違うだけである LLMも同じように、非常に高いレベルの抽象化で動作している単純なプログラムでも解決できる作業をLLMに期待するのは難しいしかし、別の種類の作業なら解決できると期待できる結論この記事を書いた動機は2つある LLMが個人的にすでに大きな価値を提供していることを主張するため LLMのアイデアは良いが、自分にどう役立つのか分からない人たちに活用例を示すため LLMの価値 LLMは何でもできるわけではないが、現在のモデルだけでもかなりの価値を提供しているたとえばCUDAエラーを診断し、パッケージを再インストールする方法を教えたり、Cでプログラムを書き直したり、特定のテーマについて教えたりできるこれは大学生でも数時間頑張ればできることだが、いつでも質問に答えてくれる大学生はいない。一方で、LLMならそれが可能である LLMの進歩と現在の状況 5年前のLLMは、もっともらしい英語の段落を書くのがせいぜいで、実用性は皆無だったしかし今日のLLMは、プログラミング作業の生産性を少なくとも50%向上させ、退屈な作業を取り除いてくれる LLMsのおかげで、試していなかったであろうプロジェクトもいくつも完成させた LLMsの有用性に対する反論「LLMは誇大宣伝で、実質的な価値はない」という主張に反対する個人的には、LLMが大きな価値を提供している 20年のプログラミング経験がある私でさえ、LLMによって生産性が大きく向上している私以外にも、LLMsの恩恵を受けられる人は多いと思う今後の展望現在のモデルだけでも多くの価値を提供している今後5年間でLLMがどう進化するのか、期待と不安が入り混じっている次の記事でこれについての予測を扱う予定である

(nicholas.carlini.com)

65 ポイント投稿者 xguru 2024-08-06 | 7件のコメント | WhatsAppで共有

この1年ほど、毎週何時間も大規模言語モデルとやり取りしながら、ますます難しい作業をこなす能力に継続して感銘を受けてきた
- その結果、研究プロジェクトや個人プロジェクトでのコード作成速度が少なくとも50%向上した
オンラインでLLMの有用性について語る人の多くは、たいてい過度に楽観的か、過度に悲観的である
将来についての議論よりも、この1年でLLMを活用して研究能力を高め、コーディングプロジェクトを助けるために使った50の対話例を示したい
私のLLM活用例
- これまで使ったことのない技術で、Webアプリ全体を構築した
- さまざまなフレームワークの使い方を、実際に最初から触らなくても学んだ
- 何十ものプログラムをCまたはRustに変換し、性能を10〜100倍改善した
- 大規模なコードベースを削減して、プロジェクトを大幅に単純化した
- この1年で、ほぼすべての研究論文の初期実験コードを書いた
- ほぼすべての単調な作業や使い捨てスクリプトを自動化した
- 新しいパッケージやプロジェクトのセットアップ・設定のためのWeb検索をほぼ完全に置き換えた
- エラーメッセージのデバッグのためのWeb検索の約50%を置き換えた
これを分類すると2つになる
1. 学習の補助: 以前なら難しかったことができるようになる
2. 退屈な作業の自動化: 自分が最も得意なことに集中し、難しい問題を解けるようにする
最も重要なのは、これらの事例が実際にLLMを活用して助けを得た方法だという点である
- 印象的な機能を見せるためではなく、実際の業務を処理しなければならない自分の必要から生まれたものだ

Nuance

インターネットがあまり得意ではないことのひとつは、ニュアンスである。私は、今日のLLMが世界を支配するようになると主張したり、将来のモデルが何をできるかについて語ったりするつもりはない
- 単に、今日のモデルが自分にとって役立つかどうかだけを論じるつもりである
なぜ言語モデルが有用だと正当化するために文章を書くのか、不思議に思うかもしれない。しかし、学術界、ソフトウェアエンジニアリング分野、メディア領域には、LLMは何の貢献もせず、単なるまたひとつの誇大広告サイクルにすぎず、数年後には世界に何の影響も与えずに消えると広く断言する人々がいるように見える
- 私は、現在のLLMはすでに有用であるため、彼らは間違っていると主張するつもりだ
逆に、今日のモデルはすべてのプログラマーを置き換えられ、人々はプログラミングを学ぶべきではないと主張する人たちもいる
- 私は彼らの主張を明示的に反論しようとしているわけではない
私は、LLMが多くの有害な影響をもたらしうることを十分に理解している。偽情報、虐待、監視、雇用の代替など、あらゆることを意味する。近いうちに、LLMの有害な影響についての考えを扱う文章を書く予定である。しかし、それは言語モデルが有用でありうるかどうかとは別の問題である
私は、LLMが幻覚を起こし、事実を繰り返し、堅牢性に欠け、失敗する可能性があるため、使いたくないと思う理由をよく理解している。しかし、この記事はそれについてではない
- 私は、このような失敗にもかかわらず、モデルは有用でありうると考えている
これらのモデルを訓練することの倫理性には疑問の余地がある。本人の許可なくその人のデータで訓練されていたり、モデルを明示的に訓練するために低賃金で働く人々のことを考えることができる。私は、これが問題であることに同意する
- この記事はそれについてのものではない
何度も言ってきたように、この記事は 現在存在するモデルが有用かどうかだけを扱う

私の背景

私は基本的に、何かを簡単に信じるタイプではない。10年前、セキュリティコミュニティで暗号資産の誇大広告を目にしたが、ブロックチェーンに関する論文を書くことは完全に避けてきた。ビットコインを所有したこともない。あらゆる主張に懐疑的である
誰かがこのAI技術は非常に有用で、日常の働き方を大きく変えるだろうと最初に言ったとき、私の反応は「自分の目で見るまでは信じない」だった
私はセキュリティ研究者である。この10年間、AIモデルが訓練されていない環境に直面したときに、どれほどひどく失敗するかを示すのが日常業務だった。機械学習モデルへの入力を少し乱すだけで、出力を大きく誤らせたり、ほとんどの機械学習モデルが訓練データセット内の特定の例を記憶し、利用時にそれを繰り返すことを示したりしてきた。私は、こうしたシステムの限界を完全に理解している
それにもかかわらず、私は現在の大規模言語モデルが、インターネットが作られて以来、最も大きな生産性向上をもたらしたと言っている。今日、ランダムに選ばれたプログラミング作業に対して、インターネットへのアクセスか最新の言語モデルへのアクセスのどちらかひとつを選ばなければならないなら、半分以上では言語モデルを選ぶだろう

[ 私がLLMを使う方法 ]

自分のために完全なアプリケーションを構築する

昨年、私はGPT-4が少数のタスクを解く能力をどれほど正確に予測できるかを試すクイズを作った。そのクイズはかなり人気を集め、1,000万回を超えるページビューを記録した。
GPT-4に、このアプリケーションの初期バージョンの大部分を書かせた。アプリケーションの基本構造を求めるところから始め、さまざまな機能を少しずつ構築していく一連の質問を通して進めた
この対話は合計3万語に達し、当時の最新GPT-4モデルの能力をフルに使った
- [実際のプロンプトと回答は省略します]
私はGPT-4との対話で、さまざまな形で依頼をした
- 言葉で欲しいものを説明し、モデルに実装全体を求めるメッセージから、特定の変更を求めるメッセージ（"平均スコアと比較するのではなく、KDEを使ってパーセンタイルを示せますか？"）まで
- エラーメッセージをコピーして貼り付けるだけの、まったく不完全な質問をするメッセージ（例: "Plotting: numpy.linalg.LinAlgError: singular matrix"）や、簡単な使い捨ての回答を求める場合（"文字列から読み込んだ内容を持つiframeをJavaScriptでページに追加するにはどうすればよいですか？"）も含まれる
言語モデルが効果的な理由
- 言語モデルは、人々が以前に解いたことをうまく解決するため、このやり方が有効なのである
- このクイズの99%は、他の誰かでも書ける、PythonのWebサーバーバックエンドを持つ基本的なHTMLにすぎなかった
このクイズが興味深く、人々に好まれた理由は、その背後の技術ではなく、クイズの内容にあった。そして、退屈な部分をすべて自動化すれば、クイズを作るのはとても簡単になる
言語モデルの助けがなければ、おそらく私はこのクイズを作らなかったと確信している
- 最初からWebアプリケーション全体を書くことに時間を費やす気がなかったからである
- しかも、これはプログラミングのやり方を知っている人間の話である！
私は、現在のモデルでさえ、大多数の人が解決策を求めるだけで、以前なら決してこなせなかった意味のある作業を実行できるほど十分だと信じている
今後、モデルが私のためにアプリケーション全体を書いた事例をさらにいくつか紹介する予定であり、それらを公開するときには、言語モデルの助けで作られたことを明確にするつもりである

新しい技術のためのチューターとしての役割

以前は新しいフレームワークに追いつこうと努力していたが、一人の人間が使える時間には限りがある
仕事柄、ほとんどの時間を最新の研究の進展を追うことに使っており、最新のJavaScriptフレームワークの進化までは追っていない。
特定の研究領域以外で新しいプロジェクトを始めるとき、一般的には2つの選択肢がある
- 1つ目は知っているものを使うこと、
- 2つ目は新しい（たいていはより良い）方法を学ぶことだ
ここで言語モデルが役に立つ。Docker、Flexbox、Reactのような新しいフレームワークやツールの大半は、他の人にとっては新しいものではない。世界にはそれらを徹底的に理解している人が数万から数十万人はいるはずだ。現在の言語モデルも同様だ。
特定の読者を想定し、特定の目標達成を目指す静的なチュートリアルを読む代わりに、言語モデルと対話しながら、作業を解決するのに必要なことを学べる。
今年の初めにLLM評価フレームワークを構築していたとき、LLMが生成したコードを制限された環境で実行したかった
- Dockerはこの作業に最適なツールだったが、以前に使ったことはなかった。
Dockerを使うこと自体がプロジェクトの目的ではなく、あくまで目的達成に必要な道具だった
- 可能な限り最も基本的なやり方で安全に使えているという確信を持つために、Dockerの10%だけ理解したかった
90年代なら、基本原理からDockerの使い方まで説明した本を買い、最初の数章を読んでから飛ばし読みしつつ、やりたいことの方法を見つけ出していただろう
- この10年ほどで、Dockerの使い方を説明するオンラインチュートリアルを検索して試し、エラーメッセージを検索して他の人も同じ問題に遭遇しているか確認する、という形に改善された
だが今日では、言語モデルにDockerを教えてくれと頼めばよい
- Dockerをセットアップして動かしたあと、Linuxで実行すると権限の問題があることに気づいた。この問題を解決したくて、モデルに助けを求めた
- その過程でPodmanを知り、モデルにDocker専用コードを同等のPodman版へ書き換えてくれと頼んだ
- そしてDockerコンテナにホストのGPUを渡す方法を知りたいときにも頼んだ

新しいプロジェクトを始める

子どものころ、最初のプログラミング言語はJavaだった。プログラミング自体は大好きだったが、新しいプロジェクトの空白の画面を見るのが本当に嫌だった。特にJavaでは！
- Hello Worldプログラムをコンパイルするだけでも、public static void main string argsが何をするのか、括弧はどこに置くのか、どの文字をまた大文字にするのか、中括弧や角括弧がなぜあちこちにあるのかを理解するのが難しかった
だから子どもなら誰でもやりそうなことをした。父に代わりにやってくれと頼んだ
20年たった今でも、慣れていないフレームワークで新しいプロジェクトを始めるのはやはり嫌いだ
- ボイラープレートを取り除くのに時間がかかりすぎるし、自分が何をしているのか理解できない
たとえば最近、誰かの効率的で最適化されたCPU実装と比較して、GPU上でいくつかの素朴なGreedy探索の性能をベンチマークするためにCUDAコードを書いてみたかった
しかし、CUDAプログラムの書き方がわからない
- Cの書き方は知っているし、GPUの動作やカーネルの仕組み、メモリレイアウトなども理解している
- しかし実際にGPUへ仕事を送るコードをどう書けばいいのかはわからない
- そこでモデルに、CUDAプログラムの最初のパスを書いてくれと頼んだ
- 完璧か？まったく違う！だが、それは出発点になる。そしてそれこそが自分の求めているものだ
ここではコードに多くの誤りがあることがわかる
- 実際、それはまったく問題ではない
- 完璧な解決策を探しているのではなく、出発点を探しているからだ
- 今後モデルがさらに良くなれば、それは素晴らしいことだろう
- だが、いま手元にあるものだけでもすでに大いに助けになっている。
それとはまったく別に、家で進めている別の個人プロジェクトではRaspberry Pi Pico Wを使っている
- これを使うのは初めてだった
- 特にネットワーク関連の作業をさせたかった
- もちろん、やりたいことを実現する方法を説明した良いチュートリアルをオンラインで見つけることはできるだろう
- しかし最近インターネット検索をすると、上位5件はたいてい2008年のバグ入りコードを載せたゴミのようなコンテンツファームで、SEOのためだけに更新されていて、しかもいまだに動かない
そこで代わりに、言語モデルに自分のやりたいことの方法を教えてくれと頼んだ
- 以前にマイクロコントローラを扱ったことがあるので、それがどう動くかは大まかに理解している
- しかしPico Wを触ったことはない
- すべての依存関係を含めて、始めるのを助けてくれるものさえあれば、残りは自分で何とかできた
新しいマイクロコントローラでいつも最初に書く"hello world"プログラムは、LEDを点滅させるものだ
- これによって、そのデバイス向けにコードをコンパイルしてアップロードできるか、すべてのピンが正しく設定されているか、基本的に自分が何をしているのかを確認できる
- だから単に点滅プログラムを頼めばいい。（繰り返すが、こういうものはインターネット上にあるのか？ほぼ確実にある。だが、その場合は自分で探さなければならない。）
このコードを動かせば、次に何をすべきかがわかる
- Pythonがどう動くかは知っている（信じるかどうかは別として！）
- だから特別なMicroPython作業を済ませて、そこからそのまま編集を続けられる
そして特別な扱いが必要な別の問題にぶつかったら、モデルに助けを求めればいい
- たとえばここでは、モデルにWiFiへ接続するスクリプトを書いてくれと頼む流れになる
さらにMQTTサーバーへ接続しなければならないなど、また行き詰まるたびにモデルへ助けを求めればよい
今ではこれを継続的にやっている。このセクション冒頭の例でさえ仮説ではない
- HTMLレイアウトを学ぶ新しい方法が、テーブルではなくdivを使うことだったので、Flexboxの使い方を尋ねている

コードを単純化する

セキュリティ研究者として、私はしばしば他人の数千行に及ぶ研究プロジェクトを含む新しいリポジトリを受け取り、それがどう動くのかを把握して攻撃しなければならない状況に置かれる
- みんながきれいなコードを書いてくれればそれほど難しくはないのだが、現実はそうではない
- 研究者にはきれいなコードを公開するインセンティブがない
- そのため、しばしば人は動くゴミコードを提出する。（私もそうする）
ここで共有できる研究関連の例はないが、自分が取り組んでいる個人プロジェクトの例なら共有できる
- 私はコンウェイのライフゲームに不健全なほど執着している
- 最近、Pythonでいくつかのライフパターンを評価する高速な方法を探していた
- これを行う優れたC++ツールとしてgollyがあるが、PythonコードをC++に書き直したくはなかった
gollyには、やりたいことを実行できるCLIツールがある
- 必要だったのは、それを正しく呼び出す方法だけだった
- そのための第一歩は、約50種類のコマンドラインオプションをサポートするC++コードを取り出し、自分のやりたい1つの処理だけを正確に行うようにすることだった
- そこで500行のC++コードを丸ごとLLMに投入し、同じ作業をするもっと短いファイルを頼んだ
それでどうなったか？完璧に動いた
- そのあと、そのC++コードを包むPythonラッパーも頼んだ。それもやはりうまく動いた
これは面倒すぎて、著者自身なら絶対にやらなかったであろう作業の1つだ
- だが今では、ただ頼めばよいので、元のPythonコードより100倍速いものを手に入れた
私はこういうことをかなり頻繁にやっている。Pythonでまったく同じことをする別の例もある
これらの作業はどれも難しくない
- だが、こうするたびにかなりの時間を節約できる
- そしてこれこそが、今日のLLMが驚くべきものだと私が思う理由の1つだ
- 派手ではないし、「人生を楽にするためにLLMを使った退屈な方法です」と言ってもインターネット上のポイントはあまり稼げないだろうが、これが実際に起きていることだ

単調な作業を自動化する

考える必要はなく退屈だが、やらなければならない仕事はたくさんある
作業を先延ばしにする主な理由のひとつは、それをやり遂げるのがイライラして苦痛だと分かっているからだ
- LLMはこうした苦痛を大幅に減らしてくれるし、面白い問題だけを解けばよいと分かっているので、何かを始めるのがずっと簡単になる
- ここでは、LLMに依頼して解決したごく日常的な問題を見ていく
たとえば最近、Python 3.9で書かれたPythonプログラムを逆アセンブルしなければならなかった
- ほとんどのPythonディスアセンブラはPython 3.7以前でしか動作せず、3.9のバイナリでは実行できなかった
逆アセンブルは本当に難しい作業というわけではない。主に goto を追いながら制御フローを再構成し、ミスをしないことが大半だ
- 何百行ものコードについて何千ものop-codeを手作業で変換するのに時間を費やす代わりに、LLMに代わりにやってもらうよう頼んだ
- すると本当にうまくやってくれた。できると思っていたより、はるかにはるかに良かった
別の例として、非構造化データを持ってきて構造化された形式に整形しなければならないときがある
- たとえば、あるプロジェクトをしていて、著者名付きの書名リストが必要だった
- そこでオンラインで非構造化形式のデータを見つけ、LLMに整形してもらうよう頼んだ
あるいは最近、ある防御を突破した方法についてのブログ記事を書いていて、変更しなければならなかったコードの完全なdiffを見せたかった
- そこで、(1) diff と (2) diffをHTML化する方法についての以前の例を貼り付け、LLMにこのdiffを以前の形式で提示してくれと頼んだ
もうひとつの例として、仕事の一環でよく使うリソースの引用文を生成しなければならないことがある
- Google Scholarは論文についてはこれを簡単にしてくれて、引用文をコピーして貼り付けるだけでよい
- しかし、ウェブページを引用するのは少し面倒だ
- 最近ではLLMに引用文を生成してくれと頼むことがある。（念のため言うと、私はこれが正確かどうか確認している！）
こういう例なら、少なくともあと100個は挙げられるだろう。だが要点は伝わったと思う
誰かが見て「それだけ??」と言うかもしれないタイプの仕事だということは十分に理解している
- しかし5年前には、彼らはせいぜい一貫した段落をつなぎ合わせることしかできず、問題全体を解決してはくれなかったことを覚えておいてほしい

すべてのユーザーを「パワーユーザー」にする

自分よりずっと不慣れな人が何かの道具を使っているのを見たことがあるなら、それはかなりつらいものになりうる
- ある種のマクロや並列アプリケーションを賢く使えば自動化できる作業に、何分も、ときには何時間も費やしているのを見ることがある
しかし、それを行うのに必要な呪文を覚えるには時間がかかるし難しい
たとえば最近、Apple Lisaのキーボードでキーボード入力を処理するPythonプログラムを書こうとしていた
- オンラインでこれをCで行うものを書いた人を見つけたが、#define KEYNAME key_code のような文がたくさんあった
- これを、整数コードを対応する文字列にマッピングするPython辞書に変換したかった
私はEmacsユーザーだ。Emacsでこの問題をどう解くかは知っている。そんなに難しくはないはずだ。次は、この効果を出せた直後に記録した主なキーストロークだ:
C-h C-s #def [enter] M-f [delete] C-d M-f C-[space] M-f C-w C-a C-y : " M-f ", C-g C-] } C-[ {
これは私にはほとんど自然なことだが、これが自然になるまで、私は人生の半分以上をEmacsに十分習熟するために費やしてきた。だが今、もしLLMがエディタにつながっていたら、何を入力するだろうか？
C-h C-h rewrite these #defines to a dictionary of {keycode: string, ...}
すると突然、目の前でテキストが書き換わる
このような場合、LLMの潜在的な有用性は、専門家よりも非専門家にとっての方が高いと思う
- モデルは誰にとっても基準を引き上げてくれ、以前はまったくできなかったことが、突然ずっと多くできるようになる

APIリファレンスとして使う

本物のプログラマーは、道具の動作を知りたいときにはリファレンスマニュアルを読む
- しかし私は怠け者のプログラマーなので、ただ答えをそのまま教えてほしい
- だから今では言語モデルに聞く
こういう例を見せると、防御的に反応して「LLMは、あなたがすでに持っている道具でできないことは何もしていない！」と言う人がいる
- そして彼らは正しい
- しかし、物理的な本でできないことで検索エンジンにできることはなく、ソースコードを読めばできないことで物理的な本にできることもない
しかし、それぞれは順に前より簡単になっている
- そして何かが簡単になると、それをより頻繁に、質的に異なるやり方で行うようになる
プロンプトを含む事例
- 「Bashでは、残りのすべての引数を表す $ はどれか」と尋ねて答えを得る。（その直後に「これをどう使うのか」という別の質問が続く！）
- あるいは、LaTeXでテキストを赤くする方法を知りたいとき、もはや検索したり文書を読んだりせず、モデルに尋ねる
- そして、さまざまなGDBコマンドに対応するLLDBコマンドが何かを知りたいときも同じようにする
- あるいは、一部の find コマンドがどう動作するのかを知りたいときも
- lpr の使い方も
- LaTeXコマンドを再バインドする方法も
実際、これは私がLLMを最も頻繁に使う方法のひとつだ
- こうした例をさらに何千個も並べられない唯一の理由は、EmacsにもシェルにもLLMに問い合わせるツールが組み込まれているからだ
- だから90%の場合、この種のことをやりたいときには、エディタを離れる必要すらない

見つけにくいものを検索する

インターネットでコンテンツを検索することは、以前は苦労して身につけた技術だった
- クエリに含めたい特定の単語は何か？複数形にすべきか？単数形か？過去形か？
- ページに現れてほしくない単語は何か？ X AND Y が欲しいのか、それとも X OR Y なのか？
もうそうではない
- Google で OR を使ったクエリを最後に書いたのがいつだったか思い出せない
- 結果のサブセットを除外するためにマイナス（-）を使った最後の時期も思い出せない
- 今日ではたいていの場合、探したいものをそのまま書けば検索エンジンが見つけてくれる。
しかし検索エンジンは、依然として100%自然言語のクエリではない
- いまだに Reverse-Jeopardy のゲームをしているような感じで、質問ではなく答えに使うキーワードを使おうとしている
- これは、私たちのほぼ全員が身につけたことを忘れてしまった技術だ
言語モデルは、今日ではいくつかの単純な作業については、ただ単により優れている（そして時間がたつほどそうした作業は増えている）
- ただ「では + が add に相当するのは分かったけど、~ は何？」と入力すれば、inv という答えを教えてくれる
これは標準的な検索エンジンでは検索するのが非常に難しいことだ
- 答えを見つける方法があることは分かっている
- おそらく「python documentation metaclass add」と入力して、それからページ内で ~ を検索すれば答えが得られるはずだ
- しかし、LLM に自分の質問をそのまま尋ねるのもうまくいく
こうすることで節約できるのは一度にせいぜい数秒にすぎないが、何かコーディング作業を解決していて、すでに一度に何百万ものことを処理しようとしているときには、解決したいことをそのまま吐き出して一貫した答えを得られるだけでも驚くほど助かる
とはいえ、今日の時点で彼らがこの仕事に完璧だというわけではない
- 言語モデルは、オンライン上にあるものが十分な頻度で繰り返されているときにしか知らない
- 「十分な頻度」が何を意味するかはモデルによって異なるので、モデルに聞くべきかインターネットに聞くべきかを考えるのに、何度か思考のサイクルを使わなければならない
- しかしモデルはこれからも進化し続けるだろう
あるいは、ランダムな衝突が起きるたびに、見えているものをモデルにそのまま投げて説明を求めることもある
- ここで「Remote wildcard transfer issue」と入力しているのはそういうことだ
まったく別の例として、昨年ブログ記事を書いているとき、最初の単語の最初の文字を大きくして、その周りに残りのテキストを回り込ませたいと思っていた
- これはドロップキャップと呼ばれる。しかしそのことを知らなかった
- 欲しい効果だけは分かっていたので、言語モデルに「テキストが O の周りを回り込む、素敵な本みたいに見せたい」と尋ねたら、まさに欲しかったものをくれた
- この作業もまた「LLM があったからこそやった」というカテゴリに入る
- これをどうやるかを突き止めるのに多くの時間を使う価値はないと思っていただろう
- しかしモデルに聞けたのでそうしたし、そのおかげで私の投稿は少しだけ見栄えが良くなった

単発作業を片づける

プログラムには2種類ある
- 第一に、きちんと作りたいプログラムがある。これらはしばらく存在し、何年にもわたって保守しなければならないので、整然としていることが重要だ
- 第二に、25秒だけ存在するプログラムがある。これらは何らかの作業を完了するのを助け、すぐに捨てられる
コードの品質をまったく気にせず、プログラムが完全に独立しているこういうケースでは、今ではほぼ全面的に LLM を使って書いている
注意: こうしたケースの大半もやはり「それだけ？」と言いたくなるようなものだ
- しかし先ほども言ったように、あるプロジェクトに投じられる1日の時間には限りがある
- そして二度と使わないプログラムを書く時間と精神的エネルギーを節約できるなら、そうする
最もよくある例は、おそらく何らかの研究実験の結果として生成したデータを可視化するプロットを作るのを助けてもらうことだろう
- こういう例は何十個もある。たぶん 0 より 100 に近い。どれも基本的に同じように見えるので、ここでは1つだけ書いておく
もう1つ似た例は、ある形式のデータを持っていて、それを別の形式のデータに変換したいときだ
- たいていこれは一度だけやればよく、終わったら結果のスクリプトは捨てる
欲しいスクリプトが十分に単純なら、LLM に全部書いてくれるよう頼むことが多い
- 例えばここでは、LLM に論文を音読するスクリプトを書いてもらい、ばかな文法上の問題がないか確認できるようにしている
たいていの場合、欲しいものがまだはっきりしていないときは、まずモデルに初期コードを頼み、そこから反復していく
- 例えば、ここにデータをすばやく処理しなければならない単発作業がある
- 2022年なら、これを Python で書くのに2分使い、一度しか実行しないのだから何時間も走るのを待いていただろう
- 最適化するのにかかる時間のほうが、その Python プログラムの実行時間より長くなるはずだ
- しかし今は？私は同じ2分を、自分のデータ処理をやってくれる Rust のコードを頼むことに使うはずだと確信している
あるいは別の例として、モデルにデータセットをダウンロードして初期処理をしてくれるよう頼むこともある
- 自分でやるのは簡単か？おそらくそうだろう
- しかしこれは、自分が考えたい作業ではない
- 私は、そのデータセットで行う研究について考えたい
- 気を散らす要素を取り除くことは、節約できる数分以上の価値がある
また別のときには、小さなキューブでピクセル化された画像を3Dプリントできるようにするプログラムを書いていた
- そのために PNG を STL ファイルに変換したかったが、これはプロジェクトの本題ではなかった
- ただ途中で発生しなければならないことにすぎなかった。だから LLM にこれを解決してくれと頼んだ
さらに別の例として、最近 Docker Compose を使って新しいプロジェクトを設定したいと思っていた
- 問題が起きていて、何が何でもとにかく動かしたくて、何が悪かったのかは後で調べるつもりだった
- それで結局、エラーメッセージを1つずつコピーするだけで何度もやり取りし、最終的には動く解決策を得た。
また、多くの場合、完全な解決策を頼むことから始めて、その後でそれをどう修正するかのヒントを求めている自分に気づく
- ここのこの会話では、HTML を解析するプログラムを頼むところから始めて、そこから API リファレンスや改善方法のヒントを求めている
また別のときには、コンピュータが時間とともにどれだけメモリと CPU を使うのか追跡したいと思った
- 適切なコマンドを見つけ出して、自分の望むことをするスクリプトにまとめるのに数分使うこともできただろうが、代わりに言語モデルにやってもらうよう頼んだ
最近、少し電子工作をしようとしていて、Arduino で動く C のプログラムがあったのだが、それを MicroPython の Raspberry Pi Pico で動かしたかった
- この変換プロセスには興味深いものは何もない。ただ完了されるべきものだ
- だから自分で作業する代わりに、言語モデルに代わりにやってもらうよう頼んだ
別のプロジェクトでは、ある対話ループ向けの素敵な ML モデルでいくつかの画像を分類する必要があった
- 自分で書くこともできただろうが、単にモデルに代わりにやってもらうよう頼むこともできた

私に何かを説明してくれること

私は最近、電子工作に興味を持ち始めた。
- 子どもの頃に電子機器をいじっていて、大学でもいくつか授業を受けた。
- しかし、いざ実際にプロジェクトをやろうとすると、知らない何千もの細かなことのせいで、何かを作るのが難しい。
実用電子工学の本を読むこともできるし、そうすればその分野をちゃんと理解できるのだろうが、勉強しているような形で時間を使いたくはない。
- 電子工作をやる理由の半分は、一日中論文を読んだり書いたりすることから離れるためだからだ。
ここでLLMのよいところは、世界で最も物知りな人ほど博識ではないにせよ、私が持ちうる電子工作関連の質問の答えを知っている人が何千人、何百万人もいるということだ。
- だから言語モデルも、おそらくその答えを知っているはずだ。
- しかも、あらゆる質問に喜んで答えてくれるので、細部と格闘せずに自分が求める楽しさを味わえる。
- インターネットで検索すれば、もう少し手間をかければ答えにたどり着けるのだろうが、複雑な研究コードに一日中取り組んだあと、モデルに頼むだけで済むという便利さはとても快適だ。
そこで、ここに言語モデルへ電子工作の仕組みに関する基本的な質問をした例をいくつか載せておく。
- これらの答えは完璧か？さあ、どうだろう。
- でも、何も知らないよりはましではある。
（この記事はかなり長くなってきたし、このあたりまで来ると読むのと同じくらい書くのにも疲れているはずだ。なので、説明抜きでこれらの例だけ置いておく。）
- PCB設計に関する基本的な質問
- はんだ付けに関する基本的な質問
- コンデンサに関する基本的な質問
- LEDに関する基本的な質問
- フロッピーディスクに関する基本的な質問
まだ続けられるが、要点は伝わったと思う。

既知の解決策で作業を片づける

誰かがすでにやっていることが、ほとんどすべてだ。
- 本当に新しいことをやろうとしている場合はほとんどない。
- そして言語モデルは、以前に見たことのあるものに対する解決策を提示するのが非常に得意だ。
最近のプロジェクトでは、Pythonコードの一部の性能を改善する必要があった。
- (1) LLMにそれをCに書き直してほしいと頼み、さらに
- (2) PythonからCコードを呼び出せるインターフェースを作ってほしいと頼んだ。
これらの作業は「難しい」わけではない。
- PythonからCへの変換は、1〜2時間もあればできるはずだ。
- そしてPython->C APIがどう動くのか正確には知らなくても、ドキュメントを読めば理解できるだろう。
- しかし、自分でやることになっていたら、絶対にやっていなかった。
- 重要な経路にあるわけではないので、頻繁に実行する必要のない処理を速くするために時間を使うくらいなら、待ってコンピュータに仕事を片づけさせたほうがよい。
しかし、単純なプログラムなら、PythonからCへの変換は（ほとんど）機械的な作業であり、標準のPython->C呼び出し規約も実質ひとつしかない。
- だから、代わりにLLMにやってもらえばよい。
それ以来、これは自分にできることだと期待するようになり、基本的に高速なコード片が必要になるたび、Pythonでやりたいことを説明して最適化されたCを求めるようになった。
別の場面では、Cの出力と比べたときにRustの出力の正確さのほうが判断しやすそうなら、Cの代わりにRustの出力を求めることもある。
別の例として、multiprocessingライブラリを使ってPython関数を並列化するのは難しくない。
- 少し定型コードを書けば、基本的にはそれだけで動く。
- しかし、そのコードを書くのは少し面倒で、本当にやりたい作業の邪魔になる。
- 今では、これが必要になるたびに、代わりにLLMにやってもらっている。
あるいは、何らかのAPIをテストするとき、最初は curl リクエストを書いて、とりあえず動かすことがよくある。
- そしてそれが動き、プログラムから繰り返し実行したくなったら、Pythonに変換する。
- 以前はたいてい本当にひどいやり方をして、単に os.popen() を呼び出して curl コマンドを実行していたが、これはよくない。
- Pythonの requests ライブラリに変換したほうがよい。しかし、それには時間がかかるので、やらない。
- けれど今では、代わりにLLMにやってもらえば、よりきれいなプログラムをより速く手に入れられる。
ここで、おそらく今後話すことになるプロジェクトのために、人々が簡単な無線送信機でどんな種類のものを使っているのか知る必要があった。
- 私が本当に欲しいのは、ほどほどに詳しい人間の答えなので、LLMは完璧な選択だった！

よくあるエラーを修正する

2022年以前は、有名なツールやライブラリでエラーメッセージが出たら、次のような手順を踏んでいた。
1. エラーメッセージをコピーする
2. Googleに貼り付ける
3. 一番上のStack Overflowリンクをクリックする
4. その質問が自分の聞きたいことか確認する。違えば2に戻る
5. 一番上の解決策を自分の作業に適用する
6. 動かなければ2に戻って検索語を変え、祈るなどする
正直に言えば、たいてい壊れるツールは、最終的に解決したい作業から5段階くらい離れていて、実際どう動いているかなど本当は気にしておらず、とにかく動いてくれればよい。
では2024年の今はどうか？
1. エラーメッセージをコピーする
2. LLMに「このエラーはどう直せばいいですか？ [エラー]」と尋ねる
3. LLMが提案した段階的な解決策を適用する
4. 動かなければ「動きませんでした」と伝える
これに関する例として見せられる記録はない。（あるいは1時間探しても見つからなかった。）しかし、これには実際ちゃんとした理由がある。これをワークフローに直接組み込んだからだ。
- 私はEmacsユーザーだ。
- プログラムを実行して、0以外のステータスコードで終了するたびに（つまり問題が起きたという意味だ）、自動的に最新かつ最速クラスのLLMを呼び出して、その回答を説明させると同時に、コードのバグを修正するためにそのまま適用できるパッチも求めるよう、環境を設定してある。
- 現在のモデルは、まだほとんどの場合この作業で作者を上回るほど十分によくはないが、だんだん近づいてきている。
- そして時おり、どこかのタイプミスのせいで追跡が悪夢になりそうだと分かっているバグをLLMが直してくれると、うれしい驚きがある。

まとめ

上でリンクした会話はすべて、昨年私がLLMと交わした会話全体の2%未満にすぎない。
他の会話をリンクしなかったのは、そのモデルが失敗した事例だからではなく（もちろんそういう事例も多いが）、
- (1) すでにリンクした会話と同じパターンの繰り返しになるか、
- (2) 何が起きているのか説明しにくく、なぜ有用なのかを直接確認するのが難しいからだ。
今後もこうしたモデルの利用は増え続けると予想している。
参考までに、2023年と比べて2024年にはWebインターフェース経由のLLMクエリを30%多く実行しており、APIクエリの増加は集計できていないが、少なくとも2倍か3倍にはなっていると思う。

LLMにできないことではなく「できること」を評価するべき

面接で候補者を評価する際には、彼らができないことよりも、できることに注目すべきである
LLMに些細な質問を投げると、無能に見えることがある。たとえば、10億人が使う中国語で質問したとしても、うまく答えられないかもしれない
コンピュータ工学の中でも、SQLのSELECT文くらいしか分からないなど、知らない分野は多い
オンラインで、LLMが特定のtaskを実行できないことを理由に誇大宣伝だと主張するのは理解しがたい
- 文の単語数を数えられない
- すべての単語がaで始まる詩を書けない
- 2桁の掛け算ができない
- リストからランダムな要素を選べない
しかし、こうしたことを実際にやるときに、LLMが適した道具だと思ったことがあるのか疑問である
64ビット整数の除算を暗算でできないからといって人間が役に立たないとは言わないのと同じで、LLMが解けない問題を作ったからといってLLMを軽視するのは妥当ではない
重要なのは、LLMが価値を提供できるtaskがあるかどうかである
プログラマーは、目的によって異なる言語が有用であることをすでによく理解している
- オペレーティングシステムを書くには、PythonよりCのほうが適している
- Pythonが変数を32バイト境界に整列できないとは言わない。単に抽象化のレベルが違うだけである
LLMも同じように、非常に高いレベルの抽象化で動作している
- 単純なプログラムでも解決できる作業をLLMに期待するのは難しい
- しかし、別の種類の作業なら解決できると期待できる

結論

この記事を書いた動機は2つある
- LLMが個人的にすでに大きな価値を提供していることを主張するため
- LLMのアイデアは良いが、自分にどう役立つのか分からない人たちに活用例を示すため
LLMの価値
- LLMは何でもできるわけではないが、現在のモデルだけでもかなりの価値を提供している
- たとえばCUDAエラーを診断し、パッケージを再インストールする方法を教えたり、Cでプログラムを書き直したり、特定のテーマについて教えたりできる
- これは大学生でも数時間頑張ればできることだが、いつでも質問に答えてくれる大学生はいない。一方で、LLMならそれが可能である
LLMの進歩と現在の状況
- 5年前のLLMは、もっともらしい英語の段落を書くのがせいぜいで、実用性は皆無だった
- しかし今日のLLMは、プログラミング作業の生産性を少なくとも50%向上させ、退屈な作業を取り除いてくれる
- LLMsのおかげで、試していなかったであろうプロジェクトもいくつも完成させた
LLMsの有用性に対する反論
- 「LLMは誇大宣伝で、実質的な価値はない」という主張に反対する
- 個人的には、LLMが大きな価値を提供している
- 20年のプログラミング経験がある私でさえ、LLMによって生産性が大きく向上している
- 私以外にも、LLMsの恩恵を受けられる人は多いと思う
今後の展望
- 現在のモデルだけでも多くの価値を提供している
- 今後5年間でLLMがどう進化するのか、期待と不安が入り混じっている
- 次の記事でこれについての予測を扱う予定である

7件のコメント

edunga1 2024-08-06

共感できる文章です。筆者は読むのが疲れるほど使いこなしていますね..;

> こういう例を何千個もさらに連結できない唯一の理由は、Emacsとシェルの両方にLLMをクエリするツールが組み込まれているから

私もターミナルウィンドウから離れないようです。怠け者の開発者はみんなこうやって使っているのではないかと思います。
簡単な問題ならcopilot.vimを使って適当なバッファを開き、自動補完される形で答えを引き出しています。
shellコマンドが思い出せないならcopilot-cliの??コマンドがあるので、検索する必要がありません。
コード補完ツールは、私が質問する前に意図を理解してコードを作り出します。

本文で言うように、どう検索すればいいかは分かっていても、LLMは堅苦しくせず自由に質問できるので、より気に入っています。

galadbran 2024-08-06

copilot-vim は私も使っているのですが、copilot-cli はどのことをおっしゃっているのかお伺いします。

edunga1 2024-08-06

https://www.npmjs.com/package/@githubnext/github-copilot-cli
です！

https://docs.github.com/ko/copilot/…
GitHub CLI の拡張版もありますが、使い方は少し異なります。

galadbran 2024-08-08

コマンドラインでもCopilotの助けを受けられていいですね、ありがとうございます！

wedding 2024-08-06

どう作るかは分かっているけど、タイピングするのが面倒なときはChatGPTにやらせます。
成果物をレビューできてこそ、うまく使えるのだと思います。

xguru 2024-08-06

筆者が強調するLLMの活用法は、1. 学習の補助 2. 退屈な作業の自動化、という点です。
最近の私にもちょうど当てはまります。最近やったことを思い返してみると、

OpenSCADコードでボードゲーム用オーガナイザーをデザインする

Fusion でやるよりも、OpenSCADコードを書いてもらうほうが後で再利用しやすいです。
パラメータ処理をお願いすると関数化もうまくやってくれるので、さまざまな場面で使えます。

カードをスキャンしたPDFから画像を抽出して、思い通りに調整する自動化ツールのPythonスクリプトを書く

日本語版がなかなか出なさそうなボードゲームをスキャンして日本語化する際に、こうした作業に使っています。

ショッピングモールのカートをコピーするJavaScriptを書く

複数の海外ボードゲーム通販サイトで購入したものを転送代行先に入力する作業を自動化しています。

もちろんLLMがなくてもできることではありますが、ただ指示するだけのほうが速いので、ライフハック用途には最適です。

helloppfm 2024-08-06

共感できる点が多いです。
私がAIを使いながら感じることと似ています。