AIF#22

Amazon CloudWatch で Amazon SageMaker AI をモニタリングするためのメトリクス

「Amazon CloudWatch」 は、リアルタイムメトリクスとアラームを標準で提供し、スケーラブルに ML システムのパフォーマンスを監視できるため正解です。

具体的には、Amazon CloudWatch は、機械学習 (ML) システムにおけるリソース使用率 (CPU、メモリ、ディスク、ネットワーク) やアプリケーション固有のメトリクス を収集し、ダッシュボードで視覚化できます。これにより、スケーラブルなアーキテクチャ上で発生するパフォーマンスのボトルネックや異常検出が可能となり、適切なアクション (例 :Auto Scaling トリガー、CloudWatch Alarm の発火) に自動連携できます。


※Amazon CloudWatch で Amazon SageMaker AI をモニタリングするためのメトリクス
Amazon CloudWatch を使用すると、Amazon SageMaker AI をモニタリングできます。Amazon CloudWatch は生データを収集し、読み取り可能なほぼリアルタイムのメトリクスに変換します。これらの統計情報は 15 か月間保存されます。これらの統計情報を利用することで、履歴情報にアクセスし、Web アプリケーションやサービスのパフォーマンスをより深く理解できます。ただし、Amazon CloudWatch コンソールでは、検索対象が過去 2 週間以内に更新されたメトリクスに制限されます。この制限により、名前空間内で最新のジョブが表示されるようになります。
参考URL : Amazon CloudWatch で Amazon SageMaker AI をモニタリングするためのメトリクス

■以下は間違いです。
・AWS Config
→「AWS Config」 は、AWS リソースの構成履歴を記録し、設定変更がポリシーに準拠しているかを評価するサービスです。このサービスは コンプライアンス評価や変更監査には適している一方、CPU 使用率やディスク I/O といったシステムの性能情報を提供しないため間違いです。

・AWS Trusted Advisor
→「AWS Trusted Advisor」 は、コスト最適化、パフォーマンス効率化、セキュリティ改善、耐障害性向上などの観点で、AWS 環境全体の 「ベストプラクティスに基づいた推奨事項」 を提示しますが、リアルタイムでの機械学習システムの細かなパフォーマンス監視やメトリクス取得、アラーム通知などの機能がないため間違いです。

・AWS CloudTrail
→「AWS CloudTrail」 はユーザーや AWS サービスによる API オペレーションのログを記録し、セキュリティ分析やコンプライアンス監査のために使用します。これは主にシステムのアクティビティや変更を追跡する用途であり、機械学習システムのパフォーマンスをモニタリングするための リアルタイムのメトリクス収集や視覚化 の機能を持っていないため間違いです。

公平性

「公平性 (Fairness)」 の観点から、代表性に欠けるデータセットはモデルに 「バイアス」 を生み、応募者に不公平な評価を与えるため正解です。

具体的には、「Amazon SageMaker」 をはじめとする AI/ML サービスでは、学習データセットに含まれる情報が偏っていると、モデルの予測結果にも同様の偏り (バイアス ) が生じます。これは 公平性 (Fairness) の欠如を示し、特定の性別、人種、年齢層などのグループが不利に扱われる可能性があるため、責任ある AI の観点で重大な問題です。公平性は、AI が個人や集団に対して差別的でないように設計されているかを評価する重要な次元であり、トレーニングデータの代表性を確保することがその前提条件です。履歴書審査という文脈では、代表的でない履歴書に基づいて構築されたモデルは、特定の背景を持つ応募者を過小評価するリスクがあり、実際の意思決定で不平等を助長する恐れがあります。

※(動画) AWS を活用した responsible AI ～ 機械学習のバイアス、公平性、説明可能性 ～ | AWS AI/ML Update と事例紹介


※(画像引用) AI 公平性・説明可能 AI(XAI) の 概説と動向
参考 PDF : AI 公平性・説明可能 AI(XAI) の 概説と動向
参考URL : 責任ある AI - AWS で責任を持って AI を構築する - AWS

■以下は間違いです。
・透明性 (Transparency)
→「透明性 (Transparency)」 は、AI システムがどのように構築・運用されているか、関係者が適切に理解できるように情報が開示されている状態を指します。これは開発者や利用者に対して、モデルの構造、アルゴリズムの選定、データの利用方針などが明確にされていることが目的であり、データセット自体の偏りや不平等な結果を直接的に説明するものではないため間違いです。

・プライバシーとセキュリティ (Privacy and security)
→「プライバシーとセキュリティ」 は、ユーザーデータが適切に保護されており、漏洩や不正アクセスがないことを意味します。このシナリオでは、トレーニングデータに含まれる履歴書が「すべての属性を代表していない」ことが問題とされており、それは 「データの構成の偏り」 による公平性の欠如を示しています。データが不完全であることと、それが外部に漏洩したり不正利用されるというセキュリティ上の脅威とは無関係です。

・説明可能性 (Explainability)
→「説明可能性 (Explainability)」 は、モデルの出力結果がどのように導かれたのかを人間が理解できるようにするための概念です。これは主にモデルの振る舞いの透明性や、特定の予測に対する説明を求められる場面に関係しますが、トレーニングデータの偏りによって特定グループに不利益を与えるかどうかの判断は 「公平性」 に関わる問題のため間違いです。

Amazon SageMaker Model Monitor

「Amazon SageMaker Model Monitor」 は、本番環境にデプロイした機械学習モデルの品質の変化を監視できるため正解です。

具体的には、Amazon SageMaker Model Monitor は、AWS 上にデプロイした機械学習モデルの推論データを継続的にモニタリングして、「時間の経過に伴うモデルの品質変化 (データドリフトなど) を自動的に検出」 し、モデルの精度低下など問題が発生した場合に通知することができます。

※Amazon SageMaker Model Monitor でデータとモデル品質をモニタリングする
Amazon SageMaker Model Monitor は、本番環境の Amazon SageMaker 機械学習モデルの品質をモニタリングします。Model Monitor では、以下を設定できます。

・リアルタイムエンドポイントによる継続的なモニタリング
・定期的に実行されるバッチ変換ジョブによる継続的なモニタリング
・非同期バッチ変換ジョブのオンスケジュールモニタリング

Model Monitor では、モデルの品質に偏差がある場合に通知するアラートを設定できます。これらの逸脱を早期かつプロアクティブに検出することで、是正措置を講じることができます。モデルの再トレーニング、アップストリームシステムの監査、品質問題の修正などのアクションを実行できます。モデルを手動でモニタリングしたり、追加のツールを構築したりする必要はありません。コーディングが不要な Model Monitor のビルド済みモニタリング機能を使用できます。また、カスタム分析を提供するコーディングによってモデルを柔軟に監視できます。
参考 PDF : Amazon SageMaker モニタリング Part1 Amazon SageMaker Model Monitor を理解しよう
参考URL : Amazon SageMaker Model Monitor でデータとモデル品質をモニタリングする

※Amazon SageMaker Model Monitor の概要
※(動画) Amazon SageMaker モニタリング Part1 【 ML-Dark-07 】【 AWS Black Belt 】 参考URL : 「Amazon SageMaker Model Monitor を理解しよう」を解説する動画を公開しました ! 【 ML Enablement Series Dark#7 】
参考URL : Data and model quality monitoring with Amazon SageMaker Model Monitor

■以下は間違いです。
・Amazon Comprehend
→「Amazon Comprehend」 は感情分析、キーフレーズ抽出、トピック検出といった自然言語処理のタスクに特化したサービスであり、ユーザーが独自に開発したカスタムの ML モデルを本番環境にデプロイしたり、モデルのパフォーマンスを継続的に監視したりする機能は備えていないため間違いです。

・Amazon SageMaker Clarify
→「Amazon SageMaker Clarify」 はデータやモデルのバイアスを検出・分析したり、モデルが予測を行った理由を説明したりするサービスです。デプロイ後における継続的なモデルの品質の監視や変化検知に対応した機能は提供されていないため間違いです。

・Amazon Rekognition
→「Amazon Rekognition」 は主に画像や動画におけるオブジェクト検出、顔認識、テキスト抽出に使用されるサービスです。視聴者の行動や人口統計の分析に用いるカスタマイズした ML モデルをデプロイしたり、モデルの品質を監視して変化を検知したりする機能は提供していないため間違いです。

※サービス比較表

名称	特徴	主な用途
Amazon SageMaker Model Monitor	本番エンドポイントの入力・出力を収集し、ベースライン統計と比較して データドリフトや品質劣化を自動検知 します。アラーム発報やレポート生成も可能です。	継続的モデル監視。 例 : 動画配信サービスが「視聴者行動データ」で学習した推薦モデルを 24 時間体制で見守り、異常な推論が出たら運用チームへ通知する。
Amazon Rekognition	画像・動画の物体検出や顔認識をフルマネージドで実行します。	メディア分析。 例 : 写真から犬や猫を判定し、アルバムを自動分類する。
Amazon SageMaker Clarify	学習データと推論結果のバイアス計測やモデルの説明可能性レポートを生成します。	AI の公平性評価。 例 : 入試判定モデルが男女で不公平になっていないかを確認する。
Amazon Comprehend	自然言語処理サービスで、感情分析やエンティティ抽出を API で提供します。	テキスト分析。 例 : 商品レビューから「うれしい」「悲しい」といった感情を集計し、人気商品を把握する。

継続的な事前トレーニング

「継続的な事前トレーニング」 は最新データを逐次取り込みモデルを常に更新できるため正解です。

具体的には、継続的な事前トレーニング (Continual Pre-training) では、基礎モデルが一度のトレーニングで完結するのではなく、新しく収集されたデータを用いて定期的に追加学習を行います。これにより、モデルは時間とともに進化し、最新のデータを反映し続けることができます。その結果、常に現状に即した性能を保つことができ、継続的に変化するビジネスニーズやドメイン知識にも対応可能です。


※Amazon Bedrock での継続的な事前トレーニングがプレビューで利用可能になりました
継続的な事前トレーニングは、モデルを当初のトレーニングを超えた新しい多様なデータにさらすことで、分野外の学習課題に対処するのに役立ちます。事前トレーニングを継続することで、モデルの理解力を深めてドメインで使用されている言語を含めることができるようになり、対象のビジネスについてのモデルの全体的な能力を高めることができます。
参考URL : Amazon Bedrock での継続的な事前トレーニングがプレビューで利用可能になりました

■以下は間違いです。
・潜在空間を活用するトレーニング
→「潜在空間を活用するトレーニング」は、モデルの構造設計や生成アルゴリズムに関わる技術であり、モデルを定期的に最新化するような更新戦略とは直接関係がないため間違いです。

・静的トレーニング
→「静的トレーニング」 はモデルを一度だけ訓練する方式であり、データの変化に対応できないため間違いです。

具体的には、静的トレーニング は初期のデータセットのみを用いて一度モデルをトレーニングし、その後は更新を行わない前提の戦略です。この手法では新しいデータに基づく知識が追加されないため、データ分布が変化する環境下ではモデル性能が時間とともに低下してしまいます。

・バッチトレーニング
→「バッチトレーニング」 は、定期的に大量データを一括学習する方式で、新着データを即時反映できずモデルを常時最新状態に保てないため間違いです。

具体的には、バッチトレーニング は一定期間に蓄積されたデータをまとめて処理するため、最新データを随時取り込んでモデルを更新するようなリアルタイム性が欠如しています。この方式ではモデルの更新タイミングが固定されるため、変化の早い環境下ではモデルの精度劣化につながるおそれがあります。

温度 (temperature) : モデルの推論パラメータ

モデルの推論パラメータである 「温度 (temperature)」 を下げることで、生成される回答のランダム性が抑制され、幻覚 (ハルシネーション) を減らすことができるため正解です。

具体的には、温度 (temperature) は大規模言語モデルの推論時に使用される 「出力の多様性を制御するパラメータ」 です。温度 (temperature) の値が高いほど出力にランダム性が増し、多様な語彙や文構造が生成されますが、その分 「事実と異なる内容や信頼性の低い回答 (幻覚 (ハルシネーション))」 が発生しやすくなります。温度 (temperature) を下げることで、より 確率の高い (つまりトレーニングデータ上でより信頼される) 出力 が選択されやすくなり、結果として幻覚 (ハルシネーション) の発生を抑えることができます。

※温度パラメータを下げる
推論時の温度パラメータを下げることで、ランダム性を抑え、正確なトークンが選ばれる確率を高めます。これにより、ハルシネーションのリスクを減少させます。
参考URL : 温度パラメータを下げる

※ランダム性と多様性
どのシーケンスでも、モデルはシーケンス内の次のトークンのオプションの確率分布を決定します。出力で各トークンを生成するために、モデルはこの分布からサンプリングします。ランダム性と多様性とは、モデルのレスポンスにおける変動量を指します。これらの要因は、分布を制限または調整することで制御できます。基盤モデルでは通常、レスポンスのランダム性と多様性を制御するための以下のパラメータがサポートされています。

・[温度]
予測出力の確率分布の形状に影響し、モデルがより確率の低い出力を選択する可能性にも影響します。

確率の高い出力を選択するには、モデルに影響する値を低く設定します。
確率の低い出力を選択するには、モデルに影響する値を高く設定します。

専門用語で言うと、温度は次のトークンの確率質量関数を変調します。温度が低いほど関数が急勾配になり、レスポンスがより決定論的になります。一方、温度が高いほど関数が平坦になり、ランダムなレスポンスが多くなります。
参考URL : ランダム性と多様性

※(引用) LLM はなぜ幻覚を見せるのか 回答生成の仕組みを掘り下げる
LLM は誤った情報をまことしやかに提示し、幻覚 (ハルシネーション) を見せることがある。LLM に基づく生成 AI は「嘘をつく」と言われるゆえんであり、「検証が必須」とされる理由でもある。なぜ幻覚を見せるのか。それは LLM の仕組みを理解するとよく分かる。

LLM は言葉と言葉のつながりを学習したものである。そのつながりの学習結果に基づき、ある単語に続く単語はどれであるかを確率として算出し、その可能性が高い「つながりそうな」単語を続ける (図) 。正確には単語ではなく「トークン」と呼ばれる、文字のつながりを細かく区切ったものが用いられる。

この仕組みでは、個々の単語が持つ意味などは考慮されない。それゆえに幻覚が発生 するのだ。
文章・画像引用 : LLM はなぜ幻覚を見せるのか 回答生成の仕組みを掘り下げる

■以下は間違いです。
・幻覚 (ハルシネーション) が発生しないようにトレーニングされた基礎モデル (FM) を使用します。
→幻覚 (ハルシネーション) が一切発生しないように完全にトレーニングされた基礎モデルは存在しないため間違いです。

具体的には、現時点で幻覚 (ハルシネーション) が完全に発生しないことを保証する基礎モデル (FM) は実用化されておらず、モデルの構造上、一定の幻覚 (ハルシネーション) リスクは常に存在します。

・データの前処理を使用して、幻覚 (ハルシネーション) を引き起こすデータを削除します。
→データセットから行を削除してもモデルの生成確率分布は変わらず幻覚 (ハルシネーション) を防げないため間違いです。

具体的には、幻覚 (ハルシネーション) を引き起こす特定のデータを完全に特定することは困難であり、実際の幻覚 (ハルシネーション) はモデルの生成プロセスに起因するため、前処理でのデータ除去による幻覚 (ハルシネーション) 抑制には限界があります。

・Amazon Bedrock のエージェントを設定して、モデルのトレーニングを監視します。
→「Amazon Bedrock のエージェント」 はトレーニング済みモデルを監視して幻覚 (ハルシネーション) を防ぐ機能を持っていないため間違いです。

具体的には、Amazon Bedrock のエージェント はモデルのトレーニング監視ではなく、推論時のタスクを自動化して処理を補助する機能を提供します。そのため、モデルの幻覚 (ハルシネーション) を監視して防止する仕組みを提供していません。

Chain-of-Thought (CoT: 思考の連鎖) プロンプティング

「Chain-of-Thought (CoT: 思考の連鎖) プロンプティング」 を用いることで、詳細な推論や段階的な説明プロセスを効果的に引き出すことができるため正解です。

具体的には、Chain-of-Thought (CoT: 思考の連鎖) プロンプティング は、大規模言語モデルが複雑な問題に対して高品質な回答を出すために、「中間的な推論ステップ」 を明示的に出力するよう促す手法です。これにより、モデルは単一の最終出力だけでなく、「各ステップでどのように結論に至ったのかを説明しながら」 回答を構築します。このプロセスは、「数学的問題、論理的推論、文章理解」 など、複数の推論段階を必要とする複雑なタスクにおいて有効です。モデルの思考を言語化することで、回答の透明性と正確性が向上します。

※Chain of thought (思考の連鎖) プロンプティング
Chain of thought (思考の連鎖) プロンプティングは、複数のプロンプトをつなげることで、大規模言語モデル (LLM) がより自然なコンテキストを考慮した出力を生成できるようにするプロンプトエンジニアリングの手法です。 CodeWhisperer を利用する際、この手法を用いて非常に複雑なコーディングタスクを小さなステップに分解することによって、 CodeWhisperer がユースケースに対してより正確なレコメンデーションを行うことができます。
参考URL : Chain of thought (思考の連鎖) プロンプティング

※(引用) Chain-of-Thought (CoT: 思考の連鎖)Prompting(プロンプティング) とは ?
最近の自然言語処理において、言語モデルの思考の連鎖 (CoT:Chain-of-Thought) プロンプティング (Prompting) とは、問題を解くまでの一連の手順をプロンプト (= 言語モデルに入力するテキスト) に含めるテクニックのことである。例えば図 1 の下にある「標準的なプロンプティング」では結果の例文だけをデモンストレーションとして提示しているのに対し、図 1 の上にある「CoT プロンプティング」では途中の計算過程 (推論手順の流れ) の例文を提示している。

通常の人間の思考では、例えば算術の問題 (例 : 「2 個のリンゴと 3 個のリンゴの合計は ?」) を解く際、いきなり計算結果 (「答えは 5 個。」) が求まるのではなく、問題を途中の手順 (計算過程) に分解して段階的に解いていく (例えば「2 個と 3 個を足すので、2+3=5 を計算して、答えは 5 個。」) のが一般的である。このような「途中の段階的な思考プロセス」を模倣して、その途中の推論 (reasoning) 手順の流れをフューショット学習 (Few-shot Learning) の例文 / 見本として含める、というのが基本的な CoT プロンプティングだ。

文章・画像引用 : Chain-of-Thought (CoT: 思考の連鎖)Prompting(プロンプティング) とは ?

■以下は間違いです。
・方向性刺激プロンプティング (Directional Stimulus Prompting)
→「方向性刺激プロンプティング (Directional Stimulus Prompting)」 は、段階的な思考プロセスを生成するための手法ではないため間違いです。

具体的には、「方向性刺激プロンプティング (Directional Stimulus Prompting)」は、モデルに特定のスタイルや出力形式を誘導すること を目的とした手法であり、例えば 「より礼儀正しく応答してください」 といった形で使用されます。しかしこの手法では、問題解決に必要な段階的推論プロセスや説明展開を明示的に誘導することはできません。そのため、複雑な論理的思考や多段階の推論を必要とするタスクには不十分です。

・Zero-shot プロンプティング
→「Zero-shot プロンプティング」 は事例を示さず最終回答のみを生成させるため、推論過程が出力されず間違いです。

具体的には、Zero-shot プロンプティング は、事前に例を示さずに直接質問する方法であり、モデルに対してどのように考えるか、どのように段階的に推論すべきかのガイドを与えることができません。そのため、複雑な問題を解くために必要な思考プロセスをモデルが内在的に展開できないケースが多くなります。推論過程を明示的に導く必要があるタスクには不適です。

・Few-shot プロンプティング
→「Few-shot プロンプティング」 は少数の例示で応答パターンを学習させるだけで、段階的推論の出力を要求しないため間違いです。

具体的には、Few-shot プロンプティング は、プロンプト内にいくつかの例を含めて、モデルに類似のタスクを実行させる方法ですが、段階的な思考プロセスや中間推論ステップを明示的に出力させる設計にはなっていません。例が複雑な推論を含んでいない限り、モデルは単に結論を模倣するだけの出力を行うため、複雑な論理構造の視覚化や説明には適しません。

※Prompt Engineering Techniques

サービス名	特徴	主な用途
Chain-of-Thought Prompting	モデルに中間推論ステップを言語化させることで 段階的な思考プロセスを可視化し、複雑な問題解決の精度を高める 。	複数の計算や論理を順番に行うタスクで有効。 例 : 中学生向けの算数の文章題で「りんごを 20 個、みかんを 3 箱 (1 箱 47 個) 買ったら合計はいくつ ?」と聞くと、モデルが「Step 1: 20 × 1 = 20 個」「Step 2: 3 × 47 = 141 個」「Step 3: 合計 = 161 個」と順に説明して答えを示す。
Few-shot Prompting	プロンプトに少数の例を含めて類似の出力を誘導する。推論過程は出力しないため結論のみを模倣しやすい。	パターン学習やフォーマット統一が必要なタスクに適用。 例 : 英単語とその日本語訳を 2 つ示し、「banana = ばなな」と続けさせて追加の単語を訳させる。
Zero-shot Prompting	例を一切提示せずに直接タスクを指示するシンプルな形式。思考過程を明示せず回答のみを出す。	一般知識を素早く引き出す質問に適用。 例 : 「東京タワーの高さを教えて」と聞くだけで即座に答えを返させる。
Directional Stimulus Prompting	出力のトーンやスタイルを方向付ける追加指示を与える。推論の深さより表現形式を制御することに長ける。	回答の語調やフォーマット統一が重要な場面で使用。 例 : 「この質問には敬語で丁寧に答えて」と指示し、礼儀正しい日本語で返答させる。

プロンプトエンジニアリング

「プロンプトエンジニアリング」 により FM を再トレーニングせずに応答精度を向上でき、追加コストを最小化できるため正解です。

具体的には、プロンプトエンジニアリング とは、「基盤モデル (FM)」 の出力結果を意図した内容に近づけるために、入力するプロンプトの設計や構造を工夫する手法です。Amazon Bedrock を利用する場合、モデル自体のトレーニングやファインチューニングにはコストと時間がかかりますが、プロンプトエンジニアリングは 「モデルの再トレーニングを伴わずに性能を向上」 させるため、コストを抑えながら 「応答精度の最適化」 が可能です。また、Amazon Bedrock は既存の基盤モデルへのプロンプト提供を前提としており、この特性にも合致します。

※プロンプトエンジニアリング (Prompt Engineering) とは ?
大規模言語モデル (LLM) によるチャット AI や画像生成 AI などの生成系 AI におけるプロンプトエンジニアリング (Prompt Engineering) とは、より望ましい生成結果 (返答テキストや画像など) が得られるように、ユーザーが AI モデルに入力する質問や指示のテキスト (= プロンプト :Prompt) を工夫することである。

文章・画像引用 : プロンプトエンジニアリング (Prompt Engineering) とは ?
参考URL : プロンプトエンジニアリングとは何ですか ?
参考 PDF : プロンプトエンジニアリング入門

※(引用) 【 Copilot 活用術 vol.6 】生成 AI の精度 UP プロンプトエンジニアリングを解説 /Zero-Shot と Few-Shot の違い /CoT ・Self-Consistency ・ReAct の使い分け


※プロンプトエンジニアリングの代表的な手法

手法名	概要	主な用途・例
思考の連鎖 (Chain-of-Thought)	複雑なタスクを細分化し、ステップごとのプロンプトを作成して解決を導く手法。	・問題解決の手順を一歩ずつ説明する応答 ・「次のステップは何ですか？」を繰り返しながら進める
ゼロショット (Zero-shot)	例を示さずに、タスクに関する説明のみを提示する手法。	・単純な命令や質問: 「次の文を翻訳してください。」 ・直接的なタスク指定
シングルショット (Single-shot)	モデルに応答の例を1つ提示することで、望ましい回答パターンを誘導する手法。	・例: 質問に対する模範回答を1例だけ提示
フューショット (Few-shot)	モデルに応答の例を複数提示することで、望ましい回答パターンを誘導する手法。	・例: 質問に対する複数の模範回答を提示 ・「次の形式に従って答えてください」
プロンプトテンプレート	モデルがタスクや制約を理解するために使用する構造化された指示のセットを利用する手法。	・テンプレートに基づいた特定の形式やスタイルの応答 ・「以下の形式で答えてください」

■以下は間違いです。
・新しい FM をトレーニングします。
→新たな基盤モデルのトレーニングは、非常に大規模なリソースと多額の費用を要するため間違いです。

具体的には、新規の基盤モデルをゼロからトレーニングするには、高性能なコンピューティングリソースと長期にわたる計算時間を必要とします。これは既存のモデルを活用しプロンプトの設計を工夫するよりも著しく高コストになります。

・FM を再トレーニングします。
→基盤モデルを再トレーニングすると大量のリソースと高額なコストが発生するため間違いです。

具体的には、基盤モデル (FM) の再トレーニングには膨大な計算資源 (GPU や TPU など) と大量のデータが必要であり、Amazon Bedrock の既存モデルをそのまま利用しプロンプトを調整する方法に比べ、費用対効果が非常に悪化します。

・FM をファインチューニング (微調整) します。
→基盤モデルの 「ファインチューニング」 は、プロンプトエンジニアリングに比べて時間と費用がかかるため間違いです。

具体的には、Amazon Bedrock 上で基盤モデルの ファインチューニング (微調整) を行うと、トレーニング用データの準備やコンピューティングリソースの使用に多くの時間と追加コストが発生します。プロンプトエンジニアリングの方が、モデルの調整を簡易かつ低コストで迅速に実施可能です。