Pular para conteúdo

Infraestrutura

Gobus MCP: um agente que investiga o gov.br — do Cloud Run ao forecast

Em pouco menos de duas semanas — de 19 de junho a 1 de julho de 2026 — a plataforma DGB ganhou uma nova porta: o Gobus MCP, um servidor que abre todo o acervo enriquecido de notícias do governo a agentes de IA como o Claude. Não é mais um endpoint humano; é uma interface para uma máquina que raciocina. Com ele, um agente passou a poder perguntar "o que o MEC comunicou esta semana?", "essa política está em qual fase?", "há algum pico anômalo de cobertura?" e "quais temas devem crescer nos próximos dias?" — e responder consultando dados reais, não a própria memória. Este post conta o nascimento do Gobus: as quatro queries GraphQL que o alimentam, o provisionamento no Cloud Run, o site de documentação, as duas fases de capacidades analíticas, e — o fio mais honesto da história — a saga do transporte, um bug de sessão que só apareceu quando subagentes começaram a usar o servidor de verdade.

O grafo do gov.br: entidades em Neo4j e o backfill retroativo com governador de cota

Com as entidades canônicas em mãos — cada órgão, lei, política e pessoa reduzido a um canonical_id estável, muitos deles já ancorados num QID da Wikidata — faltava fazer duas coisas com elas. A primeira: projetá-las num grafo, para que "quem aparece com quem" deixasse de ser uma consulta ad-hoc e virasse uma estrutura navegável, no Postgres e num Neo4j dedicado, servida ao portal como entidades relacionadas e uma rede ego-centrada. A segunda, bem mais dura: rodar um backfill retroativo sobre toda a base histórica — os ~314 mil artigos que nunca passaram pelo NER canônico — sem estourar o teto diário de tokens da AWS Bedrock. Em cerca de três dias intensos, a plataforma ganhou o grafo (Fases 6a–6d) e transformou o reprocessamento numa operação de guerra controlada por um governador de cota, com direito a dois tropeços de permissão, uma quota que se descobriu fictícia, um limite real da AWS confirmado na marra e uma sequência de falsos-positivos de sigla que só apareceram rodando em escala de produção.

MLflow no DGB: uma plataforma de experimentos atrás do IAP — e o JWT que a lib assina sozinha

Até esta semana, cada experimento de ciência de dados do DGB vivia e morria na máquina de quem o rodou: métricas num notebook, o modelo num .pkl perdido numa pasta, e nenhum rastro compartilhado de "o que foi treinado, com quais dados, e quão bom ficou". A plataforma ganhou agora um servidor MLflow compartilhado — tracking de experimentos, Model Registry e ferramentas de GenAI — rodando em Cloud Run atrás do IAP, com uma biblioteca cliente que faz a autenticação sumir: import dgb_mlflow; dgb_mlflow.configure() e o resto é o mlflow de sempre. Este post conta o que foi construído, e o gotcha de autenticação que virou a peça central do desenho.

Março na DGB — da busca semântica ao pentest, passando pelo clipping

Em 24 dias, a plataforma DGB recebeu cerca de 100 PRs em 11 repositórios, tocando desde a experiência de busca do portal até a correção de vulnerabilidades identificadas em pentest. O mês trouxe três grandes movimentos: um sistema de clipping completo, o hardening de segurança pós-pentest, e a ativação da busca semântica.

Três frentes em paralelo: scraper, Telegram e Keycloak

Entre 4 e 6 de março, o projeto avançou em paralelo em três direções distintas: o scraper ganhou uma otimização de performance que evita re-processar artigos já conhecidos, o serviço de push notifications cresceu de WebPush para um ecossistema Telegram completo, e a infraestrutura de autenticação ganhou um SSO centralizado com Keycloak.

Umami, GrowthBook, Auth e v1.0.0: dois dias até o release do Portal

Sábado de manhã o portal não tinha analytics, nem autenticação, nem feature flags. Domingo à noite, tínhamos Umami Analytics com IAP, GrowthBook com dual-service, autenticação Google OAuth, push notifications com service worker, e a tag v1.0.0 no ar. Foram ~25 PRs em 6 repos, com 3 serviços novos no Cloud Run, e uma release que consolida semanas de trabalho.