Ingénierie de prompts
Enchaîner des prompts complexes pour de meilleures performances
Ingénierie de prompts
Enchaîner des prompts complexes pour de meilleures performances
Lorsque vous travaillez sur des tâches complexes, Claude peut parfois laisser tomber si vous essayez de tout gérer dans un seul prompt. Les prompts de chaîne de pensée (CoT) sont excellents, mais que faire si votre tâche comporte plusieurs étapes distinctes qui nécessitent chacune une réflexion approfondie ?
Entrez dans l’enchaînement de prompts : décomposer les tâches complexes en sous-tâches plus petites et gérables.
Pourquoi enchaîner les prompts ?
- Précision : Chaque sous-tâche reçoit toute l’attention de Claude, réduisant les erreurs.
- Clarté : Des sous-tâches plus simples signifient des instructions et des sorties plus claires.
- Traçabilité : Identifiez et corrigez facilement les problèmes dans votre chaîne de prompts.
Quand enchaîner les prompts
Utilisez l’enchaînement de prompts pour les tâches en plusieurs étapes comme la synthèse de recherche, l’analyse de documents ou la création de contenu itérative. Lorsqu’une tâche implique de multiples transformations, citations ou instructions, l’enchaînement empêche Claude de sauter ou de mal gérer des étapes.
Rappelez-vous : Chaque maillon de la chaîne reçoit toute l’attention de Claude !
Conseil de débogage : Si Claude manque une étape ou fonctionne mal, isolez cette étape dans son propre prompt. Cela vous permet d’affiner les étapes problématiques sans refaire toute la tâche.
Comment enchaîner les prompts
- Identifier les sous-tâches : Divisez votre tâche en étapes distinctes et séquentielles.
- Structurer avec XML pour des transferts clairs : Utilisez des balises XML pour passer les sorties entre les prompts.
- Avoir un objectif à tâche unique : Chaque sous-tâche doit avoir un seul objectif clair.
- Itérer : Affinez les sous-tâches en fonction des performances de Claude.
Exemples de flux de travail enchaînés :
- Analyse en plusieurs étapes : Voir les exemples juridiques et commerciaux ci-dessous.
- Pipelines de création de contenu : Recherche → Plan → Brouillon → Édition → Formatage.
- Traitement des données : Extraire → Transformer → Analyser → Visualiser.
- Prise de décision : Recueillir des informations → Lister les options → Analyser chacune → Recommander.
- Boucles de vérification : Générer du contenu → Réviser → Affiner → Re-réviser.
Conseil d’optimisation : Pour les tâches avec des sous-tâches indépendantes (comme l’analyse de plusieurs documents), créez des prompts séparés et exécutez-les en parallèle pour plus de rapidité.
Avancé : Chaînes d’auto-correction
Vous pouvez enchaîner des prompts pour que Claude révise son propre travail ! Cela permet de détecter les erreurs et d’affiner les sorties, en particulier pour les tâches à enjeux élevés.
Prompt 1
| Rôle | Contenu |
|---|---|
| Utilisateur | Résumez cet article de recherche médicale. <paper>{{RESEARCH_PAPER}}</paper> Concentrez-vous sur la méthodologie, les résultats et les implications cliniques. |
| Assistant {{SUMMARY}} | Méthodologie : ECR en double aveugle avec 500 patients diabétiques de type 2. Groupe A (n=250) a reçu un nouvel agoniste double GLP-1/GIP ; Groupe B (n=250) a reçu un agoniste GLP-1 standard. Essai de 24 semaines, critère principal : réduction de l’HbA1c. Résultats : - Groupe A : réduction moyenne de l’HbA1c de 1,8% - Groupe B : réduction moyenne de l’HbA1c de 1,1% - 68% du groupe A vs 52% du groupe B ont atteint une HbA1c <7% - Groupe A : perte de poids moyenne de 5,2 kg - Groupe B : perte de poids moyenne de 3,1 kg Sécurité : Profils d’événements indésirables similaires, aucun événement grave attribué au traitement. Implications cliniques : L’agoniste double montre un contrôle glycémique et une perte de poids supérieurs par rapport au traitement standard. Pourrait être un changement de paradigme, en particulier pour les diabétiques obèses. |
Prompt 2
| Rôle | Contenu |
|---|---|
| Utilisateur | Votre tâche est de fournir des commentaires sur un résumé d’article de recherche. Voici un résumé d’un article de recherche médicale : <summary> {{SUMMARY}} </summary> Voici l’article de recherche : <paper> {{RESEARCH_PAPER}} </paper> Examinez ce résumé pour l’exactitude, la clarté et l’exhaustivité sur une échelle graduée de A à F. |
| Assistant {{FEEDBACK}} | 1. Exactitude : A - Rapporte correctement les statistiques clés : réductions de l’HbA1c, perte de poids. - Note avec précision le profil de sécurité et l’absence d’événements indésirables graves. - L’affirmation “changement de paradigme” est justifiée par des résultats significativement meilleurs. 2. Clarté : A- - Concis et bien structuré avec des sections claires. - Bonne utilisation du langage comparatif (par ex., “en hausse de 3% par rapport au T1”) pour le contexte. - Problème mineur : Les acronymes comme “ECR”, “GLP-1” et “GIP” ne sont pas définis. Envisagez d’épeler la première utilisation. 3. Exhaustivité : B+ - Couvre tous les domaines demandés : méthodologie, résultats, implications cliniques. - Manquant : Caractéristiques de base des groupes (étaient-ils bien appariés ?). - Manquant : Tout critère d’évaluation secondaire (par ex., pression artérielle, lipides). - À considérer : Implications à long terme ou nécessité de recherches supplémentaires. Dans l’ensemble, le résumé est précis et clair, fournissant des informations clés pour une compréhension rapide de l’étude. Pour passer à A+, définissez les acronymes, mentionnez les statistiques de base des groupes, notez les résultats secondaires et abordez brièvement la nécessité d’études à long terme. |
Prompt 3
| Rôle | Contenu |
|---|---|
| Utilisateur | Votre tâche est d’améliorer un résumé d’article en fonction des commentaires. Voici le premier jet d’un résumé d’article de recherche médicale : <summary> {{SUMMARY}} </summary> Voici l’article de recherche : <paper> {{RESEARCH_PAPER}} </paper> Voici les commentaires : <feedback> {{FEEDBACK}} </feedback> Mettez à jour le résumé en fonction des commentaires. |
| Assistant | Méthodologie : Essai contrôlé randomisé (ECR) en double aveugle avec 500 patients diabétiques de type 2. Le groupe A (n=250) a reçu un nouvel agoniste double du peptide-1 de type glucagon/polypeptide insulinotrope dépendant du glucose (GLP-1/GIP) ; le groupe B (n=250) a reçu un agoniste GLP-1 standard. Le critère principal de l’essai de 24 semaines était la réduction de l’HbA1c. Les groupes étaient bien appariés pour l’âge, l’IMC et l’HbA1c de base. Résultats : - Groupe A : réduction moyenne de l’HbA1c de 1,8% - Groupe B : réduction moyenne de l’HbA1c de 1,1% - 68% du groupe A vs 52% du groupe B ont atteint une HbA1c <7% - Groupe A : perte de poids moyenne de 5,2 kg - Groupe B : perte de poids moyenne de 3,1 kg Les critères d’évaluation secondaires ont montré des améliorations de la pression artérielle et des profils lipidiques pour les deux groupes, le groupe A montrant des résultats légèrement meilleurs. Sécurité : Profils d’événements indésirables similaires, sans événement grave attribué à l’un ou l’autre traitement. Implications cliniques : L’agoniste double GLP-1/GIP démontre un contrôle glycémique et une perte de poids supérieurs par rapport au traitement GLP-1 standard. Ces résultats suggèrent qu’il pourrait s’agir d’une avancée significative, en particulier pour les diabétiques obèses. Cependant, des études à plus long terme sont nécessaires pour confirmer l’efficacité et la sécurité durables, ainsi que pour étudier les avantages potentiels sur les résultats cardiovasculaires. |
Exemples
Notez que Claude manque l’instruction de fournir les changements proposés dans son projet d’e-mail.
| Rôle | Contenu |
|---|---|
| Utilisateur | Vous êtes notre directeur juridique. Examinez ce contrat SaaS pour les risques, en vous concentrant sur la confidentialité des données, les SLA et les plafonds de responsabilité. <contract> {{CONTRACT}} </contract> Ensuite, rédigez un e-mail au fournisseur avec vos préoccupations et les changements proposés. |
| Assistant | Après avoir examiné le contrat SaaS, j’ai identifié plusieurs préoccupations : 1. Confidentialité des données (Section 7) : - Problème : Le fournisseur a de larges droits d’utilisation des données des clients pour “l’amélioration du service”. - Risque : Pourrait conduire à un partage ou une monétisation non autorisés des données. 2. SLA (Section 5) : - Problème : La garantie de disponibilité de 99,5% est inférieure à la norme du secteur. - Risque : Un temps d’arrêt excessif pourrait avoir un impact sur nos opérations. 3. Responsabilité (Section 9) : - Problème : Plafond fixé à 3 mois de frais. - Risque : Inadéquat pour les violations de données ou les défaillances de service potentielles. Projet d’e-mail : Cher {{VENDOR}}, Après avoir examiné le contrat SaaS, nous avons des préoccupations : 1. Confidentialité des données : Nous exigeons que nos données ne soient utilisées que pour la fourniture directe de services, et non pour une large “amélioration des services”. Veuillez modifier la section 7. 2. SLA : Une disponibilité de 99,5% est insuffisante. Nous avons besoin de 99,99% avec des pénalités clairement définies. Veuillez réviser la section 5. 3. Responsabilité : Le plafond actuel de 3 mois de frais est inadéquat. Nous proposons un plafond de 12 mois de frais, sans plafond pour les violations de données ou les fautes intentionnelles. Nous apprécions notre partenariat potentiel et pensons que ces changements nous mettront sur la voie du succès. Veuillez envoyer un contrat révisé. Cordialement, {{CLO_NAME}} |
Prompt 1
| Rôle | Contenu |
|---|---|
| Utilisateur | Vous êtes notre directeur juridique. Examinez ce contrat SaaS pour les risques, en vous concentrant sur la confidentialité des données, les SLA et les plafonds de responsabilité. <contract> {{CONTRACT}} </contract> Produisez vos conclusions dans des balises <risks>. |
| Assistant {{CONCERNS}} | 1. Confidentialité des données (Section 7) : - Problème : Le fournisseur a de larges droits d’utilisation des données des clients pour “l’amélioration du service”. - Risque : Pourrait conduire à un partage ou une monétisation non autorisés des données des clients. - Impact : Violation potentielle de la confiance des clients, amendes réglementaires (RGPD, CCPA). 2. SLA (Section 5) : - Problème : La garantie de disponibilité de 99,5% est inférieure à la norme du secteur (généralement 99,99%). - Risque : Jusqu’à 43,8 heures d’indisponibilité par an contre 52,6 minutes à 99,99%. - Impact : Perturbations opérationnelles, perte de revenus, insatisfaction des clients. 3. Responsabilité (Section 9) : - Problème : Plafond de responsabil ité fixé à 3 mois de frais. - Risque : Inadéquat pour les violations de données potentielles, le vol de propriété intellectuelle ou les défaillances de service prolongées. - Impact : Compensation insuffisante pour des dommages qui pourraient dépasser de loin le plafond, comme les recours collectifs ou les amendes réglementaires. |
Prompt 2
| Rôle | Contenu |
|---|---|
| Utilisateur | Rédigez un e-mail à un fournisseur de produits SaaS décrivant les préoccupations suivantes et proposant des changements. Voici les préoccupations : <concerns> {{CONCERNS}} </concerns> |
| Assistant {{EMAIL}} | Cher {{VENDOR}}, Après un examen approfondi du contrat SaaS proposé, notre équipe juridique a identifié plusieurs préoccupations prioritaires qui doivent être traitées avant que nous puissions procéder : 1. Confidentialité des données (Section 7) : - Actuel : Larges droits d’utilisation des données des clients pour “l’amélioration du service”. - Préoccupation : Partage ou monétisation potentiels non autorisés des données. - Changement proposé : Limiter l’utilisation des données à la fourniture directe de services. Toute utilisation pour l’amélioration, l’analyse ou le marketing doit être optionnelle, révocable et anonymisée. 2. SLA (Section 5) : - Actuel : Garantie de disponibilité de 99,5%. - Préoccupation : Jusqu’à 43,8 heures d’indisponibilité par an, risquant des perturbations opérationnelles. - Changement proposé : Disponibilité de 99,99% avec crédits de service par paliers. Par ex., 10% de crédit pour <99,99%, 25% pour <99,9%, 50% pour <99,5%. 3. Responsabilité (Section 9) : - Actuel : Plafond à 3 mois de frais. - Préoccupation : Grossièrement inadéquat pour les violations de données, le vol de propriété intellectuelle ou les pannes prolongées. - Changement proposé : 12 mois de frais pour la responsabilité générale. Sans plafond pour les violations de données, la faute intentionnelle, la violation de propriété intellectuelle. Ces changements sont non négociables pour nous. Ils s’alignent sur les normes du secteur et notre engagement envers la sécurité des données, l’excellence opérationnelle et la responsabilité fiduciaire. Nous apprécions le potentiel de notre partenariat, et y répondre établira une base solide. Veuillez demander à votre équipe juridique d’examiner et d’intégrer ces changements. Nous sommes heureux d’en discuter davantage pour assurer une compréhension et un accord mutuels. Cordialement, {{CLO_NAME}} |
Prompt 3
| Rôle | Contenu |
|---|---|
| Utilisateur | Votre tâche est d’examiner un e-mail et de fournir des commentaires. Voici l’e-mail : <email> {{EMAIL}} </email> Donnez votre avis sur le ton, la clarté et le professionnalisme. |
| Assistant | 1. Ton : - Professionnel et assertif sans être conflictuel. - L’utilisation de “non négociable” est forte mais justifiée étant donné la criticité des problèmes. - Le langage collaboratif (“nous apprécions”, “heureux d’en discuter”) équilibre la fermeté, maintenant un ton constructif. 2. Clarté : - Excellente structuration : État actuel, préoccupation et changement proposé pour chaque problème. - Les termes techniques (par ex., “crédits de service par paliers”) sont appropriés pour un contexte SaaS B2B. - Les actions à entreprendre sont claires : l’équipe juridique du fournisseur doit examiner et intégrer les changements. 3. Professionnalisme : - Se concentre sur le bénéfice mutuel et les normes du secteur, pas seulement sur nos demandes. - Mentionne des responsabilités plus larges (sécurité des données, excellence opérationnelle, devoir fiduciaire), élevant la discussion. - Propose une discussion plus approfondie, montrant un engagement à comprendre et résoudre les problèmes. Dans l’ensemble, l’e-mail trouve le juste équilibre entre assertivité et collaboration. Il articule clairement nos préoccupations, propose des solutions spécifiques et maintient un ton professionnel et orienté vers le partenariat. Aucune révision nécessaire ; procédez à l’envoi. |
Prompt 1
| Rôle | Contenu |
|---|---|
| Utilisateur | En tant qu’architecte de solutions senior, examinez et analysez cette stratégie de multi-location pour notre nouveau produit SaaS d’entreprise. <strategy> {{STRATEGY}} </strategy> Concentrez-vous sur l’évolutivité, la sécurité et la rentabilité. |
| Assistant {{ANALYSIS}} | 1. Évolutivité : + Le sharding de la base de données par locataire réduit la contention, prend en charge une croissance élevée. + Les microservices permettent une mise à l’échelle indépendante des composants. - Les serveurs d’applications partagés pourraient créer des goulots d’étranglement sous une charge extrême. - Aucune mention de mise à l’échelle automatique ou d’équilibrage de charge pour le niveau applicatif. 2. Sécurité : + L’isolation des données des locataires via le sharding atténue les fuites de données. + JWT avec expiration courte et jetons d’actualisation est la meilleure pratique du secteur. - Aucune mention de chiffrement (au repos, en transit) ou de gestion des clés. - La stratégie IAM manque de détails sur les rôles, les autorisations ou le RBAC. 3. Rentabilité : + Les serveurs d’applications partagés réduisent les coûts des ressources inactives. + Les fonctions serverless pour les tâches peu fréquentes optimisent les coûts. - La base de données par locataire pourrait augmenter les coûts à grande échelle par rapport à une base de données multi-locataires optimisée. - Aucune discussion sur les instances réservées ou les instances spot pour réaliser des économies. |
Prompt 2
| Rôle | Contenu |
|---|---|
| Utilisateur | Rédigez un document d’examen de la stratégie pour la direction de l’ingénierie basé sur cette analyse d’une stratégie de multi-location. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Incluez un résumé exécutif, une analyse détaillée et des recommandations. |
| Assistant {{STRATEGY_DOC}} | # Examen de la stratégie de multi-location : Produit SaaS d’entreprise ## Résumé exécutif La stratégie proposée démontre une base solide dans les principes d’évolutivité et de sécurité mais présente des lacunes dans les détails de mise en œuvre. Elle excelle dans l’isolation des données et la mise à l’échelle au niveau des composants mais manque d’une mise à l’échelle robuste du niveau applicatif et de mesures de sécurité avancées. Les optimisations de coûts sont présentes mais peuvent faiblir à grande échelle. Avec des améliorations ciblées, cette stratégie peut soutenir efficacement nos ambitions SaaS d’entreprise. ## Analyse détaillée ### 1. Évolutivité : B+ Forces : - Le sharding de la base de données par locataire est excellent. Il minimise la latence des requêtes, prend en charge une forte croissance des données et facilite une mise à l’échelle transparente par locataire. - L’architecture en microservices permet de mettre à l’échelle les composants individuels en fonction de la demande, ce qui est crucial pour gérer diverses charges de travail d’entreprise. Faiblesses : - Les serveurs d’applications partagés risquent de devenir un goulot d’étranglement. À mesure que le nombre de locataires et le trafic augmentent, cela pourrait dégrader les performances pour tous les locataires. - L’absence de mise à l’échelle automatique et d’équilibrage de charge pour le niveau applicatif est une lacune critique. Ils sont essentiels pour gérer les pics de trafic sans sur-provisionnement. ### 2. Sécurité : B- Forces : - Les bases de données shardées fournissent une forte isolation des données des locataires, atténuant les risques de fuites de données ou d’accès non autorisé entre locataires. - JWT avec expiration courte et jetons d’actualisation s’alignent sur les meilleures pratiques OWASP, réduisant les fenêtres de vulnérabilité des jetons. Faiblesses : - Aucune mention de chiffrement des données au repos ou en transit (TLS 1.3). C’est non négociable pour les données d’entreprise. - La stratégie de gestion des clés est manquante. Comment les clés de chiffrement, les secrets JWT et les informations d’identification de la base de données sont-ils gérés et tournés ? - IAM manque de profondeur. Nous avons besoin de RBAC avec des rôles bien définis, de contrôle d’accès basé sur les attributs (ABAC) pour des autorisations granulaires et d’intégration avec les fournisseurs d’identité d’entreprise (SAML, OIDC). ### 3. Rentabilité : B Forces : - Les serveurs d’applications partagés réduisent les coûts de capacité inactive, ce qui est bon pour le trafic en régime permanent. - Serverless pour les tâches peu fréquentes (par ex., rapports) est intelligent ; payez uniquement lorsque ces ressources sont utilisées. Faiblesses : - Les bases de données par locataire peuvent ne pas être rentables à grande échelle par rapport à une base de données multi-locataires bien conçue avec un partitionnement robuste des données. - Aucune mention de mesures d’économie de coûts comme les instances réservées pour les charges de travail prévisibles ou les instances spot pour les tâches tolérantes aux pannes. - L’absence de mise à l’échelle automatique du niveau applicatif pourrait entraîner un sur-provisionnement, augmentant les coûts. ## Recommandations 1. Résilience du niveau applicatif : Implémentez la mise à l’échelle automatique avec Kubernetes ou des services natifs du cloud (EKS, GKE). Déployez dans des zones de disponibilité avec un CDN pour les ressources statiques. 2. Renforcement de la sécurité : a. Chiffrez les données au repos (AES-256) et en transit (TLS 1.3). b. Utilisez un KMS géré (AWS KMS, GCP KMS) pour la gestion des clés. c. Améliorez IAM avec RBAC, ABAC et SAML/OIDC pour l’authentification unique d’entreprise. 3. Optimisation des coûts : a. Évaluez une base de données multi-locataires en colonnes (par ex., Snowflake) vs. sharding à grande échelle. b. Utilisez des instances réservées pour les serveurs d’applications, des instances spot pour les charges de travail non critiques. c. Implémentez une surveillance proactive et un dimensionnement approprié pour éviter le sur-provisionnement. 4. Preuve de concept (PoC) : Avant une implémentation complète, réalisez un PoC avec une simulation à grande échelle : a. Testez la base de données shardée vs. la base de données multi-locataires optimisée pour le coût et les performances. b. Testez le niveau applicatif avec des pics de trafic simulés de niveau entreprise. c. Effectuez un audit de sécurité par un tiers, en vous concentrant sur l’isolation des données et les contrôles d’accès. Avec ces améliorations, notre stratégie de multi-location sera de niveau entreprise : évolutive, sécurisée et rentable. Le PoC validera nos choix de conception et instillera la confiance chez nos clients entreprises. |
Prompt 3
| Rôle | Contenu |
|---|---|
| Utilisateur | Évaluez ce document d’examen de la stratégie pour la clarté, l’actionnabilité et l’alignement avec les priorités de l’entreprise. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
| Assistant | 1. Clarté : A + Structure claire avec Résumé exécutif, Analyse détaillée et Recommandations. + L’analyse utilise un système de notation (B+, B-) pour une compréhension rapide des forces/faiblesses. + Les termes techniques (RBAC, ABAC, TLS) sont expliqués ou contextualisés, aidant la direction non technique. + Les aides visuelles (puces, indentation) améliorent la lisibilité. 2. Actionnabilité : A- + Les recommandations sont spécifiques et techniques (par ex., “Implémentez la mise à l’échelle automatique avec Kubernetes”). + Le plan de PoC avec des objectifs clairs fournit une feuille de route. + Manquant : Délais, besoins en ressources ou affectations d’équipe pour chaque recommandation. + À considérer : Ajoutez une section “Prochaines étapes” avec les actions immédiates, les rôles et un calendrier de haut niveau. 3. Alignement avec l’entreprise : A+ + Aborde directement les priorités de l’entreprise : - Évolutivité : Discute de la gestion des pics de trafic de niveau entreprise. - Sécurité : Se concentre sur l’isolation des données, le chiffrement et l’IAM d’entreprise. - Coût : Les stratégies s’alignent sur la FinOps d’entreprise (instances réservées, dimensionnement approprié). + Le PoC avec “simulation à grande échelle” et audit de sécurité montre un engagement envers la qualité de niveau entreprise. + Le langage résonne avec les préoccupations de l’entreprise : “risque inacceptable”, “de niveau entreprise”, “instiller la confiance”. Dans l’ensemble, le document excelle en clarté et alignement avec l’entreprise. L’actionnabilité est forte mais pourrait être élevée à A+ avec une section “Prochaines étapes”. La profondeur technique, couplée à des explications claires, rend cela très efficace pour la direction technique et non technique. Excellent travail ! |
Bibliothèque de prompts
Inspirez-vous d’une sélection de prompts pour diverses tâches et cas d’utilisation.
Tutoriel de prompting GitHub
Un tutoriel rempli d’exemples qui couvre les concepts d’ingénierie de prompts trouvés dans notre documentation.
Tutoriel de prompting Google Sheets
Une version plus légère de notre tutoriel d’ingénierie de prompts via une feuille de calcul interactive.