メインコンテンツまでスキップ
中級

能力と信頼性のギャップ

What you'll learn
  • なぜ「デモでは動いた」は本番で動く証拠にならないのか
  • 能力と信頼性 — これらは別の特性であり、ほとんどのガイドが混同している
  • 分散がいかに静かに 95% のタスクを壊れたプロダクトに変えるか
  • スプレッドシートで今日から始められる 4 ステップのゴールデンセット評価ループ
  • なぜプロンプトではなく評価こそが本当の堀なのか

初めて AI を実ユーザーに出荷するほぼ全員がやられるパターンがあります。

モデルはあなたのテストでは完璧にやってのける。本番では失敗する。あなたは混乱する。動くのを 見た のだから。

あなたがぶつかったのは、能力と信頼性のギャップです。

能力 とは、モデルがタスクを できる ことを意味します — 何らかの条件下で、少なくとも一度は正しい出力を生成する。

信頼性 とは、モデルが 一貫して タスクを正しくこなすことを意味します — 多様な入力にわたり、繰り返しの実行にわたり、言い回しや文脈のわずかな変化にわたって。

デモは能力を証明します。本番は信頼性を要求します。これらは別の特性であり、ほとんどのガイドが混同しています。

なぜデモは嘘をつくのか​

プロンプトをテストするとき、あなたはたいてい:

  • 自分で設計した入力で実行する
  • ほんの数回実行する
  • 良さそうに見える出力を選び取る
  • 正しく見えるまでプロンプトをいじる

このプロセスは能力を最適化します。プロンプトは今や あなたの 例で動きます。正しい出力を見ました。出荷します。

問題は、本番のユーザー入力があなたの例ではないことです。より雑然として、より多様で、予期しなかった言い回しをしています。モデルはそれらで一度もテストされていません。それらでどう振る舞うか、あなたには分かりません。

一度の良い出力は性能の推定値ではありません。逸話です。

分散が隠れた変数​

LLM は確率的です。同じプロンプトを 2 回実行すると、しばしば異なる出力が得られます。この分散は正常で、たいていは問題ありません。しかしそれは、重要な問いが「動いたか?」ではなく「どれくらいの割合で動くか?」だということを意味します。

モデルが 95% の確率で成功するタスクは、デモでは素晴らしく見え、およそ 20 人に 1 人のユーザーで壊れます。60% の確率で成功するタスクは、実行しているのがあなたなら問題なく見えます。これらはまったく異なる状況であり、測定なしには見分けられません。

実際の能力・信頼性スペクトラム​

次元能力はあるが信頼できない信頼できる
テストした入力作者が設計した例多様な実ユーザー入力
サンプルサイズ数回の実行多数の例に対する繰り返し実行
失敗モードの可視性テストでは失敗は稀、本番では頻繁失敗は測定され理解されている
壊れたことをどう知るかユーザーからの苦情あなたの評価スイート
どう改善するかプロンプトを推測して確認合格率を追跡し、失敗を体系的にデバッグ
デプロイの確信雰囲気ベース証拠ベース

評価こそが本当の堀​

より良いプロンプトは能力を上げられます。信頼性を上げたかどうかを教えてくれるのは評価だけです。

評価(eval) とは構造化されたテストです。入力のセット、期待される出力または評価基準、そして合格率を測る方法。モデルを入力で実行し、出力を採点し、数値を得ます。それから何かを変え — プロンプト、モデル、temperature — もう一度実行します。これでシグナルが手に入ります。

これは華やかではありません。ほとんどのチュートリアルが丸ごと飛ばす AI プロダクト開発の一部です。しかし、出荷するときに本当に重要な問い「見たことのない入力で、これはどれくらいの頻度で動くのか?」に答える唯一の方法です。

簡単な始め方​

始めるのにインフラは要りません。最小限の実行可能な評価ループはこうです。

Guided walkthrough1 of 4
  1. 20〜50 個の実際の、または現実的な入力を集める。それぞれについて、正しい出力がどのようなものか(またはそれを判断する基準)を書く。これがあなたのゴールデン例。自分で発明したものより実ユーザーの入力を優先すること — あなたが探しているのは、まだテストしていない分布だ。

それだけです。スプレッドシートで十分です。ツールより規律のほうが重要です。

なぜこれはプロンプティングの問題ではなくエンジニアリングの問題なのか​

モデルが失敗したときの本能は、プロンプトを書き直すことです。それが正しいこともあります。しかし多くの場合、それは見た失敗ケースに最適化する方法であり、確認しなかったケースで退行する代償を払っています。

AI の信頼性エンジニアリングはこういう姿をしています。

  • 何かを実行する前に「正しい」の意味を定義する
  • 代表的な入力分布に対して測定する
  • 一貫した方法論で変更を時系列で追跡する
  • 「このモデルはこのタスクができない」と「このタスクの仕様が不十分だ」を区別する

プロンプトエンジニアリングはそのプロセス内のツールです。その代替ではありません。

正直な捉え方​

ほとんどの AI の能力は本物です。モデルは本当に驚くべきことができます。能力と信頼性のギャップは、能力が偽物だという主張ではありません — 能力が存在すると知るだけでは十分でない、という主張です。

タスクを 95% の確率で動かす必要があるなら、95% の確率で動くという 証拠 が必要です。その証拠は構造化されたテストを実行することから得られるのであって、デモへの自信からではありません。

長持ちする AI プロダクトを作るエンジニアは、必ずしも最高のプロンプトを書く人ではありません。出荷する前に「動く」が何を意味するかを知っていて、それが本当かどうかを教えてくれる測定を持っている人です。

理解度チェック

0/3
  1. 新しいプロンプトをチームにデモしました。お気に入りの例を 3 回連続で完璧にこなしました。何を証明したことになりますか?
  2. プロンプトがゴールデンセットで 95% の確率で成功します。本番投入できますか?
  3. 見つけた 1 つの失敗ケースを直すためにプロンプトを変更しました。次に取るべき最善の一手は?
Key takeaways
  • 能力は「できるか?」、信頼性は「どれくらいの頻度でできるか?」 — デモは前者を証明し、本番は後者を要求する。
  • 一度の良い出力は逸話であって性能の推定値ではない。本当の証拠には、多様な入力を複数回実行することが必要。
  • 分散は隠れた変数: 95% の成功はデモでは素晴らしく見え、20 人に 1 人のユーザーで壊れる。
  • 20〜50 個の実入力のゴールデンセットから始め、それぞれを N 回実行し、合格率を追跡し、変更のたびに再実行する。
  • より良いプロンプトは能力を上げる。信頼性を上げ(そして証明す)るのは評価だけ — 評価こそが本当の堀。

関連​

次へ​