[ blog · tutorial ]10 min read

Comment construire un agent de revue de littérature scientifique sans se faire rate-limiter

Sarah Choy·Publié le 3 mai 2026·10 min de lecture

Construisez un agent de revue de littérature directement sur arXiv + PubMed + Semantic Scholar aujourd'hui et vous prendrez des 429 avant d'avoir traité dix articles. Voici pourquoi les rate limits se sont durcis, ce que font réellement PaperQA / Undermind en interne, et un pattern qui survit à une vraie session de revue.

L'essentiel

• •arXiv a commencé à throttler agressivement fin 2024 après que les scrapers LLM ont déclenché des tempêtes de 429 ; la limite documentée est de 1 requête toutes les 3 secondes, mais la tolérance réelle aux bursts est plus basse.
• •Les 1 000 req/s de Semantic Scholar sont partagés entre tous les appelants non authentifiés — concrètement inutilisable pour des agents en production.
• •PubMed E-utils plafonne le trafic non authentifié à 3 req/s ; avec une clé API, 10 req/s.
• •Les agents qui fonctionnent (PaperQA2, Undermind, Elicit) utilisent tous une couche de proxy / cache devant ces sources.
• •API Pick Academic Search enveloppe arXiv, PubMed, bioRxiv et medRxiv dans un seul endpoint à débit géré — 5 crédits par appel, uniquement en cas de succès.

Le problème en un paragraphe

Les API académiques gratuites sont formidables et elles se font dévorer vivantes. arXiv, PubMed et Semantic Scholar ont été conçues à une époque où « un chercheur écrit un script qui interroge l'API toutes les quelques secondes » représentait la charge du pire cas. Aujourd'hui, chaque étudiant qui connaît Python écrit un agent LLM qui lance cinquante appels en parallèle pour lire les références d'un seul article. Multipliez par des milliers d'agents similaires et vous obtenez le phénomène que l'équipe d'arXiv décrit sur X comme l'« arXiv-pocalypse » de fin 2024 — des réponses Rate Exceeded en continu, un service dégradé, et une vague de nouvelles règles de throttling qui frappent les indie builders plus durement que les acteurs malveillants.

Le résultat : un agent de revue de littérature qui marche sur cinq articles en environnement de dev s'effondre au milieu d'une vraie session de revue. L'utilisateur récupère une réponse à moitié finie avec trois citations au lieu de quinze.

Cet article explique comment construire l'agent pour que ça n'arrive pas.

Ce qui est réellement rate-limité, et où

Ce que font réellement les produits qui marchent

PaperQA2, Undermind, Elicit, ResearchRabbit et les articles sur le RAG agentique (par exemple Open-Source Agentic Hybrid RAG Framework, arXiv 2508.05660) convergent tous vers un schéma similaire. Trois choix d'ingénierie comptent le plus :

1. Mettez en cache par DOI / arXiv ID, pas par requête

Le même article est demandé par de nombreuses requêtes différentes. Mettre en cache au niveau du résultat de recherche n'aide presque pas ; mettre en cache au niveau de l'identifiant d'article, si. Une petite couche Redis (ou même SQLite) indexée sur doi:10.1038/... est rentabilisée en une après-midi de trafic d'agent.

2. Traitez le graphe de citations comme l'index à évolution lente

La force de Semantic Scholar n'est pas la recherche par mots-clés ; c'est le graphe de citations. PaperQA2 l'utilise pour partir d'un article-germe et s'étendre à un cluster d'articles liés, pas pour découvrir des articles à partir de rien. C'est un volume de requêtes bien plus faible — un appel par article, pas des centaines — et ça reste largement sous le rate limit.

3. Acceptez la latence comme compromis, OU proxifiez le rate limit

Soit vous faites attendre l'utilisateur 30 à 60 secondes pour une requête soignée qui respecte le throttling (le choix de PaperQA2), soit vous ajoutez une couche qui agrège le trafic de tous les utilisateurs et présente à l'agent une interface unique tolérante aux bursts (le choix API Pick). Les deux fonctionnent. Mélanger les deux — une UX à faible latence par-dessus des API publiques rate-limitées sans tampon — c'est ce qui échoue.

Code qui marche : un agent de littérature qui va au bout

L'agent minimal viable qui survit à une vraie session de revue :

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)"))

Coût par question :

• 1 à 2 appels academic_search (5-10 crédits = $0.005-$0.010)
• 1 appel extract couvrant 3 à 5 articles (6-10 crédits = $0.006-$0.010)
• ~5 000 tokens d'entrée + 1 200 de sortie vers Claude (~$0.04)

En chiffre rond : ~5 centimes par réponse de revue de littérature avec citations. À 100 questions/jour, cela fait $5/jour — à peu près ce que coûte la caféine quotidienne d'un chercheur raisonnable.

Ajustements par sous-vertical

Littérature biomédicale

Biaisez l'agent vers PubMed (relu par les pairs) et marquez explicitement les résultats bioRxiv/medRxiv comme des preprints. Quand on demande « que dit la dernière évidence en date », l'agent devrait pondérer plus fort le relu par les pairs. Une ligne dans le system prompt — « Si des sources preprint et relues par les pairs divergent, privilégier le relu par les pairs et signaler l'écart » — règle ça proprement.

Mathématiques / informatique

arXiv domine ici. Le rapport signal/bruit est meilleur qu'en biomédical, et pour les travaux fondamentaux les citations comptent plus que la récence. Lancez des requêtes plus larges et laissez l'agent élaguer.

Découverte de médicaments / clinique

Couplez avec Clinical Search (ClinicalTrials.gov + étiquettes FDA + ChEMBL + DrugBank) pour les dimensions réglementaires et de bioactivité que la recherche académique ne peut pas couvrir. La combinaison — littérature relue par les pairs + registre d'essais + données structurelles — c'est ainsi qu'un agent de repositionnement de médicaments ou de pharmacovigilance devient utile.

Où cela se généralise

Le problème du rate limit n'est pas propre à la recherche académique. Tout dataset public ouvert ayant livré ses API à l'ère pré-LLM subit aujourd'hui les mêmes schémas de charge : SEC EDGAR, USPTO, EPO, bases de registres publics, services météo, données ouvertes gouvernementales. Le même pattern d'ingénierie fonctionne pour tous : mettre en cache au niveau de l'entité, intercaler un proxy géré, accepter la latence comme alternative quand on ne peut pas s'offrir le proxy.

Le glissement plus profond : en 2026, il n'est plus raisonnable d'attendre d'une API publique gratuite qu'elle absorbe directement la charge d'un agent LLM. Les endpoints ne disparaissent pas — mais ils se font envelopper par une couche de services managés payants dont la raison d'être est de traduire des rate limits de « chercheur humain courtois » en « trafic d'agent tolérant aux bursts ». API Pick Academic Search est l'une de ces couches pour le cas d'usage de la revue de littérature. Attendez-vous à en voir d'autres.

Écrit par

Sarah Choy

CEO, API Pick

Sarah Choy est CEO d'API Pick. Elle écrit sur la création d'APIs prêtes pour la production destinées aux agents IA et aux workflows LLM.