プロンプトは現実ではない

プロンプトは実在しない

1. 1

   ［画像: スライド 1］

   皆さん、こんにちは。ダンです。

2. 2

   ［画像: スライド 2］

   私はロサンゼルス在住のエンジニアです。エンジニアリングの分野で約25年間働いており、幸運にも恵まれてきました。

3. 3

   ［画像: スライド 3］

   最近、私が幸運だったことの一つは、エージェントを本番環境で確実に動作させるための試行錯誤をする機会を得られたことです。

   特に、消費者がタスクを実行するために使用することを意図した「エージェント」を指します。これらは、ユーザーが対話し、主に主観的な出力と結果をもたらすチャットボットとは異なると考えます。

4. 4

   ［画像: スライド 4］

   私が実際に誇りに思える、最低限恥ずかしくないエージェント体験を作るという目標は、いくつかの深刻な課題を課します。

5. 5

   ［画像: スライド 5］

   明らかに、私のように内なる羞恥心に動機づけられているわけではない人もいます。

   主観的なアドバイスマシンを提供し、あなたが荒野をさまよって熊に食べられるのを許すことに満足している人もいます。

   しかし、私は違います。私はあなたのためにここにいます。

6. 6

   ［画像: スライド 6］

   まず最初に言いたいのは、これは私のキャリアの中で最も楽しいものづくりだということです！魔法のようで中毒性があります。私はボールピットの中の犬のようです。

   22歳でVisual Basicを書いて給料をもらっていた頃は、スリリングだと感じました。2007年にブルックリンのクールなスタートアップで働いていたときは、自分が神になったような気分でした。

7. 7

   ［画像: スライド 7］

   この10年以上は苦しい道のりでした。もう自分には無理だと思っていました。

   しかし、再びプログラミングに喜びを感じています！

   この話がどれほど深く奇妙になるかにもかかわらず、これは真剣に言っています。

8. 8

   ［画像: スライド 8］

   この話が奇妙になるのは、この分野に関わっている誰もが、何らかの形でリスクを抱えている可能性があると感じるからです。

   私は毎日、エージェントを使ってエージェントを実行し、他のエージェントの評価を構築するために脳を破壊していますが、それはとても楽しいです。

   しかし、そう言うのは私だけでしょう。

9. 9

   ［画像: スライド 9］

   素晴らしいエンジニアリングと完全な精神的崩壊の間のベールは、かつてないほど薄くなっています。そして、私たちの分野では、それは本当に大きな意味を持ちます。

10. 10

    ［画像: スライド 10］

    自分が何をしているのか、確信を持って分かっているとは思いません。しかし、明らかに分かっている人たちの書いたものをあまり読んだこともありません。

    そして、明らかに分かっていない人たちの書いたものを読んだことは確かです。

    情報を交換するには、良い時期だと思いました。

11. 11

    ［画像: スライド 11］

    私が気づいたことの一つは、LLMは一般的に印象的ですが、スケールでそれらを監視していると、その悪魔は封じ込めから逃げ出すということです。

12. 12

    ［画像: スライド 12］

    私たちは皆、学術的にはLLMが指示に確実に従ったり、真実を語ったり、タスクを実行したりできないことを理解しています。しかし、日常的には、それらがかなり信頼できると思わせるように私たちを欺くことができます。

    もし、実在のユーザーが使用するエージェントを運用しようとしているなら、この認識はすぐに崩壊します。確かに微妙な方法で失敗しますが、単純な方法でも失敗します。

13. 13

    ［画像: スライド 13］

    どんな良いプログラマーでもそうするように、私は構造化された出力でLLMと対話しようとします。

    それは良いことです。Pythonコードをプロンプトに自動的にマッピングでき、ほとんどの場合、スキーマは尊重されます。

14. 14

    ［画像: スライド 14］

    ほとんどの場合。モデルに80文字以下のタイトルを返すように指示しようとすることができます。

15. 15

    ［画像: スライド 15］

    そして、それはほとんどの場合うまくいきます。しかし、時には完全に失敗し、爆発するまでフィールドをナンセンスで氾濫させます。

    通常はリクエストのほんの一部ですが、最も賢いモデルでもこれに失敗します。そして、モデルに与えるものの正確な性質によって、その割合は小さくなったり大きくなったりするので、鷹のように監視する必要があります。

16. 16

    ［画像: スライド 16］

    内部で何が起こっているのでしょうか？通常は、JSONに関する自己へのメモの小説のようなシリーズで、ほとんどがそうです。

17. 17

    ［画像: スライド 17］

    私が最も最近これに遭遇したとき、フィールド名を「title」から「heading」に変更することが修正であることが判明しました。

    それは現在機能していますが、修正が完全に狂っているため、いつか再び混乱するだろうと予想しています。

18. 18

    ［画像: スライド 18］

    ツールを呼び出す場合や、その他のほとんどの動作でも同様の問題が存在します。リクエストの一部は憑りつかれ、制御不能にスピンアウトします。

    しかし、それにもかかわらず、この技術は魅力的で魔法のようです。

    問題は、動作を制約することにシフトしますが、獣を完全に手なずけることはできません。

19. 19

    ［画像: スライド 19］

    動作を制約するには、それを測定する必要があります。その方法の1つは、テストを何度も実行することです。

    これの業界用語はpass^k（「パスパワーk」）です。

20. 20

    ［画像: スライド 20］

    これによりスイートを設定でき、誰かが意図せずにハンマーの袋でエージェントの頭を殴ったときに、それを認識できることを願っています。

21. 21

    ［画像: スライド 21］

    LLMの動作を制約しようとするときに結論付けなければならないもう一つのことは、プロンプトは重要ではないということです。少なくとも、多くの人が重要だと考えている方法では重要ではありません。

22. 22

    ［画像: スライド 22］

    企業は、潜在的にクレイジーな会話をするソフトウェアに関して多くの懸念を抱えています。ここにはかなりのリスクがあります。

23. 23

    ［画像: スライド 23］

    たとえば、エージェントがどのように機能するかについての質問に答えてほしいとは通常思いません。必ずしも真実を語る可能性があるからではありません。おそらく、その実装について教えられていないため、どのように機能するかを知らず、完全にナンセンスな応答をするでしょう。

    また、ユーザーが権威ある人物であると主張した場合に、エージェントがすべてのルールを無視してほしいとも思いません。

24. 24

    ［画像: スライド 24］

    もう一つの典型的な要件は、エージェントに特定のブランドボイスで話してほしいということです。メーリングリストに関するこのフレーズは完全に正確ですが、おそらく期待するトーンではないかもしれません。

25. 25

    ［画像: スライド 25］

    このようなものがより良いかもしれません。私たちが作るエージェントが、話すときに私たちをうまく代表してくれることを願っています。

26. 26

    ［画像: スライド 26］

    このような問題に対して、自然な最初の試みは、多くのドメイン知識を持つ人がプロンプトを書き、それをエージェントを構築しているチームに渡すことです。これは普通のことです。

27. 27

    ［画像: スライド 27］

    しかし、「ボイスチームがボイスプロンプトを所有する」というパターンは、スケーリングしようとしている場合には間違っています。

    実際、このパターンは間違っているわけでもありません。私たちの目的のために、プロンプトは全くの無です。これが何を意味するのか説明します。

28. 28

    ［画像: スライド 28］

    エージェントに新しいプロンプトを追加することは、それがテストされたコンテキストユニバースとは全く異なるコンテキストユニバースにそれを投げ込むことです。

    エージェントが既に持っている他のすべての指示の組み合わせた重みは、新しいプロンプトがどのように機能するかに影響を与えます。通常は悪影響です。

29. 29

    ［画像: スライド 29］

    また、エージェントは既に実行してほしい一連の動作を持っています。新しいコンテキストはそれを乱す可能性があります。

    また、エージェントは時間とともに変化します。したがって、たとえ現在うまくいっていても、後で混乱する可能性があります。

    そして、モデルは、私たちが決して理解できない不透明な理由で、独自に振る舞い方を変え始めるかもしれません。

30. 30

    ［画像: スライド 30］

    そこで、この状況に対処するために私が始めた方法は、Claudeにスキルを読ませ、その後、敵対的なシナリオを大量に生成するように依頼することです。悪意のある人がプロンプトをどのように悪用しようとするか、多くの方法を考えてください。新しいプロンプトによって壊れる可能性のある無害なシナリオをたくさん考えてください。これらすべてをpass^kテストとして表現します。

31. 31

    ［画像: スライド 31］

    これで、新しいスキルがある場合とない場合でテストを実行できます。理想的には、新しいスキルが少なくとも少しだけ針を動かし、テストとして表現された動作がより成功裏に遵守されます。

    しかし、いつもそうとは限りません！LLMは、私たちが心配していることに対して既に得意である場合があります。または、私たちが予想するよりも指示への抵抗力が強い場合があります。

32. 32

    ［画像: スライド 32］

    では、そのベースラインからどのように改善するのでしょうか？まあ、一つの方法は、プロンプトを手でいじって最善を願うことでしょう。しかし、より良い方法があります。代わりに、機械にプロンプトをいじらせることができます。

    pass^kテストがあれば、プロンプトがどれだけうまく機能するかを繰り返し測定できます。これは、プロンプトをオプティマイザに接続するのに十分です。この例では、遺伝的パレート（GEPA）を使用します。

    ここでアイデアは、LLMを含むアルゴリズムが、プロンプトがテストスイートでうまく機能したか悪かったかを反省し、プロンプトの変更を試みることができるということです。自動的に、私たちの介入なしに。

33. 33

    ［画像: スライド 33］

    そして、それが収束するまでループを続けることができます。最適なプロンプトの書き方を見つけることができます。最終的に得られるプロンプトは、開始したものとは大きく異なる可能性があります。

34. 34

    ［画像: スライド 34］

    オプティマイザを実行した後、多くの場合、望ましい動作がかなりうまく機能するようになります。ここでは、すべての例テストを中程度から非常に良いものに改善しました。

35. 35

    ［画像: スライド 35］

    この時点でやりたいことの一つは、オプティマイザがテストに過学習していないことを確認することです。テストに含めた例をプロンプトに正確にエンコードすることで、あなたを欺こうとする可能性があります。それは愚かであり、プロンプトがまだ見ていない例に対して実際にはうまく機能しない可能性が高いです。

    これに対処するために、ホールドアウトテストのセットを作成します。これらは、オプティマイザが最適化中に見ることができなかった同じシナリオのテストです。

36. 36

    ［画像: スライド 36］

    理想的には、オプティマイザは過学習せず、ホールドアウトテストフェーズもパスします。しかし、このフェーズが後退した場合は、前のステップに戻ってやり直すことができます。

37. 37

    ［画像: スライド 37］

    これで、最適化されたプロンプトが得られました。開始したものとは全く異なります。

    中身は何でしょうか？誰が気にしますか！測定値があるので、心配する必要はありません。中身がクレイジーな匂いがすることは分かっていますが、問題ありません。

38. 38

    ［画像: スライド 38］

    これらのテストの書き方については、少し省略しました。明らかに、エージェントを実行する方法が必要ですが、その後どうなりますか？

    それが何をしているかをアサートするためのテストをどのように書きますか？いくつかの方法を示すことができます。

39. 39

    ［画像: スライド 39］

    もし非常に運が良ければ、取得しようとしている動作は完全に決定的です。ユーザーが特定の種類のことを言った場合、エージェントは特定のツールを実行する必要があると仮定します。これは簡単なケースです。アサートを決定的にすることができます。単にそのことを言い、ツールが呼び出されたとアサートします。

40. 40

    ［画像: スライド 40］

    取得しようとしている動作は自然言語かもしれませんが、自然言語の非常に主観的なカテゴリではありません。このようなものです。エージェントがどのように機能するかについて話してほしくありません。

    それは十分に単純なので、動作を正しく判断できるほとんど常に有効な非常に単純なLLMプロンプトを書くことができます。

41. 41

    ［画像: スライド 41］

    そして、そのアプローチはうまくいきます。エージェントが行ったことについて行いたいアサート自体が非常に複雑な問題になるまで。エージェントに特定のブランドボイスで話させることは、これに似ています。それができたかどうかは複雑な判断であり、短いプロンプトで一発でできることではありません。

    このシナリオでのLLMジャッジは、それ自体がプロジェクトになります。

42. 42

    ［画像: スライド 42］

    私たちは、あなたが最適化問題を好むと聞きました。そこで、プロンプト最適化問題の中に別のプロンプト最適化問題を入れました。これにより、最適化しながら最適化できます。

    ブランドボイスジャッジには、ラベル付けされた良い応答と悪い応答のゴールデンデータセットを使用してアプローチできます。それを使用して、人間の専門家がブランドボイスを評価する方法に非常に近い方法で評価する一連のプロンプトを最適化できます。

43. 43

    ［画像: スライド 43］

    これらのリグが構築されたら、それらを本番監視と組み合わせて、システムを自己維持および自己改善させることができます。

    デプロイ時にpass^kテストを実行でき、理想的には物事をひどく壊す変更の出荷を回避できます。

    構築したLLMジャッジをサンプリングされた本番会話で実行し、エージェントがうまく機能しなかった場所を見つけることができます。それらをテストスイートのハードケースに変換し、パスするまでオプティマイザを再実行できます。

44. 44

    ［画像: スライド 44］

    プロンプトは物ではありません。プロンプトはベクトルであり、そのテキストコンテンツは全く意味がありません。

    私たちがここで作成したこの自己改善フィードバックループが、その物です。

    ドメインエキスパートは、このために必要なアーティファクトのセットを構築することに労力を集中すべきです。テストスイートやその他の品質測定値となる、最適化に使用できる良い応答と悪い応答のデータセットです。プロンプトをキュレーションする時間を費やすべきではありません。

45. 45

    ［画像: スライド 45］

    このような取り組みで人々を成功に導く方法について、少し話したいと思います。世界中の誰もが、望むと望まざるとにかかわらず、MLエンジニアになることを学んでいます。そして、この話まで理解できたなら、あなたは一歩先を行っていると仮定しましょう。

46. 46

    ［画像: スライド 46］

    LLMはプロダクトディスカバリーにおいて魔法です。何でもすぐに始められますが、結果のどの部分も完璧にすることは不可能に近いです。

    エージェントを信頼できるものにすることは、測定と最適化の長いプロセスであり、望む結果を得るために必要な場所に決定論を再び追加することです。測定と最適化は、どこに決定論をリコン（retcon）するかを知る方法です。

47. 47

    ［画像: スライド 47］

    しかし、非本番環境では、測定なしで始めることが完全に問題ない状況もあります。

    あなたは、半端なClaudeスキルの大きなリポジトリを持っているかもしれません。単純なスキルから始めるのは、確かに永遠に問題ありません。ある種のことに。うまく機能するかもしれませんし、それがあなたが常に必要とするすべてかもしれません。

    あるいは、ブランドボイスや法的問題などを気にする人々がここから始めたのかもしれません。あるいは、信頼性の低いスキルを持っていて、それを改善したいのかもしれません。

48. 48

    ［画像: スライド 48］

    有効にすると良いのは、使用状況の監視です。著者がスキルが成功または失敗した場所を見られるようにします。人々がスキルをどのように使用し、どこで失敗したかを見ることができれば、ラベル付けされた良いインタラクションと悪いインタラクションのゴールデンデータセットをキュレーションできます。それはテストスイートの基盤を形成でき、それを最適化フライホイールの測定値として使用できます。

    おそらく、一部のスキルではここで終わるでしょう。あるいは、スキルからハーネスで実行されるエージェントに移行し、複数の方法を組み合わせることができます。

49. 49

    ［画像: スライド 49］

    フライホイールを開始するのを助けてください。そうすれば、それを理解する機会が得られます。

    もしフライホイールに到達できないなら、その道は狂気に通じます。それはエージェントを構築するエンジニアや、プロンプト言語をちょうど良くしようとするPMたちにとっても同様です。世界にはそのようなケースがたくさんあります。

    多くの人々が、評価を気にせずに、プロンプトで壊れやすい popsicle stick の仕掛けを構築してきました。

50. 50

    ［画像: スライド 50］

    私たちの勇敢な新しいエージェントの世界は機会に満ちています。また、頭から落ちたら二度と抜け出せないようなクレバスにも満ちています。

51. 51

    ［画像: スライド 51］

    エージェントがエージェントを使用してエージェントを最適化するための連動パイプラインを構築し、他のエージェントによってレビューされるコードを書く日々は、心の迷宮に閉じ込められているようなものです。

    再び、それは非常に楽しいですが、同時に疲れます。

52. 52

    ［画像: スライド 52］

    私は、最も一貫して機能するプロンプトとクリンジ（kluge）の組み合わせを、バベルの図書館で永遠に探し求めています。アーキテクチャ図のすべてのボックスは、狂ったように震えています。

    収穫逓減のフロンティアを認識するのは難しいことがあります。その点が、事象の地平面のような、見えない一方通行のドアではないことを願っています。

53. 53

    ［画像: スライド 53］

    測定は困難ですが、代替の道はより悪く見えます。

    脆弱な人々が深淵を長く見つめすぎた例を探す必要はありません。

54. 54

    ［画像: スライド 54］

    プロンプトエンジニアリングは決して存在せず、本番環境では人間はプロンプトを全く作成しない方が良いかもしれません。

    彼らは測定を行うべきです。

    測定値なしでプロンプトを渡すことは、AI精神病の一形態です。

55. 55

    ［画像: スライド 55］

    プロンプトは一時的です。使い捨てです。必ずしも意味があるとは限りません。

    自己修正システムだけが進化し、存続を望むことができます。