前一篇文提到了模型的微調，大多都涉及到模型的小規模訓練，如果現在都已經即將要問模型一個問題了，有沒有什麼是最後最後可以做的。

要讓模型有更好答案最簡單的方式，就是調整輸入問題的方式。通常這一段都會在平台方服務中被完成，雖然我們不得而知底層做了什麼樣的指令改善，但依舊有一些大原則可以遵循，來看出更好的指令應該包含什麼要素。

在問題之上: 改善輸入問題的過程

從 LLM 推出的幾年間，已經有無數 prompt 的討論與社群分享，在不同的案例之中應該輸入什麼樣的 prompt 以獲得更好的答案，但近期才開始有更多的討論，包含：怎麼有架構的改善輸入 prompt 的方式，以及怎麼讓 LLM 來幫我們想要怎麼問題。

當在跟 LLM 對話的時候，隨著日積月累的對話量增加，是否曾覺得 LLM 就像一個黑盒子，很煩悶到底要怎麼有效的管理跟觀察自己 prompt 下的好不好？

首先在 LLM 常見的對話平台中，並不有利於將相同目的但不同 prompt 的結果一字排開的比較、也很難記錄過去評估後的分數、當對話來來回回時，更難記錄連續對話方式的好壞。怎麼去改善、管理、評估 prompt 成效的領域，就是時常耳聞的 Prompt Engineering。在此領域有許多「工程」用工具，像是 LangChain, LangGraph, LangSmith 等甚至讓我們能夠視覺化在 LLM 鍊中的成效。

但回歸到問題，我只是一個在 LLM 輸入問題的普通使用者，我們可以怎麼借鑑工具的思路來做 Prompt Engineering？

是連續問題 ? 還是一次性問題？

今天與 LLM 的互動有很多種，我們可以寫一篇長篇大論的問題提供給 LLM 請它提供我一次性的結果。此時的 Prompt 精進就是單一 Prompt 與單一回復之間的持續改善，我們可以對相同目的的 Prompt 記錄不同版本在不同模型下，產出結果進行評分跟比較，這是一種作法。

又或者與 LLM 的對話方式是連續複數個提問，就會涉及到提問策略層次的設計，也要被納入考慮，例如，提供一個產品問題請模型先自行在不知道答案的情況下設想一個解法，接著請模型自評自己的解法，最終再提供一個現實中的實際 Best Practice 讓模型核對並反思其中不一樣之處在哪。這樣的一系列問題，我們習慣稱呼為鍊（Chain) 指的是讓模型分步驟去處理你的問題。

在這種情況下，Prompt 的設計就不單單只是一個節點的問題，也包含整條鍊的設計邏輯都需要考量進去。而節點的設計也有很多種，有時純粹就是一條 LLM 的鍊，有時可能涉及到中間負責尋找資訊、基於資訊再生成結果。

怎麼評估其好壞？

除此之外，我們要怎麼比較一個提問的好壞，在專業的論文中有很多複雜的計分方式，但最簡單的，先讓擁有評價產出結果並記錄的習慣是第一步。但這個評分並不永遠都是要由自己來做，可以貼回復給相同或不同的 LLM 請它評價，甚至更進一步讓模型從不同角度更評價一次，並記錄生成的結果。

更甚者有時我們並不是只要一個分數而已，需要知道的是為什麼錯誤？這時候，需要的是拿出特定案例來分析什麼情境下會導致生成結果不如預期？最好的情況是，你對錯誤會發生的情境以及結果的好壞是有品味的，以能夠明確標註成果是好是壞。例如，如果今天作為一個工程新手，即便生成結果不如預期，除了盲測之外，也很難從常見錯誤案例中分析出，怎麼樣算是生成一個好的程式嗎？又這些會有 bug 的程式碼，應該怎麼去提示他來避免出現錯誤。

怎麼分析出改善方向？

有了分數，我們可以單純就 LLM 的產出做統計圖表來瞭解不同版本的 Prompt 在經歷不同版本的多次使用下，平均得到的分數是多少，藉此來改善 Prompt 的制訂。在更成熟的工具中，甚至 Prompt 的表現可以直接連結到商業指標，又或者可以觀察的不只是表現，也包含每次的成本、時間，有助於改善 AI 服務的營運效率。

除此之外，在前述提到的一些錯誤情境，我們可以再尋找幾組案例，並直接來做開放性的評論，來更明確對於生成結果好壞的標準跟直覺。最終，大量的開放性評論可以再被人或 LLM 彙整、分組，並計算不同類型的錯誤案例分別有多少。

落地執行改善建議

當我們獲得了表現分數、甚至是錯誤情境分析出來的錯誤表，能不能在未來相同的提問上落地成為改善 Prompt 的標準呢？如果今天是一個格式問題，那可能還好處理，可以透過一些現成工具去判斷是否合乎想要的格式結果。但如果今天是主觀評斷，像是生成的答案有沒有創意？合不合理？這就可以再讓一個 LLM 來負責二分法的評斷生成結果是否可行，加速落地的可能性。

以上的評斷 LLM 可以與同樣能辨別的人類合作，此時需要謹慎的辨別，LLM 除了判斷準確率外，需要更加留意，不應通過卻當成通過的案例數與應通過卻被失敗等偽性案例比例。在一些謹慎的場合，會更希望寧可錯殺也不要遺漏。

在問題之中：怎麼問？

雖然以下都是老生常談，而且 prompt 的討論隨新的模型，最佳範例會一直改變，但還是可以歸納出下列原則且適用於不同的模型上：

給予方向

我們可以透過角色扮演又或者是提供模型一些 Guideline 來告訴他，什麼答案適合做、不適合。甚至如果不太知道一開始要怎麼定方向，可以先請模型預熱，請它提供給你 Guideline。

以角色扮演為例，特別適合用在想要換句話說或者有特定領域知識希望模型關注的時候：

User: 我希望你扮演一位{名人/職業等等角色}，{緊接著提供模型任務}
e.g. 我希望你扮演一位資深產品經理，我會給你一段使用敘述，而你需要提供完整的 User Story。

User: 用五歲小孩都能懂得方式來說明{某件事}
e.g. 用五歲小孩都能懂得方式來說明 LLM 怎麼運作。

而 Guideline 就更直覺了，我們可以直接跟模型說，你應該遵循什麼樣的原則以及什麼樣的原則不要做。但比起要求模型不要做什麼，要模型做什麼的效果會比較好：

User: 請依照下列原則來幫我｛做某一件事｝

1. 原則 1 
2. 原則 2
3. 原則 3

e.g. 請依照下列原則來幫我潤飾我的文章

1. 如果有專有名詞，請保留原本用字不要做出任何修改。
2. 如果有冗言墜字，請盡可能保持精簡但不失原意的重述。
... etc 

或者沒有最佳範例可以參考時，甚至可以請模型自己來說說看應該怎麼做比較好，讓模型預熱，舉例來說：

User: 請根據 {某某角色/專家} 提供我 {某件事的準則}？
AI: 
1. 原則 1 
2. 原則 2
3. 原則 3
User: 使用這些原則，來幫我 {做某件事}

指定格式 & 提供範例

也許模型生成的答案正確，但又臭又長又難用，如果後續的資料又需要銜接在其他服務上，那為模型指定格式會是一個很有幫助的作法。例如，要求模型生成 JSON, markdown 等特定格式。

e.g. 
請幫我基於下列資料生成一段格式如下的 JSON 檔:

```json
{
  "{key1}": {value1},
  "{key2}": {value2}
}
```

除了指定方向跟格式，有時直接提供模型 3-5 個直接的範例，讓模型有跡可尋什麼答案是比較好的，同樣的也可以放入比較不好的範例讓模型參考。

任務分工

我們也可以不要只問模型一次性問題，多問幾輪，把文字拆小、請它自行評價自己的產出，甚至請它自己先列出預計的執行步驟，在一步步請它執行，像是前一陣子很流行的強調一步步來思考（Let’s think step by step) 。

其中，如果在最前面的步驟，是先讓模型生出更好模型 Prompt 的作法，又叫做 Meta Prompt，如今，其實 LLM 已經有媲美人類的 Prompt 能力，也許更多時候，需要設計的是一個更好的 Meta Prompt 或者是最前面所敘述管理 Prompt 並進行改進的機制，才會是這些提問的下一步。

總結

如果 Prompt 可以解決，就不要進到 Training，相比於後者，前者的成本低上許多，不用太多的資料、想試隨時都可以試。雖然有朝一日可預期 LLM 會變成通靈大師，Prompt 怎麼下他都能輕易理解。但誠如前段所述，重點並不是 LLM 多能寫，而是寫出來的過程怎麼系統性的被改善，才是即將輸入問題前應該關注的。