[ blog · tutorial ]10 min read

Cómo construir un agente de revisión bibliográfica científica sin que te limiten la tasa de peticiones

Sarah Choy·Publicado el 3 de mayo de 2026·10 min de lectura

Monta hoy un agente de revisión bibliográfica sobre arXiv + PubMed + Semantic Scholar en crudo y te chocarás con 429s antes de terminar diez papers. Aquí va por qué los límites de tasa empeoraron, qué hacen de verdad PaperQA / Undermind por dentro y un patrón funcional que sobrevive a una sesión de revisión real.

Resumen

• •arXiv empezó a aplicar throttling agresivo a finales de 2024 después de que los scrapers de LLM provocaran tormentas de 429; el límite documentado es 1 petición cada 3 segundos, pero la tolerancia real a ráfagas es menor.
• •Las 1.000 req/seg de Semantic Scholar son compartidas entre todos los llamantes sin autenticar — en la práctica, inutilizable para agentes en producción.
• •PubMed E-utils limita el tráfico sin autenticar a 3 req/seg; con una API key, 10 req/seg.
• •Los agentes que funcionan (PaperQA2, Undermind, Elicit) usan todos una capa de proxy / caché delante de estas fuentes.
• •API Pick Academic Search envuelve arXiv, PubMed, bioRxiv y medRxiv en un único endpoint con la tasa gestionada — 5 créditos por llamada, solo al éxito.

El problema en un párrafo

Las APIs académicas gratuitas son maravillosas y se las están comiendo vivas. arXiv, PubMed y Semantic Scholar se diseñaron en una época en la que "un investigador escribe un script que sondea cada pocos segundos" era el peor caso de carga. Hoy cada estudiante de grado con Python escribe un agente LLM que dispara cincuenta llamadas paralelas para leer las referencias de un solo paper. Multiplica por miles de agentes parecidos y obtienes el patrón que el personal de arXiv describe en X como el "arXiv-pocalypse" de finales de 2024 — respuestas Rate Exceeded sostenidas, servicio degradado y una oleada de nuevas reglas de throttling que golpean a los desarrolladores indie más fuerte que a los malos actores.

El resultado: un agente de revisión bibliográfica que funciona con cinco papers en el entorno de desarrollo se cae a mitad de una sesión de revisión real. El usuario recibe una respuesta a medias con tres citas en lugar de quince.

Este artículo trata de cómo construir el agente para que eso no pase.

Qué tiene límite de tasa de verdad y dónde

Qué hacen de verdad los productos que funcionan

PaperQA2, Undermind, Elicit, ResearchRabbit y los papers de RAG agéntico (p. ej. Open-Source Agentic Hybrid RAG Framework, arXiv 2508.05660) convergen todos en un patrón parecido. Tres movimientos de ingeniería son los que más importan:

1. Cachea por DOI / arXiv ID, no por query

El mismo paper lo piden muchas queries distintas. Cachear a nivel de resultado de búsqueda apenas ayuda; cachear a nivel de identificador de paper sí. Una pequeña capa de Redis (o incluso SQLite) indexada por doi:10.1038/... se amortiza en una tarde de tráfico de agente.

2. Trata el grafo de citaciones como el índice de cambio lento

La fortaleza de Semantic Scholar no es la búsqueda por palabras clave; es el grafo de citaciones. PaperQA2 lo usa para expandir de un paper semilla a un clúster relacionado, no para descubrir papers desde cero. Eso es un volumen de peticiones mucho menor — una llamada por paper, no cientos — y se mantiene muy por debajo del límite de tasa.

3. Acepta la latencia como compromiso, O proxea el límite de tasa

O bien haces esperar a los usuarios 30-60 segundos por una query cuidadosa y respetuosa con el throttle (la elección de PaperQA2), o bien añades una capa que agrega el tráfico entre usuarios y presenta una única interfaz tolerante a ráfagas al agente (la elección de API Pick). Las dos funcionan. Mezclarlas — una UX de baja latencia sobre APIs públicas con límite de tasa sin un buffer — es lo que falla.

Código que funciona: un agente bibliográfico que termina

El agente mínimo viable que sobrevive a una sesión de revisión 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)"))

Coste por pregunta:

• 1-2 llamadas a academic_search (5-10 créditos = $0.005-$0.010)
• 1 llamada a extract que cubre 3-5 papers (6-10 créditos = $0.006-$0.010)
• ~5.000 tokens de entrada + 1.200 de salida a Claude (~$0.04)

En números redondos: ~5 centavos por respuesta de revisión bibliográfica con citas. A 100 preguntas/día son $5/día — más o menos lo que cuesta la cafeína diaria de un investigador razonable.

Ajustes por subvertical

Literatura biomédica

Sesga el agente hacia PubMed (revisado por pares) y marca explícitamente como preprints los hits de bioRxiv/medRxiv. Cuando preguntes "qué dice la última evidencia", el agente debería ponderar más alto lo revisado por pares. Una línea en el system prompt — "Si las fuentes preprint y revisadas por pares discrepan, da prioridad a las revisadas por pares y señala la discrepancia" — resuelve esto limpiamente.

Matemáticas / CS

Aquí domina arXiv. La relación señal-ruido es mejor que en biomedicina, y para el trabajo fundacional las citaciones importan más que la novedad. Busca con queries más amplias y deja que el agente pode.

Descubrimiento de fármacos / clínico

Combínalo con Clinical Search (ClinicalTrials.gov + etiquetas de la FDA + ChEMBL + DrugBank) para las dimensiones regulatoria y de bioactividad que la búsqueda académica no puede cubrir. La combinación — literatura revisada por pares + registro de ensayos + datos estructurales — es lo que hace útil a un agente de reposicionamiento de fármacos o de farmacovigilancia.

Dónde generaliza esto

El problema del límite de tasa no es exclusivo de la búsqueda académica. Cualquier conjunto de datos público y abierto que sacara APIs en la era pre-LLM está sometido ahora a los mismos patrones de carga: SEC EDGAR, USPTO, EPO, bases de datos de registros públicos, servicios meteorológicos, datos abiertos gubernamentales. El mismo patrón de ingeniería sirve para todos ellos — cachear a nivel de entidad, poner una capa de proxy gestionado, aceptar la latencia como alternativa cuando no puedes permitirte el proxy.

El cambio de fondo: en 2026 ya no es razonable esperar que una API pública gratuita absorba directamente la carga de un agente LLM. Los endpoints no van a desaparecer — pero los está envolviendo una capa de servicios gestionados de pago que existe para traducir los límites de tasa de "investigador humano educado" en tráfico de "agente tolerante a ráfagas". API Pick Academic Search es una de esas capas para el caso de uso de revisión bibliográfica. Habrá más.

Escrito por

Sarah Choy

CEO, API Pick

Sarah Choy es la CEO de API Pick. Escribe sobre cómo construir APIs listas para producción para agentes de IA y flujos de trabajo con LLMs.