Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Sujets et stratégies avancés

Rubriques de cette page

Multi-objective optimisation

Advanced Prompt Optimization accepte une métrique par analyse, soit un score scalaire unique par échantillon. Cependant, il prend implicitement en charge l'optimisation multi-objectifs (multidimensionnelle) : vous pouvez regrouper plusieurs objectifs dans un seul scalaire (une métrique composite) et le service optimise l'invite en fonction de cet ensemble. Cette section décrit les modèles que nous recommandons, lorsque chacun est approprié, ainsi que les modes de défaillance à surveiller.

Cela s'applique à tous les secteurs verticaux, partout où vous vous intéressez à plus d'une chose à la fois : précision + ton, exactitude de l'appel d'outil + sécurité, fidélité + concision, respect de la latence + exhaustivité, etc.

Pourquoi une métrique est en fait multi-objectifs

Deux faits concernant le système permettent de le faire fonctionner :

Ainsi, « une métrique par exécution » est un contrat concernant la forme du signal, et non une limite quant à ce pour quoi vous pouvez optimiser.

Modèles pour regrouper plusieurs objectifs en une seule métrique

Choisissez-en un en fonction de la façon dont vos objectifs sont liés les uns aux autres.

Schéma 1 — Somme pondérée (la plus courante)

final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ, avec des poids totalisant 1.

Quand les utiliser : Les objectifs sont à peu près indépendants et vous pouvez les classer. Trade-offs sont acceptables — améliorer l'un au détriment de l'autre est acceptable tant que la somme augmente.

Choix des poids :

Exemple (utilisation d'une agence ou d'un outil) :

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

Schéma 2 — Hard-fail barrières (critiques pour la sécurité)

Définissez un ou plusieurs objectifs de contrôle. Si une porte échoue, le score est de 0 (ou d'un étage) indépendamment du reste. Sinon, le score est la somme pondérée des objectifs restants.

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

Quand utiliser : Au moins un objectif n'est pas négociable (fuite d'informations personnelles, mauvais compte modifié, refus de contenu interdit). Utilisez-le chaque fois qu'une indication « bonne en moyenne » est inacceptable si elle échoue à la barre de sécurité, même occasionnellement.

Pourquoi cela vaut mieux que la simple pondération : rien qu'avec les poids, l'optimiseur peut comparer sécurité et qualité tout en augmentant le score. Un portail rend le compromis impossible par construction.

Schéma 3 — Contrainte + récompense (Pareto-style)

Choisissez l'objectif le plus important comme récompense. Exprimez le reste sous forme de contraintes qui, lorsqu'elles ne sont pas respectées, sont déduites de la récompense (plutôt que de la remettre à zéro).

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)

Quand l'utiliser : vous voulez qu'un objectif principal soit le leader, mais les objectifs secondaires secondaires doivent tout de même influencer l'invite. Moins fragile que les portes fixes, moins ambiguë que les sommes pondérées.

Motif 4 — Lambda extérieur, LLM-as-a-Judge intérieur (recommandé pour les mélanges flous et structuraux)

Une métrique Lambda calcule des sous-scores déterministes (regex, analyse JSON, validation de schéma) et appelle une LLM-as-a-Judge sous-évaluation pour les parties floues (ton, fidélité, utilité) de la fonction Lambda. Il les regroupe ensuite en un seul scalaire.

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

Quand l'utiliser : Vos objectifs associent « facile à tester en code » (formats, noms des outils, longueur, présence de citations) à « a besoin d'un modèle pour juger » (ton, fidélité, utilité). C'est souvent plus simple que de demander à une seule LLM-as-a-Judge invite de produire un seul score composite, car les parties déterministes ne dériveront pas d'une série à l'autre.

Motif 5 — Multi-dimension LLM-as-a-Judge (pas de Lambda)

Utilisez le LLM-as-a-Judge flux intégré, éventuellement avec un flux customLLMJConfig.customLLMJPrompt qui définit vos propres dimensions et pondération. Le juge émet des scores par dimension et un Overall ; le système analyse Overall (ou fait la moyenne des dimensions si elles Overall sont manquantes) dans un scalaire [0, 1].

Quand l'utiliser : tous vos objectifs sont sémantiques/flous et vous n'avez pas de sous-vérifications déterministes. Le plus rapide à créer. Surveillez l'évaluation de la variance : relancez deux fois le même jeu de données et examinez la stabilité du score avant de le considérer comme signal d'optimisation.

Choisir un motif

Vous pouvez combiner des motifs. Un indicateur de production typique est « somme pondérée + seuil de sécurité irréprochable ».

Modes de défaillance à surveiller

Pre-launch liste de contrôle

Optimisation des instructions à plusieurs tours et par étapes

Advanced Prompt Optimization optimise un modèle d'invite unique par rapport aux évaluations par échantillon. Il ne prend pas en compte les virages de manière native : il ne peut pas itérer sur une boîte de dialogue ou optimiser le comportement à un tour spécifique de manière native. Une invite par étapes est un modèle d'invite dans lequel une conversation ou un flux de travail à plusieurs tours réutilise la même invite à tour de rôle, et l'invite elle-même contient des instructions pour chaque étape, étape ou phase du flux de travail. Pour optimiser ces instructions, aplatissez l'état de la boîte de dialogue dans les variables d'entrée du modèle, intégrez les instructions système que vous souhaitez affiner dans le fichier et analysez les promptTemplate tournants qui vous intéressent réellement à l'aide de réponses de référence par échantillon.

Ce schéma est indépendant de la verticale. Il s'applique partout où un modèle est invoqué à plusieurs reprises dans un contexte croissant : flux de service client, boucles d'utilisation des outils agentiques, raisonnement en plusieurs étapes, tutorat, tours d'assistant de code, assurance qualité basée sur des documents, flux de travail de triage, etc.

Ce que l'optimisation rapide avancée permet réellement d'optimiser

Tout ce que vous voulez optimiser doit vivre à l'intérieur de promptTemplate lui-même. Les éléments qui varient d'un échantillon à l'autre (l'historique des conversations, la requête actuelle de l'utilisateur, le contexte récupéré) sont les suivants{{variables}}. Les instructions système que vous souhaitez affiner font partie du modèle. Il ne s'agit jamais d'une variable d'entrée, sinon le service n'a rien à réécrire.

Si vous souhaitez que le service améliore le comportement au virage N, exprimez le tour N sous la forme de variables d'invite et d'entrée rendues pour un échantillon, la sortie du modèle Turn-N souhaitée. referenceResponse

Schéma A — Stage-at-a-time (entrée recommandée)

Optimisez une phase du dialogue à la fois. Chaque échantillon d'évaluation représente un point de décision unique au cours de cette phase.

Une « étape » est tout ce que vous pouvez décrire avec un ensemble cohérent de critères de réussite. Exemples par ordre vertical :

Quand utiliser le modèle A

Forme du gabarit

Les instructions système spécifiques à chaque étape sont intégrées au modèle (c'est ce que le service réécrit). Seuls l'historique des conversations et la tournure actuelle sont des variables. La structure ci-dessous est illustrative et n'est pas prescrite. Utilisez les délimiteurs ou la disposition que votre modèle gère le mieux. Les seules exigences sont les suivantes : (a) les instructions système que vous souhaitez optimiser en direct dans le modèle, et (b) les variables par échantillon sont référencées comme{{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}}

Forme de l'échantillon

{
    "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..."
}

Avantages et inconvénients

Avantages : signal de retour précis, instructions plus petites, optimisations plus rapides, création plus facile d'une métrique ciblée.

Inconvénients : ne détecte pas la dérive entre les étapes ; vous exécuterez le service une fois par étape et vous aurez peut-être besoin d'un test d'intégration final.

Schéma B — Conversation entièrement aplatie (avancé)

Optimisez une seule grande invite monolithique qui gère l'intégralité de la politique en plusieurs étapes. Chaque échantillon est le dialogue complet jusqu'à un tour de sonde.

Quand utiliser le modèle B

Forme du gabarit

L'invite du système monolithique et multiphasique complet se trouve littéralement à l'intérieur du modèle. Le service réécrit ce corps lors de l'optimisation. L'historique et la tournure actuelle restent variables. Choisissez la mise en page que votre modèle gère bien ; les exigences sont uniquement que les instructions à optimiser fassent partie du modèle et que les données par échantillon soient référencées. {{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}}

Forme de l'échantillon (sonde à n'importe quel tour 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..."
}

Pourquoi le modèle B peut fonctionner mieux que le modèle A

Mises en garde concernant le modèle B

Tool-call vérification à un moment précis

Le service voit la sortie de texte de l'assistant. Pour évaluer « le modèle a-t-il appelé l'outil X avec les bons arguments au virage N », choisissez-en une :

Pour les critères composites relatifs à de nombreux tours ou à de nombreuses sous-vérifications (exactitude de l'outil, ton et exhaustivité), consultez la section. Multi-objective optimisation

Parcours recommandé

Quand ne pas utiliser l'optimisation rapide avancée pour les opérations multitours

Liste de contrôle pour débutants