プロンプトエンジニアリングはトランザクション型プロンプトのためのもの
プロンプトエンジニアリングについて議論されるたびに、同じような混乱が繰り返し起きていることに気づきました。その混乱は、言語モデルの使い方が大きく分けて2つあることに起因していると考えています。インタラクティブプロンプトとトランザクショナルプロンプトです。プロンプトエンジニアリングが主に対象としているのはトランザクショナルプロンプトであり、この手法をインタラクティブプロンプトにそのまま当てはめようとすると、多くの混乱や否定的な反応が生まれます。
インタラクティブプロンプトとは、ChatGPTのように言語モデルと対話を重ねていく使い方です。モデルから曖昧な回答が返ってきても、それまでの文脈を活かして追加で説明を求めたり、適切な回答へと導いたりできます。また、インタラクティブプロンプトは基本的に人間が主体となって進めます。
トランザクショナルプロンプトでは、言語モデルをプログラミング言語の関数のようにより扱います。入力を与えて、欲しい出力を得るという考え方です。これは1回のプロンプトに限りません。複数のプロンプトを連鎖させたり、「エージェント」のような振る舞いをさせたりすることも含まれます。重要なのは、言語モデルを特定の課題に対してトランザクション的に、多くの場合は大量に、ソフトウェアによって駆動される形で利用しているという点です。
ここでは「prompting」「prompts」「language model」といった用語はすでにご存知であることを前提とします。これらの用語やプロンプトエンジニアリング全般について背景を知りたい方は、以前の記事Prompt Engineering vs. Blind Promptingをご覧ください。
プロンプトエンジニアリングの知識は、スタイルを問わずモデルから望む結果を引き出す力を理論上は高めてくれるため、どちらの使い方にも役立ちます。ただ、私はプロンプトエンジニアリングの主な効果はトランザクション的なユースケースでこそ発揮されると考えています。
プロンプトエンジニアリングとは、言語モデルから望む結果を、最も高い精度と最も低いコストで引き出すための取り組みです。こうした目標は、トランザクション的なユースケースにより適しています。
客観性と主観性
プロセスがインタラクティブかトランザクショナルかという区分だけでは、プロンプトエンジニアリングの価値をきれいに切り分けるには十分ではありません。もう一つの切り口として、客観性と主観性という軸が考えられます。
入力に対して客観的に正しい、あるいは「ほぼ正しい」と言える出力が得られるのであれば、プロンプトエンジニアリングはうまく機能します。客観的に正しい結果を持つ課題の例としては、情報抽出、分類、限定的なコード生成などが挙げられます。
一方で、入力に対して主観的にしか正しさを判断できない出力になる場合、プロンプトエンジニアリングの有用性は大きく下がります。主観的な結果の代表例は、アート生成や文章作成、セマンティック検索といったクリエイティブなタスクです。
アートを「エンジニアリング」して客観的に良い・悪いを決めることができないのと同じように、主観的なタスクにおいてLLMを「プロンプトエンジニアリング」して客観的な良し悪しを決めることも不可能です。もちろん、主観的なタスクでもプロンプトエンジニアリングによって出力が主観的に受け入れられる可能性を高めることはできますが、客観的なタスクと同じレベルの確実性や精度を得ることはできません。
もちろん、主観的なタスクでも望む結果を得るための有名な「プロンプトテンプレート」が数多く存在することを指摘する方もいるでしょう。たとえば、特定のスタイルのアートを安定して生成するためのテンプレートなどがあります。しかし、そうしたテンプレートにたどり着く過程は、エンジニアリングや科学的な実践というより、むしろ創造的なライティングのプロセスに近いものです。
私は「コード生成」を、客観的なタスクと主観的なタスクの両方の性質を併せ持つ例だと考えています。理論上、コード生成は客観的に正しくなり得ます。ソフトウェアの振る舞いについて十分に正確な仕様があれば、その仕様を満たすか満たさないかは客観的に判断できるからです。しかし現実には、そこまで厳密な仕様を持つソフトウェアはほとんどありません。そのため、コード生成のタスクが大きくなるほど主観的になります。逆に、タスクが小さいほど、テストケースや入力言語を正確に規定できる可能性が高まり、より客観的になります1。
客観的でトランザクション的なプロンプト
一般的に言えば、プロンプトエンジニアリングの知識があれば、どんなタスクであっても言語モデルから欲しい情報を引き出す力が誰でも高まります。ただし、インタラクティブプロンプトにおけるプロンプトエンジニアリングは、優れた「ググラー（Google検索の使い手）」になることに近いのに対し、トランザクショナルプロンプトにおけるプロンプトエンジニアリングは、データサイエンティストになることに近いと言えます。
プロンプトエンジニアリングは、LLMを決済やプロセス内の関数呼び出し、SaaSの呼び出しなど、プログラムが連携する他のあらゆるAPIと同様に、客観的で予測可能、かつトランザクション的なAPIへと変えようとする試みです。もちろん、言語モデルは決定的で100%信頼できる機械ではないため、その有用性やユースケースは異なってきます。
結論として、プロンプトエンジニアリングは言語モデルとのあらゆるプロンプトのやり取りに当てはまるわけではありません。より創造的で、データ駆動型でも体系的でもないやり取りも存在します。しかし同時に、エンジニアリング的な手法を適用することで最良の結果が得られるユースケースも言語モデルにはあります。両者は互いを否定することなく共存しています。
ここで一つ明確にしておきたいのが、この記事の執筆時点で台頭しつつある「エージェント」についてです。エージェントは言語モデルとの自動化された対話的なプロセスだと言うこともできます。厳密にはその通りです。しかし私の考えでは、エージェントの使い方は本質的にトランザクション的です。エージェントにタスクを与え、結果を待つという形であり、その結果が客観的に正しいかどうかは別として、そうした使い方です。高頻度でソフトウェアによって駆動されるというトランザクション的な性質を持つため、プロンプトエンジニアリングはエージェントにも適用できます。
脚注
コード生成はそれだけで一つのブログ記事になるほど大きなテーマですが、今後、言語モデルを使ってより大規模で複雑なソフトウェアのコードを生成する上で、仕様の曖昧さが最大の課題になると私は考えています。現在では、人間が書いた単体テストをパスするようにエージェントがコードを反復的に改善し、シンプルながら動作するプログラムを生成する例が見られます。将来は、テスト駆動開発（TDD）のムーブメントが再び活性化するかもしれません。もちろん、プログラム合成やプログラム仕様、プログラム証明は学術研究として非常に奥の深い領域ですので、そうした分野の知見が融合する可能性もあるでしょう。すでに融合が始まっているのかもしれませんが、私自身はその分野の研究を追えていません。いずれにせよ、今後は面白い展開が待っていると思います！ ↩