Databricks Certified Generative AI Engineer Associate 教科書
第2章 データ準備(Data Preparation, 14%)
🎯 この節の学習目標
チャンキング(2-3、2-4)と前処理(2-5)を経たテキストは、そのまま埋め込みモデルに渡すこともできます。しかし品質の高いRAGでは、その手前でもう2つの設計を行います。①埋め込み対象テキストの整形と②メタデータの設計です。本節は第2章の締めくくりとして、チャンクを「検索可能な資産」に仕上げるこの2つを扱います。
チャンクは文書から切り出された断片なので、単体で読むと「これが何の話か」がわからないことがあります。たとえば「上限は片道あたり3,000円とする。」というチャンクは、それがどの規程の何の上限かという情報を失っています。埋め込みはチャンク内のテキストだけから計算されるため、この文脈欠落は検索精度を直接下げます。
定番の対策がコンテキスト付加です。文書タイトルやセクション見出しを、チャンク本文の先頭に付与してから埋め込みます。
# チャンクにタイトル・見出しのコンテキストを付加する
def format_for_embedding(doc_title, section, chunk_text):
return f"文書: {doc_title}\nセクション: {section}\n\n{chunk_text}"
text = format_for_embedding(
"国内出張旅費規程", "第4条 交通費",
"上限は片道あたり3,000円とする。")こうすると「出張のタクシー代の上限は?」という質問と、チャンクの埋め込みが強く一致するようになります。2-2で「見出し構造を捨てずに抽出する」ことを強調したのは、この整形の材料にするためでもあります。あわせて、整形後のテキストが埋め込みモデルの入力上限(トークン数)を超えていないかを必ず確認します。上限超過分は黙って切り捨てられ、その部分は検索不能になるためです。
チャンクテーブルには、テキスト以外にメタデータ列を持たせます。何を持つべきかは「後で何に使うか」から逆算します。用途は大きく3つです。
| 用途 | 内容 | 必要になるメタデータの例 |
|---|---|---|
| ① 出典表示(引用) | 回答に「根拠:〇〇規程 第4条」のような引用を付ける。ユーザーの検証可能性と信頼性の要 | 文書タイトル、ソースURL/ファイルパス、セクション名、ページ番号 |
| ② 検索時のフィルタ | Databricks AI Search(旧 Vector Search)のメタデータフィルタでベクトル検索対象を絞り込む(例:製品=Xの文書だけ) | 製品名、部署、文書カテゴリ、言語 |
| ③ 鮮度・権限管理 | 古い文書の除外・降格(2-5)、ユーザーの所属に応じたアクセス制御 | 更新日時、版番号、有効期限、機密区分、アクセス可能グループ |
これを踏まえた標準的なチャンクテーブルのスキーマは次のようになります。
CREATE TABLE prod.support.docs_chunks (
chunk_id BIGINT, -- 主キー(インデックスの必須要件)
text STRING, -- 整形済みの埋め込み対象テキスト
doc_title STRING, -- 出典表示用
source_path STRING, -- 出典表示用(Volume上のパスやURL)
section STRING, -- 出典表示・コンテキスト付加用
product STRING, -- メタデータフィルタ用
department STRING, -- フィルタ・権限管理用
updated_at TIMESTAMP -- 鮮度管理用
) TBLPROPERTIES (delta.enableChangeDataFeed = true)💼 例:メタデータフィルタで誤ヒットを防ぐ
複数製品のマニュアルを1つのインデックスに入れたサポートボットで、「製品Aのエラー E-102 の対処は?」という質問に対し、類似度だけで検索すると製品Bの似たエラーの記述が上位に混ざり、誤案内が発生しました。チャンクに product メタデータを持たせ、検索時に「product = 'A'」のメタデータフィルタを適用することで、ベクトル検索の対象自体を製品Aの文書に限定でき、誤ヒットが解消しました。類似度は「意味の近さ」しか見ないため、属性による絞り込みはメタデータの仕事です。
📝 試験のポイント
「回答に出典(ソース文書へのリンク)を表示したい→ソースURL/ファイルパス・文書タイトルをメタデータとして保持」「特定部署・特定製品の文書だけを検索対象にしたい→その属性をメタデータ列に持たせ、検索時にフィルタする」という形式で問われます。「LLMに推測させる」「別インデックスを都度作る」といった選択肢より、メタデータ設計で解くのが正解の型です。
整形とメタデータ設計の着地点は、AI SearchのDelta Sync Index(4章で詳述)のソースとなるDeltaテーブルです。要件を整理します。
chunk_id)。インデックス作成時にprimary keyとして指定します。delta.enableChangeDataFeed = true が差分同期の前提です。つまり第2章で行ってきた作業の成果は、最終的に「主キー+整形済みテキスト+メタデータを持ち、CDFが有効なDeltaテーブル」という1つの形に集約されます。これが次章以降(検索・チェーン構築)の入力になります。
章全体の流れをチェックリストとしてまとめます。試験前の総復習にも使ってください。
✅ この節のまとめ
問1. RAGチャットボットの回答に、根拠となったソース文書へのリンクとタイトルを表示する要件がある。データ準備段階で行うべきこととして最も適切なのはどれか。
正解:B
出典表示は、チャンクにソースパス・タイトルのメタデータを持たせ、検索結果から取り出して表示するのが定石です。AはLLMが出典を捏造するリスクが高く、検証可能性の要件を満たしません。Cは毎回の全文走査で非効率かつ不確実です。Dはコンテキスト長・コストの面で非現実的で、リンク情報の解決にもなりません。
問2. 全部署の文書を1つのAI Searchインデックスで運用しつつ、「経理部の文書だけを検索対象にしたい」というリクエストに応えたい。最も適切な設計はどれか。
正解:A
属性による絞り込みはメタデータフィルタの典型用途で、ベクトル検索の対象自体を確実に限定できます。Bの類似度検索は「意味の近さ」しか見ないため、他部署の類似文書が混入します。Cは運用コストが過大で鮮度管理も破綻します。Dは無関係なチャンクがプロンプトに入った後の後処理であり、確実性もトークン効率も劣ります。
問3. 「上限は3,000円とする。」のような短いチャンクが、関連する質問と類似度が上がらず検索にヒットしない。埋め込みの観点から最も適切な改善はどれか。
正解:A
埋め込みはチャンク内のテキストだけから計算されるため、文脈を失った断片は質問と一致しにくくなります。タイトル・見出しのコンテキスト付加で自己完結性を高めるのが定石です。Bは生成側のパラメータで検索とは無関係です。Cは意味情報が増えないため効果がありません。Dは文脈欠落をさらに悪化させます。
問4. チャンクテーブルをソースにDelta Sync Indexを構築し、継続的に自動同期させたい。ソースのDeltaテーブルが満たすべき条件の組み合わせとして最も適切なのはどれか。
正解:B
Delta Sync Indexのソースには、主キー(インデックス作成時に指定)、埋め込み対象のテキスト列、フィルタ・出典表示に使うメタデータ列を持たせ、差分同期のためにCDFを有効化します。Aは主キーとCDFの要件が抜けています。CはDeltaテーブルからの同期という仕組みに反します。Dのような型制約はなく、更新日時などはTIMESTAMP型で持つのが自然です。