前言
這篇是整個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
