Como a Trinta monitoriza centenas de fontes todos os dias: por dentro da arquitetura

Um gestor de propostas que exporta equipamento pela África Ocidental, pelo Golfo e pela América Latina tem, no papel, uma única função: nunca perder um concurso relevante. Na prática, essa função é quase impossível à mão. Os anúncios vivem em mais de 380 lugares diferentes: o TED da UE, o PNCP brasileiro, o SECOP colombiano, o DNCP paraguaio, o Banco Mundial e o UNGM, mais dezenas de portais nacionais de contratação pública, centrais de compras médicas (NUPCO, KEMSA, CENAME, SALAMA), redes hospitalares da segurança social (IMSS, EsSalud, CCSS), e hospitais de referência pontuais que publicam um único PDF e seguem em frente. Cada um usa uma língua, um layout, um formato de prazo e uma política de início de sessão diferentes. Verificar sequer trinta deles todas as manhãs é um cargo a tempo inteiro, e aquele que salta na terça-feira é aquele que fechou na sexta.

Esse problema de monitorização é exatamente o que a arquitetura da Trinta existe para resolver. Eis como funciona realmente por baixo do capô.

Centenas de conectores escritos à mão, não um scraper mágico

O atalho tentador, quando precisa de ler centenas de fontes, é construir um único scraper universal engenhoso e apontá-lo para todo o lado. Experimentámos essa abordagem e deitámo-la fora deliberadamente. Cada portal tem as suas próprias peculiaridades: esquemas de paginação, apertos de mão anti-falsificação (CSRF), ficheiros em massa open-contracting (OCDS) entregues como arquivos ZIP mensais, sessões de convidado em dois passos que lhe entregam um cookie de visitante antes de lhe mostrarem seja o que for. Um único motor genérico lida mal com tudo isto.

Por isso a Trinta funciona sobre conectores deterministas escritos à mão: um pequeno componente feito à medida por fonte, cada um afinado ao comportamento real desse portal. A frota cresceu de cerca de 15 conectores para perto de 200, e a contar. Um conector para uma API estruturada como o TED ou o PNCP é simples. Um conector para um portal que mostra um botão "Iniciar sessão" mas serve discretamente a sua lista de concursos a partir de um ponto de acesso público, sem autenticação, exige trabalho de detetive: renderizamos a página uma vez, observamos qual a chamada à API que realmente devolve os dados, e depois chamamos esse ponto de acesso diretamente. Essa técnica sozinha desbloqueou dezenas de portais que pareciam murados por fora.

Alguns princípios mantêm a frota honesta:

Uma varredura agendada que corre sem ninguém a vigiar

Os conectores são inúteis se um humano tiver de carregar em iniciar. Todo o pipeline corre sobre uma tarefa na nuvem agendada (um cron diário no GitHub Actions) que não requer nenhum portátil aberto nem ninguém acordado. Cada execução segue a mesma sequência disciplinada:

1. Colheita. Todos os conectores correm em paralelo, com um tempo-limite rígido por fonte para que um portal lento ou avariado nunca possa bloquear ou fazer falhar toda a varredura. 2. Ingestão e triagem. Os novos anúncios são fundidos no acervo, os expirados são descartados, e o ruído óbvio é filtrado. 3. Enriquecimento, auditoria, publicação. Os documentos são recolhidos, cada concurso é revisto, e os resultados são publicados no fluxo em direto.

Dois filtros fazem o trabalho pesado durante a colheita. Uma porta de relevância compara cada anúncio com um perfil de palavras-chave multilingue (inglês, francês, espanhol, português, árabe, hebraico), para que um anúncio turco ou brasileiro seja julgado na sua própria língua, e não numa tradução aproximada. E um filtro de âmbito descarta o que parece certo mas não é: para um comprador de sistemas, um anúncio de puro reabastecimento de consumíveis ou de aluguer de equipamento fica de fora, e o filtro conhece o vocabulário de aluguer em cinco línguas, por isso "locacao", "alquiler" e "location" acionam-no todos.

Enriquecimento documental: a lista de ficheiros, não apenas a ligação

Encontrar um concurso é metade do trabalho. A outra metade é lê-lo, e é aí que as equipas perdem horas: abrir o portal, procurar o processo, descarregar cada anexo. A camada de enriquecimento documental da Trinta faz isso automaticamente. Um distribuidor encaminha cada anúncio para o extrator certo:

Este passo é totalmente determinista e não precisa de nenhum modelo de IA, por isso corre a baixo custo em cada varredura. O resultado é que um concurso chega muitas vezes com a sua ligação de processo e uma lista de anexos já anexadas, para que a equipa de propostas comece a ler em vez de procurar.

Um agente de auditoria que pontua cada concurso, e falha ruidosamente

O último passo é aquele que a maioria das ferramentas de monitorização salta. Depois da colheita e do enriquecimento, um agente de auditoria revê cada concurso que ainda não foi revisto. Abre os documentos acessíveis, lê o âmbito, mapeia os requisitos ao que o cliente realmente fornece, e atribui uma pontuação de encaixe com uma breve justificação. Essa pontuação, e não uma contagem grosseira de palavras-chave, é o que conduz a ordenação no fluxo, por isso um lead com pontuação alta é um lead cujos requisitos uma pessoa já verificou.

Há uma regra de segurança deliberada gravada no código, e não apenas na documentação: cada concurso tem de ser auditado antes de ser divulgado. Se o passo de auditoria não puder correr (por exemplo, uma chave de API em falta) ou não auditar nada, toda a varredura falha ruidosamente e para. Nada por rever chega ao fluxo em direto. Preferimos não mostrar nenhuma atualização a mostrar uma errada.

Nunca dados falsos

Por baixo de tudo isto está uma regra que molda cada escolha de conceção: nunca fabricamos dados para preencher uma lacuna. Se um valor não é público, e os valores da contratação são realmente selados surpreendentemente muitas vezes (orçamentos brasileiros ao abrigo de certas leis, anúncios de obras alemães, valores de conselhos do Golfo por trás de um início de sessão), o fluxo mostra "Não divulgado" com a razão, nunca um número inventado. Uma taxa de documentos do concurso não é o valor do contrato, e nunca deixamos que um se faça passar pelo outro. Os anúncios obsoletos são podados numa janela de recência. Os anúncios de adjudicação e de resultado, que não têm um prazo real, são filtrados para que não possam aparecer como oportunidades em curso.

O retorno para o dono de PME, o exportador ou o consultor é simples. Em vez de patrulhar mais de 1000 portais e confiar que os cobriu, abre um único fluxo diário de concursos correspondidos, já pontuados quanto ao encaixe, já a transportar os seus documentos, já limpos de ruído, de contratos de reabastecimento e de anúncios expirados. O problema de monitorização não desaparece; simplesmente deixa de ser seu. É esse o objetivo inteiro de um fluxo diário pontuado e correspondido: as centenas de fontes continuam a mudar todas as noites, e só vê a mão-cheia que lhe importa.

Perguntas frequentes

Partilhar este artigo

Reference

Artigos relacionados