AWSで実現するResponsibleAIとLLMOps

はじめに

こんにちは。NTTデータグループ クラウド技術部です。
今回は2023年11月27日から12月1日にかけて5日間開催されたAWS re:Inventにて筆者が参加してきたセッションを振り返り、AWSにおけるResponsible AIやLarge Language Model Operations(以下、LLMOps)に関する情報をお届けします。

なお、本記事はAWS re:Invent 2023 参加報告レポートの第2回です。
今回は生成AIワークロードに欠かせないResponsible AIやLLMOpsについてご紹介します。

FoundationモデルとResponsibleAI

はじめにAmazon Web Services CEO, Adam Selipskyのキーノートでも言及されていたResponsible AIについてご紹介します。

Responsible AIとは

Responsible AIとは、AIシステムを信頼性・透明性の高いものとし、公平性を確保しながら社会的弊害を防ぐための考え方や技術です。
近年、ディープラーニングなどの技術進歩によって、AIの性能が飛躍的に向上しています。その一方で、AIによる判断を人間が理解・説明できない「ブラックボックス化」や、データやアルゴリズムの偏りに起因した差別や偏見の助長といった弊害も指摘されています。
Responsible AIはこれらの課題に対処するためのアプローチで、複雑化するAIシステムをどのように制御し、説明責任を果たしながら、社会に健全な方法で実装するかを探求します。
つまり、単に高性能なAIを開発するだけでなく、その運営プロセスの透明性や公平性を保つ工夫が求められ、意図せぬ問題を回避することを目指します。
本連載の第一回でもご紹介しましたが、Guardrails for Amazon bedrockやAmazon Titan Image Generatorの電子透かし機能等は、このResponsible AIを実現する一助となるような機能だと考えております。

Responsible AIを構成する観点

では、具体的にどのような観点をクリアすればResponsible AIであると言えるのでしょうか。
筆者が参加したChalk Talkで定義されていた観点をご紹介します。

公平性(Fairness)

• モデルのアクセス、運用、モニタリングが公平であることの担保
• モデル性能指標と現実世界へのインパクトの一致度の確認

説明責任(Explainability)

• 解釈可能性を高めることでモデルへの信頼性向上

堅牢性(Robustness)

• システムが意図された範囲内で信頼でき、堅牢であることの担保
• ユーザーや開発者のミスに左右されない動作の担保

プライバシー/セキュリティ(Privacy and Security)

• 個人情報や知的財産の流出防止
• データガバナンスプロセスのAIシステム適用

ガバナンス/監査能力(Governance)

• AIシステムの運用とその影響の監視、監査
• ステークホルダーへの適切な情報提供

透明性(Transparency)

• 利用者と影響を受ける人々に対するAIシステムの透明性の確保

従来の機械学習モデルとFoundationモデルのResponsible AI

続いて従来の機械学習モデルとFoundationモデルの違いとResponsible AIへの影響の違いについて確認していきましょう。
主な違いは以下の通りです。

• 従来の機械学習モデルは特定のタスクに特化しているのに対し、Foundationモデルは多目的で柔軟性が高い
• 従来の機械学習モデルはデータセットのバイアスをある程度コントロールできるが、Foundationモデルはインターネット上のほぼ全データを学習するためコントロールが難しい
• 従来の機械学習モデルなら出力がトレーニングデータセットをコピーしているのを発見し対策できるが、Foundation モデルの場合はそうした対応が困難
• Open-endedなFoundationモデルの出力を人間の常識的な判断でフィルタリングすることが難しい

これらの違いから、Foundationモデルでは、扱うデータ量の大きさや出力の柔軟性がバイアスのコントロールや信頼性確保の課題を引き起こしていると言えます。

Responsible AIを実現するための具体的なアプローチ

前パートではFoundationモデルにおけるResponsible AI実現の難しさについてご紹介しましたが、本パートでは具体的な対策についてご紹介します。
対策には大きく2つのアプローチがあります。

入力面のアプローチ

まずは1つ目として、入力面でのアプローチに関してご紹介します。
入力面でのアプローチとはデータの偏りやバイアスを防ぐことで、公平性や透明性を高めることを目的とするアプローチです。
具体的には以下のような手法をとることができます。

• 分布式コンピューティング(SageMaker Clarifyなど)を用いた大規模データのバイアス分析
  特徴量の重要度やバイアスを可視化による、データの見直しの補助
• 埋め込みの利用によるセマンティックな関係性のモデリング
  言語データをベクトル空間上に写像することで意味的関係性（セマンティックな関係性）を表現し、データのバイアスを可視化
• 差分プライバシーの適用によるデータ漏洩リスクの低減
  ランダムな情報追加による、個人情報の特定の防止

出力面でのアプローチ

続いて出力面でのアプローチです。以下が有効なアプローチとしてあげられています。

• ファインチューニングによる生成モデルの再トレーニング
• プロンプトエンジニアリングの適用
• 免責事項や情報源の明示による結果解釈の支援

このように、データとアルゴリズムの双方における適切なアプローチを組み合わせることで、Responsible AI に近づけると言えるでしょう。

大規模言語モデルの運用に欠かせないLLMOps

機械学習がもたらすインパクトは計り知れませんが、その一方で、機械学習モデルを実運用する際には多数の課題も存在します。先にご説明したResponsible AIもその一端です。

本パートでは、LLMOpsに関するWorkshopセッションに参加した筆者が、機械学習モデルの運用を効率化するフレームワークであるMachine Learning Operations(以下、MLOps)と、
最近注目を集めている大規模言語モデルを活用したLLMOpsについてご紹介します。
両者の共通点と相違点を整理することで、ビジネスが抱える課題に対して最適なアプローチを選択する助けになれば幸いです。

MLOps/FMOps/LLMOpsの定義について

まずは以下の図をご参照ください。

各Opsはお互いに重なり合っていることが分かります。
MLOpsは幅広いML分野を対象とするのに対して、Foundationモデルの運用全般を対象とするのがFMOpsです。
再掲となりますが、Foundationモデルとは一般的に教師なし学習で大量のデータを学習したモデルで幅広いタスクをこなすことができるAIニューラルネットワークを指します。
詳細は後述しますが、このようなFoundationモデルの特徴からMLOpsにはない要素もFMopsに含まれているため、完全に包括はされていません。
さらにFoundationモデルのうち、大規模言語モデルの運用をLLMOpsとして定義しています。

以下、それぞれの定義です。

• MLOps(Machine Learning Operations)
  機械学習モデルを運用化するための、人・プロセス・技術の総合的なフレームワークです。
  データの前処理、モデル構築・チューニング、Pipeline化、運用・監視までを網羅しています。
• LLMOps(Large Language Model Operations)
  大規模言語モデル(LLM)を利用したアプリケーション開発と運用を効率化するフレームワークです。MLOpsのサブセットや応用と位置づけられています。テキスト生成を主な対象としています。
• FMOps(Foundation Model Operations)
  LLMを含むFoundation Model全般の運用を示すフレームワークです。LLMOpsがテキストに特化しているのに対し、FMOpsはテキスト/画像/音声など多様なモデルを想定している点が異なります。

それぞれ、実際にサービスとして提供するためにモデルの構築以外に運用監視、Pipelineについても言及していることにご注目ください。これらを実現するために開発体制を構築するのですが、開発するモデルによって必要とするスキルセットが異なります。次パートではこの違いからMLOpsとLLMOpsを比較してみます。

体制と役割から見るMLOpsとLLMOpsの違い

MLOpsの定義で紹介した通り、MLワークロードをサービスとして提供するためには、モデルのメンテナンスだけではなく、モデルを提供するプラットフォームに関連するアクター等を巻き込んで体制構築することが重要です。
次に紹介する体制と役割に関する図はまさにそういった点を可視化しています。
まずはMLOpsに必要な体制と役割についてご紹介します。

• Data engineer/Data owners：データの準備や前処理等を行う
• Data scientist：モデルのビルドやトレーニング、デプロイやテスト等を行う
• ML engineer：モデルの運用・デプロイを担当 データサイエンティストを支援
• DevOps engineer：CI/CDPipelineを担当
• Platform engineer：セキュリティ・運用・ガバナンスを担当

次にLLMOpsについてご紹介します。
LLMを扱うことに伴い上記MLOpsに加えていくつかの職種が追加されます。

• Prompt engineers：入出力プロンプトの設計を担当
• Prompt testers：生成結果の評価を担当
• Fine-tuners：Foundationモデルのファインチューニングを担当
• Data labelers/editors：ファインチューニング用のデータの前処理を担当

LLMにおけるtesterの存在意義について

MLOpsでもLLMOpsでも、精度や損失関数といった定量的指標に基づく評価は重要です。
特にLLMの場合、生成されたテキストや画像の「質」の評価は、人間の目で行う必要がある場合が多いです。
例えば、モデルが生成した文章が文法的に正しく、自然な印象を人間に与えるかどうかなどの評価は自動化しにくく、人間の主観的な判断が求められます。
したがって、LLMOpsでは、モデルの精度などの定量評価に加えて、生成されたコンテンツ自体の質を人間が評価するという定性的なプロセスが重要な差分となっているということです。このため専任の「Prompt tester」を用意することが多いのです。

ハンズオンの内容

上記のようにLLMOpsの意義や全体像について座学を受けた後、ハンズオンを通じて実際にLLMOpsを体感しました。以降、ハンズオンの内容について簡単にご紹介します。
ハンズオンでは以下のアーキテクチャ図とPipelineを構成し、Pipelineを利用してアプリケーションの機能追加やモデルのファインチューニング等を実装しました。

• アーキテクチャ図
  (出展:Operationalize Generative AI Applications using LLMOps よりキャプチャ)

• Pipeline
  (出展:Operationalize Generative AI Applications using LLMOps よりキャプチャ)

• SageMaker Pipeline
  (出展:Operationalize Generative AI Applications using LLMOps よりキャプチャ)

ハンズオンの流れは以下の通りです。

1. CDKを用いてシステムをデプロイ
2. デプロイしたシステムのWebUIを用いて試験
3. Pipelineの構成
4. ファインチューニング
5. RAGの実装

ハンズオンを通じて、既存のサービスを利用してPipelineを構成できることは、豊富なマネージドサービスを有するAWSの強みだなと感じました。
ただサービスインしたばかりのBedrockのファインチューニングはSageMaker Pipelinesに対応しておらず、自前でStep Functionを作りこむ必要があることは注意が必要です。

まとめ

生成AIワークロードを提供するために必要なResponsible AIとLLMOpsの２つの考え方についてご紹介してまいりました。
手軽に利用できるSaaSを使っていると気づきにくいですが、自前でサービスを提供するためにはこれらの観点についてよく検討する必要があります。
Responsible AIやLLMOpsを活用し、破壊的な変化を生む生成AIと上手に付き合っていきましょう。
第3回はGamedayやJam等のいわゆるgamified learning関連セッションに数多く参加したメンバが、その楽しさ・学びについて紹介する予定です。ぜひお楽しみに。

NTTデータの取り組みの詳細はこちら

[PR]提供：NTTデータ