プロンプトエンジニアリングが議論されるたびに繰り返し生じる混乱があることに気づいたが、その混乱は言語モデルの使い方が本質的に異なる2つあることに起因していると考えている。すなわち、インタラクティブなプロンプティングとトランザクショナルなプロンプティングだ。プロンプトエンジニアリングは主にトランザクショナルなプロンプティングに関するものであり、個人がそれをインタラクティブなプロンプティングに応用しようとしたときに、少なからぬ混乱や否定的な反応が生まれる。

インタラクティブなプロンプティングとは、ChatGPTのようなスタイルで、言語モデルとより対話するような使い方だ。モデルが不明瞭な回答を返してきても、すでにある文脈を利用して明確化を求めたり、正しい回答へとモデルを導いたりできる。さらに、インタラクティブなプロンプティングは主に人間が主導する。

トランザクショナルなプロンプティングでは、言語モデルをプログラミング言語における関数のようにより扱う。何らかの入力を与え、何らかの出力を期待するのだ。これは単一のプロンプトに限らない。プロンプトを連鎖させたり、「エージェント」のような振る舞いをさせたりすることも含まれる。重要なのは、非常に具体的な問題に対して、通常は大量に、ソフトウェアによって駆動される形で、言語モデルをトランザクション的に扱っているという点だ。

プロンプトエンジニアリングの知識は、スタイルを問わずモデルから望む結果を得る際の効果を理論上高めるはずなので、どちらの使い方にも役立ちうる。しかし、プロンプトエンジニアリングの主な恩恵は、トランザクショナルなユースケースにあると考えている。

プロンプトエンジニアリングとは、言語モデルから最も高い精度と最も低いコストで望む結果を得ることだ。これらの目標は、トランザクショナルなユースケースにより適合する。

客観性 vs. 主観性

プロセスがインタラクティブかトランザクショナルかという性質だけでは、プロンプトエンジニアリングの価値をきれいに切り分けるにはニュアンスが不足している。もう一つの切り口として、客観性と主観性という次元がある。

客観的に正しい（あるいは「ほぼ正しい」とさえ言える）出力が得られるような入力がある場合、プロンプトエンジニアリングはうまく適用できる。客観的に正しい結果を持つ問題の例としては、情報抽出、分類、限定的な形態のコード生成などが挙げられる。

しかし、主観的に正しい何かを生み出す入力の場合、プロンプトエンジニアリングははるかに有用性が低くなる。主観的な結果の最たる例は、アート生成、文章作成、セマンティック検索といった創造的なタスクだ。

アートを客観的に良いとか悪いとか「エンジニアリング」できないのと同じように、主観的なタスクにおいてLLMを「プロンプトエンジニアリング」して客観的に良いとか悪いにすることは不可能だ。主観的なタスクをプロンプトエンジニアリングして、出力結果が主観的に受け入れられる可能性を高めることはできるが、客観的なタスクと同じレベルの確実性や正確性を得ることはできない。

もちろん、主観的なタスクにおいても、望む結果を得るのに役立つよく知られた「プロンプトテンプレート」が数多く存在することを指摘する人もいるだろう。例えば、特定のスタイルのアートを安定的に生成するためのテンプレートが存在する。しかし、そうしたプロンプトテンプレートにたどり着く過程は、エンジニアリングや科学的な実践というよりも、むしろ創造的なライティングのプロセスに近い。

私は「コード生成」を、客観的タスクと主観的タスクの両方の例だと考えている。理論上、コード生成は客観的に正しくなりうる。ソフトウェアの振る舞いについて十分に正確な仕様があれば、その仕様に合格するか否かを客観的に判断できるからだ。現実には、ほとんどすべてのソフトウェアがそこまでの具体的さを持っていない。したがって、コード生成のタスクが大きくなればなるほど、より主観的になる。逆に、コード生成のタスクが小さくなればなるほど、テストケースや入力言語を正確に規定できる可能性が高まり、より客観的になる¹。

客観的でトランザクショナルなプロンプティング

一般的に、プロンプトエンジニアリングの知識があれば、目の前のタスクが何であれ、誰でも言語モデルから望む情報を引き出す能力が高まる。ただし、インタラクティブなプロンプトにおけるプロンプトエンジニアリングは、優れた「ググラー」（Google検索ユーザー）であることに近い一方で、トランザクショナルなプロンプトにおけるプロンプトエンジニアリングは、データサイエンティストであることに近い。

プロンプトエンジニアリングは、LLMを、決済やプロセス内関数呼び出し、SaaS呼び出しなど、プログラムが連携する他のあらゆるAPIと同様に、客観的で予測可能かつトランザクショナルなAPIにしようとする試みだ。もちろん、言語モデルは決定論的で100%信頼できる機械ではないため、その有用性やユースケースは異ならざるを得ない。

結論として、プロンプトエンジニアリングは言語モデルとのあらゆるプロンプトのやり取りに当てはまるわけではない。より創造的で、データ駆動型でも体系的でもないやり取りも存在する。しかし同様に、言語モデルの中には、エンジニアリングの方法論を適用することで最良の結果が得られるユースケースも存在する。どちらも互いを否定することなく共存している。