Come Hamlet utilizza Databricks Lakebase Postgres per testare le modifiche sui dati di produzione

Hamlet, una piattaforma basata sull'AI che rende accessibile e ricercabile il processo decisionale degli enti locali, utilizza Databricks Lakebase Postgres per assegnare a ogni pull request un proprio ramo di dati di produzione. Gli ingegneri e gli agenti di codifica AI testano le modifiche sui dati reali senza toccare la produzione, mentre una persona approva comunque ogni merge.

Ho parlato con il CEO Sunil Rajaraman, il Lead Developer Erich Douglass e il Senior AI Engineer Jeff Hui di come lavorano.

Cos'è Hamlet?

Hamlet è una piattaforma tecnologica basata sull'AI che rende accessibili e ricercabili le decisioni degli enti locali. Indicizzando e trascrivendo migliaia di riunioni di consigli comunali, commissioni edilizie e comitati urbanistici negli Stati Uniti, Hamlet consente a sviluppatori immobiliari, giornalisti, ricercatori e cittadini di cercare istantaneamente le trascrizioni dei meeting, monitorare gli sviluppi delle politiche locali e impostare avvisi in tempo reale per argomenti, indirizzi o attività commerciali specifici.

Perché i dati degli enti locali sono così difficili da standardizzare?

Sara Steffen: Hamlet indicizza le riunioni di oltre 7.200 organi di governo in ogni stato. Che aspetto ha questo panorama di dati e perché è così difficile comprenderlo?

Sunil Rajaraman: Negli Stati Uniti ci sono 19.000 amministrazioni comunali, 3.000 amministrazioni provinciali e circa 80.000 distretti speciali. Prendi due siti web qualsiasi e vedrai che non si assomigliano affatto. È il peccato originale degli enti locali. Un pugno di provider CMS ha deciso che ogni sito dovesse essere diverso, e il risultato è un'internet governativa completamente balcanizzata. Hamlet raccoglie tutto questo e lo standardizza.

In che modo una piattaforma di civic intelligence si differenzia da uno strumento di trascrizione?

Sara: Hamlet si definisce una piattaforma di civic intelligence. In cosa si differenzia da uno strumento di trascrizione e perché questa distinzione è importante?

Sunil: Molte aziende del settore govtech fanno un arbitraggio di dati municipali. Scrivono scraper fragili per siti web risalenti al 1998 e ci applicano sopra una mano di vernice moderna. Fare lo scraping e archiviare i dati non aggiunge molto di per sé. Devi raccontare una storia, ed essa deve basarsi sui fatti. Ciò significa sapere chi sta parlando e cosa pensa di un determinato problema. Se sei uno sviluppatore immobiliare, vuoi sapere se un membro del consiglio approverà il tuo progetto edilizio, perché lo farà o meno, e quali precedenti ha la città che potrebbero farla esitare.

Prendiamo i permessi edilizi. Molti fondi di venture capital sono stati investiti nei dati sui permessi, eppure i tempi di rilascio sono peggiorati nell'ultimo decennio. Molte aziende hanno costruito monumenti ai sintomi. Noi vogliamo arrivare al problema di fondo, cioè comprendere le persone. La domanda a cui cerchiamo di rispondere è come funzionano fondamentalmente le città.

Cosa rende così difficile lavorare con dati pubblici disordinati?

Sara Steffen: Cosa rende i dati degli enti locali così difficili da gestire?

Sunil Rajaraman: Prendi due siti web qualsiasi e non si assomiglieranno. Hamlet raccoglie tutto e lo standardizza.

Erich Douglass: Non puoi semplicemente integrarti con un solo provider. Sette o otto di essi coprono circa il 75% del mercato. Oltre c'è una lunghissima coda di configurazioni personalizzate. A volte un funzionario carica un PDF dell'ordine del giorno. A volte scansiona una copia cartacea e carica quella. Ne escono fuori artefatti davvero strani.

Di cosa hanno bisogno i clienti dai dati delle riunioni?

Sara: Di cosa hanno bisogno i clienti da questi dati?

Sunil: I nostri clienti sono aziende private come sviluppatori immobiliari, sviluppatori di data center e rivenditori al dettaglio. Quasi tutti cercano di far approvare un progetto più velocemente o di trovare una nuova opportunità. Senza Hamlet, qualcuno deve sorbirsi ore di riunioni, aspettare che si parli del proprio progetto e osservare il linguaggio del corpo dei funzionari. Noi identifichiamo chi ha parlato, ti portiamo al timestamp esatto e ti mostriamo le prove.

Erich: Vogliono anche dei precedenti. Un progetto come il loro è già stato approvato o respinto in passato? Perché? Quali modifiche ha richiesto il consiglio? Se riusciamo a mostrare cosa sta succedendo davvero, questo ha un enorme valore.

In che modo Hamlet mantiene le risposte dell'AI collegate alla fonte?

Sara: In che modo aiutate i clienti a fidarsi degli insight che trovano?

Jeff Hui: La usiamo in quasi ogni fase del processo. All'inizio, Hamlet svolgeva questo lavoro manualmente, ma questo non si adatta alla scala di migliaia di luoghi. Per molti di questi enti, il video è la principale fonte di verità. Trasformarlo in una forma strutturata che possiamo utilizzare è la parte più importante. La durata media di una riunione è di circa tre ore e mezza. Nessuno vuole guardarla tutta. L'AI indirizza le persone verso le parti che valgono il loro tempo, e il video è sempre lì a fare da supporto. Possiamo mostrare esattamente cosa è stato detto, cosa con cui molti sistemi di AI hanno difficoltà.

Il contesto fa la differenza

Sara: Come identificate con precisione gli oratori in migliaia di riunioni?

Jeff: Il contesto fa la differenza principale. Per l'identificazione degli oratori, sappiamo quale consiglio o commissione si sta riunendo e chi ne faceva parte in quel momento. Questo aiuta con i nomi, che sono difficili da azzeccare persino per una persona che ascolta una registrazione. Non puoi semplicemente dare un video in pasto a un modello e sperare in bene. Devi raccogliere tutto ciò che c'è intorno per aiutarlo a prendere la decisione giusta. È una sfida continua.

Verifica delle interpretazioni dell'AI

Sara: Come verificate l'interpretazione fornita dall'AI di ciò che dicono i funzionari?

Sunil: Una trascrizione accurata viene al primo posto. Per la sentiment analysis, utilizziamo più modelli di AI per confermare che un commento riguardi un determinato argomento, ad esempio i data center. Poi esaminano il contesto circostante per stabilire se sia a favore o contrario.

Devi anche definire cosa significano "a favore" e "contro" prima di porre la domanda. Prendiamo l'ordine pubblico. Cosa significa esserne a favore? Dedichiamo molta attenzione a queste domande. Diversi modelli ora riesaminano ogni dato sul sentiment prima di pubblicarlo, e richiediamo un grado di confidenza elevato.

In che modo Hamlet utilizza Lakebase Postgres?

Lakebase è il database Postgres gestito utilizzato da Hamlet per assegnare a ciascuna pull request un proprio ramo di dati di produzione. Gli ingegneri possono testare le modifiche sui dati che hanno causato un bug senza toccare la produzione, mentre gli agenti di codifica AI eseguono le pipeline e controllano il proprio lavoro prima che una persona approvi il merge. Il team afferma che la precedente configurazione dei dati di test poteva richiedere diverse ore alla settimana per ciascun ingegnere.

In che modo Hamlet utilizza il data branching di Lakebase?

Sara: Perché avete scelto Lakebase e cosa è cambiato per il vostro team?

Erich: Avevamo una configurazione piuttosto standard su AWS RDS, con un'istanza di produzione e un'istanza di staging. Gran parte del nostro lavoro consiste nell'ottimizzare le pipeline di dati in base a dati molto specifici. Per ogni pull request, trascorrevamo da 15 a 30 minuti a portare lo staging nello stato corretto prima di poter eseguire le validazioni. Siamo un team ridotto e la velocità per noi conta più di quasi qualsiasi altra cosa.

Il data branching è stata la funzionalità che ci ha convinto. Ora ogni pull request ottiene il proprio ramo di dati di produzione, collegato al relativo ambiente di anteprima. Quando l'anteprima viene distribuita, è pronta. Possiamo eseguire test sui dati di produzione e persino scriverci sopra senza toccare la produzione vera e propria.

Anche l'autoscaling aiuta. Su RDS, un'istanza più grande significava una migrazione che poteva richiedere un paio d'ore. Ora spostiamo un cursore e otteniamo un'istanza grande il doppio.

Jeff: Quei 15-30 minuti erano il caso migliore, quando ti capitava di copiare esattamente i dati giusti. Ogni ingegnere poteva trascorrere diverse ore a settimana per mantenere aggiornati i dati di test, incluse la clonazione locale di parti della produzione per individuare i problemi. Ora, quando riscontriamo un bug, abbiamo esattamente i dati che lo hanno causato e possiamo verificare la correzione su quegli stessi dati.

In che modo gli agenti di codifica AI eseguono test sui rami di Lakebase?

Sara: In che modo Lakebase cambia il modo di lavorare dei vostri agenti di codifica AI?

Jeff: I rami rendono il nostro flusso di lavoro molto più adatto agli agenti di codifica AI. Ogni pull request è isolata dalla produzione. Diamo a un agente come Claude o Codex l'accesso al suo ramo e gli lasciamo eseguire i propri controlli. Esegue le pipeline di dati fino al completamento e verifica se la modifica fa quello che dovrebbe. Ogni pull request riceve quel primo passaggio da un agente. Quando una persona la esamina, siamo già abbastanza sicuri che funzioni. Un essere umano approva comunque il merge. Sempre più il resto è automatizzato, e Lakebase è una parte fondamentale di ciò che rende tutto questo possibile.

Quali sono i prossimi passi esplorati da Hamlet?

Sara: Quali aspetti volete esplorare prossimamente con Lakebase?

Erich: In questo momento la maggior parte dei nostri dati risiede in un database relazionale e la ricerca viene eseguita su un database vettoriale separato. I due finiscono per desincronizzarsi. Il test della ricerca diventa di nuovo il vecchio problema dello staging. Sto provando Lakebase Search, che combina la ricerca vettoriale e testuale in Postgres, e avere tutto in un unico posto è stato fantastico.

Sara: Oltre alla ricerca, cosa vorreste semplificare in seguito?

Erich: Il branching ha funzionato così bene che ci piacerebbe avere la stessa cosa per i file di grandi dimensioni che conserviamo nell'object storage. Ogni sviluppatore ha bucket di test affiancati a un unico bucket di produzione condiviso, e gestire lo stato tra di essi è difficile.

Jeff: Stiamo anche valutando dove eseguire job agentici più lunghi. Parte del nostro processo di ingestion utilizza l'AI per pilotare un browser web e trovare i contenuti giusti sui siti governativi. Alcune esecuzioni richiedono pochi minuti. Altre richiedono 30 o 40 minuti, e la nostra attuale configurazione di AWS Lambda ha un limite di 15 minuti.

In che modo Lakebase velocizza il percorso dalle evidenze agli insight?

Il lavoro di Hamlet inizia con la registrazione originale della riunione, in modo che i clienti possano risalire da un insight dell'AI a ciò che ha detto un funzionario. Lakebase supporta il flusso di lavoro ingegneristico alla base di questa esperienza: i branch dei dati di produzione consentono a sviluppatori e agenti di coding di testare le modifiche senza toccare la produzione, mentre le persone approvano comunque il merge finale. Per un piccolo team che lavora su migliaia di organi di governo, ciò significa meno tempo dedicato alla preparazione dei dati di test e più tempo dedicato al miglioramento del prodotto.

Domande frequenti

Come si può creare ed eliminare automaticamente un branch Lakebase per ogni pull request?

Aggiungi due passaggi alla tua pipeline di continuous integration (CI): crea un branch dalla produzione quando si apre una pull request (PR) ed eliminalo quando la PR viene unita tramite merge o chiusa. Puoi creare uno script per entrambi i passaggi con la Databricks CLI ed eseguirli da uno strumento come GitHub Actions. Imposta una scadenza, un time-to-live (TTL), quando crei il branch, in modo che si elimini automaticamente anche se il passaggio di pulizia non viene mai eseguito. Consulta il tutorial sul flusso di lavoro di sviluppo basato su branch per un esempio completo.

Come funziona il branching del database in Postgres?

Un branch Lakebase è un ambiente Postgres indipendente che inizia con lo schema e i dati del suo parent e condivide lo storage con esso tramite copy-on-write. Vengono scritte separatamente solo le modifiche apportate sul branch, quindi la creazione di un branch non dipende dalle dimensioni del database. Postgres standard crea un nuovo database copiandone uno esistente, duplicando così i dati. I branch di database di Lakebase evitano questa copia e le modifiche apportate a un branch child non influiscono mai sul relativo parent.

Come si implementa il branching del database per un team di sviluppo?

Inizia con un branch per pull request, il pattern utilizzato da Hamlet, quindi estendi il branching al resto del tuo flusso di lavoro. Ogni pattern sostituisce un database di staging condiviso con ambienti isolati.

• Un branch per pull request: la CI crea il branch all'apertura della PR e lo elimina alla sua chiusura.
• Un branch per sviluppatore: ogni ingegnere ottiene un ambiente isolato con dati simili a quelli di produzione ed è possibile ripristinarlo dal parent per recuperare lo schema e i dati più recenti.
• Un branch per esecuzione di test: ogni esecuzione della CI parte da un database pulito e isolato, senza stati residui.

Quanto costa un branch Lakebase?

Il costo dipende dal calcolo e dallo storage. Ogni branch dispone di risorse di calcolo proprie, che scalano a zero quando non sono attive, per cui si pagano solo le ore di calcolo attive. Per quanto riguarda lo storage, un branch con scadenza viene fatturato solo per i dati modificati al suo interno, mentre un branch permanente senza scadenza viene fatturato per la dimensione totale dei dati. Mantieni una scadenza sui branch a breve durata. Consulta le opzioni relative alla scadenza del branch.

Gli agenti di coding basati su AI possono eseguire test su un branch Lakebase senza toccare la produzione?

Sì. Ogni branch è isolato dalla produzione, consentendo all'agente di applicare migrazioni, eseguire test e dismettere il branch al termine delle operazioni. Una persona approva comunque il merge, e le modifiche allo schema passano al branch parent tramite migrazioni nel codice anziché unendo il branch.

Per saperne di più su Lakebase, visita la pagina del prodotto Lakebase Postgres.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale