Prompt Engineering is for Transactional Prompting

Mitchell Hashimoto

提示工程是為了交易式提示

原文由 Mitchell Hashimoto 發布,訂閱此部落格

我注意到每當討論到提示工程時,總會出現一個反覆出現的困惑點,而我認為這種困惑源自於使用語言模型的兩種截然不同的方式:互動式提示交易式提示。提示工程主要是關於交易式提示,而當人們試圖將它套用到互動式提示上時,就會產生大量的困惑或負面看法。

互動式提示就是像 ChatGPT 那樣的提示方式,你更像是在跟語言模型對話。如果模型回傳了不夠清楚的回應,你可以利用既有的上下文來釐清並引導模型走向正確的回應。此外,互動式提示主要是由人來主導。

交易式提示則是把語言模型更當作程式語言中的一個函式:你給它一些輸入,並期望得到某種輸出。這並不限於單一提示,你也可以在此串連多個提示或執行類似「agent」的行為。重點在於,你是以交易的方式,為了解決某個非常具體的問題而使用語言模型,通常是大規模、高頻率地使用,並且由軟體來驅動。

我假設你對「prompting」、「prompts」、「language model」等詞彙已經很熟悉。如果你想更了解這些詞彙以及提示工程的整體背景,請參考我之前的文章 Prompt Engineering vs. Blind Prompting

提示工程對兩者都有幫助,因為理論上,具備提示工程的知識應該能讓人不論用哪種風格,都更有效地從模型中獲得想要的結果。不過,我認為提示工程最主要的價值還是在於交易式的使用情境。

提示工程的核心在於以最高的準確度與最低的成本,從語言模型中取得想要的結果。這些目標更適合交易式的使用情境。


客觀與主觀

單純以互動式或交易式來區分流程的性質,還不足以細緻地劃分出提示工程的價值。另一個可以切分的維度是客觀主觀

如果一個輸入能夠產生客觀正確(或者我甚至會說「大致正確」)的輸出,那麼就可以成功地套用提示工程。具有客觀正確結果的問題範例包括:資訊擷取、分類、有限形式的程式碼生成等。

然而,如果一個輸入產生的是主觀上才算正確的結果,那麼提示工程的用處就小得多。主觀結果的最佳例子就是創意性任務,例如藝術生成、寫作、語意搜尋。

就像你無法「工程化」地讓藝術變得客觀上好或不好一樣,你也不可能在主觀任務上對 LLM 進行「提示工程」,使其達到客觀上的好或不好。你可以對主觀任務進行提示工程,以提高最終輸出被主觀接受的機率,但你無法像客觀任務那樣,達到同等的確定性或準確度。

當然,你可能會指出,針對主觀任務也存在許多知名的「提示模板」,能幫助達到想要的結果。舉例來說,就有能穩定生成特定風格藝術作品的模板。然而,要得出這些提示模板,與其說是工程或科學實踐,不如說更像是一種創意寫作的過程。

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


客觀的交易式提示

一般來說,無論手邊的任務是什麼,具備提示工程的知識都會讓任何人更有效地從語言模型中擷取想要的資訊。然而,針對互動式提示的提示工程,比較像是成為一個高明的「Googler」(Google 搜尋使用者),而針對交易式提示的提示工程,則更接近成為一名資料科學家。

提示工程試圖將 LLM 變成一個客觀、可預測、交易式的 API,就像程式會介接的任何其他 API 一樣,例如金流、行程內函式呼叫、SaaS 呼叫等。當然,語言模型並非一個確定性的、百分之百可靠的機器,因此其實用性與使用情境必然有所不同。

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

我想特別釐清的一個領域,是在撰寫本文當時正興起的「agents」。有人可能會認為 agents 是一種與語言模型進行自動化、互動式的過程。嚴格來說,的確是。但在我看來,agents 的使用在本質上仍主要是交易式的:你交給 agent 一項任務,然後等待結果(該結果可能是客觀正確的,也可能不是)。由於 agents 的使用具有大量、由軟體驅動、交易式的本質,因此可以對其套用提示工程。

註腳

  1. 程式碼生成是一個大到足以另寫一篇部落格文章來討論的主題,但我認為,缺乏明確性將會是未來使用語言模型為更大或更複雜的軟體生成程式碼時的主要挑戰。我們現在看到 agents 透過反覆修改程式碼來通過人類撰寫的單元測試,藉此生成一個能運作但相對簡單的程式。也許未來會讓測試驅動開發(TDD)運動重新受到重視。當然,程式合成、程式規格與程式證明本身就是學術研究中非常豐富的領域,所以或許未來也會出現思想上的融合。也許現在就已經有了,只是這並非我持續關注的研究領域。無論如何,未來將會很有趣!

本文章由 muse-spark-1.2-contributor 進行翻譯

留言