Solana Developer Hub Online #0: AIで始めるRustプログラミング
この記事は2023/11/24に開催したSolana Developer Hub Online #0で話をさせていただいた「AIで始めるRustプログラミング」を再編集したものになります
AIで始めるRustプログラミング
まず、はじめにRustプログラミング要素は先ほどのセッションで使いきってしまいました。プログラミングでAIを扱う話は下記のセッションを参照してください。
なのでここではもうちょっとAI寄りの話をして、AIを活用する方法を共有できればなと思います。
改めて自己紹介を。LLM大好きおじさんをやっています。LLMというか生成AI大好きおじさんで、去年の7月ぐらいに画像生成AIに出会ってからいろいろと触り続けています。
まず、はじめに注意があります。
AIの世界はスピードが速いので、今日話をしたことが明日には変わってるかもしれません。また、これから話す内容は基本的に私の経験に基づいた話であり、実は違うかもしれないということに注意してください。
何でわざわざこんな注意を言うのかと言うと、このセッションのある数日前にGitHub Copilot ChatのJetBrains IDEの利用ができるようになりまして。実際に使ってみたらこれはプログラミングのやり方が変わる・・・ということは私が作ってる資料が変わる・・・と、絶望していたからです。
AIの世界はスピードが早過ぎて怖いです。
基礎知識
というわけでまず簡単に基礎知識としてLLMを利用するにあたって、知っておくとLLMを使うにあたって知っておくと良い話を紹介します。
私はChatGPTをメインに利用しているので、ここでの話はだいたいChatGPTでの経験だと思ってください。
最近のモデルではだいぶマシになったのですが、LLMは入力に対して肯定しやすい傾向があります。
この図のように「これは大丈夫ですか？」と聞くと「はい、大丈夫です」と返してきます。大丈夫ではなくてもこう返しやすい傾向があります。
このケースでは大丈夫ですか、と聞くようなときは問題があるかを聞きたいので「これは問題ですか？」と聞く方がより聞きたいことを聞くことができます。ただし、問題がないときにこの聞き方をすると問題ではないことを問題があると返してくることもあるので、そのあたり注意してください。
このように言い回し1つで出力の傾向が変わります。
LLMはどのモデルでも入出力に制限があります。この図の例はOpenAIのGPT-4モデルの傾向ですね。
トークンというがわかりにくいのですが、日本語の場合はだいたい1文字1トークンぐらいで考えてもらうと良いです。なので128kトークンなら128,000文字。4kトークンなら4,000文字ですね。
そのため、全ての情報をLLMの入力に渡すことはできません。ある程度、情報は選別しなければなりません。
また、出力にも制限があるため、あまり長い結果を出力するようなことをさせることもできません。昔のモデルでは途中で回答が切れるというようなことが多かったですが、最近ではそもそも回答を省略するというような動作が多い印象があります。
このような制限があるため、LLMを使う際には何を入力して、何を出力するのか制御しなければなりません。
これはアプリケーションの実装によるのですが、一般的なLLMを使ったアプリケーションでは長い会話をすると前に言った内容を忘れます。
これはコンテキストウィンドウと呼ばれる方式が採用されていることが多く、先の入力トークン数の制限に対して、制限にかかったら古い会話を忘れるような仕組みになっているからです。
ただし、これはアプリケーションの実装によります。例えば11月にあったOpenAIのDev Dayで発表されたAssistant APIでは無限のスレッドを持つといっています。実際に検証された方の記事を見るとかなり長期で記憶を保持しているという結論でした。
そのため利用しているLLMのアプリケーションがどのような記憶方式を持っているかに合わせて、どのような入力をするのか意識しないといけません。
2023/11時点のLLMでは、まず1回の入力で期待した結果を出力させることはできないと考えてください。
これはLLMの傾向として複数の指示や、長い入力を行うと出力が荒くなりやすい傾向があると思っています。基本的に1つの入力に付き1つの指示を行い、結果に対してまた1つの指示をするぐらいが精度の高い出力を出しやすいです。
また、先ほど話した入出力のトークン数の制限もあり、小さなサイクルを回して大きなものを作ると意識してもらうといいです。
根本的な問題として、そもそも人間は1回で完全な指示を出すことも難しいですし、もしそんな指示を出せるなら自身の手を動かした方が早いです。
ここまでの話を簡単にまとめると、LLMにはLLM特有の癖があります。その癖を意識して、その癖に合わせていくことが大事です。
LLMは何だかんだ言って文字列を生成するだけなので、他の生成AIのように期待する結果を生成できるように意図的に入力を作っていくことが重要になります。
実演
では、簡単にどんな風にLLMと会話するのか実演をしてみましょう。
まず、何をしようかなと考えていたのですが、先ほどのセッションで作ったSolanaのプログラム（スマートコントラクト）を生成してみましょう。
これは正確な指示になっていないので、おそらく正確な出力にならないと思います。
例えば、整数値というけどそれは何バイトの整数なの？とか、インクリメント/デクリメントするということはオーバーフローについて考えないといけないけどどうするの？とか、そもそも提示している仕様が緩いためです。
何より出力のトークン数制限により、出力しきれないかと思います。
と、言っていたら、それっぽいのが出てきましたね。コードを確認したところ、おそらくこのコードは先ほどのセッションで作ったものと同じ動作をしそうです。
（まさかの1つのファイルに収めることで出力制限を回避してくるとは思わなかった）
ただ、このコードだけではSolanaのプログラムとして動作させることはできません。先ほどのサイクルを回す話の通り、Solanaのプログラムとして動作に必要な他のファイルを生成しましょう。
というので無事にCargo.tomlを生成することができました。
実際にはここで生成したファイルをコピーして、コンパイルを行い、エラーが出ればまたChatGPTに修正方法を尋ね、やりたいことができるようになるまでサイクルを回し続けます。
つまり、LLMを使うのは仕事で他の人に作業を依頼するのと同じようなものになります。
作業を受ける方で考えてみてください。不明瞭な指示や、矛盾のある指示ではどう作業すれば良いのか迷うことになります。そういうとき、人によっては一旦見える状態まで作り検討しやすいようにしたりすると思います。LLMもそういう振る舞いをすると考えると心の安寧を保ちやすいです。
ただ、このサイクルを回すのは人によっては自身でやった方が早いです。今回は比較的にサクサク進みましたが、もう少し複雑なものになるとやりとりが増えるし、うまく進まないこともあります。そういった方はツールをうまく活用しましょう。
では、もう1つだけ実演をしたいと思います。これは私がよくやっているタスクでコードレビューをやってみましょう。
前のセッションで作ったコードでレビューをしてみます。レビューは「下記のRustコードをレビューしてください」という簡単なプロンプトでも動作します。
いくつか指摘が出てきました。このレビュー内容に合わせてコードを修正するのもよいですが、指摘内容を掘り下げるというのも重要になってきます。
例えばDocumentationの指摘では一般論な指摘ではありますが、具体的にどこの関数でどのようなコメントがあると良いのかがわかりません。そこで追加で質問を行います。
このように追加で掘り下げることで、どのように直して欲しくて指摘したのかわかりますし、なによりコメントを考える手間が省けます。
このように何を指摘しているのか、何を言っているのかわからない、具体例に欠けるというときには指摘内容を掘り下げていくというのが大事になります。特に掘り下げることで知らなかった知識を得ることもできるので、レビューは成長のチャンスになります。
では、もう1つだけ掘り下げてみましょう。
本来であればチャットの入力欄から続けるのですが、先ほど話した通り会話が長くなると過去の会話を忘れてしまいます。特にコードレビューでは最初のコードを忘れてしまうとまずいため、会話は短くするのが望ましいです。
そういうときにどうするかと言うと、先ほどDocumentationについて掘り下げたメッセージを編集します。こうすることで先ほどのDocumentationのやりとりは忘れてしまいますが、代わりに最初のコードは覚えた状態を継続することができます。
こういった形でレビューでサイクルを回してコードを品質の高いものにしていきます。
しかし、このサイクルを回していると対応が不要な指摘が出てくることも多いです。そのような指摘はそのままスルーしてください。対応すべきかわからないというときは判断できるようになるまで掘り下げていくことが重要です。
というので、意思決定は人間の仕事になります。LLMはあくまでもタスクを行うだけであり、タスクとして何をやるのか、タスクの結果が求めた結果かを判断するのは人間の仕事になります。
もちろん、その領域自体をLLMが行うようなものもありはします。ただ、今回のようなケースではまだ人間の仕事になります。
余談ですが、怪しい、嘘っぽい回答のときには論理的に詰めていくと間違いを認めやすいです。最近のモデルは比較的に発言の撤回をしやすいのですが、昔のモデルでは自身の発言した内容に強いバイアスがかかりなかなか間違いを認めることはなかったです。個人的にはLLMに期待する結果を出力させる練習としてかなり面白かったです。
今回は比較的に簡単な入力で済ませましたが、実際にはもう少し複雑な入力することも多いです。そういった入力を何度もするのは大変なのでGPTsという機能はおすすめです。
こちらもOpenAIのDev Dayで発表された内容で、特定のタスクを実行するGPTを簡単に作れる機能で、かなり便利です。
ツールの紹介
最後に簡単にプログラミングで使えるツールを紹介します。
AIファーストのコードエディタのCursorです。これはLLMを使ってプログラミングするさいの体験としてかなりおすすめです。私はJetBrainsのIDEが好きなので移行はしませんでしたが、一度は触ってみることをおすすめします。
先ほどのセッションでも実演したCodium AIのIDEプラグインです。個人的な印象では今出ているLLMベースのテスト生成系のツールで最も優秀です。
PRのレビュー、レビューイ/レビューアの補助するようなツールも出ています。
日本だとこの2つが有名だと思います。PRを作成したさいの簡単なコードレビューとしても使えますし、レビューアとしてレビューするさいにコードが読み解けないときにすぐに解説してくれたりもするので、どちらかは入れておくと開発が捗ります。
ただ、ここはGitHubがCopilot for PRをリリース予定なので、おそらく本命はそちらになると思います。
Issueを作るとPRを作成してくれるというものもあります。試したところ期待したPRを作るのは少し難しい印象はあるのですが、Issueを書いたらPRができるという体験はとてもよかったので試すのをおすすめします。
ただ、こちらもGitHubがCopilot Workspaceとして同様の機能を発表しているので本命はそちらになると思います。
おわりに
というわけで、私はもうAIがないと開発できない身体になってしまいました。
もしかしたらこのセッションのタイトルをみて、LLMへの簡単な指示でアプリケーションを作れるようになる、LLMを使うことで開発生産性が爆上がりするなどを期待していた方もいらっしゃるかもしれませんが、現時点でのLLMはまだそこまでではありません。
個人的な意見になりますが今のLLMは人間の能力を補助し、より能力を向上させるという面が強いと思っています。
LLMを使うことで開発生産性が上がるのは間違いではないのですが、それは自動化のような生産性の向上ではなく、品質が向上することでスピードが上がるという面が強いです。
実際、3月ぐらいからLLMを使って開発作業をいろいろやっていましたが、開発速度は遅くなりました。設計時にLLMと相談して考慮漏れに気づきより深い設計をしたり、コードを書いたさいにレビューで今まで気づいていなかった問題を指摘され修正するようになったからです。
もちろん同じ高い品質を作るという面では間違いなくLLMを使った方が早くなっています。しかし、今までこれで良いとしていた開発内容と比較するとどうしても長くなりやすいです。
と、言うと開発速度という面だけをみているとLLMの採用に難色を示したくなるかもしれませんが、LLMを採用することで早期に問題を発見して、問題をコントロールできるようになる。質を上げることで開発速度の低下を招きにくいとメリットは大きいのでおすすめです。
以上が「Solana Developer Hub Online #0: AIで始めるRustプログラミング」で話した内容になります。
この記事が気に入ったらサポートをしてみませんか？