生成AIをアプリケーション開発に活用する企業は、コストやハルシネーションの問題にどう取り組んでいるのか：プロンプトを改善することで、品質向上、コスト削減にもつながる

Amazon Bedrockを早期導入した企業の担当者らが、クラウドのコスト管理からプロンプトの記述に至るまで、アプリケーション開発における生成AI活用のポイントを語った。

[Beth Pariseau，TechTarget]

　Amazon Web Services（AWS）は2023年4月に、大規模言語モデル（LLM）のフルマネージドサービス「Amazon Bedrock」のプレビュー版を公開した。プレビュー版の公開時点で導入を決め、1年にわたって同サービスを活用してきた企業の担当者らが、アプリケーション開発に生成AI（人工知能）を利用する際のポイントを語った。

　語ったのは、カナダのトロントを拠点とする顧客調査プラットフォームプロバイダーAlidaでチーフアーキテクトを務めるシャーウィン・チュー氏と、米国ニューヨーク州メルビルのContact center as a ServiceプロバイダーVerint Systemsでチーフサイエンティストを務めるイアン・ビーバー氏だ。

AlidaはなぜAmazon Bedrockを選んだのか

　Amazon Bedrockは、さまざまなLLMの選択肢を提供しており、データプライバシーやセキュリティのきめ細かなオプションも組み込まれている。専用インスタンスを通じて、独自に基盤モデルをカスタマイズする機能もある。ユーザーは、基盤モデルに学習させるデータセットを制御することもできる。データは転送中も保管中も暗号化されており、IDベースのアクセス制御やAWSの「Amazon CloudWatch」による監査ログもサポートされている。

　Alidaでチーフアーキテクトを務めるシャーウィン・チュー氏は、利用を開始した当時、これらの機能がAmazon Bedrockをユニークな存在にしていたと語る。

　「AWSを利用しようと考えた動機は、顧客に提供するソリューションにおいてGDPR（一般データ保護規則）、セキュリティ、プライバシー、データ主権の要件に準拠する必要があったためだ。LLM分野のパイオニアであるOpenAIの場合、信頼性の高いサービスを提供していたが、GDPRの要件には準拠できていなかった」（チュー氏）

　AlidaにとってAmazon Bedrockは、コンプライアンスとセキュリティのニーズを満たすだけでなく、LLMやトレーニングインフラを自社でホストする必要がなかったことも決め手になったとチュー氏は話す。

　Amazon Bedrockは、API経由でLLMの機能を利用する流れとなるため、技術面から見ても、既存のアプリケーション開発プロセスに簡単に組み込むことができる。だが、APIの実行回数や他のAI、MLサービスの制約があるため、Alidaでは独自のDevOpsパイプラインインフラを用意しているという。

　チュー氏によると、AlidaのAmazon Bedrockパイプラインは「Amazon Simple Queue Service（Amazon SQS）」やAmazon CloudWatchなどのAWSサービスに基づくイベント駆動型アーキテクチャで構築し、データフロー管理や、コスト監視をしているという。同氏が率いるエンジニアリングチームは、社内の多くの開発者がサービスにアクセスできるよう、Amazon Bedrock APIを利用する際、複数のバッチジョブにグループ化する方法も検討しているという。

　「LLMの使用を民主化して誰でも使えるような方法を検討している。レート制限の引き上げはいつでもAWSに依頼できるが、法外な費用がかかる可能性もある」（チュー氏）

生成AIの活用を進めていたVerint SystemsがAmazon Bedrockに注目した理由

　AWSのクラウドサービスの顧客であり、AWS MarketplaceでContact center as a Serviceプラットフォームを提供するパートナーでもあるVerint Systemsにとって、生成AIとの連携は新しいことではなかった。ビーバー氏によると、同社は約3年にわたって社内で生成AIを利用してきたという。

　Verint Systemsの場合、地域ごとに、異なるクラウドプロバイダーのLLMサービスと連携する必要があったとビーバー氏は語る。入力される言語とLLMの組み合わせ次第で、出力結果の品質が変わってくることがあるためだ。

　同社はこうした背景からAmazon Bedrockに着目した。研究開発チームは、2023年にリリース予定だった製品「Verint Da Vinci AI」で利用するモデルを判断するために、Amazon Bedrockを採用。製品リリース前に、モデルのパフォーマンスを評価したり、出力結果をテストしたりして、どのモデルが最適かを判断できたという。

　同社の場合、AIと機械学習を扱った経験はあった。それでもLLMの使用では、コストに関して全く新たな考慮が必要だったとビーバー氏は語る。

　「コストは大きく異なる。いまだに価格の高騰に衝撃を受けるプロダクトマネジャーがいる。マネジャーは『この製品に関するアイデアがある。それは変革的なアイデアになると思う』と言うが、マネジャーがやりたいことは『GPT-4』を1日に1000万回呼び出すことなので、数百万ドルのコストがかかってしまう」（ビーバー氏）

　ビーバー氏は、こうした社内でのコスト交渉は機械学習では一般的ではないと指摘する。

　「誰もが生成AIの機能に注目している。それは素晴らしいことだが、コストと、コストに利幅を加えて販売することとのバランスを取らなければならない。価格設定の多くはトークンに基づいている。プロダクトマネジャーは、トークンとは何かさえ分かっていない。ましてや、トークンによるコストの計算方法など分からない。実際、費用対効果を高める方法が分からなかったため、中止に追い込まれたプロジェクトも幾つかある」（ビーバー氏）

　オンプレミスまたはクラウドでLLMを導入する際のコストを考慮して臨機応変に選択可能にするのは、Verint Systemsの場合、プラットフォームエンジニアリングチームの役割だという。

　「プラットフォームエンジニアリングチームはコストの優先順位付けをするMLOpsプラットフォームを用意した。例えば、『AnthropicがClaude 3の価格を40％値下げしたばかりだ。ここのスイッチを切り替えて、南北アメリカリージョンにトラフィックをルーティングしてはどうだろう』と提案してくれる。その結果、いきなり利益率が30％程度改善される。これは当社にとって非常に大きなメリットだった」

プロンプトを改善することで、品質向上、コスト削減にもつながる

　LLMによる取り組みが他のAIの取り組みと大きく違う点は、LLMから不正確な結果（幻覚〈ハルシネーション〉）がもたらされる可能性が高いことだ。そのため、慎重かつ迅速なエンジニアリングが求められる。出力結果の品質を高めるには複数回の改良が必要になることが多いと、チュー氏とビーバー氏の両氏は口をそろえる。

　「生成AIモデルを製品に導入する際は必ず、ユーザーインタフェース（UI）レベルで生成AIモデルを制御して、間違った動作を報告し修正できる人間が介在するヒューマン・イン・ザ・ループ（HITL：Human-in-the-Loop）の側面が必要だ。他にも、ユーザーが出力結果をそのまま信じてしまわないようにさせることも不可欠だ」（ビーバー氏）

　ビーバー氏によると、Verint Systemsでは同社製品のUIでLLMの出力に対してエンドユーザーが詳細なフィードバックを返す手段を構築することで、プロンプトの記述とモデルのトレーニングの改善に必要なデータを収集しているという。

　以前のVerint Systemsでは、こうした改善にまつわる作業はデータサイエンティストが担当し、改善策に応じて機械学習モデルを再トレーニングしていた。だが、プロンプトを改良する場合、自社ソフトウェアのエンドユーザーから自社のカスタマーサポート担当者やソフトウェアエンジニアに至るまで、関係者全員の協力が必要だった。ビーバー氏によると、こうした取り組みにはLLMのカスタマイズに伴うコストを回避する狙いもあるという。

　「AWSや『Microsoft Azure』のようなプラットフォームを提供するプロバイダーの大半はトレーニング費用を有償にしているだけでなく、カスタムモデルのホスティングにも追加料金を請求する。ベースモデルを使用し、プロンプトを改善するだけで対応できれば、カスタムモデルをホストする必要はなくなり、大幅なコスト削減になる」（ビーバー氏）

　教育も重要な取り組みの一つだ。プロンプトエンジニアリングでは、生成AIアプリケーションをサポートするプロセス全体を通して非常に多くのことを学ぶ必要があり、社内の1つのチームが扱うには大き過ぎる仕事だ。そのため、複数のチームがプロンプトエンジニアリングを学ぶ必要があるとビーバー氏は語る。

　「生成AIの出現でもう一つ変化している点は、この種の仕事を目的とする専門サービスやサポートチームへの教育だ。というのも、研究組織やデータサイエンティストにこうしたカスタマーサポートの問題を全て大掛かりに扱わせるのは非現実的だ」（ビーバー氏）

「生成AIの可能性は膨大」

　AlidaのAmazon Bedrockチームは、最近参加したハッカソンで、生成AIを使ってカスタマーエクスペリエンスアンケートを生成する実験をした。この実験で生成AIの大きな可能性に気付いたとチュー氏は語る。

　「アンケートの生成には、構造化されたJSONドキュメントが必要になる。そこで、トップレベルノードのスキーマと子ノードを挿入できるある種のプレースホルダーをLLMに提供した。その結果、LLMはそのテンプレートを利用して完全に構造化されたJSONドキュメントを生成できた」（チュー氏）

　この実験は、プロンプトが適切であれば、LLMは複雑なタスクや複数段階のワークフローを処理できる可能性を示しているとチュー氏は語る。

　「生成AIの可能性は膨大かつ印象的だ。それでも、一貫性の欠如という課題に、今なお取り組み続けている状況だ」（チュー氏）

　Verint Systemsの場合、特定の業界、クライアント、言語に合わせてLLMをカスタマイズしてほしいと、顧客から求められ始めている。そのため、ソフトウェアエンジニアだけでなく、専門サービスチームやカスタマーサービスチームの仕事の性質も生成AIにより変わりつつあると、ビーバー氏は語る。

　「対処しなければならない新しい問題は、全てのプロンプトを大規模に管理する必要があることだ。プロンプトをコードとして扱い、バージョン管理、アクセス制御、ゲート付きリリースをする必要がある。それぞれ重要な作業であり、独立した取り組みが必要だ」（ビーバー氏）