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

能力と信頼性のギャップ

ここに、初めて本物のユーザーにAIを届ける人をほぼ例外なく痛い目に遭わせるパターンがあります。

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

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

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

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

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

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

プロンプトをテストするとき、あなたは典型的に次のことをします。

  • 自分で設計した入力で実行する
  • 数回実行する
  • 良く見える出力を選り抜く
  • 正しく見えるまでプロンプトを微調整する

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

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

たった一度の良い出力は、性能の見積もりではありません。それは逸話です。

ばらつきこそ隠れた変数​

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

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

実践における能力・信頼性のスペクトル​

観点能力はあるが信頼性に欠ける信頼性がある
テストした入力作者が設計した例多様な、実ユーザーの入力
サンプルサイズ数回の実行多くの例での繰り返し実行
失敗モードの可視性テストでは稀、本番では頻発失敗が測定され理解されている
壊れたとどう気づくかユーザーからの苦情あなたのevalスイート
どう改善するかプロンプトを当てずっぽうで試す合格率を追跡し、失敗を体系的にデバッグする
デプロイの自信雰囲気ベース証拠ベース

evalこそが本当の堀​

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

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

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

始めるためのシンプルな方法​

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

  1. ゴールデンセットを作る。 20〜50個の実際の、または現実的な入力を集める。それぞれについて、正しい出力がどう見えるか(あるいは判定する基準)を書く。これらがあなたのゴールデンな例です。

  2. N回実行する。 各例に対してプロンプトを複数回実行する。実行間のばらつきはプロンプトの安定性を教え、例間のばらつきはカバレッジを教えます。

  3. 合格率を追跡する。 各(入力、実行)のペアについて、合格か不合格かを記録する。全体の率を計算する。この数値が、あなたの信頼性像の出発点です。

  4. リグレッションテストにする。 プロンプトを変えるたびに、evalをもう一度実行する。合格率が下がったら、何かを壊しました。上がったら、本物の改善をしました。

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

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

モデルが失敗したときの本能は、プロンプトを書き直すことです。ときにはそれが正解です。しかししばしばそれは、確認しなかったケースで後退する代償を払いながら、目にした失敗ケースに向けて最適化する方法になります。

AIのための信頼性エンジニアリングは、こう見えます。

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

プロンプトエンジニアリングは、そのプロセス内の一つの道具です。プロセスの代わりにはなりません。

正直な捉え方​

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

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

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

関連項目​