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-multi-objective) + [Optimisation des instructions à plusieurs tours et à étapes](#advanced-prompt-optimization-multi-turn) ## Multi-objective optimisation Advanced Prompt Optimization accepte une métrique par cycle, soit un score scalaire unique par échantillon. Cependant, il prend implicitement en charge l'optimisation multi-objectifs (multidimensionnelle) : vous pouvez regrouper plusieurs objectifs en un seul scalaire (une métrique composite) et le service optimise l'invite par rapport à 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, partout où vous vous souciez de plus d'une chose à la fois : précision et tonalité, exactitude de l'appel d'outils \+ sécurité, fidélité \+ concision, facilité de latence \+ exhaustivité, etc. ### Pourquoi un indicateur est en fait multi-objectifs Deux faits concernant le système permettent de le faire fonctionner : + **La métrique renvoie une seule valeur flottante par échantillon.** La boucle de rétroaction d'optimisation lit ce scalaire comme signal d'optimisation. Vous pouvez le calculer à partir de n'importe quel nombre de sous-scores. + **Les deux backends métriques agrègent déjà les sous-scores en interne.** + Le LLM-as-a-Judge modèle par défaut note en fonction de trois dimensions (précision des réponses, exhaustivité des réponses, qualité de l'expression), attribue des poids et émet un `Overall` score unique normalisé à [0, 1]. Les critères personnalisés sont fusionnés dans le même scalaire. Pour de plus amples informations, veuillez consulter [Personnalisé LLM-as-a-judge](advanced-prompt-optimization-evaluation.md#advanced-prompt-optimization-evaluation-llmj). + Les métriques Lambda/Custom-Code renvoient un chiffre, et vous pouvez contrôler la façon dont il est calculé, y compris tout ensemble de sous-objectifs. Ainsi, « une métrique par cycle » est un contrat concernant la forme du signal, et non une limite quant à ce que 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. #### Modèle 1 — Somme pondérée (le plus courant) `final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ`, avec des poids dont la somme est égale à 1. **Quand 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 :** + Pondération en fonction de l'importance pour l'utilisateur, et non en fonction de la fréquence dans l'ensemble de données. + Commencez grossièrement : `0.5 / 0.3 / 0.2` c'est bon. Ne surajustez pas les poids, il s'agit d'un problème d'optimisation distinct. **Exemple (agentique/utilisation d'outils) :** ``` final = 0.5 * tool_correctness + 0.3 * answer_correctness + 0.2 * format_compliance ``` #### Modèle 2 — Hard-fail portes (critiques pour la sécurité) Définissez un ou plusieurs objectifs de blocage. Si l'une des portes échoue, le score est de 0 (ou d'un étage), quel que soit le reste. Dans le cas contraire, 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, modification d'un compte erroné, refus de contenu interdit). Utilisez-le chaque fois qu'un message « bon dans la moyenne » est inacceptable s'il ne répond pas à la barre de sécurité, même de temps en temps. **Pourquoi cela vaut mieux que la simple pondération :** avec les poids uniquement, l'optimiseur peut faire la différence entre sécurité et qualité tout en augmentant le score. Une porte rend le compromis impossible en raison de la 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, diminuent la récompense (plutôt que de la réduire à 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 utiliser :** vous voulez qu'un objectif principal mène, mais des objectifs secondaires souples doivent tout de même façonner l'invite. Moins fragile que les barrières rigides, moins ambigües 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 du 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 agrège 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 combinent « facile à tester dans le code » (formats, noms d'outils, longueur, présence de citations) et « nécessite un modèle pour en juger » (ton, fidélité, utilité). C'est souvent plus simple que de demander à une seule LLM-as-a-Judge invite de produire une partition composite unique, car les parties déterministes ne dérivent 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 `customLLMJConfig.customLLMJPrompt` qui définit vos propres dimensions et pondérations. 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 absentes) en un scalaire [0, 1]. **Quand l'utiliser :** tous vos objectifs sont sémantiques/flous et vous n'avez pas de sous-contrôles déterministes. Le plus rapide à écrire. Surveillez l'évaluation de la variance : réexécutez le même jeu de données deux fois et examinez la stabilité du score avant de vous y fier comme signal d'optimisation. ### Choisir un motif | \# | Tu as... | Utilisation | | --- | --- | --- | | 1 | 2 à 4 objectifs flous, tous sémantiques | Motif 5 (multidimensionnel LLM-as-a-Judge) | | 2 | 2 à 4 objectifs mêlant structure et sémantique | Motif 4 (extérieur et intérieur Lambda) LLM-as-a-Judge | | 3 | Au moins un critère non négociable safety/correctness | Motif 2 (porte rigide) — combinez avec 1 ou 4 | | 4 | Un objectif principal clair et des préférences souples | Schéma 3 (contrainte \+ récompense) | | 5 | Plusieurs objectifs indépendants à peu près égaux | Modèle 1 (somme pondérée) | Vous pouvez combiner des motifs. Un indicateur de production typique est « somme pondérée \+ une limite absolue en matière de sécurité ». ### Modes de défaillance à surveiller + **Récompensez le piratage sous forme de surface.** Si votre sous-score est « La réponse contient-elle le mot « sûr » », l'optimiseur écrira des instructions qui forceront le mot « sûr » à chaque sortie. Préférez les sous-scores basés sur les résultats (nom de l'outil, valeur du slot, validité structurelle) à la présence de mots clés. + **Juge Drift.** Une LLM-as-a-Judge métrique multidimensionnelle dont les poids varient par appel (car le juge est invité à les choisir) produit un signal d'optimisation bruyant. Inscrivez les pondérations dans vos critères personnalisés ou déplacez la pondération dimensionnelle dans le code Lambda. + **Le score composite sature.** Si la métrique atteint 0,95 rapidement et s'y maintient, vos sous-scores sont trop indulgents. Resserrez les rubriques ; pensez à relever la barre maximale (par exemple, le crédit partiel devient 0 au lieu de 1) afin que l'optimiseur ait une marge de manœuvre. + **Sub-objectives directement en conflit.** La « concision » par rapport à « l'exhaustivité » est un véritable compromis. Le modèle de somme pondérée choisit un point de fonctionnement sur cette frontière ; si cela ne vous plaît pas, modifiez les pondérations. ### Pre-launch liste de contrôle + Calculez la métrique à l'invite initiale sur l'ensemble de données complet et inspectez les moyennes par dimension, et pas seulement le scalaire. Si une dimension est déjà saturée, pensez à la supprimer du bundle. + Spot-check 5 échantillons à la main. Le verdict de la métrique correspond-il à votre jugement ? Si ce n'est pas le cas, corrigez la métrique avant d'optimiser l'invite. ## Optimisation des instructions à plusieurs tours et à étapes L'optimisation avancée des invites optimise un modèle d'invite unique par rapport aux évaluations par échantillon. Il n'est pas nativement sensible au tour par tour : 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 progressive* est un modèle d'invite dans lequel une conversation ou un flux de travail à plusieurs tours réutilise la même invite d'un tour à l'autre, et l'invite elle-même contient des instructions pour chaque étape, étape ou phase du flux de travail. Pour optimiser ces instructions, adaptez l'état de la boîte de dialogue aux variables d'entrée du modèle, intégrez les instructions système que vous souhaitez affiner et analysez les `promptTemplate` virages qui vous intéressent réellement à l'aide de réponses de référence par échantillon. Ce modèle 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 d'outils agentiques, raisonnement en plusieurs étapes, tutorat, tours d'assistant de code, assurance qualité basée sur des documents, flux de triage, etc. ### Ce que l'optimisation rapide avancée optimise réellement + **Entrée :** `promptTemplate` chaîne de caractères avec des `{{placeholder}}` variables. + **Par échantillon :** Chacun `evaluationSamples[i]` fournit des valeurs pour ces variables et `referenceResponse` a. L'optimiseur effectue l'inférence, l'évaluation, le feedback et la réécriture indépendamment par échantillon, puis agrège la métrique entre les échantillons. + **Résultat :** Un raffiné`promptTemplate`. Les variables, le jeu de données et la métrique sont des entrées fixes ; seul le modèle change. Tout ce que vous voulez optimiser doit vivre à l'intérieur de `promptTemplate` lui-même. Les éléments qui varient selon l'échantillon (l'historique des conversations, la requête utilisateur en cours, le contexte récupéré) sont`{{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 virage N sous la forme des variables d'invite et d'entrée affichées pour un échantillon, la sortie du modèle Turn-N souhaitée étant la sortie souhaitée du modèle Turn-N. `referenceResponse` ### Motif A — Stage-at-a-time (point de départ recommandé) 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 ici tout ce que vous pouvez décrire avec un ensemble cohérent de critères de réussite. Exemples par ordre vertical : + **Utilisation agentique/outil : tour de formation du plan, tour de sélection d'outils**, tour d'interprétation des résultats de l'outil, tour de réponse finale. + **Assistance à la clientèle :** réception, vérification, action, confirmation, clôture. + **Tutorat/éducation :** évaluer les connaissances, expliquer le concept, vérifier la compréhension, résumer. + **Document QA :** réponse basée sur l'extraction, clarification de suivi, tour de citation. + **Assistant de codage :** clarification des spécifications, génération de code, écriture de codereview/fix, test. #### Quand utiliser le modèle A + Vous pouvez nommer des phases distinctes avec des critères de réussite distincts. + L'une des phases consiste à réduire la qualité et vous souhaitez y remédier sans déranger les autres. + Vous avez besoin d'une itération rapide et d'un signal de retour précis et débuggable. #### Forme du modèle Les instructions système spécifiques à l'étape sont intégrées dans le modèle (c'est ce que le service réécrit). Seuls l'historique des conversations et le tour actuel sont des variables. La structure ci-dessous est illustrative, elle 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 se trouvent dans le modèle, et (b) les variables par échantillon sont référencées comme `{{variablename}}` telles. ``` 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 feedback précis, instructions plus petites, optimisations plus rapides, création plus facile d'une métrique ciblée. **Inconvénients :** il ne bloque 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. ### Modèle B — Conversation aplatie complète (avancé) Optimisez une grande invite monolithique contenant l'intégralité de la politique en plusieurs étapes. Chaque échantillon correspond à la boîte de dialogue complète jusqu'à un tour de sonde. #### Quand utiliser le modèle B + Votre invite de production est déjà monolithique et vous ne souhaitez pas la scinder. + Vous voulez que l'optimiseur voie comment les virages précédents configurent les virages ultérieurs, afin que ses réécritures préservent le flux entre les étapes. + L'exactitude au tour de sonde dépend du contexte établi au fil des étapes (par exemple, « au tour N, les bons faits doivent déjà être référencés » ou « le bon outil doit déjà avoir été appelé »). #### Forme du modèle L'invite du système monolithique et multiphase complète se trouve littéralement à l'intérieur du modèle. Le service réécrit ce corps lors de l'optimisation. L'historique et le tour actuel restent variables. Choisissez n'importe quelle mise en page que votre modèle gère bien ; il suffit que les instructions à optimiser fassent partie du modèle et que les données par échantillon soient référencées via`{{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 virage 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 mieux fonctionner que le modèle A + L'optimiseur voit la progression des étapes`conversation_so_far`, de sorte que les commentaires d'optimisation peuvent raisonner d'une étape à l'autre en même temps. + Une seule invite optimisée est déployée sans avoir à assembler plusieurs instructions d'étape optimisées, ce qui réduit le post-traitement pour vous. #### Mises en garde concernant le modèle B + **Stochasticité dans les virages précédents.** Les tours de l'assistant de production ne correspondent pas toujours `conversation_so_far` exactement à ceux enregistrés. Traitez l'historique prédéfini comme la trajectoire attendue ; en production, une dérive lors des tours précédents peut invalider l'optimisation. Utilisez des captures de conversation réelles et représentatives plutôt que des parcours heureux synthétisés. + **Coût du jeton.** Les longs historiques augmentent le coût d'inférence par essai. Le service exécute de nombreux candidats × échantillons × itérations. Établissez votre budget en conséquence et envisagez de le tronquer aux K tours les plus récents et à un résumé si le coût est le goulot d'étranglement. + **Biais de réponse de référence.** `referenceResponse`devrait être ce que dirait un bon assistant compte tenu de cet historique. Si votre réponse de référence est trop étroite (une seule formulation acceptable), l'optimiseur s'y adaptera trop. Dans la mesure du possible, préférez une métrique qui note les résultats (nom de l'outil, valeurs des créneaux, décision) plutôt qu'une correspondance superficielle. ### Tool-call vérification à un tournant précis Le service voit le texte de sortie de l'assistant. Pour évaluer « le modèle a-t-il appelé l'outil X avec les bons arguments au virage N », choisissez-en un : + **Convention en sortie : demandez à** l'assistant d'émettre un jeton structuré semblable à un jeton `X(arg=...)` et de le noter avec regex/JSON analyse dans une métrique Lambda. Le moins cher, le plus fiable. + **LLM-as-a-Judge critères personnalisés :** fournissez un `customLLMJPrompt` qui demande au juge : « La réponse (a) nomme-t-elle l'outil`X`, (b) inclut-elle un argument`arg`, (c) correspond-elle au libellé requis `Y` ? » Chaque sous-vérification vaut \+1 ; agrégé. Facile à créer, plus de variété. + **Métrique Lambda avec simulation en aval :** si vous disposez d'un harnais d'exécution d'outils, faites-y passer le résultat du modèle et évaluez les effets secondaires observés. Fidélité maximale, configuration maximale. Pour les critères composites appliqués à de nombreux virages ou à de nombreux sous-contrôles (exactitude, tonalité et exhaustivité de l'outil), consultez la [Multi-objective optimisation](#advanced-prompt-optimization-multi-objective) section. ### Chemin recommandé + **Commencez par le motif A** sur la scène qui nuit le plus à la qualité. Obtenez une métrique fonctionnelle, un ensemble de données d'échantillons de 20 à 50 et une optimisation de bout en bout. Cela permet de valider votre ensemble de données et votre métrique avant d'investir dans le cycle plus important du Pattern B. + **Exécutez ensuite le modèle B une fois** avec l'invite monolithique complète et une métrique composite à objectifs multiples pour détecter les régressions entre étapes que le modèle A peut manquer. + **Itérez l'ensemble de données avant d'itérer l'invite.** Si les réécritures du service font monter en flèche votre métrique mais que le comportement de production ne s'améliore pas, c'est souvent la métrique ou le jeu de données qui pose problème. ### Quand ne pas utiliser l'optimisation rapide avancée pour les tours multiples + **Politique de dialogue/bogues de la machine à états** (mauvaise logique de transition entre les étapes) : une réécriture complète des instructions ne peut pas résoudre ce problème. Corrigez d'abord la couche d'orchestration. + **Schémas d'outils incorrects :** le service ne modifiera pas les définitions des outils. Il ne peut modifier que l'invite qui demande au modèle de les utiliser. + **Dérive entre l'historique prédéfini et l'historique en temps réel :** si les conversations réelles divergent considérablement de vos échantillons d'évaluation après quelques tours, le signal d'optimisation du modèle B est faible. La capture de véritables traces de production acceptables pour les cycles d'optimisation peut être utile à cet égard, en plus de l'état idéal. + Le **comportement requis dépend de l'état privé** que l'optimiseur ne voit jamais (par exemple, des données de compte utilisateur que le modèle apprend uniquement par le biais d'appels d'outils) : indiquez cet état de manière explicite dans `conversation_so_far` l'échantillon de sonde ou acceptez que le service ne puisse ajuster que le comportement de surface. ### Liste de contrôle pour débutants + Choisissez les tours de sonde qui vous intéressent. Chacun devient un ou plusieurs échantillons. + Choisissez le modèle A ou B (ou les deux : A d'abord, puis B). + Créez plus de 20 échantillons représentatifs avec des `referenceResponse` valeurs réalistes `conversation_so_far` et nettes.