Sviluppare un prodotto basato sull'IA generativa: cosa occorre sapere prima di tutto

Introduzione

L'IA generativa è facile da provare, ma è molto più difficile trasformarla in un prodotto su cui le persone possano fare affidamento. Un team può collegare un modello linguistico a un'interfaccia di chat in pochi giorni. Far sì che quell'interfaccia gestisca le richieste reali dei clienti, rispetti i permessi di accesso, lavori con i dati aziendali e si riprenda da risposte errate è tutta un'altra questione.

Per le aziende che stanno valutando l’IA generativa per applicazioni aziendali, la prima decisione da prendere non è quale modello utilizzare, bensì se il problema richieda effettivamente un nuovo prodotto. Gli strumenti di IA già pronti potrebbero soddisfare la maggior parte delle esigenze, mentre un’implementazione personalizzata ha più senso quando il software esistente non è in grado di adattarsi al flusso di lavoro richiesto. Le aziende che valutano quest’ultima opzione possono consultare gli ingegneri specializzati in IA generativa di SysGears per esplorare i requisiti tecnici di un prodotto costruito attorno al loro specifico caso d’uso.

Un prodotto basato sull’IA generativa implica molto di più che inserire un modello dietro un’interfaccia con il marchio aziendale. Il modello può gestire il linguaggio, ma è il resto dell’applicazione a determinare a quali informazioni può attingere, se può interagire con altri software e cosa succede quando la sua risposta non va a segno. Queste decisioni influenzano l’utilità del prodotto tanto quanto la scelta del modello stesso.

Un assistente interno può fuorviare i dipendenti se recupera un documento normativo non aggiornato. Se gli si concede l’accesso ai dati dei clienti, le autorizzazioni di accesso diventano importanti tanto quanto la qualità delle risposte. Se l’applicazione è in grado anche di modificare i dati, una risposta convincente ma errata potrebbe causare danni concreti.

Non si tratta di dettagli da sistemare dopo il lancio. Influenzano l’architettura, lo sforzo ingegneristico richiesto e i costi di sviluppo dell’IA, compreso ciò che serve per mantenere il prodotto in funzione. Un’azienda dovrebbe esaminarli attentamente prima di impegnarsi nello sviluppo, finché c’è ancora margine per restringere l’ambito o decidere che uno strumento esistente possa svolgere il compito.

Partire da un problema che richiede l’IA generativa

Una demo convincente può nascondere un problema aziendale piuttosto ordinario. Se i dipendenti impiegano troppo tempo a cercare nella documentazione interna, ad esempio, un sistema di ricerca semantica potrebbe essere sufficiente. Se invece devono interpretare documenti lunghi, estrarre dettagli specifici e redigere risposte utilizzando informazioni provenienti da diverse fonti, un modello linguistico potrebbe apportare un valore aggiunto più sostanziale.

La distinzione è importante fin dall’inizio. L’IA generativa dimostra il proprio valore quando il software deve dare un senso a materiale disordinato e non strutturato o redigere qualcosa che dipende dal contesto. Per un’attività regolata da regole fisse, invece, uno script ordinario è spesso più economico da eseguire e più affidabile.

Si prenda ad esempio un distributore che gestisce un flusso costante di richieste sui prodotti. I clienti descrivono lo stesso articolo in modi diversi, quindi un’applicazione di IA generativa potrebbe dare un senso alle loro richieste, recuperare le specifiche pertinenti e redigere una risposta. I livelli delle scorte sono un’altra questione. Questi devono provenire dai registri di inventario in tempo reale, mentre un prezzo quotato deve seguire le regole di determinazione dei prezzi dell’azienda, non qualsiasi cifra che il modello produca casualmente.

Vale la pena mantenere chiara questa divisione dei compiti: lasciare che il modello si occupi del linguaggio e affidare le operazioni prevedibili al software convenzionale, ove possibile.

Prima di iniziare qualsiasi sviluppo, individuate con precisione cosa dovrebbe effettivamente migliorare. Il personale di vendita potrebbe impiegare meno tempo a preparare un preventivo; i clienti potrebbero ottenere una risposta senza dover attendere un operatore dell’assistenza. In entrambi i casi, documentate come funziona attualmente il processo. Altrimenti, un team potrebbe finire per festeggiare l’adozione della sua nuova interfaccia di IA senza sapere se questa abbia effettivamente semplificato il lavoro.

Sviluppare o acquistare: di quanto controllo avete effettivamente bisogno?

La decisione tra «costruire» e «acquistare» viene spesso presentata come una scelta tra piena proprietà e praticità. In pratica, esistono diverse opzioni intermedie.

Gli strumenti di IA già pronti sono un punto di partenza ragionevole quando un’azienda ha bisogno di funzionalità familiari come l’assistenza alla scrittura, i riassunti delle riunioni, l’analisi dei documenti o la ricerca generica. Questi prodotti richiedono solitamente meno lavoro di ingegnerizzazione e i loro fornitori gestiscono gran parte dell’infrastruttura sottostante. Un’azienda può verificare se i dipendenti trovano utile una determinata funzionalità senza dover prima finanziare un progetto di sviluppo dedicato.

I problemi iniziano quando uno strumento generico deve adattarsi a un processo per cui non è stato progettato. Potrebbe, ad esempio, non essere in grado di interfacciarsi con un database legacy o di applicare le giuste autorizzazioni di accesso quando i dipendenti ricoprono ruoli diversi. Inoltre, i risultati potrebbero dover essere rielaborati prima che un altro sistema aziendale possa utilizzarli. Le API e le opzioni di configurazione possono aiutare a colmare queste lacune, ma non coprono necessariamente le peculiarità di un flusso di lavoro consolidato.

Un prodotto di IA personalizzato diventa più giustificabile quando il flusso di lavoro stesso rappresenta un vantaggio competitivo, quando i prodotti esistenti non riescono a soddisfare un requisito fondamentale o quando l’applicazione richiede una stretta integrazione con dati proprietari e sistemi interni.

Una terza opzione consiste nel costruire la propria applicazione attorno a un modello ospitato da un fornitore esterno. L’azienda sviluppa l’interfaccia e la logica sottostante, integra il sistema nel proprio software esistente e imposta il proprio metodo per testare i risultati. L’accesso al modello avviene tramite un’API, quindi non è necessario addestrare un modello di base partendo da zero. Ciò offre all’azienda la libertà di modellare il prodotto in base al proprio flusso di lavoro, sebbene si rimanga comunque soggetti ai prezzi del fornitore, alla disponibilità dei modelli e ai limiti del servizio.

Quest’ultima distinzione merita attenzione. Sviluppare un’applicazione IA personalizzata e sviluppare un nuovo modello di IA sono imprese diverse. Addestrare un modello di base richiede notevoli risorse di calcolo, competenze specialistiche, dati adeguati e sperimentazione continua. La maggior parte delle aziende non ha bisogno di assumersi tale onere. Un modello esistente, integrato con il recupero di informazioni dai documenti aziendali o con un accesso agli strumenti accuratamente progettato, può essere sufficiente.

Scegliere l’architettura in base al flusso di lavoro

Una volta chiarito il business case, la sfida successiva consiste nel decidere come funzionerà l’applicazione. Il modello è solo una componente, e potrebbe non essere quella che richiede più tempo di sviluppo.

Per un assistente documentale, spesso vale la pena prendere in considerazione la generazione potenziata dal recupero (RAG). Anziché affidarsi esclusivamente a ciò che un modello ha appreso durante l’addestramento, l’applicazione recupera passaggi rilevanti da una fonte di informazioni approvata e li include nel prompt. Il modello formula quindi una risposta utilizzando quel materiale.

Le risposte basate sulle politiche interne o sulle informazioni aggiornate relative ai prodotti possono risultare più pertinenti, a condizione che il recupero funzioni correttamente. Ma non è detto che sia così. La ricerca potrebbe estrarre un documento obsoleto, tralasciare un’avvertenza cruciale o fornire al modello un passaggio che questo poi interpreti in modo errato.

Il recupero deve essere testato a sé stante. Il modo in cui i documenti vengono suddivisi in parti può influenzare ciò che il sistema trova, e anche un buon risultato di ricerca è inutile se proviene da una fonte che l’utente non dovrebbe vedere. I diritti di accesso di un dipendente devono essere rispettati anche nel processo di recupero, anziché essere ignorati perché una ricerca ha casualmente portato alla luce materiale soggetto a restrizioni. È l’applicazione stessa che deve far rispettare l’autorizzazione. Non ci si dovrebbe fidare di un modello per prendere questa decisione.

La messa a punto ha uno scopo diverso. Può aiutare ad adattare il comportamento di un modello, il formato della risposta o la gestione di schemi di attività ricorrenti quando sono disponibili esempi di addestramento adeguati. Non è un semplice sostituto del recupero quando il problema principale è l’accesso a fatti in evoluzione. Un modello messo a punto sul catalogo prodotti dell’anno scorso non saprà automaticamente cosa è cambiato questa mattina.

Un prompt e un’API del modello potrebbero essere tutto ciò di cui ha bisogno un’applicazione dall’ambito ristretto, almeno all’inizio. Ciò dipende da quanto siano prevedibili gli input e da cosa ci si aspetti che il sistema faccia con i propri output. Se ogni risposta deve essere verificata rispetto a un ampio corpus di documentazione interna, il recupero potrebbe diventare necessario; per un’attività più semplice, potrebbe semplicemente aggiungere un sovraccarico.

Mantenete la prima versione snella e provatela su richieste reali, non solo su input dimostrativi perfezionati. Verificate come gestisce una domanda vaga o informazioni mancanti. Se finge di sapere la risposta invece di ammettere una lacuna, è qualcosa da correggere prima di aggiungere ulteriori elementi.