Azure認定資格 WEB問題集＆徹底解説

会員登録/ログイン

A. ファインチューニング

ファインチューニングは、事前学習済みのモデルを自社データで追加学習させ、モデルの重み（振る舞い）を調整する工程です。
リクエストのたびに入力文へ施す前処理ではなく、文章を区切って数値 ID に置き換える処理でもありません。

「ユーザーが入力した文章をモデルへ渡す前に行う」という問題文の条件と合わないため不適切です。

B. エンベディング

エンベディング（埋め込み）は、テキストなどを意味を表す数値ベクトルに変換する処理です。
「数値に置き換える」という点で紛らわしいですが、本問の処理が作るのは単位ごとの数値 ID（語彙表の通し番号）であり、意味の近さを表すベクトルではありません。

モデルの内部では、トークン化で得た ID を埋め込みベクトルに変換して計算に使うため、順序はトークン化が先、埋め込みが後です。料金やコンテキスト長を数える単位もベクトルではなくトークンです。

正解

C. トークン化

トークン化（tokenization）は、入力文をトークンと呼ばれる単位（単語、単語の一部、文字、記号など）に区切り、それぞれを語彙表の数値 IDに置き換える前処理です。
生成 AI では、利用料金は入力と出力のトークン数で計算され、モデルが 1 回のリクエストで扱える長さ（コンテキスト長）の上限もトークン数で決まります。問題文の条件をすべて満たします。

トークンへの区切り方はモデル（トークナイザー）ごとに異なり、同じ内容でも日本語は英語よりトークン数が多くなりやすい点も押さえておきましょう。

D. チャンク化

チャンク化は、RAG などで長い文書を検索しやすい大きさ（段落や一定の長さ）のまとまりに分割する処理です。
「区切る」という動作は似ていますが、分割結果は人が読める文章のかたまりのままで、数値 ID に置き換えることはしません。

また、チャンクの数は利用料金やコンテキスト長の上限を数える単位ではありません（チャンクの大きさをトークン数で決めることはあります）。単位の粒度も目的もトークン化とは別物です。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
ユーザーの入力文に対し、モデルへ渡す前に毎回行う前処理	追加学習でモデル自体を調整する工程は入力の前処理ではない →選択肢（A）を消す
文章を細かい単位に区切り、それぞれを数値 ID に置き換える	区切った結果が文章のかたまりのままの処理（検索用の分割）は該当しない →選択肢（D）を消す
置き換え先は「単位ごとの数値 ID」	意味を表すベクトルに変換するのは埋め込み。ID への置き換えはその前段 →選択肢（B）を消す
区切った単位の数が利用料金とコンテキスト長の上限に使われる	生成 AI の課金とコンテキスト長はトークン数で数える →選択肢（C）が正解

ひっかけポイント

• 選択肢 D のチャンク化も「区切る」処理なので紛らわしい。見分ける鍵は数値 ID に置き換えるかと課金・コンテキスト長の単位か。チャンクは検索用の文章のかたまりで、どちらにも当たらない
• 選択肢 B のエンベディングも「数値にする」処理。だが出力は意味を表すベクトルで、トークン化で得た ID をもとに作られる後段の処理
• トークンは単語と 1 対 1 ではない。1 つの単語が複数のトークンになることも、記号が 1 トークンになることもある。「文字数」や「単語数」で料金を見積もると外れる
• コンテキスト長は入力と出力の合計に掛かる上限。長いプロンプトや会話履歴を送ると、その分だけ生成できる応答の長さも減る

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「文書を意味の近さで検索できるように数値化したい」	エンベディング（埋め込み）が正解に。
「RAG 用に長いマニュアルを検索しやすい単位に分けたい」	チャンク化が正解に。
「自社の文体や専門用語に合わせてモデルの振る舞いを調整したい」	ファインチューニングが正解軸に。
「長い会話履歴を送るとエラーになる／料金が高くなる原因は何か」	入力のトークン数がコンテキスト長の上限と課金に効いている、が答えに。
「応答の長さを制限して料金を抑えたい」	最大出力トークン数の設定が正解に。