前言
這篇是整個ChatGPT打造AI產品系列專欄的第二篇,會介紹Prompt Engineering的基礎概念。
整個系列專欄中我會交錯使用產業、產品的視角、工程的視角、及其他視角來討論如何ChatGPT或是相關的GPT based model打造一個AI產品。如果你還沒看過第一篇,第一篇如何辨識一個好的AI產品方向,並說明了利用ChatGPT打造AI產品的致命陷阱,有興趣的朋友可以回去看。
接下來我們進到正題,也就是最多人討論的Prompt Engineering。
什麼是:Prompt Engineering?這邊我直接請ChatGPT本人來回答
舉個例子:如果我們希望GPT幫我們寫一個課程宣傳文案,直接給要求:「請幫我寫一篇課程宣傳文案」,GPT可能會寫一個跟你規劃完全無關的文案,風格也不符合你要求。取而代之,我們可以給更明確的要求「請幫我寫一篇300字左右適合用於FB宣傳的課程宣傳文案,並提供課程時間5:20下午2~4點,及提醒報名時間只剩2週」。
如上面舉例,光是把Prompt寫得更明確,就可以得到明顯好很多的結果,這就是最最最基礎的一種Prompt Engineering。
實際上,Prompt Engineering已經是一個非常多人在討論的主題,網路上也很多還不錯的資源,以下我直接列舉一些我參考過的:
- openAI-cookbook:提供幾個進階的技巧來讓改善Prompt,讓GPT回答更好。
- Learn Prompting:整理一個完整的Prompt Engineering的基礎教學,包含基礎理論跟常見技巧,還有一些進階的議題。
- Explain This ChatGPT指令大全:坊間也有各種其他職位(行銷人員、產品經理)的從業人員整理的使用懶人包
我這邊就基礎列三個,因為這種東西只會越探索越多,越整理複雜,過幾週肯定又有人提供各種Notion notebook給大家參考。
因為大家都已經很熱衷在「探索有哪些Trick?」,我這系列文章希望避開這個主題,把MLops的思考角度加入進來,討論我認為更重要的問題:
如何系統的使用Prompt Engineering來改進GPT的效果?
本篇文章會包含2個主題:
1. Prompt Engineering在整個流程中扮演什麼角色?
2. 我們怎麼樣改進(Improve)我們的Prompt Engineering?
一、Prompt Engineering在整個流程中扮演什麼角色?
先給出一個最最最基礎的解答,也就是照我們上面的流程,Prompt Engineering其實就是做為一個「把原始Prompt加工成更好的Prompt」的一個模組。(如下圖)
在這個視角下,我們其實其實可以把Prompt Engineering就當成一個ML model或是一個特徵抽取(feature extraction)的方法,會把原始輸入(raw input)轉換成對於GPT好的prompt。
既然是當成model來看,我們就可以默認,我們「不可能只有一種Prompt Engineering方法」,一定是從多個Prompt Engineering的候選中選出我們認為最好的一個。(如下圖)
這個挑選的過程,其實就像是我們從多個不同模型架構、不同超參數組合訓練出來的模型,挑選出效果最好的一個。
為了要能夠挑選出最好的一個,從ML的知識中,我們知道我們還缺少兩個元素:
- Validation Set(或是Test Set):這部分資料必須獨立於我們調整Prompt Engineering的時候使用的資料。
- Evaluation Metric(衡量標準) :我們必須要有一個公訂的標準來比較不同Prompt Engineering的效果。
加入這兩個元素後,我們就得到一個較完整的Prompt Engineering架構(如下圖)。
這樣就可以清晰地看的出來,其實去研究Prompt Engineering的各種Trick,就像是在擴充我們Prompt Engineering候選數量,但是我們還是要有一個公正的Val資料集和衡量標準,並藉由大量實驗,才能找到對於我們需求最好的一個Prompt Engineering方法。
btw 同樣的架構我們也可以擴充到模型上線時,在MLops的時候我們會監督一些指標,來決定是否要retrain我們的模型。同理,我們也可以監督一些指標,來決定是否要改善我們的Prompt Engineering。
二、我們怎麼樣改進(Improve)我們的Prompt Engineering?
要回答這個問題之前,我希望先來想想另一個問題:當我們認為GPT表現不好時,通常是GPT犯了什麼錯?
這裡就要提到GPT3.5以後體現的強大之處,過往的LLM(大型語言模型),犯錯的種類實在太多了,包含各種基礎的文法錯誤、邏輯錯誤、前後不一致...等,因此其實微軟研究院跟華盛頓大學其實3年前發表過一篇論文<Beyond Accuracy: Behavioral Testing of NLP Models with CheckList>,對每一個基礎問題都設定一些衡量指標。
但是GPT大多這些問題都不見了,因此大多數人提到GPT犯錯時都是針對「GPT給出的答案不正確」。
而GPT給出答案不正確,主要又分為兩個主要的來源(未來經過更多人研究可能會發現更多細節問題):
- Chain of Thought(CoT)能力不夠強。CoT其實就是我們所說的「思考的深度」,舉個例子:如果今天KTV開發一個GPT的線上客服,如果客人想問「KTV的營業時間」,這是單純從KTV的資訊中提取關鍵資訊回答,這個CoT能力需求就很低,但是如果客人想要詢問「週二1點到8點總共6個人,5點後會再多3個人,想問總共金額是多少?」這就需要較強的CoT能力了,因為不只要提取出資訊,還要做一定程度的運算,同時可能還要比較不同方案的價格差異。這就是所謂的Chain of Thought (CoT)
- 跟事實(Fact)相悖。很多時候GPT犯錯的關鍵就是因為他沒有得到關鍵資訊,舉個例子:如果你問GPT「台灣的五大山脈是哪五大」,GPT幾乎沒有成功回答過,但是如果你把Wiki關於台灣山脈的介紹加入到Prompt給GPT參考,GPT就幾乎不會錯。
當我們想清楚GPT最主要的兩個錯誤來源後,我們其實就可以把我們想要用GPT來處理的任務,進行分析。
舉個例子,如果把常見的GPT使用方式進行分析,也能大致給出它們的是否需要額外的Fact,跟對CoT能力的需求高低。(如下表)
同時我們也可以把我們看到的各種Prompt Engineering技巧,進行分類:
CoT能力不夠時:
- 選擇更大的GPT模型
- 開頭給「讓我們一步一步想」
- 給範例思考方式,或是給一個其他案例的參考解答
- 請GPT自我驗證自己的輸出
- Finetune GPT
- ...
需要額外Fact時:
- 提供固定的常用Fact
- 利用Semantic Search針對原始輸入找到關鍵Fact
- 請GPT基於我們提供Fact回答
- 請GPT驗證輸出跟我們提供的Fact是否邏輯上正確
- Finetune GPT
- …
這邊我都是簡單列而已,我會再後續文章結合範例做更完整了討論。不過核心思考框架是:
先確定這個任務對CoT跟Fact的需求高低,依據需求建立基準Prompt Engineering,衡量效果,分析目前問題來源,繼續改進。
其實就像是我們做ML模型的時候會持續改進模型,我們也望建立一個完整的pipeline來更有效、系統的迭代我們的Prompt Engineering方法。
同時我們也可以把過去學會的MLops技巧,像是如個做Prompt Engineering的Version Control且記錄不同Version的效果,如何在上線後持續監督、改進Prompt Engineering效果...等
總結
- Prompt Engineering在整個流程中的角色其實相當於我們以前在挑選的模型或是超參數。
- 我們需要Val Dataset跟Evaluation Metrics來衡量不同Prompt Engineering方法的效果(下一篇會講)。
- 解構GPT犯錯的兩個主要來源:CoT能力不夠時、需要額外Fact。
- 分析每個任務需要的CoT能力跟是否需要額外Fact。
- 並針對每個Prompt Engineering的方法分析會改善哪個效果。
這樣我們就有系統的Prompt Engineering思考框架。
如果你有興趣,我接下來我會繼續以比較工程的角度,繼續討論Prompt Engineer並舉實際例子,並、Response Engineer(如何處理GPT返回的資訊)及、Model Engineer(如何Finetune、Select GPT模型)。
也可以給我拍手我會更加緊寫文,同時我現在也是開放任何演講、家教邀約,我常接的包含學校演講、企業內訊、求職家教…等,有興趣可以寄信聯繫axk51013@gmail.com