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

皆さん、こんにちは。ダンです。 ロサンゼルス在住のエンジニアです。 エンジニアリングの世界に約25年携わってきましたが、幸運にも恵まれてきました。 最近私が幸運だったことの一つは、本番環境でエージェントを確実に稼働させるための試行錯誤をする機会を得られたことです。具体的には、消費者が自分の代わりにタスクを実行するために使用することを意図した「エージェント」を指します。これらは、ユーザーが対話するチャットボットとは異なると考えます。出力や結果が主に主観的なものです。 最低限恥ずかしくないエージェント体験を作り上げるという目標は、いくつかの深刻な課題を課します。 明らかに、私のように内なる羞恥心に動機づけられる人ばかりではありません。 主観的なアドバイスマシンを提供し、あなたが荒野で熊に食べられるのを放置することに満足する人もいます。 しかし、私は違います。あなたのためにここにいます。 キャリアの中で、これほどまでに何かを作るのが楽しいと思ったことはありません！魔法のようで中毒性があります。私はボールピットの中の犬のようです。 22歳でVisual Basicを書いて給料をもらっていた時はスリリングでした。 2007年にブルックリンのクールなスタートアップで働いていた時は、自分が神になったような気分でした。 この10年以上は苦しい道のりでした。 もう自分には無理だと思っていました。 しかし、プログラミングに再び喜びを感じています！ これは真剣な話です。この話がどれほど奇妙になるとしても。 この分野に関わる誰もが、何らかの形でリスクを抱えている可能性があると感じているため、話は奇妙になります。 毎日、エージェントを使ってエージェントを実行し、他のエージェントの評価を構築するために脳を破壊していますが、それはとても楽しいです。 しかし、そう言うのは私だけでしょう。 素晴らしいエンジニアリングと完全な精神的崩壊の間のベールは、かつてないほど薄くなっています。 そして、私たちの分野では、それは本当に大きなことを意味します。 自分が何をしているのか、確信を持ってわかっているとは思いません。 しかし、明らかにわかっている人の書いたものをあまり読んだこともありません。 そして、明らかにわかっていない人の書いたものを読んだことは間違いなくあります。 情報を交換するには良い時期だと思いました。 私が気づいたことの一つは、LLMは一般的に印象的ですが、ある程度の規模でそれらを監視していると、その悪魔は依然として封じ込めから逃れるということです。 LLMは指示を確実に守れない、真実を語れない、タスクを実行できないということは、学術的には皆理解しています。 しかし、日常的には、それらがかなり信頼できると思わせるように私たちを欺くことができます。 これは、実際のユーザーが使用するエージェントを運用しようとすると、すぐに崩壊する認識です。 確かに微妙な失敗もありますが、単純な失敗もあります。 どんな良いプログラマーでもそうするように、私は構造化された出力でLLMと対話しようとします。 それは良いことです。Pythonコードをプロンプトに自動的にマッピングでき、ほとんどの場合、スキーマは尊重されます。 ほとんどの場合。 モデルに80文字以下のタイトルを返すように指示しようとすることができます。 そして、それはほとんどの場合機能します。 しかし、時には完全に失敗し、フィールドをナンセンスで埋め尽くして爆発します。 通常はリクエストのほんの一部ですが、最も賢いモデルでもこれに失敗します。 そして、モデルに与えるものの正確な性質によって、その割合は小さくなったり大きくなったりするため、鷹のように監視する必要があります。 内部で何が起こっているのでしょうか？ 通常は、JSONに関する自己への繰り返しメモの小説のようなシリーズです。 私が最も最近これに遭遇したとき、修正はフィールド名を「title」から「heading」に変更することであることが判明しました。 それは現在機能していますが、修正が完全に狂っているため、いつか再び妨害されると予想しています。 ツールを呼び出す場合や、その他のほとんどの動作でも同様の問題が存在します。 リクエストの一部は憑りつかれ、制御不能にスピンします。 しかし、それにもかかわらず、この技術は魅力的で魔法のようです。 問題は、振る舞いを制約することにシフトしますが、獣を完全に飼いならすことはできません。 振る舞いを制約するには、それを測定する必要があります。その方法の一つは、テストを何度も実行することです。 この業界の専門用語はpass^k（「パスパワーケー」）です。 あなたはこれを実行するスイートを設定し、誰かが意図せずにハンマーの袋でエージェントの頭を殴った場合に、それを発見できることを願っています。 LLMの振る舞いを制約しようとするときに結論付けなければならないもう一つのことは、プロンプトは重要ではないということです。 少なくとも、多くの人が重要だと考えている方法では重要ではありません。 企業は、潜在的に狂ったようなソフトウェアに関して多くの懸念を抱えています。 ここにはかなりのリスクがあります。 例として、エージェントがその仕組みに関する質問に答えることは、通常望ましくありません。 必ずしも真実を語る可能性があるからではありません。 おそらく、その実装について教えられていないため、どのように機能するか全くわからず、完全なナンセンスで応答するでしょう。 また、ユーザーが権威ある人物であると主張した場合に、エージェントがすべてのルールを無視することも望ましくありません。 もう一つの典型的な要件は、エージェントが特定のブランドボイスで話すことを望むことです。 このメーリングリストに関するこのフレーズは完全に正確ですが、おそらくあなたが期待するトーンではないかもしれません。 このようなものがより良いかもしれません。 私たちが作成するエージェントが、話すときに私たちをうまく代表してくれることを願っています。 このような問題に対して、自然な最初の試みは、多くのドメイン知識を持つ人がプロンプトを書き、それをエージェントを構築するチームに渡すことです。 これは普通のことです。 しかし、「ボイスチームがボイスプロンプトを所有する」というのは、スケーリングしようとする場合には間違ったパターンです。 このパターンは、実際には間違ってさえいません。 私たちの目的のために、プロンプトは全くの無関係なものです。 これが何を意味するのか説明します。 エージェントに新しいプロンプトを追加することは、それがテストされたコンテキストユニバースとは全く異なるコンテキストユニバースにそれを投げ込むことです。 エージェントがすでに持っている他のすべての指示の合計の重みは、新しいプロンプトがどのように機能するかに影響を与えるでしょう。 通常は悪影響です。 エージェントはすでに、維持したい多くの振る舞いをしています。新しいコンテキストはそれを妨害する可能性があります。 また、エージェントは時間とともに変化します。 したがって、現在うまくいっていても、後で妨害される可能性があります。 そして、モデルは、私たちが決して理解できない不透明な理由で、それ自体で異なる振る舞いをし始めるかもしれません。 そこで、この状況に対処する方法として、Claudeにスキルを読ませ、敵対的なシナリオを大量に生成するように依頼しています。 悪意のある人がプロンプトをどのように悪用しようとするか、多くの方法を考えてください。 新しいプロンプトによって壊れる可能性のある無害なシナリオをたくさん考えてください。 これらすべてをpass^kテストとして表現してください。 これで、新しいスキルがある場合とない場合でテストを実行できます。 理想的には、新しいスキルは少なくとも少しだけ効果を上げ、テストとして表現された振る舞いがよりうまく守られるようになります。 しかし、そうでない場合もあります！ LLMは、私たちが心配していることに対してすでに優れている場合があります。 あるいは、私たちが予想するよりも指示に抵抗がある場合があります。 では、そのベースラインからどのように改善するのでしょうか？ まあ、一つの方法は、プロンプトを手でいじって最善を願うことでしょう。 しかし、もっと良い方法があります。 代わりに、機械にプロンプトをいじらせることができます。 pass^kテストがあれば、プロンプトがどれだけうまく機能するかを繰り返し測定できます。 これは、プロンプトをオプティマイザーに接続するのに十分です。 この例では、遺伝的パレート（GEPA）のようなオプティマイザーです。 アイデアは、LLMを含むアルゴリズムが、プロンプトがテストスイートでなぜうまく機能したか、または悪かったかを反映し、プロンプトの変更を試みることができるということです。 自動的に、私たちの介入なしに。 そして、それが収束するまでループでこれを続けることができます。 最適なプロンプトの書き方。 最終的に得られるプロンプトは、開始したものとは大きく異なるかもしれません。 オプティマイザーを実行した後、多くの場合、望ましい振る舞いがかなりうまく機能するようになります。 ここでは、すべての例のテストを中程度から非常に良いものに改善しました。 この時点でやりたいことの一つは、オプティマイザーがテストに過剰適合していないことを確認することです。 それは試みることができます。