Arquitetura de infraestrutura para reduzir custos de proxy e tokens em implantações de produção do Agent-Reach
makedream١٩ يونيو ٢٠٢٦
0
Computing/Software
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
Agentes baseados em Agent-Reach que funcionam bem em um CLI local frequentemente encontram obstáculos ao serem implantados em servidores de produção. Quando dezenas de milhares de solicitações de scraping chegam simultaneamente, as redes de segurança de CDN, como a Cloudflare, bloqueiam os IPs um após o outro. No entanto, insistir apenas em proxies residenciais pagos torna os custos de largura de banda insustentáveis. Além disso, injetar HTML bruto diretamente no LLM pode estourar o contexto e causar faturas exorbitantes de tokens. Para resolver esses problemas, são necessárias uma arquitetura de roteamento dinâmico e um pipeline de pré-processamento.
Operar o Agent-Reach sem proteção pode resultar em gastos de milhares de dólares apenas com proxies residenciais. Em um sistema que processa 100.000 solicitações por dia, com um tamanho médio de página de 150 KB e uma taxa de falha de até 50%, o volume mensal de transferência de dados atinge 675 GB. Proxies residenciais premium, como Bright Data ou Oxylabs, custam entre 4 e 8 dólares por GB. Encaminhar todo o tráfego por eles faria os custos mensais dispararem para 5.400 dólares.
Ao implantar o Scrapoxy, um agregador de proxy open-source, como um super proxy baseado em contêiner Docker, é possível controlar os custos de infraestrutura mantendo um único endpoint. Primeiro, crie um arquivo docker-compose.yml na raiz do projeto e defina as imagens valkey/valkey:7.2-alpine e fabienvauchelles/scrapoxy:latest. No contêiner Valkey, especifique o comando --appendonly yes --requirepass [senha] para garantir a persistência do cache de credenciais. Após definir o nome de usuário e a senha nas variáveis de ambiente do Scrapoxy, inicie os contêineres com o comando docker compose up -d. Essa configuração pode economizar mais de 200 dólares por mês em taxas de assinatura de serviços pagos.
Para evitar a quebra de sessões, o ciclo de rotação de IP deve ser diferenciado de acordo com a política de segurança da plataforma de destino. Para solicitações públicas de leitura (Read-Only) que não exigem autenticação, configure um TTL agressivo entre 30 segundos e 3 minutos, forçando a alocação de um novo IP a cada vez em um esquema round-robin. Esta medida visa evitar o bloqueio baseado em limites de taxa. Por outro lado, para plataformas baseadas em autenticação que exigem a manutenção de cookies de sessão, como X ou Reddit, ative a funcionalidade de injeção de cookies do Scrapoxy para fixar o mesmo nó de IP residencial por 5 a 10 minutos. Isso evita que a sessão de autenticação expire devido a uma mudança repentina no IP geográfico.
Para reduzir ainda mais os custos, o roteamento de tráfego deve ser otimizado na camada de gateway de API NGINX. No bloco upstream do arquivo de configuração do NGINX (/etc/nginx/nginx.conf), defina pools de proxy de data center de baixo custo (como DataImpulse, que custa cerca de 1 dólar por GB) e os pools de proxy residencial do Scrapoxy separadamente. Crie um location /fetch/generic/ dentro do bloco server para encaminhar tráfego HTML público de baixa segurança, como feeds RSS ou pesquisas do GitHub, para o proxy de data center. Em seguida, crie um location /fetch/social/ para rotear apenas solicitações de endpoints sociais de alta fricção para o backend do Scrapoxy com injeção de cabeçalhos. A aplicação deste roteamento de duas vias evita o desperdício de largura de banda em proxies residenciais caros e reduz os custos totais de proxy em até 90%.
Dados HTML brutos contêm elementos DOM redundantes, folhas de estilo e blocos de scripts inline. Inseri-los diretamente no LLM consome tokens desnecessários e obscurece os resultados da inferência. Converter páginas da web originais em Markdown antes de injetá-las na janela de contexto reduz o tamanho dos dados entre 75% e 90%. Realizar a limpeza baseada em expressões regulares e a serialização para Markdown na etapa de pré-processamento do pipeline pode reduzir o consumo de tokens da API do LLM em mais de 40%, prevenindo erros de estouro de janela.
Implemente uma função Python para pré-processar os dados de entrada combinando os componentes de parsing Trafilatura e html2text. Ao chamar trafilatura.extract(), defina a opção favor_recall=False para excluir barras laterais ou anúncios e extrair apenas o texto principal. Para casos em que a extração do bloco de conteúdo principal falhar, insira um código de fallback que cria um objeto html2text.HTML2Text() com ignore_images=True e body_width=0. A execução de uma rotina de limpeza, utilizando expressões regulares (re.sub) para remover tags residuais como <script> e <style> e reduzir linhas em branco consecutivas, diminui a latência de resposta do agente.
Ao dividir documentos longos, em vez de usar uma fragmentação simples baseada na contagem de caracteres, deve-se adotar um algoritmo de segmentação que preserve o contexto com base na similaridade semântica. Calcule a similaridade de cosseno entre os vetores de embedding do texto dividido em frases para identificar os pontos de ruptura semântica.
Similarity(u, v) = rac{u cdot v}{\|u\| \|v\|}Após calcular a distância entre frases adjacentes, estabeleça como ponto de segmentação semântica a fronteira onde a diferença de distância excede o percentil 95 de todo o documento. A aplicação da segmentação semântica, em vez do método de fragmentação de comprimento fixo, evita a perda de informações relacionadas ao dividi-las em diferentes blocos e melhora a precisão da recuperação de informações pelo LLM.
Plataformas como X ou LinkedIn possuem limites de velocidade rígidos, causando frequentes erros HTTP 429 ou 403. Em situações de falha temporária, se o processo da aplicação síncrona repetir a solicitação imediatamente, os recursos do servidor serão esgotados e o nível de bloqueio de IP aumentará. Para garantir a resiliência do sistema, é necessário um middleware de tratamento de exceções assíncrono que identifique a natureza da exceção e ajuste dinamicamente a carga imposta ao servidor de destino.
Ao projetar a classe de tratamento de erros, é preciso diferenciar claramente erros temporários de erros permanentes. Erros com códigos de status HTTP 429, 502, 503, 504 ou mensagens contendo 'timeout' ou 'connection refused' devem ser classificados como erros temporários e marcados para nova tentativa. Por outro lado, erros 401 ou 400 devem ser considerados permanentes e isolados imediatamente em uma Dead Letter Queue (DLQ). No caso de erros temporários, para evitar o problema de 'Thundering Herd' (manada trovejante) causado por um pico de solicitações simultâneas, aplique o algoritmo de espera exponencial (exponential backoff) incluindo um jitter aleatório em milissegundos. A fórmula para o cálculo do tempo de espera é a seguinte:
Ao definir o tempo de atraso base inicial () como 30 segundos e limitar o teto máximo () a 600 segundos, garante-se um tempo de espera distribuído de aproximadamente 240 segundos na terceira tentativa, contornando as políticas de bloqueio da plataforma de destino.
Para evitar falhas em cascata onde a indisponibilidade ou endurecimento de segurança de uma plataforma específica paralisa todo o fluxo de trabalho, implemente um padrão de anteparo (bulkhead) baseado em Redis na camada de middleware. Em vez de uma única fila global, crie listas Redis independentes separadas por domínio de destino (queue:bulkhead:twitter, queue:bulkhead:reddit, queue:bulkhead:general). Atribua limites de concorrência diferenciados para o pool de trabalhadores que consome cada fila, por exemplo, 3 para Twitter e 25 para Web Geral. Para gerenciar a programação de novas tentativas de tarefas falhas, escreva uma rotina de processamento de atraso usando um Sorted Set do Redis, registrando o timestamp de retorno como score. A aplicação dessa estrutura de anteparo garante que, mesmo que ocorra um bloqueio de API em uma mídia social específica, apenas o trabalhador correspondente entre em estado de espera, mantendo a taxa de sucesso de conclusão de tarefas de pesquisa do agente acima de 95%.
Dados brutos extraídos aleatoriamente de várias fontes da web contêm inconsistências de datas ou fatos falsos, facilitando a inferência distorcida por parte do LLM. Antes de fornecer contexto ao modelo de IA generativa, é necessário integrar na extremidade do pipeline uma camada de verificação descontínua que calcule a confiabilidade do conteúdo do arquivo Markdown e valide a consistência numérica para bloquear alucinações.
Projete uma classe de filtro determinístico que calcule a validade temporal e o peso por fonte de plataforma dos metadados coletados. Documentos que contenham timestamps futuros em relação à hora do sistema ou datas em formato ISO inválido devem ser excluídos do conjunto de dados imediatamente. Além disso, declare um dicionário que mapeie pesos de confiança por fonte: 0,95 para GitHub, 0,90 para Wikipedia, atribuindo pontuações básicas mais baixas para mídias sociais como Reddit (0,50) ou Twitter (0,40). Aplique uma lógica que adiciona um bônus de peso de metadados de 0,05 apenas se o nome do autor e o título estiverem preservados no documento para gerar a pontuação de confiança final. Ativos de informação com pontuação abaixo do limite são excluídos da etapa de montagem de prompts do LLM.
Para garantir a qualidade dos dados de saída, execute um script de pontuação que contraste os candidatos a resposta gerados com o contexto original:
\b\d+(?:\.\d+)?%?\b) para realizar uma operação de interseção entre os conjuntos de números presentes no conjunto de dados original e no texto gerado. Se forem detectados valores numéricos ou unidades monetárias arbitrárias que não existiam na fonte, gere um flag de inconsistência numérica e solicite imediatamente uma reexecução via middleware de roteamento.Ao integrar essas camadas de verificação multinível, é possível bloquear, em nível de arquitetura, problemas de manipulação numérica e citações falsas cometidos por agentes baseados em crawling, entregando ao usuário final apenas resultados de pesquisa totalmente verificados.