[ blog · tutorial ]10 min read

Rate Limit'e Takılmadan Bilimsel Literatür-Tarama Ajanı Nasıl Kurulur

Sarah Choy·Yayımlanma tarihi: 3 Mayıs 2026·10 dk okuma

Bugün ham arXiv + PubMed + Semantic Scholar üzerine bir literatür-tarama ajanı kurun ve daha on paper'ı bitirmeden 429'lara toslayın. İşte rate limit'lerin neden kötüleştiği, PaperQA / Undermind'ın kaputun altında gerçekte ne yaptığı ve gerçek bir tarama oturumunu atlatan, işleyen bir desen.

Özet

• •LLM scraper'ları 429 fırtınaları tetikledikten sonra arXiv, 2024 sonunda agresif throttling uygulamaya başladı; belgelenen sınır her 3 saniyede 1 istek, ancak gerçek dünyadaki burst toleransı daha düşük.
• •Semantic Scholar'ın 1.000 istek/sn'si tüm kimliği doğrulanmamış çağıranlar arasında paylaşılıyor — üretim ajanları için fiilen kullanılamaz.
• •PubMed E-utils, kimliği doğrulanmamış trafiği saniyede 3 istekle sınırlandırır; bir API key ile saniyede 10 istek.
• •İşe yarayan ajanlar (PaperQA2, Undermind, Elicit) hepsi bu kaynakların önünde bir proxy / cache katmanı kullanıyor.
• •API Pick Academic Search; arXiv, PubMed, bioRxiv ve medRxiv'i hızı yönetilen tek bir endpoint'te sarmalar — çağrı başına 5 kredi, yalnızca başarıda.

Sorun tek bir paragrafta

Ücretsiz akademik API'ler harikadır ve diri diri yenip bitiriliyorlar. arXiv, PubMed ve Semantic Scholar, "bir araştırmacı her birkaç saniyede bir sorgulayan bir betik yazar" durumunun en kötü yük senaryosu olduğu bir çağda tasarlandı. Bugün Python bilen her lisans öğrencisi, tek bir paper'ın kaynaklarını okumak için elli paralel çağrı dağıtan bir LLM ajanı yazıyor. Bunu benzer binlerce ajanla çarpın ve arXiv ekibinin X'te 2024 sonunun "arXiv-pocalypse"i diye tarif ettiği deseni elde edersiniz — sürekli Rate Exceeded yanıtları, bozulan hizmet ve indie geliştiricileri kötü niyetlilerden daha sert vuran bir yeni throttling kuralları dalgası.

Sonuç: geliştirme ortamında beş paper üzerinde çalışan bir literatür-tarama ajanı, gerçek bir tarama oturumunun yarısında çöküyor. Kullanıcı, on beş yerine üç atıflı, yarım kalmış bir yanıt alıyor.

Bu makale, ajanı bunun olmayacağı şekilde nasıl kuracağınızla ilgili.

Gerçekte neyin rate limit'i var ve nerede

İşe yarayan ürünler gerçekte ne yapıyor

PaperQA2, Undermind, Elicit, ResearchRabbit ve agentic RAG makaleleri (ör. Open-Source Agentic Hybrid RAG Framework, arXiv 2508.05660) hepsi benzer bir desende buluşur. En çok önem taşıyan üç mühendislik hamlesi var:

1. Query'ye göre değil, DOI / arXiv ID'ye göre cache'leyin

Aynı paper, birçok farklı query tarafından istenir. Arama sonucu düzeyinde cache'lemek pek işe yaramaz; paper tanımlayıcısı düzeyinde cache'lemek yarar. doi:10.1038/... ile anahtarlanan küçük bir Redis (hatta SQLite) katmanı, bir öğleden sonralık ajan trafiğinde kendini amorti eder.

2. citation graph'ı yavaş değişen dizin olarak ele alın

Semantic Scholar'ın gücü anahtar kelime araması değildir; citation graph'ıdır. PaperQA2 onu, sıfırdan paper keşfetmek için değil, tek bir tohum paper'dan ilişkili bir kümeye genişlemek için kullanır. Bu çok daha küçük bir istek hacmidir — yüzlerce değil, paper başına bir çağrı — ve rate limit'in oldukça altında kalır.

3. Gecikmeyi bir ödünleşim olarak kabul edin, YA DA rate limit'e proxy koyun

Ya kullanıcıları, throttle'a saygılı, dikkatli bir query için 30-60 saniye bekletirsiniz (PaperQA2'nin tercihi), ya da kullanıcılar arası trafiği bir araya toplayıp ajana tek bir burst-toleranslı arayüz sunan bir katman eklersiniz (API Pick'in tercihi). İkisi de işe yarar. Bunları karıştırmak — tampon olmadan rate limit'li herkese açık API'ler üzerinde düşük gecikmeli bir UX — işte başarısız olan budur.

İşleyen kod: işini bitiren bir literatür ajanı

Gerçek bir tarama oturumunu atlatan minimum uygulanabilir ajan:

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

Soru başına maliyet:

• 1-2 academic_search çağrısı (5-10 kredi = $0.005-$0.010)
• 3-5 paper kapsayan 1 extract çağrısı (6-10 kredi = $0.006-$0.010)
• Claude'a ~5.000 girdi + 1.200 çıktı token (~$0.04)

Yuvarlak rakamla: atıflarla birlikte literatür-tarama yanıtı başına ~5 sent. Günde 100 soruda bu günde $5 eder — aşağı yukarı makul bir araştırmacının günlük kafein masrafı kadar.

Alt-dikey ayarlamalar

Biyomedikal literatür

Ajanı PubMed'e (hakem denetimli) doğru eğin ve bioRxiv/medRxiv isabetlerini açıkça preprint olarak işaretleyin. "En son kanıtlar ne diyor" diye sorulduğunda, ajan hakem denetimliye daha yüksek ağırlık vermeli. System prompt'ta tek bir satır — "Preprint ve hakem denetimli kaynaklar uyuşmazsa, hakem denetimliye öncelik ver ve tutarsızlığı belirt" — bunu temiz biçimde halleder.

Matematik / CS

Burada arXiv baskındır. Sinyal-gürültü oranı biyomedikaldekinden iyidir ve temel çalışmalar için atıflar, güncellikten daha önemlidir. Daha geniş query'lerle arayın ve budamayı ajana bırakın.

İlaç keşfi / klinik

Akademik aramanın kapsayamadığı düzenleyici ve biyoaktivite boyutları için Clinical Search (ClinicalTrials.gov + FDA etiketleri + ChEMBL + DrugBank) ile eşleştirin. Bu birleşim — hakem denetimli literatür + denemeler kütüğü + yapısal veri — bir ilaç-yeniden konumlandırma veya farmakovijilans ajanını işe yarar kılan şeydir.

Bunun nereye genellendiği

Rate limit sorunu yalnızca akademik aramaya özgü değil. LLM öncesi çağda API'ler yayımlamış her açık herkese açık veri kümesi şimdi aynı yük desenlerine maruz kalıyor: SEC EDGAR, USPTO, EPO, kamu-kayıt veritabanları, hava durumu hizmetleri, devlet açık verisi. Aynı mühendislik deseni hepsi için geçerli — varlık düzeyinde cache'leyin, yönetilen bir proxy katmanı koyun, proxy'yi karşılayamadığınızda gecikmeyi alternatif olarak kabul edin.

Daha derin kayma: 2026'da, ücretsiz bir herkese açık API'nin LLM-ajan yükünü doğrudan soğurmasını beklemek artık makul değil. Endpoint'ler kaybolmuyor — ancak "kibar insan araştırmacı" rate limit'lerini "burst-toleranslı ajan" trafiğine çevirmek için var olan ücretli yönetilen hizmetler katmanıyla sarmalanıyorlar. API Pick Academic Search, literatür-tarama kullanım durumu için bu katmanlardan biridir. Daha fazlasını bekleyin.

Yazan

Sarah Choy

CEO, API Pick

Sarah Choy, API Pick'in CEO'sudur. Yapay zeka ajanları ve LLM iş akışları için üretime hazır API'ler geliştirme üzerine yazılar yazar.