Una conversación con el CEO de Hamlet, Sunil Rajaraman, y los ingenieros Erich Douglass y Jeff Hui
por Sara Steffen
Hamlet, una plataforma impulsada por AI que hace que la toma de decisiones de los gobiernos locales sea accesible y fácil de buscar, utiliza Databricks Lakebase Postgres para ofrecer a cada pull request su propia rama de datos de producción. Los ingenieros y los agentes de código de AI prueban los cambios con datos reales sin tocar la producción, y una persona sigue aprobando cada merge.
Hablé con el CEO Sunil Rajaraman, el desarrollador principal Erich Douglass y el ingeniero sénior de AI Jeff Hui sobre cómo trabajan.
Hamlet es una plataforma tecnológica impulsada por AI que hace que la toma de decisiones de los gobiernos locales sea accesible y fácil de buscar. Al indexar y transcribir miles de reuniones de concejos municipales, comisiones de planificación y juntas de zonificación en todo EE. UU., Hamlet permite a desarrolladores inmobiliarios, periodistas, investigadores y ciudadanos buscar al instante transcripciones de reuniones, realizar un seguimiento de las novedades de las políticas locales y configurar alertas en tiempo real sobre temas, direcciones o empresas específicas.
Sara Steffen: Hamlet indexa reuniones de más de 7200 organismos de gobierno en todos los estados. ¿Cómo es ese panorama de datos y por qué es tan difícil darle sentido?
Sunil Rajaraman: Hay 19 000 gobiernos municipales, 3000 gobiernos de condados y aproximadamente 80 000 distritos especiales en Estados Unidos. Elige dos de sus sitios web y verás que no se parecen en nada. Ese es el pecado original del gobierno local. Un puñado de proveedores de CMS decidió que cada sitio debía ser diferente, y el resultado es un internet gubernamental completamente fragmentado. Hamlet recopila todo esto y lo estandariza.
Sara: Hamlet se describe a sí misma como una plataforma de inteligencia cívica. ¿En qué se diferencia de una herramienta de transcripción y por qué es importante esa distinción?
Sunil: Muchas empresas de tecnología gubernamental son un arbitraje de datos municipales. Escriben scrapers frágiles para sitios web de la era de 1998 y les aplican una capa de pintura moderna por encima. Extraer y almacenar los datos no aporta mucho por sí solo. Tienes que contar una historia y esta debe basarse en hechos. Eso significa saber quién habla y qué opina sobre un tema. Si eres un desarrollador, quieres saber si un concejal aprobará tu proyecto de vivienda, por qué sí o por qué no, y qué antecedentes tiene la ciudad que podrían hacerla dudar.
Mira el caso de la concesión de permisos. Se ha invertido mucho capital de riesgo en los datos de permisos, y aun así los plazos de tramitación han empeorado en la última década. Muchas empresas han construido monumentos a los síntomas. Nosotros queremos llegar al problema de fondo, que es comprender a las personas. La pregunta que intentamos responder es cómo funcionan fundamentalmente las ciudades.
Sara Steffen: ¿Qué hace que los datos de los gobiernos locales sean tan difíciles de manejar?
Sunil Rajaraman: Elige dos de sus sitios web y verás que no se parecen en nada. Hamlet recopila todo esto y lo estandariza.
Erich Douglass: No basta con integrarse con un solo proveedor. Siete u ocho de ellos cubren alrededor del 75 % del mercado. A partir de ahí, hay una enorme cola larga de configuraciones personalizadas. A veces un funcionario sube un PDF del orden del día. A veces escanean una copia en papel y la suben. Encuentras algunos artefactos realmente extraños.
Sara: ¿Qué necesitan los clientes de esos datos?
Sunil: Nuestros clientes son empresas privadas como desarrolladores inmobiliarios, desarrolladores de centros de datos y minoristas. Casi todos intentan conseguir que se apruebe un proyecto más rápido o encontrar una nueva oportunidad. Sin Hamlet, alguien tendría que presenciar horas de reuniones, esperar a que surja su proyecto y observar el lenguaje corporal de los funcionarios. Nosotros identificamos quién habló, te llevamos a la marca de tiempo exacta y te mostramos las pruebas.
Erich: También quieren precedentes. ¿Se ha aprobado o rechazado antes un proyecto como el suyo? ¿Por qué? ¿Qué cambios pidió el concejo? Si podemos mostrar lo que realmente está pasando, eso aporta un gran valor.
Sara: ¿Cómo ayudan a los clientes a confiar en los datos e información que encuentran?
Jeff Hui: Lo usamos en casi todas las partes del proceso. Al principio, Hamlet hacía este trabajo a mano, y eso no escala a miles de lugares. Para muchos de estos gobiernos, el video es la fuente principal de verdad. Convertirlo en una forma estructurada que podamos usar es la parte más importante. La reunión promedio dura unas tres horas y media. Nadie quiere verla entera. La AI dirige a las personas hacia las partes que valen la pena, y el video siempre está ahí para respaldarlo. Podemos mostrar exactamente lo que se dijo, algo con lo que muchos sistemas de AI tienen dificultades.
Sara: ¿Cómo identifican con precisión a los oradores a través de miles de reuniones?
Jeff: El contexto marca la gran diferencia. Para la identificación de oradores, sabemos qué concejo o comité se está reuniendo y quiénes lo integraban en ese momento. Eso ayuda con los nombres, que son difíciles de descifrar incluso para una persona que escucha una grabación. No puedes entregarle un video a un modelo y esperar lo mejor. Tienes que recopilar todo lo que lo rodea para ayudarlo a tomar la decisión correcta. Es un desafío constante.
Sara: ¿Cómo verifican la interpretación que hace la AI de lo que dicen los funcionarios?
Sunil: Lo primero es una transcripción precisa. Para el análisis de sentimiento, usamos múltiples modelos de AI para confirmar que un comentario trata sobre un tema determinado, por ejemplo, centros de datos. Luego examinan el contexto circundante para decidir si está a favor o en contra.
También hay que definir qué significan 'a favor' y 'en contra' antes de preguntar. Toma la vigilancia policial, por ejemplo. ¿Qué significa estar a favor? Ponemos mucho cuidado en esas preguntas. Varios modelos revisan ahora cada cifra de sentimiento antes de publicarla, y exigimos un alto nivel de confianza.
Lakebase es la base de datos gestionada de Postgres que utiliza Hamlet para dar a cada pull request su propia rama de datos de producción. Los ingenieros pueden probar los cambios con los datos que causaron un error sin tocar la producción, mientras que los agentes de código de AI ejecutan las pipelines y comprueban su trabajo antes de que una persona apruebe el merge. El equipo afirma que su configuración anterior de datos de prueba podía llevar varias horas a la semana por ingeniero.
Sara: ¿Por qué eligieron Lakebase y qué cambió para su equipo?
Erich: Teníamos una configuración bastante estándar en AWS RDS, con una instancia de producción y una instancia de staging. Gran parte de nuestro trabajo consiste en ajustar las pipelines de datos con datos muy específicos. Para cada pull request, dedicábamos entre 15 y 30 minutos a poner el entorno de staging en el estado adecuado antes de poder ejecutar las validaciones. Somos un equipo pequeño y la velocidad nos importa más que casi cualquier otra cosa.
El ramificado de datos fue la funcionalidad que nos convenció. Ahora cada pull request obtiene su propia rama de datos de producción, conectada a su entorno de vista previa. Cuando se despliega la vista previa, ya está lista. Podemos hacer pruebas con datos de producción e incluso escribir en ellos sin tocar la producción.
El escalado automático también ayuda. En RDS, una instancia más grande significaba una migración que podía llevar un par de horas. Ahora movemos un deslizador y obtenemos una instancia el doble de grande.
Jeff: Los 15 a 30 minutos eran en el mejor de los casos, cuando se daba la casualidad de copiar exactamente los datos correctos. Cada ingeniero podía pasar varias horas a la semana manteniendo al día los datos de prueba, lo que incluía clonar partes de producción localmente para solucionar problemas. Ahora, cuando encontramos un error, tenemos los datos exactos que lo causaron y podemos verificar la corrección con esos mismos datos.
Sara: ¿De qué manera cambia Lakebase la forma en que trabajan sus agentes de código de AI?
Jeff: Las ramas hacen que nuestro flujo de trabajo se adapte mucho mejor a los agentes de código de AI. Cada pull request está aislado de la producción. Le damos a un agente como Claude o Codex acceso a su rama y dejamos que ejecute sus propias comprobaciones. Ejecuta las pipelines de datos hasta el final y observa si el cambio hace lo que debería. Cada pull request recibe esa primera revisión por parte de un agente. Para cuando una persona lo revisa, ya estamos bastante seguros de que funciona. Un humano sigue aprobando el merge. Cada vez hay más procesos automatizados, y Lakebase es una parte fundamental de lo que lo hace posible.
Sara: ¿Qué están explorando ahora con Lakebase?
Erich: En este momento, la mayor parte de nuestros datos reside en una base de datos relacional y la búsqueda se ejecuta en una base de datos vectorial independiente. Las dos se dessincronizan. Probar la búsqueda vuelve a convertirse en el viejo problema del staging. He estado probando Lakebase Search, que combina la búsqueda vectorial y de texto en Postgres, y tenerlo todo en un solo lugar ha sido excelente.
Sara: Más allá de la búsqueda, ¿qué les gustaría simplificar a continuación?
Erich: El ramificado de datos ha funcionado tan bien que nos encantaría tener lo mismo para los archivos grandes que guardamos en el almacenamiento de objetos. Cada desarrollador tiene buckets de prueba junto a un bucket de producción compartido, y gestionar el estado entre ellos es difícil.
Jeff: También estamos evaluando dónde ejecutar tareas de agentes más largas. Parte de nuestra ingesta utiliza AI para manejar un navegador web y encontrar el contenido correcto en sitios gubernamentales. Algunas ejecuciones duran unos minutos. Otras tardan 30 o 40, y nuestra configuración actual de AWS Lambda tiene un límite de 15 minutos.
El trabajo de Hamlet comienza con la grabación original de la reunión, para que los clientes puedan rastrear un insight de IA hasta lo que dijo un representante oficial. Lakebase admite el flujo de trabajo de ingeniería detrás de esa experiencia: las ramas de datos de producción permiten a los desarrolladores y agentes de código probar cambios sin tocar producción, mientras que las personas siguen aprobando la fusión final. Para un equipo pequeño que trabaja con miles de organismos gubernamentales, esto significa menos tiempo preparando datos de prueba y más tiempo mejorando el producto.
¿Cómo se puede crear y eliminar automáticamente una rama de Lakebase para cada pull request?
Añada dos pasos a su canalización de integración continua (CI): cree una rama a partir de producción cuando se abra una pull request (PR) y elimínela cuando la PR se fusione o se cierre. Puede automatizar mediante scripts ambos pasos con la Databricks CLI y ejecutarlos desde una herramienta como GitHub Actions. Establezca un tiempo de expiración o tiempo de vida (TTL) al crear la rama para que se elimine por sí sola incluso si el paso de limpieza nunca se ejecuta. Consulte el tutorial del flujo de trabajo de desarrollo basado en ramas para ver un ejemplo completo.
¿Cómo funciona la ramificación de bases de datos en Postgres?
Una rama de Lakebase es un entorno independiente de Postgres que comienza con el esquema y los datos de su entorno principal y comparte almacenamiento con él mediante copy-on-write (copia en escritura). Solo los cambios realizados en la rama se escriben por separado, por lo que la creación de una rama no depende del tamaño de la base de datos. Postgres estándar crea una nueva base de datos copiando una existente, lo que duplica los datos. Las ramas de bases de datos de Lakebase evitan esa copia y los cambios en una rama secundaria nunca afectan a la principal.
¿Cómo se implementa la ramificación de bases de datos en un equipo de desarrollo?
Comience con una rama por pull request, el patrón que utiliza Hamlet, y luego extienda la ramificación al resto de su flujo de trabajo. Cada patrón reemplaza una base de datos de staging compartida por entornos aislados.
¿Cuánto cuesta una rama de Lakebase?
El coste depende de la computación y del almacenamiento. Cada rama tiene su propia computación, que se escala a cero cuando está inactiva, por lo que solo paga por las horas de computación activas. En cuanto al almacenamiento, una rama con expiración solo se factura por los datos que cambian en ella, mientras que una rama permanente sin expiración se factura por su tamaño de datos completo. Mantenga una expiración en las ramas de corta duración. Consulte la sección expiración de ramas para conocer las opciones.
¿Pueden los agentes de código de IA realizar pruebas en una rama de Lakebase sin tocar producción?
Sí. Cada rama está aislada de producción, por lo que un agente puede aplicar migraciones, ejecutar pruebas y retirar la rama cuando termine. Una persona sigue aprobando la fusión, y los cambios de esquema se mueven a la rama principal a través de migraciones en código en lugar de fusionar la rama.
Para obtener más información sobre Lakebase, visite la página del producto Lakebase Postgres.
(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original
Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.