我注意到，每當討論到 Prompt Engineering(提示工程) 時，總會出現一個常見的困惑點，我認為這種困惑源於使用語言模型的兩種截然不同的方式：互動式提示與交易式提示。Prompt Engineering 主要是關於交易式提示，而當人們試圖將其套用到互動式提示時，往往會產生相當多的困惑或負面看法。

互動式提示是一種類似 ChatGPT 風格的提示方式，你與語言模型進行的更像是對話。如果模型回傳了不夠清楚的回應，你可以利用已有的上下文進行釐清，並引導模型走向正確的回應。此外，互動式提示主要由人類來主導。

交易式提示則是將語言模型更像是程式語言中的一個函式：你給予它一些輸入，並期望得到某些輸出。這並不限於單一提示，你可以在此串連多個提示或執行類似「代理人」的行為。重點在於，你是以交易式的方式，為了某個非常具體的問題而使用語言模型，通常是大量且由軟體所驅動的。

Prompt Engineering 對兩者都有幫助，因為理論上，具備 Prompt Engineering 的知識應該能讓人不論採用哪種風格，都更有效地從模型獲得想要的結果。然而，我認為 Prompt Engineering 的主要效益在於交易式的使用情境。

Prompt Engineering 的核心在於以最高的準確度與最低的成本，從語言模型獲得期望的結果。這些目標更適用於交易式的使用情境。

客觀性 vs. 主觀性

僅以流程是互動式還是交易式來區分，並不足以細膩地劃分 Prompt Engineering 的價值。另一個可以區分的面向是客觀性與主觀性。

如果輸入能夠產生客觀正確（或者我甚至會說「大致正確」）的輸出，那麼就可以成功地應用 Prompt Engineering。具有客觀正確結果的問題範例包括：資訊擷取、分類、有限形式的程式碼生成等。

然而，如果輸入產生的是主觀上正確的結果，那麼 Prompt Engineering 的用處就小得多。主觀結果的最佳範例是創意類任務，例如藝術生成、寫作、語意搜尋等。

就像你無法「設計」藝術使其客觀上是好或壞一樣，你也無法在主觀任務上對 LLM 進行「提示工程」使其客觀上變得好或壞。你可以對主觀任務進行提示工程，以提高其產出被主觀接受的機率，但你無法達到與客觀任務相同的確定性或準確度。

當然，你可能會指出，針對主觀任務存在許多知名的「提示範本」，有助於達成期望的結果。舉例來說，已有範本能夠穩定地生成特定風格的藝術作品。然而，要得出這些提示範本，與其說是工程或科學實作，不如說更像是一個創意寫作的過程。

我將「程式碼生成」視為同時兼具客觀與主觀任務的例子。理論上，程式碼生成可以是客觀正確的：如果軟體對其行為有足夠精確的規格，那麼就可以客觀地說該軟體通過或未通過規格。在現實中，幾乎沒有軟體具備如此程度的明確性。因此，程式碼生成的任務越大，就越主觀。相反地，程式碼生成的任務越小，就越有可能精確地指定測試案例或輸入語言，也就越客觀¹。

客觀的交易式提示

一般而言，不論手邊的任務為何，了解 Prompt Engineering 都能讓任何人更有效地從語言模型中擷取所需的資訊。然而，用於互動式提示的 Prompt Engineering 比較像是成為一位有效率的「Googler」（Google 搜尋使用者），而用於交易式提示的 Prompt Engineering 則更接近於成為一位資料科學家。

Prompt Engineering 試圖將 LLM 轉變為一個客觀、可預測、交易式的 API，就像程式可能介接的任何其他 API，例如付款、在程式內函式呼叫、SaaS 呼叫等。當然，語言模型並非一台決定性的、100% 可靠的機器，因此其實用性與使用情境必然有所不同。

總結來說，Prompt Engineering 並不適用於與語言模型的所有提示互動。有些互動更具創意，較少由資料驅動或講求方法。但同樣地，語言模型也有一些使用情境可以套用工程方法來獲得最佳結果。兩者並存，互不否定。