第24天：無提示工程 (Promptless Prompt Engineering)
(很多我自以為的理解的理解筆記...)
1.什麼是「無提示工程」？
Promptless，顧名思義，是不產出 Prompt。更準確地說，是不再由人來產出實際指派任務的 Prompt，而是轉向利用元指令(Meta Prompt) 產出指派任務 Prompt。也就是說，Prompt Engineering 的目標不再是設計生成能讓 LLM 執行最佳的 Prompt。
那麼，Prompt Engineering 要做什麼？答案是：透過設計出最佳的元指令，讓 LLM 有能力自行設計產出 Prompt。
＊一般的流程：
Prompt → LLM → Output
－－
在這流程中，LLM 直接根據指示完成任務。指示可能提供了「如何完成」、也可能沒有。而對應這種情況，LLM本身也會有一套「如何完成」的處理方式。在一般流程中，「如何完成」與「完成什麼」是混雜且不明確的。
＊無提示工程的流程：
Meta Prompt (元指令) → LLM (as a Prompt Generator)** → 自動生成 Prompt → LLM(as a Task Performer) → Output
(**註：接收元指令的 LLM 與產出output的 LLM 不一定是同一個)
－－
在這流程中，我們可以注意到，透過「自動生成 Prompt」的步驟，「如何完成」被先行區分出來了。而這使得在接下來的部分，LLM只需專心處理「完成什麼」。而這就意味是，原本混在一起的工作步驟被明確劃分開來。
白話說，LLM 先是「Prompt 設計師」，生出prompt、解決「如何生成」。然後 LLM 是「任務執行者」，專注於執行每一個被設計好的 Prompt，只需要把內容生出來就好。
2.應用「無提示工程」的好處是？
在只用單一 Prompt 模板時，難以應付的三種情境：指令複雜度、指令衝突、跨範式/規模化生成，透過無提示工程，便可化繁為簡地處理「複雜性」並增加「彈性」。
「複雜性」是指：
(a)當需要完成的任務極其複雜，也就是「如何完成」極其複雜，透過讓 LLM 先行自動生成 Prompt，便可將 Prompt的複雜度降低，想像在一般情況下設計一個 Prompt要求生成15個創作風格的文案，將使 Prompt長度多長、多容易形成LLM 的理解誤區及幻覺。更不論，當這些創作風格彼此衝突(ex明亮陽光/悲觀憂鬱)。
(b)有效降低系統維護的複雜度。想像在一般情況下設計15個創作風格Prompt模板，系統維護上，每當變動需要逐一調整，透過讓 LLM 先行自動生成 Prompt，便可免去一一維護Prompt模板的複雜程度。
「彈性」是指：
(a) 當出現新需求時，在不須調整LLM本體的情況下，僅憑藉無提示工程即可達成。
(b)在單一LLM框架中，接收到生成多種不同、甚至相互衝突的風格、語氣或範式的任務時，可滿足生成多樣化內容的能力。
這兩點尤其是在「大規模(ex 跨領域的資料處理)」、「高度個人化(ex 消費終端的客製行銷內容)」、「自動化(ex A/B 測試)」和「動態(ex多語言)」的應用場景中經常出現**。
(**註：這些應用場景通常是混合出現的，ex大規模且需自動化...etc.)
3.「無提示工程」的困難
(1)元指令的設計決定了自動生成 Prompt 的品質，如何設計至關重要。設計重點在於：讓 LLM 可以根據元指令中指出的任務特性，生成(一至多組)明確可重複執行的 Prompt 模板。
(2)數量上，當數百個自動生成的 Prompt 又再自動產出數百個生成內容時，如何進行效果的評估是一個很大的挑戰。(量變造成質變)
(3)一如我們有時很難理解 LLM的生成內容，由於無法第一時間理解其內部的生成邏輯(CoT)，當連Prompt都是自動生成之時，很可能會更難以被人類理解。
