[ blog · tutorial ]10 min read

Wie man einen Agenten für wissenschaftliche Literaturrecherche baut, ohne ins Rate-Limit zu laufen

Sarah Choy·Veröffentlicht am 3. Mai 2026·10 Min. Lesezeit

Bau heute einen Literaturrecherche-Agenten auf rohem arXiv + PubMed + Semantic Scholar, und du läufst in 429er, bevor du zehn Paper durch hast. Hier steht, warum die Rate-Limits schlimmer wurden, was PaperQA / Undermind unter der Haube wirklich tun, und ein funktionierendes Muster, das eine echte Recherche-Session übersteht.

Auf einen Blick

• •arXiv begann Ende 2024 aggressiv zu drosseln, nachdem LLM-Scraper 429er-Stürme auslösten; das dokumentierte Limit liegt bei 1 Request alle 3 Sekunden, doch die reale Burst-Toleranz ist niedriger.
• •Semantic Scholars 1.000 Req/Sek werden über alle nicht authentifizierten Aufrufer geteilt — für produktive Agenten praktisch unbrauchbar.
• •PubMed E-utils deckelt nicht authentifizierten Traffic bei 3 Req/Sek; mit API-Key 10 Req/Sek.
• •Funktionierende Agenten (PaperQA2, Undermind, Elicit) setzen alle eine Proxy- / Cache-Schicht vor diese Quellen.
• •API Pick Academic Search bündelt arXiv, PubMed, bioRxiv und medRxiv in einem rate-gemanagten Endpoint — 5 Credits pro Aufruf, nur bei Erfolg.

Das Problem in einem Absatz

Kostenlose akademische APIs sind wunderbar — und sie werden bei lebendigem Leib gefressen. arXiv, PubMed und Semantic Scholar wurden in einer Zeit entworfen, in der 'ein Forscher schreibt ein Skript, das alle paar Sekunden pollt' der Worst-Case-Load war. Heute schreibt jeder Bachelor-Student mit Python einen LLM-Agenten, der fünfzig parallele Calls auffächert, um die Referenzen eines einzigen Papers zu lesen. Multipliziere das mit Tausenden ähnlichen Agenten und du bekommst das Muster, das arXiv-Mitarbeiter auf X als die „arXiv-pocalypse“ Ende 2024 beschreiben — anhaltende Rate-Exceeded-Responses, degradierter Service und eine Welle neuer Drosselungsregeln, die Indie-Builder härter trafen als die echten Übeltäter.

Das Ergebnis: ein Literaturrecherche-Agent, der in der Dev-Umgebung mit fünf Papern funktioniert, kippt mitten in einer echten Recherche-Session um. Der Nutzer bekommt eine halbfertige Antwort mit drei statt fünfzehn Zitaten.

In diesem Artikel geht es darum, den Agenten so zu bauen, dass das nicht passiert.

Was tatsächlich rate-limitiert ist und wo

Was funktionierende Produkte tatsächlich tun

PaperQA2, Undermind, Elicit, ResearchRabbit und die Paper zu agentischem RAG (z. B. Open-Source Agentic Hybrid RAG Framework, arXiv 2508.05660) konvergieren alle auf ein ähnliches Muster. Drei Engineering-Schritte zählen am meisten:

1. Cache nach DOI / arXiv-ID, nicht nach Query

Dasselbe Paper wird von vielen verschiedenen Queries angefragt. Cachen auf Ebene der Suchergebnisse hilft kaum; Cachen auf Ebene der Paper-Identifier schon. Eine kleine Redis- (oder sogar SQLite-) Schicht, gekeyt auf doi:10.1038/..., amortisiert sich in einem Nachmittag Agenten-Traffic.

2. Behandle den Zitationsgraph als langsam veränderlichen Index

Die Stärke von Semantic Scholar ist nicht die Keyword-Suche; es ist der Zitationsgraph. PaperQA2 nutzt ihn, um von einem Seed-Paper auf ein verwandtes Cluster zu expandieren, nicht um Paper von Grund auf zu entdecken. Das ist ein viel kleineres Request-Volumen — ein Call pro Paper, nicht Hunderte — und bleibt deutlich unter dem Rate-Limit.

3. Akzeptiere Latenz als den Trade-off, ODER proxy das Rate-Limit

Entweder lässt du Nutzer 30–60 Sekunden auf eine sorgfältige, drosselungsbewusste Query warten (PaperQA2s Wahl), oder du fügst eine Schicht hinzu, die Traffic über Nutzer hinweg aggregiert und dem Agenten eine einzige burst-tolerante Schnittstelle präsentiert (die API-Pick-Wahl). Beides funktioniert. Das Mischen — eine latenzarme UX über rate-limitierten öffentlichen APIs ohne Puffer — ist das, was scheitert.

Funktionierender Code: ein Literatur-Agent, der zu Ende läuft

Der minimal lauffähige Agent, der eine echte Recherche-Session übersteht:

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

Kosten pro Frage:

• 1–2 academic_search-Calls (5–10 Credits = $0.005–$0.010)
• 1 extract-Call über 3–5 Paper (6–10 Credits = $0.006–$0.010)
• ~5.000 Input- + 1.200 Output-Tokens an Claude (~$0.04)

Runde Zahl: ~5 Cent pro Literaturrecherche-Antwort mit Zitaten. Bei 100 Fragen/Tag sind das $5/Tag — etwa so viel wie der tägliche Koffeinbedarf eines vernünftigen Forschers.

Anpassungen je Sub-Vertikale

Biomedizinische Literatur

Lenke den Agenten Richtung PubMed (peer-reviewed) und markiere bioRxiv-/medRxiv-Treffer explizit als Preprints. Bei der Frage „was sagt die neueste Evidenz“ sollte der Agent peer-reviewed höher gewichten. Eine Zeile im System-Prompt — „Widersprechen sich Preprint- und peer-reviewed-Quellen, gib der peer-reviewed-Quelle den Vorrang und vermerke die Diskrepanz“ — erledigt das sauber.

Mathematik / CS

Hier dominiert arXiv. Das Signal-Rausch-Verhältnis ist besser als in der Biomedizin, und Zitate zählen bei Grundlagenarbeiten mehr als Aktualität. Suche mit breiteren Queries und lass den Agenten ausdünnen.

Wirkstoffforschung / klinisch

Kombiniere mit Clinical Search (ClinicalTrials.gov + FDA-Labels + ChEMBL + DrugBank) für die regulatorischen und bioaktiven Dimensionen, die die akademische Suche nicht abdecken kann. Die Kombination — peer-reviewed Literatur + Studienregister + Strukturdaten — ist der Weg, wie ein Agent für Drug-Repurposing oder Pharmakovigilanz nützlich wird.

Wo sich das verallgemeinern lässt

Das Rate-Limit-Problem ist nicht einzigartig für die akademische Suche. Jeder offene öffentliche Datensatz, der seine APIs in der Prä-LLM-Ära ausgeliefert hat, ist heute denselben Last-Mustern ausgesetzt: SEC EDGAR, USPTO, EPO, Public-Records-Datenbanken, Wetterdienste, Open Data der Behörden. Dasselbe Engineering-Muster funktioniert für alle — auf Entitätsebene cachen, einen gemanagten Proxy davorlegen, Latenz als Alternative akzeptieren, wenn du dir den Proxy nicht leisten kannst.

Die tiefere Verschiebung: 2026 ist es nicht mehr vernünftig zu erwarten, dass eine kostenlose öffentliche API LLM-Agenten-Last direkt absorbiert. Die Endpoints verschwinden nicht — aber sie werden von einer Schicht bezahlter, gemanagter Dienste umhüllt, deren Zweck es ist, „höfliche menschliche Forscher“-Rate-Limits in „burst-toleranten Agenten-Traffic“ zu übersetzen. API Pick Academic Search ist eine dieser Schichten für den Literaturrecherche-Anwendungsfall. Erwarte mehr davon.

Geschrieben von

Sarah Choy

CEO, API Pick

Sarah Choy ist CEO von API Pick. Sie schreibt über produktionsreife APIs für KI-Agenten und LLM-Workflows.