Une conversation avec Sunil Rajaraman, PDG de Hamlet, et les ingénieurs Erich Douglass et Jeff Hui
par Sara Steffen
Hamlet, une plateforme alimentée par l'IA qui rend la prise de décision des gouvernements locaux accessible et recherchable, utilise Databricks Lakebase Postgres pour donner à chaque pull request sa propre branche de données de production. Les ingénieurs et les agents de codage IA testent les modifications par rapport à des données réelles sans toucher à la production, et une personne approuve toujours chaque fusion.
J'ai discuté avec le PDG Sunil Rajaraman, le développeur principal Erich Douglass et l'ingénieur IA senior Jeff Hui de leur façon de travailler.
Hamlet est une plateforme technologique alimentée par l'IA qui rend la prise de décision des gouvernements locaux accessible et recherchable. En indexant et en transcrivant des milliers de réunions de conseils municipaux, de commissions d'urbanisme et de conseils de zonage à travers les États-Unis, Hamlet permet aux promoteurs immobiliers, journalistes, chercheurs et citoyens de rechercher instantanément des transcriptions de réunions, de suivre l'évolution des politiques locales et de configurer des alertes en temps réel sur des sujets, adresses ou entreprises spécifiques.
Sara Steffen : Hamlet indexe des réunions de plus de 7 200 organismes dirigeants dans chaque État. À quoi ressemble ce paysage de données et pourquoi est-il si difficile à comprendre ?
Sunil Rajaraman : Il y a 19 000 municipalités, 3 000 comtés et environ 80 000 districts spéciaux aux États-Unis. Prenez deux de leurs sites web au hasard, et ils ne se ressembleront pas. C'est le péché originel des gouvernements locaux. Une poignée de fournisseurs de CMS a décidé que chaque site devait être différent, et le résultat est un Internet public complètement balkanisé. Hamlet rassemble tout cela et le standardise.
Sara : Hamlet se décrit comme une plateforme d'intelligence civique. En quoi est-ce différent d'un outil de transcription, et pourquoi cette distinction est-elle importante ?
Sunil : Beaucoup d'entreprises de la govtech font de l'arbitrage de données municipales. Elles écrivent des scripts de scraping fragiles pour des sites web datant de 1998 et y ajoutent une couche de peinture moderne. Scraper et stocker les données n'apporte pas grand-chose en soi. Il faut raconter une histoire, et elle doit reposer sur des faits. Cela implique de savoir qui parle et ce que la personne pense d'un sujet. Si vous êtes un promoteur, vous voulez savoir si un membre du conseil va approuver votre projet immobilier, pourquoi ou pourquoi pas, et quel est l'historique de la ville qui pourrait la faire hésiter.
Prenez les permis de construire. Beaucoup de capital-risque a été investi dans les données de permis, et les délais d'obtention se sont encore dégradés au cours de la dernière décennie. De nombreuses entreprises ont élevé des monuments aux symptômes. Nous voulons nous attaquer au problème sous-jacent, qui est de comprendre les gens. La question à laquelle nous essayons de répondre est : comment les villes fonctionnent-elles fondamentalement ?
Sara Steffen : Pourquoi les données des gouvernements locaux sont-elles si difficiles à exploiter ?
Sunil Rajaraman : Prenez deux de leurs sites web au hasard, et ils ne se ressembleront pas. Hamlet rassemble tout cela et le standardise.
Erich Douglass : Vous ne pouvez pas simplement vous intégrer à un seul fournisseur. Sept ou huit d'entre eux couvrent environ 75 % du marché. Après cela, c'est une immense longue traîne de configurations personnalisées. Parfois, un greffier met en ligne un PDF de l'ordre du jour. Parfois, il numérise une copie papier et la téléverse. On obtient des artefacts vraiment étranges.
Sara : De quoi les clients ont-ils besoin dans ces données ?
Sunil : Nos clients sont des entreprises privées telles que des promoteurs immobiliers, des développeurs de centres de données et des détaillants. Presque tous cherchent à faire approuver un projet plus rapidement ou à trouver de nouvelles opportunités. Sans Hamlet, quelqu'un assiste à des heures de réunion, attend que son projet soit abordé et observe le langage corporel des élus. Nous identifions qui a parlé, nous vous amenons à l'horodatage précis et nous vous fournissons les preuves.
Erich : Ils veulent aussi des précédents. Un projet comme le leur a-t-il été approuvé ou rejeté auparavant ? Pourquoi ? Quelles modifications le conseil a-t-il demandées ? Si nous pouvons montrer ce qui se passe réellement, cela apporte énormément de valeur.
Sara : Comment aidez-vous les clients à faire confiance aux informations qu'ils trouvent ?
Jeff Hui : Nous l'utilisons dans presque toutes les étapes du processus. Au début, Hamlet faisait ce travail à la main, et cela ne passe pas à l'échelle pour des milliers d'endroits. Pour beaucoup de ces gouvernements, la vidéo est la principale source de vérité. La convertir sous une forme structurée exploitable est l'étape la plus importante. Une réunion dure en moyenne trois heures et demie. Personne ne veut tout regarder. L'IA oriente les utilisateurs vers les passages pertinents, et la vidéo est toujours là pour appuyer le propos. Nous pouvons montrer exactement ce qui a été dit, ce que beaucoup de systèmes d'IA ont du mal à faire.
Sara : Comment identifiez-vous les intervenants avec précision sur des milliers de réunions ?
Jeff : Le contexte fait toute la différence. Pour l'identification des intervenants, nous savons quel conseil ou comité se réunit et qui en faisait partie à ce moment-là. Cela aide pour les noms, qui sont difficiles à saisir correctement, même pour une personne qui écoute un enregistrement. On ne peut pas simplement fournir une vidéo à un modèle et espérer le meilleur. Il faut collecter tout le contexte environnant qui l'aide à prendre la bonne décision. C'est un défi permanent.
Sara : Comment vérifiez-vous l'interprétation par l'IA des propos des élus ?
Sunil : Une transcription précise est la première étape. Pour l'analyse de sentiment, nous utilisons plusieurs modèles d'IA pour confirmer qu'un commentaire concerne un sujet donné, comme les centres de données. Ils examinent ensuite le contexte environnant pour déterminer s'il est pour ou contre.
Il faut également définir ce que signifient « pour » et « contre » avant de poser la question. Prenez le maintien de l'ordre. Que signifie être pour ? Nous apportons une grande attention à ces questions. Plusieurs modèles examinent désormais chaque indice de sentiment avant sa publication, et nous exigeons un niveau de confiance élevé.
Lakebase est la base de données gérée Postgres qu'utilise Hamlet pour donner à chaque pull request sa propre branche de données de production. Les ingénieurs peuvent tester les modifications par rapport aux données ayant causé un bug sans toucher à la production, tandis que les agents de codage IA exécutent les pipelines et vérifient leur travail avant qu'une personne n'approuve la fusion. L'équipe indique que sa précédente configuration de données de test pouvait prendre plusieurs heures par ingénieur chaque semaine.
Sara : Pourquoi avez-vous choisi Lakebase, et qu'est-ce qui a changé pour votre équipe ?
Erich : Nous avions une configuration assez classique sur AWS RDS, avec une instance de production et une instance de staging. Une grande partie de notre travail consiste à ajuster les pipelines de données par rapport à des données très spécifiques. Pour chaque pull request, nous passions 15 à 30 minutes à mettre le staging dans le bon état avant de pouvoir exécuter des validations. Nous sommes une petite équipe, et la rapidité compte pour nous plus que presque tout le reste.
Le branching de données a été la fonctionnalité qui nous a séduits. Chaque pull request obtient désormais sa propre branche de données de production, connectée à son environnement de prévisualisation. Lorsque la prévisualisation est déployée, tout est prêt. Nous pouvons faire des tests sur des données de production et même y écrire sans toucher à la production.
L'autoscaling aide aussi. Sur RDS, avoir une instance plus grande signifiait une migration qui pouvait prendre deux heures. Maintenant, nous déplaçons un curseur et obtenons une instance deux fois plus grande.
Jeff : Les 15 à 30 minutes, c'était dans le meilleur des cas, quand on réussissait à copier exactement les bonnes données. Chaque ingénieur pouvait passer plusieurs heures par semaine à maintenir les données de test à jour, y compris en clonant localement des parties de la production pour traquer les problèmes. Désormais, lorsque nous rencontrons un bug, nous disposons des données exactes qui l'ont provoqué, et nous pouvons vérifier le correctif par rapport à ces mêmes données.
Sara : Comment Lakebase change-t-il la façon dont travaillent vos agents de codage IA ?
Jeff : Les branches adaptent beaucoup mieux notre flux de travail aux agents de codage IA. Chaque pull request est isolée de la production. Nous donnons à un agent comme Claude ou Codex l'accès à sa branche et le laissons exécuter ses propres vérifications. Il exécute les pipelines de données jusqu'à leur terme et vérifie si la modification produit l'effet escompté. Chaque pull request bénéficie de ce premier passage par un agent. Au moment où un humain l'examine, nous sommes déjà assez confiants dans son fonctionnement. Un humain approuve toujours la fusion. De plus en plus du reste est automatisé, et Lakebase joue un rôle essentiel dans cette possibilité.
Sara : Que prévoyez-vous d'explorer par la suite avec Lakebase ?
Erich : Actuellement, la plupart de nos données résident dans une base de données relationnelle, et la recherche s'appuie sur une base de données vectorielle distincte. Les deux finissent par se désynchroniser. Tester la recherche redevient l'ancien problème du staging. J'ai essayé Lakebase Search, qui combine recherche vectorielle et textuelle dans Postgres, et le fait d'avoir tout au même endroit a été une excellente expérience.
Sara : Au-delà de la recherche, que souhaiteriez-vous simplifier par la suite ?
Erich : La création de branches a tellement bien fonctionné que nous aimerions retrouver la même chose pour les fichiers volumineux stockés dans notre stockage d'objets. Chaque développeur dispose de buckets de test à côté d'un bucket de production partagé, et gérer l'état à travers l'ensemble est complexe.
Jeff : Nous examinons également où exécuter les tâches agentiques plus longues. Une partie de notre ingestion utilise l'IA pour piloter un navigateur web et trouver le bon contenu sur les sites gouvernementaux. Certaines exécutions prennent quelques minutes. D'autres prennent 30 ou 40 minutes, et notre configuration AWS Lambda actuelle a une limite de 15 minutes.
Le travail de Hamlet commence avec l'enregistrement d'origine de la réunion, ce qui permet aux clients de remonter d'une analyse d'AI jusqu'à la déclaration officielle d'un intervenant. Lakebase prend en charge le flux de travail d'ingénierie sous-jacent : des branches de données de production permettent aux développeurs et aux agents de codage de tester des modifications sans toucher à la production, tandis que la fusion finale reste soumise à une validation humaine. Pour une petite équipe travaillant avec des milliers d'organismes de gouvernance, cela signifie moins de temps passé à préparer les données de test et plus de temps consacré à l'amélioration du produit.
Comment créer et supprimer automatiquement une branche Lakebase pour chaque pull request ?
Ajoutez deux étapes à votre pipeline d'intégration continue (CI) : créez une branche à partir de la production lors de l'ouverture d'une pull request (PR) et supprimez-la lorsque la PR est fusionnée ou fermée. Vous pouvez scripter ces deux étapes avec la Databricks CLI et les exécuter depuis un outil tel que GitHub Actions. Définissez une durée de vie (TTL) lors de la création de la branche afin qu'elle se supprime automatiquement, même si l'étape de nettoyage ne s'exécute pas. Consultez le tutoriel sur le flux de travail de développement basé sur les branches pour un exemple complet.
Comment fonctionne le système de branches de base de données dans Postgres ?
Une branche Lakebase est un environnement Postgres indépendant qui démarre avec le schéma et les données de son parent et partage son stockage avec lui grâce au copy-on-write. Seules les modifications effectuées sur la branche sont écrites séparément, ce qui signifie que la création d'une branche ne dépend pas de la taille de la base de données. Un Postgres standard crée une nouvelle base de données en copiant une base existante, ce qui duplique les données. Les branches de base de données Lakebase évitent cette copie, et les modifications dans une branche enfant n'affectent jamais son parent.
Comment déployer le système de branches de base de données auprès d'une équipe de développement ?
Commencez par une branche par pull request, le modèle utilisé par Hamlet, puis étendez l'utilisation des branches au reste de votre flux de travail. Chaque modèle remplace une base de données de préproduction partagée par des environnements isolés.
Combien coûte une branche Lakebase ?
Le coût dépend du calcul et du stockage. Chaque branche possède ses propres ressources de calcul, ajustées à zéro en cas d'inactivité, de sorte que vous ne payez que pour les heures de calcul actives. Pour le stockage, une branche temporaire n'est facturée que pour les données modifiées, tandis qu'une branche permanente sans expiration est facturée sur la totalité de son volume de données. Conservez une date d'expiration pour les branches à courte durée de vie. Consultez la section sur l'expiration des branches pour connaître les options.
Les agents de codage AI peuvent-ils effectuer des tests sur une branche Lakebase sans toucher à la production ?
Oui. Chaque branche est isolée de la production, de sorte qu'un agent peut appliquer des migrations, exécuter des tests et supprimer la branche une fois son travail terminé. Une personne valide toujours la fusion, et les modifications de schéma sont transmises à la branche parente via des migrations dans le code plutôt qu'en fusionnant la branche.
Pour en savoir plus sur Lakebase, visitez la page produit Lakebase Postgres.
(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original
Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.