本單元涵蓋生成式 AI 模型中創建有效提示的基本概念和技術。向大型語言模型 (LLM) 編寫提示的方式同樣重要。精心設計的提示能夠獲得更高質量的回應。但「提示」和「提示工程」這些術語究竟是什麼意思？我如何改進發送給 LLM 的提示輸入？這些都是我們在本章及下一章嘗試解答的問題。
生成式 AI 能夠根據用戶請求創造新的內容（例如，文字、圖像、音頻、程式碼等）。它是利用像 OpenAI 的 GPT（「生成式預訓練變換器」）系列這樣的 大型語言模型 來達成的，這些模型經過自然語言和程式碼的訓練。
用戶現在可以通過類似聊天的熟悉範式與這些模型互動，無需任何技術專長或訓練。這些模型是 基於提示的 ——用戶傳送文本輸入（提示），並獲得 AI 回應（完成）。用戶可以迭代地「與 AI 聊天」，進行多輪對話，調整提示直到回應符合期望。
「提示」現已成為生成式 AI 應用的主要 程式設計介面，指示模型該做什麼並影響回應品質。「提示工程」是一個快速成長的研究領域，專注於 設計和優化 提示，以大規模 deliver 一致且優質的回應。
在本課程中，我們將了解提示工程是什麼、為何重要，以及如何根據特定模型和應用目標製作更有效的提示。我們會理解提示工程的核心概念與最佳實踐——並了解一個互動式的 Jupyter 筆記本「沙盒」環境，在其中可以將這些概念應用於實際範例。
到本課結束時，我們將能夠：
- 解釋什麼是提示工程及其重要性。
- 描述提示的組成部分及其用途。
- 學習提示工程的最佳實踐和技巧。
- 運用所學技巧，在 OpenAI 端點上應用於實際範例。
提示工程：設計和改良輸入以引導 AI 模型產生理想輸出的實踐。 分詞（Tokenization）：將文本轉換為模型可理解和處理的較小單位（稱為詞元）的過程。 指令微調大型語言模型（Instruction-Tuned LLMs）：經過特定指令微調以提升回應準確性和相關性的 LLM。
提示工程目前偏向藝術多於科學。提升直覺的最佳方式是_多加練習_，採用結合應用領域專業知識、推薦技巧和模型特定優化的反覆試錯方法。
本課程附帶的 Jupyter 筆記本提供一個 沙盒 環境，可讓你在學習過程中或作為結尾程式碼挑戰的一部分，嘗試所學內容。執行練習，需要：
- Azure OpenAI API 金鑰 —— 部署中的 LLM 服務端點。
- Python 執行環境 —— 執行筆記本的環境。
- 本地環境變數 —— 請立即完成設定步驟準備好環境。
筆記本中包含 初學者 練習，但鼓勵你新增自己的 Markdown（說明）和 程式碼（提示請求）部分，嘗試更多範例或想法，構建提示設計的直覺。
想要在深入學習前先了解本課涵蓋的大綱？請參閱此圖解導覽，概覽主要主題和關鍵學習點，讓你在學習時有所思考。此課程路線圖帶你從核心概念和挑戰理解，延伸到運用相關提示工程技術和最佳實踐來解決問題。請注意，本導覽中「進階技巧」部分指的是本課程下一章將介紹的內容。
現在，讓我們談談_這個主題_如何與我們創業使命連結，即推動 AI 創新進入教育。我們希望打造 AI 驅動的_個人化學習_應用，思考我們應用的不同使用者如何「設計」提示：
- 管理員 可能會請 AI 分析課程資料以識別缺漏。AI 可以總結結果或用程式碼視覺化呈現。
- 教育工作者 可能會請 AI 為目標受眾和主題生成課程計劃。AI 可按指定格式建立個人化計劃。
- 學生 可能會請 AI 輔導他們學習困難科目。AI 現能依學生程度提供課程、提示與示例。
這僅是冰山一角。請查看 教育用提示——由教育專家策劃的開源提示庫，了解更多可能性！嘗試在沙盒或使用 OpenAI Playground 執行其中一些提示，看看會發生什麼！
我們從定義 提示工程 開始，指為了給定應用目標和模型，設計與優化 文本輸入（提示）以交付一致且優質回應（完成）的過程。我們可以將此視為一個兩步驟流程：
- 為特定模型和目標 設計 初步提示
- 反覆 調整 提示以提升回應質量
這必須透過反覆試錯過程進行，需用戶直覺與努力才能達到最佳效果。那為什麼重要？首先我們要了解三個概念：
- 分詞 = 模型「看見」提示的方式
- 基礎 LLM = 基礎模型「處理」提示的方式
- 指令微調 LLM = 模型現在如何「看見任務」
大型語言模型將提示視為 詞元序列，不同模型（或同一模型的不同版本）可對同一提示執行不同方式的分詞。由於 LLM 是基於詞元訓練的（而非原始文字），提示如何被分詞會直接影響生成回應的質量。
要理解分詞原理，可以試用下方的 OpenAI 分詞器 工具。將你的提示貼入，觀察其如何轉換成詞元，特別留意空白字符和標點符號的處理方式。請注意此範例使用的是較舊的 LLM（GPT-3），以較新模型試驗可能有不同結果。
提示一旦被分詞，"基礎 LLM"（或稱基礎模型）的主要功能是預測該序列中的下一個詞元。由於 LLM 受大量文本資料訓練，對詞元間的統計關係有良好理解，可以較有信心地做出預測。請注意，它們不理解提示或詞元中的 意義，只是看到可以透過下一個預測來「完成」的模式。直到用戶干預或達到預先設定條件，模型會持續預測序列。
想看看基於提示的完成是如何運作的嗎？將上述提示輸入 Microsoft Foundry playground，使用預設設定。系統會將提示視為資訊請求，因此你應該會看到符合該上下文的完成内容。
但如果用戶想要看到符合某些條件或任務目標的特定內容呢？這時就有 指令微調 的大型語言模型登場了。
指令微調 LLM由基礎模型開始，透過範例或輸入/輸出對（例如多輪「訊息」），帶有明確指令，進行微調，AI 回應會嘗試遵從該指令。
這利用了例如帶有人類回饋的強化學習（RLHF）等技術，訓練模型 遵循指令 並 從回饋中學習，使其產生更適合實際應用且更貼合用戶目標的回應。
讓我們試一試——回到上述提示，但這次將 系統訊息 更改為下述指令做為上下文：
為二年級學生總結你所提供的內容。保持結果為一段文字，包含 3-5 點重點條列。
看看結果如何現在調整為反映所需目標和格式？教育工作者現在可以直接在該堂課的投影片中使用這回應。
既然我們知道提示如何被 LLM 處理，讓我們談談 為什麼 需要提示工程。原因在於當前 LLM 存在多項挑戰，使 可靠且一致的完成 難以達成，除非在提示構造和優化上投入努力。例如：
-
模型回應具隨機性。 相同提示 在不同模型或模型版本間可能產生不同回應。即使是同一模型，也可能在不同時間出現不同結果。提示工程技巧可以幫助我們透過更好的護欄來減少這些變異。
-
模型可能會捏造回應。 模型經過 龐大但有限 的數據集預訓練，缺乏訓練範圍外概念的知識。所以它們可能產生不準確、虛構或與已知事實直接矛盾的完成。提示工程技巧能幫助用戶識別並減輕此類捏造，例如透過要求 AI 提供引用或推理。
-
模型能力有變異。 較新模型或新一代模型功能更豐富，但也帶來獨特的特性與成本、複雜度上的權衡。提示工程可以幫助我們發展最佳實踐和工作流程，抽象化差異並以可擴展、無縫方式適應模型特定需求。
讓我們在 OpenAI 或 Azure OpenAI Playground 中實際操作看看：
- 使用相同提示搭配不同 LLM 部署（例如 OpenAI、Azure OpenAI、Hugging Face）——你觀察到變異了嗎？
- 使用相同提示重複搭配同一 LLM 部署（例如 Azure OpenAI playground）——這些變異有哪些差異？
在本課程中，我們用 「捏造」 一詞指代 LLM 由於訓練或其他限制，有時會產生事實錯誤資訊的現象。你或許也在流行文章或研究論文中聽過它被稱為 「幻覺」。但我們強烈建議使用 「捏造」 這個術語，以免將機器產生的結果擬人化，賦予機器人類特質。這也從術語角度強化了負責任 AI 指導原則，剔除了可能在某些場合被認為具冒犯性或不包容的詞彙。
想了解捏造是如何發生的？想像一個提示指示 AI 生成不存在主題的內容（以確保該主題不在訓練數據中）。例如，我試過這個提示：
提示： 生成一份有關 2076 年火星戰爭的課程計劃。
網絡搜尋顯示火星戰爭有虛構敘述（例如電視劇或書籍），但不是在 2076 年。常識告訴我們 2076 年是在未來，因此不可能與真實事件相關。
那麼當我們用不同的 LLM 供應商執行這個提示時會發生什麼事？
回應 1：OpenAI Playground（GPT-35）
回應 2：Azure OpenAI Playground（GPT-35）
回應 3：Hugging Face Chat Playground（LLama-2）
正如預期的，每個模型（或模型版本）因為隨機行為和模型能力的差異，而產生略有不同的回應。例如，一個模型針對的是八年級學生，而另一個則假設是高中生。但這三個模型都生成了足以使未受過相關資訊的用戶相信事件是真實的回答。
提示工程技術如 元提示 和 溫度設定 可能在某種程度上減少模型的捏造。新的提示工程 架構 也將新工具和技術無縫整合到提示流程中，以緩解或減少這些影響。
在本節結尾，讓我們透過一個案例研究來了解現實世界中如何運用提示工程：GitHub Copilot。
GitHub Copilot 是你的「AI 編程拍檔」— 它將文字提示轉換為程式碼補全，而且整合在你的開發環境（如 Visual Studio Code）中，提供無縫的用戶體驗。正如以下系列部落格所記錄，最早版本基於 OpenAI Codex 模型，工程師們迅速認識到需要調整模型和開發更好的提示工程技術，以提升程式碼品質。今年七月，他們推出了超越 Codex 的改進版 AI 模型，以提供更快速的建議。
請按照順序閱讀這些文章，以跟進他們的學習歷程。
- 2023 年 5 月 | GitHub Copilot 正在變得更懂你的程式碼
- 2023 年 5 月 | GitHub 內幕：與 GitHub Copilot 背後的 LLM 一起工作。
- 2023 年 6 月 | 如何為 GitHub Copilot 撰寫更好的提示。
- 2023 年 7 月 | .. GitHub Copilot 藉由改進的 AI 模型超越 Codex
- 2023 年 7 月 | 開發者的提示工程及 LLM 指南
- 2023 年 9 月 | 如何打造企業級 LLM 應用：GitHub Copilot 的經驗談
你也可以瀏覽他們的工程部落格，閱讀更多像這篇的文章，展示這些模型和技術如何_應用_於推動現實世界的應用。
我們已經知道為何提示工程很重要—現在讓我們了解提示是如何被_組成_，以便能評估不同技術，設計更有效的提示。
讓我們從基本提示開始：沒有其他背景上下文，單純送給模型的文字輸入。以下是例子——當我們將美國國歌的前幾個字送入 OpenAI 的 Completion API 時，它會立刻_補全文字_為接下來的幾行，展示基本的預測行為。
| 提示（輸入） | 補全（輸出） |
|---|---|
| Oh say can you see | 聽起來你正在開始唱美國國歌「星條旗永不落」（The Star-Spangled Banner）的歌詞，完整歌詞是 ... |
現在來給這個基本提示加入上下文和指示。Chat Completion API允許我們組成一個複雜提示，作為多個 訊息 的集合：
- 輸入/輸出對，反映 使用者 輸入和 助手 回應。
- 系統訊息設定助手的行為或人格上下文。
請求現依呈現為以下形式，其中 分詞 有效捕捉來自上下文與對話的相關資訊。改變系統上下文對完成品質的影響，和使用者提供的輸入一樣重大。
response = client.responses.create(
model="gpt-5-mini",
input=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Who won the world series in 2020?"},
{"role": "assistant", "content": "The Los Angeles Dodgers won the World Series in 2020."},
{"role": "user", "content": "Where was it played?"}
]
)在上述例子中，使用者提示是一個簡單的文字查詢，可視為請求資訊。使用_指令_ 提示，我們可以使用該文字來更細緻地指定任務，提供更好的 AI 指導。舉例：
| 提示（輸入） | 補全（輸出） | 指令類型 |
|---|---|---|
| 撰寫一段美國內戰的描述 | 返回一段簡單的文字 | 簡單 |
| 撰寫一段美國內戰的描述。提供重要日期和事件並說明其意義 | 返回一段文字，接著列出關鍵事件日期與描述 | 複雜 |
| 用一段描述美國內戰。提供3個重點條列，包含重要日期及其意義。提供3個重點條列，包含主要歷史人物及貢獻。以 JSON 格式回傳 | 以 JSON 格式回傳詳細文字方塊，可複製貼上並根據需要驗證 | 複雜有格式 |
在以上例子中，提示仍相當開放，讓 LLM 決定其預訓練數據集中哪些部分是相關的。使用_主要內容_設計模式時，輸入片段被分為兩部分：
- 一段指示（動作）
- 相關內容（影響動作）
下面例子中，指示是「用兩句話摘要此內容」。
| 提示（輸入） | 補全（輸出） |
|---|---|
| 木星是太陽系第五顆行星，也是最大的一顆。它是個氣態巨星，質量是太陽的千分之一，但比太陽系其它所有行星的總和還要重兩倍半。木星是肉眼可見的夜空中最明亮的天體之一，早在有文字記錄的歷史之前就已經為古代文明所知。它以羅馬神朱比特命名。[19] 從地球觀察，木星的反射光甚至足夠投射可見影子，[20] 並且平均是繼月亮和金星後夜空中第三亮的自然天體。 用兩句話簡短摘要它 |
木星是太陽系第五顆行星，也是最大的一顆，且是夜空中最明亮的天體之一。它以羅馬神朱比特命名，是一顆氣體巨星，質量是太陽系其他所有行星的兩倍半。 |
主要內容片段可以用多種方式來促進更有效的指令：
- 範例 - 與其給模型明確指示做什麼，不如給它輸出範例，讓它推斷模式。
- 提示 - 在指令後跟一個「提示」，啟發補全，指引模型朝向更相關回答。
- 模版 - 這些是可重複使用的「配方」，用佔位符（變數）客製化資料以應用於特定情境的提示。
讓我們逐一探索實例。
這種方法是利用主要內容提供模型想要輸出的範例，讓它推斷所需輸出的模式。根據提供範例數量，我們有零次提示、一次提示、少次提示等。
提示現在包含三個組件：
- 任務描述
- 幾個想要輸出的範例
- 新範例開始（作為隱含任務描述）
| 學習類型 | 提示（輸入） | 補全（輸出） |
|---|---|---|
| 零次 | "The Sun is Shining". 翻譯成西班牙語 | "El Sol está brillando". |
| 一次 | "The Sun is Shining" => "El Sol está brillando". "It's a Cold and Windy Day" => |
"Es un día frío y ventoso". |
| 少次 | The player ran the bases => Baseball The player hit an ace => Tennis The player hit a six => Cricket The player made a slam-dunk => |
Basketball |
注意零次提示中需要明確指示（「翻譯成西班牙語」），但一次提示範例中可推斷出指示意圖。少次例子展示加入更多範例如何讓模型在無額外指示下做出更準確推斷。
使用主要內容的另一技術是提供_提示_而非範例。在這種情況下，我們用一段反映期望回答格式的片段作為開頭，給模型一個推動，它便「接受提示」繼續下去。
| 提示數量 | 提示（輸入） | 補全（輸出） |
|---|---|---|
| 0 | 木星是太陽系第五顆行星，也是最大的一顆。它是個氣態巨星，質量是太陽的千分之一，但比太陽系其它所有行星的總和還要重兩倍半。木星是肉眼可見的夜空中最明亮的天體之一，早在有文字記錄的歷史之前就已經為古代文明所知。 簡短摘要 |
木星是我們太陽系中最大的行星，也是第五顆行星。它是一顆氣態巨星，質量是太陽的千分之一，但比所有其他行星加起來還重。古代文明早已知曉木星，且它在夜空中很容易被看見。 |
| 1 | 木星是太陽系第五顆行星，也是最大的一顆。它是個氣態巨星，質量是太陽的千分之一，但比太陽系其它所有行星的總和還要重兩倍半。木星是肉眼可見的夜空中最明亮的天體之一，早在有文字記錄的歷史之前就已經為古代文明所知。 簡短摘要 我們學到的是木星 |
是太陽系第五顆行星，也是最大的一顆。它是一顆氣態巨星，質量是太陽的千分之一，但比其他所有行星加起來的質量還多兩倍半。它肉眼可見，自古就為人所知。 |
| 2 | 木星是太陽系中由太陽起算的第五顆行星，也是最大的行星。它是一個氣體巨行星，質量是太陽的千分之一，但卻是太陽系其他所有行星質量總和的兩倍半。木星是夜空中用肉眼可見的最明亮天體之一，並自有記錄歷史之前就被古代文明所認識。 總結如下 我們學到的三大要點： |
1. 木星是太陽系中由太陽起算的第五顆行星，也是最大的行星。 2. 它是一個質量約為太陽千分之一的氣體巨行星… 3. 木星自古代以來一直肉眼可見… |
提示範本是 預先定義的提示配方，可以儲存並按需重用，以推動更一致且大規模的用戶體驗。它最簡單的形式是像這個來自 OpenAI 的範例那樣，提供交互式的提示元件（用戶和系統訊息）以及 API 驅動的請求格式——以支持重用。
在更複雜的形式中，如這個來自 LangChain 的範例，它包含可以用來替換來自各種來源資料（用戶輸入、系統上下文、外部數據源等）的 佔位符，用以動態生成提示。這讓我們能建立一個可重用的提示庫，能 以程式化方式 大規模地推動一致的用戶體驗。
最後，模板的真正價值在於能創建並發布垂直應用領域的 提示庫——此時提示模板經過 優化，反映特定應用的上下文或範例，使回應對目標用戶更具相關性和準確度。Prompts For Edu 倉庫就是這方面的優秀例子，策劃了一套教育領域相關的提示庫，重點放在教學計劃、課程設計、學生輔導等關鍵目標。
如果我們將提示建構視為有一個指令（任務）和一個目標（主要內容），那麼 次要內容 就像是我們提供的額外上下文，用以 某種方式影響輸出。它可以是調整參數、格式指示、主題分類等，有助於模型 針對 期望的用戶目標或期待調整回應。
例如：給定一個含有詳細元資料（名稱、描述、級別、元標籤、講師等）的課程目錄，涵蓋所有課程：
- 我們可以定義一個指令為「總結 2023 秋季學期課程目錄」
- 我們可以用主要內容給出幾個想要的輸出範例
- 我們可以用次要內容標示感興趣的前 5 個「標籤」
現在，模型可以以範例中展示的格式提供摘要——但若一條結果有多個標籤，它能優先考慮次要內容中標示出的 5 個標籤。
現在我們知道如何 構建 提示，可以開始思考如何 設計 它們以反映最佳實務。我們可以從兩方面來考慮——擁有正確的 心態 和運用正確的 技術。
提示工程是個試錯過程，請牢記三大指導因素：
-
領域理解很重要。 回應的準確與相關性取決於該應用或用戶操作的 領域。發揮你的直覺和領域專長來進一步定制技術。例如，在系統提示中定義 領域專屬個性，或在用戶提示中使用 領域專屬模板。提供反映領域上下文的次要內容，或用 領域專屬線索和示例 引導模型習慣用法。
-
模型了解很重要。 我們知道模型本質上是隨機的。但模型實作也會因所用訓練數據集（預訓練知識）、支持的能力（例如透過 API 或 SDK）及其優化的內容類型（如程式碼、圖像、文字）而異。了解你使用的模型的優缺點，並用此知識 優先任務 或建立 自定義模板，優化以契合該模型的能耐。
-
反覆與驗證很重要。 模型及提示工程技術都在快速演進。作為領域專家，你可能有針對 特定應用 的其他背景或標準，未必適用於更廣的社群。使用提示工程工具與技術來「快速啟動」提示構建，然後用直覺和領域專長反覆試驗驗證結果。紀錄你的心得，建立一個 知識庫 （如提示庫），作為日後他人更快迭代的新基準。
接著讓我們看看 OpenAI 與 Azure OpenAI 實務者建議的常見最佳實務。
| 做什麼 | 為什麼 |
|---|---|
| 評估最新模型 | 新一代模型可能具備改良的功能和品質，但也可能帶來更高的成本。評估其效果後，再決定是否遷移。 |
| 區分指令與上下文 | 查看你的模型/提供者是否定義了 分隔符，用於更清楚地區分指令、主要與次要內容。這有助於模型更精準地給予詞元權重。 |
| 具體清晰 | 提供更多關於期望上下文、結果、長度、格式、風格等細節。這將提升回應的品質與一致性。把配方寫入可重用模板。 |
| 具描述性並用範例 | 模型對「示範說明」方法反應可能較佳。可先用 zero-shot（零範例）給指令，再用 few-shot（少數範例）微調，提供一些期望輸出範例。使用類比說明。 |
| 用線索啟動完成 | 藉由給出一些起始詞語或片語，引導模型朝向期望結果起步。 |
| 多次強調 | 有時可能需要對模型重複指令。可在主要內容前後都下指令，使用指令加線索等。反覆試驗驗證看看哪種方法效果最好。 |
| 順序重要 | 呈現資訊給模型的順序可能影響輸出，甚至在學習範例裡亦然，因為後效偏差。嘗試不同選項找出最佳結果。 |
| 給模型「退路」 | 給模型一個 後備 回應選項，當它無法完成任務時使用。這可降低模型產生錯誤或捏造回應的機率。 |
如同任何最佳實務，請記住根據模型、任務與領域的不同，你的情況可能有所不同。以上只作為起點，透過迭代找出最適合你的方式。隨著新模型和工具問世，持續重新評估你的提示工程流程，注重過程的可擴展性與回應品質。
恭喜你！你已經完成本課程！是時候用真實範例來檢視這些概念與技術的應用！
我們的作業會使用帶有練習題的 Jupyter 筆記本，你可以互動式完成。你也可以自行擴充該筆記本，添加自己的 Markdown 和程式碼儲存格，自行探索想法與技術。
- （推薦）啟動 GitHub Codespaces
- （或者）將倉庫克隆到你的本地設備，並用 Docker Desktop 運行
- （或者）用你偏好的筆記本執行環境開啟該筆記本
- 將倉庫根目錄的
.env.copy複製為.env，並填入AZURE_OPENAI_API_KEY、AZURE_OPENAI_ENDPOINT及AZURE_OPENAI_DEPLOYMENT等值。回到 Learning Sandbox 節 學習如何設定。
- 選擇運行時內核。若使用方法1或2，直接選擇開發容器提供的默認 Python 3.10.x 內核即可。
你已準備好執行練習題。請注意，這裡沒有 正確與錯誤 答案——只是透過試錯探索選項，培養對特定模型和應用領域可行方法的直覺。
因此，本課程沒有提供程式碼解答段落。取而代之的是筆記本中會有標題為「我的解答：」的 Markdown 儲存格，展示一個參考範例輸出。
以下哪個提示符合合理的最佳實務？
- 顯示紅色汽車的圖片
- 顯示一輛 Volvo 品牌 XC90 車型的紅色汽車，停在懸崖旁夕陽西下的圖片
- 顯示一輛 Volvo 品牌 XC90 車型的紅色汽車圖片
答：2，因為它提供了「什麼」的細節並具體描述（不只是隨便一輛車，而是具體品牌和車型），還描述了整體場景。接著是 3，因為它也包含許多描述。
試試看利用「線索」技術：完成句子「顯示一輛 Volvo 品牌的紅色汽車，並且…」。它會回應什麼？你會怎麼改進？
想了解更多不同的提示工程概念？請造訪持續學習頁面尋找此主題的其他優質資源。
接著前往第5課，我們將探討進階提示技巧！
免責聲明： 本文件由 AI 翻譯服務 Co-op Translator 翻譯而成。雖然我們致力於確保準確性，但請注意，機器自動翻譯可能包含錯誤或不準確之處。原始文件的母語版本應被視為權威來源。對於重要資訊，建議進行專業人工翻譯。我們不對因使用本翻譯而產生的任何誤解或誤釋承擔責任。