第4章 アプリケーションの組み立てとデプロイ / 想定学習時間:30〜40分 / 最終確認:2026年8月

4-6. エンドツーエンドのRAGアプリケーションのデプロイ演習

🎯 この節の学習目標

1. 全体像:8ステップのパイプライン

この節は総合演習です。第2章(データ準備)、第3章(アプリ開発)、第4章(デプロイ)で学んだ部品を1本につなぎ、「社内PDFに答えるRAGボット」を作りきる流れを通しで確認します。まず全体像です。

Volume(PDF)① UCのVolumeに文書を配置
テキスト抽出・分割
パース/チャンキング② チャンクへ分割
保存
Deltaテーブル② CDF(Change Data Feed)有効
Delta Sync Indexで自動同期
AI Searchインデックス③ マネージド埋め込みでベクトル化
retrieverとして組み込み
RAGチェーン④ retriever+prompt+LLM
1つのモデルとしてログ
MLflowログ⑤ log_model
3レベル名で登録
UC登録⑤ Model Registry
⑥ デプロイ
Model Servingagents.deploy()/エンドポイント
Databricks Appsアプリとしてホスト(4-8)
⑦動作確認 ⑧ログ記録
推論テーブル/監視評価・監視へ(第5章・第6章)

図: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アプリ構築の手順を正しい順序に並べよ」という形式がよく問われます。データ準備(①②)→ インデックス(③)→ チェーン(④)→ 登録(⑤)→ デプロイ(⑥)→ 確認・監視(⑦⑧)という大きな流れを崩さないこと。特に「インデックスはチェーン構築の前」「登録はデプロイの前」の前後関係が問われます。

2. ステップ①〜③:データ準備とインデックス

① 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",
)

3. ステップ④〜⑤:チェーン構築とUC登録

④ 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. ステップ⑥〜⑧:デプロイ・確認・監視

⑥ エンドポイント化(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章のテーマです。

💼 演習のチェックポイント

5. つまずきやすいポイント:トラブルシューティング表

この演習で(そして試験のシナリオ問題で)特に多いつまずきを表にまとめます。

症状原因対処
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チャットボットを構築する。作業の順序として最も適切なものはどれか。

  1. チェーン構築 → インデックス作成 → チャンキング → デプロイ → UC登録
  2. チャンキングしてDeltaテーブル化 → AI Searchインデックス作成 → チェーン構築 → UC登録 → デプロイ
  3. UC登録 → デプロイ → チャンキング → インデックス作成 → チェーン構築
  4. デプロイ → 動作確認 → インデックス作成 → チェーン構築 → UC登録
解答と解説を見る

正解:B

データ準備 → インデックス → チェーン → 登録 → デプロイが正しい依存順序です。チェーンはretrieverとしてインデックスを参照するためインデックスが先に必要で(Aが誤り)、登録・デプロイはチェーンが完成してから(C・Dが誤り)です。

問2. チャンクを格納したDeltaテーブルからDelta Sync Indexを作成しようとしたが失敗する。最も可能性の高い原因はどれか。

  1. ソーステーブルでChange Data Feed(CDF)が有効化されていない
  2. チャンクの文字数が多すぎる
  3. テーブル名が3レベル名になっている
  4. PDFの元ファイルをVolumeから削除した
解答と解説を見る

正解:A

Delta Sync Indexはソーステーブルの変更を追跡して同期する仕組みのため、CDFの有効化が前提条件です。これが本節・本試験で特に問われやすいのつまずきです。Bはインデックス作成失敗の直接原因にならず、Cはむしろ正しい形式、Dはテーブル化済みであれば作成自体には影響しません。

問3. 自己管理埋め込み(自分で埋め込みを計算してテーブルに保存する方式)で構築したインデックスに対し、検索結果の関連性が著しく低い。原因として最も疑うべきものはどれか。

  1. チャンクのメタデータが不足している
  2. インデックス作成時とクエリ時で異なる埋め込みモデルを使っている
  3. LLMのtemperatureが高すぎる
  4. プロンプトテンプレートが日本語で書かれている
解答と解説を見る

正解:B

異なる埋め込みモデルはベクトル空間が別物のため、類似度計算が意味をなさなくなり関連性が崩壊します。文書側とクエリ側で同一の埋め込みモデルを使うことが大前提です(マネージド埋め込みならこの不一致は構造的に起きません)。Aは付加情報の問題で関連性崩壊の主因ではなく、Cは生成段階、Dは検索品質の主因ではありません。

問4. agents.deploy()でデプロイしたRAGボットの本番の質問と回答を確認し、品質評価につなげたい。どこを見ればよいか。

  1. 推論テーブル(inference table)に自動記録されたリクエスト/レスポンスのログ
  2. AI Searchインデックスの統計情報
  3. Deltaテーブルのテーブル履歴(DESCRIBE HISTORY)
  4. クラスタのドライバーログ
解答と解説を見る

正解:A

agents.deploy()は推論テーブルを自動セットアップし、エンドポイントを通る入出力をDeltaテーブルに記録します。これが本番品質の評価・監視(第5章・第6章)の元データです。Bは検索側の統計のみ、Cはテーブル操作の履歴、Dはインフラログであり、質問と回答の内容は含まれません。