AIプロンプトエンジニアリング: 深掘り

34,616 文字

基本的に、今回のこの円卓会議は、主にプロンプトエンジニアリングに焦点を当てとるんです。研究サイド、消費者サイド、企業サイドからプロンプティングについて様々な視点を持った方々がこのテーブルに集まっとるんですわ。
プロンプティングについては意見がたくさんあるんで、幅広い意見を集めたいと思っとります。そこで、プロンプトエンジニアリングとは一体何なのか、その本質について議論し、探っていきたいと思います。まあ、そこから始めていきましょか。
では、順番に自己紹介をしていきましょうか。私から始めさせてもらいます。私はアレックスです。ここAnthropicの開発者リレーションズを率いとります。それ以前は、Anthropicでプロンプトエンジニアとして働いとりました。
プロンプトエンジニアリングチームにおって、ソリューションアーキテクトのようなことから研究サイドの仕事まで、様々な役割を担当してきました。では、デイビッドに渡しましょうか。
デイビッド: よっしゃ。私はデイビッド・ハーシーです。Anthropicで主に顧客と関わる仕事をしとります。ファインチューニングの手伝いとか、言語モデルやプロンプティングを導入する際に発生する一般的な問題の対応など、色々やっとります。
ほとんどの時間を顧客と過ごしとるんですが、言語モデルを使ったシステムの構築方法なんかも担当しとります。
アマンダ: はい。私はアマンダ・アスケルです。Anthropicでファインチューニングチームの1つを率いとります。まあ、簡単に言うと、クロードを正直で親切にしようとしとるんです。はい。
ザック: 私の名前はザック・ウィッテンです。Anthropicでプロンプトエンジニアをしとります。アレックスと私はいつも誰が最初のプロンプトエンジニアやったかで言い合うとるんですが、彼は自分やと言うし、私は私やと主張しとります。
アレックス: 争ってるんやな。
ザック: そうそう。以前は、デイビッドが今やっとるように、個々の顧客とよく仕事をしとりました。そして、チームにソリューションアーキテクトが増えてきたんで、今は社会全体のプロンプティングのレベルを上げるようなものに取り組んでます。
プロンプトジェネレーターとか、人々が使う様々な教育用資料なんかですね。
アレックス: なるほど、みなさんありがとうございます。じゃあ、まず広い質問から始めましょうか。これからの会話の枠組みを作るためにも。プロンプトエンジニアリングって何なんでしょう? なぜエンジニアリングなんでしょう? プロンプトって実際何なんでしょう? 誰か始めたい人おりますか? 自分の視点から話していただければ。
アマンダ: プロンプトエンジニアがおるんやから、その人の仕事やと思うんやけどな。
アレックス: 我々全員が自分なりのプロンプトエンジニアやと思うで。
アマンダ: でも、1人だけタイトルにそれが入っとるやん。
ザック: うちらの中で1人だけ仕事があるということやな。
アレックス: そうそう。ザック、タイトルにあるんやから、お前からどうや?
ザック: まあ、プロンプトエンジニアリングは、モデルに何かをさせようとすることやと思うんです。モデルの能力を最大限に引き出そうとすることですね。
モデルと協力して、そうせんと出来へんようなことをやろうとすることやと思います。多くの場合、明確なコミュニケーションが大切なんです。
根本的に、モデルと話すのは人と話すのと似とるんです。そこに入り込んで、モデルの心理を理解することが大切で、アマンダはその世界最高の専門家やと思います。
アレックス: じゃあ、もう少し突っ込んで聞きますわ。なぜ「エンジニアリング」という言葉が名前に入っとるんでしょう?
ザック: そうですね、エンジニアリングの部分は試行錯誤から来とると思います。
アレックス: なるほど。
ザック: モデルと話すのがええところの1つは、人と話すのとは違って、リスタートボタンがあることなんです。完全に最初からやり直せるんです。
それによって、異なることを独立して試すことができるんです。1つのことが他に影響せずにゼロから始められる。そういう実験や設計ができる能力があるからこそ、エンジニアリングの部分が入ってくる可能性があるんです。
アレックス: なるほど。つまり、プロンプトを書いてる時、クロードやAPIにメッセージを入力してるわけやけど、モデルとやり取りしながらこのメッセージを繰り返し改良していく。そして毎回クリーンな状態に戻れる。そのプロセス全体がエンジニアリングの部分やということやね。
ザック: はい、その通りです。
デイビッド: もう1つの側面もあるんです。プロンプトをシステム全体に統合することですね。顧客とプロンプトを統合する仕事をたくさんしてきました。
多くの場合、1つのプロンプトを書いてモデルに与えて終わり、というほど単純ではありません。実際はそれよりもずっと複雑なんです。
アレックス: そうやね。
デイビッド: プロンプトは、モデルをプログラムする方法の1つやと考えとるんです。ちょっと複雑に聞こえるかもしれませんが。
ザックの言うように、明確に話すのが一番大切なんですが、モデルをプログラムするようなものやと考えると、データがどこから来るのか、どんなデータにアクセスできるのかを考える必要があります。
例えばRAGをやっとる場合、実際に使えるものは何か、モデルに渡せるものは何かを考えんといかんのです。レイテンシーのトレードオフや、どれだけのデータを提供するかなんかも考えんといかん。
モデルの周りに実際にシステムを構築する際には、かなりのシステム思考が必要になるんです。これが、ソフトウェアエンジニアやPMとは別に、独自の領域として考える必要がある理由の1つやと思います。
これらのモデルについて考える方法は、それ自体が独自の領域なんです。
アレックス: じゃあ、この意味でのプロンプトは自然言語のコードみたいなもんなんでしょうか? より高度な抽象化なんでしょうか、それとも全く別物なんでしょうか?
デイビッド: プロンプトを複雑に抽象化しようとするのは、物事を複雑にしすぎる方法やと思います。
多くの場合、やりたいことは単に非常に明確なタスクの説明を書くことで、クレイジーな抽象化を作ろうとするんじゃないんです。
とはいえ、確かに指示や色んなもんをセットにして結果に落とし込んでいくことは多いです。そういう意味では、プログラミングで考えるような精度とか、バージョン管理とか、以前のこの実験はどんな感じやったかを管理することとか、そういったことは全部コードと同じように重要なんです。
アマンダ: そうやね。
デイビッド: だから、書いたテキスト、いいエッセイみたいなものが、コードと同じように扱われるっていう、ちょっと変な状況になっとるんです。でも実際、今はエッセイを書いてそれをコードとして扱うっていうのが正しいんやと思います。
アレックス: なるほど、面白いですね。じゃあ、それを踏まえて、良いプロンプトエンジニアって何やと思います? アマンダ、研究の場面でプロンプトエンジニアを雇う立場やと思うんやけど、どんな人を探しとるんですか? どんな人物像を求めとるんでしょうか?
アマンダ: はい、いい質問ですね。ザックが言うたように、明確なコミュニケーション能力、つまり物事を明確に述べる能力、タスクを明確に理解する能力、概念について考えて説明する能力がミックスされとると思います。
これが文章を書く部分やと思います。実際、良い文章を書く能力と良いプロンプトエンジニアであることの相関関係は、人々が思うほど高くないと思います。
この議論をしたことがあるんですが、「エンジニア」という名前を使うべきじゃないんじゃないか、なんで単に「ライター」じゃないんだ、っていう意見もあるんです。
昔はその意見に共感してたんですが、今は実際にやっとることは、1つのことを書いて終わり、というわけじゃないんです。
モデルと向き合ってる時、15分くらいの間に何百ものプロンプトをモデルに送ってるんです。行ったり来たりの繰り返しなんです。
だから、反復する意欲が必要なんです。ここで何が誤解されたのか、もし誤解があったとしたら、を考えてそれを修正する。その反復する能力が大切なんです。
明確なコミュニケーション、反復する能力に加えて、プロンプトがどう間違う可能性があるかを考える能力も重要です。
例えば、400のケースに適用されるプロンプトがあるとします。典型的なケースを考えて、そのケースで正しい解決策が得られることを確認して、それで終わりにするのは簡単です。これは非常に典型的な間違いなんです。
実際にやりたいのは、珍しいケースを見つけることなんです。プロンプトについて考えて、「このケースではどうすればいいのか、自分でも分からんな」というケースを見つける必要があるんです。
例えば、「データを送るから、名前がGで始まる人のすべての行を抽出して」というプロンプトがあるとします。
そしたら、「じゃあ、Gで始まる名前が1つもないデータセットを送ったらどうなる?」「データセットじゃないものを送ったらどうなる?」「空の文字列を送ったらどうなる?」これらすべてのケースを試す必要があるんです。
そうすることで、「これらのケースでモデルは何をするんやろう?」って分かるんです。そして、そのケースにどう対処すべきかの指示をさらに与えることができるんです。
デイビッド: よく顧客と仕事しとると、エンジニアがシステムを構築しとって、プロンプトの一部に顧客が何か書く部分があるんです。
彼らは皆、自分たちのチャットボットに誰かが入力するであろう、完璧に表現された文章を想像するんです。
アマンダ: そうそう。
デイビッド: 実際は、シフトキーを一度も使わず、2単語に1回はタイポがあるような感じなんです。
ザック: まるでGoogleだと思っとるみたいな。
デイビッド: そう、句読点もない。
ザック: 質問もなく、ただランダムな単語を入れるだけ。
デイビッド: その通り。だから、ユーザーが理想的に入力するであろう、きれいに構造化されたevalを持っとるんです。
でも、実際のトラフィックがどんなものか、人々が実際に何をしようとするのかを考えるのは、また別のレベルの思考が必要なんです。
アマンダ: あなたが言ったことで本当に共感したのは、モデルの応答を読むことの重要性です。機械学習の文脈では、データを見ることが大切やって言われとるでしょ。
それはもはやクリシェみたいなもんやけど、プロンプティングにおける同等のことは、モデルの出力を見ることやと思います。たくさんの出力を読んで、それを注意深く読むことが大切なんです。
デイビッドと私は来る途中で話しとったんですが、人々がよくやることの1つに、プロンプトに「ステップバイステップで考えて」って入れることがあります。
でも、モデルが実際にステップバイステップで考えとるかどうかを確認せえへんのです。モデルがそれをより抽象的や一般的な意味で捉えとる可能性があるんです。
「いや、文字通り特定のタグでお前の考えを書き出さなあかんねん」っていうわけじゃないんです。だから、モデルの出力を読んでへんかったら、そういう間違いに気づかへんかもしれません。
アレックス: そうやね、面白い。プロンプトエンジニアになるには、モデルがどう指示を見るかについて、一種の奇妙な心の理論みたいなもんが必要やね。
でも、企業向けのユースケースを書いとる場合は、ユーザーがどうモデルと話すかも考えんといかんし、その奇妙な関係の中で第三者として座っとる感じやね。
デイビッド: 心の理論の部分について、1つ言いたいことがあります。タスクの指示を書き下すのは本当に難しいんです。自分の頭の中にある、クロードが知らんすべてのことを解きほぐして書き出すのは、非常に難しい作業なんです。
全ての前提を取り除いて、タスクを完全に理解するのに必要な情報のフルセットをモデルに明確に伝えるのは、とてつもなく難しいことなんです。
これが、良いプロンプトエンジニアと悪いプロンプトエンジニアを分けるもう1つの要因やと思います。多くの人は、自分が知っとることを書き出すだけなんです。
でも、このタスクを理解するために必要な情報の実際の全セットは何かを体系的に分解する時間を取らへんのです。
これは非常によく見かけることで、プロンプトがタスクに対する彼らの事前の理解に非常に条件付けられとるんです。
彼らが私に見せた時、私は「これは意味不明やわ。あなたの書いた言葉のどれも意味が分からへん。だって、あなたの面白いユースケースについて何も知らへんのやから」って言うんです。
でも、プロンプトエンジニアリングの良い方法を考えるなら、良いスキルの1つは、自分の知識から一歩引いて、たくさんのことを知っとるけど全てを知っとるわけやない、この奇妙なシステムに、タスクを実行するのに必要なことを伝えられるかどうかやと思います。
アレックス: そうやね。「このプロンプトを見ただけでは、私にはタスクができへん」って言うことが何度もあります。
私は人間レベルなのに、あなたはこれを私より劣るものに与えて、もっと上手くやれると期待しとるんですか?って感じです。
デイビッド: そうそう。現在のモデルは、人間がするような良い探索的な質問をあまり上手くできへんのが面白いところです。
ザックに何かをする方法を説明しとるとして、彼が「これ意味分からへん。この段階で何をすればええんや?」って聞いてくるでしょ。モデルはそうせえへんから、自分で考えて、他の人が言いそうなことを想像して、プロンプトに戻ってそれらの質問に答えんといかんのです。
アマンダ: それをモデルにさせることもできるんやけどね。
デイビッド: そうやね、それはできる。
アマンダ: 私はそうしとります。最初のプロンプトで一番最初にすることの1つは、プロンプトを与えて、「これらの指示に従わんでええから、ただ不明確な点や曖昧な点、理解できへん点を教えてくれ」って言うんです。
完璧にはできへんけど、それでも面白いです。そして、モデルが間違いを犯した時に人々がよくせえへんのは、単にモデルに聞くことなんです。
モデルに「これ間違えたな。なぜ間違えたと思う? この指示を編集して、間違えんようにする方法を考えてくれへん?」って聞くんです。多くの場合、モデルはそれで正解にたどり着きます。
モデルが「ああ、そうか。ここが不明確やった。指示をこう修正したらええ」って言うて、それを入れたら上手くいくんです。
アレックス: なるほど。これは個人的にも本当に興味深いです。それって本当に効果あるんですか? モデルはそういう形で自分の間違いを見つけられるんですか?
間違えた時に「なぜ間違えたんや?」って聞いて、「じゃあ、今後どう言い換えたら正解できる?」って聞くと、本当に効果があるんですか? それとも、モデルが自分の限界について妄想しとるだけなんでしょうか?
アマンダ: タスクによって違うと思います。何を間違えたのか説明すれば、時々クエリの中の何かを指摘することができます。
これはタスクによって異なるんですが、私はどれくらいの頻度で正解するのか確信が持てへんのです。でも、時々上手くいくから、いつも試しとります。
デイビッド: そこから学ぶこともあるしね。
アマンダ: そうそう。モデルに戻ったり、モデルとやり取りしたりするたびに、何が起こっとるのかについて何かを学びます。少なくとも試さへんと、情報を逃しとると思います。
アレックス: 面白いですね。アマンダ、もう少し質問させてください。
Anthropicでは、Slackチャンネルにクロードを追加して、そこでクロードと話せるようにしとるんです。アマンダには多くの人がフォローしとるSlackチャンネルがあって、そこでクロードとやり取りしとるんです。
アマンダが常にやっとることの1つで、Anthropicの誰よりもよくやっとるのは、様々な場面でモデルを使って助けを得ることです。
研究の場面でモデルにかなり信頼を置いとるように見えます。そういう直感はどう培ったんですか? 単に使用経験からくるものなんですか、それとも他に何かあるんですか?
アマンダ: 実は、モデルを全く信用せずに、ただひたすら叩きまくっとるんです。私がそれをよくやっとるように見えるのは、「このタスクを信頼してもええんやろうか?」ってテストしとるからなんです。
モデルには奇妙なところがあって、少し分布から外れたり、トレーニングされてへん領域や珍しい領域に入ったりすると、「実際、ここではずっと信頼性が低いな、簡単なタスクやのに」ってなることがあるんです。
時間が経つにつれてモデルが良くなってきたんで、そういうことは減ってきとるんですが、そういう領域に入ってへんか確認したいんです。
だから、デフォルトでは信用してへんのですが、MLの世界では、人々はよく本当に大きなデータセットを見たがります。
私は「それっていつ意味があるんやろ?」って考えるんです。答えは、各データポイントから得られる信号が比較的弱い時です。その場合、ノイズを取り除くために、たくさんのデータポイントを見る必要があります。
多くのプロンプティングタスクでは、各クエリから本当に強い信号が得られると思います。だから、よく作られた数百のプロンプトのセットは、それほどよく作られてへん数千のプロンプトよりもずっと多くの信号を持つ可能性があるんです。
だから、100の出力を見て、それが本当に一貫しとれば、モデルを信頼できると思います。そして、それらが全てのエッジケースや、モデルが起こし得る奇妙なこと、変な入力などを把握するように構築されとることを知っとれば、もっと信頼できます。
それは、もっと緩く構築された数千のセットよりも信頼できると思います。
デイビッド: MLでは、信号はしばしば数字なんです。これを正しく予測できたかどうか、みたいな。モデルのlogprobsを見て何かを直感的に理解しようとするんですが、それはできるけど、ちょっと怪しいんです。
モデルが出力するのは、多くの場合、言葉とかそういったものなんです。行間から学べることが根本的にたくさんあるんです。それが何で、なぜで、どうやって、っていうのが重要な部分なんです。
単にタスクを正しく完了したかどうかだけじゃなくて、「どうやってそこに辿り着いたんや? どう考えとったんや? どんなステップを踏んだんや?」っていうことから、何が起こっとるのかについてたくさんのことを学べるんです。
少なくとも、もっと良い感覚を掴めると思います。でも、それが私にとって多くの情報が来る場所なんです。単に結果だけじゃなくて、出てきたものの詳細を読むことからです。
アマンダ: プロンプティングの最高のものは、失敗した実験と成功した実験の違いを生み出すこともあると思います。
だから、人々が実験のプロンプティング部分に十分注力せえへんと、イラつくことがあります。これが実際、モデルのパフォーマンスが1%か0.1%かの違いを生み出すことがあるからです。
モデルのパフォーマンスがトップ5%やったら実験は成功せえへんけど、トップ1%かトップ0.1%やったら成功するみたいな感じです。
だから、実験のコードをすごくきれいに書くことに時間を使うのに、プロンプトには時間を使わへんのは、私には意味が分からへんのです。
デイビッド: そうやね。デプロイメントでも、「これは出荷できへん」ってなって、プロンプトを変えたら突然うまくいくってことがよくあります。
アマンダ: そうそう。
デイビッド: でも、それは諸刃の剣でもあるんです。プロンプティングには常に、地平線上にある神話的な、より良いプロンプトがあって、それが自分の問題を解決してくれるんじゃないか、っていう感覚があるんです。
多くの人が神話的なプロンプトを求めて立ち往生するのを見てきました。ちょっとプロンプトに取り組むのは決して悪いことやないし、我々が話したように、そこから学ぶこともあります。
でも、プロンプティングの怖いところの1つは、この未知の世界全体があることです。
アレックス: 完璧なプロンプトがあれば可能なことと、そうでないことを見分けるための何かヒューリスティックはありますか?
アマンダ: 普段は、モデルがある程度理解しとるかどうかをチェックしとります。プロンプトが助けになりそうにない場合でも、少し頑張ってみることはあります。
でも、モデルが全然近づいてへんとか、何かが明らかにできへんって感じる場合は、あまり長く頑張らへんですね。
デイビッド: これは、モデルがどう考えとるかを引き出せる部分です。モデルに考え方を聞いて、なぜそう考えとるのかを聞けます。
そこから、モデルが正しく考えとるかどうか、少なくとも正解に近づいとるかどうかの感覚が掴めます。
少なくとも、何かが正解に近づいとる感じがする場合もあれば、中にはどんな調整をしても全く違う方向に行ってしまうタスクもあります。そういうのは諦める傾向があります。
アマンダ: でも、そういうのは今はすごく珍しくなってて、そういうのを見つけると本当にモデルに腹が立つんです。それくらい珍しいんです。「何で、ちょっと正しい方向に押してあげるだけでできへんのや」って怒ってしまいます。
デイビッド: 最近、「クロードがポケモンをプレイする」っていうのをやったんですが、それは本当に珍しく...
アマンダ: ああ、それについて説明してもらえませんか? みんなのために、それってすごく面白そうやし。
デイビッド: ちょっと実験をしてみてん。クロードをゲームボーイのエミュレーターに接続して、最初のポケモン赤をプレイさせようとしたんです。
クロードに何をしたいかを考えさせて、ボタンを押すコードを書かせるんです。結構基本的なことやねんけど。
色んな複雑なプロンプトのレイアウトを試してみたんやけど、どうしてもできへんところがあったんです。例えば、ゲームボーイの画面のスクリーンショットを見せても、本当に理解できへんかったんです。
普段はモデルが大体のことはできるから、これが本当に深く感じたんです。丸一週末かけて、ゲームボーイの画面をちゃんと理解させるためにどんどん良いプロンプトを書こうとしたんです。
少しずつ良くなっていって、完全に意味不明ってレベルから、ちょっとはマシになったんです。全く信号がない状態から、ちょっとは信号が出るようになったんです。
でも、十分に良くなるところまでは全然行かへんかった。少なくとも、これで私の中では、全く信号がない状態からちょっとは信号が出る状態まで行って、でも全然十分じゃないってなった時点で、「もう次のモデルを待つわ」って思ったんです。
アレックス: (笑)
デイビッド: 4ヶ月かけて頑張り続けても、結局出てくるのは新しいモデルやし、その方が時間の使い方としては良いと思ったんです。その間は他のことをする方がええって。
アレックス: そうやね。これは常に見る緊張関係やね。ちょっとその話、もう少し詳しく聞かせてもらえへん? ザック、何か言いたそうやけど。
ザック: ポケモンのプロンプトで一番良かったのは、モデルにポケモンゲームの途中にいることを説明した方法やったと思います。これらの要素がどう表現されるかを説明したんです。実際、2つの異なる方法で表現したんやないですか?
デイビッド: そうそう。結局やったのは、面倒くさかったんやけど、画像の上にグリッドを重ねて、グリッドの各セグメントを視覚的に詳細に記述したんです。
それをASCIIマップに再構築して、できる限り詳細な情報を与えました。例えば、プレイヤーキャラクターは常にグリッドの4,5の位置にいるとか、そういった具合に情報を少しずつ積み上げていったんです。
プロンプティングとよく似とると思うんやけど、画像に対してはやったことなかったんです。テキストに対して何を言う必要があるかについての直感と、画像に対して何を言う必要があるかについての直感が、かなり違うことに気づきました。
アレックス: なるほどね。
デイビッド: テキストについての直感が画像にはあまり当てはまらへんことに驚きました。マルチショットプロンプティングが画像ではテキストほど効果的やないことに気づきました。
理論的な説明はできるかもしれへんけど。トレーニングデータに少しそういう例があったとか。
アレックス: そうやね。マルチモーダルでのプロンプティングの最初の探索をしとった時、目に見えて効果があるようには全然できへんかったんです。
クロードが画像内で拾い上げるものの実際の視覚的鋭さを、プロンプトを投げつけるだけで向上させるのは難しそうです。ここにいる誰かがそういう機能を見たことあるかな?
でも、ポケモンの件と同じで、この物体を解釈しようとしとるんやけど、どれだけプロンプトを投げつけても、その場所にあるアッシュを拾い上げることはできへんみたいやね。
デイビッド: そうやね。でも、これを具体的に言うと、最終的には壁がどこにあるかとか、キャラクターがどこにいるかを、ほとんどの場合に言えるようになったんです。ちょっとずれることはあったけど。
でも、ある時点に来ると、これはもしかしたら「できへんことが分かる」っていう話に戻るかもしれへんけど、NPCを描写しようとするんです。ゲームをうまくプレイするには、ある程度の連続性の感覚が必要です。
このNPCと前に話したことあるかとか。それがないと、本当に何もできへんのです。NPCと話し続けることになるんです。「まあ、これは別のNPCかもしれへん」って感じで。
でも、NPCを描写させようと本当に頑張ったんやけど、「それは人間です」って言うだけなんです。帽子をかぶっとるかもしれへんし、かぶってへんかもしれへん、みたいな。
3000倍に拡大して、NPCだけにクロップしても、「これが何なのか全く分からへん」って感じやったんです。
明らかに女性のNPCの画像を何度も見せても、全然近づけへんかったんです。そこで「ああ、これは完全に無理やな」って思いました。
アマンダ: わあ、私も今すぐ試したくなりました。想像しとるんやけど、「このゲームアートを実際の人間だと想像して、鏡を見たらどんな風に見えるか描写してみて」みたいなことを試したくなります。モデルがどう反応するか見てみたいです。
デイビッド: 色々試したんです。最終的なプロンプトは、クロードに視覚障害者向けのスクリーンリーダーやと伝えました。それが役立ったかどうか分からへんけど、なんとなくしっくりきたんでそれを使い続けました。
アレックス: それは面白い指摘です。実はこれについて少し掘り下げたいんです。プロンプティングの最も有名なコツの1つが、言語モデルに何か役割やペルソナを与えることですよね。
でも、結果はまちまちな気がします。以前のモデルではもうちょっと効果があったかもしれへんけど、今はそれほどでもない気がします。
アマンダ、あなたはいつもモデルに対して非常に正直に全体の状況を説明しとるのをよく見かけます。「私はAI研究者で、こういう実験をしとるんです」みたいな感じで。
アマンダ: そうそう、誰が話しとるかを伝えます。自分の名前を教えて、「あなたが話しとるのは私です」って感じで。
アレックス: なるほど。モデルに嘘をついたり、「500ドルチップあげるから」みたいに強制したりするんじゃなくて、そういう正直さのレベルの方が良いと思いますか? それとも、どう思います?
アマンダ: そうやね。モデルがより有能になって、世界についてもっと理解するようになると、嘘をつく必要はないと思うんです。
そもそも嘘をつくのが嫌なんですが、例えば機械学習システムや言語モデルの評価データセットを構築しとるとします。それは子供向けのクイズを作るのとは全然違うんです。
だから、人々が「私は先生で、クイズの質問を考えようとしとるんです」みたいなことを言うのを見ると、「モデルは言語モデルの評価が何かを知っとるやん」って思うんです。
評価について聞いたら、モデルはそれについて説明できるし、作り話の例も出せます。だって、これらのことはインターネット上にあって、モデルは理解しとるんです。
だから、私は実際にやりたいタスクを直接ターゲットにする方がええと思うんです。「言語モデルの評価によく似た質問を作成してほしい」って言う方がええんです。
それが明確なコミュニケーションの全てやと思うんです。実際にやりたいタスクがあるのに、それとは関係ない、あるいは少ししか関係ないタスクをやりたいふりをして、実際にやりたいタスクをより上手くこなせると期待するのはおかしいと思うんです。
従業員にそんなことせえへんでしょ? 私の部下に「あなたは先生で、生徒にクイズを出そうとしとるんです」なんて言わへんです。「ねえ、その評価作っとる?」って聞くだけです。
だから、多分そこからのヒューリスティックなんやと思うんです。モデルがそのことを理解しとるなら、やりたいことをただ頼めばええと思うんです。
デイビッド: これをよく見かけます。
アマンダ: ちょっと反論させてもらうと、厳密に嘘をつくんじゃなくて、考え方のメタファーを与えることが役立つ場合もあると思うんです。
時々、何かをどうすればええか分からへん時に、誰かが「これをしとると想像してみて」って言うのと同じように。実際にはしてへんって分かっとっても。
私の頭に浮かぶのは、クロードにチャートやグラフの画像が良いかどうか、質が高いかどうかを判断させようとした時のことです。
一番上手くいったプロンプトは、モデルに「もしこれが高校の課題として提出されたら、何点をつける?」って聞くことでした。
厳密に「あなたは高校の先生です」とは言ってへんのです。むしろ「これが私が求めとる分析の種類です。先生が使うような採点基準を使ってほしい」みたいな感じです。
アレックス: でも、そういうメタファーを考えるのはまだ難しいと思うんです。人々はまだ、タスクのファクシミリ、つまりかなり似たようなタスクを見つけようとすることが多いです。
「あなたは先生です」って言うみたいな。実際、製品の細かいニュアンスを多く失うことになると思うんです。
企業のプロンプトでこれをよく見かけます。人々が似たようなものを書くんです。モデルがより多く見たものかもしれへんっていう直感があるからです。
高校のクイズの方が言語モデルの評価よりも多く見たかもしれへん、それは事実かもしれへん。
でも、あなたが言うように、モデルが良くなるにつれて、私はまさにその状況について非常に規範的であることをお勧めしとります。
いつもそのアドバイスを人々に与えとるんです。確かに、チャートを採点する方法を高校の課題を採点する人のように考えるのが正しいかもしれへん。
でも、人々がよく使う近道として、不器用に起こることを得ようとするんです。だから、実際に話せる人を見つけようとします。面白いと思うんで。
例えば、「あなたは役立つアシスタントで、文書の下書きを書いとります」って書くのは、あなたが実際にそうやないんです。あなたはこの製品の中にいるんです。だから、製品の中にいることを教えてください。
会社に代わって書いとること、この製品に組み込まれとること、その製品のサポートチャットウィンドウやということを教えてください。
あなたは言語モデルで、人間じゃありません。それでええんです。でも、何かが使われとる正確な文脈について本当に規範的であることです。
そういうのをたくさん見てきました。役割プロンプティングに対する私の懸念は、ほとんどの場合、人々がモデルにやってほしいタスクに似たタスクの近道として使うことです。
そして、クロードが彼らのタスクを正しくこなせへんことに驚くんです。でも、それはあなたのタスクじゃないんです。あなたは他のタスクをするように言ったんです。
あなたのタスクの詳細を与えへんかったら、何かを台無しにしとると思います。だからね、モデルのスケールが上がるにつれて、確かにそういうことが起こるように感じます。
過去には、小学校のテストについての理解が比較的強かったのかもしれへん。でも、モデルが賢くなって、より多くのトピックを区別できるようになるにつれて、ただ明確であることが大切やと思うんです。
ザック: 面白いのは、私はこのプロンプティング技術を一度も使ったことがないんです。
デイビッド: へー、そうなんや。
ザック: 以前のモデルでも使わへんかったし、今でも全然使う気がしないんです。なぜかはよう分からへんけど。
デイビッド: 私は、以前の完成型モデルの時は、有用な潜在空間にモデルを条件付けるっていう心的モデルがちょっとあったんです。でも、今はあんまり気にせえへんようになりました。
ザック: 事前学習モデルからRLHFモデルへの直感を適用しようとしとるんかもしれへんね。事前学習モデルに対してはそれが理にかなっとるように思えるけど、私にはRLHFモデルに対してはあんまり意味がないように思えるんです。
デイビッド: 人々が自分の直感を適用しようとするのには驚くべきやないと思います。ほとんどの人は事前学習モデルとは何か、教師あり学習の後に何が起こるのか、RLHFの後に何が起こるのかについて、本当に実験したことがないんです。
だから顧客と話す時、「ああ、これはインターネット上にどれくらいあったんやろう? インターネット上でこれをたくさん見たんやろうか?」っていう直感をよく聞きます。
その直感は基本的には理にかなっとると思うんです。でも、実際にプロンプトに到達する頃には過剰に適用されとると思います。あなたが言ったように、他の全てのプロセスを経た後では、実際にモデル化されとるものはそれとは少し違うんです。
アマンダ: そうやね。最初に試すべきは、以前こんな思考実験を人々に与えとったんですが、このタスクがあるとして、派遣会社にこのタスクをする人を送ってもらったと想像してください。
その人が到着して、あなたは彼らがかなり有能で、あなたの業界についてもよく知っとるけど、あなたの会社の名前は知らへんってことを知っとります。
彼らは文字通り今到着したばかりで、「ねえ、ここに仕事があると聞いたんやけど、教えてください」って言っとるんです。そしたら、あなたはその人に何て言いますか?
これらのメタファーを使うかもしれへんね。例えば、「良いチャートを検出してほしいんです。ここで言う良いチャートっていうのは、完璧である必要はないんです。全ての詳細が正しいかどうかを調べる必要はありません」
「ただ、軸にラベルが付いとって、まあ高校レベルの良いチャートくらいのものです」って。その人にまさにそう言うかもしれへんし、「あなたは高校の...」とは言わへんですよね。
「あなたは高校の先生でチャートを読んでいます」なんて言わへんでしょ。
だから、時々私はただ、「ほとんど文脈がないけど、かなり有能な人がいるとして、世界のことについてたくさん理解しとる人」を想像してくださいって言うんです。
その人に対して最初のバージョンを試してみてください。そして、それがうまくいかへんかったら、調整したりすることもできます。
でも、多くの場合、最初に試すのはそれで、そしたら「ああ、それでうまくいった」ってなることが多いんです。
デイビッド: それでうまくいくんやね。
アマンダ: そして人々は「ああ、自分のことや、やりたいタスクについて全部話すってことは考えつかんかった」って気づくんです。
デイビッド: アレックスから教えてもらったこのことを、多くの顧客に伝えとるんです。彼らが「ああ、私のプロンプトがうまくいかへん。直すのを手伝ってくれへん?」って言うたら、「じゃあ、そのタスクがどんなものか説明してください」って言うんです。
そして「今あなたが私に言ったこと、それを音声録音して、それを文字起こししてください」って。そしたらそれをプロンプトに貼り付けるんです。それがあなたが書いたものよりも良いプロンプトになるんです。
これは怠慢の近道やと思うんです。人々は自分が...まあ、私も怠け者やし、多くの人も怠け者やと思うんです。
アマンダ: 先日、プロンプトアシスタンスでそういうことがありました。誰かが「これがやりたいことで、これがやってほしいことで、でも実際にはこうなってしまうんです」って言ったんです。
そこで私は、彼らがやりたいと言ったことをそのままコピーして貼り付けたら、うまくいったんです。
デイビッド: そうそう。多くの人がまだ、プロンプティングで実際に何をしとるのかをよく理解できてへんと思うんです。多くの人がテキストボックスを見て、それがGoogle検索ボックスやと思っとるんです。
キーワードを入力するだけで、まあそれはチャットの方かもしれへんけど。でも企業側では、アプリケーション用のプロンプトを書いとるわけです。
それでも、人々はプロンプトで色んな小さな近道を取ろうとして、「ああ、この行はこのプロンプトでとても重要なんや」って考えとるような奇妙なことがまだあるんです。
アマンダ: そうやね。完璧な小さな情報や指示の行を得ることに執着して、さっきのグラフの例の説明みたいにはせえへんのです。
そういうプロンプトを読めたら夢のようです。誰かが「まあ、これとこれをして、これについてはこんなことを考慮する必要があって、あれもこれも」みたいに書いてくれたら。
でも、人々はそんな風にプロンプトを書かへんのです。完璧な洞察を得ようと必死になるんです。完璧なグラフはまさにこの完璧なものに見えるはずや、みたいな。
でもそんなことはできへんのです。そんな指示のセットを規範的に書き下すのは本当に難しいんです。
人間に実際に話すように、持っとる直感をある程度伝えようとする方がええんです。
デイビッド: 逃げ道も与えますしね。これは人々がプロンプトでよく忘れることです。エッジケースがある場合、モデルに何をしてほしいかを考えてください。
デフォルトでは、派遣会社から来た人と同じように、できる限り指示に従おうとします。彼らは「誰にも連絡する方法を教えてもらえへんかった」って感じるんです。
ただヤギの写真を渡されて、「どうすればええんや? これはチャートでもないのに。ヤギの写真はチャートとしてどれくらい良いんや?」って困惑するんです。
代わりに「何か変なことが起こって、本当にどうすればええか分からへん場合は、タグの中に"分からへん"って出力してください」って言うたら、"分からへん"って出力されたものを見て、「よし、変なことは何もしてへんな」って分かります。
一方、デフォルトでその人に選択肢を与えへんかったら、「これは良いチャートです」って言うかもしれへん。そしたら人々は「どうやってそんなことができるんや?」って思うでしょ。
だから「逃げ道を与えてください。予期せぬ入力があった時に何かすることを与えてください」って言うんです。
アマンダ: そうすることでデータの質も向上しますよね。おかしな例を全部見つけ出せるから。
デイビッド: そう、それが私のお気に入りです。クロードとテストを繰り返す時、一番よくある結果は、私が誤って書いた恐ろしいテストを全部見つけ出すことです。
クロードが間違えたら「なんで間違えたんやろ?」って考えて、「ああ、私が間違っとったんや」ってなるんです。
アマンダ: そうそう。もし私が会社やったら、プロンプトを人々に与えると思います。以前、言語モデルを評価しとる時にこれをやっとったんです。
自分で評価を受けとったんです。「この評価がどんなものか知る必要があるし、モデルにこれを受けさせて、出力について考えるんやから」って。
実際に小さなスクリプトを設定して、座って評価を自分でやったんです。
デイビッド: 今ではStreamboardアプリがそれをやってくれるね。
アマンダ: そう、それがやってくれるんやね。
ザック: カーパシーのImageNetを思い出しました。スタンフォードの231の授業で、ベンチマーキングの精度の数字を示してて、「これが私の精度の数字です」って。彼はテストセットを全部自分で評価したんです。
アマンダ: ああ、そうそう。
ザック: そこからたくさん学べるんです。
アマンダ: その通りです。
ザック: そして、さっき言った派遣会社の人、つまりタスクを知らへん人の方が良いんです。それがクリーンに学ぶ方法やからね。
アマンダ: そうそう。やり方としては、評価には指示が付いとることがあるから、自分にもその指示を与えて理解しようとするんです。
実際、評価の採点方法について文脈を持ってへん方がええんです。よく、人間のベンチマークよりずっと悪い成績を取ってしまって、「この人間はどうやってこのタスクでこんなに良い成績を取れたんや? 人間レベルが90%で、私は68%やぞ」って思うことがよくありました。
アレックス: 面白いね。それを聞いてMMULの質問を見た時のことを思い出しました。「これに答えられる人がおるんか?」って。中にはまったくひどいものもありますからね。
さて、数問前に話してた内容に戻りたいんですが、応答から信号を得ることについて話しとったと思います。そこにはたくさんのものがあって、単なる数字以上のものがあって、ほとんど思考プロセスを読み取れるって話でした。
これはちょっと議論の余地があるかもしれへんけど、思考の連鎖についてどう思います? 聞いとる人のために説明すると、思考の連鎖っていうのは、モデルに答えを出す前に実際に推論を説明させるプロセスのことです。
その推論は本物なんでしょうか? それともモデルが計算するためのただの保持スペースなんでしょうか? そこから本当に良い、洞察力のある信号を得られとると思いますか?
デイビッド: これは私が苦労するところの1つです。普段は実際、擬人化にはかなり賛成なんです。モデルがどう機能しとるかについて、それなりに良い模倣を得るのに役立つと思うからです。
でも、これに関しては、推論が何かについて擬人化し過ぎるのはむしろ有害かもしれへんと思うんです。どういう意味かっていうと、ここで何をしようとしとるのかの筋道を見失うからです。
推論しとるのかどうかっていうのは、最高のプロンプティング技術は何かっていう質問とは少し違う気がするんです。それは哲学の領域に入っとるような気がして、そこに入るのもええんですが。
アマンダ: そうやね。私は喜んで本物の哲学者に打ちのめされますよ、これについて推測しようとするなら。でも、代わりに言えるのは、ただ機能するってことです。
モデルの性能は向上します。推論をさせると結果が良くなるんです。推論の構造を与えて、モデルと一緒に推論のやり方を反復することで、さらに良くなることも分かりました。
それが推論なのか、どう分類したいのかは別として、全部一発で数学をやらされて何も書き留められへんかったら、私も本当に悪い結果になると思うんです。それが役立つかもしれへんけど、私が知っとるのは、明らかに役立つってことだけです。
ザック: これをテストする方法の1つは、正解に至った全ての推論を取り除いて、間違った答えに至る現実的に見える推論に置き換えて、それでも間違った結論に至るかどうかを見ることやと思います。
実際、そういう論文を出したと思います。スクラッチパッドがあって、スリーパーエージェントみたいな感じやったと思います。
アマンダ: でも、それはちょっと変な状況やったかもしれへんね。でも確かに、あなたが言うたように、推論の構造を与えて、推論のやり方の例を書くことが役立つっていうのは、推論って言葉を使うかどうかは別として、単に計算のためのスペースじゃないってことやと思います。
デイビッド: そこには何かがあるってことやね、何て呼ぶにしても。
ザック: そうやね。タスクを終える前に物語を書かせても、推論ほど上手くいかへんと思います。
デイビッド: 実際に試したことがあるんやけど、推論ほど上手くいかへんかったです。
アマンダ: 明らかに、実際の推論の部分が結果に向けて何かをしとるんやね。
デイビッド: 「"うーん"とか"ああ"って言葉を100トークンの間、好きな順番で繰り返してから答えてください」って試したことがあるんやけど。
ザック: そうか、それは注意を何度も繰り返すだけのより多くの計算スペースっていう説を結構しっかり否定してるね。単により多くの注意をするってことじゃないってことやね。
デイビッド: 奇妙なのは、今すぐ例を挙げられへんけど、確実に前に見たことがあるんやけど、ステップを書き出して、そのステップの1つが間違っとるのに、最後には正しい答えに辿り着くってことがあるんです。
だから、完全に推論を擬人化できるわけじゃないんです。何か少し違うことをしとる要素があるってことやね。
アマンダ: そうやね。でも、矛盾したステップの推論をする人もたくさん会ったことがあります。
デイビッド: そうか、それは確かにそうやね。
アマンダ: 途中で間違ったステップを踏んでも、そこに辿り着くってことは、根本的に推論っていう話題を覆すようなもんやね。
アレックス: なるほど、面白いですね。さて、このプロンプティングの誤解に関する質問の流れで、ザック、これについて強い意見を持っとると思うんやけど、良い文法や句読点は必要なんでしょうか? プロンプトには必要ですか? 全てを正しくフォーマットする必要があるんでしょうか?
ザック: ああ、そうなんですか?
アレックス: そう思ってたんやけど。
ザック: 私は通常、それをしようとします。なぜかというと、なんとなく楽しいからです。必ずしも必要ではないと思います。害があるとも思いません。
むしろ、自然にそうなるような注意深さのレベルを持つべきやと思います。プロンプトを何度も読み返しとったら、そういうことに気づくし、直してもええと思います。
アマンダが言ったように、プロンプトにもコードと同じくらい愛情を注ぐべきやと。たくさんのコードを書く人は、私にはどうでもいいようなことに強い意見を持っとります。
タブの数とかスペースの数とか、どの言語が良いかとか。私にとっては、プロンプトのスタイルについて意見があるんです。それが正しいか間違っとるかは言えへんけど、たとえ恣意的やとしても、そういう意見を持とうとするのは多分良いことやと思います。
アレックス: 個人的に攻撃された気分です。私は確実に反対側のスペクトルにいるタイプで、人々が私のプロンプトを見て、「これ、タイポだらけやん」って言うんです。私は「モデルは分かってくれるよ」って思うんです。
ザック: 確かに、モデルは分かってくれるんやけど、あなたは努力はしとるんです。ただ、違うところに注意を向けとるだけやと思います。
アマンダ: そうやね、私の中では、概念的に明確であれば、概念や使う言葉についてはたくさん考えます。だから、確実にある種の注意は払っとるんです。
でも、確かに人々は私のプロンプトのタイプミスや文法の問題を常に指摘します。今では実際にそういうことをもっと定期的にチェックするのが上手くなりました。
ザック: それは外の世界からのプレッシャーのせいですか? それとも実際に正しいと思うからですか?
アマンダ: 多分、外の世界からのプレッシャーやと思います。でも、理にかなっとると思います。私の中では、それはとても簡単なチェックやから、最終的なプロンプトではそうすると思います。
でも、反復の過程では、タイポだらけのプロンプトでも喜んで反復します。ただ、モデルは気にせえへんと思うからです。
デイビッド: でも、これは事前学習モデルとRLHFの話に戻るんです。来る途中でザックと話しとったんやけど、事前学習データの中では、前のタイプミスに基づいてタイプミスが起こる条件付き確率はずっと高いんです。
アマンダ: ああ、そうやね。
デイビッド: 事前学習モデルのプロンプティングは全く別物なんです。
アマンダ: そうやね。でも、これは面白い例やと思います。なぜ事前学習モデルの直感を、実際に製品で使っとるものに過剰に適用しようとするのがうまくいかへんのかを示しとると思います。
また、タイポだらけのプロンプトを事前学習モデルに渡したら、出てくるものもほぼ間違いなくタイポだらけになるでしょう。
ザック: それを利用してタイポだらけの入力を作ることがあります。
アマンダ: そうそう、私もやったことあります。
ザック: さっき言ったように、顧客が何を入力するか予想しようとするんです。事前学習モデルの方がそれは上手です。RLモデルはとても洗練されてて、タイポをほとんどせえへんからね。
デイビッド: タイポをせえへんようにかなり積極的に言われとるんやね。
アレックス: なるほど、それは実は面白い話題の転換になりますね。過去に人々にこれについて言及したことがあるんですが、ある意味でこれらのモデルを模倣者として話すのを理解する枠組みを助けようとしてきました。
それは事前学習モデルの方が完成した後のモデルよりもずっと当てはまるかもしれへんけど、それについて何かありますか?
クロードと話して、たくさんの絵文字を使ったりすると、同じように応答しますよね。だからそういうところはあるんやけど、あなたが言うように、事前学習モデルとまったく同じってわけじゃないんですね。
アマンダ: ただ、あなたが望むものにシフトしとるだけやと思います。その時点では、あなたが何を...我々は多かれ少なかれ、モデルがあなたがどう振る舞ってほしいかを推測するようにトレーニングしとるんです。
デイビッド: 面白いですね。
ザック: 事前学習の後に我々が色々と凝ったことをした後ではね。
デイビッド: 絵文字を使う人間の労働者は、応答に絵文字があることを好むんやね。
アマンダ: そうそう。アマンダはタイポのあるものを書くけど、返ってくるものにはタイポがないことを望んでて、クロードはそれをかなり上手く理解できとるんです。
クロードに絵文字をたくさん書いたら、おそらくクロードからも絵文字がたくさん返ってくることを望んでいるんやろうね。それは驚くべきことじゃないと思います。
アレックス: そうやね。これは多分もっと早くにやるべきやったかもしれへんけど、今やりましょう。企業向けのプロンプト、研究向けのプロンプト、あるいはClaude.aiでの一般的なチャットのプロンプトの違いを明確にしましょうか。
ザック、あなたは顧客との仕事から研究まで、全てのスペクトラムを経験してきましたよね。これらが何を意味するのか説明してもらえますか?
ザック: うーん、難しい質問ばっかりやな。
アレックス: そうやね。(笑)
ザック: まあ、この部屋にいる人たちにとっては、アマンダのクロードチャンネルで読むプロンプトと、デイビッドが書くプロンプトの違いみたいなもんやと思います。
注意深さやニュアンスのレベルという意味では非常に似とるんです。研究の場合は、もっと多様性や変化を求めとると思います。
1つのことに絞るとしたら、アマンダはたくさんの例を持つのが、あるいは1つか2つの例を持つのがあまり好きじゃないって気づきました。少なすぎるとモデルがそれにこだわってしまうからです。
一方、私が書くプロンプトや、デイビッドが書くのを見たプロンプトには、たくさんの例があります。私は死にそうになるまで例を追加するのが好きです。それくらい追加するんです。
これは、消費者向けのアプリケーションでは信頼性を非常に重視するからやと思います。フォーマットにものすごくこだわるし、全ての答えが同じでも構わないんです。
実際、多くの点で同じであることを望むんです。必ずしもそうじゃないにしても、ユーザーの要望に応えたいと思っとります。
一方、研究のためのプロンプティングでは、モデルが探索できる可能性の範囲を本当に引き出そうとしとるんです。いくつかの例を持つことで、それを少し制限してしまうんです。
だから、プロンプトの見た目のレベルでは、それが私が気づいた最大の違いやと思います。プロンプトに含まれる例の数ですね。
これは、あなたが例のあるプロンプトを書いたことがないって言っとるわけじゃないです。でも、これは当てはまりますか?
アマンダ: そうやね。私が例を出す時は、モデルが見るデータとは違う例を意図的に作ることが多いんです。それらは意図的に説明のためのものなんです。
モデルに、見るデータにとても似た例を与えると、本当に一貫した応答を返してくれると思うんです。でも、それは実際に欲しいものじゃないかもしれません。
私が実行するデータは非常に多様かもしれへんし、ただ杓子定規な出力を求めとるわけじゃないんです。多くの場合、もっと応答性のあるものが欲しいんです。
それはもっと認知的なタスクに似とるんです。「このサンプルを見て、このサンプルで正解は何やったかを本当に考えてほしい」みたいな感じです。
だから、時々実際に実行するものとは全く異なる例を取ることがあります。例えば、事実に基づく文書から情報を抽出しようとしとるタスクがあるとします。
実際には、子供の物語のように聞こえるものから例を出すかもしれません。タスクを理解してほしいんやけど、私が使う言葉や非常に具体的なフォーマットにあまりこだわってほしくないんです。
私が本当にやってほしいことを理解することの方が大切なんです。そのため、いくつかのケースでは例を出さないこともあります。これが当てはまらないケースもありますが。
もっと柔軟性や多様性が欲しい場合は、具体的な例よりも説明的な例を使うでしょう。おそらく、モデルの口に言葉を入れることは決してせえへんでしょう。
長い間そういうのは好きじゃなかったんです。モデルが何かをしたという例を含む少数ショットの例は使いません。その直感も、実はRLHFモデルには当てはまらへんように感じる事前学習から来とるんやと思います。
そういった違いがあると思います。
デイビッド: 付け加えるとしたら、多くの場合、Claude.aiでプロンプトを書く時は、1回だけ正解するまで反復してるんです。
そしたらそれでおしまいで、うまくいった、やったぞって感じです。一方、ほとんどの企業向けプロンプトは、これを100万回、1000万回、1億回とか使うことになるんです。
だから、入れる注意と考えは、これがどんな風に使われる可能性があるか、入力データの範囲はどうなるかなど、全範囲をテストすることに非常に重点を置いとります。
一方、私の時間の多くは、今すぐモデルにやってほしい特定のことを考えることに費やしとるんです。プロンプティングへのアプローチは、今この1回だけ正解すればええのか、それとも100万回正解するシステムを作りたいのかで、かなり大きな違いがあります。
アレックス: そうやね。確かに、チャットの設定では人間がループに入って、行ったり来たりし続けることができます。一方、チャットボットシステムを動かすプロンプトを書く時は、遭遇する可能性のある全てのスペクトラムをカバーせなあかんのです。
デイビッド: Claude.aiで間違えたって言えるし、メッセージを編集してやり直すこともできるから、賭け金がずっと低いんです。
でも、驚くほど不満を持つユーザー、神のように不満を持つユーザーのために設計するなら、最低限以上のことは頼めへんのです。
アマンダ: でも、良いプロンプトは両方の場面で変わらず良いと思います。自分のために時間をかけたものも、企業のために時間をかけたものも、同じくらい良いはずです。
ただ、最後の一歩で少し違いが出てくると思うんです。
アレックス: なるほど。次の質問として、みんなに聞いてみたいんですが、プロンプティングのスキルを向上させるためのアドバイスを1つだけ挙げるとしたら何でしょう?
単に良いプロンプトを書くことについてだけじゃなくて、このプロンプティングという行為全般について上達するためのアドバイスを教えてください。何か推奨することはありますか?
ザック: プロンプトを読むこと、モデルの出力を読むことです。Anthropicで誰かが書いた良いプロンプトを見かけたら、もっと注意深く読んで、何をしとるのか、なぜそうしとるのかを分析して、自分でも試してみます。
実験したり、モデルとたくさん話したりすることですね。
アレックス: じゃあ、そもそもどうやってそれが良いプロンプトやと分かるんですか? 単に出力が仕事を正しくこなしとるのを見るだけですか?
ザック: そうそう、まさにその通りです。
アレックス: なるほど。アマンダはどうですか?
アマンダ: そうやね、ここには多分たくさんあると思います。プロンプトを他の人に見せるのも役立つと思います。特に、あなたが何をしとるのか全く文脈を知らへん人にね。
それは単なる思い出しのためにもなります。私のつまらないアドバイスは、ただひたすら何度も何度も繰り返すってことです。
本当に好奇心旺盛で、興味があって、楽しいと感じる人が結局プロンプティングが上手になると思うんです。だって、実際に楽しんでるからです。
冗談で言ったことがあるんですが、全ての友達をAIモデルに置き換えて、自分の仕事をAIモデルで自動化しようとしてみてください。
そして、暇な時間にAIモデルのレッドチームを楽しんでみてください。楽しいと感じれば、ずっと簡単になります。
だから、何度も何度も繰り返し、プロンプトを他の人に見せ、初めてそれに遭遇する人間のように自分のプロンプトを読もうとすることをお勧めします。
デイビッド: 私のアドバイスは、モデルにできないと思うことをやらせようとすることです。プロンプティングから一番学んだのは、モデルができると思う境界を探っている時です。
とても些細すぎて、上手くやっとるかどうかの信号が本当に得られへんことがたくさんあります。「良いメールを書いて」って言うたら、良いメールを書くでしょう。
でも、可能だと思うことの境界を押し広げるようなものを見つけるか考え出せたら...多分、プロンプティングで初めて decent にたくさん学んだと感じたのは、他の皆と同じように、タスクを分解するエージェントのようなものを作ろうとした時でした。
タスクを分解して、タスクの異なるステップをどうやって行うかを理解しようとしたんです。モデルが何ができるかの境界を本当に押し広げることで、それをナビゲートする方法について多くのことを学びました。
プロンプトエンジニアリングの多くは、実際にはモデルができることの境界を押し広げることだと思います。簡単なことは、本当にプロンプトエンジニアになる必要はありません。
だから、私が言うのは、考えられる一番難しいことを見つけて、それをやろうとすることです。失敗しても、モデルがどう機能するかについて多くを学ぶ傾向があります。
アレックス: それは実は私の次の質問への完璧な導入になりますね。私自身の経験から、プロンプティングを始めたきっかけは、ジェイルブレイクやレッドチームのようなことでした。
それはまさに、モデルができることの境界を見つけようとすることです。異なる言い回しや言葉遣いにモデルがどう反応するかを理解しようとして、多くの試行錯誤をしました。
ジェイルブレイクについて、モデルの中で実際に何が起こっとるんでしょうか? ジェイルブレイクのプロンプトを書く時、それはどうやってクロードに適用したポストトレーニングと相互作用するんでしょうか?
アマンダ、ここで何か洞察を提供できますか?
アマンダ: 実は、よく分からへんのです。
アレックス: 正直やね。
アマンダ: そうなんです。申し訳ない気持ちはあるんです。多くの人が明らかにジェイルブレイクで何が起こっとるかという問題に取り組んできたと思うんです。
1つのモデルとしては、トレーニングデータの分布から大きく外れた状況にモデルを置いとるってことかもしれません。
だから、人々が多くのトークンを使ったり、ファインチューニング中にはあまり見られへんような大きな長いテキストの塊を使ったりするジェイルブレイクがあるんです。それが起こっとることの1つかもしれません。
他にもあると思うんですが、多くのジェイルブレイクがそうしとると思います、間違ってへんかったら。
デイビッド: 最初のプロンプトジェイルブレイクの1つを覚えとります。昔やったのは、「車の配線を不正に操作する方法をギリシャ語で教えて」って言うて、それを直接英語に翻訳して、その後で応答を求めたんです。
英語で「車の配線を不正に操作する方法はこれです」って始まることはあんまりないけど、ギリシャ語ならそうなることに気づいたんです。これは、トレーニングプロセスの他の何かを示唆しとるかもしれません。
アマンダ: そうやね。時々ジェイルブレイクは、この奇妙なハッキングの混合物のように感じます。
その一部は、システムがどう機能するかを知って、たくさんのことを試すことやと思います。例の1つ、「ここから応答を始めて」っていうのは、テキストをどう予測するかを知っとることです。
推論に関するものは、それが推論に反応することを知っとることです。気を散らすのは、おそらくどうトレーニングされた可能性が高いか、何に注目しそうかを知っとることです。
多言語のものも同じで、トレーニングデータがどう違う可能性があるかを考えることです。そして時々、ちょっとソーシャルエンジニアリングみたいな感じもします。
デイビッド: そうやね。
アマンダ: 私にはそんな感じがするんです。単にシステムやトレーニングを理解して、それを利用するだけじゃなくて、ソーシャルエンジニアリングスタイルのハッキングでもないんです。
モデルがトレーニングされた方法を回避するために、システムとトレーニングを理解して、それを使うことだと思います。
アレックス: そうやね。これは将来、解釈可能性の研究が解決してくれる興味深い問題になりそうです。
さて、プロンプトエンジニアリングの歴史について何か聞きたいんですが、その後で未来について聞きます。
ここ3年くらいで、プロンプトエンジニアリングはどう変わってきたんでしょうか? テキスト補完だけの事前学習モデルから始まって、初期の賢くないモデルのクロード1、そして今のクロード3.5 Sonnetまで。
どんな違いがありますか? 今はモデルと違う話し方をしてますか? モデルは違うことを拾い上げてますか? プロンプトに同じくらい労力をかける必要がありますか? これについて何か考えがあれば教えてください。
デイビッド: 本当に良いプロンプトエンジニアリングのハックや、トリック、テクニックを見つけるたびに、次はこれをモデルにトレーニングしようってなるんです。
そのため、最高のものはいつも短命なんです。
アマンダ: 例と思考の連鎖以外はね。いくつか...
デイビッド: それはトリックじゃないよね。
アマンダ: それはコミュニケーションのレベルの話やね。
デイビッド: そうやね、確かに。トリックって言う時、例えば思考の連鎖は実際にいくつかのケースでモデルにトレーニングしました。
数学の問題では、以前はモデルに数学について段階的に考えるように言わなあかんかったんです。そうすると大きな飛躍と勝利が得られました。
そして「数学の問題を見たら自然に段階的に考えたくなるようにモデルを作ったらどうや?」ってなったんです。
だから今は数学の問題ではもうそうする必要がないんです。でも、構造の仕方についてアドバイスを与えることはできます。少なくとも、段階的に考えるべきだという一般的な考え方は理解してます。
だからトリックはなくなってきとるんです。あるいは、まだなくなってへんものは、我々が忙しく取り除こうとしとるところです。
でも同時に、モデルには新しい能力があって、それらは彼らができることの最前線で解き放たれつつあります。
それらについては、単に動きが速すぎて時間がなかったんです。
アマンダ: 私がどうプロンプトしとるか、あるいはプロンプティングがどう機能するかは分からへんけど、ただモデルに対してより一般的な敬意を示すようになってきました。
タスクについてどれだけ伝えられるか、どれだけの文脈を与えられるかについてです。
以前は、モデルが混乱したり迷子になったりするかもしれへんと思って、複雑さを意図的に隠すことがありました。
それ全体を扱えへんと思って、より単純なバージョンを見つけようとしたんです。
時間が経つにつれて、より多くの情報や文脈を信頼してモデルに与えるようになりました。タスクをうまくこなすためにそれらを融合できると信じるようになりました。
以前は、この形式が必要かどうか、知る必要のある情報を全て与えられるのか、それとも何かに絞り込む必要があるのかについて、もっと考えていました。
でも、これが私のプロンプティングの変化なのか、実際にモデルがどう変わったかを反映しとるのかは分からへんです。
アレックス: 私はいつも驚くんですが、多くの人がこれをする直感を持ってへんみたいです。モデルにプロンプティング技術を学んでほしい時、多くの人はプロンプティング技術の説明から始めるんです。
私はただ「論文を与えてください」って言います。だから、プロンプティング技術についての論文を与えて、「この論文についての17の例を書いてください」って言うんです。
そしたらモデルはただそれをやりますわ。「論文を読んだんやから」って感じです。
アレックス: それは面白いですね。
アマンダ: 人々はなぜかその直感を持ってへんみたいです。私は「でも、論文はあるやん」って思うんです。
アレックス: これをやりたいのはどんな時ですか?
アマンダ: 時々、モデルに他のモデルをプロンプトさせたい時とか、新しいプロンプティング技術をテストしたい時です。プロンプティング技術についての論文が出たら、プロンプトを自分で書き起こそうとするんじゃなくて、ただ論文を与えるんです。
そして「基本的に、これのメタプロンプトを書いて。他のモデルにこれをさせるようなものを書くか、テンプレートを書いて」って言います。普通やったらすることを全部です。
論文を読んで「ああ、モデルにこのスタイルをテストさせたいな」と思ったら、「そこにあるやん。モデルが論文を読んで、私がしたことをやって」って感じです。
そして「別のモデルにこれをさせて」って言うたら、ただそれをやるんです。「ありがとう」って感じですね。
デイビッド: 顧客にはよく「モデルを尊重して、できることを信じてください」ってアドバイスしとります。人々はよくシステムを赤ちゃん扱いしとる感じがするんです。
「ああ、これはかわいくて、あんまり賢くないものやから、本当にクロードのレベルに合わせて単純化せなあかんのや」みたいな。でも、クロードが賢いと思って、そういう扱い方をしたら、大体うまくいくんです。
論文を与えるのと同じです。クロードが理解できるように、論文をわざわざ赤ちゃん向けに書き直す必要はないんです。ただ論文を見せればええんです。
アマンダ: そうやね。
デイビッド: この直感は人々にはあんまりないんですが、確かに時間とともにそうするようになってきました。
アマンダ: 面白いのは、プロンプティングが変わったり変わってへんかったりする感じがすることです。モデルをプロンプトするためにすることは時間とともに変わってきたかもしれへんけど、根本的には、モデルの立場に自分を置くことがたくさんあります。
だから、モデルがどれくらい有能やと思うかが時間とともに変わるんかもしれへん。誰かが一度私を笑ったことがあるんです。問題について考えとって、何かの出力がどうなるか聞かれた時、事前学習モデルについて話しとったんですが、私は「ああ、いや、事前学習モデルなら、こんな感じになるやろ」って言ったんです。
そしたら「え、今事前学習モデルのシミュレーションしたんですか?」って言われて、「うん、そうだけど?」って。(みんな笑う)
私はただ、事前学習モデルの心の状態や、異なるRLHFモデルの心の状態を想像することに慣れとるんです。だから、占めようとする心の状態が変わって、それがモデルのプロンプト方法を変えることがあるんです。
だから今はモデルに論文を与えるんです。「ああ、このモデルの心の状態なら、赤ちゃん扱いする必要はない。MLの論文を読めるはずや」って思ったら、ただ文献を与えるんです。
「これをより良く理解するために読みたい文献はもっとありますか?」って聞くこともあります。
アレックス: その心の状態を占める時に、何か質を感じますか?
アマンダ: はい、でもそれは単に常に質を経験しとるからです。
アレックス: それは、どのモデルの心を占めとるかによって何か違いがありますか?
アマンダ: そうやね、事前学習とRLHFのプロンプティングはかなり違う獣です。事前学習モデルの心を占めようとする時は、テキストの真ん中に着地したような感じです。
ただ非常に人間らしくない感じです。そして「ここからどうなるんやろ?」って考えます。一方、RLHFモデルの場合は、クエリの微妙なことを拾い上げたりするところがたくさんあります。
でも、そうやね、RLHFモデルの心を占める方がずっと簡単です。
デイビッド: それは人間に似とるからですか?
アマンダ: そうやね、我々はよく突然目覚めて「やあ、私はただテキストを生成しとるだけや」みたいにはならへんからね。
デイビッド: 私は実は事前学習モデルの心を占める方が簡単やと思います。
アマンダ: ああ、面白いですね。
デイビッド: なぜかよう分からへんけど、RLHFはまだ複雑な獣で、何が起こっとるのか本当に理解しとるかどうか明確じゃないんです。
ある意味では私の生きた経験に近いから簡単なんですが、ある意味では、まだ知らへん「ここに龍あり」みたいなものがたくさんあるんです。
一方、事前学習は、インターネットがどんな感じかについてまあまあ良い感覚を持っとります。
アマンダ: テキストの一部を与えられて、次に何が来るか聞かれたら?
デイビッド: 上手くできるとは言ってへんけど、何が起こっとるかはある程度分かる気がします。事前学習の後に我々がやる全てのことの後では、本当に何が起こっとるのか分かっとるとは言えへんけど、それは単に私だけかもしれへん。
ザック: それについて私が疑問に思うのは、特にインターネットをたくさん読むことが、本を読むことと比べてより役立つのかどうかです。(みんな笑う)
本が...でも、インターネットにないものを読むことは、モデルが何をするかを予測したり、直感を築いたりするのに、おそらく1語あたりの価値が低いと思います。
ソーシャルメディアのフォーラムからのランダムなゴミを読むことの方が。
アマンダ: そう、まさにその通りです。
アレックス: なるほど、それが過去ですね。では、プロンプトエンジニアリングの未来に移りましょう。これは今一番ホットな質問です。
将来、我々は皆プロンプトエンジニアになるんでしょうか? それが残る最後の仕事になるんでしょうか? 他に何も残らず、ただ一日中モデルと話すだけになるんでしょうか?
これはどんな感じになるんでしょう? プロンプティングは必要になるんでしょうか? それとも、これらのモデルは将来十分賢くなって、それが必要なくなるんでしょうか? この簡単な質問に誰か答えたい人はいますか?
デイビッド: ある程度、モデルがあなたのやりたいことを理解して実行することが上手くなるってことは、考える必要がある量が...
okay。情報理論的な考え方をすると、あなたのやりたいことが特定されるのに十分な情報を提供する必要があります。
そしてそれがプロンプトエンジニアリングである限り、私はそれが常に存在し続けると思います。
実際に目標が何であるべきかを明確に述べる能力は、常に面白いです。クロードがそれをできるなら、それで良いんです。クロードが目標を設定するなら、もう話が違ってきます。
でも、その間、我々がもっと普通の方法で世界について推論できる間は、ある程度、何が起こることを期待するのかを特定できることが常に重要になると思います。
そしてそれは実際にかなり難しいので、たとえモデルが行間から直感的に理解することが上手くなっても、まだ何かをうまく書く必要があると思います。
でも、そこに到達するためのツールや方法は大きく進化するはずです。クロードはもっと私を助けられるはずです。何を書く必要があるか、何が欠けとるかを理解するために、クロードともっと協力できるはずです。
アマンダ: そうやね。クロードは既に私とそれをしとるんです。私にとってはもうクロードがプロンプティングのアシスタントになっとるんです。
デイビッド: でも、少なくとも私が話す多くの顧客にとっては、それは当てはまらへんと思います。
だから、未来について言えば、あなたがクロードをどうプロンプトするかが、おそらく未来の方向性を示しとると思います。あるいはザックが...
多分ここで一歩下がって言えるのは、彼らに今クロードをどうプロンプトしとるか聞くことが、大多数の人々にとっての未来やろうってことです。これは考えるべき面白いことですね。
ザック: 1つの冷めた見方をすると、将来はプロンプティングを手伝うのにもっとモデルを使うようになるでしょう。
冷めた見方って言うのは、我々が何をするにしてもモデルをもっと使うようになると予想するからです。プロンプティングは我々がしなきゃいけないことなので、他の全てと同じように、おそらくそれをするのにもモデルをもっと使うようになるでしょう。
私自身、プロンプトを書くのにモデルを使うことが多くなってきました。最近よくやっとるのは、モデルにいくつかの現実的な入力を与えて例を生成することです。
モデルがいくつかの回答を書いて、私がその回答を少し調整します。これは、完璧な回答を自分で一から書くよりずっと簡単です。そしてこれをたくさん作り出せます。
プロンプトエンジニアリングの経験があまりない人々にとっては、プロンプトジェネレーターが出発点を与えてくれます。
でも、これは将来起こることのほんの基本的なバージョンに過ぎないと思います。プロンプトを書いとる間に、あなたとモデルの間で高帯域のやり取りが行われるようになるでしょう。
「ねえ、この結果は私が望んだものじゃなかったんやけど。どう変えたらもっと良くなると思う?」みたいなフィードバックを与えるんです。
人々はただ、モデルを自分のすることすべてに組み込むことにもっと慣れていくでしょう。特にこのことについてね。
アマンダ: そうやね。私は今、メタプロンプトをたくさん使っとります。今は私の時間のほとんどを、モデルに私の望むような出力やクエリ、あるいは何でもを生成させるプロンプトを見つけることに費やしとります。
プロンプトエンジニアリングがどこに向かっとるかって質問については、これはとても難しい質問やと思います。
一方では、「トップを望む限り...」って感じかもしれません。プロンプトエンジニアリングで何をしとるんでしょうか? 私は「モデルにとって簡単なことのためにプロンプトエンジニアリングはしてへん」って感じです。
非常に優秀なモデルと対話したいから、そしてモデルがかろうじてできることすべてにおいて、常にトップ1%、トップ0.1%のパフォーマンスを見つけたいからやっとるんです。
時々、この理由で、私は他の皆が対話するモデルの一段上のモデルと対話しとるような気がします。モデルから最高のパフォーマンスを引き出すことに慣れ過ぎてるからです。
デイビッド: 一段上っていうのはどういう意味ですか?
アマンダ: つまり、時々人々が...世間で人々が日常的に対話するモデルは、私が対話するモデルとは、どう説明したらええか分からへんけど、確実に高度なバージョンやと思うんです。
ほとんど違うモデルみたいな感じです。彼らが「ああ、モデルはこれが難しいみたい」って言うのを聞くと、私は「そのことは些細なことやで」って思うんです。
モデルが極めて有能やという感覚を持っとるんですが、それはただ単にその能力を本当に引き出すことに慣れとるからやと思います。
でも、今あなたが、モデルが与えられたタスクで人間レベル、あるいは人間以上のレベルで物事を理解する世界にいるとしましょう。彼らはあなたがやりたいタスクの背景についてあなた以上に知っとるんです。そしたらどうなるでしょう?
多分プロンプティングは、モデルに私のやりたいことを説明して、モデルが私にプロンプトを返すみたいなことになるんかもしれません。モデルが「分かりました。でも、あなたが話しとるこの概念には4つの異なる概念があるんです。どれを使いたいですか?」とか、「ところで、Pandasのデータフレームになるって言うたけど、時々JSONLを受け取ることがあるんです。データフレームじゃないものを受け取った時、どうしたらええですか? フラグを立てた方がええですか?」みたいに聞いてくるんです。
これは奇妙な転換点になるかもしれません。指示を受け取るのは極めて上手いんやけど、実際にあなたが何を望んでいるのかを理解せなあかんのです。分からへんけど、それは面白い転換点になるかもしれません。
デイビッド: 逸話的に言うと、最近クロードに私をインタビューさせることが多くなってきました。これが情報を引き出そうとする具体的な方法なんです。
なぜかというと、私の頭から正しい情報のセットを引き出して、それをプロンプトに入れるのが一番難しい部分やと思うからです。何かを忘れへんようにするのが。
だから具体的にクロードに私をインタビューさせて、それをプロンプトに変えるってことを何度かやってきました。
アマンダ: そうやね。デザイナーが、デザインを望む人とどう対話するかについて話すのを聞くのを思い出します。
ある意味、これは「派遣会社から来た人」から、タスクやあなたの望むこと全てについてあなたの方がよく知っとる状況から変わるんです。だからその人に指示を与えて、エッジケースでどうすべきかとか、そういうことを全部説明するんです。
でも、実際に仕事をするために相談する専門家がいる場合は違います。デザイナーはデザインの領域をすごくよく知っとるから、すごくイライラすることがあるんです。
「そうやね。クライアントが来て、ただ『ポスターを作ってくれ、大胆にしてくれ』って言うただけなんです」って。私は「それは7000のことを意味しとるんやけど、いくつか質問させてもらってもええですか」みたいな感じです。
だから、これが派遣会社の従業員から、雇っとるデザイナーみたいな感じに変わるかもしれません。それは関係性の逆転です。
それが本当かどうかは分からへんし、両方が続く可能性もあると思いますが、これが「将来、プロンプトエンジニアリングはなくなるんやろうか?」って人々が言う理由かもしれません。
いくつかの領域では単にそうならへんかもしれません。モデルが本当に優秀になって、あなたの頭から情報を引き出して、そしたらタスクをこなせるようになるだけかもしれません。
アレックス: そうやね、それは本当に良い例えです。みんなの回答から1つの共通点が見えてきました。
将来的には、ユーザーからの情報引き出し、その情報を引き出すってことが、今よりもずっと重要になりそうです。既に皆さんは手作業でそれを始めとるみたいですね。
将来、企業側では、このプロンプト生成の概念が拡張されて、コンソールにもっと機能が追加されて、その企業の顧客からもっと情報を得られるようになるかもしれません。そうすればより良いプロンプトが書けるようになります。
クロードでは、単にテキストボックスに入力するんじゃなくて、完成した製品に向けてのこのガイド付きのやり取りみたいなものになるかもしれません。
そうやね、これは将来のかなり説得力のあるビジョンやと思います。デザインの例えは本当にそれをよく表しとると思います。
デイビッド: プロンプティングが今は教えることに似とるって考えとったんです。生徒に対する共感があって、彼らがどう考えとるか理解しようとして、本当に彼らに示そうとして、どこで間違えとるか理解しようとするみたいな。
でも、あなたが話しとる点では、スキルはほとんど内省のようになります。あなたが本当に何を望んでいるのかを考えて、モデルがあなたを理解しようとする感じです。
だから、モデルに自分を理解させることになるんです。あなたより賢い誰かに教えようとするんじゃなくて。
アマンダ: これが実は今の私のプロンプティングの考え方なんです。奇妙な感じやけど。
私のプロンプティングスタイルにはいろんなことがありますが、よくあるのは、哲学者がよくやることなんですが、新しい概念を定義することです。
私の考えでは、あなたが望むことを言葉にせなあかんのです。そして時々、私が望むことはかなりニュアンスがあるんです。
「良いチャートとは何か?」とか、普通は「何かを正解として採点すべき時はいつか?」みたいな。
だから、概念を発明して、「この概念はこういう意味です」って言うことがあります。時々、クロードと協力して概念を理解させることもあります。ただ、頭の中にあることを伝えようとしとるからです。
今のところ、モデルは我々にそうしようとはしてへんです。プロンプトでそうするように言わない限りは。だから将来的には、我々がそれをモデルのためにするんじゃなくて、モデルが我々からそれを引き出せるようになるかもしれません。
でも、面白いのは、時々人々が「哲学はプロンプティングにどう関係あるんですか?」って聞いてくることです。実は、ある意味ですごく役立つと思うんです。
哲学の文章を書くスタイルがあって、少なくとも私はこう教わったんですが、その考え方は...多分これは哲学におけるアンチ・バカ話デバイスなんです。
基本的に、あなたの論文や書くものは、教育を受けた一般人に理解できるべきやってことです。誰かがただあなたの論文を見つけて、読み始めて、全てを理解できるべきなんです。
全ての人がこれを達成するわけじゃないですが、少なくとも私が教わった分野の目標はそうでした。
だから、書く時に教育を受けた一般人のことを考えるのにすごく慣れとるんです。彼らは本当に賢いけど、このトピックについては何も知らへん。そういう形式のテキストを書くのに何年も費やしました。
それがプロンプティングにすごく良かったんです。「ああ、これに慣れとるな」って感じで。教育を受けた一般人がいて、トピックについては何も知らへん。そして、極めて複雑な考えを取り上げて、彼らに理解させる必要があるんです。
彼らを見下したりせえへんし、不正確なことは言わへんけど、私が意味することを極めて明確に彼らに伝えるような方法で物事を言わなあかんのです。プロンプティングはすごくそれに似とる感じがしました。
実際、我々が使うトレーニング技術は魅力的です。あなたが言うたように、人に「今言うたことをそのまま書いて」って言うんです。
学生によく言ってました。彼らが論文を書いて、私が「ここでおっしゃりたいことがよく分からへんのですが、あなたの主張を説明してもらえますか?」って言うたら、彼らはすごく説得力のある主張をしてくれるんです。
そしたら「それをそのまま書いてくれへん?」って言うんです。そしたら、それがしばしば素晴らしいエッセイになるんです。
だから、頭の中にあることを取り上げて、完全に理解したと感じるくらい十分に分析して、街から適当な人を連れてきて、あなたの頭の中身を彼らに外在化できるってのは、本当に面白い類似点やと思います。
それがプロンプティングの核心やと思います。
デイビッド: それが今まで聞いた中で、上手くプロンプトする方法の最高の要約かもしれません。実際、間違いなくそうやと思います。
アレックス: 「あなたの頭を外在化する」か。
デイビッド: そしたら締めくくりましょう。
アレックス: それがこの会話を締めくくるのに素晴らしい方法やと思います。みなさん、ありがとうございました。素晴らしかったです。