こんにちは。 ニフクラエンジニアミートアップ事務局の鮫島です。
2024年1月17日(水)に第68回ニフクラエンジニアミートアップを開催しました。
昨年大ブレイクを果たした?「ChatGPT」以降、テック界隈のみならず生成系AIは注目を集める技術になりましたが、実際にビジネスで活用している人はまだまだ少数派だと思います。
今回はテクニカルライター&フルエンジニアとして幅広く活躍中の大澤文孝氏を講師にお招きして、インフラエンジニア向けのAI活用法についてお話いただきました。
ChatGPTってなに?
ChatGPTを知っているけど使っていないという人向けの解説から。
OpenAI社が提供している対話型のAIであり、入力欄に「プロンプト」と呼ばれる「質問・指示」を入れることで、回答が返ってくるというもの。
ChatGPTに限らず、生成AI全般に言えることですが、こういう特徴があります。
・回答が正しいとは限らない
・同じ質問・指示をしても同じ回答が得られない
この点は、LLM(大規模言語モデル)を使っていることに起因するそうです。
インターネットの情報を基に「ある語句の次にはどの語句が来る可能性が高いか?」を学習して、「確率論的にそれらしい回答をランダムに返しているだけ」とのこと。
確かに、DALL-EやMidjourneyでアニメ画っぽいイラストを生成したときに同じプロンプトでも同じキャラクターが出てくることは無かったですね。。
※LLMについて興味がある人は、大澤氏の電子書籍「10分10ページでわかる「LLMのいま」」もどうぞ。
ChatGPTが返す回答は「うさんくさい」ですし、実際に間違いも多いので、使う側は、「間違えている」前提で使わなければならないようです。
「ChatGPTがこれほど使い物になるとは思っていなかった」とおっしゃる大澤氏ですが、「聞き方が悪かった」ことに気が付いたそうです。
以前はプロンプトで「質問」をしていたが「指示」をするようしたら、かなり使える回答が得られることが判ったようで、何気に重要な気づきだと感じました。
「質問」をすると、「真偽不明の回答」が帰ってくるため、「真偽を確認する作業」が発生するので非常に効率が悪いですね。。
※ちなみにこの課題を技術的に解決するアプローチは後ほど別のLTで出てきます。
質問するな作業させろってことですね
大澤氏のChatGPT利用のブレイクスルーポイントは、「聞くものではなくやらせるもの」と気づいたときだったそうで、それ以降多くの活用アイデアが浮かび、「使えるChatGPT」になった模様。
GPT3.5 VS GPT4
「ChatGPT?自分、課金してGPT4使ってます」とちょっとドヤ顔で語っているエンジニアの姿を目撃したことがある人も多いはず。
無料版のGPT3.5と、課金すると使えるようになるGPT4の違いについても説明がありました。
小さな作業ならChatGPT3.5でも問題ないし、動作が高速というメリットもあるそうです。 とはいえ、ChatGPT4じゃないと使えない機能もあるし課金する(つまりChatGPTPlus)と、GPT3.5の処理速度も高速になるというメリットがあるので、バリバリ使う人は20ドル払う価値は十分ありそうですね。
インフラエンジニア的ChatGPTの使い方
ココからが本題です。 インフラエンジニアがChatGPTをどのように活用できるか?と言うお話ですが大きく分けると下記のようなものが考えられそう。
データ整理・生成(汎用、SIer全般)
CSV変換その他
ダミーデータの生成
コードの生成
バックアップ用のスクリプトの作成(解釈)
IaC(Infrastructure As Code)
CSVの変換や整形は、やはりマクロだよな…っていう人は「そんな手があったか」と思うかもしれませんね。IT業界もいろんな職場がありますので、最後はExcelで…というパターンは多いと思います。 繰り返し手動ではやりたくない作業には積極的に活用したいです。
IaCについては、世界中でChatGPTにコードを書かせて成功する事案がXでも沢山報告されているので、インターネット上で公開されているAWSのクラウドフォーメーションとかはベストプラクティスを学習すれば成功率は高そうです。
とはいえ、LLMなので「さっきできたのに今やったらできない」ことは、たまにあるようです。 今回の大澤氏のセッション中のデモで、そういう事案が発生していました。 「だいたいできる」ので間違ったら再度指示するなど根気よくやることも大事です。
まとめ
ChatGPTは、LLMを利用しているサービスだという前提なので 「こういう指示をだせばこういう回答が確実に得られる」という保証はありません。 しかし、どんな指示(プロンプト)を出すのがいいのかを考える「プロンプトエンジニアリング」が一つのスキルとなるかもしれません。
注目すべきは、ChatGPTは日本的なDX文脈で人気のあるRPAなどの自動化を凌駕する手軽さで自動化を実現できる可能性があることです。 RPAも、結局はコードを書かなくてはならないですが、ChatGPTならば「ノーコード」的に自動化を実現できるわけですね。
もっと詳しく知りたい人はぜひ、大澤氏の著書も読んでみてはいかがでしょうか。
詳しくは動画アーカイブもご覧ください。
ローカルLLMを複数組み合わせた話
続いて、プライム・ストラテジー株式会社の井元剛氏によるLTです。 大澤氏のセッションでも何度も話題にのぼった「LLM」のお話ですが、ずばり「LLMの弱点」である「回答が正しいかどうかわからない問題」をLLMを複数組み合わせることで克服しようとするお話。
まず、ローカルLLMがなぜ必要か?と言う前提の話です。
企業や組織が生成AI活用を考えるとき、コンプライアンスに違反するようなことはもちろん出来ない上に、会社の機密情報をChatGPTのプロンプトに入力するようなことは避けたいので、ローカルで動くAIを使いたいというニーズがあるそうです。
とはいえ、OSSのLLMをローカルで動かしても、なかなかChatGPTのような性能は出ない問題があります。そこでローカルLLMを複数組み合わせるという話がでてきます。
大澤氏のセッションでも「ChatGPTは間違った回答を返してくる」話は何度もでてきましたが、回答の正確さを確認するアプローチとして、複数の生成AIサービスに同じプロンプトを投げてその結果を別のサービスが評価することで正確な回答をユーザーに返すという合議制の通称「MAGIシステム」というのがあるそうです。 ただし、最低3つのサービスに課金する必要があるそうで、コスト的には割高になります
そこで考えられたのが、マルチエージェントシステムという方法論。
すでに、ChatDev、Autogen、CrewAIといったマルチエージェントのフレームワークが提供されていて、今回はCrewAIを使ったデモを見せてくださいました。
実際に協調動作させるLLMは下記の2つ。
・OpenHermes2.5Bモデル
・Solar10.7Bモデル
それぞれ特性が違うため、これらを強調動作させることにはメリットがあるとのこと。
これを、「NVIDIAのT4でオンボードメモリー16GBのちょっとしたゲーミングPCより性能が低いくらいの環境」で動かすデモを見せてくださいました。
これって、つよつよな自宅サーバー勢なら動かせそうなレベルなのか?
弊社のYouTubeチャンネルを調べて獲得ユーザー数を増やす方策を箇条書きで出してくれ」という指示を出していました。
リサーチャー役と日本語に変換してまとめる役が協調して動作していますが、ローカルで動いているので処理速度も速く、予想よりサクッと回答が得られました。
こういうローカルLLMの使い方なら、たとえば社内の過去のメールを学習させて一発で顧客サポート用のメール文面を生成するような使い方が出来そうですね。
詳しくはこちらの動画をご覧ください。
QAセッション
恒例のQAセッションですが、まだまだ手探り状態の人が多いせいか、普段よりは初心者っぽい質問が多かった気がしました。
自宅サーバーの話で毎回盛り上がるニフクラエンジニアミートアップなので、自宅ローカルLLMのハードウェア構成に関する質問が飛び出したり。 自宅サーバーでローカルLLMを動かす話は盛り上がりそうでした。
詳しくはこちらの動画をご覧ください。 youtu.be
ということで、インフラエンジニアのためのChatGPT入門大盛況でした。 自宅ローカルAI環境構築超入門・・・やってみたいですね!
それでは次回をお楽しみに。