Amazon Bedrockでいい感じのChatBotをプロトタイピングした
先日(2023年10月23日)、AWS主催のイベント『Amazon Bedrock Prototyping Camp』に参加してきたので、そのレポートです。
※スライド資料はWeb公開OKである旨の説明があったため、本記事ではそのいくつかを抜粋して載せてあります。
前置き/読み飛ばし可
筆者の属性(雑な説明)
ここ何年か、データアナリストとかデータサイエンティストとか呼ばれる仕事をしている
Pythonはそれなりに書ける (Python 3 エンジニア認定実践試験 合格)
「Fine Tuningごりごりやれ」と業務命令が下りると、涙目になりながら「はい……」と言うくらいにはモデル構築の業務経験は浅い
(分類モデルのレビューは一応できる)機械学習の基本は押さえているつもり
AWSよくわからん (Azureは認定資格AZ-900を持ってるのでクラウドは多少わかる)
OpenAI API ServiceはPlaygroundで動かして遊んでるがガチでLLM使ったアプリを組んだことはない
Amazon Bedrockとは
公式ページへのリンクは↓こちらです。
ひとことで表すと？
「LLMをはじめとした生成AIの基盤モデルをAPI経由でサクッと利用できるサービス」です。上記の公式ページでは「基盤モデルを使用して生成系 AI アプリケーションを構築およびスケーリングする最も簡単な方法」と謳っていますね。
CLIからpipコマンドを叩いて色んなライブラリをインストールしたり、大枚叩いてグラボを買ったりびくびくしながら高額インスタンスに課金したり、モデルパラメータを保存したGBオーダーの重たいファイルをダウンロードした果てにGPUのVRAMが足りなくてエラーが出て涙目になりながらパラメータいじって試行錯誤してなんとか動かしたり、そういうことをしなくても、サクッと動かせます。
"最も"と言えるかはわかりませんが、かなり簡単な方法です。
「基盤モデル」って何？
基盤モデル（きばんモデル、foundation model） は、自己教師あり学習や半教師あり学習（英語: Semi-supervised learning）により膨大なデータで学習した大規模人工知能モデルで、 様々な下流タスクに適用することができる。
個人的には”事前学習済みモデル”と言ったほうがしっくりくるのですが、LLMが転移学習やファインチューニングなしで別タスクに転用できるこのご時世にあっては、そんな言葉は廃れていくのかもしれません……。
OpenAI API Serviceじゃだめなの？
システムの要件次第ですが、OpenAI API Serviceを使ったChatBotを現行のプロダクトに組み込もうとした場合、いくつか課題があります。
サーバーが日本国外にあるため、入力されたデータが海外に送信・保存されることになる(API経由で送信したデータは学習には使われないものの、国外サーバーに一定期間保存されるため、セキュリティ要件が厳しい場合に課題となる)
AWS, GCP等、Azure以外のサービスを利用している場合、利用量の監視が面倒になる (クラウドサービスで直接モニタリングできない)
ほかにも色々あると思うのですが、冒頭に書いたようにインフラ運用ぜんぜんわからんマンなので許してください……(ググるとつよつよな人たちがAzure OpenAI Serviceと比較している記事があると思うので、詳細はそちらを参照ください。弊社つよつよインフラリーダーから見解をもらえたら、この記事にも追記します。)
Amazon Bedrock を使うと何が嬉しい？
「ひとことで表すと？」に書いたことのほかには──
システムがAWS上で完結する
複数の基盤モデルを同じインターフェースで使える
──などがあります。個人的にはClaudeのコンテキストウィンドウ(扱えるトークンの量)がGPT系よりずっと多いので「おぉぉ」とテンションが上がりました。また、ClaudeではプロンプトにXMLタグを用いることで文章や構造に意味を持たせることができるとのこと。それゆえにGPT系より回答をプロンプトで制御しやすい印象で、本気でプロダクトにLLMを組み込もうとするとここはありがたいところです。
どうすれば使える？
AWSのマネジメントコンソールから Amazon Bedrock にアクセスし、左側メニューの"Model Access"から利用したいモデルを有効化します。そのあとは有効化したモデルを使ってPlaygroundで遊んだり、SDKを使ってモデルを呼び出せるようになります。
チュートリアルの動画はこちら。
なお、チュートリアルの動画では説明されていませんが、デフォルトの状態ではモデルが有効化されていないため、先述したようにモデルを有効化してAccess Statusを"Access Granted"にする必要があります。Statusが "Available"の状態ではモデルを呼び出すことはできませんのでご注意ください。
いやAvailableなのに使えないとか、こんなん絶対ハマるやろ……と思っていたら、やはり先人の倒れた跡がありました。合掌。
（クラスメソッドさん、いつも人柱になっていただきありがとうございます……感謝しながら記事を読ませていただいてます。）
イベントについて
ここから本題のイベント内容です。
何やったの？
「Amazon Bedrockを初めて触ったその日のうちに、生成AIを用いた機能を製品に組み込む/本番環境にデプロイする」という企画でした。なかなかハードなゴール設定……。
午前
Amazon Bedrockの概要やAIプロジェクトの進め方に関する説明と、ハンズオンでBedrockの使い方を覚える時間でした。説明の中では、AIプロジェクトをビジネス的視点からどう捉えるか、プロジェクトを進める上でのチェックポイントは何か、といった点にも言及されていました。
具体的には「機械学習を製品・業務に適用できた回数」×「研究発表できた回数」の２軸で組織のAI活用度を分類し、組織の状態を測る……というものです。
その上で「継続的革新」にたどりつくためにはこういうステップが大事ですよ、こういうチェックポイントがありますよ、という説明を経てから午後の実装タイムに進みます。
これに関連するものとして「ML Enablement Workshop」があり、その資料がGitHubで公開されています。ハンズオン部分を除けば AWSを利用していない場合でも有用だと思いますので、失敗PJに巻き込まれて血の涙を流す前に、ぜひご一読ください。
午後
午前中の内容を踏まえて、もくもく会形式で企画・設計・実装・評価を行っていきデプロイを目指す時間が始まります。この時間はいきなり実装をスタートするのではなく、Checkpointsに従ってユースケースの検討から始まります。
これはその場で一人でひねりだすのはまぁまぁ無理ゲーというか、的を外してしまうことも少なくないので、AWSのアーキテクトの方々が参加者とディスカッションする形で進めていきました。
ビジネスユースケースは何か、それは顧客にどんな価値を提供するか、それはどんなKPIで測ることができるか……。そういう話をしていくと、結果として「それ生成AIいらなくない？」という結論になることもあります。
私は元々ユースケースを定めていたこと、誰にどんな価値を提供するか明確であったことがあり、ここは比較的スッと越えて実装に進んで行ったのですが、人/チームによってはこの議論に最後まで時間をかけていたところもあったようです。また、これ以降のチェックポイントでもはまりどころはあるようで、実装が完了しない人/チームもありました。
※私見ですが、後でキャッチアップできる限りは、ビジネスユースケースの決定にはいくら時間をかけてもよいと思います。価値を生まないものをつくっても、後で悲しくなるだけなので。誰も幸せにならない。
──なお、私個人の進捗は Checkpoints 4まで到達するも精度検証に至らず、でした。もっとも”動くもの”は出来上がったので、後日「こんなんどうスか？」と手元で動かしながら、社内の反応を確かめています。
※具体的に何をつくったかは、さすがに社外秘です。
感想は？
色々ごちゃまぜの感想で申し訳ないですが──
がっつり集中して作業できる時間があったので楽しかった
AI/機械学習PJをPoC止まり・企画倒れにしないためのレクチャーがあるのがありがたい。開発よりの発想が抜けない人(筆者含む)にはおすすめ。
AWSアーキテクトがそばにいて相談に乗ってもらえるのはぜいたく(17階では平日の業務時間内ならそんな感じで作業できるっぽいです)。
ClaudeのほうがGPT系よりプロンプトエンジニアリングの結果が出やすい気がする(比較してないけど)ので、エンジニアのメンタルにやさしい可能性ある
AWSでSaaS動かしてるならAWSで完結できるBedrockはありがたい(自明)
──という感じです。
招待制のイベントですが、AWSのPrototyping Campは度々行われているようですので、AWS利用企業のエンジニアの皆様は、機会があればぜひ参加してみてください。得るものは何かしらあると思います。
というわけで、AWSさんありがとうございました！！！
この記事が気に入ったらサポートをしてみませんか？