Pular para conteúdo

Blog

Entidades em alta, políticas públicas e o fechamento do ciclo

Em cerca de três semanas (10 de junho a 3 de julho), a plataforma fechou o ciclo transformando pesquisa em produto. Um scorer de detecção de tendências subiu de NDCG@10 0.727 para 1.000 e virou uma seção "Entidades em Alta" na home; as políticas públicas deixaram de ser texto solto e passaram a objetos de primeira classe, com ontologia, gazetteer e queries próprias; e uma release consolidada de entidades (NER v2) foi para produção. Este é o quarto e último post da série — o momento em que a canonicalização, o grafo e o agente Gobus viram aplicação no ar.

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.

Entidades que viram conhecimento: NER canônico, Wikidata e a lente semântica

Até esta rodada, uma entidade no DGB era apenas texto: "Min. da Saúde", "Ministério da Saúde" e "MS" eram três coisas diferentes para a plataforma, strings soltas presas a uma notícia e a mais nada. Em dois dias (10 e 11 de junho de 2026), a plataforma trocou esse NER "bruto" por entidades canônicas — cada menção passou a resolver para um nó de conhecimento com identidade estável, tipo (organização, pessoa, lugar, e agora também Eventos e Políticas públicas) e, quando possível, um QID da Wikidata como chave de deduplicação linked-data. No caminho, a busca de "relacionadas" deixou de ser por código de tema e virou similaridade semântica (com um ganho medido de ~4,3s para ~180ms), a tela da notícia ganhou chips agrupados por tipo e uma lente semântica que marca entidades no corpo do texto.

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.

Fonte única de dados: o desacoplamento BD→GraphQL e os bugs que só o navegador pegou

Cinco dias depois de a fachada GraphQL entrar no ar, ela ainda dividia o trabalho com o passado: o portal falava GraphQL, sim — mas atrás de feature flags, com fallback REST por baixo, e várias páginas públicas ainda liam o Firestore e o Typesense direto. Existir não era o suficiente; faltava ser o único caminho. Este post conta a história de cortar esse último cabo — Fases 1 a 4 do desacoplamento — e de como um punhado de bugs que o build jurava não existir só apareceu quando um navegador de verdade exercitou o caminho browser → portal → graphql-api.

Uma fachada GraphQL para o DGB: arquitetura e um novo paradigma de dados

Por meses, cada parte da plataforma falou direto com os backends de dados: o portal lia o Firestore via Firebase Admin, consultava o PostgreSQL para temas e órgãos, batia no Typesense para busca — e os workers liam o Postgres direto via DATABASE_URL. Esse post conta a decisão de colocar uma fachada GraphQL única no meio disso, como ela ficou por dentro, e — principalmente — convida o time a explorar a documentação nova e se apropriar do paradigma que ela inaugura. É um relato de design para quem vai construir em cima dela.

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.

Bot Telegram e scraper resiliente: push notifications v2 e otimização de coleta

O pipeline event-driven disparava notificações web push, mas faltava o canal mais direto: Telegram. Em paralelo, o scraper ganhou otimizações que cortaram requests HTTP pela metade e corrigiram agências com falha persistente. ~12 PRs em 5 repos, incluindo 2 repos novos (push-notifications, telegram-bot) e infraestrutura completa no Cloud Run.