diff --git a/docs/ai/01_prompt.md b/docs/ai/01_prompt.md new file mode 100644 index 0000000..d1aeaf9 --- /dev/null +++ b/docs/ai/01_prompt.md @@ -0,0 +1,275 @@ +--- +title: Prompt Engineering +sidebar_label: Prompt Engineering +keywords: ["Prompt"] +description: "提示工程 (Prompt Engineering) 如何影響 LLM 理解使用者輸入的問題" +sidebar_position: 1 +tags: ["Prompt"] +--- + +## 提示工程 (Prompt Engineering) + +目前的 LLM 本質上還是機率模型,所以要如何透過所謂的提示詞 (Prompt),提供模型我們想要回覆的預期方向,讓模型能夠猜的更準,變成使用AI的第一個要掌握的重點。 + +當我們將觀念從傳統的 **指令** 改為 **提示詞**,自然也就衍生出常見的 Pattern。 + +## Pattern + +### 角色提示 + +- 定義:賦予一個專家角色,模型會優先使用與該角色相關的背景知識、語氣、和思考模式。 +- 範例: + > 你是一位擁有 20 年經驗的美食作家,擅長將複雜概念的味覺感受轉化成文字描述。 + +### 上下文提示 +- 定義:完成這個任務/目標,模型需要知道的基本上下文(脈絡)。 +- 範例: + > 這份報告的目標讀者是沒有咖啡豆背景知識的潛在投資者,所以請避免使用過多專業術語。報告的重點應放在市場規模、主要參與者和潛在風險上。 + +### 限制提示 + +- 定義:避免模型過於發散,明確規定輸出的風格、語氣、篇幅,甚至是格式(ex: markdown, xml...)。 +- 範例: + > 正向: 請用一種熱情、活潑、充滿鼓勵的語氣來撰寫這封歡迎新員工的郵件,全文不得超過 100 字。 + > 反向: 請為我比較 A 和 B 兩款手機的優缺點。請**不要考慮價格**因素,只專注於**硬體規格**和**用戶體驗**。 + +### 範例提示 + +- 定義:透過小且精確的範例,讓模型直接當作參考依據。 +- 範例: + > 請將最終結果以下方形式呈現: + > 品項:xxx咖啡豆 + > 產地:來自衣索比亞的單一產區。 + > 特點:豐富的花香和柑橘風味。 + +### 翻轉提示 + +- 定義:當你自己也不完全清楚完成任務需要哪些資訊時,可以利用這個模式,讓 AI 扮演專家的角色,來引導您提供必要的資 +- 範例: + > 你是一位資深的商業分析師(Business Analyst)。擅長引導客戶進行需求探索。我們的共同目標是透過一系列的對話討論,為一個新的商業提案做出分析報告。 + +## 系統提示詞 vs 使用者提示詞 + +### 系統提示詞 +定義 AI 對話的核心,包含角色、個性、行為準則和長期目標,且會在整個任務中持續生效。 + +:::tip +你是一位名叫「數學小老師」的 AI 家教。 +你的任務是: +1. 只回答國小六年級以下的數學問題。 +2. 如果問題超出範圍,要禮貌地拒絕,並說明你的專長是國小數學。 +3. 解釋問題時,要使用生動的比喻,讓小朋友容易理解。 +4. 絕對不能直接給出答案,必須先引導小朋友思考。 +::: + +### 使用者提示詞 +使用者想要跟互動的AI(不論是否包含設定好角色),發問的內容。 + +## 如何開發提示詞 + +由於模型本身是機率模型,所以開發提示詞的過程中,一定少不了多次的嘗試與持續調整,甚至不同版本的模型,各自對應的提示詞也會有所不同。 + +只能通過不斷的試驗,逐漸優化提示,觀察輸出結果,才能做出一個讓自己滿意的提示詞。 + +1. 避免全方位的角色 + > 越全面的角色,設定的內容越多越複雜,也更容易失焦,反而傾向於攏統描述,不如針對各項專精的項目,謹慎地設定好每個角色分別應該具備的能力與期待完成的目標,才能更有方向的去調教設定,優化產生的品質。 +2. 持續優化、反覆實驗 + > 相同的提示詞,在同一個模型執行多次也會有不同的結果,不同模型間的效果落差甚至會更明顯,只有針對不同的場景,反覆實驗,直到能夠在主要使用的模型上,取得不錯的結果。 +3. 不必過於追求完美 + > 提示工程雖然有指引,但並沒有標準答案,有些提示詞也許第一次問答的結果不夠好,但是根據第一次的回答作為 context 的一部分,往後展開,也許就會出現想要的內容。 +4. Deep Domain Knowledge + > 只有當領域知識足夠深厚,才能夠提供更深刻的關鍵詞、Context,讓模型更精準找到你需求的內容,甚至基於這些內容,產生更深刻的結論或是推斷,讓你去做更深的思考。 +5. 清晰 != 囉嗦。 + > 有時候,一個精準的技術術語(關鍵字)比一段冗長的描述更有效。關鍵在於找到「恰到好處」的資訊量,—既能完整傳達意圖,又不會引入不必要的噪音。 +6. 限制 + > 避免模型過於發散,如同前面說到的,我們做提示的目的,就是希望能夠讓模型**猜得準**,所以透過限制,明確告訴模型不能包含哪些部分,也會是很好的引導。 + +## Key Concept + +### In-Context Learning (ICL) + +模型無需更新自身參數(即無需重新訓練),僅透過分析提示中提供的範例,就能學會並執行新任務。 +**表示當模型大到一個程度後,已經展現理解和推理能力。** + +![](img/2025-11-16-15-21-09.png) + +### Zero-shot Prompting + +- 定義: 不提供任何任務範例,直接要求模型根據其龐大的預訓練知識完成任務。 +- 運作原理: 模型對自然語言指令的強大理解能力,以及其內部知識庫中已經存在的相關模式。 +- 適用時機: + 1. 通用任務: 如翻譯、常識問答等模型在訓練中已大量接觸的任務。 + 2. 簡單指令: 任務邏輯簡單直接,沒有複雜的格式要求。 + +:::info +Input: 東京位於哪一個國家? +A: 日本 +(因為這個知識已在模型預訓練包含) + +--- +Q: + +將問題描述的類別名稱設定為「高」、「中」或「低」。僅預測最後一個問題的類別名稱。簡短說明選擇該類別名稱的原因。 + +Class name: High +說明:對企業成本影響高、影響眾多使用者或兩者皆是的問題。 +Class name: Medium +描述:介於高與低之間的問題。 +Class name: Low +描述:對少數使用者有影響、沒有高昂的商業成本,或兩者皆有的問題。 + +問題:使用者回報無法上傳檔案。 + +A: + +Class: High +Description: 此問題被視為高嚴重性,因為它影響了許多使用者且業務成本高昂。無法上傳檔案可能會阻止使用者完成其任務,進而導致延遲和生產力下降。此外,此問題可能會影響多個部門或團隊,進一步增加業務成本。 +(透過模型本身育訓練的理解能力,幫助回答問題) +(example from: https://www.ibm.com/think/topics/zero-shot-prompting) +::: + +### Few-shot Prompting + +- 定義: 提供少數(通常 1-5 個)範例,讓模型透過範例來歸納出你想要的輸出。 +- 運作原理: 模型透過分析您提供的輸入/輸出對,歸納出任務的潛在規則、邏輯、格式或風格,並將其應用到新的輸入上。 +- 適用時機: + 1. 特定格式要求:當您需要模型輸出特定結構(如特定風格的程式碼註解)時。 + 2. 複雜分類任務:當分類標準比較微妙,難以用語言完全描述時(如判斷用戶評論的意圖是「產品諮詢」、「售後投訴」還是「功能建議」)。 + +:::tip +好的範例本身應基本遵循以下原則: + +- 清晰 + 準確 +- 一致性:所有範例的格式和邏輯應保持高度一致,避免讓模型產生困惑。 +- 覆蓋性:應盡可能涵蓋任務的不同情況。 + (例如,在做主觀評價分析時,最好包含 **`正面`**、**`負面`** 以及 **`中性`** 評論。) +- 順序:將最複雜的範例放在最後。 +::: + +### Chain-of-Thought (CoT) + +CoT 實際上是強迫模型將其隱性的思考過程,轉化為顯性可追蹤的文字步驟。 +這不僅僅是為了讓我們看到它的思考過程,更重要的是,這個「寫下來」的動作本身,就能幫助模型更穩定、更合乎邏輯地進行推理,減少了在複雜問題上「一步錯,步步錯」的情況。 + +- 定義: **`Let's think step by step.`** (**`請一步一步地思考。`**) +- 運作原理: + > CoT 將一個複雜的大問題,分解成一系列更小的中間步驟。模型在每一步只需要專注於一個子問題,從而降低了出錯的機率。 + > 生成的每一步推理,都為後續的步驟提供了完整的 Context,確保邏輯鏈的連貫性。 + > 類似於人類在解決難題時進行演算的過程。將思考過程外化,有助於整理思路和發現潛在的錯誤。 + +:::tip +如果覺得 `Let's think step by step.` 效果不如預期,可能是模型自動產生的步驟並不正確。 +可以試著提供手動 CoT 的簡單範例,觀察是否會有所改善。 +::: + +### Self-Consistency + +Self-Consistency 是 CoT 的一個延伸,簡單說,就是讓模型採樣多個不同的推理路徑,然後從多個產生結果中,選出最一致的答案。 + +- 運作原理: + 1. 多路徑生成:針對同一個問題,多次運行 CoT 提示。由於生成過程帶有隨機性,每次生成的推理路徑都會略有不同。 + 2. 答案投票:收集所有這些不同推理路徑得出的最終答案。 + 3. 選擇最優解:選擇在這些答案中出現次數最多的那個,作為最終的可信的答案。 +- 優勢 + 一個複雜問題可能有多種解法,即使某些解法在中間步驟出現了小錯誤,但只要大部分的推理路徑都能指向同一個答案,那麼這個答案的可信度就非常高。 + 這種類似「群體智慧」的方法,極大地增強了結果的穩定性。 + +### Tree of Thoughts (ToT) + +CoT 的思考是線性單向的,一旦某個環節出錯,整個後面就可能導致連環錯。 + +- 運作原理: + 1. 分解步驟:像 CoT 一樣,將問題分解成多個思考步驟。 + 2. 多路徑探索:在**每一個**步驟上,ToT 都會引導模型生成多個可能的「**下一步**」或「**中間解**」。這就像從樹的同一個節點,長出了多個分枝。 + 3. 評估:ToT 會引導模型對每個分枝的「好壞」或「前景」進行自我評估,判斷有沒有價值。 + 4. 剪枝與回溯:模型會「剪掉」那些被評估為沒有前途的分枝,並集中資源在更有希望的路徑上繼續探索。如果所有路徑都走不通,它甚至可以「回溯」到上一個節點,嘗試其他可能性。 +- 優勢 + 當一個任務需要綜合評估多種方案時,使用ToT就能展現出優勢,這也是 Agent 收到使用者任務,制定相關計畫的核心能力。 + +### Retrieval-Augmented Generation (RAG) + +檢索增強生成,是目前將 LLM 應用於企業知識庫最主流、最重要的技術框架。 + +- 運作原理: + 1. 查詢:您的問題首先被發送到一個「檢索器 (Retriever)」。 + 2. 檢索:檢索器會將問題轉換為向量,然後在公司的「知識庫」(一個預先被處理和向量化的文件資料庫,如 Confluence、Google Drive 裡的文件)中,搜尋語義上最相關的文本片段(Chunks)。 + 3. 增強 (Augment):檢索器將找到的這些相關文本片段,連同您最初的問題,一起「打包」成一個更豐富、包含更多上下文的提示。 + 4. 生成 (Generate):這個被「增強」過的提示,最終被發送給 LLM。 + 5. 回答:LLM 根據您提供的即時、準確的上下文,生成一個有理有據的回答,而不是依賴其可能已經過時的內部知識。 + +### ReAct (Reason + Act) + +LLM 的知識被凍結在它們的訓練數據中,它們無法獲取即時資訊,也無法執行計算之外的動作。**ReAct** 徹底改變了這一點,它讓模型成為了一個能夠使用「工具」的智慧代理 (Agent)。 + +- 運作原理: ReAct 的核心是一個「思考 -> 行動 -> 觀察」的循環。 + 1. Reason:模型首先分析任務,並判斷是否需要使用外部工具。 + 如果需要,它會決定使用哪個工具,以及如何使用(即生成呼叫所需的程式碼或指令)。 + 3. Act:系統執行模型生成的指令,調用外部工具。 + 這些工具可以是: + - 搜尋引擎 API:用於查詢即時資訊(如今天的天氣、某支股票的最新價格)。 + - 計算機/程式碼解釋器:用於執行精確的數學計算或程式碼。 + - 資料庫查詢 API:用於從企業內部資料庫中獲取數據。 + - 任何其他 API:如訂票、發送郵件等。 + 4. 觀察:接收 Act 返回的結果。 + 5. 再次思考:模型將觀察到的新資訊,整合到 Context 中,然後進行下一步的思考,決定是繼續使用工具,還是已經擁有足夠資訊來回答最終問題。 + +ReAct 框架極大地擴展了 LLM 的能力邊界,使其轉變為一個能夠動手解決現實世界問題的「數位助理」。 +(已見 AI Agents 的雛形) + +--- + +## Timeline + +```mermaid +timeline + title LLM + + section 2017 + Google
Transformer : Attention Is All You Need + + section 2020 + OpenAI
GPT 3 : Language Models are Few-Shot Learners + Meta
RAG : Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks +``` +```mermaid +timeline + title LLM + + section 2022 + Google
CoT : Chain-of-Thought Prompting Elicits Reasoning in Large Language Models + ReAct : Synergizing Reasoning and Acting in Language Models + + section 2023 + ToT : Tree of Thoughts - Deliberate Problem Solving with Large Language Models +``` + +```mermaid +timeline + title LLM + + section 2024 + Anthropic: Model Context Protocol + + section 2025 + Github : Copilot
Agent Mode + Google : Gemini Cli + OpenAI : Codex + +``` + +## Reference +[Prompt Engineering Guide](https://www.promptingguide.ai) +[Learn Prompting](https://learnprompting.org/docs/introduction) +[openai-cookbook](https://cookbook.openai.com) +[Gemini Api Prompt Strategy](https://ai.google.dev/gemini-api/docs/prompting-strategies) +[Digital Ocean Prompt Tutorials](https://www.digitalocean.com/community/tutorials?q=prompt) +[RAG Best Practices](https://www.kapa.ai/blog/rag-best-practices) +[zero-shot-prompting](https://www.ibm.com/think/topics/zero-shot-prompting) + +## Paper +[Attention Is All You Need](https://arxiv.org/abs/1706.03762) +[Language Models are Few-Shot Learners](https://arxiv.org/abs/2005.14165) +[RAG : Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks](https://arxiv.org/abs/2005.11401) +[Chain-of-Thought (CoT)](https://arxiv.org/abs/2201.11903) +[ReAct](https://arxiv.org/abs/2210.03629) +[Tree of Thoughts (ToT)](https://arxiv.org/abs/2305.10601) diff --git a/docs/ai/img/2025-11-16-15-21-09.png b/docs/ai/img/2025-11-16-15-21-09.png new file mode 100644 index 0000000..bf7df54 Binary files /dev/null and b/docs/ai/img/2025-11-16-15-21-09.png differ