Comment une recommandation est produite

Les quatre étapes

1. 01

   La détection est déterministe

   Les seuils dépassés et les dégradations d'une fenêtre à l'autre sont détectés par des règles sur des métriques normalisées. Le modèle n'a pas voix au chapitre sur l'existence d'un problème.

   La détection des problèmes est une couche déterministe : des règles évaluent des métriques normalisées à la recherche de seuils dépassés, d'anomalies et de dégradations d'une fenêtre à l'autre, dans le périmètre du compte publicitaire que vous avez sélectionné. Les recommandations s'exécutent en aval de cette couche et en consomment la sortie. On ne demande jamais à un modèle si une alerte existe, et il ne peut pas en créer une.

2. 02

   Les preuves sont figées

   Chaque brief est lié à une alerte et à une révision de preuves précise. Sans cette version, la demande est rejetée plutôt que traitée à partir de données en direct sans rapport.

   Une recommandation est générée à partir d'une seule alerte ou incidence de règle et d'une seule révision de preuves faisant autorité, figée au moment de la demande. Si cette version figée manque, la demande est rejetée. L'alternative — assembler discrètement un contexte neuf à partir de l'état actuel du compte — produirait un brief dont le raisonnement ne correspond plus aux preuves qu'il cite.

3. 03

   La sortie est analysée strictement

   La réponse doit correspondre exactement à un schéma canonique, sans récupération, remplissage, alias ni valeurs par défaut. Une sortie malformée échoue au lieu d'être réparée jusqu'à paraître valide.

   La réponse du modèle est analysée face à un schéma canonique. L'analyseur n'applique ni repli, ni remplissage, ni récupération, ni coercition d'alias, ni valeur sémantique par défaut, et il rejette d'emblée les clés dupliquées et les nombres non finis. Une réponse non conforme déclenche un échec d'analyse structuré au lieu d'être transformée en brief d'apparence valide. Vous voyez une erreur, pas une supposition réparée.

4. 04

   Les actions restent consultatives

   Chaque élément est classé en sécurité avant de vous être montré. Si le modèle qualifie sa propre proposition d'exécutable, elle est rétrogradée en revue manuelle.

   Chaque élément est ensuite classé selon sa sécurité d'exécution. Les éléments démarrent en insight ; des garde-fous détectent le langage laissant entendre qu'une action a déjà été menée ; les modifications d'audience et d'emplacements sont signalées comme sensibles. Un élément que le modèle a étiqueté comme candidat exécutable est rétrogradé en revue manuelle. Rien dans un brief ne modifie de lui-même votre compte publicitaire : appliquer une recommandation est une étape humaine distincte.

Ce que le système ne fera pas

• Laisser le modèle décider qu'un problème existe. La détection reste dans la couche déterministe.
• Répondre à partir d'un contexte en direct sans rapport lorsque la révision de preuves figée manque.
• Réparer, compléter ou récupérer une réponse malformée du modèle pour en faire un brief exploitable.
• Laisser un modèle promouvoir sa propre proposition au rang d'exécutable.
• Traiter le texte libre d'un brief comme une autorisation de modifier quoi que ce soit. Les transferts portent des champs explicites et délimités, ou sont rejetés.

Limites à connaître

• Les recommandations sont en aval de la détection. Si aucune règle ne s'est déclenchée, il n'y a pas de brief : ce n'est pas un auditeur autonome et continu de tout ce qui se passe sur le compte.
• Un brief appartient au compte publicitaire, pas à la personne qui l'a généré. Toutes les personnes autorisées sur ce compte voient la même génération active et le même résultat.
• Seul le dernier brief publié pour une alerte source est affiché. Les versions antérieures n'apparaissent pas dans le produit.
• La régénération est réservée aux propriétaires du compte ; seule la personne ayant lancé une génération peut l'annuler.