Un motore di ricerca intelligente
In seguito ai processi di digitalizzazione, le aziende hanno convertito una grande quantità di informazioni in dati digitali. Questi dati, però, sono spesso di tipo diverso, come file di testo, immagini, blue print, file di progetti, e sono salvati in modo non organizzato, disgregati su diversi storage la cui consultazione si traduce spesso in un consumo di tempo importante. Con gli strumenti oggi a disposizione è possibile creare un’infrastruttura informatica che aggreghi i dati e li renda ricercabili da un agente AI tramite il noto metodo di un prompt, per massimizzare l’efficacia e la velocità della ricerca.
Analizzare lo stack informatico necessario
Realizzare una moderna applicazione SAAS solitamente implica lo sviluppo almeno di due componenti: un’interfaccia e un layer back end che gestisca le operazioni CRUD sui dati. Per lo sviluppo di un agente AI, invece, l’equivalente di questo stack è significativamente più complesso.
Alla base dello stack abbiamo la registrazione alle API del LLM su cui ci si intende appoggiare. Per il nostro motore di ricerca basato su AI, infatti, si andrà a utilizzare un LLM (Large Language Model) già esistente, in modo da poter ereditare tutte le conoscenze che il modello già possiede in fatto di cultura generale, linguaggio, interazione con gli utenti: ci si potrà così concentrarci solo nel doverlo istruire sulla parte relativa ai dati aziendali. Una volta eseguita la registrazione alle API, bisognerà creare un modello personalizzato, che verrà istruito con i dati della propria azienda ma sarà in grado di impiegare le funzionalità del modello padre tramite le API. A questo punto, ci si potrà dedicare alla parte di UI/UX, dove andremo a creare l’interfaccia del prompt per effettuare le ricerche sul modello.
Come utilizzare le API di un LLM
Tutti i Large Language Model esistenti, come Chat GPT, Claude o Gemini, mettono a disposizione delle API (interfacce di programmazione) invocabili in procedure personalizzate. Per utilizzare queste API occorre sottoscrivere un abbonamento, per ricevere il token di autenticazione che consentirà di accedere alle funzionalità necessarie.
A seconda del LLM scelto, le API potranno essere fruibili per mezzo di chiamate REST a degli endpoint, oppure con delle librerie Python installabili nel proprio ambiente di sviluppo. Alcuni fornitori mettono anche a disposizione framework in cloud, già interfacciati con le librerie necessarie, da cui è possibile eventualmente anche noleggiare le GPU necessarie al training del modello.
Fattori di scelta di un LLM
Scegliere il LLM con cui interfacciare il proprio agente richiede la valutazione di alcuni fattori chiave.
Il primo è sicuramente il costo. Le differenze di pricing possono essere significative non solo tra i diversi LLM, ma anche tra diverse versioni di uno stesso modello. Scegliere di utilizzare l’ultima versione di un LLM, aggiornata e performante, può costare di più che accontentarsi di una versione legacy, che però potrebbe rivelarsi sufficiente per le nostre esigenze. Occorre perciò impratichirsi nelle differenze tra i vari LLM e le loro versioni, magari facendo delle prove con i diversi prompt, in modo da capire quale sia la fascia di pricing a noi necessaria.
Un’altra considerazione importante riguarda la specializzazione del LLM. Ad esempio, un modello come Claude mostra una maggiore esperienza nel campo del codice software rispetto ad altri suoi competitor, magari più performanti nel riconoscimento di immagini. Se perciò stiamo costruendo un Agente AI che si occuperà di catalogare repository software, potremmo orientarci all’impiego di Claude, mentre se il nostro agent avrà a che fare ad esempio con logiche di riconoscimento facciale potremo deciderci di rivolgerci ad altri LLM.
Training e validazione del modello
Stabilito il collegamento con le API del LLM padre, è ora il momento di addestrare il modello per rispondere alle ricerche degli utenti relativi ai dati aziendali. Per il training occorrerà innanzitutto inventariare il materiale digitale (documentazione, immagini, file tridimensionali di progetti, ecc.) che intendiamo rendere disponibile al prompt di ricerca. Dovremo poi definire una pipeline di training, ossia una sequenza di istruzioni che normalizzeranno i dati e li etichetteranno con delle label per aiutare l’agente AI a interagire con le richieste dell’utente finale. Particolare attenzione andrà dedicata alla procedura di validazione, per evitare fastidiosi over fitting che andrebbero a falsare i risultati del modello una volta messo in produzione. Per realizzare il codice software necessario alla pipeline ci si può affidare a un consulente di data science, oppure utilizzare un template che spesso i fornitori delle API mettono a disposizione. In questo caso, sarà sufficiente eseguire un fine tuning dei parametri del modello prima di metterlo in produzione.
Esperienza utente
L’apparente banalità grafica dei prompt di intelligenza artificiale non deve trarre in inganno: le logiche che si scatenano dietro a quella semplice casella di testo sono complesse, e richiedono molti accorgimenti affinché l’esperienza utente risulti appagante.
Per processare il prompt dell’utente, occorrerà innanzitutto gestire la logica per scomporre la richiesta in token significativi. Questi token andranno valutati in modo da decidere se siano sufficienti per scatenare le logiche di regressione o classificazione che popoleranno i risultati di ricerca.
Se la pertinenza dei token non è quella desiderata, occorre stabilire la qualità del feedback da restituire all’utente: un dialogo che offra l’illusione di un’interazione personale sarà sicuramente più appagante di una generica richiesta di maggiori informazioni. Il primo caso, però, è sicuramente più complesso da mettere in produzione.
Fortunatamente, avendo deciso di impiegare delle API, potremo fare affidamento sulle competenze del modello padre per pilotare il dialogo con l’utente fino all’ingegnerizzazione di un prompt soddisfacente. Occorre però valutare i costi dell’impiego di ulteriori chiamate alle API, anche in relazione al volume dei token che andremo a processare: entrambi i fattori potrebbero farci sforare la fascia di consumo preventivata, causando ulteriori addebiti. Sarebbe consigliabile, anche qui, fare diversi test prima di andare in produzione per accertarsi di rimanere correttamente nei range del budget disponibile.
