Databricks Certified Generative AI Engineer Associate 教科書
第1章 生成AIアプリケーション設計(Design Applications, 14%)
🎯 この節の学習目標
1-1で要件をタスクに分解したら、次は各タスクを実行するモデルを選びます。「一番賢いモデルを選べばよい」わけではありません。高性能なモデルほど一般に高コスト・高レイテンシであり、業務要件によってはむしろ不適切になります。選定は次の6軸のトレードオフとして考えます。
| 評価軸 | 確認する内容 | 典型的な問いかけ |
|---|---|---|
| タスク複雑度 | 単純な分類・抽出か、複雑な推論・長文生成か | 「小型モデルでも品質要件を満たせるか?」 |
| 品質(精度) | 許容できる誤り率、出力の一貫性・忠実性 | 「誤答のビジネスインパクトはどれほどか?」 |
| レイテンシ | 応答までの許容時間(対話型かバッチか) | 「ユーザーは何秒待てるか?」 |
| コスト | トークン単価 × 呼び出し回数 × 入出力長 | 「1日あたり何件処理し、予算はいくらか?」 |
| コンテキスト長 | 1回の呼び出しで渡す入力の量 | 「長文書・長い会話履歴・多数の検索結果が入るか?」 |
| データプライバシー・ガバナンス | データを外部APIに送ってよいか、地域・規制の制約 | 「機密データを自社環境内で処理する必要があるか?」 |
📝 試験のポイント
試験では「品質・コスト・レイテンシなどの属性に基づいてチェーンに使うモデルを選ぶ」形式の設問が出ます。設問文の中に「リアルタイムで」「コストを最小化したい」「機密データのため外部に出せない」といった制約キーワードが埋め込まれているので、それを見つけて優先すべき軸を特定するのが解法の第一歩です。
モデル選定の最重要原則は、品質要件を満たす中で最も小さく・安く・速いモデルを選ぶことです。大は小を兼ねますが、その分コストとレイテンシを常に払い続けることになります。
💼 例:同じアプリ内でモデルを使い分ける
1-1のサポートボットの例では、パイプラインが「分類 → 検索 → 生成」の3ステージでした。ステージごとに要件が異なるため、モデルも変えるのが合理的です。
このようにチェーンの各ステージに最適なモデルを割り当てる発想は、1-5(マルチステージ設計)の利点にも直結します。
もう1つの大きな選択が、プロプライエタリモデル(APIで提供される商用モデル)と、オープンモデル(Llama系など、重みが公開されているモデル)のどちらを使うかです。
| 観点 | プロプライエタリモデル(商用API) | オープンモデル(Llama系など) |
|---|---|---|
| 品質 | 最高水準のモデルが多く、複雑なタスクに強い | 近年大きく向上。多くの実務タスクで十分な品質 |
| コスト構造 | トークン従量課金。使うほど増える | ライセンス費は原則不要。自前のサービング基盤(GPU)のコストがかかる |
| カスタマイズ性 | 提供される範囲に限られる | 重みにアクセスできるためファインチューニングの自由度が高い |
| ホスティング | プロバイダー側で実行(データが外部に出る) | 自社環境内でホスト可能。データを外に出さずに済む |
| 運用負担 | 小さい(APIを呼ぶだけ) | サービング・スケーリング・更新を自分で管理(Databricksのサービング基盤で軽減可能) |
Databricks 環境では、外部の商用モデルとオープンモデルの両方を Model Serving 経由で統一的に利用できます(第3章で詳述)。選定の決め手になりやすいのは次の2点です。
レイテンシ要件は利用形態によって大きく異なります。
| 利用形態 | レイテンシ要件 | 設計の指針 |
|---|---|---|
| 対話型(チャットボット、コパイロット) | 厳しい(秒単位で応答が必要) | 小型・高速モデルを優先。ストリーミング応答で最初のトークンを早く見せ、体感を改善する |
| ニアリアルタイム(問い合わせ振り分けなど) | 中程度 | 品質とのバランスで中型モデルも選択肢 |
| バッチ処理(夜間の一括要約、大量文書の抽出) | 緩い(処理時間よりスループットと総コスト) | 大型モデルでも許容される。品質を優先しやすい |
マルチステージのチェーン(1-5)では各ステージのレイテンシが積み上がることにも注意してください。対話型アプリでステージ数が多い場合、各ステージを小型モデルにする、並列化できる処理は並列にする、といった工夫が必要です。
モデルには一度に処理できるトークン数の上限(コンテキストウィンドウ)があります。入力(プロンプト+参照文書+会話履歴)と出力の合計がこの上限に収まらなければなりません。
📝 試験のポイント
「長大な文書を扱う必要があるがモデルのコンテキストに収まらない」というシナリオでは、より長いコンテキストのモデルへの変更、チャンク分割+検索(RAG)、逐次要約が定番の対処です。逆に「文書全部を毎回プロンプトに入れる」選択肢はコスト・制約の面で誤答になるのが典型パターンです。
✅ この節のまとめ
問1. ECサイトのカスタマーレビューを「ポジティブ/ネガティブ/中立」の3値に分類するバッチ処理を毎日100万件実行したい。品質は現行の小型モデルで十分達成できている。モデル選定として最も適切なのはどれか。
正解:B
「要件を満たす最小のモデルを選ぶ」原則の典型問題です。品質要件をすでに満たしているのに大型モデルへ切り替える(A)のは、100万件規模ではコストの大幅な無駄になります。Cはレビュー分類に長いコンテキストは不要なので的外れ、Dは呼び出し回数が倍増しコストが跳ね上がるうえ、要件に対して過剰です。
問2. 金融機関が、顧客の取引データを含む文書を処理する生成AIアプリを構築する。社内ポリシーにより機密データを外部のAPIサービスへ送信することが禁じられている。最も適切なアプローチはどれか。
正解:B
データガバナンス制約が最優先軸になるシナリオです。オープンモデルは自社環境内でホストできるため、データを外部に出さずに生成AIを利用できます。AとCはデータが外部に送信される時点でポリシー違反であり、圧縮や削除依頼は解決になりません。Dは制約を満たす選択肢(B)が存在するため不適切です。
問3. リアルタイムの対話型アシスタントを開発している。ユーザーテストで「応答が遅い」という不満が多い。品質は現状でおおむね許容範囲である。改善策として最も適切な組み合わせはどれか。
正解:B
対話型アプリでレイテンシが問題なら、小型・高速モデルへの変更とストリーミング応答が定石です。Aは大型化も入力増加もレイテンシを悪化させます。Cは対話型という利用形態そのものを壊します。Dは入力トークンが増えて応答開始がさらに遅くなります。
問4. 数百ページに及ぶ技術マニュアルに関する質問応答システムを作りたいが、マニュアル全文は利用予定モデルのコンテキストウィンドウに収まらない。最も適切な設計はどれか。
正解:B
コンテキストウィンドウ制約への標準的な解決策はチャンク分割+検索(RAG)です。Aはそもそも物理的に収まらず、収まったとしてもコストとレイテンシが非現実的です。Cは制約の原因が質問文ではなく参照文書側なので効果がありません。Dは目次だけでは回答の根拠となる本文情報が欠落します。