本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

高级主题和策略

本页面上的主题

Multi-objective 优化

高级提示优化每次运行接受一个指标，即每个样本一个标量分数。但是，它隐含地支持多目标（多维）优化：您可以将多个目标捆绑到一个标量（复合指标）中，然后该服务会针对该捆绑包优化提示。本节介绍我们推荐的模式、每种模式何时合适，以及需要注意的故障模式。

这适用于各个垂直行业——任何你同时关心不止一件事的地方：准确性+语气、工具调用正确性+安全性、忠诚度+简洁性、延迟友好性+完整性等等。

为什么一个指标实际上是多目标的

关于该系统的两个事实使它起作用：

因此，“每次运行一个指标” 是关于信号形状的合约，而不是对你可以优化的内容的限制。

将多个目标捆绑成单个指标的模式

根据您的目标相互关联来选择一个。

模式 1 — 加权和（最常见）

final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ，权重之和为 1。

何时使用：目标大致独立，你可以对它们进行排名。 Trade-offs 是可以接受的 —— 只要总和增加，以牺牲另一种为代价来改进一个是可以的。

选择权重：

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

final = 0.5 * tool_correctness + 0.3 * answer_correctness + 0.2 * format_compliance

模式 2 — Hard-fail 大门（安全关键）

定义一个或多个门控目标。如果任何一扇门失效，则无论其余门如何，分数都是 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 泄露、修改了错误的账户、拒绝禁止的内容）。每当 “平均良好” 提示不可接受，即使偶尔也无法通过安全栏时，请使用此选项。

为什么这胜过了仅仅加权：仅凭权重，优化器就可以用安全性与质量进行权衡，同时仍然可以攀登分数。大门通过施工使权衡变得不可能。

模式 3 — 约束 + 奖励 (Pareto-style)

选择最重要的目标作为奖励。将其余部分表示为约束，当违反这些限制时，会从奖励中减去（而不是将其归零）。

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 指标计算确定性子分数（正则表达式、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 提示生成单个复合乐谱要干净一些，因为确定性部分不会逐次漂移。

模式 5 — Multi-dimension LLM-as-a-Judge （没有 Lambda）

使用内置 LLM-as-a-Judge 流程，也可以使用定义自己的尺寸和权重的流程。customLLMJConfig.customLLMJPrompt评委发出每个维度的分数和Overall；系统将解析为 [0, 1] 标量Overall（如果缺失，Overall则为维度求平均值）。

何时使用：您的所有目标都是语义/模糊的，并且没有确定性的子检查。创作速度最快。注意判断方差 — 重新运行相同的数据集两次，并先查看分数稳定性，然后再将其视为优化信号。

选择图案

你可以组合图案。典型的生产指标是 “加权总和+安全方面的硬失败门”。

需要注意的故障模式

Pre-launch 清单

优化多回合和分阶段提示

高级提示优化针对每个样本的评估优化单个提示模板。它本身不是回合感知型的——它无法在对话框中迭代对话框或在特定转弯处优化行为。分阶段提示是一种提示模板，其中多回合对话或工作流程在回合中重复使用相同的提示，提示本身包含工作流程每个阶段、步骤或阶段的说明。要优化这些提示，请将对话框状态扁平化为模板的输入变量，烘焙你想要完善的系统指令promptTemplate，然后用每个样本的参考响应来探测你真正关心的转弯。

这种模式是垂直不可知的。它适用于在不断增长的背景下反复调用模型的任何地方，包括客户服务流程、代理工具使用循环、多步推理、辅导、代码助手轮换、基于文档的 QA、分类工作流程等。

高级提示优化实际上优化了什么

任何你想要优化的东西都必须存在于其本promptTemplate身。每个样本的不同之处（对话历史记录、当前用户查询、检索到的上下文）是{{variables}}。你想要完善的系统指令是模板的一部分，从来都不是输入变量，或者服务没有什么可重写的。

如果您希望服务在回合 N 时改善行为，请将回合 N 表示为一个样本的渲染提示加输入变量，并作为所需的回合 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..."
}

优缺点

优点：反馈信号紧凑，提示更小，优化运行速度更快，更容易制定有针对性的指标。

缺点：没有 catch 跨阶段漂移；你将在每个阶段运行一次该服务，可能需要进行最终的集成测试。

模式 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 的注意事项

Tool-call 在特定转弯处进行验证

该服务会看到助手的文本输出。要评分 “模型在回合 N 时是否使用正确的参数调用了工具 X”，请选择一个：

有关多回合或许多子检查的复合标准（工具正确性以及音调和完整性），请参阅部分。Multi-objective 优化

推荐路径

何时不使用高级提示优化进行多回合

入门清单