Expérimenter sur les prompts LLM et les configurations d'agents IA

Les applications basées sur un LLM et les agents IA sont non déterministes. Modifier un prompt, un modèle, une stratégie de récupération, une configuration d’outil ou un workflow d’agent peut affecter la qualité des réponses, le coût d’exploitation, la latence et le comportement des utilisateurs de façons différentes et difficiles à prévoir. Les frameworks d’évaluation comme RAGAS évaluent si une réponse individuelle atteint un niveau de qualité donné, mais ce score ne vous indique pas si le changement aide les utilisateurs à accomplir ce pour quoi ils sont venus sur votre produit. Vous pouvez utiliser les fonctionnalités de Feature Experimentation de Kameleoon pour personnaliser, tester et déployer la configuration qui sous-tend une application d’IA générative ou un agent IA. Une variable de feature contient un élément de cette configuration (un prompt, un paramètre de modèle, une stratégie de récupération, une définition d’outil), afin que votre équipe puisse la gérer en dehors de votre code applicatif. Chaque variation représente une configuration candidate, ce qui vous permet d’itérer, d’expérimenter et de déployer des changements plus sûrement, sans redéployer. Par exemple, un agent IA de support client peut exposer son prompt système, son modèle, son niveau d’effort de raisonnement et ses paramètres de récupération sous forme de quatre variables distinctes, ce qui vous permet de tester une nouvelle combinaison des quatre en une seule fois au lieu d’attendre un déploiement pour chacune. Répartissez le trafic entre les variations et comparez leur impact à l’aide de plusieurs types de métriques :

• Métriques de qualité IA, telles que l’exactitude, la fiabilité factuelle (groundedness), la pertinence, la qualité du contexte, la sécurité ou la conformité
• Métriques de performance des agents, telles que la réussite de l’utilisation des outils ou l’achèvement des tâches
• Métriques opérationnelles, telles que la latence, la consommation de tokens, les erreurs et le coût
• Métriques utilisateur et business, telles que la satisfaction, l’escalade, la conversion, la rétention et le revenu

Comme la configuration vit dans un feature flag plutôt que dans votre code source, vous pouvez ajouter, modifier ou annuler une variation directement depuis la plateforme Kameleoon, à tout moment.

​

L’évaluation et l’expérimentation résolvent des problèmes différents

L’évaluation détermine si une sortie individuelle d’un modèle ou d’un agent atteint un standard de qualité défini. Les outils d’observabilité permettent d’inspecter les prompts, les réponses, les traces, les étapes de récupération et les appels d’outils à l’origine de cette sortie. L’expérimentation détermine si un changement apporté à la configuration sous-jacente entraîne une amélioration mesurable pour les utilisateurs ou pour l’entreprise, une question à laquelle ni l’évaluation ni l’observabilité ne répondent. Par exemple, un juge LLM peut évaluer le prompt système réécrit d’un agent de support client comme plus fiable factuellement que sa version actuelle. Une expérience Kameleoon répond aux questions dont votre équipe est responsable : si cette même configuration résout davantage de tickets sans escalade vers un humain, et ce qu’elle coûte en latence et en consommation de tokens pour y parvenir. Kameleoon ne remplace pas votre pile d’observabilité ou d’évaluation LLM. Transmettez les scores de vos évaluateurs, qu’ils proviennent de RAGAS, d’un juge LLM ou d’un processus de révision humaine, à Kameleoon sous forme d’objectif personnalisé, et suivez ces scores aux côtés des objectifs comportementaux et business que votre expérience mesure déjà. Vos signaux de qualité au niveau du modèle se connectent alors à une mesure statistiquement fiable de l’impact réel sur les utilisateurs. Pour la plupart des expériences liées à l’IA, combinez plusieurs types de métriques plutôt que de vous fier à une seule :

• Définissez un résultat utilisateur ou business comme objectif principal.
• Suivez les métriques de qualité IA comme objectifs secondaires ou garde-fous.
• Surveillez la latence, le coût, les erreurs et la sécurité comme garde-fous opérationnels.
• Validez les juges automatisés par rapport à un échantillon d’exemples révisés par des humains avant de faire confiance à leurs scores à grande échelle.

​

Fonctionnement

Une expérience sur une application basée sur un LLM ou un agent IA passe par cinq étapes dans Kameleoon :

1. Un feature flag contient la configuration. Chaque élément de la configuration, comme un prompt ou un nom de modèle, devient une variable de feature du flag.
2. Chaque variation définit ses propres valeurs. Une variation est une configuration candidate complète, avec une valeur pour chaque variable.
3. Le SDK affecte une variation à chaque visiteur. Lorsqu’un visiteur accède à votre application, votre code interroge le flag et reçoit les valeurs de la variation affectée, puis les utilise pour appeler le LLM ou configurer l’agent.
4. Les objectifs enregistrent ce qui s’est passé. Votre application suit une conversion pour chaque objectif attaché au flag, y compris une conversion de garde-fou qui se déclenche uniquement lorsqu’une réponse dépasse un seuil acceptable de qualité ou de latence.
5. La page de résultats compare les variations. Une fois que vous avez collecté suffisamment de trafic, comparez les variations sur chaque objectif attaché pour décider quelle configuration déployer.

​

Prérequis

• Un compte Kameleoon avec un projet configuré pour Feature Experimentation.
• L’ID client et la clé secrète client de votre compte. Pour trouver ces valeurs, consultez Identifiants API.
• Une application côté serveur dans laquelle vous pouvez installer un SDK Kameleoon, par exemple une application Python.

​

Configurer votre expérience d’agent IA dans Kameleoon

Les étapes suivantes construisent une expérience concrète : un prompt système réécrit, combiné à un modèle plus puissant et à un niveau d’effort de raisonnement plus élevé, aide-t-il un agent IA de support client à résoudre davantage de tickets par lui-même, tout en maintenant la latence dans une plage acceptable ? Configurez le feature flag, les variations et les objectifs de suivi dans la plateforme Kameleoon avant de toucher à votre code applicatif.

​

Créer le feature flag

Créez un feature flag pour contenir la configuration de votre agent et contrôler le déploiement de votre expérience.

1. Dans l’application Kameleoon, cliquez sur Features > Flags & Experiments > New feature flag.
2. Saisissez un nom, par exemple AI support agent config, et sélectionnez le projet pour le flag.
3. Dans le champ Description, notez ce que contrôle le flag, par exemple « Contrôle le prompt système, le modèle, l’effort de raisonnement et les paramètres de récupération du chatbot de support », afin que les autres membres de votre équipe comprennent son objectif.
4. Cliquez sur Validate.
5. Kameleoon génère une clé de feature à partir du nom du flag. Notez la clé générée, ou modifiez-la pour ai_support_agent. Votre code applicatif identifie le flag par cette clé, et non par son nom, les deux doivent donc correspondre.

Les nouveaux flags démarrent à l’état OFF. Vous activez le flag dans le Rollout Planner une fois sa configuration terminée. Pour en savoir plus, consultez Créer un feature flag.

​

Stocker la configuration de l’agent dans des variables de feature

Ajoutez une variable de feature pour chaque élément de la configuration de l’agent que vous voulez tester, afin de pouvoir en modifier chacune depuis la plateforme Kameleoon sans éditer votre code applicatif. Cet exemple teste quatre variables :

1. Sur la page du flag, dans la barre latérale gauche, cliquez sur Set Up > Variables > Add Variable.
2. Définissez le Type de la variable pour qu’il corresponde au tableau, soit String, soit Number.
3. Saisissez la Variable Key indiquée dans le tableau, par exemple system_prompt.
4. Définissez la Default Value sur la valeur utilisée aujourd’hui par votre application en production. Chaque variation que vous créerez par la suite démarre pré-remplie avec ces valeurs : des valeurs par défaut précises vous font donc gagner du temps et vous offrent une configuration de secours fiable.
5. Cliquez sur Save.
6. Répétez ces étapes pour chaque variable restante du tableau.

Pour en savoir plus, consultez Définir des variables de feature.

​

Créer vos variations

Une règle de diffusion ne peut servir que Off ou une variation que vous avez créée vous-même : une comparaison A/B nécessite donc une variation pour votre configuration actuelle en plus d’une variation pour chaque nouvelle configuration que vous voulez tester. Cet exemple crée deux variations : Baseline, qui reproduit ce que votre application sert déjà en production, et Grounded, high reasoning, une challenger qui combine un prompt réécrit et plus explicite avec un modèle plus puissant et davantage d’effort de raisonnement.

1. Dans la barre latérale gauche, cliquez sur Set Up > Variations > Add variation.
2. Saisissez un Name, par exemple Baseline, et une Variation Key correspondante, par exemple baseline. Chaque variable est pré-remplie avec sa valeur par défaut, laissez donc les quatre inchangées.
3. Cliquez sur Save.
4. Répétez ces étapes pour une seconde variation nommée Grounded, high reasoning (clé grounded_high_reasoning), en modifiant chacune des quatre variables pour qu’elle corresponde à la valeur indiquée dans le tableau pour cette variation.
5. Cliquez sur Save.

Pour en savoir plus, consultez Définir des variations de feature.

​

Attacher des objectifs pour l’impact business, la qualité IA et la latence

Attachez plusieurs objectifs au feature flag afin de pouvoir comparer les variations sur l’ensemble des résultats dont votre équipe est responsable, et pas seulement sur la qualité des réponses. Kameleoon étant une plateforme unifiée, vous pouvez attacher n’importe quel objectif déjà existant dans votre organisation, ou créer un objectif spécifique à votre fonctionnalité basée sur un LLM. Cet exemple attache trois objectifs, un pour chacune des catégories de métriques importantes pour un agent IA : Créez les trois comme des Custom goals déclenchés par votre backend, puisque c’est votre application qui les déclenche, et non le navigateur du visiteur. Lorsque vous créez chaque objectif, sélectionnez Custom goal comme Type, puis choisissez l’option pour un événement backend via le SDK.

1. Sur la page du flag, dans le menu Set Up, cliquez sur Goals > Add goal.
2. Sélectionnez un objectif existant, ou cliquez sur Create a new goal pour en définir un. Ajoutez d’abord Ticket resolved without escalation, car Kameleoon définit automatiquement le premier objectif attaché comme Primary goal.
3. Cliquez sur Save.
4. Répétez ces étapes pour Response groundedness score et Response latency, que Kameleoon attache comme Secondary goals.

Response groundedness score et Response latency ne transportent pas de valeur numérique. Votre application détermine si une réponse donnée dépasse un seuil acceptable, que ce soit parce qu’elle est trop lente ou insuffisamment fiable factuellement, et ne déclenche la conversion de l’objectif que dans ce cas. Kameleoon calcule ensuite le taux de conversion de chaque objectif par variation, ce qui indique quelle proportion des réponses a dépassé ce seuil. Pour en savoir plus sur les types d’objectifs, y compris comment déclencher un objectif personnalisé depuis votre backend, consultez Créer un objectif.

​

Déployer l’expérience

Ajoutez une règle Experiment qui répartit le trafic entre vos deux variations, puis activez le flag pour commencer à collecter des données. Le menu Add a rule regroupe les règles par finalité. Feature testing contient la règle Experiment, qui répartit le trafic et mesure une comparaison statistiquement significative entre les variations, tandis que Feature delivery contient Progressive delivery et Targeted delivery, qui déploient une seule variation progressivement ou vers un segment spécifique sans comparer de bras. Un test A/B nécessite la règle Experiment.

1. Dans le Rollout Planner, sélectionnez l’environnement que vous voulez cibler, par exemple Production.
2. Cliquez sur Add a rule, puis sous Feature testing, sélectionnez Experiment.
3. Sous Variations to serve, définissez Baseline comme Control et ajoutez Grounded, high reasoning comme Treatment. Kameleoon mesure les résultats de chaque treatment par rapport au control, le control doit donc être la configuration que vous exécutez déjà en production.
4. Définissez la répartition du trafic entre les deux variations, par exemple 50 % chacune.
5. Définissez le ciblage de la règle pour inclure les visiteurs que vous voulez tester, par exemple tous les visiteurs qui ouvrent une conversation de support.
6. Dans le menu déroulant Then, for everyone else in production, serve, sélectionnez Baseline. Les visiteurs qui sortent du ciblage de la règle reçoivent alors votre configuration actuelle et validée, et votre application obtient tout de même un jeu complet de variables pour eux.
7. Activez le toggle ON/OFF du flag sur ON.
8. Cliquez sur Save.

Pour en savoir plus, consultez Créer des expériences de feature. Une fois la règle enregistrée, Kameleoon commence à affecter les visiteurs à une configuration et à servir les variables correspondantes. Pour modifier une valeur ou ajouter une variation plus tard, éditez-la directement depuis la plateforme Kameleoon. Vous n’avez pas besoin de redéployer votre application pour appliquer ces changements.

​

Récupérer la configuration dans votre application

Installez le SDK Python de Kameleoon, puis récupérez la configuration affectée au visiteur et suivez une conversion pour chaque objectif à mesure que le ticket du visiteur progresse. Le même principe s’applique à n’importe quel SDK Kameleoon côté serveur, y compris Node.js, Java et Go. Comme Kameleoon fournit uniquement les valeurs de configuration, ce même principe fonctionne aussi avec n’importe quel framework d’agent, comme l’OpenAI Agents SDK, le Claude Agent SDK ou LangChain. La plupart du code d’agent s’exécute en Python ou en TypeScript, choisissez donc celui qui correspond à votre application.

1. Installez le SDK comme dépendance :
   pip install kameleoon-client-python
   
2. Initialisez le client avec votre site code et vos identifiants. Définissez environment sur le même environnement du Rollout Planner que celui qui contient votre règle Experiment, sinon le SDK évalue les règles d’un autre environnement :
   from kameleoon import KameleoonClientConfig, KameleoonClientFactory
   
   SITE_CODE = "a8st4f59bj"
   FEATURE_KEY = "ai_support_agent"
   TASK_GOAL_ID = 12345      # "Ticket resolved without escalation"
   QUALITY_GOAL_ID = 12346   # "Response groundedness score"
   LATENCY_GOAL_ID = 12347   # "Response latency"
   
   configuration = KameleoonClientConfig(
       client_id="your-client-id",
       client_secret="your-client-secret",
       environment="production",
   )
   kameleoon_client = KameleoonClientFactory.create(SITE_CODE, configuration)
   
   if not await kameleoon_client.wait_init_async():
       # L'initialisation du SDK a échoué. Repli sur votre configuration de production.
       ...
   
3. Récupérez la configuration affectée avant d’appeler votre LLM, et suivez une conversion pour chaque objectif à mesure que le ticket du visiteur progresse :
   from anthropic import AsyncAnthropic
   
   judge_client = AsyncAnthropic()
   
   # Reflète les valeurs par défaut du flag, à utiliser lorsque le SDK ne parvient pas à joindre Kameleoon.
   FALLBACK_CONFIG = {
       "system_prompt": "You are the support assistant for Kameleoon's help center. ...",
       "model": "claude-sonnet-5",
       "reasoning_effort": "low",
       "retrieval_top_k": 3,
   }
   
   # Une réponse dépasse le garde-fou de latence au-delà de cette valeur.
   LATENCY_THRESHOLD_MS = 5000
   # Une réponse dépasse le garde-fou de fiabilité factuelle en dessous de cette valeur.
   QUALITY_THRESHOLD = 0.7
   
   
   def get_agent_config_for_visitor(visitor_code: str) -> dict:
       try:
           variation = kameleoon_client.get_variation(visitor_code, FEATURE_KEY)
       # Ces classes d'exception sont fournies avec le SDK Kameleoon.
       except (FeatureNotFound, FeatureEnvironmentDisabled, VisitorCodeInvalid):
           # Le visiteur ne fait pas partie de l'expérience, servez donc la configuration connue comme fiable.
           return FALLBACK_CONFIG
   
       variables = variation.variables
       if not variables:
           return FALLBACK_CONFIG
   
       return {
           "system_prompt": variables["system_prompt"].value,
           "model": variables["model"].value,
           "reasoning_effort": variables["reasoning_effort"].value,
           "retrieval_top_k": int(variables["retrieval_top_k"].value),
       }
   
   
   def track_ticket_resolved(visitor_code: str) -> None:
       kameleoon_client.track_conversion(visitor_code, TASK_GOAL_ID)
   
   
   # Juge LLM : extrait les affirmations factuelles de `response` et évalue
   # la fraction que `retrieved_context` confirme.
   async def score_response_groundedness(retrieved_context: str, response: str) -> float:
       judge_prompt = (
           "List the factual claims in RESPONSE. For each claim, check "
           "whether CONTEXT supports it. Return only a number from 0 to 1: "
           "the fraction of RESPONSE claims that CONTEXT supports.\n\n"
           f"CONTEXT:\n{retrieved_context}\n\nRESPONSE:\n{response}"
       )
       judge_reply = await judge_client.messages.create(
           model="claude-opus-5",
           max_tokens=10,
           messages=[{"role": "user", "content": judge_prompt}],
       )
       return float(judge_reply.content[0].text)
   
   
   def track_quality_score(visitor_code: str, score: float) -> None:
       if score < QUALITY_THRESHOLD:
           kameleoon_client.track_conversion(visitor_code, QUALITY_GOAL_ID)
   
   
   def track_response_latency(visitor_code: str, latency_ms: float) -> None:
       if latency_ms > LATENCY_THRESHOLD_MS:
           kameleoon_client.track_conversion(visitor_code, LATENCY_GOAL_ID)
   
   Appelez get_agent_config_for_visitor() avec le visitor_code du visiteur avant d’envoyer une requête à votre LLM, et utilisez les valeurs retournées pour construire la requête : le prompt système, le modèle, l’effort de raisonnement et le nombre de documents récupérés. Appelez track_ticket_resolved() lorsque l’agent résout le problème du visiteur sans escalade vers un humain. Une fois que l’agent a répondu, appelez score_response_groundedness() avec les documents qu’il a récupérés et la réponse qu’il a générée, puis transmettez le score retourné à track_quality_score(). Appelez track_response_latency() avec le temps de réponse en millisecondes après chaque appel au LLM. track_quality_score() et track_response_latency() ne suivent une conversion que lorsque la valeur dépasse son seuil : une réponse qui reste dans les deux garde-fous ne déclenche donc aucun des deux objectifs. score_response_groundedness() est un exemple minimal de juge LLM : elle demande à un modèle de comparer les affirmations de la réponse au contexte récupéré et de retourner la fraction qu’il confirme. La métrique Factual Correctness de RAGAS évalue la même idée sous-jacente, et vous pouvez la substituer, ou tout autre framework d’évaluation déjà utilisé par votre équipe, à un prompt de juge écrit à la main. Kameleoon calcule ensuite le taux de conversion de chaque objectif par variation, ce qui indique quelle proportion des réponses a dépassé le garde-fou de qualité ou de latence, plutôt que de suivre le score brut ou la valeur en millisecondes elle-même.

​

Suivre et itérer

Ouvrez la page de résultats du feature flag pour comparer Baseline et Grounded, high reasoning sur les trois objectifs attachés. Kameleoon suit automatiquement les expositions et les conversions dès que votre application appelle get_variation() et track_conversion(), vous n’avez donc besoin d’aucune instrumentation supplémentaire. Lisez les trois objectifs ensemble plutôt qu’isolément. Le challenger de cet exemple exécute un modèle plus grand avec un effort de raisonnement plus élevé et récupère davantage de documents : il coûte donc plus cher par conversation et risque davantage de dépasser le garde-fou de latence. Un gain sur Ticket resolved without escalation ne justifie ce compromis que si Response latency et Response groundedness score ne convertissent pas plus souvent pour le challenger que pour Baseline. Si l’objectif principal progresse mais que le taux de conversion d’un garde-fou dépasse ce que vous êtes prêt à accepter, continuez à servir Baseline et affinez le challenger. Lorsqu’un challenger l’emporte, promouvez-le : mettez à jour la Default Value de chaque variable avec la configuration gagnante afin qu’elle devienne la nouvelle configuration de référence fiable, puis retirez la règle d’expérience ou réutilisez la variation pour votre prochaine hypothèse. Pour en savoir plus, consultez Consulter les résultats globaux de votre feature flag.

​

Étapes suivantes

• Consultez la référence du SDK Python pour des options avancées telles que les custom data, l’expérimentation cross-device et les conditions de ciblage.
• Attachez des critères de segmentation précis pour cibler l’expérience sur une audience spécifique, par exemple uniquement les tickets associés à un certain domaine produit.
• Ajoutez un objectif de coût en tokens aux côtés de la latence, en suivant les tokens consommés par conversation comme un objectif personnalisé à valeur numérique, afin de chiffrer directement la différence entre une configuration Sonnet et une configuration Opus. Consultez Créer un objectif.
• Ajoutez un objectif de pertinence du contexte pour vérifier si l’augmentation de retrieval_top_k améliore réellement les documents que l’agent récupère, car une réponse fiable factuellement peut malgré tout provenir des mauvais documents. Consultez Créer un objectif.
• Ajoutez un objectif de retour utilisateur direct, comme un contrôle pouce levé ou pouce baissé après chaque réponse, pour capturer la satisfaction des visiteurs aux côtés des signaux comportementaux que cet exemple suit déjà. Consultez Créer un objectif.
• Ajoutez d’autres variables pour tester d’autres parties de la configuration de l’agent, comme la température, les définitions d’outils ou un modèle de repli pour les nouvelles tentatives. Consultez Définir des variables de feature.
• Validez votre seuil Response groundedness score en comparant un échantillon de scores automatisés à une révision humaine avant de lui faire confiance à grande échelle. Consultez Créer des objectifs pour les feature flags.