こんにちは、Infrabbitです。Bedrockいじくって遊ぼう企画4回目です。
Bedrock自体はいろんな機能が盛られまくってる最中なので、いろんな使い方ができるわけですが、ここではそのうちのいくつかの機能に絞りましょう。
まずは、Bedrockエージェントです。
基本は、Bedrockに「～～してよ」みたいな感じで依頼すると、Bedrockがあなたに代わってそれを実行してくれる、という仕掛けですね。いわゆるタスク実行型。Titanではサポートされていないので、Claude 3とかを有効化しましょう。呼び出すAPIはbedrock-runtimmeのconverse/invokeなどではなく、bedrockサブコマンドのInvoke-Agentになるかと思います。
ただし、当然ながら「実際に行う行動」そのもの、いわゆるタスクそのものはコードを作成する必要があります。AIがやるのは、「聞かれたことを解釈し、どのAPIにどういったリクエストを投げればいいか、そのLambdaをコールすればいいか」というところを判断します。
当然ですが、APIの仕様は固めないといけませんし、APIから何かを呼び出して処理する場合はその処理先も書かないといけません。なのでこのあたりは普通にコード書きなのですが、「ユーザーからのふわっとした言語による揺らぎのある指示」をアプリケーションの規定する「正規化/標準化された要求」に組み替えてもらえる仕組み、といえば多少わかりやすいでしょうか。
なので日本語で何か書いたらAIが全部やってくれるわけではないです。まあ、Co-Pilotとかに聞けば書くべきコードはだいたい書いてくれそうですがｗ
ちょっと作るものが多いのでエージェントはスルー。
次は、フロー。こちらは、エージェントとは異なってLLMに何かを判断させて次のパイプラインに流す、という仕掛け。いわゆるデータパイプラインですね。雑多なパターンのメトリクスデータ/ログデータなどのいくつかの異なる形式のデータがごちゃ混ぜで流れてるデータストリーム、なんてまあよくあるじゃないですか。Fluentdとかで。
で、まあ真面目にやってるとタグふったり形式で分岐させたりするわけですが、要はそこをLLMにやらせようぜ、という仕掛けですね。こちらもまあ作ったりするところが多いのでサンプルはスルーですが、だいたいイメージはわかるんじゃないでしょうか。細かいとこは作りながらやればいいんじゃないかなと思います。
で、最後に紹介したいのがナレッジベースです。
これは何か、というといわゆるRAG、拡張検索生成、というもので、こちらはむしろ一回やってみたほうがわかりやすいでしょう。
まずとりあえずS3バケットをなんか適当に用意します。なんでもよかったので、とりま、我々がちょいちょい触れることの多い個人情報保護の基本方針のPDFを持ってきました。これをさくっとS3に放り込んでおきます。
さて、それではナレッジベースを作っていきます。with vector storeで作成します。やることはそんなに多くありません。適当に説明をつけ、データソースを選択し、参照するファイル等を設定します。
最後にベクトル情報を作成するLLMエンジンを選択し、どこにベクトル情報を保存するかを選択します。とりあえず、Amazon Titan Embedded – v1を利用し、OpenSearch serverlessに保存することにします。
OpenSearchは旧Elasticsearchですので、試したあとはそちらも削除するのもお忘れなく。
ベクトル情報の生成はそれなりに時間がかかります。まあ部分トレーニングしてるようなものですしね。
作成が終わったら右のテストウィンドウでテストできます。モデルを選択し、データソースを選んだら同期します。
さて、では聞いてみましょう。
個人情報の保護に関する基本方針の1-(3)については、以下のような内容が一般的です。
1-(3) 個人情報の利用目的の特定
個人情報を取り扱う際は、あらかじめ利用目的を明確に定め、その目的の範囲内で適切に取り扱う。利用目的を変更する場合は、変更前の利用目的と関連性を有すると合理的に認められる範囲内で行う。利用目的を変更した場合は、変更後の利用目的を本人に通知または公表する。
つまり、個人情報の利用目的を明確に特定し、その範囲内で適切に取り扱うことが求められるというものです。利用目的の変更がある場合の手続きも定められています。
一般化された場合の1-(3)あたりに書かれていそうなことを適当にでっち上げている感じですね。このように、Q&Aなどを作成する場合のナレッジとしてRAGを用いることは非常に多いのですが、本来このRAGって実は結構作るのがめんどくさいわけです。
情報ソース用意して、一回ベクトルデータの作成して、ggufフォーマットにして保存して、基本モデルと連携して、みたいなことをやってたはずですが、GUI上でぽちぽちするだけで終わってしまいました。便利。というかなんだこのお手軽さは。
ぱっと思いつくだけでもConnectのLex botと連携できねぇかな、とかLambda呼ばせて連携とかいくらでも使い道がありそうなものです。
最低限の機能の確認が終わったら、ナレッジベースを消して、Opensearch Serverlessも消して、あとぼろぼろイージーに作成されるIAMロールも消しておきましょう。あとS3バケットもね。真面目にやるならこの辺はきっちり設計が要りますが、とりあえず動かす、とかならとてもイージーにやれるのがわかると思います。
さて、LLMを使って何かしよう、と思ったときに、LLMの勉強をするのはなんか本質ではないわけです。本来はそもそもサービスのデザインとかプロンプトエンジニアリングによってより高精度の回答を引き出す、というところに注力したいはずで、別にRAGがどーのとかタスクがどーのとかそのためにあれやってこれやって、とか、そもそもベクトルデータフォーマットがどーだとか、本業じゃなけりゃ脳みそにそれを入れておくスペースはできるだけ小さくしておきたい。というのが本音じゃないでしょうか。
でも世間様はAIだーLLMだーって騒ぐわけで、やらないわけにはいかないけれど、正直「ユーザー」で居たいんですよね。データサイエンティストになりたいわけじゃないので。ベンダー側になりたくない、というか。
そんな感覚に一番ぴたっとはまる感じなのが、こういったBedrockだったり、Lang Chainフレームワークだったり、という感じなのだと思います。で、言語がPythonに制約されるLang ChainよりもBedrockのほうがお手軽だなぁと。
まあ、Lang ChainはLang Chainでもっとやれることが多いので比較してもいいですし、そもそも「Lang ChainのバックエンドとしてBedrockを使用する」ことができるので、組み合わせてもいいわけです。
InfrabbitもLLMなんて正直真面目にかかわっていないので間違った内容もあるかもしれませんが、これくらい楽だと手軽に手を出しやすい、というのが正直な感想でしたね。
