Databricks 認定 Generative AI Engineer Associate 試験サンプル問題（日本語訳＋AI解説）

Databricks 認定試験「Generative AI Engineer Associate」のサンプル問題を日本語訳し、
あわせて AI による解説をまとめました。

本記事の解説部分は AIが生成した内容 です。
そのため、誤りやより良い表現などがありましたら、ぜひコメントでご指摘いただけると嬉しいです 🙏

参考資料（公式PDF）：

問1

目的：
与えられたドキュメント構造とモデルの制約に基づいて、チャンク化（分割）戦略を適用すること。
状況：
ある生成AIエンジニアが、ベクターデータベースに 1億5,000万件の埋め込み（embedding）をロードしようとしています。
しかし、そのデータベースの上限は 1億件です。
質問：
レコード数を減らすために、エンジニアが取れる2つの対応策は何でしょうか？

A. ドキュメントのチャンクサイズを増やす
B. チャンク間の重複を減らす
C. ドキュメントのチャンクサイズを減らす
D. チャンク間の重複を増やす
E. より小さな埋め込みモデルを使用する

答え＆解説

正答：A、B

✅ 解説

埋め込み（embedding）の数は、文書をどのように分割（chunking）するかによって決まります。
チャンクが多いほど、生成される埋め込みの数も増えます。

A. Increase the document chunk size（チャンクサイズを大きくする） ✅
チャンク1つあたりのテキスト量を増やすことで、
文書全体を分ける回数が減り、生成される埋め込み数も減ります。

例：
10,000トークンの文書
chunk_size = 1000 → 10個
chunk_size = 2000 → 5個
→ 埋め込み数が半分に！

B. Decrease the overlap between chunks（オーバーラップを減らす） ✅
隣り合うチャンク間の重なりを減らすことで、
重複部分が少なくなり、チャンク数（埋め込み数）も減ります。

❌ 間違いやすい選択肢

選択肢	理由
C. チャンクサイズを小さくする	チャンク数が増えてしまう
D. オーバーラップを増やす	重複部分が増えてチャンク数も増える
E. 小さいモデルを使う	ベクトルの次元は減るが、件数は変わらない

問2

目標: 特定のRAGアプリケーションに必要な知識と品質を提供する、必要なソースドキュメントを特定する。
Generate AIエンジニアは、自動車部品の販売を支援するために開発中の顧客向けGenAIアプリケーションからの応答を評価しています。
このアプリケーションでは、顧客が質問に答えるために、アカウントIDとトランザクションIDを明示的に入力する必要があります。
最初のリリース後、顧客からのフィードバックでは、アプリケーションは注文と請求の詳細には適切に回答しているものの、配送と到着予定日に関する質問には正確に回答していないというものでした。
次のどのレシーバーが、これらの質問への回答能力を向上させるでしょうか？

A. すべての自動車部品に関する会社の配送ポリシーと支払い条件を含むベクターストアを作成する。

B. transaction_id を主キーとし、請求書データと予定配達日が格納されたフィーチャーストアテーブルを作成する。

C. 到着予定日に関するサンプルデータをチューニング用データセットとして提供し、モデルを定期的にファインチューニングして配送情報を最新化する。

D. チャットプロンプトを修正し、注文日を入力するようにし、すべての配送方法は14日以内に到着するとして「注文日＋14日」を計算するようモデルに指示する。

答え＆解説

正答：B

✅ 解説

アプリは「注文」や「請求」には正確に答えられている一方、
「配送」や「到着予定日」には正確に答えられていません。

つまり、配送関連データがRAGの知識に含まれていない のが原因です。
この問題を解決するには、注文ごとに正確な配送情報を結びつける必要があります。

✅ B.トランザクションIDをキーに、請求情報と配達予定日を格納したフィーチャーストアを作成する

transaction_id をキーにして「請求書データ」や「予定配達日」を構造化データとして管理することで、
ユーザーが入力したIDに基づき、RAGアプリが正確な配送情報を取得できるようになります。
これが、「動的な出荷情報」を扱う唯一の現実的な方法 です。

❌ 間違いやすい選択肢

選択肢	理由
A. 配送ポリシーや支払い条件のベクターストア	一般的なルールであり、個々の注文の到着日とは関係がない。
C. 到着予定日データでモデルをファインチューニング	モデルの知識を更新する方法であり、最新の動的データ反映には不向き。
D. 注文日＋14日を計算するようプロンプトを変更	一律14日では配送方法・地域差を反映できず不正確。

💡補足：フィーチャーストアとは？
AIモデルが使う「特徴量（feature）」を一元管理する仕組みで、
再利用性・一貫性・正確性を保ちながらデータを管理できる。
RAGにおいては「構造化データの知識ベース」として機能します。

問3

目的：与えられたソースデータとその形式から、文書の内容を抽出するために適切なPythonパッケージを選択する。
ある生成AIエンジニアが、RAGアプリケーションを構築しています。
このアプリは、スキャンされた文書（.jpeg や .png などの画像ファイル形式）から取得したコンテキスト情報に基づいて動作します。
このエンジニアは、できるだけ少ないコード行数でテキストを抽出できるソリューションを開発したいと考えています。
次のうち、ソース文書からテキストを抽出するために使用すべきPythonパッケージはどれですか？

A. beautifulsoup

B. scrapy

C. pytesseract

D. pyquery

答え＆解説

正答：C. pytesseract

✅ 解説

ソースデータは スキャンされた画像ファイル（.jpeg / .png） であるため、
必要なのは「画像内の文字を読み取る（OCR：Optical Character Recognition）」処理です。

pytesseract は、Googleの Tesseract OCRエンジン をPythonから簡単に利用できるライブラリで、
わずか数行のコードで画像からテキストを抽出できます。
「最小限のコード行数で開発したい」という条件にも最も適しています。

🧩 サンプルコード

import pytesseract
from PIL import Image

text = pytesseract.image_to_string(Image.open("invoice.png"))
print(text)

❌ 他の選択肢との比較

選択肢	用途	不正解の理由
A. beautifulsoup	HTML/XMLの構文解析	画像から文字を読む機能はない
B. scrapy	Webスクレイピング（Webページのデータ収集）	OCR機能はない
D. pyquery	jQueryライクなHTML解析ツール	画像解析には対応していない

問4

目的：ソースドキュメント、想定されるクエリ、そして最適化戦略に基づいて、適切な埋め込みモデルのコンテキスト長（context length）を選択する。
ある生成AIエンジニアが、大規模言語モデル（LLM）を利用したアプリケーションを開発しています。
このアプリのリトリーバー（Retriever）用ドキュメントは、最大512トークンに分割（チャンク化）されています。
このエンジニアは、
「品質よりもコストと応答速度（レイテンシ）を優先する」ことが重要だと理解しています。
現在、いくつかの異なるコンテキスト長（入力長）の埋め込みモデルを選択できる状況です。
このとき、どのモデル設定を選ぶべきか？

A. コンテキスト長 512：最小モデルのサイズは 0.13GB、埋め込み次元（embedding dimension）は 384。

B. コンテキスト長 514：最小モデルのサイズは 0.44GB、埋め込み次元は 768。

C. コンテキスト長 2048：最小モデルのサイズは 11GB、埋め込み次元は 2560。

D. コンテキスト長 32768：最小モデルのサイズは 14GB、埋め込み次元は 4096。

答え＆解説

正答：A

✅ 解説

アプリでは、すでに ドキュメントが最大512トークンでチャンク化 されています。
さらに、エンジニアは 品質よりもコストと速度（レイテンシ）を優先 すると明言しています。

このため、「最小サイズのモデル（軽量・高速・安価）」が最も適しています。

A. context length 512: model size 0.13GB, embedding dimension 384 ✅

チャンクサイズ512とモデルのコンテキスト長512が完全に一致しており、
モデルの入力枠を無駄なく使える。
モデルサイズが最小（0.13GB）で、埋め込み生成が高速・低コスト・低メモリ消費。
品質よりも処理効率を重視する今回の要件に最も合致する。

**❌ 他の選択肢が不適切な理由
**

選択肢	問題点
B. context length 514 (0.44GB)	512とほぼ同じ長さだが、モデルサイズが3倍以上。非効率。
C. context length 2048 (11GB)	ドキュメントは512トークンしかないのに、4倍以上の枠を持つのは無駄。
D. context length 32768 (14GB)	超大規模モデルでメモリ・コストが膨大。用途に対して完全にオーバースペック。

💡 なぜ「チャンクサイズ」と「コンテキスト長」が一致すると無駄がないのか？

コンテキスト長：モデルが一度に処理できる最大トークン数。
チャンクサイズ：1つの文書ブロックの長さ（＝RAGで埋め込みに使う単位）。

モデルのコンテキスト長がチャンクサイズより大きい場合、
使われないトークン枠（入力容量）が発生してしまう。

モデルのコンテキスト長	チャンクサイズ	効率
512	512	✅ 最大限活用（効率的）
2048	512	❌ 75％の入力枠が無駄
32768	512	❌ ほとんどが空き枠。非効率の極み。

例えるなら：

4人しか乗らないのに大型バスを借りるようなもの🚌

⚙️ なぜ小さいモデルは速くて軽いのか？

小さいモデルは、

パラメータ数（重み） が少なく、
行列計算の規模 が小さいため、
→ 計算が軽く、メモリ使用量も少ない。

💡そもそも「埋め込み次元」とは？

埋め込み次元（embedding dimension）とは、
テキストをベクトル化したときの「ベクトルの次元数」のことです。

つまり、1つの文章やチャンクを「数値の並び（ベクトル）」で表現したときの
“数の個数” を意味します。

埋め込みベクトルは、テキスト間の**意味的な距離（類似度）**を計算するために使われます。
次元数が多いほど、

より細かい意味の違いを表現できる（高精度）
しかし、計算コストとストレージ消費が増える（高コスト）

今回の問題文では「品質よりコストと速度重視」と明記されていたので、
埋め込み次元が小さいモデル（A: 384次元）が自動的に最適となります。

問5

目的：開発するアプリケーションの特性に基づいて、最適なLLM（大規模言語モデル）を選択する。
ある生成AIエンジニアが、次のようなアプリケーションを作ろうとしています：

「メモ欄」に書かれた 1段落程度の文章を、
その内容の意図（要点）だけを1文にまとめた短い要約に変換し、
アプリケーションのフロントエンド上に表示できるようにしたい。
このとき、どの自然言語処理（NLP）タスクカテゴリに属するLLMを評価すべきでしょうか？

A. text2text Generation（テキストからテキストを生成）
B. Sentencizer（文分割）
C. Text Classification（テキスト分類）
D. Summarization（要約）

答え＆解説

正答：D

✅ 解説

このアプリの目的は、1段落のメモを1文にまとめて「要点だけを表示」すること。
つまり、文の一部を抽出したり、短く言い換えたりして「本質的な内容を要約」するタスクです。

これはまさに Summarization（要約）タスクに該当します。

❌ 他の選択肢が不適切な理由

選択肢	内容	不適切な理由
A. text2text Generation	入力テキストから新しいテキストを生成する幅広いカテゴリ	要約もこの一種ではあるが、目的が「要約」で明確なのでSummarizationがより正確。
B. Sentencizer	テキストを文ごとに分割する処理	文を短くするのではなく、分割するだけ。意図を抽出しない。
C. Text Classification	テキストをカテゴリに分類（例：ポジティブ／ネガティブ）	意図を要約するわけではなく、「分類」するタスク。

Youtubeもやってます！

FabricやDatabricksについて学べる勉強会を毎月開催！

次回イベント欄から直近のMicrosoft Data Analytics Day(Online) 勉強会ページ移動後、申し込み可能です！