本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

進階主題和策略

本頁主題

多目標最佳化

進階提示最佳化每次執行接受一個指標 — 每個範例單一純量分數。不過，它隱含支援多目標 （多維度） 最佳化：您可以將多個目標綁定在一個純量 （複合指標） 中，服務會根據該綁定最佳化提示。本節涵蓋我們建議的模式、何時適合，以及要注意的失敗模式。

這適用於垂直 - 任何您同時關心多個物件的位置：準確性 + 音調、工具呼叫正確性 + 安全性、忠於 + 簡潔性、延遲親和性 + 完整性等。

為什麼一個指標實際上是多目標指標

有關系統的兩個事實使此工作生效：

因此「每次執行一個指標」是有關訊號形狀的合約，而不是您可以最佳化的項目限制。

將多個目標綁定到單一指標的模式

根據目標彼此的關係選擇一個。

模式 1 — 加權總和 （最常見）

final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ，權重加總為 1。

使用時機：目標大致獨立，您可以對其進行排名。可以接受權衡 — 只要總和增加，可以用其他權衡的方式改善一個權衡。

選擇權重：

範例 （代理/工具使用）：

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】 純量。

使用時機：您的所有目標都是語意/模糊，而且您沒有確定性的子檢查。撰寫速度最快。注意判斷差異 - 重新執行相同的資料集兩次，並查看分數穩定性，然後再將其信任為最佳化訊號。

選擇模式

您可以結合模式。典型的生產指標是「加權總和 + 安全上的硬失敗閘道」。

要監看 的失敗模式

啟動前檢查清單

最佳化多迴轉和暫存提示

進階提示最佳化針對每個範例評估最佳化單一提示範本。它本質上不會轉感知 - 它無法重複對話或原生在特定轉彎時最佳化行為。階段式提示是提示範本，其中多迴轉對話或工作流程會輪流重複使用相同的提示，而提示本身包含工作流程每個階段、步驟或階段的指示。若要最佳化這些提示，請將對話方塊狀態扁平化為範本的輸入變數、將您想要精簡的系統指示製作到 中promptTemplate，並使用每個範例參考回應探查您實際關心的轉彎。

此模式與垂直無關。它適用於透過不斷增長的內容重複調用模型的任何位置：客戶服務流程、代理工具使用迴圈、多步驟推理、教學、程式碼輔助輪換、文件基礎 QA、分類工作流程等。

進階提示最佳化實際最佳化的內容

您想要最佳化的任何項目都必須存在於 promptTemplate 本身內。每個範例不同的物件 （對話歷史記錄、目前使用者查詢、擷取的內容） 為 {{variables}}。您想要精簡的系統指示是範本的一部分，絕不是輸入變數，或服務也無需重寫。

如果您希望服務在轉 N 時改善行為，請將轉 N 表達為一個範例的轉譯 prompt-plus-input-variables，而 referenceResponse是所需的轉 N 模型輸出。

模式 A — Stage-at-a-time（建議啟動者）

一次最佳化一個階段的對話方塊。每個評估範例代表該階段內的單一決策點。

此處的「階段」是您可以使用一組一致的成功條件來描述的內容。垂直範例：

何時使用模式 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

範本形狀

完整的單體多階段系統提示實際上位於範本內。服務會在最佳化期間重寫此內文。歷史記錄和目前輪換會保留變數。選擇模型妥善處理的任何配置；要求只有要最佳化的指示是範本的一部分，而每個範例資料是透過 參考{{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 更有效

模式 B 的注意事項

特定輪換的工具呼叫驗證

服務會看到助理的文字輸出。若要分級「模型呼叫工具 X 在轉 N 時有右引數」，請選擇一個：

如需多個回合或多個子檢查的複合條件 （工具正確性、色調和完整性），請參閱多目標最佳化一節。

建議的路徑

何時不對多迴轉使用進階提示最佳化

入門檢查清單