Agentes autónomos que vigiam portais de contratação pública

Os portais de contratação pública foram construídos para humanos a clicar por páginas, não para software a lê-las. Cada um tem a sua própria disposição, o seu próprio formulário de pesquisa, a sua própria forma de listar anúncios, e o seu próprio hábito de mudar essa disposição sem aviso. Vigiar sequer um punhado destes portais de forma fiável, todos os dias, sem falhar um novo anúncio nem contar duas vezes um antigo, é um problema mais difícil do que parece de fora. É isto que os agentes de monitorização autónomos existem para resolver, e compreender como funcionam explica porque é que algumas abordagens aguentam meses de operação contínua e outras se avariam discretamente em semanas.

O que um agente de monitorização faz realmente

No seu mais simples, um agente de monitorização visita uma fonte segundo um calendário, extrai qualquer novo conteúdo que tenha surgido, e transforma-o num registo estruturado: um título, um comprador, um prazo, uma categoria, uma ligação de volta ao anúncio original. Repetido por centenas de fontes e executado todos os dias, isto produz uma visão continuamente atualizada do que está atualmente em aberto em todo um mercado, algo que nenhuma equipa conseguiria manter à mão a um custo razoável.

A complexidade não está no conceito. Está em fazer isto de forma fiável contra fontes que nunca foram concebidas para serem lidas por máquinas, que mudam de estrutura sem aviso, e que por vezes falham, expiram ou devolvem páginas incompletas por razões alheias ao próprio agente.

Conectores por portal: porque uma só abordagem não serve para todos

A abordagem ingénua trata todos os portais de contratação da mesma forma: obter a página, procurar algo que se pareça com uma lista de concursos, extraí-la. Isto funciona para as fontes mais simples e padronizadas e falha em quase todo o resto. Uma plataforma nacional de contratação eletrónica com uma API documentada é um problema completamente diferente de uma autoridade regional de saúde a publicar anúncios em PDF dentro de uma página web estática, que é por sua vez diferente de um portal que apresenta as suas listas através de JavaScript depois do carregamento inicial da página.

A abordagem mais resiliente constrói um conector dedicado para cada fonte: uma pequena peça de lógica feita à medida que compreende exatamente como aquele portal em particular estrutura os seus dados, onde vive o campo do prazo, e como distinguir um anúncio verdadeiramente novo de um que simplesmente foi reordenado para o topo de uma lista. Um conector para um endpoint de API estruturado não se parece nada com um conector para um portal baseado em PDF, e nenhum se parece com um construído para um sítio que exige um início de sessão antes de os resultados se tornarem visíveis. Tratar cada fonte como o seu próprio problema bem compreendido, em vez de forçar um único raspador genérico a lidar com tudo, é o que faz a monitorização aguentar-se em centenas de portais verdadeiramente diferentes.

Deteção de alterações: saber o que é realmente novo

Um portal raramente anuncia que um anúncio é novo. Os agentes têm de o inferir, tipicamente mantendo um registo do que já foi visto, indexado por alguma combinação de um identificador de fonte, um número de referência e uma data de publicação, e comparando cada nova extração com esse registo. Erre isto num sentido e o mesmo concurso surge três vezes numa semana. Erre-o no outro sentido e uma oportunidade verdadeiramente nova é silenciosamente tratada como duplicado e nunca surge de todo, a falha mais dispendiosa, uma vez que permanece invisível até alguém reparar na lacuna.

A deteção de alterações também tem de lidar com atualizações a anúncios que já existem. Uma prorrogação de prazo, uma quantidade corrigida, um anúncio cancelado: estas são alterações a um registo já existente no sistema, e um agente precisa de distinguir um novo concurso de uma modificação a um já capturado.

Recuperação de erros: a parte ingrata que mais importa

As fontes ficam em baixo. As páginas carregam lentamente e expiram. O certificado de um portal expira por um dia. Uma alteração de disposição avaria silenciosamente o campo que antes continha o prazo. Nada disto é excecional; ao longo de meses de operação contínua em centenas de fontes, é a base diária. O que separa uma monitorização de confiança de uma monitorização que apodrece discretamente é a forma como a falha é tratada.

Um agente bem construído não falha em silêncio. Quando uma fonte não pode ser alcançada, ou os dados extraídos parecem estruturalmente errados (um campo de prazo vazio, uma lista a devolver zero resultados quando habitualmente devolve dezenas), a falha é sinalizada para que um humano ou uma verificação a jusante possa apanhar um conector avariado antes de este produzir semanas de dados em falta. Um sistema que falha em silêncio é pior do que nenhuma monitorização, uma vez que cria uma falsa confiança de que um mercado está a ser vigiado quando não está.

Porque é que o determinístico vence o generativo na recolha

É tentador apontar um modelo de linguagem de uso geral a um portal e pedir-lhe que extraia o que quer que pareça um concurso. Para uma leitura pontual, isto pode funcionar razoavelmente bem. Como motor por trás de uma monitorização diária, sem supervisão, em centenas de fontes, é a ferramenta errada. Um modelo generativo pode parafrasear um prazo, ler mal uma moeda, ou produzir uma resposta plausível mas errada sem qualquer sinal de que algo correu mal, e fá-lo de forma inconsistente, pelo que a mesma página pode ser lida corretamente um dia e incorretamente no seguinte.

A extração determinística, um conector que procura sempre no mesmo sítio o mesmo campo na mesma estrutura, é aborrecida em comparação. É também previsível, testável e, criticamente, falha de formas que são detetáveis, em vez de formas que corrompem discretamente os dados. Os modelos generativos continuam a ter um papel real neste fluxo, em particular na leitura de um concurso depois de este ter sido recolhido de forma fiável e no juízo sobre se é relevante para uma dada empresa. Recolher o facto puro de um anúncio e o seu prazo é uma tarefa estreita e repetitiva em que a lógica determinística é mais de confiança do que um modelo a adivinhar a estrutura.

Onde isto se encaixa num fluxo de trabalho de concursos

Nada disto substitui o discernimento sobre que concursos valem a pena prosseguir. Substitui o trabalho manual e repetitivo de os encontrar em primeiro lugar. A TRINTA lê o que uma empresa vende e faz sobressair os concursos correspondentes de fontes oficiais diariamente, usando por baixo exatamente este tipo de camada de conectores continuamente monitorizada.