L’IA non dovrebbe sprecare tempo a reinventare ETL

L'IA non dovrebbe reinventare ETL

I recenti progressi nell’Intelligenza Artificiale sono molto entusiasmanti. Le persone la stanno utilizzando in tutti i tipi di modi innovativi, per migliorare l’esperienza del supporto clienti, scrivere e eseguire codice, creare nuova musica e persino accelerare la tecnologia di imaging medico.

Ma nel processo, è emerso un trend preoccupante: la comunità di Intelligenza Artificiale sembra reinventare il movimento dei dati (aka ELT). Che si chiamino connettori, estrattori, integrazioni, caricatori di documenti o altro, le persone stanno scrivendo lo stesso codice per estrarre dati dalle stesse API, formati di documenti e database e poi caricarli in DB vettoriali o indici per i loro LLM (Language Models).

Il problema è che costruire e mantenere robusti flussi di estrazione e caricamento da zero è un impegno enorme. E c’è così tanto lavoro precedente in questo settore che per quasi tutti gli ingegneri o le aziende nello spazio dell’IA, è uno spreco di tempo ricostruirlo. In uno spazio in cui le notizie di ultima ora emergono circa ogni ora, il focus principale dovrebbe essere rendere il tuo prodotto principale incredibile per i tuoi utenti, non intraprendere missioni secondarie. E per quasi tutti, il prodotto principale non è il movimento dei dati; è la magia dell’IA che hai in mente.

Molto è stato scritto sulle sfide coinvolte nella costruzione di robusti flussi di estrazione, trasformazione e caricamento (ETL), ma mettiamolo in contesto all’interno dell’IA.

• 10 Cose Interessanti Che Puoi Fare Con gli Embeddings! [Parte 1]
• I ricercatori di ATLAS esplorano nuovi fenomeni con la rilevazione di anomalie tramite apprendimento automatico non supervisionato
• 10 Podcast di Data Science che ogni appassionato deve ascoltare

Perché l’IA ha bisogno del movimento dei dati?

LLM addestrati su dati pubblici sono fantastici, ma sai cosa è ancora meglio? IA che possono rispondere a domande specifiche per noi, le nostre aziende e i nostri utenti. Ci piacerebbe tutti se ChatGPT potesse imparare l’intera wiki della nostra azienda, leggere tutte le nostre email, messaggi Slack, appunti di riunioni e trascrizioni, collegarsi all’ambiente analitico della nostra azienda e utilizzare tutte queste fonti quando risponde alle nostre domande. Oppure, quando integriamo l’IA nel nostro prodotto (ad esempio, con Notion AI), vorremmo che il modello di intelligenza artificiale della nostra app conoscesse tutte le informazioni che abbiamo su un utente quando lo aiutiamo.

Il movimento dei dati è un prerequisito per tutto questo.

Sia che tu stia perfezionando un modello o utilizzando la Generazione potenziata dalla ricerca (RAG), devi estrarre dati da qualsiasi fonte, trasformarli in un formato comprensibile dal tuo modello e quindi caricarli in uno store di dati a cui la tua app di intelligenza artificiale può accedere per servire il tuo caso d’uso.

Il diagramma sopra illustra come appare tutto questo quando si utilizza RAG, ma puoi immaginare che anche se non stai usando RAG, i passaggi di base sono improbabili che cambino: devi estrarre, trasformare e caricare, alias ETL, i dati per costruire modelli di IA che conoscono informazioni non pubbliche specifiche per te e il tuo caso d’uso.

Perché il movimento dei dati è difficile?

Costruire un MVP funzionale di base per l’estrazione dei dati da un’API o un database è generalmente – anche se non sempre – fattibile in tempi brevi (<1 settimana). La parte davvero difficile è renderlo pronto per la produzione e mantenerlo tale. Analizziamo alcune delle sfide standard che vengono in mente durante la costruzione dei flussi di estrazione.

Estrazioni incremental e gestione dello stato

Se hai un volume di dati significativo, dovrai implementare l’estrazione incrementale in modo che il tuo flusso estragga solo i dati che non ha ancora visto. Per fare questo, avrai bisogno di uno strato di persistenza per tenere traccia dei dati estratti da ogni connessione.

Gestione degli errori transitori, tempi di attesa, ripresa in caso di fallimento, separazione dell’aria (air gapping)

Le fonti di dati upstream possono andare giù tutto il tempo, talvolta senza alcun motivo chiaro. I tuoi flussi devono essere resilienti a questo e riprovare con le politiche di attesa corrette. Se i fallimenti non sono così transienti (ma comunque non sono colpa tua), allora il tuo flusso deve essere abbastanza resiliente da ricordare da dove ha interrotto e riprendere dallo stesso punto una volta che l’upstream viene ripristinato. A volte, il problema proveniente dall’upstream è così grave (come un’API che elimina alcuni campi cruciali dai record) che vuoi mettere in pausa tutto il flusso fino a quando non esamini cosa sta succedendo e decidi manualmente cosa fare.

Identificazione e risoluzione proattiva degli errori di configurazione

Supponiamo che tu stia costruendo flussi di estrazione dati per estrarre i dati dei tuoi clienti. In tal caso, dovrai implementare alcuni controlli di sicurezza per assicurarti che tutte le configurazioni che i tuoi clienti ti hanno fornito per estrarre dati per loro siano corrette, e se non lo sono, fornire loro rapidamente messaggi di errore con azioni da intraprendere. La maggior parte delle API non lo rende facile perché non pubblicano tabelle di errori esaustive e anche quando lo fanno, raramente ti danno endpoint che puoi utilizzare per verificare le autorizzazioni assegnate, ad esempio, ai token API, quindi devi trovare modi per bilanciare controlli completi con feedback rapido per l’utente.

Autenticazione e gestione dei segreti

Le API possono variare in semplicità, dall’autenticazione con token di tipo “bearer” a implementazioni “creative” di token di sessione o OAuth a uso singolo. Sarà necessario implementare la logica per eseguire l’autenticazione e gestire i segreti, che potrebbero essere rigenerati ogni ora, coordinando eventualmente il rinnovo dei segreti tra più lavoratori concorrenti.

Ottimizzazione della velocità di estrazione e caricamento, concorrenza e limiti di tasso

E parlando di lavoratori concorrenti, probabilmente vorrai implementare la concorrenza per raggiungere un alto throughput per le tue estrazioni. Sebbene questo possa non essere importante per set di dati piccoli, è assolutamente cruciale per quelli più grandi. Anche se le API pubblicano limiti di tasso ufficiali, dovrai empiricamente scoprire i migliori parametri di parallelismo per sfruttare al massimo il limite di tasso fornito dall’API senza essere inserito in una blacklist IP o ricevere limitazioni di tasso permanenti.

Adattarsi ai cambiamenti delle API di origine

Le API cambiano e acquisiscono nuovi comportamenti o caratteristiche non documentate tutto il tempo. Molti fornitori pubblicano nuove versioni delle API trimestralmente. Sarà necessario monitorare come tutti questi aggiornamenti possono influire sul tuo lavoro e dedicare tempo di sviluppo per tenerlo tutto aggiornato. Nuovi endpoint vengono creati continuamente e alcuni cambiano il loro comportamento (e non sempre si riceve un avviso preventivo).

Pianificazione, monitoraggio, registrazione e osservabilità

Oltre al codice che estrae dati da API specifiche, probabilmente dovrai anche costruire alcune capacità orizzontali utilizzate da tutti i tuoi estrattori di dati. Sarai interessato a una programmazione, nonché a un sistema di registrazione e monitoraggio per quando la pianificazione non funziona o quando si verificano altri problemi e devi indagare. Probabilmente vorrai anche avere un sistema di osservabilità, ad esempio per sapere quanti record sono stati estratti ieri, oggi, la settimana scorsa, ecc., e da quali endpoint API o tabelle del database provengono.

Blocco o hash dei dati

A seconda di dove stai prelevando i dati, potresti aver bisogno di alcune funzionalità di privacy per bloccare o codificare le colonne prima di inviarle a valle.

Per essere chiari, quanto sopra non si applica se si desidera semplicemente spostare alcuni file una tantum.

Ma si applica quando si stanno costruendo prodotti che richiedono lo spostamento dei dati. Prima o poi, sarà necessario affrontare la maggior parte di queste problematiche. E sebbene nessuna di esse da sola sia impossibile da risolvere, prese insieme possono rapidamente richiedere uno o più lavori a tempo pieno, soprattutto se si prelevano dati da molte fonti diverse.

Ecco esattamente la difficoltà nel mantenere l’estrazione e le pipeline dei dati: la maggior parte dei costi derivano dall’investimento incrementale continuo necessario per mantenere queste pipeline funzionali e robuste. Per la maggior parte degli ingegneri AI, questo non è il lavoro che aggiunge più valore ai loro utenti. Il loro tempo è meglio impiegato altrove.

Quindi, cosa deve fare un ingegnere di AI per spostare dei dati qui?

Se ti trovi mai nella necessità di estrazioni e caricamenti di dati, prova le soluzioni già disponibili anziché costruire automaticamente la tua. Molto probabilmente possono risolvere molti, se non tutti, dei tuoi problemi. In caso contrario, costruisci la tua come ultima risorsa.

E anche se le piattaforme esistenti non supportano tutto ciò di cui hai bisogno, dovresti comunque essere in grado di arrivare molto lontano con un framework portatile ed estensibile. In questo modo, anziché costruire tutto da zero, puoi arrivare al 90% del percorso utilizzando funzionalità pronte all’uso nella piattaforma e costruire e mantenere solo il 10% finale. L’esempio più comune sono le integrazioni di nicchia: se la piattaforma non include un’integrazione con un’API di cui hai bisogno, una buona piattaforma renderà facile scrivere del codice o addirittura una soluzione senza codice per costruire tale integrazione e ottenere comunque tutte le utili funzionalità offerte dalla piattaforma. Anche se desideri la flessibilità di importare un connettore come pacchetto Python e attivarlo nel modo che preferisci dal tuo codice, puoi utilizzare uno dei tanti strumenti EL open-source come Airbyte o connettori Singer.

Per essere chiari, lo spostamento dei dati non è completamente risolto. Ci sono situazioni in cui le soluzioni esistenti sono realmente insufficienti e devi costruire soluzioni innovative. Tuttavia, questa non è la situazione della maggior parte degli ingegneri AI. La maggior parte delle persone non ha bisogno di ricostruire le stesse integrazioni con Jira, Confluence, Slack, Notion, Gmail, Salesforce, ecc., più e più volte. Utilizziamo invece le soluzioni che sono già state testate sul campo e rese disponibili per chiunque, in modo da poter continuare ad aggiungere il valore che i nostri utenti si aspettano.