Ingegneria dei prompt
Concatena prompt complessi per prestazioni più forti
Ingegneria dei prompt
Concatena prompt complessi per prestazioni più forti
Quando si lavora con compiti complessi, Claude a volte può perdere colpi se si cerca di gestire tutto in un unico prompt. Il prompting Chain of Thought (CoT) è ottimo, ma cosa succede se il tuo compito ha più passaggi distinti che richiedono ciascuno un pensiero approfondito?
Entra nel prompt chaining: scomporre compiti complessi in sotto-compiti più piccoli e gestibili.
Perché concatenare i prompt?
- Precisione: Ogni sotto-compito ottiene la piena attenzione di Claude, riducendo gli errori.
- Chiarezza: Sotto-compiti più semplici significano istruzioni e output più chiari.
- Tracciabilità: Individua e risolvi facilmente i problemi nella tua catena di prompt.
Quando concatenare i prompt
Usa il prompt chaining per compiti a più passaggi come sintesi di ricerche, analisi di documenti o creazione iterativa di contenuti. Quando un compito coinvolge più trasformazioni, citazioni o istruzioni, la concatenazione impedisce a Claude di perdere o gestire male i passaggi.
Ricorda: Ogni anello della catena ottiene la piena attenzione di Claude!
Suggerimento per il debug: Se Claude salta un passaggio o ha prestazioni scarse, isola quel passaggio in un prompt separato. Questo ti permette di perfezionare i passaggi problematici senza rifare l’intero compito.
Come concatenare i prompt
- Identifica i sotto-compiti: Suddividi il tuo compito in passaggi distinti e sequenziali.
- Struttura con XML per passaggi di consegne chiari: Usa i tag XML per passare gli output tra i prompt.
- Abbi un obiettivo a compito singolo: Ogni sotto-compito dovrebbe avere un singolo obiettivo chiaro.
- Itera: Affina i sotto-compiti in base alle prestazioni di Claude.
Esempi di flussi di lavoro concatenati:
- Analisi multi-step: Vedi gli esempi legali e aziendali di seguito.
- Pipeline di creazione di contenuti: Ricerca → Schema → Bozza → Modifica → Formatta.
- Elaborazione dati: Estrai → Trasforma → Analizza → Visualizza.
- Processo decisionale: Raccogli info → Elenca opzioni → Analizza ciascuna → Raccomanda.
- Loop di verifica: Genera contenuto → Revisiona → Affina → Ri-revisiona.
Suggerimento di ottimizzazione: Per compiti con sotto-compiti indipendenti (come l’analisi di più documenti), crea prompt separati ed eseguili in parallelo per velocità.
Avanzato: Catene di auto-correzione
Puoi concatenare i prompt per far sì che Claude riveda il proprio lavoro! Questo rileva gli errori e affina gli output, specialmente per compiti ad alta posta in gioco.
Prompt 1
| Ruolo | Contenuto |
|---|---|
| Utente | Riassumi questo articolo di ricerca medica. <paper>{{RESEARCH_PAPER}}</paper> Concentrati su metodologia, risultati e implicazioni cliniche. |
| Assistente {{SUMMARY}} | Metodologia: RCT in doppio cieco con 500 pazienti con diabete di tipo 2. Gruppo A (n=250) ha ricevuto un nuovo agonista duale GLP-1/GIP; Gruppo B (n=250) ha ricevuto un agonista GLP-1 standard. Trial di 24 settimane, endpoint primario: riduzione HbA1c. Risultati: - Gruppo A: riduzione media HbA1c 1,8% - Gruppo B: riduzione media HbA1c 1,1% - 68% del Gruppo A vs 52% del Gruppo B ha raggiunto HbA1c <7% - Gruppo A: perdita di peso media 5,2kg - Gruppo B: perdita di peso media 3,1kg Sicurezza: Profili di eventi avversi simili, nessun evento grave attribuito al trattamento. Implicazioni cliniche: L’agonista duale mostra un controllo glicemico e una perdita di peso superiori rispetto alla terapia standard. Potrebbe essere un punto di svolta, specialmente per i diabetici obesi. |
Prompt 2
| Ruolo | Contenuto |
|---|---|
| Utente | Il tuo compito è fornire feedback su un riepilogo di un articolo di ricerca. Ecco un riepilogo di un articolo di ricerca medica: <summary> {{SUMMARY}} </summary> Ecco l’articolo di ricerca: <paper> {{RESEARCH_PAPER}} </paper> Rivedi questo riepilogo per accuratezza, chiarezza e completezza su una scala graduata A-F. |
| Assistente {{FEEDBACK}} | 1. Accuratezza: A - Riportate correttamente le statistiche chiave: riduzioni HbA1c, perdita di peso. - Notato accuratamente il profilo di sicurezza e l’assenza di eventi avversi gravi. - L’affermazione “punto di svolta” è giustificata da risultati significativamente migliori. 2. Chiarezza: A- - Conciso e ben strutturato con sezioni chiare. - Buon uso del linguaggio comparativo (es. “su del 3% dal Q1”) per il contesto. - Problema minore: Acronimi come “RCT”, “GLP-1” e “GIP” non definiti. Considera di scrivere per esteso il primo uso. 3. Completezza: B+ - Copre tutte le aree richieste: metodologia, risultati, implicazioni cliniche. - Mancante: Caratteristiche di base dei gruppi (erano ben abbinati?). - Mancante: Eventuali endpoint secondari (es. pressione sanguigna, lipidi). - Da considerare: Implicazioni a lungo termine o necessità di ulteriori ricerche. Nel complesso, il riepilogo è accurato e chiaro, fornendo informazioni chiave per una rapida comprensione dello studio. Per elevarlo ad A+, definisci gli acronimi, menziona le statistiche di base dei gruppi, nota eventuali risultati secondari e accenna brevemente alla necessità di studi a lungo termine. |
Prompt 3
| Ruolo | Contenuto |
|---|---|
| Utente | Il tuo compito è migliorare un riepilogo di un articolo in base al feedback. Ecco la prima bozza di un riepilogo di un articolo di ricerca medica: <summary> {{SUMMARY}} </summary> Ecco l’articolo di ricerca: <paper> {{RESEARCH_PAPER}} </paper> Ecco il feedback: <feedback> {{FEEDBACK}} </feedback> Aggiorna il riepilogo in base al feedback. |
| Assistente | Metodologia: Trial controllato randomizzato (RCT) in doppio cieco con 500 pazienti con diabete di tipo 2. Il Gruppo A (n=250) ha ricevuto un nuovo agonista duale del peptide-1 simile al glucagone/polipeptide insulinotropico glucosio-dipendente (GLP-1/GIP); il Gruppo B (n=250) ha ricevuto un agonista GLP-1 standard. L’endpoint primario del trial di 24 settimane era la riduzione dell’HbA1c. I gruppi erano ben abbinati per età, BMI e HbA1c di base. Risultati: - Gruppo A: riduzione media HbA1c 1,8% - Gruppo B: riduzione media HbA1c 1,1% - 68% del Gruppo A vs 52% del Gruppo B ha raggiunto HbA1c <7% - Gruppo A: perdita di peso media 5,2kg - Gruppo B: perdita di peso media 3,1kg Gli endpoint secondari hanno mostrato miglioramenti nella pressione sanguigna e nei profili lipidici per entrambi i gruppi, con il Gruppo A che ha mostrato risultati leggermente migliori. Sicurezza: Profili di eventi avversi simili, senza eventi gravi attribuiti a nessuno dei trattamenti. Implicazioni cliniche: L’agonista duale GLP-1/GIP dimostra un controllo glicemico e una perdita di peso superiori rispetto alla terapia GLP-1 standard. Questi risultati suggeriscono che potrebbe essere un progresso significativo, in particolare per i diabetici obesi. Tuttavia, sono necessari studi a più lungo termine per confermare l’efficacia e la sicurezza sostenute, nonché per indagare i potenziali benefici sugli esiti cardiovascolari. |
Esempi
Nota che Claude manca l’istruzione di fornire le modifiche proposte nella sua bozza di email.
| Ruolo | Contenuto |
|---|---|
| Utente | Sei il nostro Chief Legal Officer. Rivedi questo contratto SaaS per i rischi, concentrandoti su privacy dei dati, SLA e limiti di responsabilità. <contract> {{CONTRACT}} </contract> Quindi scrivi una bozza di email al fornitore con le tue preoccupazioni e le modifiche proposte. |
| Assistente | Dopo aver esaminato il contratto SaaS, ho identificato diverse preoccupazioni: 1. Privacy dei dati (Sezione 7): - Problema: Il fornitore ha ampi diritti di utilizzo dei dati dei clienti per “miglioramento del servizio”. - Rischio: Potrebbe portare a condivisione o monetizzazione non autorizzata dei dati. 2. SLA (Sezione 5): - Problema: La garanzia di uptime del 99,5% è inferiore allo standard del settore. - Rischio: Tempi di inattività eccessivi potrebbero influire sulle nostre operazioni. 3. Responsabilità (Sezione 9): - Problema: Limite fissato a 3 mesi di commissioni. - Rischio: Inadeguato per potenziali violazioni dei dati o guasti del servizio. Bozza email: Caro {{VENDOR}}, Dopo aver esaminato l’accordo SaaS, abbiamo delle preoccupazioni: 1. Privacy dei dati: Richiediamo che i nostri dati vengano utilizzati solo per la fornitura diretta del servizio, non per un generico “miglioramento del servizio”. Si prega di modificare la Sezione 7. 2. SLA: L’uptime del 99,5% è insufficiente. Abbiamo bisogno del 99,99% con penali chiaramente definite. Si prega di rivedere la Sezione 5. 3. Responsabilità: L’attuale limite di 3 mesi di commissioni è inadeguato. Proponiamo un limite di 12 mesi di commissioni, senza limiti per violazioni dei dati o condotta dolosa. Apprezziamo la nostra potenziale partnership e crediamo che questi cambiamenti ci prepareranno al successo. Si prega di inviare un accordo rivisto. Cordiali saluti, {{CLO_NAME}} |
Prompt 1
| Ruolo | Contenuto |
|---|---|
| Utente | Sei il nostro Chief Legal Officer. Rivedi questo contratto SaaS per i rischi, concentrandoti su privacy dei dati, SLA e limiti di responsabilità. <contract> {{CONTRACT}} </contract> Riporta i tuoi risultati in tag <risks>. |
| Assistente {{CONCERNS}} | 1. Privacy dei dati (Sezione 7): - Problema: Il fornitore ha ampi diritti di utilizzo dei dati dei clienti per “miglioramento del servizio”. - Rischio: Potrebbe portare a condivisione o monetizzazione non autorizzata dei dati dei clienti. - Impatto: Potenziale violazione della fiducia dei clienti, multe normative (GDPR, CCPA). 2. SLA (Sezione 5): - Problema: La garanzia di uptime del 99,5% è inferiore allo standard del settore (tipicamente 99,99%). - Rischio: Fino a 43,8 ore di inattività all’anno contro 52,6 minuti al 99,99%. - Impatto: Interruzioni operative, perdita di entrate, insoddisfazione dei clienti. 3. Responsabilità (Sezione 9): - Problema: Limite di responsabilità fissato a 3 mesi di commissioni. - Rischio: Inadeguato per potenziali violazioni dei dati, furto di proprietà intellettuale o guasti prolungati del servizio. - Impatto: Risarcimento insufficiente per danni che potrebbero superare di gran lunga il limite, come cause collettive o multe normative. |
Prompt 2
| Ruolo | Contenuto |
|---|---|
| Utente | Scrivi una bozza di email a un fornitore di prodotti SaaS delineando le seguenti preoccupazioni e proponendo modifiche. Ecco le preoccupazioni: <concerns> {{CONCERNS}} </concerns> |
| Assistente {{EMAIL}} | Caro {{VENDOR}}, Dopo un’attenta revisione del proposto accordo SaaS, il nostro team legale ha identificato diverse preoccupazioni di alta priorità che devono essere affrontate prima di poter procedere: 1. Privacy dei dati (Sezione 7): - Attuale: Ampi diritti di utilizzo dei dati dei clienti per “miglioramento del servizio”. - Preoccupazione: Potenziale condivisione o monetizzazione non autorizzata dei dati. - Modifica proposta: Limitare l’uso dei dati alla fornitura diretta del servizio. Qualsiasi uso per miglioramento, analisi o marketing deve essere opt-in, revocabile e anonimizzato. 2. SLA (Sezione 5): - Attuale: Garanzia di uptime del 99,5%. - Preoccupazione: Fino a 43,8 ore di inattività all’anno, rischiando interruzioni operative. - Modifica proposta: Uptime del 99,99% con crediti di servizio a livelli. Es. 10% di credito per <99,99%, 25% per <99,9%, 50% per <99,5%. 3. Responsabilità (Sezione 9): - Attuale: Limite a 3 mesi di commissioni. - Preoccupazione: Gravemente inadeguato per violazioni dei dati, furto di proprietà intellettuale o interruzioni prolungate. - Modifica proposta: 12 mesi di commissioni per responsabilità generale. Senza limiti per violazioni dei dati, condotta dolosa, violazione della proprietà intellettuale. Queste modifiche sono non negoziabili per noi. Si allineano agli standard del settore e al nostro impegno per la sicurezza dei dati, l’eccellenza operativa e la responsabilità fiduciaria. Apprezziamo il potenziale della nostra partnership e affrontare questi punti creerà una solida base. Si prega di far esaminare e incorporare queste modifiche dal vostro team legale. Siamo lieti di discuterne ulteriormente per garantire comprensione e accordo reciproci. Cordiali saluti, {{CLO_NAME}} |
Prompt 3
| Ruolo | Contenuto |
|---|---|
| Utente | Il tuo compito è rivedere un’email e fornire feedback. Ecco l’email: <email> {{EMAIL}} </email> Dai feedback su tono, chiarezza e professionalità. |
| Assistente | 1. Tono: - Professionale e assertivo senza essere conflittuale. - L’uso di “non negoziabile” è forte ma giustificato data la criticità delle questioni. - Il linguaggio collaborativo (“apprezziamo”, “lieti di discutere”) bilancia la fermezza, mantenendo un tono costruttivo. 2. Chiarezza: - Eccellente strutturazione: Stato attuale, preoccupazione e modifica proposta per ogni problema. - Termini tecnici (es. “EBITDA”, “crediti di servizio a livelli”) sono appropriati per un contesto SaaS B2B. - Le azioni richieste sono chiare: il team legale del fornitore deve rivedere e incorporare le modifiche. 3. Professionalità: - Si concentra sul beneficio reciproco e sugli standard del settore, non solo sulle nostre richieste. - Menziona responsabilità più ampie (sicurezza dei dati, eccellenza operativa, dovere fiduciario), elevando la discussione. - Offre ulteriori discussioni, mostrando impegno per la comprensione e la risoluzione dei problemi. Nel complesso, l’email raggiunge il giusto equilibrio di assertività e collaborazione. Articola chiaramente le nostre preoccupazioni, propone soluzioni specifiche e mantiene un tono professionale e orientato alla partnership. Nessuna revisione necessaria; procedere con l’invio. |
Prompt 1
| Ruolo | Contenuto |
|---|---|
| Utente | Come architetto di soluzioni senior, rivedi e analizza questa strategia di multitenancy per il nostro nuovo prodotto SaaS enterprise. <strategy> {{STRATEGY}} </strategy> Concentrati su scalabilità, sicurezza e rapporto costo-efficacia. |
| Assistente {{ANALYSIS}} | 1. Scalabilità: + Lo sharding del database per tenant riduce la contesa, supporta un’elevata crescita. + I microservizi consentono il ridimensionamento indipendente dei componenti. - I server di applicazioni condivisi potrebbero creare colli di bottiglia sotto carichi estremi. - Nessuna menzione di auto-scaling o bilanciamento del carico per il livello applicativo. 2. Sicurezza: + L’isolamento dei dati dei tenant tramite sharding mitiga le perdite di dati. + JWT con breve scadenza e token di aggiornamento è la migliore pratica del settore. - Nessuna menzione di crittografia (a riposo, in transito) o gestione delle chiavi. - La strategia IAM manca di dettagli su ruoli, permessi o RBAC. 3. Rapporto costo-efficacia: + I server di applicazioni condivisi riducono i costi delle risorse inattive. + Le funzioni serverless per attività poco frequenti ottimizzano i costi. - Il DB per tenant potrebbe aumentare i costi su larga scala rispetto a un DB multi-tenant ottimizzato. - Nessuna discussione su istanze riservate o istanze spot per il risparmio sui costi. |
Prompt 2
| Ruolo | Contenuto |
|---|---|
| Utente | Scrivi una bozza di un documento di revisione della strategia per la leadership ingegneristica basato su questa analisi di una strategia di multitenancy. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Includi un riepilogo esecutivo, un’analisi dettagliata e raccomandazioni. |
| Assistente {{STRATEGY_DOC}} | # Revisione della strategia di multitenancy: Prodotto SaaS Enterprise ## Riepilogo esecutivo La strategia proposta dimostra una solida base nei principi di scalabilità e sicurezza ma presenta lacune nei dettagli di implementazione. Eccelle nell’isolamento dei dati e nel ridimensionamento a livello di componente ma manca di un robusto ridimensionamento a livello di applicazione e di misure di sicurezza avanzate. Le ottimizzazioni dei costi sono presenti ma potrebbero vacillare su larga scala. Con miglioramenti mirati, questa strategia può supportare efficacemente le nostre ambizioni SaaS enterprise. ## Analisi dettagliata ### 1. Scalabilità: B+ Punti di forza: - Lo sharding del database per tenant è eccellente. Minimizza la latenza delle query, supporta un’elevata crescita dei dati e facilita un ridimensionamento senza soluzione di continuità per tenant. - L’architettura a microservizi consente di ridimensionare i singoli componenti in base alla domanda, cruciale per gestire diversi carichi di lavoro aziendali. Punti deboli: - I server di applicazioni condivisi rischiano di diventare un collo di bottiglia. Con l’aumento del numero di tenant e del traffico, questi potrebbero degradare le prestazioni per tutti i tenant. - L’assenza di auto-scaling e bilanciamento del carico per il livello applicativo è una grave svista. Questi sono essenziali per gestire picchi di traffico senza sovradimensionamento. ### 2. Sicurezza: B- Punti di forza: - I database con sharding forniscono un forte isolamento dei dati dei tenant, mitigando i rischi di perdite di dati o accessi non autorizzati tra tenant. - JWT con breve scadenza e token di aggiornamento si allineano alle migliori pratiche OWASP, riducendo le finestre di vulnerabilità dei token. Punti deboli: - Nessuna menzione di crittografia dei dati a riposo o in transito (TLS 1.3). Questo è non negoziabile per i dati aziendali. - Manca la strategia di gestione delle chiavi. Come vengono gestite e ruotate le chiavi di crittografia, i segreti JWT e le credenziali del DB? - IAM manca di profondità. Abbiamo bisogno di RBAC con ruoli ben definiti, controllo degli accessi basato su attributi (ABAC) per permessi granulari e integrazione con identity provider aziendali (SAML, OIDC). ### 3. Rapporto costo-efficacia: B Punti di forza: - I server di applicazioni condivisi riducono i costi di capacità inattiva, buoni per il traffico in stato stazionario. - Serverless per attività poco frequenti (es. reporting) è intelligente; si paga solo quando queste risorse vengono utilizzate. Punti deboli: - I database per tenant potrebbero non essere convenienti su larga scala rispetto a un database multi-tenant ben progettato con un robusto partizionamento dei dati. - Nessuna menzione di misure di risparmio sui costi come istanze riservate per carichi di lavoro prevedibili o istanze spot per attività tolleranti ai guasti. - La mancanza di auto-scaling a livello di applicazione potrebbe portare a un sovradimensionamento, aumentando i costi. ## Raccomandazioni 1. Resilienza del livello applicativo: Implementare l’auto-scaling con Kubernetes o servizi nativi del cloud (EKS, GKE). Distribuire su zone di disponibilità con una CDN per asset statici. 2. Rafforzamento della sicurezza: a. Crittografare i dati a riposo (AES-256) e in transito (TLS 1.3). b. Utilizzare un KMS gestito (AWS KMS, GCP KMS) per la gestione delle chiavi. c. Migliorare IAM con RBAC, ABAC e SAML/OIDC per SSO aziendale. 3. Ottimizzazione dei costi: a. Valutare DB multi-tenant a colonne (es. Snowflake) vs. sharding su larga scala. b. Utilizzare istanze riservate per i server di applicazioni, istanze spot per carichi di lavoro non critici. c. Implementare monitoraggio proattivo e dimensionamento corretto per evitare il sovradimensionamento. 4. Proof of Concept (PoC): Prima dell’implementazione completa, condurre un PoC con una simulazione ad alta scala: a. Testare DB con sharding vs. DB multi-tenant ottimizzato per costi e prestazioni. b. Stress-test del livello applicativo con picchi di traffico simulati a livello aziendale. c. Condurre audit di sicurezza di terze parti, concentrandosi sull’isolamento dei dati e sui controlli di accesso. Con questi miglioramenti, la nostra strategia di multi-tenancy sarà di livello enterprise: scalabile, sicura ed economicamente vantaggiosa. Il PoC convaliderà le nostre scelte di progettazione e infonderà fiducia nei nostri clienti aziendali. |
Prompt 3
| Ruolo | Contenuto |
|---|---|
| Utente | Valuta questo documento di revisione della strategia per chiarezza, attuabilità e allineamento con le priorità aziendali. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
| Assistente | 1. Chiarezza: A + Struttura chiara con Riepilogo esecutivo, Analisi dettagliata e Raccomandazioni. + L’analisi utilizza un sistema di valutazione (B+, B-) per una rapida comprensione di punti di forza/debolezza. + I termini tecnici (RBAC, ABAC, TLS) sono spiegati o contestualizzati, aiutando la leadership non tecnica. + Gli aiuti visivi (punti elenco, rientri) migliorano la leggibilità. 2. Attuabilità: A- + Le raccomandazioni sono specifiche e tecniche (es. “Implementare l’auto-scaling con Kubernetes”). + Il piano PoC con obiettivi chiari fornisce una roadmap. + Mancante: Tempistiche, requisiti di risorse o assegnazioni di team per ogni raccomandazione. + Da considerare: Aggiungere una sezione “Prossimi passi” con azioni immediate, ruoli e una timeline di alto livello. 3. Allineamento aziendale: A+ + Affronta direttamente le priorità aziendali: - Scalabilità: Discute la gestione di picchi di traffico a livello aziendale. - Sicurezza: Si concentra su isolamento dei dati, crittografia e IAM aziendale. - Costi: Le strategie si allineano con FinOps aziendale (istanze riservate, dimensionamento corretto). + PoC con “simulazione ad alta scala” e audit di sicurezza mostra impegno per la qualità di livello enterprise. + Il linguaggio risuona con le preoccupazioni aziendali: “rischio inaccettabile”, “di livello enterprise”, “infondere fiducia”. Nel complesso, il documento eccelle in chiarezza e allineamento aziendale. L’attuabilità è forte ma potrebbe essere elevata ad A+ con una sezione “Prossimi passi”. La profondità tecnica, unita a spiegazioni chiare, lo rende altamente efficace sia per la leadership tecnica che non tecnica. Ottimo lavoro! |
Libreria di prompt
Lasciati ispirare da una selezione curata di prompt per varie attività e casi d’uso.
Tutorial di prompting su GitHub
Un tutorial ricco di esempi che copre i concetti di prompt engineering trovati nella nostra documentazione.
Tutorial di prompting su Google Sheets
Una versione più leggera del nostro tutorial di prompt engineering tramite un foglio di calcolo interattivo.