[ blog · tutorial ]10 min read

रेट-लिमिट में फँसे बिना वैज्ञानिक साहित्य-समीक्षा एजेंट कैसे बनाएँ

Sarah Choy·प्रकाशित 3 मई 2026·10 मिनट पढ़ें

आज ही कच्चे arXiv + PubMed + Semantic Scholar पर एक साहित्य-समीक्षा एजेंट बना लीजिए और दस paper पूरे करने से पहले ही आप 429 से टकरा जाएँगे। यहाँ बताया गया है कि रेट लिमिट क्यों और बिगड़ी, PaperQA / Undermind भीतर-ही-भीतर असल में क्या करते हैं, और एक ऐसा कारगर पैटर्न जो असली समीक्षा-सत्र को झेल जाता है।

TL;DR

• •LLM scraper द्वारा 429 की बाढ़ लाने के बाद arXiv ने 2024 के अंत में आक्रामक throttling शुरू कर दी; दस्तावेज़ित सीमा हर 3 सेकंड में 1 request है, पर असल दुनिया में burst की सहनशीलता इससे कम है।
• •Semantic Scholar की 1,000 req/sec सभी अप्रमाणित (unauthenticated) कॉलर्स के बीच साझा है — प्रोडक्शन एजेंट के लिए व्यावहारिक रूप से अनुपयोगी।
• •PubMed E-utils अप्रमाणित ट्रैफ़िक को 3 req/sec पर सीमित करता है; API key के साथ 10 req/sec।
• •जो एजेंट काम करते हैं (PaperQA2, Undermind, Elicit) वे सभी इन स्रोतों के आगे एक proxy / cache परत का इस्तेमाल करते हैं।
• •API Pick Academic Search, arXiv, PubMed, bioRxiv और medRxiv को एक ही रेट-प्रबंधित endpoint में लपेट देता है — प्रति कॉल 5 credit, सिर्फ़ सफलता पर।

समस्या एक पैराग्राफ में

मुफ़्त अकादमिक API शानदार हैं और उन्हें ज़िंदा निगला जा रहा है। arXiv, PubMed और Semantic Scholar उस दौर में बने थे जब "एक शोधकर्ता कुछ-कुछ सेकंड में poll करने वाला script लिखता है" सबसे बुरा भार-परिदृश्य था। आज Python जानने वाला हर स्नातक छात्र एक LLM एजेंट लिख रहा है जो किसी एक paper के references पढ़ने के लिए पचास समानांतर कॉल भेजता है। इसे हज़ारों ऐसे ही एजेंटों से गुणा कीजिए और आपको वह पैटर्न मिलता है जिसे arXiv के कर्मचारी X पर 2024 के अंत का "arXiv-pocalypse" कहते हैं — लगातार Rate Exceeded जवाब, बिगड़ी सेवा, और नए throttling नियमों की लहर जो indie डेवलपर्स को बुरे लोगों से ज़्यादा चोट पहुँचाती है।

नतीजा: एक साहित्य-समीक्षा एजेंट जो development environment में पाँच paper पर चलता है, असली समीक्षा-सत्र के बीचों-बीच धराशायी हो जाता है। उपयोगकर्ता को पंद्रह के बजाय तीन उद्धरणों वाला अधूरा जवाब मिलता है।

यह लेख इसी बारे में है कि एजेंट को ऐसे कैसे बनाया जाए कि ऐसा न हो।

असल में किस पर रेट लिमिट है और कहाँ

जो product काम करते हैं वे असल में क्या करते हैं

PaperQA2, Undermind, Elicit, ResearchRabbit और agentic RAG के paper (जैसे Open-Source Agentic Hybrid RAG Framework, arXiv 2508.05660) सभी एक जैसे पैटर्न पर आ जुटते हैं। तीन इंजीनियरिंग कदम सबसे ज़्यादा मायने रखते हैं:

1. DOI / arXiv ID से cache करें, query से नहीं

एक ही paper को कई अलग-अलग queries माँगती हैं। search-result के स्तर पर cache करने से बमुश्किल मदद मिलती है; paper-identifier के स्तर पर cache करने से मिलती है। doi:10.1038/... पर keyed एक छोटी Redis (या यहाँ तक कि SQLite) परत एजेंट-ट्रैफ़िक की एक दोपहर में ही अपनी कीमत वसूल कर लेती है।

2. citation graph को धीमे-बदलते index की तरह बरतें

Semantic Scholar की ताकत keyword search नहीं है; वह citation graph है। PaperQA2 इसका इस्तेमाल एक seed paper से किसी संबंधित cluster तक फैलने के लिए करता है, शून्य से paper खोजने के लिए नहीं। यह कहीं छोटा request वॉल्यूम है — प्रति paper एक कॉल, सैकड़ों नहीं — और रेट लिमिट से काफ़ी नीचे रहता है।

3. latency को समझौते के रूप में स्वीकारें, या रेट लिमिट को proxy करें

या तो आप उपयोगकर्ताओं को throttle का सम्मान करने वाली एक सावधान query के लिए 30-60 सेकंड इंतज़ार कराते हैं (PaperQA2 का चुनाव), या आप एक परत जोड़ते हैं जो उपयोगकर्ताओं भर का ट्रैफ़िक एकत्र करके एजेंट के सामने एक अकेला burst-सहिष्णु interface पेश करती है (API Pick का चुनाव)। दोनों काम करते हैं। इन्हें मिलाना — बिना buffer के रेट-लिमिटेड सार्वजनिक API के ऊपर एक low-latency UX — वही है जो विफल होता है।

चलता हुआ कोड: एक साहित्य एजेंट जो काम पूरा करता है

वह न्यूनतम व्यवहार्य एजेंट जो असली समीक्षा-सत्र को झेल जाता है:

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

प्रति प्रश्न लागत:

• 1-2 academic_search कॉल (5-10 credit = $0.005-$0.010)
• 3-5 paper कवर करती 1 extract कॉल (6-10 credit = $0.006-$0.010)
• Claude को ~5,000 input + 1,200 output token (~$0.04)

मोटे आँकड़े में: उद्धरणों सहित प्रति साहित्य-समीक्षा जवाब ~5 सेंट। 100 प्रश्न/दिन पर यह $5/दिन है — लगभग उतना ही जितना एक समझदार शोधकर्ता की रोज़ाना caffeine पर खर्च होता है।

उप-वर्टिकल समायोजन

बायोमेडिकल साहित्य

एजेंट को PubMed (peer-reviewed) की ओर झुकाएँ और bioRxiv/medRxiv hits को स्पष्ट रूप से preprint के रूप में चिह्नित करें। जब आप पूछें "नवीनतम साक्ष्य क्या कहते हैं", तो एजेंट को peer-reviewed को ऊँचा भार देना चाहिए। system prompt में एक पंक्ति — "अगर preprint और peer-reviewed स्रोत असहमत हों, तो peer-reviewed को प्राथमिकता दें और विसंगति को नोट करें" — इसे साफ़-सुथरे ढंग से संभाल लेती है।

गणित / CS

यहाँ arXiv का दबदबा है। signal-to-noise अनुपात बायोमेडिसिन से बेहतर है, और बुनियादी काम के लिए recency से ज़्यादा citations मायने रखते हैं। व्यापक queries से खोजें और एजेंट को छँटाई करने दें।

दवा खोज / clinical

उन नियामक और bioactivity आयामों के लिए, जिन्हें अकादमिक search कवर नहीं कर सकता, इसे Clinical Search (ClinicalTrials.gov + FDA labels + ChEMBL + DrugBank) के साथ जोड़ें। यह संयोजन — peer-reviewed साहित्य + trial registry + structural data — ही वह चीज़ है जिससे drug-repurposing या pharmacovigilance एजेंट उपयोगी बनता है।

यह कहाँ सामान्यीकृत होता है

रेट-लिमिट की समस्या केवल अकादमिक search तक सीमित नहीं है। कोई भी खुला सार्वजनिक dataset जिसने pre-LLM युग में API जारी की थीं, अब उन्हीं भार-पैटर्न का सामना कर रहा है: SEC EDGAR, USPTO, EPO, सार्वजनिक-अभिलेख databases, मौसम सेवाएँ, सरकारी open data। वही इंजीनियरिंग पैटर्न इन सबके लिए काम करता है — entity के स्तर पर cache करें, एक प्रबंधित proxy परत लगाएँ, और जब आप proxy का खर्च न उठा सकें तो latency को विकल्प के रूप में स्वीकारें।

गहरा बदलाव: 2026 में यह उम्मीद करना अब उचित नहीं कि कोई मुफ़्त सार्वजनिक API सीधे LLM-एजेंट का भार सोख ले। endpoints गायब नहीं हो रहे — पर उन्हें भुगतान वाली प्रबंधित सेवाओं की एक परत लपेट रही है, जो इसलिए मौजूद है कि "विनम्र मानव शोधकर्ता" वाली रेट लिमिट को "burst-सहिष्णु एजेंट" ट्रैफ़िक में अनुवादित कर सके। साहित्य-समीक्षा के use case के लिए API Pick Academic Search ऐसी ही एक परत है। और भी आएँगी।

लेखक

Sarah Choy

CEO, API Pick

Sarah Choy, API Pick की CEO हैं। वे AI एजेंट्स और LLM वर्कफ़्लो के लिए प्रोडक्शन-रेडी APIs बनाने के बारे में लिखती हैं।