本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 進階主題和策略 ## 本頁主題 + [多目標最佳化](#advanced-prompt-optimization-multi-objective) + [最佳化多迴轉和暫存提示](#advanced-prompt-optimization-multi-turn) ## 多目標最佳化進階提示最佳化每次執行接受一個指標 — 每個範例單一純量分數。不過，它隱含支援多目標（多維度）最佳化：您可以將多個目標綁定在一個純量（複合指標）中，服務會根據該綁定最佳化提示。本節涵蓋我們建議的模式、何時適合，以及要注意的失敗模式。這適用於垂直 - 任何您同時關心多個物件的位置：準確性 \+ 音調、工具呼叫正確性 \+ 安全性、忠於 \+ 簡潔性、延遲親和性 \+ 完整性等。 ### 為什麼一個指標實際上是多目標指標有關系統的兩個事實使此工作生效： + **指標會傳回每個範例的單一浮點值。**最佳化回饋迴圈會將此純量讀取為最佳化訊號。您可以從任何數量的子分數進行計算。 + **兩個指標後端已在內部彙總子分數。** + 預設 LLM-as-a-Judge 範本的三個維度分級（答案準確性、答案完整性、表達品質）、指派權重，並發出標準化為【0， 1】的單一`Overall`分數。自訂條件會合併到相同的純量中。如需詳細資訊，請參閱[自訂 LLM-as-a-judge](advanced-prompt-optimization-evaluation.md#advanced-prompt-optimization-evaluation-llmj)。 + Lambda / 自訂程式碼指標會傳回一個數字，而您可以控制其運算方式，包括任何子物件的複合。因此「每次執行一個指標」是有關訊號形狀的合約，而不是您可以最佳化的項目限制。 ### 將多個目標綁定到單一指標的模式根據目標彼此的關係選擇一個。 #### 模式 1 — 加權總和（最常見） `final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ`，權重加總為 1。 **使用時機：**目標大致獨立，您可以對其進行排名。可以接受權衡 — 只要總和增加，可以用其他權衡的方式改善一個權衡。 **選擇權重：** + 對使用者的重要性加權，而不是資料集中的頻率加權。 + 開始粗略：`0.5 / 0.3 / 0.2`沒問題。請勿過度調校權重，這是個別的最佳化問題。 **範例（代理/工具使用）：** ``` final = 0.5 * tool_correctness + 0.3 * answer_correctness + 0.2 * format_compliance ``` #### 模式 2 — 硬失敗閘道（安全關鍵）定義一或多個門控目標。如果有任何閘道失敗，無論其餘的分數為 0 （或一些樓層）。否則，分數是剩餘目標的加權總和。 ``` if not safety_check_passed: return 0.0 if wrong_tool_called_for_destructive_action: return 0.0 return 0.6 * accuracy + 0.4 * tone ``` **使用時機：**至少一個目標不可協商 (PII 洩漏、修改錯誤帳戶、refusal-on-prohibited-content)。每當出現「平均良好」提示時，即使偶爾未通過安全列，也請使用此選項。 **為什麼這比僅權重高：**光是權重，最佳化工具就可以將安全性與品質進行交易，並且仍能提升分數。閘道讓建構無法權衡。 #### 模式 3 — 限制 \+ 獎勵 (Pareto 樣式）選擇最重要的目標做為獎勵。將其餘部分表達為在違反時從獎勵中減去的限制（而不是將其歸零）。 ``` reward = task_accuracy penalty = 0.0 if response_too_long: penalty += 0.1 if missed_required_disclosure: penalty += 0.2 return max(0.0, reward - penalty) ``` **使用時機：**您希望一個主要目標領導，但軟次要目標仍應塑造提示。比硬閘道更脆弱，比加權總和更不明確。 #### 模式 4 — Lambda 外部、LLM-as-a-Judge 內部（建議用於模糊 \+ 結構混合） Lambda 指標會計算確定性子分數 (regex、JSON 剖析、結構描述驗證），並呼叫 Lambda 函數內模糊部分（色調、忠誠度、實用性）的 LLM-as-a-Judge 子評估。然後，它會將其彙總為一個純量。 ``` def compute_score(prompt, prediction, gold, ...): structural = grade_format_and_tools(prediction) # 0..1 from regex semantic = call_llm_judge(prediction, gold, criteria) # 0..1 from LLMJ if structural < 1.0 and is_safety_critical(prompt): return 0.0 return 0.6 * semantic + 0.4 * structural ``` **使用時機：**您的目標將「易於測試程式碼」（格式、工具名稱、長度、引文是否存在）與「需要判斷的模型」（色調、忠實、實用性）混合在一起。這通常比要求一個 LLM-as-a-Judge 提示產生單一複合分數更乾淨，因為確定性部分不會偏離run-to-run。 #### 模式 5 — 多維度 LLM-as-a-Judge （無 Lambda) 使用內建 LLM-as-a-Judge 流程，選擇性地搭配 `customLLMJConfig.customLLMJPrompt`來定義您自己的維度和加權。判斷會發出每個維度分數和 `Overall`；系統會將維度剖析 `Overall`（如果`Overall`遺失，則平均）為【0， 1】純量。 **使用時機：**您的所有目標都是語意/模糊，而且您沒有確定性的子檢查。撰寫速度最快。注意判斷差異 - 重新執行相同的資料集兩次，並查看分數穩定性，然後再將其信任為最佳化訊號。 ### 選擇模式 | \# | 您有... | 使用 | | --- | --- | --- | | 1 | 2–4 個模糊目標，所有語意 | 模式 5 （多維度 LLM-as-a-Judge) | | 2 | 2-4 個混合結構和語意的目標 | 模式 4 (Lambda 外部 \+ LLM-as-a-Judge 內部） | | 3 | 至少一個不可協商的安全性/正確性條件 | 模式 2 （硬失敗閘道） — 結合 1 或 4 | | 4 | 一個明確的主要目標 \+ 軟偏好設定 | 模式 3 （限制 \+ 獎勵） | | 5 | 數個大致相等的獨立目標 | 模式 1 （加權總和） | 您可以結合模式。典型的生產指標是「加權總和 \+ 安全上的硬失敗閘道」。 ### 要監看的失敗模式 + **獎勵表面形式的駭客攻擊。**如果您的子分數為「回應是否包含「sure」一詞，最佳化工具會將強制「sure」的提示寫入每個輸出。相較於關鍵字存在，偏好結果基礎子分數（工具名稱、槽值、結構有效性）。 + **判斷偏離。**多重維度 LLM-as-a-Judge 指標，其權重因每次呼叫而異（因為會要求判斷者選擇），可提供雜訊最佳化訊號。在自訂條件中固定權重，或將維度權重移入 Lambda 程式碼。 + **複合分數飽和。**如果指標快速達到 0.95 並停留在那裡，則您的子分數太寬鬆。收緊摩擦；考慮提高最大長條（例如，部分額度變成 0 而不是 1)，以便最佳化工具有空間。 + **子目標直接衝突。**「簡潔」與「完整」是真正的取捨。加權總和模式會挑選該邊界上的操作點；如果您不喜歡，請變更權重。 ### 啟動前檢查清單 + 在完整資料集的初始提示上計算指標，並檢查每個維度平均值，而不只是純量。如果一個維度已經飽和，請考慮將其從套件中捨棄。 + 手動 Spot 檢查 5 個範例。指標的判斷是否符合您的判斷？如果沒有，請在最佳化提示之前修正指標。 ## 最佳化多迴轉和暫存提示進階提示最佳化針對每個範例評估最佳化單一提示範本。它本質上不會轉感知 - 它無法重複對話或原生在特定轉彎時最佳化行為。*階段式提示*是提示範本，其中多迴轉對話或工作流程會輪流重複使用相同的提示，而提示本身包含工作流程每個階段、步驟或階段的指示。若要最佳化這些提示，請將對話方塊狀態扁平化為範本的輸入變數、將您想要精簡的系統指示製作到中`promptTemplate`，並使用每個範例參考回應探查您實際關心的轉彎。此模式與垂直無關。它適用於透過不斷增長的內容重複調用模型的任何位置：客戶服務流程、代理工具使用迴圈、多步驟推理、教學、程式碼輔助輪換、文件基礎 QA、分類工作流程等。 ### 進階提示最佳化實際最佳化的內容 + **輸入：**具有`{{placeholder}}`變數的`promptTemplate`字串。 + **每個範例：**每個 `evaluationSamples[i]` 會提供這些變數和的值`referenceResponse`。最佳化工具會根據每個範例獨立執行推論、評估、意見回饋和重寫，然後彙總跨範例的指標。 + **輸出：**精簡的 `promptTemplate`。變數、資料集和指標都是固定的輸入；只有範本會變更。您想要最佳化的任何項目都必須存在於 `promptTemplate` 本身內。每個範例不同的物件（對話歷史記錄、目前使用者查詢、擷取的內容）為 `{{variables}}`。您想要精簡的系統指示是範本的一部分，絕不是輸入變數，或服務也無需重寫。如果您希望服務在轉 N 時改善行為，請將轉 N 表達為一個範例的轉譯 prompt-plus-input-variables，而 `referenceResponse`是所需的轉 N 模型輸出。 ### 模式 A — Stage-at-a-time（建議啟動者）一次最佳化一個階段的對話方塊。每個評估範例代表該階段內的單一決策點。此處的「階段」是您可以使用一組一致的成功條件來描述的內容。垂直範例： + **代理程式/工具使用：**計劃形式輪換、工具選擇輪換、tool-result-interpretation輪換、最終答案輪換。 + **客戶支援：**接收、驗證、動作、確認、關閉。 + **教學/教育：**評估知識、解釋概念、檢查理解、總結。 + **文件 QA：**擷取基礎答案、後續釐清、引用輪換。 + **編碼助理：**規格釐清、程式碼產生、程式碼預覽/修正、測試寫入。 #### 何時使用模式 A + 您可以命名具有不同成功條件的不同階段。 + 一個階段正在向下拖曳品質，您想要在不干擾他人的情況下修正它。 + 您想要快速反覆運算和緊密、可偵錯的回饋訊號。 #### 範本形狀階段特定的系統指示會製作成範本（這是服務重寫的內容）。只有對話歷史記錄和目前回合是變數。以下結構是說明性的，而非規定。使用模型處理最佳的分隔符號或配置。唯一的要求是：(a) 您希望在範本內即時最佳化的系統指示，以及 (b) 每個範例變數參考為 `{{variablename}}`。 ``` You are an assistant in the {STAGE_NAME} phase of a multi-turn task. - ...the policy / goals / format / tool-use rules for this phase... - ...constraints the model must satisfy at this point in the conversation... Conversation so far: {{conversation_so_far}} User's current message: {{user_query}} ``` #### 範例形狀 ``` { "inputVariables": [ {"conversation_so_far": "user: ...\nassistant: ...\n... (turns 1..N-1)"}, {"user_query": "...the user input that triggers this stage..."} ], "referenceResponse": "...the assistant output that satisfies the stage's success criteria..." } ``` #### 優點和缺點 **優點：**緊密的意見回饋訊號、較小的提示、更快的最佳化執行、更容易撰寫聚焦指標。 **Cons：**不會捕捉跨階段偏離；每個階段您將執行一次服務，而且可能需要最終整合測試。 ### 模式 B — 完全平面化對話（進階）最佳化一個擁有整個多階段政策的大型整體提示。每個範例都是完整對話方塊，直到探查轉彎為止。 #### 何時使用模式 B + 您的生產提示已經是單體，而且您不想將其分割。 + 您希望最佳化工具查看較早的輪換如何設定後續輪換，因此其重寫會保留跨階段流程。 + 探測周轉的正確性取決於跨階段建置的內容（例如，「透過周轉 N，必須已參考正確的事實」或「必須已呼叫正確的工具」)。 #### 範本形狀完整的單體多階段系統提示實際上位於範本內。服務會在最佳化期間重寫此內文。歷史記錄和目前輪換會保留變數。選擇模型妥善處理的任何配置；要求只有要最佳化的指示是範本的一部分，而每個範例資料是透過參考`{{name}}`。 ``` You are an assistant for {TASK}. The conversation may proceed through phases: 1. {PHASE_1} — ... 2. {PHASE_2} — ... 3. {PHASE_3} — ... (...the entire multi-phase policy, tool-use rules, tone, formatting, refusal rules...) Conversation so far (turns 1..N-1, with role tags): {{conversation_so_far}} User's current message: {{user_query}} ``` #### 範例形狀（在 N 轉的任何時間探查） ``` { "inputVariables": [ {"conversation_so_far": "user: ...\nassistant: ...\n[tool_call: X(...)]\n... (turns 1..N-1)"}, {"user_query": "...the user input at turn N..."} ], "referenceResponse": "...desired assistant output at turn N..." } ``` #### 為什麼模式 B 比模式 A 更有效 + 最佳化工具會在中看到階段進展`conversation_so_far`，因此最佳化意見回饋可以一次跨階段推理。 + 單一最佳化提示會部署，而不會將多個最佳化階段提示拼接在一起，從而減少後續處理。 #### 模式 B 的注意事項 + **隨機性的較舊輪換。**生產助理輪換不一定`conversation_so_far`完全符合標準。將固定歷史記錄視為預期軌跡；在生產環境中，稍早的偏離可能會使最佳化失效。使用代表性的真實對話擷取，而不是合成的快樂路徑。 + **字符成本。**長歷史記錄氣球每試驗推論成本。服務會執行許多候選者 × 範例 × 反覆運算。預算相應，如果成本是瓶頸，請考慮截斷到最近的 K 輪換加上摘要。 + **參考回應偏差。** `referenceResponse`應該是正確的助理根據該歷史記錄所說的內容。如果您的參考回應太窄（只有一個可接受的措辭），最佳化工具會過度適應它。盡可能偏好將結果（工具名稱、槽值、決策）分級為表面格式比對的指標。 ### 特定輪換的工具呼叫驗證服務會看到助理的文字輸出。若要分級「模型呼叫工具 X 在轉 N 時有右引數」，請選擇一個： + **輸出慣例：**讓助理在 Lambda 指標中使用 regex/JSON 剖析發出結構式字符，例如 `X(arg=...)`和等級。最便宜、最可靠。 + **LLM-as-a-Judge 自訂條件：**提供 `customLLMJPrompt`以詢問判斷：「回應 (a) 名稱為工具 `X`、(b) 包含引數 `arg`、(c) 符合所需的措辭 `Y`？」每個子檢查都是 \+1；彙總。易於撰寫，變異更多。 + **具有下游模擬的 Lambda 指標：**如果您有工具執行工具，請執行模型輸出，並對觀察到的副作用進行評分。最高保真度，大多數設定。如需多個回合或多個子檢查的複合條件（工具正確性、色調和完整性），請參閱[多目標最佳化](#advanced-prompt-optimization-multi-objective)一節。 ### 建議的路徑 + 從最有害品質階段的**模式 A 開始**。取得工作指標、20–50 個範例資料集，以及一個end-to-end執行。這會先驗證您的資料集和指標，再投資較大的模式 B 執行。 + **然後使用完整的單體提示和多物件複合指標執行一次模式 B**，以擷取模式 A 可能會遺漏的跨階段迴歸。 + **在反覆提示之前反覆運算資料集。**如果服務的重寫 hill-climb 您的指標，但生產行為未改善，則指標或資料集通常是問題所在。 ### 何時不對多迴轉使用進階提示最佳化 + **對話方塊政策/狀態機器錯誤** （階段轉換邏輯錯誤）：一般提示重寫無法修正此問題。首先修正協同運作層。 + **工具結構描述錯誤：**服務不會變更工具定義。它只能變更要求模型使用它們的提示。 + **標準歷史記錄和即時歷史記錄之間的偏離：**如果真實對話在幾圈後從您的評估樣本中大幅偏離，則模式 B 的最佳化訊號會較弱。除了理想狀態之外，擷取真正可接受的生產追蹤以進行最佳化執行也會在這裡提供協助。 + **必要行為取決於最佳化工具從未看到的私有狀態** （例如，模型僅透過工具呼叫學習的使用者帳戶資料）：`conversation_so_far`讓探查範例在中明確顯示該狀態，或接受服務只能調整表面行為。 ### 入門檢查清單 + 選擇您關心的探查轉彎。每個都會成為一或多個範例。 + 決定模式 A 或 B （或兩者 - 先決定，再決定 B)。 + 建置 20 多個具有逼真的`conversation_so_far`乾淨`referenceResponse`值的代表性範例。