Prompting 知識養成 Day28

第28天：自我優化 Prompt (Self-Optimizing Prompts) ＆ Prompt 蒸餾 (Prompt Distillation)

今天要學習的「自我優化 Prompt (Self-Optimizing Prompts)」與「Prompt 蒸餾 (Prompt Distillation)」，其實正是進入 Prompt engineering 一個新的、更進階的概念：Prompt 工程的自動化與進化 (Automating and Evolving Prompt Engineering)。而這也與之前已經學過的「無提示工程(Promptless engineering)」息息相關。

綜上所述，我們可以說，
「自我優化 Prompt」是：
透過實現無提示工程，實踐 Prompt engineering「自動化」的技術。
「Prompt 蒸餾」是：
透過實現無提示工程，實踐 Prompt engineering「優化」的技術。

▶︎ 溫習「無提示工程」
既然說「自我優化 Prompt」與「Prompt 蒸餾」是無提示工程的具體應用，那麼就讓我們來溫習一下。

「無提示工程」的流程：
Meta Prompt (元指令) → LLM (as a Prompt Generator)** → 自動生成 Prompt → LLM(as a Task Performer) → Output
_{(**註：接收元指令的 LLM 與產出 output 的 LLM 不一定是同一個。這部分在下面也將有更多說明。)}

按上面流程，也就意味著：開發者(工程師)退居至二線，讓 LLM 擔任 Prompt 模板的設計生產者，讓 LLM 去自動生成、優化或測試 Prompt模板。

▶︎ 如何做到 ⇢ Prompt engineering「自動化」與「優化」

▪︎ 自我優化 Prompt (Self-Optimizing Prompts) ⇢ Prompt engineering 自動化
1.概念：
讓 LLM (as a Prompt Generator)扮演 Prompt 優化師的角色，根據特定的任務和評估指標，自動生成多個 Prompt 變體，然後對其進行測試與評估，最終選出表現最佳的 Prompt。
2.關於測試與評估：
在評選機制這個環節有兩種做法。
第一種是，從產出prompt到評選出結果都在同一個元指令中完成。
第二種是，評選機制獨立出來，當prompt產出後，再由人工、或另一個 AI 評估機制，進行測試與篩選。
現階段主流做法是第二種，因為流程更穩定、成本相對更低。

▪︎ Prompt 蒸餾 (Prompt Distillation) ⇢ Prompt engineering 優化
概念：給 LLM (as a Prompt Generator) 一個「Distillation Prompt」指令，要求 LLM 在不犧牲性能的前提下，精煉和簡化Prompt，以達到更高效(ex加快推理速度、降低運算成本)，或是取得標準化的「通用範本」，跨模型的同樣效能運作。

▶︎「自我優化 Prompt」與「Prompt 蒸餾」的實際應用場景
這是對我個人而言，必須加入的一個說明環節，也就是：「自我優化 Prompt 」與「Prompt 蒸餾」的應用場景。因為作為一個終端的用戶，如果無法想像出應用場景，會更難理解它們的效能與功用。

在 Prompt engineering 中，「自我優化 Prompt 」與「Prompt 蒸餾」是應用於「前端」的開發階段。意即，在應用程式「正式上線」之前。這兩個技術是開發者(工程師)用來設計、測試和優化 Prompt 模板的工具。

而當透過操作「自我優化 Prompt」 生成並篩選出最佳 Prompt模板，透過操作「Prompt 蒸餾」精煉出更高效 Prompt模板後，這些經過優化、穩定且安全的 Prompt 模板將被設置於應用程式中，最終面向用戶端，被用戶們使用。

▶︎ LLM 的兩種角色
另一個我也想再補充的是，不論是無提示工程、自我優化Prompt、Prompt 蒸餾，LLM 都有雙重身份：
LLM as a Prompt Generator(生產者)
LLM as a Task Performer(執行者)

這裡想要特別說明的是，
首先，是關於這個 LLM 分工模式。我們之前已提過，這是類似於AI Agent分工模式。
其次，因應 LLM 的不同角色，效能考量與成本耗費也不相同。
Prompt生產者的角色要求更高階的能力，包含思考、創造、設計、語意理解...等等，所以也需要更高的運行成本。
Prompt 執行者的角色負責執行和測試，需求上可接受效能較弱但運算速度快；且相對而言，運行成本也會更低。

文章一開始已提到，兩個 LLM 可以是同一個，但不一定是同一個。而目前業界主流是以分開分層由不同 LLM 處理。
主因有以下 3點：
1.成本考量：Prompt 生成品質極高的高階 LLM 運算成本非常昂貴。
2.效率與用戶體驗：相較於高效 LLM，輕量 LLM 在執行運作上，推理＆響應速度更快，可避免用戶最不喜歡的體驗「延遲(Latency)」。
3.穩定與隔離風險：將核心的 Prompt 設計邏輯與執行區分開，可確保即便執行 LLM 執行上有問題，不會影響到核心的 Prompt 設計邏輯。

❖小結
從「無提示工程」到「自我優化 Prompt 」與「Prompt 蒸餾」，都不再是人工設計產出 Prompt，而是「以 AI 管理 Prompt」。這是在 Prompt engineering 很重要且必要的進階操作。

它們都有著相同構成要素：
Meta Prompt (元指令)
LLM (as a Prompt Generator)
LLM(as a Task Performer) 

它們其實也都有著相類似挑戰：
(a)自動生成 Prompt 的品質維穩
(b)自動生成的 Prompt 及其生成內容的評估
(c) LLM (s a Prompt Generator)的內部生成邏輯(CoT)未可知

不過，「以 AI 管理 Prompt」已成勢不可擋的趨勢，相信這些挑戰已在克服路上(說不定在我結語此刻，就已不成問題)。