Uma conversa com o CEO do Hamlet, Sunil Rajaraman, e os engenheiros Erich Douglass e Jeff Hui
por Sara Steffen
A Hamlet, uma plataforma baseada em IA que torna a tomada de decisões do governo local acessível e pesquisável, usa o Databricks Lakebase Postgres para dar a cada pull request sua própria ramificação de dados de produção. Engenheiros e agentes de codificação por IA testam alterações em dados reais sem tocar na produção, e uma pessoa ainda aprova cada merge.
Conversei com o CEO Sunil Rajaraman, o desenvolvedor líder Erich Douglass e o engenheiro sênior de IA Jeff Hui sobre como eles trabalham.
A Hamlet é uma plataforma de tecnologia baseada em IA que torna a tomada de decisões do governo local acessível e pesquisável. Ao indexar e transcrever milhares de reuniões de câmaras municipais, comissões de planejamento e conselhos de zoneamento nos EUA, a Hamlet permite que incorporadores imobiliários, jornalistas, pesquisadores e cidadãos pesquisem instantaneamente transcrições de reuniões, acompanhem desdobramentos de políticas locais e configurem alertas em tempo real para tópicos, endereços ou empresas específicos.
Sara Steffen: A Hamlet indexa reuniões de mais de 7.200 órgãos governamentais em todos os estados. Como é esse cenário de dados e por que é tão difícil compreendê-lo?
Sunil Rajaraman: Existem 19.000 governos municipais, 3.000 governos de condados e cerca de 80.000 distritos especiais nos Estados Unidos. Escolha dois sites quaisquer e eles não serão parecidos. Esse é o pecado original do governo local. Um punhado de provedores de CMS decidiu que cada site deveria ser diferente, e o resultado é uma internet governamental completamente balcanizada. A Hamlet reúne tudo e padroniza.
Sara: A Hamlet se descreve como uma plataforma de inteligência cívica. Qual é a diferença para uma ferramenta de transcrição e por que essa distinção importa?
Sunil: Muitas empresas de govtech fazem arbitragem de dados municipais. Elas criam scrapers frágeis para sites da era de 1998 e colocam uma camada moderna por cima. Fazer scraping e armazenar dados não agrega muito por si só. É preciso contar uma história, e ela precisa ser baseada em fatos. Isso significa saber quem está falando e o que pensa sobre um assunto. Se você é um incorporador, quer saber se um vereador aprovará seu projeto habitacional, por que sim ou por que não, e que histórico a cidade tem que possa fazê-la hesitar.
Olhe para o licenciamento. Muito capital de risco foi investido em dados de licenciamento, e os prazos de emissão de licenças ainda assim pioraram na última década. Muitas empresas construíram monumentos para os sintomas. Queremos chegar ao problema fundamental, que é entender as pessoas. A pergunta que estamos tentando responder é como as cidades funcionam fundamentalmente.
Sara Steffen: O que torna os dados do governo local tão difíceis de trabalhar?
Sunil Rajaraman: Escolha dois sites quaisquer e eles não serão parecidos. A Hamlet reúne tudo e padroniza.
Erich Douglass: Não dá para simplesmente se integrar a um único provedor. Sete ou oito cobrem cerca de 75% do mercado. Depois disso, há uma enorme cauda longa de configurações personalizadas. Às vezes, um funcionário envia um PDF da pauta. Às vezes, escaneia uma cópia em papel e faz o upload. Você encontra artefatos realmente estranhos.
Sara: O que os clientes precisam desses dados?
Sunil: Nossos clientes são empresas privadas, como incorporadoras imobiliárias, desenvolvedores de data centers e varejistas. Quase todos tentam aprovar um projeto mais rapidamente ou encontrar uma nova oportunidade. Sem a Hamlet, alguém precisa assistir a horas de reuniões, esperar que seu projeto seja mencionado e observar a linguagem corporal dos funcionários. Nós identificamos quem falou, levamos você até a marca de tempo e mostramos as evidências.
Erich: Eles também querem precedentes. Um projeto como o deles já foi aprovado ou rejeitado antes? Por quê? Quais alterações o conselho pediu? Se pudermos mostrar o que realmente está acontecendo, isso gera muito valor.
Sara: Como vocês ajudam os clientes a confiar nos insights que encontram?
Jeff Hui: Usamos isso em quase todas as etapas do processo. No início, a Hamlet fazia esse trabalho manualmente, e isso não escala para milhares de locais. Para muitos desses governos, o vídeo é a principal fonte de verdade. Transformá-lo em um formato estruturado que possamos usar é a parte mais importante. A reunião média dura cerca de três horas e meia. Ninguém quer assistir a tudo. A IA direciona as pessoas para as partes que valem o tempo delas, e o vídeo está sempre lá para comprovar. Podemos mostrar exatamente o que foi dito, algo que muitos sistemas de IA têm dificuldade em fazer.
Sara: Como vocês identificam os oradores com precisão em milhares de reuniões?
Jeff: O contexto faz a maior diferença. Para a identificação de oradores, sabemos qual conselho ou comissão está se reunindo e quem fazia parte no momento. Isso ajuda com nomes, que são difíceis de acertar até mesmo para uma pessoa ouvindo uma gravação. Não dá para entregar um vídeo a um modelo e esperar pelo melhor. Você precisa coletar tudo ao redor que o ajude a tomar a decisão certa. É um desafio permanente.
Sara: Como vocês verificam a interpretação da IA sobre o que os funcionários dizem?
Sunil: A transcrição precisa vem em primeiro lugar. Para a análise de sentimento, usamos múltiplos modelos de IA para confirmar se um comentário é sobre determinado tópico, como data centers. Em seguida, eles analisam o contexto ao redor para decidir se é a favor ou contra.
Você também precisa definir o que significa "a favor" e "contra" antes de perguntar. Tome o policiamento como exemplo. O que significa ser a favor? Colocamos muito cuidado nessas perguntas. Vários modelos agora revisam cada indicador de sentimento antes de publicarmos, e exigimos alta confiança.
O Lakebase é o banco de dados Postgres gerenciado que a Hamlet usa para dar a cada pull request sua própria ramificação de dados de produção. Engenheiros podem testar alterações com base nos dados que causaram um bug sem tocar na produção, enquanto agentes de codificação por IA executam os pipelines e checam seu trabalho antes que uma pessoa aprove o merge. A equipe afirma que sua configuração anterior de dados de teste podia levar várias horas por engenheiro a cada semana.
Sara: Por que vocês escolheram o Lakebase e o que mudou para sua equipe?
Erich: Tínhamos uma configuração bastante padrão no AWS RDS, com uma instância de produção e uma de staging. Grande parte do nosso trabalho é ajustar pipelines de dados em relação a dados muito específicos. Para cada pull request, gastávamos de 15 a 30 minutos colocando o staging no estado correto antes de podermos executar validações. Somos uma equipe pequena e a velocidade é mais importante para nós do que quase qualquer outra coisa.
A ramificação de dados (data branching) foi o recurso que nos convenceu. Agora, cada pull request recebe sua própria ramificação de dados de produção, conectada ao seu ambiente de pré-visualização. Quando a pré-visualização é implantada, ela está pronta. Podemos testar em dados de produção e até mesmo gravar neles sem tocar na produção.
O autoscaling também ajuda. No RDS, uma instância maior significava uma migração que podia levar algumas horas. Agora, basta mover um controle deslizante e obter uma instância duas vezes maior.
Jeff: Os 15 a 30 minutos eram no melhor dos casos, quando você por acaso copiava exatamente os dados certos. Cada engenheiro podia gastar várias horas por semana mantendo os dados de teste atualizados, incluindo clonar partes da produção localmente para rastrear problemas. Agora, quando encontramos um bug, temos os dados exatos que o causaram e podemos verificar a correção com base nesses mesmos dados.
Sara: Como o Lakebase muda a forma como seus agentes de codificação por IA trabalham?
Jeff: As ramificações tornam nosso fluxo de trabalho muito mais adequado para agentes de codificação por IA. Cada pull request fica isolado da produção. Damos a um agente como o Claude ou Codex acesso à sua ramificação e deixamos que ele execute suas próprias verificações. Ele executa os pipelines de dados até a conclusão e verifica se a alteração faz o que deveria. Cada pull request passa por essa primeira verificação de um agente. Quando uma pessoa vai analisar, já temos bastante confiança de que funciona. Um humano ainda aprova o merge. O restante está cada vez mais automatizado, e o Lakebase é uma grande parte do que torna isso possível.
Sara: O que vocês estão explorando a seguir com o Lakebase?
Erich: No momento, a maior parte dos nossos dados fica em um banco de dados relacional, e a busca é executada em um banco de dados vetorial separado. Os dois ficam dessincronizados. Testar a busca volta a ser o antigo problema de staging. Tenho testado o Lakebase Search, que combina busca vetorial e de texto no Postgres, e ter tudo em um só lugar tem sido ótimo.
Sara: Além da busca, o que você gostaria de simplificar a seguir?
Erich: A ramificação funcionou tão bem que adoraríamos ter a mesma coisa para os arquivos grandes que mantemos no armazenamento de objetos. Cada desenvolvedor tem buckets de teste ao lado de um bucket de produção compartilhado, e gerenciar o estado entre eles é difícil.
Jeff: Também estamos analisando onde executar tarefas de agentes mais longas. Parte da nossa ingestão usa IA para controlar um navegador web e encontrar o conteúdo certo em sites governamentais. Algumas execuções levam alguns minutos. Outras levam 30 ou 40, e nossa configuração atual do AWS Lambda tem um limite de 15 minutos.
O trabalho da Hamlet começa com a gravação original da reunião, para que os clientes possam rastrear um insight de IA até a fala de uma autoridade. O Lakebase dá suporte ao fluxo de trabalho de engenharia por trás dessa experiência: branches de dados de produção permitem que desenvolvedores e agentes de código testem alterações sem tocar na produção, enquanto pessoas continuam aprovando o merge final. Para uma equipe pequena que trabalha em milhares de órgãos governamentais, isso significa menos tempo preparando dados de teste e mais tempo aprimorando o produto.
Como você pode criar e excluir automaticamente um branch do Lakebase para cada pull request?
Adicione duas etapas ao seu pipeline de integração contínua (CI): crie um branch a partir da produção quando um pull request (PR) for aberto e exclua-o quando o PR for mesclado ou fechado. Você pode criar scripts para ambas as etapas com a Databricks CLI e executá-los a partir de uma ferramenta como o GitHub Actions. Defina uma expiração, um tempo de vida (TTL), ao criar o branch para que ele seja excluído automaticamente, mesmo que a etapa de limpeza nunca seja executada. Consulte o tutorial de fluxo de trabalho de desenvolvimento baseado em branch para ver um exemplo completo.
Como funciona o branching de banco de dados no Postgres?
Um branch do Lakebase é um ambiente Postgres independente que começa com o esquema e os dados de seu pai e compartilha o armazenamento com ele por meio de copy-on-write. Apenas as alterações feitas no branch são gravadas separadamente, portanto, a criação de um branch não depende do tamanho do banco de dados. O Postgres padrão cria um novo banco de dados copiando um existente, o que duplica os dados. Os branches de banco de dados do Lakebase evitam essa cópia, e as alterações em um branch filho nunca afetam seu pai.
Como implantar o branching de banco de dados em uma equipe de desenvolvimento?
Comece com um branch por pull request, o padrão que a Hamlet usa, e depois estenda o branching para o restante do seu fluxo de trabalho. Cada padrão substitui um banco de dados de staging compartilhado por ambientes isolados.
Quanto custa um branch do Lakebase?
O custo depende da computação e do armazenamento. Cada branch tem sua própria computação, que reduz a zero quando ociosa, para que você pague apenas pelas horas de computação ativas. Em relação ao armazenamento, um branch temporário é cobrado apenas pelos dados que mudam nele, enquanto um branch permanente sem expiração é cobrado pelo tamanho total dos dados. Mantenha uma expiração em branches de curta duração. Consulte a expiração de branch para ver as opções.
Agentes de código com IA podem testar em um branch do Lakebase sem tocar na produção?
Sim. Cada branch é isolado da produção, portanto, um agente pode aplicar migrações, executar testes e desativar o branch quando terminar. Uma pessoa continua aprovando o merge, e as alterações de esquema são movidas para o branch pai por meio de migrações no código, em vez de mesclar o branch.
Para saber mais sobre o Lakebase, visite a página do produto Lakebase Postgres.
(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original
Assine nosso blog e receba os posts mais recentes diretamente na sua caixa de entrada.