ファインマンのテスト

リチャード・ファインマンには有名なテストがある。

If you can't explain it simply, you don't understand it.

（リチャード・ファインマン）

簡単に説明できなければ、理解していない。

ファインマンの学習法は明快だ。まず、概念を学ぶ。次に、それを12歳の子どもに説明するつもりで書いてみる。うまく説明できない部分が見つかる。そこが、自分の理解が足りない部分だ。教科書に戻って、その部分を学び直す。また説明してみる。この往復を繰り返す。

AIプロンプトの本質は、このファインマンのテストと同じだ。

AIに何かを指示するということは、自分の理解を言語化するということだ。何を求めているのか。なぜそれが必要なのか。どういう条件を満たすべきか。何が良くて何がダメか。

これらを明確に言語化できるとき、AIは良い出力を返す。言語化できないとき、AIは曖昧な出力を返す。

AIの出力が悪いとき、ほとんどの場合、問題はAIにあるのではなく、自分の理解にある。自分が何を求めているか、自分でもわかっていない。ファインマンのテストに落ちている。

これは不愉快な事実だ。AIの出力が悪いのはAIのせいだと思いたい。モデルの性能が悪い、プロンプトのテクニックが足りない、と。でも多くの場合、本質的な問題は「自分が何を理解していて何を理解していないかを把握できていない」ことだ。

ポール・グレアムはエッセイ「Write Like You Talk」でこう書いた。

If you simply try to write the way you would speak, you'll find that your writing improves. And so will your ideas.

（ポール・グレアム「Write Like You Talk」2015年）

話すように書け。そうすれば文章が良くなる。そしてアイデアも良くなる。

なぜか。話し言葉は、理解していないことを隠せないからだ。書き言葉では、難しい用語や複雑な構文で理解の浅さを隠すことができる。話し言葉では、それが難しい。相手の顔を見ながら、わかりやすく説明しようとすると、自分がどこを理解していてどこを理解していないかが、否応なく露呈する。

AIプロンプトも同じだ。最良のプロンプトは、友人に説明するように書かれたプロンプトだ。技巧的なテンプレートや、プロンプトエンジニアリングの定型句ではなく、「これをやりたくて、こういう理由で、こういう条件があって、こういう結果がほしい」と、自分の言葉で書いたもの。

ファインマンのテストに合格するプロンプトが、最良のプロンプトだ。

ブライアン・イーノはGenerative Music（生成音楽）の先駆者だ。イーノは、音楽を「作曲する」のではなく、「生成される仕組みを設計する」というアプローチを取った。

イーノの方法はこうだ。まず、音楽が生成されるシステムのルールを設計する。どういう音を使うか、どういう制約を設けるか、どういう変化を許容するか。そして、システムを走らせる。出てきた結果の中から、良いものを選ぶ。

You set up conditions and let things happen within them.

（ブライアン・イーノ）

条件を設定し、その中で物事が起きるのに任せる。

人間の仕事は二つだ。入口で何を入れるかを決めること。そして出口で何を選ぶかを決めること。真ん中のプロセスは、システムに任せる。

AIの使い方も、まったく同じ構造だ。

入口で、自分の理解を正確に言語化する。ファインマンのテストに合格する精度で。出口で、AIの出力を評価し、選択し、修正する。専門家としての判断で。

真ん中のプロセス、つまり大量の情報を処理し、パターンを認識し、テキストを生成する作業は、AIに任せる。

入口と出口が人間の仕事だ。そして、入口の質と出口の質は、どちらも人間の理解度に依存する。

ファインマンのテストは、入口の質を測るテストだ。簡単に説明できるか。12歳の子どもにわかるように言えるか。それができれば、AIは良い仕事をする。

理解のないところに、良い入力はない。良い入力のないところに、良い出力はない。

自分の理解度がそのまま、AIの出力品質を決める。これがファインマンのテストが教えてくれることだ。