はじめに
こんにちは、H×Hのセンリツ大好きエンジニアです。（同担OKです😉）
2024年6月20日(木)、21日(金)に開催されるAWS Summit Japanの2日目を参加してきました！
この記事では、2日目に行われたセッションの内容をまとめたものになります。
参加したセッション
基調講演 ビルダーとテクノロジーが加速する次のイノベーション
内容
生成AIにおけるイノベーション
下記の3層からなる
- 学習と推論
- 大量のモデルからFMを作成
- AWSは生成AI専用のチップを開発し、LLMの推論におけるコストを最大50%カット
- LLMのトレーニング時のエネルギー効率が25%向上
- LLMや基盤モデルを活用してアプリケーションを開発するためのツール
- ほとんどの企業がAmazon Bedrockを活用
- 多種多様なモデルを単一のAPIから利用できる
- 万能なモデルは存在しないため、ユースケースによる使い分けが必要
- LLMや基盤モデルを活用するアプリケーション
- 実際に企業が作成したプロダクト
- 電通ではマーケティングの自動化として、∞AIというサービスを生み出している
リニア中央新幹線での取り組み
列車をシステムで運用する自動運転構成で、徹底したデータドリブンな開発を行っている。
運転士による操作から遠隔制御へのイノベーションには、運行・保守・計画・管理が必要でありシステムを跨いだシームレスなデータ連携が必要である。
そのためにシステムの内製化と継続した最新技術の採用をデータ・ドリブン運営に向けて行う。
AWSとの取り組みではIoTや機械学習を活用しており、保守用車のリアルタイムでの状態監視を実現している。
動作音をインプットデータとして機械学習を行い、電気設備の異常検知を実現した。
Amazon Bedrock
Bedrockでは、生成AIのサードパーティモデルを単一APIで使用できる。
今日成功しているモダンビジネスは全てデータビジネスであり、データを最大限活用するためには、最も包括的なデータサービスが必要である。
そこで、自社データをBedrockで学習させ、ファインチューニングや検索拡張生成を行う。
また、データ保護は最優先課題であるため、Bedrockでは基盤モデルのトレーニングに顧客からのデータを活用しない点、顧客専用のVPC経由で接続する点が挙げられていた。
電通での活用事例 ∞AI
∞AIシリーズはBedrockを活用したサービス群である。
∞AIチャット for salesは3ヶ月で完成したサービスであり、不動産に関するユーザとのAIチャットから取られたリッチデータを人間が活用できる形に落とし込まれるものである。
チャット履歴からユーザカルテが作成される。
基本情報だけでなく住みたい意思や場所、更にはペルソナ像の作成から特別感の演出をトークスクリプトとして生成できる。
開発にはAmazon Qを使用している。
Amazon Qはコードの説明を付与したり、数分で任意のモデルを使用することが出来るコードを生成してくれるため、Bedrockでの開発が捗る。
自然言語によるコード提案だけでなく、Qを使うだけでLambda関数の処理内容を変更できる。
所感
このサミットで初めて知ったBedrockとQが活用事例と共に紹介されており、非常に興味をそそられました。
生成AIに関するセッションが多いこともあり、今後ますます生成AIの活用がメインになっていくのだろうと思いました。
実際に生成AIを活用する際にAmazon Qを使用したスピーディなBedrockの使用が行えるとのことなので、参入障壁は思ったよりも低そうな感じもしました。
サーバーレス開発のベストプラクティス ～より効果的に、より賢く使いこなすために～
内容
サーバレスの変遷
初期（2014年）では、サーバレスに求められることとしてサーバやインフラの管理が不要で実行できるコードであったが、現在(2024年)においては、複雑なインフラを管理することなく顧客に価値を提供できることに変わっている。
背景としてはAWS Step FunctionsやAmazon Bedrockの登場によって、実装面で気を使う必要が減ってきたためである。
サービスフルなサーバレス
Lambdaを、Transport(転送)ではなくTransform(変換)に使用することが重要。
Lambdaを使用するタイミングはイベント連携のためではなく、独自にやりたい処理にのみ限定する方が良いとのこと。
例えば、Event sourceからDynamo DBへのデータの変更をAPIリクエストする場合、Event sourceからLambdaを呼び出し、LambdaからDynamo DBへデータ変更するという処理をしていることがTransport(転送)。
このLambdaは無駄であるためEvent sourceから直接Dynamo DBへデータの変更をリクエストすることが望ましい。
Lambdaを使用する場合、すべての処理（認証、ルーティング、リトライ処理など）をLambdaで処理するのではなく、AWSの各種サービスに責務を移譲することが望ましい。
例えば、認証、ルーティングはAPI Gatewayで行い、リトライ処理はAWS Workflowを用いることでLambda自体の責務を軽減できる。
また、Lambdaの一関数で処理をまとめるのではなく、責務ごとに関数を切り離す必要がある。
しかし、全ての関数を切り離すと管理コストが膨大になるため、グループ化を行う。
グループ化の例としては集約や開発組織の構造など。
このようにして分割した関数を構築する場合、オーケストレーション（フロー制御）とコレオグラフィ（それぞれのサービスが自律的に連携）が必要であり、多くのサービスは両方組み込まれている。
使い分けとして、ドメインごとの処理はオーケストレーション（AWS Step Functions）、イベントのやり取りを行う場合はコレオグラフィ（AWS EventBridge）となる。
ポイントは、シンプルなLambda関数を削除してconfigとして置き換えることができるかどうかである。
所感
今まではLambdaを万能なサービスとして利用できると考えていましたが、それだけだと責務が集中する＆余分なリソースを生みやすいということがこのセッションで気付かされました。
Lambdaに持たせる責務を出来る限り小さくする＆シンプルなLambdaは削除して組み込みの統合に置き換えるという意識が必要だと感じました。
また、生成AIを活用したアプリケーションの作成事例で具体的にどうサーバレスを利用するか紹介されており、非常に分かりやすかったです。
生成 AI とつくる新しい英語学習体験 ～講師の業務負荷軽減と顧客体験向上の両立～
内容
英会話アプリレアジョブでは、1回25分のレッスン後にレベルに合わせたアドバイスをAIが行う機能がベータ版として公開されている。
プロダクト開発における生成AIのアンチパターン
- 生成AIの応答精度に100%を要求
- 適切に課題を捉えられていない
- 適切な体験として組み込めていない
これは、仕組みが最適化されていないが解決されたような体験をすぐに生成AIによって実現できてしまうために勘違いが起こりやすいとのこと。
対策としては一般的なプロダクト開発と何ら変わりなく、十分な要件定義や検証を行うことである。
アンチパターンを避ける仕組み
- 生成AIを常に監視し結果が期待できるものであるか確認できる
- 容易に検証が行える環境作り
- 価値の議論を開発者だけで終わるのではなく、オープンにする
- プロンプトの見直し、利用率のモニタリング
- 価値検証をユーザ提供する
上記のものが挙げられるが、それ以前にセキュリティやガバナンスを高水準にすることが求められる
手段としてのAmazon Bedrock
多くのトークンを処理でき、高精度に出力されることや、セキュリティ・ガバナンスレベルを下げず自社顧客に価値を提供できることが挙げられていた。
高性能なClaude3が単一のAPIから利用できることも強みとして挙げられていた。
しかし生成AIを自社プロダクトに組み込む際には、なんでも行わせないことが重要。
NGワード検出や単語の出現数計算は自前で実装を行い、前処理後のプロンプトを送信したり等。
ただ、PoCとして早く回したい場合などは、プロンプトのみで完結できるためシンプルな作りになることもある。
実務で使用するために、まずは開発者以外でも簡単に触ってもらえる環境を作ることが大切であり、それを実現するものがBedrock-Claude-chatである。
このようにして検証しやすい環境を作ってから実際の開発を行う。
プロンプトや結果の価値検証では、英会話の先生が付けるスコアと生成AIが付けるスコアとの乖離を少なくするためにフィードバックや調査を実施したり、プロンプトエンジニアリングガイドにあるようなテクニックを用いることでチューニングを行う。
所感
企業目線で生成AIを活用した事例を紹介していただいたので、とても勉強になりました。
生成AIが浸透していない企業で浸透させる方法であったり、ただ生成AIを使うのではなく仮説を立てて検証を行うサイクルをいかに早く回すかといった内容がもろにブッ刺さりました。
企業から見たAmazon Bedrockの利点も述べられていたため、検討材料として使えそうでした。
OpenSearch のベクトル機能による検索の改善
内容
全文検索
初期の検索では、全文検索によるテキストマッチングが行われていた。
全文検索は、クエリテキストと検索エンジン内のデータを照合し、検索結果を関連度に基づきランク付けをするというものである。
また、結果から含まれる属性値（色や形などの値）を集計することで、ファセットと呼ばれる絞り込みでの検索が可能になった。
検索方法としてインデックスが使用されている。これは、テキストからインデックス（キーワード）を形態素解析などにより抽出し、このインデックスに対して検索を行うといったものである。
クエリからも同様にインデックスを抽出する。
しかし、クエリが曖昧だと予期しない結果となることや、クエリテキストに含まれる意図を読み取れないという課題が存在する。
例として、「暖かい季節に着る服」をクエリとして検索した場合、インデックスとして取り出されるものが「暖かい/季節/着る/服」となり、関連度の高いダウンジャケットが検索結果として出力されてしまうといった課題である。
自然言語による検索
課題を解決する手法として生み出されたものがベクトル検索である。
これは文書や画像、音声などの非構造化データをベクトルとして扱い、ベクトルの距離や角度で類似したベクトルを類似したアイテムとして関連付けするといった手法である。
ベクトル検索の方法としては、機械学習による推論により非構造化データのベクトル化（埋め込み）を行う。
クエリも同様にしてベクトルクエリに変換し、ベクトルデータベースから類似度の高いベクトルを算出し返却する。
ベクトルデータベースは、ベクトルデータの格納・検索をスケーラブルに行える、ベクトルのCRUDをリアルタイムで行える、クエリに類似するアイテムをベクトルの類似性に基づき検索できるものである。
AWSでは、OpenSearchというベクトルエンジンを提供している。
OpenSearchによるベクトル検索の流れとしては、元データを必要に応じてチャンクに分割し、密ベクトル埋め込みMLモデルによってベクトル埋め込みの生成を行い、チャンクごとにインデックスに格納する。
次にロードとしてOpenSearchでベクトルを保存する。
検索の際はクエリからベクトルを生成し、インデックス内のベクトルで類似するものを取得するといった流れとなる。
ただ、ベクトル検索は万能ではなく、厳密なマッチングは苦手な点や未知語対応のための学習コストが必要な点があるため、全文検索とのANDやOR検索でカバーする必要がある。
会話による検索
更に発展した検索手法として、AI/MLにより更に進化を遂げた会話方検索というものが存在している。
これは、AIとの会話により、意図を汲み取り正確なマッチングを実現するというものである。
また、AIチャットボットで自然な検索結果をLLMで実現することができる。この回答精度を向上させる技術をRAGという。
RAGワークフローとしてはAIチャットボットから受け取ったクエリをMLで変換し、セマンティック検索クエリとしてOpenSearchに送信する。
OpenSearchから受け取った順位付きの検索結果を、Amazon Bedrockに送ることで、LLMプロンプトにコンテキストを追加し、生成された自然な回答結果をAIチャットボットが使用するといった流れになる。
所感
検索の歴史や、ベクトル検索、会話方検索の詳細な実装方法が述べられていたためイメージしやすかったです。
現状はPoCを回すために簡略化したベクトル検索を使用する予定なのですが、今後検索の発展系としてBedrockを活用したチャットボットとの会話型検索も面白そうだと感じました。
OpenSearchでのベクトル検索をまだ実装した事が無かったのですが、解説付きで実装されていたので自分も試したい気持ちが強まりました。
おわりに
2日間参加した感想としては、これからの時代生成AIの活用は切っても切り離せないものになるのかなといった感じでした。
また、AWS Summit Japanではたくさんのブースもあり、色々なお話を聞かせてもらったのでそちらも個別で記事にしようと思います！
めちゃくちゃグッズも貰えて満足しました！
これからの開発でもどんどんAWS使っていきたいですね！
最後までご覧いただきありがとうございました！
以上、センリツでした。🤓