[ blog · tutorial ]10 min read

Jak zbudować agenta do przeglądu literatury naukowej bez wpadania w limity zapytań

Sarah Choy·Opublikowano 3 maja 2026·10 min czytania

Zbuduj dziś agenta do przeglądu literatury na surowych arXiv + PubMed + Semantic Scholar, a wpadniesz w błędy 429, zanim przerobisz dziesięć prac. Oto dlaczego limity zapytań się pogorszyły, co PaperQA / Undermind naprawdę robią pod maską i działający wzorzec, który przetrwa prawdziwą sesję przeglądu.

TL;DR

• •arXiv zaczął agresywnie throttlować pod koniec 2024 roku, gdy scrapery LLM wywołały burze błędów 429; udokumentowany limit to 1 zapytanie co 3 sekundy, ale rzeczywista tolerancja na serie zapytań jest niższa.
• •1000 req/s w Semantic Scholar jest współdzielone przez wszystkich nieuwierzytelnionych wywołujących — w praktyce bezużyteczne dla agentów produkcyjnych.
• •PubMed E-utils ogranicza ruch nieuwierzytelniony do 3 req/s; z kluczem API — 10 req/s.
• •Działający agenci (PaperQA2, Undermind, Elicit) wszyscy stosują warstwę proxy / cache przed tymi źródłami.
• •API Pick Academic Search opakowuje arXiv, PubMed, bioRxiv i medRxiv w jeden endpoint z zarządzanym limitem — 5 kredytów za wywołanie, pobierane tylko przy sukcesie.

Problem w jednym akapicie

Darmowe API akademickie są cudowne i są pożerane żywcem. arXiv, PubMed i Semantic Scholar zaprojektowano w czasach, gdy „jeden badacz pisze skrypt odpytujący co kilka sekund” było najgorszym przypadkiem obciążenia. Dziś każdy student z Pythonem pisze agenta LLM, który rozsyła pięćdziesiąt równoległych wywołań, żeby przeczytać bibliografię jednej pracy. Pomnóż to przez tysiące podobnych agentów, a otrzymasz wzorzec, który zespół arXiv nazywa na X „arXiv-pocalypse” z końca 2024 roku — utrzymujące się odpowiedzi Rate Exceeded, zdegradowaną usługę i falę nowych reguł throttlingu, które uderzają w niezależnych twórców mocniej niż w tych działających w złej wierze.

Efekt: agent do przeglądu literatury, który działa na pięciu pracach w środowisku deweloperskim, wykłada się w połowie prawdziwej sesji przeglądu. Użytkownik dostaje niedokończoną odpowiedź z trzema cytowaniami zamiast piętnastu.

Ten artykuł jest o tym, jak zbudować agenta tak, żeby to się nie zdarzyło.

Co dokładnie jest objęte limitem zapytań i gdzie

Co naprawdę robią działające produkty

PaperQA2, Undermind, Elicit, ResearchRabbit oraz prace o agentowym RAG (np. Open-Source Agentic Hybrid RAG Framework, arXiv 2508.05660) zbiegają się do podobnego wzorca. Najbardziej liczą się trzy inżynierskie posunięcia:

1. Cache'uj po DOI / arXiv ID, a nie po zapytaniu

O tę samą pracę pyta wiele różnych zapytań. Cache'owanie na poziomie wyniku wyszukiwania prawie nie pomaga; cache'owanie na poziomie identyfikatora pracy — owszem. Mała warstwa Redis (albo nawet SQLite) indeksowana po doi:10.1038/... zwraca się w jedno popołudnie ruchu agenta.

2. Traktuj graf cytowań jako wolno zmieniający się indeks

Siłą Semantic Scholar nie jest wyszukiwanie po słowach kluczowych; to graf cytowań. PaperQA2 używa go, by rozszerzyć się od jednej pracy-ziarna do powiązanego klastra, a nie by odkrywać prace od zera. To znacznie mniejszy wolumen zapytań — jedno wywołanie na pracę, a nie setki — i utrzymuje się dobrze poniżej limitu zapytań.

3. Zaakceptuj opóźnienie jako kompromis, ALBO postaw proxy przed limitem zapytań

Albo każesz użytkownikom czekać 30-60 sekund na staranne, szanujące throttling zapytanie (wybór PaperQA2), albo dodajesz warstwę, która agreguje ruch pomiędzy użytkownikami i prezentuje agentowi jeden interfejs tolerancyjny na serie zapytań (wybór API Pick). Oba podejścia działają. Mieszanie ich — UX o niskim opóźnieniu na publicznych API z limitem zapytań, bez bufora — to właśnie to, co zawodzi.

Działający kod: agent literaturowy, który kończy pracę

Minimalny sensowny agent, który przetrwa prawdziwą sesję przeglądu:

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

Koszt na pytanie:

• 1-2 wywołania academic_search (5-10 kredytów = $0.005-$0.010)
• 1 wywołanie extract obejmujące 3-5 prac (6-10 kredytów = $0.006-$0.010)
• ~5000 tokenów wejściowych + 1200 wyjściowych do Claude (~$0.04)

W zaokrągleniu: ~5 centów za odpowiedź z przeglądu literatury z cytowaniami. Przy 100 pytaniach dziennie to $5/dzień — mniej więcej tyle, ile kosztuje dzienna dawka kofeiny rozsądnego badacza.

Dostrojenia pod podniszę

Literatura biomedyczna

Nastaw agenta na PubMed (recenzowane naukowo) i jawnie oznaczaj trafienia z bioRxiv/medRxiv jako preprinty. Przy pytaniu „co mówią najnowsze dowody” agent powinien wyżej ważyć źródła recenzowane. Jedna linijka w system promptcie — „Jeśli źródła preprintowe i recenzowane naukowo są rozbieżne, przyznaj pierwszeństwo recenzowanym i odnotuj rozbieżność” — załatwia to czysto.

Matematyka / CS

Tu dominuje arXiv. Stosunek sygnału do szumu jest lepszy niż w biomedycynie, a dla prac fundamentalnych cytowania liczą się bardziej niż świeżość. Wyszukuj szerszymi zapytaniami i pozwól agentowi przycinać.

Odkrywanie leków / klinika

Połącz z Clinical Search (ClinicalTrials.gov + etykiety FDA + ChEMBL + DrugBank) dla wymiarów regulacyjnego i bioaktywności, których wyszukiwanie akademickie nie obejmie. To połączenie — literatura recenzowana naukowo + rejestr badań klinicznych + dane strukturalne — sprawia, że agent do repozycjonowania leków lub farmakowigilancji staje się użyteczny.

Gdzie to się uogólnia

Problem limitu zapytań nie dotyczy wyłącznie wyszukiwania akademickiego. Każdy otwarty, publiczny zbiór danych, który wypuścił API w erze przed LLM, jest teraz poddawany tym samym wzorcom obciążenia: SEC EDGAR, USPTO, EPO, bazy rejestrów publicznych, serwisy pogodowe, otwarte dane rządowe. Ten sam wzorzec inżynierski sprawdza się dla wszystkich — cache'uj na poziomie encji, nałóż warstwę zarządzanego proxy, zaakceptuj opóźnienie jako alternatywę, gdy nie stać Cię na proxy.

Głębsza zmiana: w 2026 roku nie jest już rozsądne oczekiwać, że darmowe publiczne API bezpośrednio wchłonie obciążenie agenta LLM. Endpointy nie znikają — ale są opakowywane warstwą płatnych usług zarządzanych, która istnieje po to, by tłumaczyć limity zapytań w stylu „uprzejmego ludzkiego badacza” na ruch „agenta tolerancyjnego na serie zapytań”. API Pick Academic Search to jedna z takich warstw dla zastosowania w przeglądzie literatury. Spodziewaj się kolejnych.

Autor

Sarah Choy

CEO, API Pick

Sarah Choy jest CEO API Pick. Pisze o budowaniu produkcyjnych API dla agentów AI i przepływów pracy z LLM.