Storie di successo SnapLogic: dai requisiti aziendali alle soluzioni AI implementate [Integreat 2025]

Trascrizione:

Il mio collega Chris Ward, che dirige il Center of Excellence/Center of Enablement, espande l'acronimo in entrambi i sensi, e ho pensato di raccontarvi tre storie di clienti provenienti da diversi settori industriali in tutto il mondo, cercando di mostrarvi come hanno ottenuto i loro risultati, come hanno risolto i loro particolari problemi aziendali e come ciò si traduce nella pratica.

I tre clienti di cui parleremo sono Aptia, un marketplace dedicato alla sanità, Accor, un programma di fidelizzazione per viaggiatori, e Drax, un'azienda che produce energia rinnovabile. Alla fine ci sarà anche tempo per domande e risposte.

Ma cominciamo con Aptia. Aptia è un cliente di lunga data di SnapLogic.

Si occupano dell'amministrazione delle pensioni e delle prestazioni per la loro attività. Quindi hanno circa 7.000.000 di persone che coprono con queste prestazioni sanitarie in 1.100 aziende.

Operano negli Stati Uniti, nel Regno Unito, ma anche in India e Portogallo. Gestiscono quindi questo mercato, questo portale dove le persone possono vedere a quali benefici hanno diritto.

Possono richiedere vari servizi. Quindi, l'inserimento di nuove persone e nuove aziende nel loro sistema è ovviamente una parte fondamentale della loro attività, così come la capacità di gestire l'interazione tra le persone, i servizi a cui hanno diritto e i fornitori con cui hanno a che fare.

Quindi, prima di tutto, non possono verificarsi perdite di dati. Non può capitare che qualcuno abbia sottoscritto un'assicurazione sanitaria e poi non riceva ciò che gli spetta.

Questo processo richiede anche un notevole lavoro di inserimento manuale dei dati. Si tratta solo di cinque-otto minuti per partecipante, ma moltiplicando questo tempo per centinaia e migliaia di partecipanti, il tempo richiesto aumenta rapidamente.

E poi, a seconda del tipo di giurisdizione sanitaria, potrebbero esserci delle trattenute sullo stipendio da gestire. Anche in questo caso, tali trattenute vengono aggiornate nel tempo.

Quindi, ogni mese, vengono apportate da 5.000 a 10.000 modifiche diverse ai record per tenere traccia di tutto ciò, poiché gli stipendi, i diritti e qualsiasi altra cosa cambiano nel tempo. Quindi, in sostanza, ciò che ne deriva è un'enorme sfida in termini di dati che Aptia sta affrontando.

Si tratta quindi di grandi volumi di flussi di dati, che includono tutti i tipi di dati relativi alle persone coperte, i dati di iscrizione, i loro diritti. Ma questi sono solo i dati interni ad Aptia, perché c'è anche l'integrazione con tutti i fornitori di assistenza sanitaria e i sistemi dei datori di lavoro con cui Aptia deve lavorare.

Quindi le integrazioni che vanno oltre il firewall sono sempre quelle più divertenti. Specifiche per il cliente del libro paga e tutto questo è anche soggetto alle normative di conformità, che poi sono diverse da un paese all'altro.

E non possono scherzare qui, sia a livello personale. Non si può scherzare con la salute delle persone.

Tendono a non apprezzarlo molto. Ma ci sono anche tutti gli adempimenti normativi e la supervisione legale richiesti nel settore sanitario e finanziario.

Quindi l'insieme di tutti i processi serve solo a garantire che tutto funzioni correttamente. Quindi, ciò che sono riusciti a fare con SnapLogic è stato sostanzialmente simile a quanto abbiamo sentito da Spotify.

Così sono riusciti a coinvolgere molte persone nella creazione di pipeline. Sono riusciti addirittura a far sì che fossero gli esperti in materia a creare direttamente le pipeline.

Ci sono circa 30 persone che lavorano lì e questo ha ridotto il tempo di inserimento dei dati del 99%. In pratica ha eliminato l'inserimento dei dati.

Solo in casi eccezionali qualcuno deve effettivamente mettersi alla tastiera. Hanno anche iniziato a ricorrere a integratori di dati per compiti di livello superiore per quelle integrazioni con altri sistemi, in particolare quelli esterni all'azienda.

E grazie al successo ottenuto, si sono espansi fino a comprendere cinque diversi gruppi funzionali all'interno dell'azienda. Finora tutto bene.

Ma come hanno fatto concretamente? Allora, Chris, perché non ci sveli i retroscena e ci racconti come è andata nella pratica?

Assolutamente sì. Quindi, se analizziamo il flusso di lavoro operativo così come era strutturato in Aptery, lo consideriamo essenzialmente un flusso di lavoro di elaborazione delle e-mail.

Quindi avevano dei team che monitoravano manualmente le caselle di posta elettronica, con diversi tipi di piani. Ricevevano le e-mail, scaricavano gli allegati, estraevano manualmente i dati e le informazioni da tali allegati e poi cercavano di trasferirli in un modello Excel.

Quindi abbiamo fatto un passo indietro e abbiamo cercato di individuare i quattro pilastri fondamentali che dovevamo integrare nella soluzione. Innanzitutto, l'automazione del monitoraggio continuo dell'arrivo delle e-mail nella casella di posta, l'estrazione e l'analisi degli allegati presenti nelle e-mail e infine la suddivisione delle diverse regole di mappatura relative a ciascuno di questi allegati.

Quindi abbiamo ottenuto un formato JSON strutturato, ovvero un formato coerente con cui potevamo lavorare e che ha reso davvero facile la mappatura in un modello che il team ha potuto poi portare avanti e presentare ai team aziendali. Quindi, la cosa fondamentale da sottolineare qui è che gran parte di ciò che vediamo in anticipo è solo l'estrazione dei dati.

E poi abbiamo le regole di mappatura, ed è qui che entra in gioco l'LLM per supportare alcune di queste attività. E poi, per trasferire tutto questo anche sul foglio di calcolo Excel, utilizziamo l'LLM.

E così chiudiamo il cerchio. Abbiamo quindi una sorta di flusso end-to-end dell'e-mail dall'inizio alla fine.

Stiamo cercando di chiudere e contrassegnare come letta anche l'e-mail iniziale come risultato di ciò. Quindi, in termini di come ciò viene rappresentato in SnapLogix, abbiamo una pipeline qui che potete vedere sullo schermo che in realtà sta solo suddividendo quei pilastri in entrambi i tipi di snap.

Quindi, alcune cose da sottolineare. Abbiamo degli snap standard pronti all'uso per monitorare la casella di posta elettronica all'inizio.

Abbiamo uno snap router che ci permette di prendere le regole aziendali, la logica di routing per ciascuno dei diversi tipi di piano e allegati, e poi applicare una logica diversa. Infine, abbiamo la generazione del riepilogo del piano, che è il modello Excel che otteniamo, e poi chiudiamo il ciclo con la generazione delle e-mail che vengono inviate al team.

Va bene. Ottimo.

Ecco come funzionano queste cose. Abbiamo quindi alcuni componenti standard.

Abbiamo alcune best practice. Abbiamo alcuni modelli e schemi che possiamo mettere in pratica.

E questo è in grado di gestire quello che prima era un processo molto manuale e di automatizzarlo, in modo che quelle persone potessero concentrarsi su altro, come ad esempio soddisfare meglio le esigenze sanitarie dei pazienti. Passiamo ora a un altro esempio e spero che inizierete a cogliere i temi che si sviluppano qui.

Questo coincide anche con quanto affermato in precedenza da Ralph di Boehringer Ingelheim. Accor Plus è quindi un programma fedeltà per viaggiatori che opera nella regione Asia-Pacifico.

Quindi Accra gestisce diversi marchi alberghieri. Ha circa 25 marchi alberghieri, dal Fairmont Sofitel e dal Raffles Hotel nella fascia alta, fino a quelli in cui potrei soggiornare io, come Ibis, Mercure o Tribe, ecc.

Ma nell'area Asia-Pacifico hanno anche un fondo extra che gestiscono in 20 paesi diversi. Ovviamente, in ciascuno di questi paesi e per tutti questi marchi, la matrice delle competenze, delle descrizioni delle mansioni, delle retribuzioni, delle possibilità di avanzamento di carriera ecc. era molto complessa e per nulla allineata.

Quindi stavano cercando di armonizzare questo aspetto con l'iniziativa dell'ora. In questo modo, in tutta la regione ci sarebbe stata coerenza e questo li avrebbe aiutati a ottenere la certificazione Hey Job Evaluation, che è fondamentalmente una certificazione di standardizzazione e prevedibilità dell'avanzamento di carriera e simili.

Il grande problema che il Gruppo Acarbel doveva affrontare era che molte di queste descrizioni di mansioni pregresse erano archiviate in dati non strutturati. Parliamo quindi di PDF, documenti Word, questo genere di cose, persino scansioni di stampe, possibilmente anche in lingue diverse.

E così il ruolo, le responsabilità, le competenze, le aspettative di leadership, sono completamente diversi, definiti in modo diverso, descritti in modo diverso e materialmente diversi anche tra le diverse regioni di una nazione all'altra. E hanno questa spinta strategica a standardizzare tutto questo per dargli un senso, in modo da facilitare il reclutamento, l'inserimento e l'allineamento delle prestazioni, così che qualcuno sappia che io sono un grado X, qualunque cosa significhi, cosa significa effettivamente in questo paese rispetto a quell'altro.

Dovrebbe essere almeno in qualche modo comparabile. Avevano anche una cultura molto rigida, quindi stanno cercando di standardizzare le lingue, le descrizioni dei lavori e cose del genere.

Ancora una volta, solo nel processo di standardizzazione di tutti questi sistemi. E stavano cercando di fare tutto questo a mano, il che semplicemente non è scalabile.

Ci sono ritardi, incongruenze, è necessario rifare gran parte del lavoro. E ancora una volta, si mette a repentaglio il sostentamento delle persone, si mette a repentaglio la loro retribuzione, la loro progressione di carriera, le loro possibilità di promozione o, dal punto di vista aziendale, la capacità di trattenere il personale qualificato invece di vederlo andare via e passare alla concorrenza, il che non è certo positivo.

Quindi è necessario un processo scalabile per supportare tutto questo. Ma come fanno? Sì. Analogamente all'esempio di Aptera, abbiamo cercato di scomporre il problema.

Quindi, invece di affidarci completamente al grande modello linguistico e aspettarci che risolvesse il problema, abbiamo cercato di individuare gli elementi chiave da prendere in considerazione. Quindi, partendo dall'estrazione dei dati, che è piuttosto intuitiva, abbiamo voluto estrarre le vecchie descrizioni delle mansioni da Google Drive.

Li abbiamo effettivamente trasferiti in un bucket S3. Volevano sfruttare meglio i loro servizi AWS per altre esigenze basate su quei dati.

Abbiamo quindi letto la descrizione del lavoro, l'abbiamo messa in pausa e poi abbiamo risolto il primo ordine, ovvero la standardizzazione della matrice di lavoro. Quindi, come ha detto Dominic, avevano diversi livelli di coerenza dei dati tra le diverse aree geografiche e il modo in cui ordinavano e strutturavano tali dati.

Quindi abbiamo deciso di trovare un modo per standardizzare questo processo. Ovviamente, sappiamo che gli LLM eccellono in questo tipo di lavoro.

Quindi, tornando a una sorta di schema JSON formalizzato per quei dati. E poi cerchiamo di mappare e ampliare il tipo di cultura aziendale di cui parlava Dominic, la mappatura dei nuovi ruoli lavorativi e il nuovo schema di descrizione dei lavori.

Inoltre, aiutiamo a guidare l'LLM nella definizione di cosa sia un buon lavoro in termini di come pensiamo alla stesura di una buona descrizione del lavoro. Quindi, riassumendo tutto questo in una sintesi, il risultato finale è che abbiamo una descrizione del lavoro trasformata.

E poi l'ultimo passo è ancora una volta come presentarlo in modo che possa essere mostrato ai dirigenti e al management. Quindi utilizziamo l'LLM per generare una presentazione PowerPoint con quella nuova descrizione del lavoro e poi la mappiamo in SuccessFactors, che è anche il loro sistema HR interno.

Quindi risolvere davvero il processo end-to-end, ridurre i tempi e, sì, essere in grado di muoversi più velocemente. Quindi la pipeline, ancora una volta, è molto, molto simile: leggere i dati, analizzarli inizialmente.

Quindi cerchiamo di aumentare i dati aggiuntivi relativi, sì, al tipo di cultura aziendale, al nuovo schema di descrizione del lavoro. Stiamo informando l'LLM con un prompt di sistema, assegnandogli un compito specifico, un ruolo per poi trasformarlo nella nuova descrizione del lavoro e poi, alla fine, richiamando la funzione Lambda e caricando quei dati in S3.

E penso che questo sia particolarmente interessante perché non so se avete notato che uno dei risultati è una presentazione PowerPoint. Quindi il flusso di lavoro classico prima sarebbe andato bene, forse abbiamo tutto in SuccessFactors e poi qualcuno genera qualcosa e lo copia e incolla in PowerPoint come classico esempio di lavoro superfluo.

Ora, qualcuno con competenze specifiche nel settore e accesso ai sistemi dovrebbe occuparsene, ma se SnapLogic è in grado di farlo, ciò non sostituirà quella persona. Il punto è che quella persona ha cose migliori da fare con il proprio tempo.

E se riusciamo a liberarli da quel lavoro faticoso, è lì che si ottiene l'impatto, il vantaggio. Passiamo quindi al terzo esempio del nostro tour frenetico intorno al mondo.

Avevamo quindi un cliente negli Stati Uniti e uno nell'area Asia-Pacifico. Questo è quello più vicino a casa nostra. Si tratta di Drax, un'azienda che produce energia rinnovabile proprio qui nel Regno Unito. Si concentra principalmente sulla produzione di energia rinnovabile, ma svolge anche attività significative nel campo della produzione sostenibile di biomassa e della cattura e dello stoccaggio del carbonio.

È davvero interessante, visto che continuiamo a sentire parlare di come gli LLM consumino sempre più energia. È bello sapere che qualcuno sta pensando di fornire quell'energia in modo pulito e sostenibile.

E così hanno avuto l'idea di utilizzare l'IA, non per nessuno di questi scopi, ma per gestire i loro fogli presenze. Ma i fogli presenze sono un problema significativo perché monitorare il lavoro delle persone, se avete mai provato a farlo, voglio dire, probabilmente tutti noi siamo stati almeno una volta oggetto di monitoraggio del nostro tempo, dovete andare a inserire il vostro tempo in una sorta di portale dei fogli presenze, ma ci sono anche gli eventi del calendario.

Probabilmente c'è un foglio di calcolo da qualche parte. C'è una sorta di sistema di domini.

In questo caso, si trattava degli sprint delle attività di Azure DevOps, dei ticket, delle unità di lavoro DevOps, dei progetti e delle allocazioni dei centri di costo, e poi di tutto il resto. È qui che entrano in gioco i fogli di calcolo, i foglietti di carta sulla scrivania e quant'altro.

Quindi bisognava raccogliere tutte queste informazioni perché bisogna pagare le persone. Ma se lo si fa a mano, è molto inefficiente, è incoerente e le persone saranno insoddisfatte dei risultati se non le si paga abbastanza e si potrebbe finire per pagare più del dovuto e quindi aver perso un sacco di tempo.

Anche i ritardi nel farlo sono costosi. Non solo in termini di tempo delle persone che lo fanno.

È costoso in termini di risultati perché non è possibile chiudere i conti, non è possibile fare previsioni per il prossimo periodo finanziario. Ciò significa che potresti non ottenere il budget necessario per qualsiasi cosa tu stia cercando di fare in futuro.

Le ripercussioni sono enormi. Quindi sei direttamente coinvolto in questo caso.

Perché non ci spieghi come funziona?

Ero presente e credo che anche alcuni dei collaboratori di Drax siano qui con noi, quindi molto vicini a casa. Quindi sì, è stato davvero interessante.

Avendo un background nel settore dei servizi professionali, potevo identificarmi molto con il tipo di lavoro che stavamo cercando di trasformare qui. Ogni venerdì, inviavo una sorta di resoconto del tempo che avevo dedicato ai diversi progetti.

È un'operazione che richiede molto tempo ed è l'ultima cosa che vorresti fare in un venerdì pomeriggio. Quindi sì, per questi casi, l'argomento in questione era proprio quello di esaminare i diversi sistemi di origine.

Quindi, utilizzando le API Microsoft Graph per estrarre tutti i dati, i dati strutturati negli inviti del calendario, il tempo trascorso lì e anche entrando in DevOps per le diverse attività lavorative che il team svolgeva quotidianamente. Una cosa interessante al riguardo era che Draxwear era molto attenta a fornire ed esporre informazioni sensibili all'LLM.

Quindi hanno voluto riflettere su come mitigare eventuali rischi o esposizioni di dati sensibili. Abbiamo quindi valutato l'integrazione delle protezioni NVIDIA NEMO, che per chi non lo sapesse sono effettivamente un firewall LLM.

Quindi possiamo dargli un prompt che forse espone alcuni dati e ci darà, sì, un risultato positivo o negativo a seconda che esponga o meno i dati. Questa è stata la prima fase.

Passiamo quindi alla mappatura nel codice del progetto, quindi, sulla base del loro portale dei fogli presenze, varie mappature e codici che vogliono tradurre nelle attività lavorative provenienti dalla fonte utilizzando un LLM open source, Alarmah, ospitato in loco. Il risultato è che otteniamo una bozza di foglio presenze, che, ancora una volta, vogliamo mantenere come componente umana nel ciclo, non solo come semplice foglio presenze da inviare.

Vogliamo poter verificare la qualità di ciò che viene prodotto. Quindi, in realtà, l'ultimo passo è che gli stakeholder possano esaminare ciò che è stato prodotto e approvarlo o rifiutarlo.

Quindi, in realtà, si tratta di qualcosa che, sì, ancora una volta, siamo riusciti a racchiudere in una serie di pipeline molto semplici, ancora una volta, ricavando i dati dai diversi endpoint di origine, consolidandoli, unendoli, fornendoli all'LLM con un prompt di sistema e poi prendendo quella risposta strutturata e mappandola nel foglio presenze verso la fine. Quindi, ancora una volta, utilizzando le funzionalità pronte all'uso di cui disponiamo per l'estrazione, la mappatura e la trasformazione dei dati, nonché i nuovi snap AI.

Ottimo. Allora, cosa abbiamo imparato? Una delle cose che cerchiamo di fare in SnapLogic è migliorare, progredire e aiutare i nostri clienti a migliorare.

Abbiamo quindi avviato diverse iniziative per cercare di acquisire le informazioni. Non è che qualcuno consegni Drax o AbbVie o qualsiasi altro progetto e poi se ne vada, lasciando quelle informazioni sul proprio hard disk.

Vogliamo provare a documentarlo e condividerlo, e cercare di garantire che tutti ne traggano il massimo beneficio possibile. Questo è l'obiettivo di questa sessione: darvi, in modo molto sintetico, un assaggio di ciò che abbiamo imparato da queste iniziative e poi parleremo tra poco di come lo facciamo a un livello più strutturato.

Assolutamente sì. Alcuni di questi potrebbero risuonare dalla sessione precedente, se sei con Ben di Spotify.

Alcuni temi comuni che stiamo osservando, credo, in generale nel settore quando affrontiamo e discutiamo questi casi d'uso dell'IA, sono in realtà una visione chiara di dove riteniamo di poter costruire un caso. Quindi, se avete partecipato al workshop Slalom di prima, che era incentrato sul ritorno sull'investimento e sull'aiuto a sviluppare un business case davvero chiaro basato su come viene svolto oggi il lavoro all'interno dell'azienda, quali sono i rischi, i costi che possiamo poi proiettare e integrare in un solido modello di ROI.

Questo ci aiuta a evitare di limitarsi a introdurre la tecnologia e a investire tutto su di essa, aiutandoci invece a concentrarci su un'area specifica dell'azienda su cui possiamo focalizzare la nostra attenzione. Quindi, partendo da questo presupposto, cerchiamo di comprendere in modo dettagliato come si presenta oggi il flusso di lavoro, se esiste, collaborando con l'azienda e analizzando il processo dall'inizio alla fine.

Lo abbiamo fatto con CCB, uno dei nostri clienti che sta portando avanti un progetto di trasformazione AI di grande portata nel settore della finanza patrimoniale. Stiamo investendo molto tempo in questo progetto, che ci aiuta a capire quali sono i punti critici del processo e dove possiamo intervenire con l'AI per migliorare la situazione.

Il prossimo passo è quello di riuscire a realizzare prototipi con il maggior numero possibile di dati reali, il che ci aiuta a individuare eventuali casi limite che potrebbero verificarsi in produzione. Quindi, invece di limitarsi a simulare dati di prova iniziali per aiutare a costruire il prototipo iniziale, l'utilizzo di dati reali e concreti ci aiuta a perfezionare la soluzione.

Il processo di convalida e perfezionamento non consiste semplicemente nel fornire un prodotto, metterlo in produzione e lasciarlo lì. È possibile ottenere un grande valore dalle attività che si svolgono in un ambiente di produzione con questi casi d'uso dell'IA.

Si tratta di comprendere appieno i risultati dei prompt e le risposte dei modelli di linguaggio large (LLM) per aiutare a reiterare e perfezionare il caso d'uso anche in futuro. Quindi, per quanto riguarda il modo in cui sintetizziamo tutto questo e lo proponiamo a clienti come voi per supportarvi nel vostro percorso, abbiamo un programma Identik Elite, che è un percorso di abilitazione della durata di dodici mesi che mira a codificare e riunire tutte le best practice che osserviamo tra i diversi clienti e casi d'uso con cui lavoriamo nell'ambito dell'IA.

Quindi il nostro primo obiettivo è quello di accelerare il più possibile il primo caso d'uso produttivo, supportandovi in questo percorso, ma in modo sicuro, perché vogliamo assicurarci che fin dall'inizio siano presenti le giuste misure di sicurezza, osservabilità e discussione sul ROI, piuttosto che in un secondo momento. E poi, mentre cerchiamo di scalare anche lo sviluppo dei casi d'uso dell'IA, vogliamo intraprendere un percorso di aggiornamento professionale, consentendo a una forza lavoro più ampia di partecipare allo sviluppo dei casi d'uso dell'IA, sempre utilizzando le migliori pratiche.

Abbiamo quindi una libreria Sigma Framework disponibile nella nostra community che ha lo scopo di documentare e raccogliere molte di queste best practice e il nostro modo di pensare su come fare le cose nel modo giusto. Sentitevi liberi di darci un'occhiata.

Abbiamo anche alcuni fantastici manufatti.

Sì. Di cosa si tratta?

Ricordate le statistiche di Dayle: l'85% dei progetti di IA non entra in produzione. Questo perché di solito falliscono su uno di questi ostacoli.

O richiedono troppo tempo per essere avviati e quindi non mostrano alcun risultato in tempi utili, oppure non sono percepiti come sicuri e quindi qualcuno dell'ufficio legale o di conformità o altro alza la mano e dice basta, basta, basta, basta, basta. Questo non entrerà in produzione.

Oppure semplicemente non vengono utilizzati. Non vengono adottati e quindi in un certo senso muoiono sul nascere.

E così ora abbiamo avuto la fortuna di lavorare con diversi clienti nel campo dell'intelligenza artificiale. Come avete visto nelle slide di Jeremiah, siamo stati tra i primi ad avvicinarci al mondo dell'intelligenza artificiale.

Ora abbiamo un'idea piuttosto chiara di cosa funziona e cosa no, e vorremmo assicurarci che i vostri progetti siano quelli che funzionano. Sono quelli che rientrano nel 15% che ha successo, che mostra risultati concreti e che ci permette di capire quale sarà il prossimo passo, a quali vostri colleghi potremo raccontare la nostra esperienza affinché anche loro possano trarne beneficio.

Ma detto questo, Chris ed io siamo qui per rispondere alle vostre domande nei prossimi minuti, prima di ricongiungerci con tutti gli altri per la sessione di chiacchierata informale. Qualcuno ha domande? Proprio qui davanti.

È sempre così. Ci dispiace, oggi ti stiamo facendo correre.

Quando si utilizzano gli LLM per compilare modelli e inviare notifiche e altro, come si fa a testarli fino al punto da poterli tranquillamente mettere in produzione?

Ottima domanda. Sì, è una questione che mi riguarda da vicino.

Ho lavorato a molti progetti interni e la prima cosa che mi è venuta in mente è stata: come possiamo creare fiducia nei risultati e riuscire a monitorare i progressi man mano che sviluppiamo il progetto? Credo che la chiave sia avere alcuni KPI su cui basare la soluzione.

Quindi si tratterebbe della qualità dei risultati, della coerenza dei dati, dell'integrazione di tutto ciò nelle valutazioni, di un quadro di riferimento per i test su ciò che stiamo costruendo e della sua valutazione costante. Quindi sì, si tratta di avere una visione chiara di cosa sia.

Stiamo prendendo dati non strutturati, mappandoli in un formato JSON, verificando la completezza dello schema e disponendo anche di una sorta di set di dati di test di riferimento a cui possiamo fare riferimento per orientare la qualità dell'output. Ma sì, questo è qualcosa a cui penso dovremmo davvero pensare, al punto che il framework AgenTic Elite è davvero all'inizio del progetto, per capire quali sono le misure chiave della qualità e del successo.

E abbiamo anche integrato alcune funzionalità del prodotto. Se si osservano le prime versioni di GenAI App Builder, si noterà che offrivano solo una casella di testo in cui scrivere il prompt.

E questo va bene, ma quando lo fai devi tenere a mente molte informazioni. Il nuovo workbench Prompt Composer presente nell'ultima versione di AgentCreator offre una visibilità molto maggiore perché hai a disposizione i tuoi dati e lo schema dei dati di input.

Hai i tuoi prompt perché stai ancora facendo prompt engineering, ma hai un assistente AI che ti aiuta se vuoi. E puoi vedere i risultati in tempo reale.

Man mano che modifichi il prompt, puoi vedere il cambiamento nei dati di output e nello schema di output. Questo è già di grande aiuto.

E poi ci sono le best practice, le competenze che Chris e il suo team possono apportare. E sì, continuiamo a lavorare su questo aspetto.

Un altro elemento è il visualizzatore dell'agente, che consente di vedere quando si sta costruendo qualcosa di veramente agentico. Quindi il flusso di lavoro non è deterministico.

Il punto è capire in una certa misura quali strumenti utilizzare e quali agenti coinvolgere. Essere in grado di visualizzare questo processo è fondamentale sia nella fase di sviluppo, per capire come il sistema sta svolgendo o potenzialmente non sta svolgendo il compito, sia in seguito, per fornire l'udibilità di cui parlava Ben e capire come ha raggiunto un determinato risultato o ha preso una determinata decisione.

Sì. E aggiungerei anche che una soluzione rapida che potremmo prendere in considerazione è chiedere all'LLM di fornirci un livello di confidenza basato sul compito che gli stiamo chiedendo di svolgere.

Questo ci permette di capire in qualche modo cosa pensa l'IA, se è in linea con ciò che le stiamo chiedendo. In questo modo possiamo segnalare alla revisione umana tutti i livelli di confidenza inferiori a una certa soglia.

E questo vale non solo nella fase di sviluppo, test e iterazione, ma anche nella produzione. È utile sì, la tattica che puoi usare in questo caso.

Ottimo. Prossima domanda.

Va bene. Ancora uno e poi siamo liberi.

 Lavoro con diversi clienti che conoscono molto bene la piattaforma SnapLogic. Quali consigli daresti per aiutarli ad ampliare l'utilizzo degli agenti e, in un certo senso, a iniziare davvero?

Sì. Quindi abbiamo una comunità.

Quindi la Sigma Library di cui abbiamo parlato contiene risorse davvero ottime che aiutano a capire come sfruttare la piattaforma per sviluppare casi d'uso dell'IA. Oltre a ciò, sul web si trovano tantissimi materiali su concetti quali il prompt engineering, il data context engineering e altri aspetti simili.

E davvero, penso che basti buttarsi, iniziare a costruire, creare prototipi, usare la tecnologia per capire dove si può arrivare per risolvere i problemi che esistono all'interno dell'azienda? Beh, ecco fatto.

No, ma dirò una cosa. Uno dei fattori che compromette irrimediabilmente i progetti di IA è l'accesso ai dati.

Quindi hai una demo davvero interessante e puoi programmare qualcosa in pochissimo tempo. Sarà fantastico e tutti diranno: "Oh, meraviglioso!".

È possibile inserire i dati di produzione? Se sei già un utente SnapLogic, allora sei già un passo avanti rispetto alla maggior parte del mercato perché disponi di quella struttura di integrazione, di quella struttura dati. Puoi collegarla a qualsiasi cosa.

Quindi potrebbe trattarsi di qualcosa che opera dietro le quinte, come tutte le demo o tutte le situazioni che abbiamo mostrato oggi, oppure potrebbe essere qualcosa di molto più innovativo, come quello che Jeremiah ha coraggiosamente dimostrato sul palco utilizzando cloud . Ma tutte queste soluzioni richiedono l'interazione con tutti i sistemi di back-end.

Come ho detto, in qualità di utenti SnapLogic, avete già un grande vantaggio rispetto ai vostri colleghi, quindi forse dovreste iniziare con la domanda "Dovrei usare l'IA per qualcosa?" piuttosto che "Per cosa userò l'IA, dato che ho già accesso a tutti i dati necessari per alimentarla?". Il nostro fondatore, Gaurav Dhillon, dice sempre che l'IA muore di disidratazione dei dati, e noi non vogliamo che questo accada.

Vogliamo essere ben idratati.