Web系エンジニア、Amazon Bedrock Prototyping Campに参加して、生成系AI の組み込み方を学ぶ

こんにちは、フロントエンドエンジニアの田所（@ikumatdkr）です。

昨日AWSの方にご招待頂き、AWSの生成系AI関連製品を使った1Dayセミナー、Amazon Bedrock Prototyping Campに参加してきました！

エンペイではプロダクトとして生成系AIを使った機能はまだ提供していないのですが、社内の問い合わせナレッジの効率活用のために、にゃんだーコールサポートというBotを飼い慣らしています。

このBotはAWS Lambdaをバックエンドとして、社内ナレッジを参照し、RAG（Retrival Augumented Generation）による回答を行うものです。

業務の傍ら有志で実装したものであるため、とりあえず社内に展開したはいいものの、その後のチューニングが十分に施されていないという課題がありました。

AWS Bedrockをはじめとする生成AI系のソリューションにより短時間で品質を高められないか、この記事ではそんな思いを持って参加したイベントでの学びを共有します！

参加前の期待値としては「プロンプトエンジニアリングの具体的なハックを知りたい」と思っていました。RAGの仕組み自体は構築できているため、あとはプロンプトエンジニアリングで精度を上げるだけだと思っていたためです。

しかし実際に参加してみて一番学びになったのは具体的なテクニックというよりも、生成系AIを組み込んだプロダクトの改善に対するメンタルモデルでした。

私たちが構築しているのは、もはやN番煎じな問い合わせAIチャットボット。ネットにも多くの構築記事が公開されていますので、構築自体はそこまで難しくありません。

一方で一度構築したあとの改善は三者三様です。

生成系AIビギナーとしては、全体像が見えないがゆえに状況への打ち手としてプロンプトエンジニアリングのようなHowを掲げたくなってしまうところです。ここで一歩俯瞰して、通常のプロダクト開発同様にフィードバックサイクルの軌道に乗せるのがポイントだと感じました。

とはいえ、フィードバックサイクルに乗せるといっても、利用状況の集積と適切なペースでの打ち手の提供は難しいところです。そのための手段としてセミナー中ではAmazon Kendraの紹介とハンズオンがあり、こちらが便利に使えそうだったのでご紹介します。

Kendraは機械学習(ML) を利⽤したインテリジェント検索サービスです。主な機能として以下のようなものがあります。

インデックス生成をワンクリックでやってもらえるのも便利ですが、特にRAGを利用したプロダクトを支える機能として、自動で生成される分析改善ダッシュボード - Search Analytics がとても便利に使えそうだなと感じました。

この機能では作成したインデックスに対して、検索結果を自動で収集・分析してくれるもので、ユーザーが使用しているクエリの人気度や、示したもののクリックされなかった結果などを見ることができます。詳しくは Kendraのドキュメント をご参照ください。

生成系AIの返答は一概にその正誤を二分することが難しいため、いくつかのプリセット指標とともに統計の自動収集を行なってもらえる点がプロダクト推進にプラスになりそうです。

今回のハンズオンの中では時間が限られていたため、aws-sample/generative-ai-use-cases-jp というよくある生成系 AI を利用したビジネスユースケースをまとめたサンプルを使って、Kendra含むRAGチャットのサンプルを構築しました。

がAWS CDKで一発で立ち上がり、30分ほどで実際にChatGPTライクなUIでKendraを使ったサンプルを試すことができました。

より自分たちのユースケースに寄せていこうとなると、テンプレート側に事前に組み込まれているプロンプトやソースの解読、都度デプロイが重たく感じたため、その際はこのリポジトリを参考にしつつ別途ローカル検証用の仕組みや個別のUIを設けるのもいいかもしれません。

KendraのSearch Analyticsはどちらというと「見えていないものを見えるようにして、改善点を作っていく」ことに寄与しますが、今回のセミナーでは「すでに見えているものを改善する」ためのTipsもいくつか得られたので、簡単にご紹介します。

モデル：Claude限定の話になりますが、プロンプト内のXMLタグを認識できるようにFine Tuningが施されており、前提条件等を独自のタグで囲むと回答精度が向上します。

モデルの選択はレスポンスに対する変数だと認識していたので、プロンプト部分に影響を受けることは初耳でした。

LLMからのレスポンスとしてJSONを受け取り、そのJSONをアプリケーションコードで使用したいケースはよくあると思います。

出力形式をプロンプトに含めても良いのですが、レスポンスの始まりをこちらで指定すると、LLM側でそれに続くように回答が補完され、回答の精度があがります。例えばJSONであれば以下のようにプロンプトを指定すると、余計な返答が最初に入らなくなりやすいです。

私も社内AI ChatBot以外で「出力はJSONで指定してください」とプロンプトを書いていて、「はい、わかりました」のような不要な返答が含まれることに悩んでいたので、ためになりました。

Kendraを利用している場合、データコネクタを利用して複数のデータソースを利用することができます。S3配置のコンテンツもその1つです。

KendraでS3配置のコンテンツにヒットして回答を行った際に、ハルシネーションではないことを裏付けるために、どのソースを参考にして回答を行ったのかを表示したいケースがあると思います。その場合、コンテンツを配置しているS3 バケットに <コンテンツのファイル名>.metadata.jsonを配置し、以下の内容を記述することでドキュメントのURLを含めることができます。

設定できるmetadataの種類については、Amazon KendraのS3コネクタについての説明をご参照ください。

今回は社内AI ChatBot、通称にゃんだーコールサポートを前進させるための視点・方法を学ぶことができました。

ハンズオンの中では、Amazon Bedrockで使えるModelの中からClaude Instant、データコネクタとしてKendraを利用していましたが、実際の社内ユーザーの利用状況を客観的に分析し、適切なリソースを用いてアップデートしていきたいと思います！

今回のセミナーは事前にスケジュールをご連絡いただいており、「昼食は無償のしゃけ弁当を提供」とあったのですが、当日蓋を開けてみると「無償のトンカツ弁当、しゃけもある」でした。この事実には良い意味で予想を裏切られました。

そんなこんなで何が起こるかわからない世の中ですが、だからこそ生成系AIのように柔軟にコンテンツを提供できる手段を、今回学んだ通り目的を見失わず適切に使って、プロダクト内外の価値を高めていきたいものです。

開催およびご招待いただきましたAWSの皆様、ありがとうございました！