L’idea è di dividere il flusso di lavoro in due flussi per ottimizzare costi e stabilità, come proposto con il Architettura LATMcon alcuni miglioramenti aggiuntivi per la gestione dei dati e delle memorie specifici delle Ricette Dati…
Flusso 1: Assistente ricette
Questo flusso utilizza agenti LLM e modelli più potenti per generare frammenti di codice (ricette) tramite un’interfaccia conversazionale. Il LLM viene istruito con informazioni sulle origini dati (specifiche API e schema del database) in modo che la persona che crea ricette possa programmare più facilmente nuove competenze in modo conversazionale. È importante sottolineare che il processo implementa una fase di revisione in cui il codice generato e i risultati possono essere verificati e modificati da un essere umano prima di essere memorizzati. Per una migliore generazione del codice, questo flusso utilizza modelli più potenti e agenti autonomi, comportando costi più elevati per richiesta. Tuttavia, c’è meno traffico quindi i costi sono controllati.
Flusso 2: Assistente all’analisi dei dati
Questo flusso viene utilizzato dal gruppo più ampio di utenti finali che pongono domande sui dati. Il sistema controlla la memoria per vedere se la loro richiesta esiste come un dato di fatto, ad esempio “Qual è la popolazione del Mali?”. In caso contrario, controlla le ricette per vedere se ha la capacità di ottenere la risposta, ad esempio “Come ottenere la popolazione di qualsiasi paese‘. Se non esiste memoria o abilità, viene inviata una richiesta alla coda dell’assistente ricette affinché la ricetta venga aggiunta. Idealmente, il sistema può essere precompilato con ricette prima del lancio, ma la libreria di ricette può crescere attivamente nel tempo in base alla telemetria dell’utente. Tieni presente che il flusso dell’utente finale non genera codice o query al volo e pertanto può utilizzare LLM meno potenti, è più stabile e sicuro e comporta costi inferiori.
Aggiornamento dati asincrono
Per migliorare i tempi di risposta per gli utenti finali, le ricette vengono aggiornate in modo asincrono, ove possibile. La memoria delle ricette contiene codice che può essere eseguito secondo una pianificazione prestabilita. Le ricette possono essere eseguite preventivamente per prepopolare il sistema, ad esempio, recuperando la popolazione totale di tutti i paesi prima che gli utenti finali le richiedano. Inoltre, i casi che richiedono l’aggregazione di grandi volumi di dati estratti dalle API possono essere eseguiti fuori orario, mitigando, anche se in parte, la limitazione delle query aggregate che utilizzano i dati API.
Gerarchia della memoria: ricordare abilità e fatti
Quanto sopra implementa una gerarchia di memoria per salvare “fatti” che possono essere promossi a “abilità” più generali. La promozione del recupero della memoria nelle ricette viene ottenuta attraverso una combinazione di ricerca semantica e riclassificazione e trasformazione LLM, ad esempio richiedendo a un LLM di generare un intento generale e un codice, ad es.Ottieni la popolazione totale per qualsiasi paese‘ da un intento e un codice specifici, ad esempio ‘Qual è la popolazione totale del Mali?‘.
Inoltre, includendo automaticamente le ricette come funzioni disponibili per la generazione di codice LLM, il suo toolkit riutilizzabile cresce in modo tale che le nuove ricette siano efficienti e richiamino ricette precedenti anziché generare tutto il codice da zero.
Catturando le richieste di analisi dei dati da parte degli utenti e rendendole altamente visibili nel sistema, la trasparenza aumenta. Il codice generato da LLM può essere attentamente esaminato, ottimizzato e adattato e le risposte prodotte da tale codice sono ben comprese e riproducibili. Ciò agisce per ridurre l’incertezza che molte applicazioni LLM devono affrontare riguardo al fondamento fattuale e all’allucinazione.
Un altro aspetto interessante di questa architettura è che cattura i requisiti specifici di analisi dei dati e la frequenza con cui questi vengono richiesti dagli utenti. Questo può essere utilizzato per investire in ricette maggiormente utilizzate che apportano vantaggi agli utenti finali. Ad esempio, se si accede frequentemente a una ricetta per generare un rapporto sulla situazione della risposta umanitaria, il codice della ricetta per quel rapporto può essere migliorato in modo proattivo.
Questo approccio apre la possibilità di una libreria di ricette di dati gestita dalla comunità che abbraccia più domini: un hub di ricette di dati. Simile ai siti Web di snippet di codice già esistenti, aggiungerebbe la dimensione dei dati e aiuterebbe gli utenti nella creazione fornendo una programmazione conversazionale assistita da LLM. Le ricette potrebbero ricevere punti reputazione e altri feedback simili sulla piattaforma social.
Come con qualsiasi architettura, potrebbe non funzionare bene in tutte le situazioni. Gran parte delle ricette di dati sono orientate alla riduzione dei costi e dei rischi associati alla creazione di codice al volo e alla creazione di una libreria riutilizzabile con maggiore trasparenza e intervento umano nel ciclo. Naturalmente può succedere che un utente possa richiedere qualcosa di nuovo che non sia già supportato nella libreria delle ricette. Possiamo creare una coda per l’elaborazione di queste richieste e, fornendo la programmazione assistita da LLM, ci aspettiamo che i tempi di sviluppo siano ridotti, ma ci sarà un ritardo per l’utente finale. Tuttavia, questo è un compromesso accettabile in molte situazioni in cui non è auspicabile rilasciare codice non moderato generato da LLM.
Un’altra cosa da considerare è l’aggiornamento asincrono delle ricette. A seconda della quantità di dati richiesti, ciò potrebbe risultare costoso. Inoltre, questo aggiornamento potrebbe non funzionare correttamente nei casi in cui i dati di origine cambiano rapidamente e gli utenti richiedono queste informazioni molto rapidamente. In questi casi, la ricetta verrebbe eseguita ogni volta anziché il risultato recuperato dalla memoria.
Il meccanismo di aggiornamento dovrebbe aiutare con le attività di aggregazione dei dati in cui i dati provengono dalle API, ma resta comunque il fatto che i dati grezzi sottostanti verranno inseriti come parte della ricetta. Questo ovviamente non funzionerà bene per enormi volumi di dati, ma almeno limita l’acquisizione in base alla domanda degli utenti anziché tentare di acquisire un intero set di dati remoto.
Infine, come tutte le applicazioni “Chat with Data”, la loro qualità sarà pari a quella dei dati a cui hanno accesso. Se i dati desiderati non esistono o sono di bassa qualità, le prestazioni percepite saranno scarse. Inoltre, nei set di dati esistono ingiustizie e pregiudizi comuni, quindi è importante eseguire un controllo dei dati prima di presentare approfondimenti all’utente. Ovviamente questo non è specifico delle Data Recipes, ma una delle maggiori sfide poste nel rendere operative tali tecniche. Immondizia dentro, spazzatura fuori!
L’architettura proposta mira ad affrontare alcune delle sfide affrontate con LLM “Chat With Data”, essendo…
- Trasparente — Le ricette sono altamente visibili e riviste da un essere umano prima di essere promosse, mitigando i problemi relativi alle allucinazioni e al riepilogo LLM
- Deterministico — Essendo codice, produrranno ogni volta gli stessi risultati, a differenza del riepilogo dei dati LLM
- Esecutore — Implementare una memoria che catturi non solo fatti ma competenze, che possono essere aggiornate in modo asincrono, migliora i tempi di risposta
- Poco costoso— Strutturando il flusso di lavoro in due flussi, il flusso di utenti finali ad alto volume può utilizzare LLM a costi inferiori
- Sicuro — Il gruppo principale di utenti finali non attiva la generazione e l’esecuzione di codice o query al volo e qualsiasi codice è sottoposto a valutazione umana per quanto riguarda sicurezza e accuratezza
Pubblicherò una serie di post successivi sul blog che descrivono in dettaglio l’implementazione tecnica delle ricette dati mentre elaboriamo i test utente su DataKind.
Grandi modelli linguistici come creatori di strumenti, Cai et al., 2023.
Se non diversamente specificato, tutte le immagini sono dell’autore.
Metti mi piace a questo articolo se sei interessato e sarei felice se mi seguissi! Puoi trovare più articoli Qui.
Fonte: towardsdatascience.com
