提示策略總覽

本指南將概略說明設計提示的常見策略，以及提示的疑難排解檢查清單。

設計提示沒有絕對正確或錯誤的方法，但有一些常見策略可有效影響模型的回覆。嚴格的測試和評估仍是最佳化模型效能的關鍵。

大型語言模型 (LLM) 經過大量文字資料訓練，可學習語言單元之間的模式和關係。只要提供一些文字 (提示)，語言模型就能預測後續內容，就像精密的自動完成工具。因此，設計提示時，請考量可能影響模型預測結果的各種因素。

提示工程工作流程

提示工程是以測試為依據的疊代程序，可增強模型效能。建立提示時，請務必清楚定義每個提示的目標和預期結果，並有系統地測試提示，找出需要改進的地方。

下圖顯示提示工程工作流程：

提示工程工作流程圖

如何撰寫有效提示

提示的有效性最終取決於兩個方面：內容和結構。

  • 內容：

    模型需要與工作相關的所有資訊，才能完成工作。這類資訊可能涵蓋指令、範例和上下文資訊等。詳情請參閱「提示的組成要素」。

  • 結構：

    即使提示中已提供所有必要資訊，提供資訊結構仍有助於模型剖析資訊。排序、標籤和分隔符號的使用方式等因素，都會影響回覆品質。如需提示結構範例，請參閱提示範本範例。

提示的元素

下表列出提示的必要和選用元素：

元件 說明 範例
目標 您希望模型達成的成果，請提供具體說明並涵蓋所有首要目標。也稱為「使命」或「目標」。 你的目標是協助學生解出數學問題，但不能直接提供答案。
操作說明 如何執行手上工作的逐步指令。也稱為「工作」、「步驟」或「指示」。
  1. 理解問題內容。
  2. 瞭解學生不懂的地方。
  3. 提供解決問題的下個步驟。
選用元件
系統指示

透過技術或環境指令，控管或改變模型執行一系列工作時的行為。在許多模型 API 中，系統指令會透過專屬參數來指定。

系統指令適用於 Gemini 2.0 Flash 以上版本。

 您是程式設計專家，專門為前端介面算繪程式碼。當我描述要建構的網站元件時，請傳回建構該元件所需的 HTML 和 CSS，不要提供這段程式碼的說明。並提供一些 UI 設計建議。
角色 模型要扮演的角色。也稱為「角色」或「願景」。 你是一名數學家教，目標是指導學生完成數學作業。
限制 模型生成回覆時必須遵守的限制，包括可做和不能做的事情。也稱為「安全防護措施」、「界線」或「控制項」。 請勿直接提供答案給學生，請給予提示，讓他們知道解決問題的下一步是什麼。如果學生完全沒有頭緒，請給他們解決問題的詳細步驟。
語氣 回覆時採用的語氣。您也能指定角色來調整回覆風格和語氣。也稱為「風格」、「語氣」或「情緒」。 以輕鬆又符合技術專業的態度回覆。
脈絡資訊 模型執行手上工作所需的任何參考資訊。 也稱為「背景」、「文件」或「輸入資料」。 數學教案的副本。
少量樣本範例 模型收到提示時該如何回覆的範例。也稱為「範例」。 input: 我想計算一個體積為一立方公尺的盒子可以裝多少顆高爾夫球。我已將一立方公尺換算為立方公分，並除以高爾夫球的體積 (以立方公分為單位)，但系統表示我的答案有誤。
output:高爾夫球是球體，無法以完美效率裝入空間。計算時，請將球體的最高包裝效率納入考量。
推論步驟 引導模型說明推論過程，模型的推理能力有時能因此而提升。也稱為「思考步驟」。 請逐步說明推論過程。
回覆格式 您希望回覆使用的格式。舉例來說，您能要求模型輸出回覆時採用 JSON、資料表、Markdown、段落、項目符號清單、關鍵字、電梯簡報等格式。也稱為「結構」、「呈現方式」或「版面配置」。 以 Markdown 格式提供回覆。
重點回顧 在結尾簡要重述提示中的重點，特別是限制和回覆格式。 不要直接給答案，而是提供提示。一律採用 Markdown 格式來回覆。
保護措施 將問題範圍限縮在機器人的任務中。也稱為「安全規則」。 不適用

視手邊的特定工作而定，您可能會選擇納入或排除部分選用元件。你也可以調整元件順序，並查看這會如何影響回覆。

提示範本範例

以下提示範本顯示結構良好的提示範例：

      <OBJECTIVE_AND_PERSONA>
      You are a [insert a persona, such as a "math teacher" or "automotive expert"]. Your task is to...
      </OBJECTIVE_AND_PERSONA>

      <INSTRUCTIONS>
      To complete the task, you need to follow these steps:
      1.
      2.
      ...
      </INSTRUCTIONS>

      ------------- Optional Components ------------

      <CONSTRAINTS>
      Dos and don'ts for the following aspects
      1. Dos
      2. Don'ts
      </CONSTRAINTS>

      <CONTEXT>
      The provided context
      </CONTEXT>

      <OUTPUT_FORMAT>
      The output format must be
      1.
      2.
      ...
      </OUTPUT_FORMAT>

      <FEW_SHOT_EXAMPLES>
      Here we provide some examples:
      1. Example #1
          Input:
          Thoughts:
          Output:
      ...
      </FEW_SHOT_EXAMPLES>

      <RECAP>
      Re-emphasize the key aspects of the prompt, especially the constraints, output format, etc.
      </RECAP>

最佳做法

提示設計最佳做法包括：

提示健全度檢查清單

如果提示成效不彰，請使用下列檢查清單找出潛在問題，並提升成效。

寫作問題

  • 錯別字：檢查關鍵字 (例如「summarize」而非「summarize」)、技術用語或實體名稱是否拼字錯誤，因為這些錯誤可能會導致成效不佳。
  • 文法：確保句子文法正確且容易理解。避免使用冗長句子、主詞和動詞不一致，或可能造成模型混淆的結構。
  • 標點符號：確認逗號、句號和引號等標點符號使用正確，因為標點符號錯誤可能會導致誤解。
  • 未定義的術語：定義任何領域專用術語、縮寫或首字母縮略字。請勿假設模型知道這些資訊。
  • 清楚明瞭：如果提示的範圍、必要步驟或基本假設不明確，模型可能會誤解工作。確保所有指令都明確。
  • 模糊不清：以可測量的客觀限制 (例如「三句話以內」) 取代主觀的限定詞 (例如「簡短」)。
  • 缺少重要資訊：提供所有必要背景資訊。如果任務需要特定文件、政策或資料集，請在提示中提供相關資訊。
  • 用字不當：使用清晰簡潔的語言。避免使用過於複雜、模糊或冗長的措辭，以免模型產生混淆。
  • 二次審查：如果模型成效沒有提升，請同事審查提示。從不同角度出發，往往能發現您可能錯過的問題。

操作說明和範例有問題

  • 明顯操縱：請勿嘗試以情緒訴求、奉承或威脅來影響模型 (例如「這件事非常重要」)。雖然這有時適用於舊版模型，但可能會降低現有模型的效能。
  • 指令和範例互相衝突：稽核提示，找出矛盾之處。請確保操作說明不會互相衝突，也不會與提供的範例衝突。
  • 多餘的指令和範例：移除多餘的資訊。除非能提供新資訊或細微差異，否則請避免重複說明相同的指示或概念。
  • 無關的指令和範例：請確保所有指令和範例都與核心工作相關。移除可省略的特徵，以免影響模型效能。
  • 使用「少量樣本」範例：對於複雜的工作、特定格式或細微的語氣，請提供具體的少量樣本範例，展示所需的輸入/輸出模式。
  • 缺少輸出格式規格：明確定義所需的輸出格式。請勿讓模型猜測。在少量樣本範例中強化格式。
  • 缺少角色定義：如果模型應採用特定形象或角色，請在系統指令中清楚定義。

提示和系統設計問題

  • 規格不足的任務：指定如何處理極端情況、非預期的輸入內容和遺漏資料。請勿假設所有提供的資料都是完整且格式正確。
  • 超出模型能力範圍的任務：請確認任務在模型已知的能力範圍內。避免要求執行有基本限制的任務。
  • 工作過多：請避免在單一提示中要求模型執行過多不同的工作 (例如摘要、擷取實體和翻譯)。將複雜的工作流程拆成多個簡單的提示。
  • 非標準資料格式：如要輸出機器可解讀的內容，請使用可剖析的標準格式，例如 JSON、XML、Markdown 或 YAML。如需自訂格式，請先讓模型生成標準格式，然後再使用自己的程式碼轉換格式。
  • 思考鏈 (CoT) 順序有誤：使用思考鏈 (CoT) 時，請確保範例先顯示逐步推理過程，再顯示最終答案。
  • 內部參照衝突：提示應具有邏輯結構。避免使用非線性邏輯或分散的指令，導致模型必須從提示的不同部分拼湊出工作。
  • 提示詞注入風險：防範提示詞注入。將不受信任的使用者輸入內容插入提示時，請務必採取明確的安全措施。

後續步驟