Pipeline dati in tempo reale: costruire uno scoring AI integrato nel CRM aziendale

Perché lo scoring in batch non basta più

La maggior parte delle implementazioni AI nei CRM aziendali funziona ancora con un ciclo batch notturno: il modello gira alle 2 di notte, aggiorna i punteggi di lead e opportunità, e il commerciale li trova la mattina già vecchi di ore. Nel frattempo il cliente ha visitato la pagina prezzi tre volte, ha aperto due email e ha avviato una chat. Tutte segnali che un sistema batch non ha ancora visto.

Lo scoring in tempo reale cambia il contratto tra il dato e la decisione: il punteggio deve essere disponibile nel momento in cui il commerciale apre il record, non quando il sistema ha tempo di calcolarlo.

Anatomia della pipeline streaming

Una pipeline di inferenza in tempo reale per il CRM si compone di tre strati principali, che devono essere progettati insieme e non come moduli indipendenti.

1. Ingestion e trasporto degli eventi

Il primo strato raccoglie eventi eterogenei: interazioni web, aperture email, log di chiamate, aggiornamenti del CRM stesso, dati firmografici da fonti esterne. Il protocollo più diffuso è Apache Kafka (o il suo equivalente managed come Confluent Cloud o Amazon MSK), che garantisce ordinamento per partizione, replay degli eventi e disaccoppiamento tra produttori e consumatori.

Ogni evento deve portare con sé un entity key — tipicamente l'ID del lead o dell'account — e un timestamp preciso. Senza questi due campi, qualsiasi join temporale a valle diventa inaffidabile.

{
  "event_type": "page_view",
  "entity_id": "lead_8821",
  "timestamp": "2025-01-15T14:32:07Z",
  "properties": {
    "page": "/pricing",
    "session_id": "sess_9k2x",
    "time_on_page_sec": 142
  }
}

2. Feature store: il cuore del sistema

Il feature store è il componente più sottovalutato nelle architetture AI commerciali, eppure è quello che determina se il modello vedrà dati coerenti in training e in produzione. La sua funzione è duplice:

• Feature offline: calcolate su dati storici, usate per addestrare i modelli. Tipicamente risiedono in un data warehouse (BigQuery, Snowflake, Redshift).

• Feature online: versione a bassa latenza delle stesse feature, servite da un key-value store come Redis o DynamoDB per la lettura in millisecondi.

La consistenza tra i due ambienti — il cosiddetto training-serving skew — è la principale causa di degrado silenziosa dei modelli in produzione. Se in training la feature email_open_rate_30d è calcolata su una finestra esatta di 30 giorni e in serving viene aggiornata ogni 6 ore con una finestra approssimata, il modello sta operando su una distribuzione diversa da quella su cui è stato ottimizzato.

Strumenti come Feast, Tecton o Hopsworks nascono esattamente per risolvere questo problema: definire la feature una volta sola e materializzarla in modo consistente sia offline che online.

3. Serving del modello e integrazione CRM

Il modello addestrato viene esposto come microservizio REST o gRPC. Al momento della richiesta — tipicamente scatenata dall'apertura di un record nel CRM o da un trigger di pipeline — il serving layer esegue questi passi in sequenza:

1. Riceve l'entity_id dal CRM via webhook o API call.

2. Interroga il feature store online per recuperare il vettore di feature aggiornato.

3. Chiama il modello (che può girare su TorchServe, Triton Inference Server, o un endpoint SageMaker/Vertex AI).

4. Restituisce il punteggio (es. probabilità di conversione 0–100) al CRM, che lo scrive sul record.

La latenza end-to-end target per un'esperienza utente accettabile è sotto i 300ms. Oltre quella soglia, i commerciali percepiscono il ritardo e smettono di fidarsi del sistema.

Gestire le finestre temporali in streaming

Molte delle feature più predittive per lo scoring commerciale sono aggregate su finestre temporali: visite nell'ultima settimana, email aperte negli ultimi 30 giorni, valore degli ordini nei 90 giorni precedenti. Calcolare queste aggregazioni in streaming è più complesso che in batch perché gli eventi possono arrivare fuori ordine.

Framework come Apache Flink o Spark Structured Streaming gestiscono questo tramite il concetto di watermark: una soglia oltre la quale gli eventi in ritardo vengono scartati o gestiti separatamente. La scelta del watermark è un trade-off tra completezza del dato e latenza della feature.

Un watermark di 10 minuti significa che il sistema aspetta fino a 10 minuti prima di chiudere una finestra temporale. Abbassarlo riduce la latenza ma aumenta il rischio di perdere eventi in ritardo provenienti da sistemi lenti.

Il modello: cosa funziona in contesti CRM

Per lo scoring di lead e opportunità, i modelli gradient boosting — XGBoost, LightGBM — rimangono la scelta più solida per la maggior parte dei casi: sono veloci in inferenza (microsecondi), interpretabili tramite SHAP values, e non richiedono normalizzazione delle feature. Le reti neurali diventano competitive solo quando i dati superano i milioni di esempi e si lavora con feature testuali non strutturate (es. note di CRM, trascrizioni di chiamate).

Un aspetto spesso trascurato è l'output del modello. Un punteggio grezzo tra 0 e 1 non dice nulla a un commerciale. È necessario calibrare il modello (Platt scaling o isotonic regression) in modo che il punteggio rifletta una probabilità reale, e poi tradurlo in tier leggibili: Alta priorità, Media priorità, Bassa priorità, con soglie decise insieme al team sales e non dal data scientist in isolamento.

Monitoraggio: il lavoro che non finisce mai

Una pipeline in produzione senza monitoraggio è un debito tecnico che si accumula in silenzio. Le tre dimensioni da tenere sotto controllo sono:

• Data drift: la distribuzione delle feature in ingresso cambia rispetto al training set? Strumenti come Evidently AI o WhyLabs calcolano metriche di divergenza (PSI, KL divergence) in modo automatico.

• Latenza del pipeline: lag Kafka, tempo di fetch dal feature store, latenza di inferenza. Ogni componente va strumentato con metriche Prometheus e visualizzato in Grafana.

• Business outcome: il punteggio prevede davvero le conversioni? Va confrontato periodicamente con i dati di chiusura reali tramite metriche come AUC-ROC e precisione per tier.

Integrazione pratica con i CRM più diffusi

Salesforce, HubSpot e Microsoft Dynamics offrono tutti meccanismi per esporre campi custom e ricevere aggiornamenti via API. Il pattern più pulito prevede un sidecar service che ascolta gli eventi del CRM (via webhook o change data capture), scatena il pipeline di scoring, e riscrive il risultato sul record tramite API upsert.

In Salesforce, i punteggi possono essere esposti come campi formula visibili nelle list view e nelle opportunità; in HubSpot come property custom con storico. L'importante è che il commerciale non debba aprire un tool separato: il punteggio deve essere dove il lavoro già accade, non dove il dato è tecnicamente più comodo da scrivere.

Un'architettura di riferimento minima

Per un'azienda con volumi medi (decine di migliaia di lead, qualche centinaio di eventi al minuto), uno stack funzionale e sostenibile può essere:

• Kafka (o Redpanda per semplicità operativa) come backbone di eventi.

• Flink per le aggregazioni streaming, con sink su Redis per le feature online.

• BigQuery + dbt per le feature offline e il training set.

• LightGBM servito tramite FastAPI su Cloud Run (stateless, scala a zero).

• Evidently AI per il monitoraggio del drift, con alert su Slack.

Non è necessario partire con Kubernetes e un cluster Flink da dieci nodi. La complessità operativa va introdotta quando i volumi la giustificano, non come punto di partenza.