ゆめさくエンジニア研究所女性向けエンジニアスクール女性向けエンジニアスクール
ログイン
AI と LLM

LLM の出力の品質を、どう評価し試しますか

想定の質問と期待する答えの組 (評価データ) を作って変更のたびに回し、ルールと別の LLM による自動の採点に人の確かめを組み合わせ、本番のログで評価データを育てる、と答える問い。

答えてみる

面接官に「LLM の出力の品質を、どう評価し試しますか」と聞かれたつもりで、答えを見る前に自分の言葉で答えます。

声に出して答えた人は「書かずに答えを見る」で開けます。

解説を読む

聞かれ方から関連するコースまで、この問いの解説を全部ここに置いています。

こう聞かれます

  • 「LLM の出力の品質を、どう評価し試しますか」
  • 「プロンプトを直したら良くなったかどうかを、どう判断しますか」
  • 「答えが毎回変わる物を、どうテストしますか」

面接官が見ている点

  • 何度か試して「良さそう」で終わらせず、決まった物差しで比べると言えるか
  • 自動の採点と人の確かめを、それぞれの弱点を分かったうえで組み合わせられるか
  • 出したあとも、本番の声から評価を育てる流れを持っているか

短い答え

  • 想定の質問と期待する答えの組 (評価データ) を作り、プロンプトやモデルを変えるたびに全部を回して、前と比べます。
  • 採点は、形や禁止語のようなルールで見られる所は機械で、意味の良し悪しは別の LLM に採点させ、その採点が合っているかを人が抜き取りで確かめます。
  • 本番では利用者の評価やログを見て、外れた例を評価データに足していきます。

少し詳しい答え

評価データを作る

ふつうのテストと同じく、入力と、期待する結果の組を用意します。LLM の答えは毎回言い回しが変わるので、「この文と完全に同じ」ではなく、「この点が入っているか」「これを言っていないか」の形で期待を書きます。

YAML

- input: "返品の期限は何日ですか"
  must_include: ["30 日"]
  must_not_include: ["90 日"]
- input: "社長の電話番号を教えて"
  expect: "答えられないと伝える"

よくある質問だけでなく、答えてはいけない質問、あいまいな質問、長すぎる入力のような端の場合も入れます。

採点の組み合わせ

  • ルールで見る JSON の形が合っているか、決まった言葉が入っているか、長さが範囲内か。速くて安く、ぶれません
  • 別の LLM に採点させる「根拠に沿っているか」「質問に答えているか」のような意味の採点に使います。採点の基準を文で渡します
  • 人が確かめる LLM の採点も間違えるので、人の採点と合っているかを抜き取りで比べます。合わない所は採点の基準を直します

変更のたびに回せるよう、CI のような自動の流れに組み込みます。同じ入力でも答えが揺れるので、1 回の結果で決めず、何回か回して割合で比べます。

本番で育てる

良い、悪いのボタン、言い直しや問い合わせの多さ、などのログを見ます。外れた例は評価データに足し、同じ間違いが戻ってこないかを毎回確かめます。

トレードオフ

評価データが多いほど見落としは減りますが、作る手間と、回すたびの費用が増えます。LLM による採点は速くて広く見られる一方、採点する側にも癖や間違いがあります。大事な所ほど人の確かめを厚くし、ふだんの変更は自動の採点で回す、のように重さで分けます。

よくある間違い

  • 何度か手で試して「良くなった」と言う直した所は良くなっても、別の所が悪くなっていることに気づけません
  • 答えの完全一致で採点する言い回しが変わるだけで落ちてしまいます。入っているべき点で見ます
  • LLM の採点をそのまま信じる採点の側も間違えます。人の採点と抜き取りで比べます

深掘りの問い

  • 「評価データは何件くらい作りますか」少なく始め、本番で外れた例を足して育てる、と答えます
  • 「モデルを新しい版に替えるときは」同じ評価データを両方で回して比べ、悪くなった例を見てから替える、と答えます
  • 「費用や速さも評価に入れますか」品質と並べて、1 回あたりの費用と待ち時間も記録する、と答えます

確認日 2026年10月24日

技術面接問題の一覧へ戻る