Come SnapLogic ha costruito un’applicazione di testo-per-pipeline con Amazon Bedrock per tradurre l’intento aziendale in azione

Come SnapLogic ha creato un'applicazione di testo-per-pipeline utilizzando Amazon Bedrock per trasformare l'intenzione aziendale in azione

Questo articolo è stato scritto in collaborazione con Greg Benson, Chief Scientist; Aaron Kesler, Sr. Product Manager; e Rich Dill, Enterprise Solutions Architect di SnapLogic.

Molti clienti stanno creando app generative AI su Amazon Bedrock e Amazon CodeWhisperer per creare artefatti di codice basati sul linguaggio naturale. Questo caso d’uso mette in evidenza come i grandi modelli di linguaggio (LLM) siano in grado di diventare un traduttore tra lingue umane (inglese, spagnolo, arabo, e altro) e lingue interpretabili dalle macchine (Python, Java, Scala, SQL, e così via) insieme a sofisticate ragionamenti interni. Questa abilità emergente nei LLM ha spinto gli sviluppatori di software a utilizzare i LLM come strumento per l’automazione e l’ottimizzazione dell’esperienza utente, trasformando il linguaggio naturale in un linguaggio specifico del dominio (DSL): istruzioni di sistema, richieste API, artefatti di codice, e altro. In questo articolo, ti mostreremo come SnapLogic, un cliente di AWS, ha utilizzato Amazon Bedrock per potenziare il loro prodotto SnapGPT attraverso la creazione automatica di questi complessi artefatti DSL a partire dal linguaggio umano.

Quando i clienti creano oggetti DSL dai LLM, il DSL risultante è o una replica esatta o una derivazione di un’interfaccia dati e schema esistente che forma il contratto tra l’interfaccia utente e la logica di business nel servizio di supporto. Questo pattern è particolarmente in voga tra i fornitori indipendenti di software (ISV) e i fornitori di software come servizio (SaaS) ISV a causa del loro modo unico di rappresentare le configurazioni tramite il codice e del desiderio di semplificare l’esperienza utente per i loro clienti. Esempi di casi d’uso includono:

• Conversione del linguaggio naturale in visualizzazioni specifiche dello strumento ed espressioni di calcolo, come visto con le recenti capacità di BI generativo annunciate di recente in Amazon QuickSight
• Generazione della chiamata API corretta in base all’intento e al contesto dell’utente individuale attraverso le app SaaS produttive di punta con le prossime caratteristiche di produttività in AWS AppFabric
• Creazione di pipeline di integrazione complesse con semplici indicazioni umane, come leggerai in questo articolo

Il modo più semplice per costruire e scalare applicazioni di testo-a-pipeline con LLM su AWS è utilizzare Amazon Bedrock. Amazon Bedrock è il modo più semplice per costruire e scalare applicazioni di intelligenza generativa con modelli di base (FM). È un servizio completamente gestito che offre accesso a una scelta di modelli di base ad alte prestazioni dei principali fornitori di intelligenza artificiale attraverso un’unica API, insieme a un’ampia gamma di funzionalità necessarie per costruire applicazioni di intelligenza generativa con privacy e sicurezza. Anthropic, un laboratorio di sicurezza e ricerca sull’intelligenza artificiale che sviluppa sistemi AI affidabili, interpretabili e direzionabili, è una delle aziende di intelligenza artificiale leader che offre accesso al loro LLM all’avanguardia, Claude, su Amazon Bedrock. Claude è un LLM che eccelle in una vasta gamma di compiti, dal dialogo attento, alla creazione di contenuti, al ragionamento complesso, alla creatività e alla programmazione. Anthropic offre sia i modelli Claude che Claude Instant, tutti disponibili su Amazon Bedrock. Claude ha guadagnato rapidamente popolarità in queste applicazioni di testo-a-pipeline grazie alla sua migliore capacità di ragionamento, che gli consente di eccellere nella risoluzione di problemi tecnici ambigui. Claude 2 su Amazon Bedrock supporta una finestra di contesto di 100.000 token, equivalente a circa 200 pagine di testo in inglese. Questa è una caratteristica particolarmente importante su cui puoi fare affidamento quando costruisci applicazioni di testo-a-pipeline che richiedono un ragionamento complesso, istruzioni dettagliate ed esempi esaustivi.

• Google DeepMind svela Lyria un innovativo generatore di musica basato sull’intelligenza artificiale e un parco giochi creativo
• Ottimizzazione dei costi per Amazon SageMaker Canvas con spegnimento automatico delle applicazioni inattive
• Automatizzare la generazione delle descrizioni dei prodotti con Amazon Bedrock

Background di SnapLogic

SnapLogic è un cliente di AWS con la missione di portare l’automazione aziendale nel mondo. La piattaforma di integrazione intelligente SnapLogic (IIP) consente alle organizzazioni di realizzare l’automazione su scala enterprise, connettendo l’intero ecosistema delle loro applicazioni, database, big data, macchine e dispositivi, API e altro ancora con connettori intelligenti predefiniti chiamati Snaps. SnapLogic ha recentemente rilasciato una funzionalità chiamata SnapGPT, che fornisce un’interfaccia di testo in cui è possibile digitare la pipeline di integrazione desiderata da creare nel linguaggio umano semplice. SnapGPT utilizza il modello Claude di Anthropic tramite Amazon Bedrock per automatizzare la creazione di queste pipeline di integrazione come codice, che vengono quindi utilizzate attraverso la soluzione di integrazione di punta di SnapLogic. Tuttavia, il percorso di SnapLogic verso SnapGPT è stato il culmine di molti anni di operazioni nell’ambito dell’intelligenza artificiale.

Il percorso dell’IA di SnapLogic

Nel campo delle piattaforme di integrazione, SnapLogic è costantemente all’avanguardia, sfruttando il potere trasformativo dell’intelligenza artificiale. Nel corso degli anni, l’impegno dell’azienda nell’innovazione con l’IA è diventato evidente, soprattutto se tracciamo il percorso da Iris ad AutoLink.

I modesti inizi con Iris

Nel 2017, SnapLogic ha svelato Iris, un assistente di integrazione alimentato da IA, una primizia nel settore. Iris è stato progettato per utilizzare algoritmi di apprendimento automatico (ML) per prevedere i prossimi passi nella creazione di un flusso di dati. Analizzando milioni di elementi di metadati e flussi di dati, Iris poteva fare suggerimenti intelligenti agli utenti, democratizzando l’integrazione dei dati e consentendo anche a coloro che non avevano una profonda competenza tecnica di creare workflow complessi.

AutoLink: Costruire slancio

Sulla base del successo e degli apprendimenti derivanti da Iris, SnapLogic ha introdotto AutoLink, una funzionalità mirata a semplificare ulteriormente il processo di mappatura dei dati. Il compito tedioso di mappare manualmente i campi tra i sistemi di origine e di destinazione è diventato semplicissimo con AutoLink. Utilizzando l’IA, AutoLink individuava automaticamente e suggeriva possibili corrispondenze. Integrazioni che una volta richiedevano ore potevano essere eseguite in pochi minuti.

Il salto generativo con SnapGPT

La più recente incursione di SnapLogic nell’IA ci porta a SnapGPT, che si propone di rivoluzionare ancora di più l’integrazione. Con SnapGPT, SnapLogic introduce la prima soluzione generativa di integrazione al mondo. Non si tratta solo di semplificare i processi esistenti, ma di rimmaginare completamente il modo in cui vengono progettate le integrazioni. Il potere dell’IA generativa può creare interi flussi di integrazione da zero, ottimizzando il flusso di lavoro in base all’obiettivo desiderato e alle caratteristiche dei dati.

SnapGPT ha un impatto enorme per i clienti di SnapLogic perché sono in grado di ridurre drasticamente il tempo necessario per generare la loro prima pipeline di SnapLogic. Tradizionalmente, i clienti di SnapLogic avrebbero dovuto passare giorni o settimane a configurare pipeline di integrazione da zero. Ora, questi clienti possono semplicemente chiedere a SnapGPT di, ad esempio, “creare una pipeline che sposti tutti i miei clienti SFDC attivi in WorkDay”. Viene automaticamente creata una bozza di una pipeline per questo cliente, riducendo drasticamente il tempo di sviluppo necessario per la creazione della base della loro pipeline di integrazione. Ciò consente al cliente finale di dedicare più tempo a ciò che ha un vero impatto commerciale anziché lavorare alle configurazioni di una pipeline di integrazione. L’esempio seguente mostra come un cliente di SnapLogic può inserire una descrizione nella funzione SnapGPT per generare rapidamente una pipeline utilizzando il linguaggio naturale.

AWS e SnapLogic hanno collaborato strettamente durante la realizzazione di questo prodotto e hanno imparato molto lungo il percorso. Il resto di questo articolo si concentrerà sugli apprendimenti tecnici che AWS e SnapLogic hanno avuto nell’utilizzo delle LLM per le applicazioni di testo-a-pipeline.

Panoramica della soluzione

Per risolvere questo problema di testo-a-pipeline, AWS e SnapLogic hanno progettato una soluzione completa mostrata nell’architettura seguente.

Una richiesta a SnapGPT segue il seguente flusso di lavoro:

1. Un utente invia una descrizione all’applicazione.
2. SnapLogic utilizza un approccio di generazione arricchita da recupero (RAG) per recuperare esempi pertinenti di pipeline di SnapLogic simili alla richiesta dell’utente.
3. Questi esempi pertinenti estratti vengono combinati con l’input dell’utente e vengono sottoposti a una pre-elaborazione del testo prima di essere inviati a Claude su Amazon Bedrock.
4. Claude produce un artefatto JSON che rappresenta una pipeline di SnapLogic.
5. L’artefatto JSON viene integrato direttamente nella piattaforma di integrazione core di SnapLogic.
6. La pipeline di SnapLogic viene visualizzata all’utente in modo visivamente intuitivo.

Attraverso vari esperimenti tra AWS e SnapLogic, abbiamo scoperto che lo step di ingegnerizzazione delle istruzioni nel diagramma della soluzione è estremamente importante per generare output di alta qualità per queste uscite di testo-a-pipeline. La sezione successiva approfondisce alcune tecniche specifiche utilizzate con Claude in questo ambito.

Sperimentazione rapida

Durante la fase di sviluppo di SnapGPT, AWS e SnapLogic hanno scoperto che l’iterazione rapida sulle frasi inviate a Claude era un compito critico per migliorare l’accuratezza e la pertinenza dell’output testo-pipeline negli output di SnapLogic. Utilizzando gli appunti interattivi di Amazon SageMaker Studio, il team di AWS e SnapLogic è stato in grado di lavorare rapidamente su diverse versioni di frasi utilizzando la connessione SDK Boto3 a Amazon Bedrock. Lo sviluppo basato su appunti ha permesso ai team di creare rapidamente connessioni lato client a Amazon Bedrock, inclusi descrizioni basate su testo insieme al codice Python per inviare frasi a Amazon Bedrock e tenere sessioni congiunte di ingegneria delle frasi in cui venivano apportate iterazioni rapide tra più persone.

Metodi di ingegneria delle frasi di Claude antropico

In questa sezione, descriviamo alcune delle tecniche iterative che abbiamo utilizzato per creare una frase ad alte prestazioni basata su una richiesta utente illustrativa: “Crea una pipeline che utilizza il database di ExampleCompany per recuperare tutti i clienti attivi.” Nota che questo esempio non rappresenta lo schema su cui si basa SnapGPT, ma viene utilizzato solo per illustrare un’applicazione di testo-pipeline.

Per stabilire una base per l’ingegneria delle frasi, utilizziamo la seguente frase originale:

Crea una pipeline che utilizza il database di ExampleCompany per recuperare tutti i clienti attivi

L’output atteso è il seguente:

{ "database": "ExampleCompany", "query": "SELECT * FROM ec_prod.customers WHERE status = 'active'"} 

Miglioramento #1: Utilizzando le annotazioni umane e assistenti

La procedura di addestramento di Claude insegna al FM a comprendere il dialogo tra un umano e un assistente nella struttura delle frasi. Gli utenti di Claude possono sfruttare questa struttura terminando la frase con “Assistente:”, il che farà sì che Claude inizi a generare la risposta a una query in base a quanto detto dall’umano. Nota che poiché Claude continuerà a generare testo fino a quando non gli verrà detto di fermarsi, assicurati di utilizzare una sequenza di stop di \n\nUmano: nella richiesta API a Amazon Bedrock quando usi Claude. Ciò garantirà che ricevi solo la risposta dall’assistente e non la prossima risposta prevista dall’umano nella catena di dialogo. Questi indicatori \n\nUmano e \n\nAssistente non solo aiutano a limitare la risposta di Claude alle informazioni rilevanti, ma aiutano anche a fornire una chiara demarcazione tra gli input principali umani e le risposte dell’assistente da altre interazioni. Ciò è particolarmente utile in un contesto di prompt a poche iterazioni in cui puoi avere più query e risposte con le query contrassegnate da \n\nUmano e le risposte precedenti contrassegnate da \n\nAssistente. Vediamo la frase migliorata e la chiamata API illustrativa associata ad Amazon Bedrock tramite Boto3 SDK.

Utilizziamo la seguente frase:

Umano: Crea una pipeline che utilizza il database di ExampleCompany per recuperare tutti i clienti attivi

Assistente:

L’output è il seguente:

Ecco una pipeline MongoDB per recuperare tutti i clienti attivi dal database di ExampleCompany:

pipeline = [ { '$match': { 'database': 'ExampleCompany', 'status': 'active' } }]db.customers.aggregate(pipeline)

I passaggi chiave sono:

– `$match` per filtrare i documenti solo quelli nel database di ExampleCompany con stato “attivo”.

– `db.customers.aggregate()` esegue la pipeline sulla collezione dei clienti e restituisce i risultati filtrati.

Quindi restituirà tutti i documenti dei clienti dal database di ExampleCompany in cui il campo di stato è impostato su “attivo”.

Nota come nell’output, Claude fornisce una risposta alla nostra domanda senza alcun contesto. La risposta potrebbe essere utile, ma non è specifica per il problema che stiamo cercando di risolvere perché non viene fornito con abbastanza contesto. È anche importante notare che Anthropica richiede questo formato umano e assistente quando si utilizzano i modelli Claude; se non includi questo passaggio, Amazon Bedrock restituirà un errore.

Miglioramento #2: Includere un contesto iper-specifico per Claude prima che gli venga detto cosa fare

Claude funziona al meglio quando viene fornito un contesto chiaro su ciò che deve fare e su come deve raggiungere l’obiettivo. Ecco alcuni esempi di cose da includere come contesto per Claude prima di dirgli il compito:

• Descrivi la funzione di lavoro che vuoi che Claude svolga. In questo modo, stai facendo pensare a Claude nel ruolo di qualcuno che lavora in quel lavoro, o più come qualcuno appena assunto in quel ruolo specifico. Questo aiuterà Claude a formulare la risposta dalla prospettiva di quel ruolo specifico, riducendo l’allucinazione e la casualità nella risposta.
• Includi dettagli tecnici relativi al formato di output. I modelli di base sono generalmente bravi a seguire le azioni, quindi chiedere a Claude di generare l’output in un formato o schema specifico con uno o alcuni esempi aiuterà Claude a fornire la risposta nel formato corretto, riducendo la necessità di filtrare e postelaborare l’output. L’esempio nel prompt seguente mostra uno schema fittizio che corrisponde all’output atteso.

Uniamo questi suggerimenti per migliorare il nostro prompt originale:

Umano: Il tuo compito è agire come esperto di pipeline ETL. In particolare, il tuo compito è creare una rappresentazione JSON di una pipeline ETL che risolverà la richiesta dell’utente fornita.

L’output JSON dovrebbe seguire il seguente formato:

{  "database": "nome del database che verrà utilizzato qui",  "query": "inserire qui una rappresentazione SQL per risolvere il compito in questione"}

Ecco il tuo compito: creare una pipeline che utilizzi il database di ExampleCompany per recuperare tutti i clienti attivi

Assistente:

L’output è il seguente:

Ecco una rappresentazione JSON di una pipeline ETL per recuperare tutti i clienti attivi dal database di ExampleCompany:

{  "database": "ExampleCompany",  "query": "SELECT * FROM customers WHERE status = 'active'"}

Questa pipeline utilizza il database di ExampleCompany e una query SQL per selezionare tutti i record dalla tabella dei clienti in cui lo stato è ‘attivo’.

Con l’aggiunta del contesto, il modello è ora in grado di arrivare quasi alla nostra risposta. Ora sa come strutturare l’output e capisce che deve scrivere un’istruzione SQL per risolvere il compito. Tuttavia, noterai che il modello non utilizza correttamente la nomenclatura ec_prod.customers che ci aspettiamo. C’è spazio per miglioramenti! Nota anche che, nella pratica, sarà necessario includere molto più contesto rispetto a quello fornito in questo esempio per ottenere risultati di qualità elevata nei casi di utilizzo testo-pipeline.

Miglioramento n. 3: Racchiudere gli esempi tra tag XML

L’apprendimento in pochi passaggi è un modo popolare per aumentare l’accuratezza con i modelli di base quando si hanno esempi pertinenti per guidare il modello nel suo compito. Questo è particolarmente importante quando si lavora con applicazioni testo-pipeline perché queste pipeline iper-specifiche di solito non sono incluse in nessun dataset pubblico perché sono specifiche della rappresentazione dei dati di un singolo cliente. Quando si utilizza Claude, è possibile sfruttare la sua conoscenza innata dei tag XML arbitrari per fornire questi esempi in formato a pochi passaggi. Nel seguente prompt migliorato, si noti l’aggiunta di esempi racchiusi tra i tag XML <example>. Inoltre, è possibile utilizzare le abbreviazioni H e A per riferirsi rispettivamente a umano e assistente e fornire contesto a Claude senza farlo pensare che siano parti specifiche del dialogo già avvenute.

Utilizziamo il seguente prompt:

Umano: Il tuo compito è agire come esperto di pipeline ETL. In particolare, il tuo compito è creare una rappresentazione JSON di una pipeline ETL che risolverà la richiesta dell’utente fornita.

L’output JSON dovrebbe seguire il seguente formato:

{  "database": "nome del database che verrà utilizzato qui"  "query": "inserire qui una rappresentazione SQL per risolvere il compito in questione"}

Ecco alcuni esempi di richieste degli utenti e di artefatti JSON di output associati che risolvono correttamente il compito fornito. Assicurati di utilizzare la stessa nomenclatura fornita negli esempi se stai utilizzando gli stessi database.

<example-1>

H: esegui una query sul database di ExampleCompany per qualsiasi ordine attivo per il cliente n. 1234

A:

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.orders WHERE customer_id = 1234 AND status  = 'active'"}

La ragione di questa query è che il cliente n. 1234 è filtrato e stiamo cercando nella tabella “ordini” per eventuali record esistenti dopo il filtro “attivo”.

</example-1>

<example-2>

H: rimuovi tutti i clienti nel database di ExampleCompany che non sono stati attivi nell’ultimo mese

A:

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status != 'active'"}

La ragione di questa query è che la tabella “ec_prod.customers” è l’unica tabella nel database di ExampleCompany che contiene record dei clienti.

</example-2>

Ecco il tuo compito: creare una pipeline che utilizzi il database di ExampleCompany per recuperare tutti i clienti attivi.

Assistente:

L’output è il seguente:

Ecco la rappresentazione JSON per un ETL pipeline per recuperare tutti i clienti attivi dal database ExampleCompany:

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status = 'active'"}

Il ragionamento è:

Il database ExampleCompany è specificato come database da utilizzare

La tabella ec_prod.customers contiene i dati del cliente

Il campo di stato indica se un cliente è attivo, quindi la query filtra solo i clienti attivi

Ciò dovrebbe recuperare tutti i record dei clienti attivi dal database ExampleCompany. Fammi sapere se hai bisogno di ulteriori chiarimenti o di requisiti aggiuntivi per l’ETL pipeline!

L’output JSON ora ha la corretta nomenclatura del database, che Claude è stato in grado di utilizzare grazie agli esempi che abbiamo fornito. Accoppiare gli indicatori umani e dell’assistente con i tag XML rende più facile per Claude capire qual è il compito e quale è stata la risposta in esempi simili con una chiara separazione tra diversi esempi di few-shot. Più è facile per Claude capire, migliore e più pertinente sarà la risposta, riducendo ulteriormente la possibilità che il modello dia risposte casuali e irrilevanti.

Miglioramento n. 4: Triggerare Claude per iniziare la generazione JSON con i tag XML

Una piccola sfida con le applicazioni di testo-pipeline utilizzando FMs è la necessità di analizzare esattamente un output dal testo risultante in modo che possa essere interpretato come codice in un’applicazione downstream. Un modo per risolvere questo problema con Claude è sfruttare la sua comprensione dei tag XML e combinare questo con una sequenza di arresto personalizzata. Nel seguente esempio, abbiamo istruito Claude ad includere l’output nei tag XML <json></json>. Quindi, abbiamo aggiunto il tag <json> alla fine del prompt. Ciò assicura che il primo testo che esce da Claude sarà l’inizio dell’output JSON. Se non fai questo, Claude spesso risponde con un testo conversazionale, quindi la vera risposta in codice. Istruendo Claude a iniziare immediatamente la generazione dell’output, puoi interrompere facilmente la generazione quando vedi il tag di chiusura </json>. Questo è mostrato nell’aggiornato Boto3 API call. I vantaggi di questa tecnica sono doppi. Primo, sei in grado di analizzare esattamente la risposta in codice da Claude. Secondo, sei in grado di ridurre i costi perché Claude genera solo output di codice e nessun testo extra. Ciò riduce i costi su Amazon Bedrock perché ti vengono addebitati per ogni token prodotto come output da tutti i FMs.

Utilizziamo il seguente prompt:

Umano: Il tuo compito è agire come esperto di ETL pipeline. In particolare, il tuo compito è creare una rappresentazione JSON di una ETL pipeline che risolverà la richiesta dell’utente fornita.

L’output JSON dovrebbe seguire il seguente formato:

{    "database": "il nome del database che verrà utilizzato qui"    "query": "inserisci una rappresentazione sql per risolvere il compito qui"}

Ecco alcuni esempi di richieste degli utenti e relativi artefatti in formato JSON che risolvono correttamente il compito fornito. Assicurati di utilizzare la stessa nomenclatura fornita negli esempi se stai utilizzando gli stessi database.

<example-1>

H: consulta il database ExampleCompany per eventuali ordini attivi per il cliente n. 1234

A:

<json>

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.orders WHERE customer_id = 1234 AND status  = 'active'"}

</json>

Il ragionamento di questa query è che il cliente n. 1234 è filtrato e stiamo cercando nella tabella “orders” eventuali record esistenti dopo il filtro “active”.

</example-1>

<example-2>

H: rimuovi tutti i clienti nel database ExampleCompany che non sono stati attivi nell’ultimo mese

A:

<json>

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status != 'active'"}

</json>

Il ragionamento di questa query è che la tabella “ec_prod.customers” è l’unica tabella nel database ExampleCompany che contiene record dei clienti.

</example-2>

Ricorda sempre di racchiudere i tuoi output JSON nei tag <json></json>.

Ecco il tuo compito: crea una pipeline che utilizzi il database ExampleCompany che recupera tutti i clienti attivi.

Assistente:

<json>

Utilizziamo il seguente codice:

body = json.dumps({"prompt": prompt, "stop_sequences": ['\n\nHuman:', '</json>']})response = bedrock.invoke_model(   body=body,   modelId='anthropic.claude-v2')

L’output è il seguente:

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status = 'active'"}

Ora siamo arrivati all’output atteso con solo l’oggetto JSON restituito! Utilizzando questo metodo siamo in grado di generare un artefatto tecnico immediatamente utilizzabile e ridurre il costo di generazione mediante la riduzione dei token di output.

Conclusioni

Per iniziare oggi stesso con SnapGPT, richiedi una prova gratuita di SnapLogic o richiedi una demo del prodotto. Se desideri utilizzare questi concetti per la costruzione di applicazioni oggi stesso, ti consigliamo di sperimentare in modo pratico la sezione di ingegneria delle prompt in questo post, utilizzando lo stesso flusso su un caso d’uso di generazione di DSL diverso che si adatti al tuo business e approfondendo le funzionalità RAG disponibili tramite Amazon Bedrock.

SnapLogic ed AWS sono stati in grado di collaborare efficacemente per costruire un traduttore avanzato tra il linguaggio umano e lo schema complesso delle integrazioni delle pipeline di SnapLogic basate su Amazon Bedrock. Lungo questo percorso, abbiamo visto come l’output generato con Claude possa essere migliorato nelle applicazioni di testo-pipeline utilizzando specifiche tecniche di ingegneria delle prompt. AWS e SnapLogic sono entusiasti di continuare questa partnership nell’Intelligenza Artificiale Generativa e sono ansiosi di futura collaborazione e innovazione in questo spazio in rapida evoluzione.