Databricks Certified Generative AI Engineer Associate 教科書
第2章 データ準備(Data Preparation, 14%)
🎯 この節の学習目標
前節で「どこで切るか(戦略)」を学びました。本節は「どれくらいの大きさにするか(サイズ)」です。チャンクサイズに万能な正解値はなく、検索精度・回答の文脈量・コストの3者のトレードオフとして決めます。試験では、このトレードオフの理解が「症状→調整方向」の形式で問われます。
両極端の性質を対比して押さえるのが理解の近道です。
| 観点 | 小さいチャンク(例:数百トークン以下) | 大きいチャンク(例:数千トークン) |
|---|---|---|
| 埋め込みの性質 | 1つの話題に焦点化されたベクトルになる | 複数の話題が混ざり、ベクトルが平均化される |
| 検索精度 | 質問と強く一致しやすく精密。取得結果に無関係な文が少ない(ノイズ少) | 質問との一致が「薄まり」、関連チャンクを取り逃しやすい。ヒットしても大部分が無関係な文になりうる |
| 回答生成への影響 | 文脈不足になりがち。断片だけでは背景・前提が欠け、浅い回答や誤解につながる | 文脈豊富。背景を含めた深い回答を生成しやすい |
| コスト・レイテンシ | プロンプトに入れてもトークン消費が小さい | プロンプトのトークン消費増=コスト増・レイテンシ増。無関係な文がノイズとして生成品質を下げることも |
まとめると、小さくすると「見つけやすいが、答えるための材料が足りない」、大きくすると「材料は豊富だが、見つけにくく、高くつく」という関係です。
📝 試験のポイント
症状と調整方向の対応を即答できるようにしましょう。「検索は当たっているのに回答が浅い・文脈が足りない」→チャンクを大きくする(または後述のparent-child)。「検索結果に無関係な内容が多い・関連箇所を取り逃す」→チャンクを小さくする。逆方向を選ばせる誤答が必ず並びます。
チャンクサイズは単体では決められません。検索で取得するチャンク数 top-k との積が、プロンプトに投入されるトークン量を決めるからです。
プロンプト全体 ≒ システムプロンプト + 質問 + (top-k × チャンクサイズ) + 出力用の余裕
この合計がLLMのコンテキストウィンドウに収まらなければなりません。
たとえばコンテキストウィンドウが8,000トークンのモデルで、チャンクサイズ2,000トークン・top-k=5とすると、検索結果だけで10,000トークンとなり収まりません。チャンクを小さくするか、top-kを減らすか、より大きなコンテキストウィンドウのモデルを使うかの調整が必要です。
また「コンテキストウィンドウが大きいモデルなら全部詰め込めばよい」とも言えません。投入トークンに比例してコストとレイテンシは増えますし、無関係なテキストの混入は生成品質を下げる要因になります。必要十分な情報を最小のトークンで渡すのが理想であり、だからこそチャンクサイズとtop-kの設計が重要になります。
では実際にどう決めるか。出発点となる考え方は次の基準です。
「想定される質問に回答するために必要な情報が、1チャンクに収まるか」
FAQのように1問1答が短く完結するコーパスなら小さめ、背景説明を含めて読まないと答えられない技術文書なら大きめ、というように、コーパスと質問の性質からあたりを付けます。そのうえで重要なのは、最終的には評価(第5章)で実測して決めることです。チャンクサイズやtop-kを変えた複数の設定で、検索指標(関連チャンクを取得できたか)と回答品質を測定・比較し、データに基づいて選びます。感覚で「512が良いらしい」と固定するのではなく、評価パイプラインを持って調整可能にしておくことが、試験でも実務でも正しい姿勢とされます。
💼 例:症状からの診断
ケースA:技術サポートRAGで、検索されたチャンクは質問に関連しているのに、回答が「手順の断片」しか述べず不完全。→ チャンクが小さすぎて手順全体が入っていない。チャンクサイズを大きくする(またはセクション単位の分割に変更する)。
ケースB:同じRAGで、検索結果の大半が質問と無関係な章の内容で、正しい箇所がtop-kに入ってこない。→ チャンクが大きすぎて埋め込みが平均化され、類似度の判別力が落ちている。チャンクサイズを小さくする。
症状の起きている場所(検索段階か、生成段階か)を切り分けてから調整方向を決めるのがポイントです。
「小さいチャンクの検索精度」と「大きいチャンクの文脈量」を両立させる発展的な手法として、parent-child(親子)チャンク戦略があります(small-to-big retrievalとも呼ばれます)。
インデックスと親子対応の管理が増える分、パイプラインは複雑になります。試験対策としては「小さく検索して、大きく渡す」ことで検索精度と文脈量のトレードオフを緩和する手法、と理解しておけば十分です。
✅ この節のまとめ
問1. 社内手順書のRAGボットで、検索されるチャンクは質問と関連しているものの、生成される回答が断片的で手順の全体像を含まず「浅い」というフィードバックが多い。最も適切な調整はどれか。
正解:B
検索は当たっているのに回答の文脈が不足している症状は、チャンクが小さすぎて回答に必要な情報のまとまりが1チャンクに収まっていないことを示します。チャンクを大きくする(またはparent-childで親を渡す)のが正しい方向です。Aは症状を悪化させます。Cの次元数は文脈量とは無関係です。Dは事実に基づく回答の不足を解決せず、むしろ捏造リスクを高めます。
問2. チャンクを4,000トークンと大きめに設定したRAGで、質問に関連する文書がtop-kの検索結果に入ってこないことが増えた。原因の説明として最も適切なのはどれか。
正解:A
大きなチャンクは多様な内容を1本のベクトルで代表するため、埋め込みが「平均化」され、個別の質問との類似度の判別力が落ちます。これが大チャンクの検索精度低下の主因です。Bはインデックス構築可否の問題ではありません(埋め込みモデルの入力上限による切り捨ては別の問題として注意)。Cのtemperatureは生成側のパラメータで無関係です。Dは大チャンクの性質の説明として逆です。
問3. コンテキストウィンドウが8,000トークンのLLMを使うRAGで、チャンクサイズ1,500トークン・top-k=6に設定したところ、プロンプト構築時にコンテキスト長超過のエラーが発生した。適切な対処の組み合わせとして最も妥当なのはどれか。
正解:A
検索結果だけで1,500×6=9,000トークンとなり、質問やシステムプロンプトを足す前からウィンドウ(8,000)を超えています。プロンプトに入る量はtop-k×チャンクサイズで決まるため、どちらか(または両方)を減らすのが直接の対処です(より大きなウィンドウのモデルへの変更も選択肢)。Bは問題を放置し、Cはむしろ重複分のトークンを増やします。Dの埋め込みモデルは検索側の部品で、プロンプト長には影響しません。
問4. 「小さいチャンクによる精密な検索」と「大きな文脈をLLMに渡すこと」を両立させたい。この目的に合致する手法はどれか。
正解:B
parent-child(small-to-big)戦略は、検索は焦点化された子チャンクで精密に行い、生成には文脈豊富な親チャンクを渡すことで、チャンクサイズのトレードオフを緩和します。Aは検索は精密でも渡す文脈が最小になり目的の半分しか満たしません。Cは検索精度と埋め込み上限の両面で不適切です。Dは社内文書に基づく回答というRAGの前提を放棄しています。