Databricks Certified Generative AI Engineer Associate 教科書
第2章 データ準備(Data Preparation, 14%)
🎯 この節の学習目標
RAG(Retrieval-Augmented Generation)アプリケーションの品質は、LLMそのものよりも「どんなデータを、どんな状態で持っているか」に大きく左右されます。試験の第2セクション「Data Preparation」は、まさにこのデータ側の設計を問うセクションであり、その土台となるのがDatabricksの2つの中核技術です。
ソース文書からDatabricks AI Search(旧 Vector Search)インデックスに至るまで、RAGパイプラインが扱うすべてのデータをこの2つの上に置くのがDatabricksにおける定石です。まずそれぞれの基礎を押さえましょう。
Unity Catalogでは、あらゆる資産を catalog.schema.object という3レベルの名前空間で識別します。たとえば prod.rag_app.docs_chunks は「prodカタログ内のrag_appスキーマにあるdocs_chunksテーブル」を指します。
| レベル | 役割 | 例 |
|---|---|---|
| Catalog(カタログ) | 最上位の区分。環境(dev/prod)や事業部単位で分けることが多い | prod, dev |
| Schema(スキーマ) | カタログ内の論理グループ。プロジェクトやアプリ単位 | rag_app |
| Object(オブジェクト) | 実体。テーブル、ビュー、Volume、関数、モデルなど | docs_chunks |
3レベル目に置けるオブジェクトの種類が重要です。GenAIアプリでよく使うのは次の4つです。
/Volumes/catalog/schema/volume_name/... というパスでファイルにアクセスできます。💼 例:RAGプロジェクトの名前空間設計
社内規程QAボットを作る場合、次のように整理できます。
prod.hr_qa.raw_docs(Volume)— 規程PDFの原本を格納prod.hr_qa.docs_parsed(テーブル)— パース済みテキストprod.hr_qa.docs_chunks(テーブル)— チャンク化済みテキスト+メタデータprod.hr_qa.docs_index — AI Searchインデックスprod.hr_qa.qa_chain(モデル)— デプロイするRAGチェーン原本からモデルまでを同じスキーマ配下に置くことで、権限・リネージ・監査を一元管理できます。
📝 試験のポイント
「PDFなどの非構造化ソース文書はどこに置くべきか?」と問われたら、答えはUnity CatalogのVolumeです。DBFSのルートやローカルパスを選ばせる誤答選択肢が出ます。ガバナンス(権限・監査)の対象にできるのはUC管理下のVolumeである、という点が判断基準です。
Delta Lakeは、Parquetファイルにトランザクションログを組み合わせたオープンなストレージ形式で、Databricksのテーブルのデフォルトです。GenAIエンジニアとして押さえるべき機能は次のとおりです。
| 機能 | 内容 | RAGでの意味 |
|---|---|---|
| ACIDトランザクション | 書き込みの原子性・一貫性を保証 | パイプラインが途中で失敗しても中途半端なデータが残らない |
| タイムトラベル | 過去バージョンのテーブルを参照・復元できる | 「先週のインデックスの元データ」を再現でき、品質劣化の原因調査に有効 |
| スキーマ強制 / 進化 | 定義と異なるスキーマの書き込みを拒否(または明示的に進化) | チャンクテーブルの列構成が勝手に壊れるのを防ぐ |
| Change Data Feed(CDF) | 行レベルの変更(挿入・更新・削除)を差分として読み出せる | AI SearchのDelta Sync Indexが差分同期に利用する。有効化が前提条件 |
特にChange Data Feedは試験よく問われます。AI SearchのDelta Sync Index(4章で詳述)は、ソースのDeltaテーブルの変更を自動でインデックスに反映しますが、その仕組みはCDFに依存しています。ソーステーブルには次のように設定します。
# チャンクテーブル作成時にCDFを有効化
spark.sql("""
CREATE TABLE prod.hr_qa.docs_chunks (
chunk_id BIGINT,
text STRING,
source_path STRING
) TBLPROPERTIES (delta.enableChangeDataFeed = true)
""")📝 試験のポイント
「Delta Sync Indexを作ろうとしたら失敗した/更新が反映されない。原因は?」という問いに対し、「ソーステーブルで Change Data Feedが有効になっていない」が正解になるパターンがあります。delta.enableChangeDataFeed = true というプロパティ名まで覚えておきましょう。
RAGのデータ準備は「生文書 → パース済みテキスト → チャンク → インデックス」という段階を踏みます。各段階の成果物をUC管理下のDeltaテーブル(またはVolume)として明示的に保存するのが定石です。
中間成果物をテーブルとして残す理由は3つあります。①失敗時に途中から再実行できる、②各段階の品質を検査・デバッグできる、③リネージにより「この回答の根拠はどの原本か」を追跡できる。アドホックにメモリ上で処理して直接インデックス化する構成は、小規模な実験を除き避けるべきです。
Unity Catalogの価値はガバナンスにあります。詳細は第6章で扱いますが、データ準備の段階で知っておくべき基礎は次の3点です。
GRANT 文で、カタログ/スキーマ/オブジェクト単位にアクセス権を付与します。例:GRANT SELECT ON TABLE prod.hr_qa.docs_chunks TO `data-scientists`; 上位(スキーマ)への付与は配下オブジェクトに継承されます。💼 例:機密文書を含むRAGでの権限設計
人事規程には全社員が読める文書と人事部限定の文書が混在するとします。この場合、スキーマやテーブルを権限境界で分け(例:hr_qa.docs_chunks_public と hr_qa.docs_chunks_hr_only)、GRANTでアクセス可能なグループを制御します。インデックス化の前段階、つまりデータ準備の時点で権限境界を設計しておくことが、後からの手戻りを防ぎます。
✅ この節のまとめ
問1. RAGアプリケーションのソースとなる大量のPDFファイルをDatabricks上で管理したい。ガバナンス(権限管理・監査)の対象にできる格納先として最も適切なのはどれか。
正解:C
非構造化ファイルをUnity Catalogの権限体系・監査の下で管理できるのはVolumeです。Aのローカルファイルシステムはクラスタ終了で消え、共有もできません。BのDBFSルートはUCのガバナンス対象外で、本番データの置き場として推奨されません。Dはそもそもファイル管理の手法ではありません。
問2. チャンク化したテキストを格納するDeltaテーブルをソースとして、AI SearchのDelta Sync Index(自動同期型インデックス)を作成したい。ソーステーブルに必要な設定はどれか。
正解:B
Delta Sync Indexはソーステーブルの変更差分をChange Data Feed(CDF)経由で取得して同期します。したがって delta.enableChangeDataFeed = true が必要です。Aのexternal tableは要件と無関係、CのZ-ORDERはクエリ性能最適化であり同期の前提条件ではありません。Dの主キー列はインデックス作成時に指定が必要ですが、それだけではCDFの代わりになりません。
問3. Unity Catalogにおける「prod.support_bot.faq_chunks」という識別子の説明として正しいものはどれか。
正解:B
UCの名前空間は上位からcatalog.schema.objectの順です。Aのワークスペースやクラスタは名前空間の構成要素ではありません。Cは順序が逆です。Dは誤りで、テーブルだけでなくビュー・Volume・関数・登録モデルも同じ3レベル名前空間で管理されます。
問4. RAGパイプラインで「生文書のパース → チャンク化 → インデックス化」を毎晩実行している。あるとき回答品質が急に低下し、原因調査のため「先週時点のチャンクデータ」を確認したい。最も直接的に役立つDelta Lakeの機能はどれか。
正解:B
タイムトラベルは VERSION AS OF / TIMESTAMP AS OF により過去バージョンのテーブルを参照できる機能で、「先週時点のデータ」の確認に直接使えます。Aはスキーマ不整合の書き込み防止、Cは書き込みの整合性保証、Dはクエリ高速化の仕組みであり、過去データの参照はできません。