Ein Gespräch mit Sunil Rajaraman, CEO von Hamlet, und den Entwicklern Erich Douglass und Jeff Hui
von Sara Steffen
Hamlet, eine AI-gestützte Plattform, die Entscheidungsfindungen lokaler Regierungen zugänglich und durchsuchbar macht, nutzt Databricks Lakebase Postgres, um jedem Pull Request einen eigenen Branch mit Produktionsdaten zuzuweisen. Ingenieure und AI-Coding-Agenten testen Änderungen an realen Daten, ohne die Produktion zu berühren, und eine Person genehmigt weiterhin jeden Merge.
Ich habe mit CEO Sunil Rajaraman, Lead Developer Erich Douglass und Senior AI Engineer Jeff Hui darüber gesprochen, wie sie arbeiten.
Hamlet ist eine AI-gestützte Technologieplattform, die Entscheidungsfindungen lokaler Regierungen zugänglich und durchsuchbar macht. Durch die Indizierung und Transkription tausender Sitzungen von Stadträten, Planungskommissionen und Baubehörden in den gesamten USA ermöglicht Hamlet es Immobilienentwicklern, Journalisten, Forschern und Bürgern, Sitzungsprotokolle sofort zu durchsuchen, lokale Politikentwicklungen zu verfolgen und Echtzeit-Benachrichtigungen für bestimmte Themen, Adressen oder Unternehmen einzurichten.
Sara Steffen: Hamlet indiziert Sitzungen von mehr als 7.200 Verwaltungsorganen in jedem Bundesstaat. Wie sieht diese Datenlandschaft aus und warum ist es so schwer, sie zu verstehen?
Sunil Rajaraman: Es gibt 19.000 Stadtverwaltungen, 3.000 Kreisverwaltungen und rund 80.000 Sonderbezirke in den Vereinigten Staaten. Wählen Sie zwei beliebige ihrer Websites aus, und sie werden nicht gleich aussehen. Das ist die Erbsünde der lokalen Verwaltung. Eine Handvoll CMS-Anbieter hat entschieden, dass jede Website anders sein sollte, und das Ergebnis ist ein Regierungs-Internet, das völlig zersplittert ist. Hamlet führt all das zusammen und standardisiert es.
Sara: Hamlet beschreibt sich selbst als eine Civic-Intelligence-Plattform. Wie unterscheidet sich das von einem Transkriptions-Tool und warum ist dieser Unterschied wichtig?
Sunil: Viele GovTech-Unternehmen betreiben Arbitrage mit kommunalen Daten. Sie schreiben fehleranfällige Scraper für Websites aus dem Jahr 1998 und verpassen ihnen einen modernen Anstrich. Das Scrapen und Speichern der Daten bringt allein nicht viel. Man muss eine Geschichte erzählen, und die muss auf Fakten basieren. Das bedeutet zu wissen, wer spricht und wie die Person zu einem Thema steht. Wenn Sie Entwickler sind, möchten Sie wissen, ob ein Ratsmitglied Ihr Wohnbauprojekt genehmigen wird, warum oder warum nicht, und welche Vorgeschichte die Stadt hat, die sie zögern lassen könnte.
Nehmen wir das Genehmigungswesen. Viel Wagniskapital ist in Baugenehmigungsdaten geflossen, und dennoch haben sich die Zeiträume für Genehmigungen im letzten Jahrzehnt verschlechtert. Viele Unternehmen haben Denkmäler für die Symptome gebaut. Wir wollen das zugrundeliegende Problem angehen, nämlich die Menschen zu verstehen. Die Frage, die wir zu beantworten versuchen, ist, wie Städte im Grunde funktionieren.
Sara Steffen: Was macht die Arbeit mit Daten lokaler Regierungen so schwierig?
Sunil Rajaraman: Wählen Sie zwei beliebige ihrer Websites aus, und sie werden nicht gleich aussehen. Hamlet führt alles zusammen und standardisiert es.
Erich Douglass: Man kann nicht einfach nur einen Anbieter integrieren. Sieben oder acht von ihnen decken etwa 75 % des Marktes ab. Danach kommt ein riesiger Long Tail von individuellen Setups. Manchmal lädt ein Sachbearbeiter ein PDF der Tagesordnung hoch. Manchmal scannen sie eine Papierkopie und laden diese hoch. Da bekommt man wirklich merkwürdige Artefakte.
Sara: Was benötigen Kunden aus diesen Daten?
Sunil: Unsere Kunden sind private Unternehmen wie Immobilienentwickler, Rechenzentren-Entwickler und Einzelhändler. Fast alle versuchen, ein Projekt schneller genehmigen zu lassen oder eine neue Gelegenheit zu finden. Ohne Hamlet sitzt jemand stundenlang in Sitzungen, wartet darauf, dass sein Projekt aufgerufen wird, und beobachtet die Körpersprache der Amtsträger. Wir identifizieren, wer gesprochen hat, bringen Sie direkt zum Zeitstempel und liefern Ihnen die Belege.
Erich: Sie wollen auch Präzedenzfälle. Wurde ein ähnliches Projekt wie ihres schon einmal genehmigt oder abgelehnt? Warum? Welche Änderungen hat der Rat gefordert? Wenn wir zeigen können, was wirklich vor sich geht, ist das von enormem Wert.
Sara: Wie helfen Sie Kunden dabei, den gefundenen Erkenntnissen zu vertrauen?
Jeff Hui: Wir nutzen es in fast jedem Teil des Prozesses. Zu Beginn hat Hamlet diese Arbeit manuell erledigt, was sich nicht auf tausende Orte skalieren lässt. Für viele dieser Verwaltungen ist das Video die primäre Quelle der Wahrheit. Es in eine strukturierte Form zu bringen, die wir nutzen können, ist der wichtigste Teil. Die durchschnittliche Sitzung dauert etwa dreieinhalb Stunden. Niemand möchte sich das komplett ansehen. Die AI weist die Leute auf die Abschnitte hin, die ihre Zeit wert sind, und das Video steht immer als Beleg zur Verfügung. Wir können genau zeigen, was gesagt wurde, womit viele AI-Systeme Probleme haben.
Sara: Wie identifizieren Sie Sprecher über tausende Sitzungen hinweg präzise?
Jeff: Der Kontext macht den größten Unterschied. Für die Sprechererkennung wissen wir, welcher Rat oder Ausschuss tagt und wer zu diesem Zeitpunkt Mitglied war. Das hilft bei Namen, die selbst für eine Person, die sich eine Aufnahme anhört, schwer korrekt zu erfassen sind. Man kann einem Modell nicht einfach ein Video übergeben und das Beste hoffen. Man muss alles drumherum sammeln, was dabei hilft, die richtige Entscheidung zu treffen. Das ist eine dauerhafte Herausforderung.
Sara: Wie überprüfen Sie die Interpretation der AI dessen, was Amtsträger sagen?
Sunil: Eine genaue Transkription steht an erster Stelle. Für die Stimmungsanalyse verwenden wir mehrere AI-Modelle, um zu bestätigen, dass sich ein Kommentar auf ein bestimmtes Thema bezieht, beispielsweise Rechenzentren. Anschließend betrachten sie den umgebenden Kontext, um zu entscheiden, ob er dafür oder dagegen ist.
Man muss auch definieren, was „dafür“ und „dagegen“ bedeuten, bevor man fragt. Nehmen wir das Polizeiwesen. Was bedeutet es, dafür zu sein? Wir widmen diesen Fragen sehr viel Sorgfalt. Mehrere Modelle überprüfen nun jeden Stimmungswert, bevor wir ihn veröffentlichen, und wir setzen eine hohe Konfidenz voraus.
Lakebase ist die verwaltete Postgres-Datenbank, die Hamlet nutzt, um jedem Pull Request einen eigenen Branch mit Produktionsdaten zuzuweisen. Ingenieure können Änderungen an den Daten testen, die einen Fehler verursacht haben, ohne die Produktion zu berühren, während AI-Coding-Agenten die Pipelines ausführen und ihre Arbeit überprüfen, bevor eine Person den Merge genehmigt. Laut dem Team konnte das vorherige Testdaten-Setup wöchentlich mehrere Stunden pro Ingenieur in Anspruch nehmen.
Sara: Warum haben Sie sich für Lakebase entschieden und was hat sich für Ihr Team verändert?
Erich: Wir hatten ein recht Standard-Setup auf AWS RDS mit einer Produktionsinstanz und einer Staging-Instanz. Ein Großteil unserer Arbeit besteht darin, Daten-Pipelines auf sehr spezifische Daten abzustimmen. Für jeden Pull Request haben wir 15 bis 30 Minuten damit verbracht, Staging in den richtigen Zustand zu bringen, bevor wir Validierungen ausführen konnten. Wir sind ein kleines Team, und Geschwindigkeit ist uns wichtiger als fast alles andere.
Data Branching war das Feature, das uns überzeugt hat. Jeder Pull Request erhält nun seinen eigenen Branch von Produktionsdaten, der mit seiner Vorschauumgebung verbunden ist. Wenn die Vorschau bereitgestellt wird, ist sie einsatzbereit. Wir können mit Produktionsdaten testen und sogar darauf schreiben, ohne die Produktion zu berühren.
Autoscaling hilft ebenfalls. Bei RDS bedeutete eine größere Instanz eine Migration, die einige Stunden dauern konnte. Jetzt bewegen wir einen Schieberegler und erhalten eine doppelt so große Instanz.
Jeff: Die 15 bis 30 Minuten waren der Bestfall, wenn man zufällig genau die richtigen Daten kopiert hatte. Jeder Ingenieur konnte mehrere Stunden pro Woche damit verbringen, Testdaten aktuell zu halten, einschließlich des lokalen Klonens von Teilen der Produktion, um Fehlern nachzugehen. Wenn wir jetzt auf einen Fehler stoßen, haben wir genau die Daten, die ihn verursacht haben, und können die Korrektur mit genau diesen Daten überprüfen.
Sara: Wie verändert Lakebase die Arbeitsweise Ihrer AI-Coding-Agenten?
Jeff: Branches sorgen dafür, dass unser Workflow viel besser zu AI-Coding-Agenten passt. Jeder Pull Request ist von der Produktion isoliert. Wir geben einem Agenten wie Claude oder Codex Zugriff auf seinen Branch und lassen ihn seine eigenen Prüfungen durchführen. Er führt die Daten-Pipelines vollständig aus und prüft, ob die Änderung das tut, was sie soll. Jeder Pull Request erhält diesen ersten Durchgang von einem Agenten. Wenn sich eine Person den Request ansieht, sind wir bereits ziemlich zuversichtlich, dass er funktioniert. Ein Mensch genehmigt weiterhin den Merge. Immer mehr vom Rest ist automatisiert, und Lakebase ist ein großer Teil dessen, was dies möglich macht.
Sara: Was erforschen Sie als Nächstes mit Lakebase?
Erich: Derzeit befindet sich der Großteil unserer Daten in einer relationalen Datenbank, und die Suche läuft auf einer separaten Vektordatenbank. Die beiden laufen asynchron. Das Testen der Suche wird wieder zum alten Staging-Problem. Ich habe Lakebase Search ausprobiert, das Vektor- und Textsuche in Postgres kombiniert, und alles an einem Ort zu haben, war großartig.
Sara: Was möchten Sie abgesehen von der Suche als Nächstes vereinfachen?
Erich: Das Branching hat so gut funktioniert, dass wir dasselbe gerne für die großen Dateien hätten, die wir im Object Storage aufbewahren. Jeder Entwickler hat Test-Buckets neben einem gemeinsamen Produktions-Bucket, und die Verwaltung des Zustands über diese hinweg ist schwierig.
Jeff: Wir prüfen auch, wo wir längere agentische Aufgaben ausführen können. Ein Teil unseres Ingestion-Prozesses nutzt AI, um einen Webbrowser zu steuern und die richtigen Inhalte auf Regierungsseiten zu finden. Einige Durchläufe dauern einige Minuten. Andere dauern 30 oder 40, und unser aktuelles AWS Lambda-Setup hat ein Limit von 15 Minuten.
Die Arbeit von Hamlet beginnt mit der ursprünglichen Aufzeichnung der Besprechung, sodass Kunden eine AI-Erkenntnis bis zu den Aussagen eines Amtsträgers zurückverfolgen können. Lakebase unterstützt den Engineering-Workflow hinter diesem Prozess: Branches von Produktionsdaten ermöglichen es Entwicklern und Coding-Agenten, Änderungen zu testen, ohne die Produktion zu beeinträchtigen, während die finale Zusammenführung weiterhin von Menschen genehmigt wird. Für ein kleines Team, das für Tausende von Verwaltungsgremien arbeitet, bedeutet dies weniger Zeit für die Vorbereitung von Testdaten und mehr Zeit für die Verbesserung des Produkts.
Wie können Sie für jeden Pull Request automatisch einen Lakebase-Branch erstellen und löschen?
Fügen Sie Ihrer Continuous Integration (CI)-Pipeline zwei Schritte hinzu: Erstellen Sie einen Branch von der Produktion, wenn ein Pull Request (PR) geöffnet wird, und löschen Sie ihn, wenn der PR zusammengeführt oder geschlossen wird. Sie können beide Schritte mit der Databricks CLI skripten und über ein Tool wie GitHub Actions ausführen. Legen Sie beim Erstellen des Branchs eine Ablaufzeit (Time-to-Live, TTL) fest, damit er sich von selbst löscht, selbst wenn der Bereinigungsschritt nicht ausgeführt wird. Siehe das Tutorial zum branch-basierten Entwicklungs-Workflow für ein vollständiges Beispiel.
Wie funktioniert Database Branching in Postgres?
Ein Lakebase-Branch ist eine unabhängige Postgres-Umgebung, die mit dem Schema und den Daten ihrer übergeordneten Umgebung beginnt und den Speicherplatz mit dieser über Copy-on-Write teilt. Nur Änderungen, die im Branch vorgenommen werden, werden separat geschrieben, sodass die Erstellung eines Branchs nicht von der Datenbankgröße abhängt. Standard-Postgres erstellt eine neue Datenbank durch Kopieren einer vorhandenen Datenbank, wodurch die Daten dupliziert werden. Die Datenbank-Branches von Lakebase vermeiden diese Kopie, und Änderungen in einem untergeordneten Branch wirken sich niemals auf die übergeordnete Umgebung aus.
Wie führen Sie Database Branching in einem Entwicklungsteam ein?
Beginnen Sie mit einem Branch pro Pull Request – dem Muster, das Hamlet verwendet – und weiten Sie das Branching dann auf den Rest Ihres Workflows aus. Jedes Muster ersetzt eine gemeinsame Staging-Datenbank durch isolierte Umgebungen.
Wie viel kostet ein Lakebase-Branch?
Die Kosten hängen von Compute und Speicher ab. Jeder Branch verfügt über eine eigene Compute-Ressource, die bei Inaktivität auf Null skaliert, sodass Sie nur für aktive Compute-Stunden zahlen. Beim Speicher wird ein ablaufender Branch nur für die Daten abgerechnet, die sich darauf ändern, während ein dauerhafter Branch ohne Ablaufdatum für die gesamte Datengröße abgerechnet wird. Behalten Sie ein Ablaufdatum für kurzlebige Branches bei. Siehe Branch-Ablaufdatum für die Optionen.
Können KI-Coding-Agenten auf einem Lakebase-Branch testen, ohne die Produktion zu beeinträchtigen?
Ja. Jeder Branch ist von der Produktion isoliert, sodass ein Agent Migrationen anwenden, Tests ausführen und den Branch nach Abschluss stilllegen kann. Eine Person genehmigt weiterhin die Zusammenführung, und Schemaänderungen werden durch Migrationen im Code und nicht durch das Zusammenführen des Branchs in den übergeordneten Branch übertragen.
Um mehr über Lakebase zu erfahren, besuchen Sie die Produktseite zu Lakebase Postgres.
(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag
Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.