[ blog · tutorial ]10 min read

Como construir um agente de revisão de literatura científica sem esbarrar em rate limits

Sarah Choy·Publicado em 3 de maio de 2026·10 min de leitura

Monte hoje um agente de revisão de literatura sobre arXiv + PubMed + Semantic Scholar no estado bruto e você vai esbarrar em 429s antes de terminar dez papers. Veja por que os rate limits pioraram, o que PaperQA / Undermind realmente fazem por baixo dos panos e um padrão funcional que sobrevive a uma sessão de revisão real.

TL;DR

• •O arXiv começou a aplicar throttling agressivo no fim de 2024 depois que scrapers de LLM provocaram tempestades de 429; o limite documentado é 1 requisição a cada 3 segundos, mas a tolerância real a rajadas é menor.
• •As 1.000 req/seg do Semantic Scholar são compartilhadas entre todos os chamadores não autenticados — na prática, inutilizáveis para agentes em produção.
• •O PubMed E-utils limita o tráfego não autenticado a 3 req/seg; com uma API key, 10 req/seg.
• •Os agentes que funcionam (PaperQA2, Undermind, Elicit) usam todos uma camada de proxy / cache na frente dessas fontes.
• •O API Pick Academic Search envolve arXiv, PubMed, bioRxiv e medRxiv em um único endpoint com a taxa gerenciada — 5 créditos por chamada, somente no sucesso.

O problema em um parágrafo

As APIs acadêmicas gratuitas são maravilhosas e estão sendo devoradas vivas. arXiv, PubMed e Semantic Scholar foram projetados em uma época em que "um pesquisador escreve um script que faz polling a cada poucos segundos" era o pior caso de carga. Hoje cada estudante de graduação com Python escreve um agente LLM que dispara cinquenta chamadas paralelas para ler as referências de um único paper. Multiplique por milhares de agentes parecidos e você obtém o padrão que a equipe do arXiv descreve no X como o "arXiv-pocalypse" do fim de 2024 — respostas Rate Exceeded sustentadas, serviço degradado e uma onda de novas regras de throttling que atingem os desenvolvedores indie mais forte do que os maus atores.

O resultado: um agente de revisão de literatura que funciona com cinco papers no ambiente de desenvolvimento desaba no meio de uma sessão de revisão real. O usuário recebe uma resposta pela metade, com três citações em vez de quinze.

Este artigo é sobre como construir o agente para que isso não aconteça.

O que tem rate limit de verdade e onde

O que os produtos que funcionam realmente fazem

PaperQA2, Undermind, Elicit, ResearchRabbit e os papers de RAG agêntico (p. ex. Open-Source Agentic Hybrid RAG Framework, arXiv 2508.05660) convergem todos para um padrão parecido. Três movimentos de engenharia são os que mais importam:

1. Faça cache por DOI / arXiv ID, não por query

O mesmo paper é pedido por muitas queries diferentes. Fazer cache no nível de resultado de busca quase não ajuda; fazer cache no nível de identificador de paper ajuda. Uma pequena camada de Redis (ou até SQLite) indexada por doi:10.1038/... se paga em uma tarde de tráfego de agente.

2. Trate o grafo de citações como o índice de mudança lenta

A força do Semantic Scholar não é a busca por palavras-chave; é o grafo de citações. O PaperQA2 o usa para expandir de um paper-semente a um cluster relacionado, não para descobrir papers do zero. Isso é um volume de requisições muito menor — uma chamada por paper, não centenas — e fica bem abaixo do rate limit.

3. Aceite a latência como trade-off, OU faça proxy do rate limit

Ou você faz os usuários esperarem 30-60 segundos por uma query cuidadosa e respeitosa com o throttle (a escolha do PaperQA2), ou você adiciona uma camada que agrega o tráfego entre usuários e apresenta uma única interface tolerante a rajadas para o agente (a escolha do API Pick). As duas funcionam. Misturá-las — uma UX de baixa latência sobre APIs públicas com rate limit sem um buffer — é o que falha.

Código que funciona: um agente de literatura que conclui

O agente mínimo viável que sobrevive a uma sessão de revisão real:

import requests
from anthropic import Anthropic

KEY = "pk_yourkey"
client = Anthropic()

def fetch_tool(path: str) -> dict:
    return requests.get(f"https://www.apipick.com{path}/tool-schema").json()["claude"]

# Two tools: academic search + URL extract for the full body
TOOLS = [
    fetch_tool("/api/search/academic"),
    fetch_tool("/api/extract"),
]

SYSTEM = """You are a literature-review research assistant. Process:

1. Use academic_search with the user's question to find relevant papers
   from arXiv, PubMed, bioRxiv, and medRxiv. One call usually returns
   the right set of seed papers.

2. For papers worth citing in detail, use extract_urls on the paper's URL
   to pull the body. Batch up to 5 URLs per call.

3. Answer the user's question with inline citations in the form
   [Author Year, doi/arxiv URL]. Quote findings verbatim where possible.

4. If the search returned <3 substantive results, expand the query and
   try once more. Don't loop indefinitely — say "I couldn't find a strong
   answer in the indexed literature" if nothing matches.

Be precise. Cite every factual claim. Distinguish preprints (arXiv,
bioRxiv, medRxiv) from peer-reviewed (PubMed) when it matters."""

def call_tool(block):
    name_to_path = {"academic_search": "/api/search/academic", "extract_urls": "/api/extract"}
    r = requests.post(
        f"https://www.apipick.com{name_to_path[block.name]}",
        json=block.input,
        headers={"x-api-key": KEY},
        timeout=60,
    )
    return {"type": "tool_result", "tool_use_id": block.id,
            "content": r.text, "is_error": r.status_code != 200}

def review(question: str) -> str:
    msgs = [{"role": "user", "content": question}]
    while True:
        r = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=4096,
            system=SYSTEM,
            tools=TOOLS,
            messages=msgs,
        )
        msgs.append({"role": "assistant", "content": r.content})
        if r.stop_reason == "end_turn":
            return "\n".join(b.text for b in r.content if b.type == "text")
        if r.stop_reason == "tool_use":
            results = [call_tool(b) for b in r.content if b.type == "tool_use"]
            msgs.append({"role": "user", "content": results})

print(review("Recent advances in LLM-based protein structure prediction (2025)"))

Custo por pergunta:

• 1-2 chamadas a academic_search (5-10 créditos = $0.005-$0.010)
• 1 chamada a extract cobrindo 3-5 papers (6-10 créditos = $0.006-$0.010)
• ~5.000 tokens de entrada + 1.200 de saída para o Claude (~$0.04)

Em números redondos: ~5 centavos por resposta de revisão de literatura com citações. A 100 perguntas/dia são $5/dia — mais ou menos o que custa a cafeína diária de um pesquisador razoável.

Ajustes por subvertical

Literatura biomédica

Enviese o agente para o PubMed (revisado por pares) e marque explicitamente como preprints os hits de bioRxiv/medRxiv. Ao perguntar "o que diz a evidência mais recente", o agente deve dar peso maior ao que foi revisado por pares. Uma linha no system prompt — "Se as fontes preprint e revisadas por pares discordarem, dê prioridade às revisadas por pares e aponte a discrepância" — resolve isso de forma limpa.

Matemática / CS

Aqui o arXiv domina. A relação sinal-ruído é melhor do que na biomedicina, e para o trabalho fundacional as citações importam mais do que a novidade. Busque com queries mais amplas e deixe o agente podar.

Descoberta de fármacos / clínico

Combine com o Clinical Search (ClinicalTrials.gov + rótulos da FDA + ChEMBL + DrugBank) para as dimensões regulatória e de bioatividade que a busca acadêmica não consegue cobrir. A combinação — literatura revisada por pares + registro de ensaios + dados estruturais — é o que torna útil um agente de reposicionamento de fármacos ou de farmacovigilância.

Onde isso generaliza

O problema do rate limit não é exclusivo da busca acadêmica. Qualquer conjunto de dados público e aberto que lançou APIs na era pré-LLM está sendo submetido aos mesmos padrões de carga agora: SEC EDGAR, USPTO, EPO, bancos de dados de registros públicos, serviços meteorológicos, dados abertos governamentais. O mesmo padrão de engenharia serve para todos eles — fazer cache no nível de entidade, colocar uma camada de proxy gerenciado, aceitar a latência como alternativa quando você não pode bancar o proxy.

A mudança mais profunda: em 2026 já não é razoável esperar que uma API pública gratuita absorva diretamente a carga de um agente LLM. Os endpoints não vão desaparecer — mas estão sendo envolvidos por uma camada de serviços gerenciados pagos que existe para traduzir os rate limits de "pesquisador humano educado" em tráfego de "agente tolerante a rajadas". O API Pick Academic Search é uma dessas camadas para o caso de uso de revisão de literatura. Espere mais.

Escrito por

Sarah Choy

CEO, API Pick

Sarah Choy é a CEO da API Pick. Ela escreve sobre a construção de APIs prontas para produção para agentes de IA e fluxos de trabalho com LLMs.