Databricks Certified Generative AI Engineer Associate 教科書
第4章 アプリケーションの組み立てとデプロイ(Assembling and Deploying Applications, 22%)
🎯 この節の学習目標
この節は総合演習です。第2章(データ準備)、第3章(アプリ開発)、第4章(デプロイ)で学んだ部品を1本につなぎ、「社内PDFに答えるRAGボット」を作りきる流れを通しで確認します。まず全体像です。
図:E2E RAGパイプラインの全体像。データ準備 → インデックス → チェーン → 登録 → デプロイ → 監視の一方通行
| ステップ | やること | 復習する節 |
|---|---|---|
| ① 文書配置 | UCのVolumeにPDFを配置 | 2-2 |
| ② パース&チャンキング | テキスト抽出・分割してDeltaテーブルへ(CDF有効) | 2-2, 2-3 |
| ③ インデックス作成 | AI SearchエンドポイントとDelta Sync Indexを作成 | 3-3 |
| ④ チェーン構築 | LangChainでretriever+prompt+LLMのRAGチェーンを組む | 3-1, 3-4 |
| ⑤ ログ&登録 | MLflowでログし、UCのModel Registryに登録 | 3-8, 4-1 |
| ⑥ デプロイ | agents.deploy() / Model Servingでエンドポイント化 | 4-2 |
| ⑦ 動作確認 | ai_queryやRESTでクエリして応答を確認 | 4-2 |
| ⑧ 監視 | 推論テーブルでログを確認し、評価・監視へつなぐ | 4-4、第5章へ |
📝 試験のポイント
試験では「RAGアプリ構築の手順を正しい順序に並べよ」という形式がよく問われます。データ準備(①②)→ インデックス(③)→ チェーン(④)→ 登録(⑤)→ デプロイ(⑥)→ 確認・監視(⑦⑧)という大きな流れを崩さないこと。特に「インデックスはチェーン構築の前」「登録はデプロイの前」の前後関係が問われます。
① Volumeに PDFを配置(2-2の復習)。ファイルはUCのVolumeに置くことで、ガバナンスの下で管理されます。
/Volumes/prod/rag/docs/ 配下にPDFをアップロード
② パース&チャンキングしてDeltaテーブルへ(2-2、2-3の復習)。PDFからテキストを抽出し、チャンクに分割して保存します。このときChange Data Feed(CDF)を必ず有効化します。後続のDelta Sync Indexが変更を追跡するために必要です。
CREATE TABLE prod.rag.chunks (
chunk_id STRING,
content STRING,
source STRING
) TBLPROPERTIES (delta.enableChangeDataFeed = true);
③ AI Searchエンドポイント+Delta Sync Indexの作成(3-3の復習)。埋め込みはマネージド埋め込み(例:databricks-gte-large-en)を指定すれば、チャンク追加時のベクトル化とインデックス同期が自動化されます。
from databricks.vector_search.client import VectorSearchClient
vsc = VectorSearchClient()
index = vsc.create_delta_sync_index(
endpoint_name="rag-vs-endpoint",
index_name="prod.rag.chunks_index",
source_table_name="prod.rag.chunks",
pipeline_type="TRIGGERED",
primary_key="chunk_id",
embedding_source_column="content",
embedding_model_endpoint_name="databricks-gte-large-en",
)
④ LangChainでRAGチェーンを構築(3-1、3-4の復習)。retriever(AI Search)→ prompt → ChatDatabricks(Servingエンドポイント上のLLM)をつなぎます。
from databricks_langchain import (
ChatDatabricks, DatabricksVectorSearch
)
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
retriever = DatabricksVectorSearch(
index_name="prod.rag.chunks_index",
columns=["content", "source"],
).as_retriever(search_kwargs={"k": 3})
prompt = ChatPromptTemplate.from_template(
"コンテキストのみに基づいて回答してください。\n"
"コンテキスト: {context}\n質問: {question}"
)
llm = ChatDatabricks(endpoint="databricks-llm-endpoint")
chain = (
{"context": retriever, "question": lambda x: x}
| prompt | llm | StrOutputParser()
)
⑤ MLflowでログし、UCへ登録(3-8、4-1の復習)。チェーンを1つのモデルとしてログし、3レベル名で登録します。
import mlflow
mlflow.set_registry_uri("databricks-uc")
with mlflow.start_run():
mlflow.langchain.log_model(
lc_model=chain,
artifact_path="chain",
registered_model_name="prod.rag.pdf_qa_bot",
)
⑥ エンドポイント化(4-2の復習)。エージェント/チェーンならagents.deploy()が近道です。Review Appと推論テーブルも自動で用意されます。
from databricks import agents
agents.deploy(model_name="prod.rag.pdf_qa_bot", model_version="1")
⑦ 動作確認。RESTまたはSQLのai_query()で応答を確認します。
SELECT ai_query(
"pdf-qa-bot-endpoint",
"経費精算の締め日はいつですか?"
) AS answer;
⑧ 監視(4-4の復習、第5章への接続)。推論テーブルに記録されたリクエスト/レスポンスを確認し、以降の品質評価・監視サイクルにつなげます。ここから先(評価指標、LLM-as-a-judge、継続監視)が第5章・第6章のテーマです。
💼 演習のチェックポイント
SHOW TBLPROPERTIESで確認)この演習で(そして試験のシナリオ問題で)特に多いつまずきを表にまとめます。
| 症状 | 原因 | 対処 |
|---|---|---|
| Delta Sync Indexが作成できない/同期されない | ソーステーブルのCDF(Change Data Feed)が未有効 | TBLPROPERTIES で delta.enableChangeDataFeed = true を設定する(②) |
| 検索結果の関連性が異常に低い | 埋め込みモデルの不一致(自己管理埋め込みで、インデックス作成時とクエリ時に別モデルを使用) | 両者で同じ埋め込みモデルに統一する。マネージド埋め込みなら不一致自体が起きない(③) |
| チェーンやエンドポイントからインデックス/モデルにアクセスできない | 権限不足(USE CATALOG / USE SCHEMA / SELECT / EXECUTEの欠落。実行主体がサービスプリンシパルである点の見落とし) | 実行主体を特定し、階層全体の権限を付与する(4-3) |
| 新しい文書を追加したのに回答に反映されない | インデックスの同期が未実行(TRIGGERED型は明示的な同期が必要) | インデックスの同期を実行する。常時反映が必要ならCONTINUOUS型を検討(③) |
| デプロイ後の初回リクエストだけ極端に遅い | scale-to-zeroからのコールドスタート | 要件次第でscale-to-zeroを無効化(トレードオフは4-7) |
📝 試験のポイント
「Delta Sync Indexが同期しない→CDF」「検索精度が突然崩壊→埋め込みモデル不一致」「アクセスエラー→UC権限」の3つは、原因と対処をセットで即答できるようにしておきましょう。いずれも本試験のトラブルシューティング問題の定番です。
✅ この節のまとめ
問1. 社内PDF文書に基づくRAGチャットボットを構築する。作業の順序として最も適切なものはどれか。
正解:B
データ準備 → インデックス → チェーン → 登録 → デプロイが正しい依存順序です。チェーンはretrieverとしてインデックスを参照するためインデックスが先に必要で(Aが誤り)、登録・デプロイはチェーンが完成してから(C・Dが誤り)です。
問2. チャンクを格納したDeltaテーブルからDelta Sync Indexを作成しようとしたが失敗する。最も可能性の高い原因はどれか。
正解:A
Delta Sync Indexはソーステーブルの変更を追跡して同期する仕組みのため、CDFの有効化が前提条件です。これが本節・本試験で特に問われやすいのつまずきです。Bはインデックス作成失敗の直接原因にならず、Cはむしろ正しい形式、Dはテーブル化済みであれば作成自体には影響しません。
問3. 自己管理埋め込み(自分で埋め込みを計算してテーブルに保存する方式)で構築したインデックスに対し、検索結果の関連性が著しく低い。原因として最も疑うべきものはどれか。
正解:B
異なる埋め込みモデルはベクトル空間が別物のため、類似度計算が意味をなさなくなり関連性が崩壊します。文書側とクエリ側で同一の埋め込みモデルを使うことが大前提です(マネージド埋め込みならこの不一致は構造的に起きません)。Aは付加情報の問題で関連性崩壊の主因ではなく、Cは生成段階、Dは検索品質の主因ではありません。
問4. agents.deploy()でデプロイしたRAGボットの本番の質問と回答を確認し、品質評価につなげたい。どこを見ればよいか。
正解:A
agents.deploy()は推論テーブルを自動セットアップし、エンドポイントを通る入出力をDeltaテーブルに記録します。これが本番品質の評価・監視(第5章・第6章)の元データです。Bは検索側の統計のみ、Cはテーブル操作の履歴、Dはインフラログであり、質問と回答の内容は含まれません。