Databricks Certified Generative AI Engineer Associate 教科書
第3章 アプリケーション開発(Application Development, 30%)
🎯 この節の学習目標
Databricks の Model Serving は、自分で学習・登録したモデルだけでなく、基盤モデル(Foundation Model)をAPIとしてすぐに呼び出せる仕組みを提供しています。GPUのプロビジョニングやモデルのダウンロード・デプロイ作業なしに、ワークスペース内のエンドポイントとしてLLMを利用できるのが最大の利点です。しかも Unity Catalog の権限管理、監査ログ、Unity AI Gateway(旧 Mosaic AI Gateway)(4-4)といったガバナンス機構と統合されています。
提供形態は次の3つに大別されます。この区別は試験でもよく問われます。
| 提供形態 | 内容 | 向いている場面 |
|---|---|---|
| pay-per-token | Databricks が運用する共有エンドポイントを、処理したトークン数に応じた課金で利用する。Meta Llama 系などの主要オープンモデルが最初から使える | PoC・検証、低頻度・不定期なワークロード。すぐ試したいとき |
| Provisioned Throughput | 専用のスループット(処理能力)を確保したエンドポイント。性能が保証され、ファインチューニング済みモデルもホストできる | 本番運用、高負荷・安定したトラフィック、レイテンシ/スループット保証が必要な場面 |
| External Models | OpenAI や Anthropic など外部プロバイダのモデルを、Databricks のエンドポイント経由で統一的に呼び出す。APIキーは Databricks 側で集中管理 | 外部の商用モデルを使いつつ、認証・ガバナンス・レート制限を Databricks に集約したい場面 |
📝 試験のポイント
「PoC を素早く始めたい/たまにしか呼ばない → pay-per-token」「本番の高トラフィックで性能保証が必要 → Provisioned Throughput」「OpenAI などの外部モデルをガバナンス下で使いたい → External Models」という対応付けを即答できるようにしてください。コスト最適化の観点(4-7)とセットで問われます。
Databricks の Foundation Model API は OpenAI 互換の REST API を提供しているため、広く使われている openai パッケージのクライアントをそのまま使えます。base_url をワークスペースの serving-endpoints に向けるだけです。
💡 コード例:OpenAIクライアントでの呼び出し
from openai import OpenAI
client = OpenAI(
api_key=DATABRICKS_TOKEN, # Databricksのアクセストークン
base_url="https://<workspace-host>/serving-endpoints"
)
response = client.chat.completions.create(
model="databricks-meta-llama-3-3-70b-instruct", # エンドポイント名
messages=[
{"role": "system", "content": "あなたは簡潔に答えるアシスタントです。"},
{"role": "user", "content": "RAGとは何ですか?"}
],
temperature=0.1,
max_tokens=500
)
print(response.choices[0].message.content)
model には Databricks 上のサービングエンドポイント名を指定します。既存のOpenAI向けコードを最小の変更で移行できるのがこの方式の利点です。
SQLから直接LLMを呼び出せるのが ai_query() 関数です。Delta テーブルの各行に対してバッチでLLM処理(要約・分類・抽出など)を適用する場面で特に便利で、データエンジニアリングのパイプラインに自然に組み込めます。
💡 コード例:ai_query() によるバッチ推論
SELECT
review_id,
ai_query(
'databricks-meta-llama-3-3-70b-instruct',
CONCAT('次のレビューを positive / negative / neutral のいずれかに分類してください: ',
review_text)
) AS sentiment
FROM main.reviews.customer_reviews;
第1引数がエンドポイント名、第2引数がプロンプトです。テーブル全行への一括適用が1つのSQLで書けるため、「SQLだけでLLMをデータに適用したい」という要件の正解選択肢としてよく登場します。
MLflow の Deployments クライアントを使うと、Databricks のサービングエンドポイントを統一的なインターフェースで呼び出せます。
from mlflow.deployments import get_deploy_client
client = get_deploy_client("databricks")
response = client.predict(
endpoint="databricks-meta-llama-3-3-70b-instruct",
inputs={
"messages": [{"role": "user", "content": "RAGとは何ですか?"}],
"max_tokens": 500
}
)
3-1〜3-2 で学んだ LangChain のチェーンに Databricks のエンドポイントを組み込むには、ChatDatabricks を使います。
from databricks_langchain import ChatDatabricks
llm = ChatDatabricks(
endpoint="databricks-meta-llama-3-3-70b-instruct",
temperature=0.1,
max_tokens=500
)
answer = (prompt | llm | parser).invoke({"question": "RAGとは?"})
チェーン内のLLM部品としてそのまま差し込めるため、RAGチェーンやエージェント(3-9)の構築ではこの方式が標準的です。
| 呼び出し方法 | 主な用途 |
|---|---|
| OpenAI互換クライアント | 汎用。既存のOpenAI向けコードからの移行、アプリケーションコード |
| MLflow Deployments SDK | MLflow中心のワークフロー、エンドポイントの統一的な操作 |
| SQL ai_query() | テーブルデータへのバッチ推論、SQLパイプラインへの組み込み |
| LangChain ChatDatabricks | LangChainのチェーン・エージェントの部品として |
どの呼び出し方法でも共通して指定できる主要パラメータを押さえます。1-4 のプロンプト設計と合わせて、出力の品質・形式・コストを制御する基本手段です。
| パラメータ | 意味 | 実務での指針 |
|---|---|---|
| temperature | 出力のランダム性。低いほど決定的、高いほど多様 | 分類・抽出・RAGの事実回答は低め(0〜0.2)、創作的な文章生成は高め |
| max_tokens | 生成する最大トークン数 | 出力の上限を制御しコストと途中切れを管理。短い分類タスクでは小さく設定 |
| top_p | 累積確率によるサンプリング範囲の制限 | temperature とどちらか一方を主に調整するのが一般的 |
| stop | 生成を打ち切る文字列 | 決まった区切りで出力を止めたいときに使用 |
📝 試験のポイント
「回答の一貫性・再現性を高めたい → temperature を下げる」「回答が途中で切れる → max_tokens を増やす(またはコンテキスト長を確認)」という対応はよく問われます。逆に「temperature を上げると事実性が上がる」といった選択肢は誤りです。
✅ この節のまとめ
問1. チームが RAG アプリケーションの PoC を始めようとしている。呼び出し頻度は低く、まずは Llama 系モデルで検証したい。最も適切な提供形態はどれか。
正解:B
PoC・低頻度のワークロードには、セットアップ不要でトークン数に応じた課金で使える pay-per-token が最適です。Aは専用スループットを常時確保するため低頻度の検証にはコスト過剰です。Cはインフラ管理の手間が大きく、Foundation Model API の利点を捨てています。Dは「Llama系で検証したい」という要件に合いません(External Models は外部プロバイダのモデル向け)。
問2. 本番環境で安定した高トラフィックが見込まれ、レイテンシとスループットの保証が必要なチャットアプリケーションをデプロイする。最も適切な提供形態はどれか。
正解:B
Provisioned Throughput は専用の処理能力を確保するため、高負荷・本番ワークロードでの性能保証に適しています。Aの共有エンドポイントは手軽ですが、専用の性能保証が必要な本番高負荷には不向きです。Cはサービングインフラとしてスケーラビリティ・可用性を欠きます。Dの ai_query() はバッチのSQL処理向けであり、対話型アプリのリアルタイム呼び出し経路としては不適切です。
問3. Delta テーブルに保存された100万件の顧客レビュー全件に感情分類を適用したい。データエンジニアはSQLパイプラインの中でこれを完結させたい。最も適切な方法はどれか。
正解:B
ai_query() はSQLからサービングエンドポイントを呼び出す関数で、テーブル全行へのバッチ推論をSQLだけで実現できます。Aは実装・運用の手間とスループットの面で非効率です(バッチ用途にはSQL/Spark経由が定石)。Cは規模的に非現実的です。Dは会話履歴の保持のための部品であり、バッチ分類とは無関係です。
問4. RAGアプリケーションの回答が呼び出しのたびに大きく変わり、事実に基づく一貫した回答が得られないという苦情がある。最初に調整すべきパラメータとして最も適切なのはどれか。
正解:A
temperature は出力のランダム性を制御します。事実性・一貫性が求められるRAGの回答では低い値に設定するのが定石です。Bは逆効果で、多様性が増して回答のブレが大きくなります。Cのmax_tokensは出力の長さの上限であり、一貫性には直接影響しません。Dのstopは生成の打ち切り位置の制御で、回答のブレとは無関係です。