企業は、寛容なライセンスと補償を備えた指示に従うモデルを必要としています。
サードパーティーのホスト型モデルではなく、watsonx.ai カタログから IBM Granite instruct モデルを選択します。
理由: Granite モデルは IBM によって構築、統制されており、IBM's の知的財産補償が付帯しています。これは、規制対象のワークロードにとって安全なデフォルトの選択肢です。
最終確認：2026年6月
C1000-185 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
企業は、寛容なライセンスと補償を備えた指示に従うモデルを必要としています。
サードパーティーのホスト型モデルではなく、watsonx.ai カタログから IBM Granite instruct モデルを選択します。
理由: Granite モデルは IBM によって構築、統制されており、IBM's の知的財産補償が付帯しています。これは、規制対象のワークロードにとって安全なデフォルトの選択肢です。
単一ターン抽出タスクのために、チャット向けに調整されたバリアントと指示向けに調整されたバリアントのどちらかを選択しています。
明確な指示プロンプトと共に instruct バリアントを使用し、チャットモデルは複数ターンの対話のために予約しておきます。
理由: チャットモデルは役割構造化されたターンを期待します。ワンショットタスクの場合、instruct モデルの方がシンプルで安価です。
コンプライアンス・レポートのために、出力は決定論的で再現可能である必要があります。
デコーディングを貪欲（サンプリングなし）に設定し、常に最も確率の高いトークンが選択されるようにします。
理由: 貪欲なデコーディングはランダム性を排除します。温度を使用したサンプリングは、監査対象の出力に望ましくないバリエーションを導入します。
クリエイティブなコピーの生成が反復的で単調に感じられます。
サンプリングデコーディングに切り替え、温度を上げて（例：0.7-1.0）トークン分布を広げます。
理由: 温度が高いと確率が平坦化され、順位の低いトークンが選択されるようになり、多様性が増します。
サンプリング出力が、まれなトークンによって時々トピックから外れます。
top-k または top-p (nucleus) でサンプリングを制約し、候補を最も確率の高いトークンに限定します。
理由: top-k は候補数を制限し、top-p は累積確率質量を制限します。どちらもドリフトの原因となるロングテールを切り詰めます。
モデルがループし、同じフレーズや文を繰り返します。
最近のトークンの再生成を抑制するために、繰り返しペナルティ・パラメーターを増やします。
理由: ペナルティは既に見たトークンの確率を下げます。停止シーケンスだけでは、生成中のループは修正されません。
生成が回答を通り過ぎ、幻覚的な続きのテキストに突入します。
1つ以上の停止シーケンス（例：「\n\n」、「###」）を定義して、既知の境界で生成が停止するようにします。
理由: 停止シーケンスは出力を決定論的に終了させます。最大トークンだけに頼ると、文の途中で切り詰められます。
要求された JSON が完了する前に、応答が途中で切り詰められています。
最大新規トークン数を増やします。必要に応じて最小新規トークン数を設定して、最小限の長さの回答を強制します。
理由: 最大新規トークン数は出力長を制限します。少なすぎると、閉じ括弧の前に構造化出力が切り詰められます。
ゼロショット分類が、エッジケースを誤って分類します。
プロンプト内にラベル付きの入力/出力の例をいくつか（few-shot）直接追加します。
理由: Few-shot の例は、チューニングなしで、コンテキスト内で出力形式と決定境界を設定します。
チームはコードを書く前にプロンプトを反復処理したいと考えています。
Prompt Lab を使用します。フリーフォーム、構造化、チャットモードを切り替え、パラメーターを調整し、プロンプトテンプレートとして保存します。
理由: Prompt Lab はノーコードの反復サーフェスです。構造化モードは、指示、例、入力をきれいに分離します。
長いドキュメントが、選択したモデルのコンテキストウィンドウを超過します。
ドキュメントをチャンクに分割して関連するパッセージのみを検索するか (RAG)、カタログからより長いコンテキストモデルを選択します。
理由: モデル's のトークン制限を超えることはできません。テキストを詰め込みすぎると、通知なくドロップまたはエラーが発生します。検索はスケーラブルな解決策です。
プロンプト・エンジニアリングが、一貫したスタイルを必要とする狭いドメインタスクで限界に達しています。
Tuning Studio でプロンプトチューニングを実行し、ラベル付きの例に基づいてソフトプロンプト（チューニング済みベクトル）を学習します。
理由: プロンプトチューニングは、基本の重みを変更せずに動作を適応させます。ファイン・チューニングよりも安価で、長いプロンプトよりも信頼性があります。
モデルが最新の事実に基づいた企業知識を欠いています。
その事実に基づいてモデルをチューニングするのではなく、RAG を使用して検索されたドキュメントに回答を根拠づけます。
理由: チューニングはスタイルや動作を教えますが、新しい事実を教えるわけではありません。RAG は現在の根拠に基づいたコンテキストを注入し、簡単に更新できます。
アソシエイトレベルの watsonx プロジェクトで、プロンプトチューニングとフルファイン・チューニングのどちらにするか決定しています。
プロンプトチューニングを推奨します。パラメーター数がはるかに少なく、実行が高速で、Tuning Studio でサポートされているパスです。
理由: フルファイン・チューニングはコストがかかり、大規模なデータセットが必要で、壊滅的忘却のリスクがあります。プロンプトチューニングは watsonx のデフォルトです。
要約モデルをプロンプトチューニングするためのデータを準備しています。
期待される JSON/JSONL 形式で入力/出力ペアを提供し、トレーニングセットと検証セットに分割します。
理由: クリーンで代表的なペアがチューニング品質を向上させます。汎化を評価するためには、保留された検証セットが必要です。
チューニング損失曲線が早期に平坦化する一方で、検証損失が上昇し始めています。
エポックを停止または削減します。モデルはトレーニングセットに過学習し始めています。
理由: トレーニング損失と検証損失の乖離は、古典的な過学習の兆候です。エポック数を増やすと、汎化ではなく記憶が促進されます。
プロンプトチューニングの結果が実行間で不安定です。
チューニング構成の学習率、エポック数、バッチサイズ、および仮想トークン数を調整します。
理由: 学習率が高すぎるとトレーニングが不安定になります。これらは、Tuning Studio が収束のために公開しているレバーです。
2つのプロンプトまたはチューニング済みアセットを客観的に比較する必要があります。
タスクメトリクス（例：要約の ROUGE/BLEU、抽出の exact-match/F1）と人間によるレビューで評価します。
理由: 生成品質は多次元です。自動化されたメトリクスは回帰を捉えますが、人間によるレビューは忠実性を判断します。
チューニングされたモデルが、ソースに存在しない事実をまだ捏造しています。
RAG で根拠を与え、温度を下げ、提供されたコンテキストからのみ回答するか、わからない場合はそう答えるようにモデルに指示します。
理由: 幻覚は重みの問題というよりも、根拠とデコーディングの問題です。検索と制約の組み合わせでほとんどが解決されます。
適応のために利用できるラベル付きの例が数十個しかありません。
few-shot プロンプティングまたは軽度のプロンプトチューニングに留めます。ごく小さなデータではファイン・チューニングを行いません。
理由: 小規模なデータセットは、フルファイン・チューニングではひどく過学習します。その規模では、コンテキスト内の例の方が汎化性が高くなります。
分類タスクのためにどの基盤モデルをプロンプトチューニングするかを選択しています。
Tuning Studio がプロンプトチューニングをサポートしている、タスクのサイズに合わせたチューニング可能な Granite 基盤モデルを選択します。
理由: すべてのカタログモデルがチューニング可能であるわけではありません。サポートされているより小さなモデルをチューニングする方が安価で、多くの場合、分類には十分です。
生成出力の品質を本番環境で継続的に追跡する必要があります。
デプロイメントに対して watsonx.governance の評価メトリクス（品質、ドリフト、生成AIメトリクス）を構成します。
理由: ガバナンスは、一度限りの評価を手動のスポットチェックではなく、アラート付きの監視対象しきい値に変換します。
同じチューニング済みプロンプトで、異なるフィールドを持つ多数の入力を処理する必要があります。
プロンプトテンプレートを名前付き変数でパラメーター化し、推論時に値を供給します。
理由: 変数を使用することで、入力をハードコーディングする代わりに再利用可能なテンプレートを1つ維持でき、APIパラメーターにもきれいにマッピングされます。
モデルがタスク指示を無視し、テキストを単に続行します。
指示用に調整されたモデルを使用し、プロンプトを完了させるための断片ではなく、明示的な指示として構成します。
理由: 基本の完了モデルはパターンを続行しますが、指示モデルは指示に従うようにトレーニングされています。
AI機能の準備のために、オブジェクトストレージデータ全体でインタラクティブなSQLを実行する必要があります。
オブジェクトストレージ内の Iceberg テーブルに対して watsonx.data Presto エンジンを使用します。
理由: Presto は、データをウェアハウスにコピーすることなく、オープンなテーブル形式で高速なフェデレーテッド SQL を提供します。
分析データには、レイクハウス上でのスキーマ進化とタイムトラベルが必要です。
watsonx.data によって管理される Apache Iceberg テーブルとして保存します。
理由: Iceberg は、オブジェクトストレージでのスキーマ進化、スナップショット、および ACID 操作をサポートします。これはレイクハウスのデフォルトです。
大規模な ETL 変換とアドホッククエリーのどちらにエンジンを選択するか決定しています。
大規模なバッチ変換/ETL には Spark を使用し、インタラクティブで低レイテンシーの SQL には Presto を使用します。
理由: Spark はバッチ計算をスケーリングします。Presto は高速なフェデレーテッドクエリー用に最適化されています。ワークロードの形状によって選択します。
RAG には、統制されたデータと共に配置されるエンベディング用のベクター・ストアが必要です。
watsonx.data 内に Milvus を類似性検索用のベクターデータベースとしてプロビジョニングします。
理由: Milvus は統合された watsonx.data のベクター・ストアです。エンベディングをレイクハウスに保持することで、ガバナンスが簡素化されます。
検索のために Milvus と watsonx Discovery のどちらにするか決定しています。
制御する生のベクター類似性には Milvus を使用します。ハイブリッド検索を備えた管理型エンタープライズ検索には watsonx Discovery (Elasticsearch ベース) を使用します。
理由: Milvus は操作するベクター DB です。Discovery は、取り込みとランキングが組み込まれた高レベルの検索サービスです。
基盤モデルがそれらのドキュメントに基づいて回答を根拠づけることができるように、ドキュメントを準備しています。
ドキュメントをチャンク化し、watsonx.ai のエンベディングモデルでエンベディングを生成し、それらを Milvus にインデックス化します。
理由: 検索品質は、適切なチャンク化と一致するエンベディングモデルに依存します。次元の不一致はインデックスを破損させます。
AI機能には、複数のデータベースとバケットに分散されたデータが必要です。
watsonx.data にソースを登録し、エンジン's のフェデレーションを通じてそれらをその場でクエリーします。
理由: フェデレーションはコストのかかるデータの重複を回避し、単一の統制されたアクセスポイントを維持します。
ガバナンスチームは、モデルに供給されるデータに対するリネージとアクセス制御を要求しています。
watsonx.data カタログでデータセットをカタログ化し、IAM/ポリシーベースのアクセスを適用します。
理由: 統制されたカタログは、後でデータリネージをモデルのファクトシートにリンクするものです。アドホックなバケットアクセスはそれをバイパスします。
watsonx.ai プロジェクトは、RAG のためにキュレーションされたレイクハウステーブルを読み取る必要があります。
プロジェクトに watsonx.data 接続を追加し、テーブルをデータアセットとして参照します。
理由: 接続は、統制されたレイクハウスデータをコピーをエクスポートすることなく AI プロジェクトに公開します。
動作する Prompt Lab プロンプトを、再利用可能でデプロイ可能なアセットにする必要があります。
プロジェクト内でプロンプトテンプレートアセットとして保存し、その後デプロイメント・スペースにプロモートします。
理由: デプロイメント・スペースは本番環境の境界です。プロンプトは、提供される前にそこにプロモートされる必要があります。
アプリケーションは、チューニングされたプロンプト用の低レイテンシー推論エンドポイントを必要としています。
デプロイメント・スペースにオンラインデプロイメントを作成します。これにより、スコアリング/生成 REST エンドポイントが公開されます。
理由: オンラインデプロイメントは同期エンドポイントを提供します。バッチデプロイメントはオフラインのスコアリングジョブ用です。
Python アプリケーションコードから基盤モデルを呼び出しています。
watsonx.ai Python SDK の ModelInference クラスを使用し、パラメーターを指定して `generate_text` を呼び出します。
理由: ModelInference は、認証、モデル ID、プロジェクト/スペース、およびパラメーターを1つのクライアントにまとめます。これは生の REST よりもクリーンです。
Python 以外のサービスが watsonx.ai 推論を呼び出す必要があります。
モデル ID、入力、およびパラメーターを JSON ボディに含めて、watsonx.ai のテキスト生成 REST エンドポイントを呼び出します。
理由: REST API は言語にとらわれません。SDK は同じエンドポイントの単なるラッパーです。
watsonx.ai への SDK または API 呼び出しを認証しています。
IBM Cloud IAM API キーをベアラー・トークンと交換し、そのトークンとプロジェクト/スペース ID を使用してエンドポイントを呼び出します。
理由: watsonx は IBM Cloud IAM を使用します。各呼び出しで生の API キーを埋め込んだり、トークンをハードコーディングしたりすることは誤りであり、安全ではありません。
開発中とサービス提供時のモデルアセットの場所を決定しています。
プロジェクト内で開発と実験を行い、サービス提供のためにアセットをデプロイメント・スペースにプロモートします。
理由: プロジェクトは共同開発サンドボックスです。デプロイメント・スペースは、本番環境にプロモートされ、アクセス制御されたアセットを保持します。
検索と生成を1つのアプリケーションフローに連携させています。
クエリーをエンベッドし、Milvus/Discovery から top-k チャンクを検索し、それらをプロンプトテンプレートに注入してから、デプロイされたモデルを呼び出します。
理由: 検索してから生成する順序が回答の根拠となります。最初にモデルを呼び出すと RAG の意味がなくなります。
生成AIワークロードを watsonx 製品ファミリーにマッピングしています。
watsonx.ai で構築およびチューニングし、watsonx.data でデータを保存/クエリーし、watsonx.governance で統制および監視します。
理由: 3つのコンポーネントは補完的であり、互換性はありません。どれが何を行うかを知ることは、試験の中核的な知識です。
データレジデンシーの理由で、企業はオンプレミスで watsonx を必要としています。
IBM Cloud SaaS オファリングではなく、Cloud Pak for Data (Red Hat OpenShift) 上にソフトウェアとして watsonx をデプロイします。
理由: SaaS は IBM Cloud で実行されます。ソフトウェア形式は、レジデンシー/エアギャップのニーズのために独自の OpenShift クラスターで実行されます。
共同の生成AI作業とその成果物を整理しています。
共有アクセスを持つデータアセット、ノートブック、プロンプト、チューニング済みモデルを保持するワークスペースとして、watsonx プロジェクトを使用します。
理由: プロジェクトはコラボレーションとアセットスコープの単位です。デプロイメント・スペースは独立しており、本番環境向けです。
誰がどの watsonx インスタンスとアセットにアクセスできるかを制御しています。
アクセス範囲を設定するために、IBM Cloud アカウント、リソース・グループ、および IAM アクセス・ポリシー/役割を使用します。
理由: watsonx でのアクセスは、アカウント/リソース・グループレベルで IAM によって管理されます。アセットごとのアドホックな共有だけではありません。
基盤モデル推論の実行コストを見積もっています。
watsonx.ai 推論のトークンベースの課金と、watsonx.data でプロビジョニングされたエンジン/ストレージを考慮します。
理由: 生成AIのコストは入出力トークンが支配的です。レイクハウスとベクター・ストアの計算は別項目です。
watsonx 上での本番 RAG アーキテクチャーをスケッチしています。
レイクハウスデータ → Milvus 内のエンベディング → watsonx.ai 検索 + 生成 → アプリケーション。これらすべてを watsonx.governance が監視します。
理由: このエンドツーエンドのフローは、試験で認識することが期待される標準的な watsonx リファレンスパターンです。
監査人が、デプロイされたモデル's のライフサイクルと来歴の記録を求めています。
watsonx.governance AI factsheets を使用して、モデルのメタデータ、リネージ、およびライフサイクル全体での承認をキャプチャします。
理由: ファクトシートは、モデルの来歴に関する watsonx's の記録システムであり、「このモデルはどこから来たのか」という質問に対する文書化された回答です。
本番モデル's の出力が時間の経過とともに劣化します。
デプロイメントに対して、しきい値とアラートを備えた watsonx.governance のドリフトおよび品質モニターを構成します。
理由: 継続的な監視は、ユーザーが気づく前にドリフトを捕捉します。一度限りの検証では、デプロイ後の劣化を検出できません。
保護されたグループ間での不公平な扱いの有無をモデルで確認する必要があります。
watsonx.governance で公平性/バイアス評価を実行し、軽減策をファクトシートに文書化します。
理由: 責任ある AI の義務では、測定され記録された公平性が必要であり、測定されていない公平性の仮定だけでは不十分です。
コンプライアンスチームは、生成AIシステムをAI規制にマッピングする必要があります。
watsonx.governance を使用して、リスクを追跡し、コントロールを規制にリンクし、監査対応の証拠を維持します。
理由: ガバナンスは、モデルリスクを規制コントロールに一元的に結び付けます。これは、監査および IBM の責任ある AI 原則が要求するものです。