Un chatbot Azure OpenAI doit fournir des réponses cohérentes, ciblées et non créatives pour un scénario de service client.
→Définir le paramètre `temperature` sur une valeur basse, telle que 0,1 ou 0,2. Éviter de le régler à exactement 0 pour la plupart des modèles.
Pourquoi: La température contrôle le caractère aléatoire de la sortie. La réduire rend le modèle plus déterministe et plus susceptible de choisir les jetons à plus haute probabilité.
Dans une solution RAG, s'assurer que le modèle génératif ne synthétise des réponses qu'à partir des documents auxquels l'utilisateur spécifique est autorisé à accéder.
→Mettre en œuvre un filtrage de sécurité au stade de la récupération. Dans Azure AI Search, appliquer des filtres de sécurité à la requête de recherche basés sur l'identité AAD de l'utilisateur et ses appartenances à des groupes.
Pourquoi: Le contrôle d'accès doit être appliqué avant que le LLM ne voie les données. Le filtrage au niveau de la couche de recherche (récupération) est le seul moyen sécurisé d'implémenter cela.
Extraire systématiquement des données structurées de texte non structuré dans un objet JSON valide à l'aide d'Azure OpenAI.
→Utiliser une invite qui inclut : 1) Un rôle clair. 2) Une instruction explicite de renvoyer UNIQUEMENT du JSON. 3) Le schéma JSON souhaité avec les noms de champs et les types. 4) Des exemples "few-shot" si possible.
Pourquoi: Des invites très structurées et explicites augmentent considérablement la fiabilité d'obtenir une sortie structurée et bien formée des LLM.
Une application critique nécessite un débit garanti et constant d'Azure OpenAI, sans étranglement pendant les périodes de pointe.
→Acheter et déployer le modèle à l'aide d'Unités de Débit Provisionné (PTU).
Pourquoi: Les PTU fournissent une capacité de traitement de modèle dédiée et réservée, contrairement aux déploiements standard "paiement à l'utilisation" qui fonctionnent sur un modèle de capacité partagée et sont sujets à l'étranglement.
Référence↗
Maintenir le contexte dans une conversation de chatbot de longue durée sans dépasser la limite de jetons du modèle.
→Mettre en œuvre une stratégie de résumé de conversation. Utiliser périodiquement un appel LLM distinct pour résumer les parties plus anciennes de la conversation, et inclure ce résumé ainsi que les tours les plus récents dans l'invite.
Pourquoi: Ce modèle de "résumé et glissement" préserve le contexte à long terme beaucoup plus efficacement et économiquement qu'une simple troncature ou l'envoi de l'historique entier (et éventuellement trop long).
Permettre à un modèle Azure OpenAI d'appeler une API externe pour obtenir des informations météorologiques actuelles.
→Définir l'API comme un outil pour le modèle en utilisant un format JSON Schema précis. Inclure une `description` de fonction claire et des descriptions de `paramètres` détaillées afin que le modèle sache quand et comment l'utiliser.
Pourquoi: Le modèle s'appuie entièrement sur le schéma et les descriptions pour prendre une décision éclairée d'appeler une fonction. Une fonction bien décrite est essentielle pour la fiabilité.
Utiliser Azure OpenAI pour résumer un document beaucoup plus long que la fenêtre de contexte du modèle.
→Mettre en œuvre une stratégie de "map-reduce" ou de "raffinage". Segmenter le document, générer un résumé pour chaque segment (map), puis générer un résumé final à partir de la collection de résumés de segments (reduce).
Pourquoi: Ceci est le modèle standard pour appliquer des modèles à contexte fixe à des entrées arbitrairement longues, garantissant que le contenu complet du document est pris en compte.
Améliorer la réactivité perçue d'une application de chat en affichant la réponse de l'IA au fur et à mesure qu'elle est générée.
→Lors de l'appel de l'API Chat Completions, définir le paramètre `stream` sur `true`. Traiter les événements envoyés par le serveur au fur et à mesure de leur arrivée pour construire la réponse jeton par jeton.
Pourquoi: Le streaming offre une bien meilleure expérience utilisateur pour les applications en temps réel que d'attendre que la réponse complète soit générée, ce qui peut prendre plusieurs secondes.
Un agent d'IA doit décider dynamiquement lequel de plusieurs outils (par exemple, requête de base de données, recherche web, envoi d'e-mail) utiliser pour répondre à une demande d'utilisateur.
→Utiliser un framework comme Semantic Kernel ou Azure AI Agent Service. Définir chaque capacité comme un outil/plugin distinct et laisser le planificateur de l'agent ou la boucle ReAct orchestrer les appels d'outils.
Pourquoi: Les frameworks agentiques fournissent la couche d'orchestration (planificateur/boucle de raisonnement) qui permet à un LLM de dépasser la simple question-réponse pour devenir un acteur autonome qui utilise des outils.
Empêcher un agent d'IA autonome d'effectuer des actions à haut risque (par exemple, suppression de données, dépenses d'argent) sans surveillance.
→Mettre en œuvre un modèle "humain dans la boucle". Lorsque l'agent planifie une action à haut risque, le système doit se mettre en pause et exiger une confirmation explicite d'un opérateur humain avant l'exécution.
Pourquoi: Ceci est un modèle d'IA responsable essentiel pour les systèmes agentiques, équilibrant autonomie et sécurité en encadrant les actions irréversibles ou à fort impact.