كيف تبني وكيل مراجعة أدبيات علمية دون الاصطدام بحدود معدّل الطلبات

ابنِ وكيل مراجعة أدبيات اليوم على arXiv + PubMed + Semantic Scholar الخام، وستصطدم بأخطاء 429 قبل أن تنهي عشر أوراق. إليك لماذا ساءت حدود المعدّل، وما الذي تفعله PaperQA / Undermind فعلاً تحت الغطاء، ونمط عملي يصمد في جلسة مراجعة حقيقية.
الخلاصة
- •بدأ arXiv بالخنق بعنف أواخر 2024 بعد أن أطلقت أدوات الكشط المدفوعة بنماذج اللغة عواصف 429؛ الحدّ الموثّق هو طلب واحد كل 3 ثوانٍ، لكن تحمّل الدفقات الواقعي أقلّ من ذلك.
- •الـ 1,000 طلب/ثانية في Semantic Scholar مشتركة بين كل المتّصلين غير المصادَق عليهم — غير قابلة للاستخدام عمليًا لوكلاء الإنتاج.
- •PubMed E-utils يحدّ الحركة غير المصادَق عليها بـ 3 طلبات/ثانية؛ مع مفتاح API، 10 طلبات/ثانية.
- •الوكلاء العاملون (PaperQA2، Undermind، Elicit) جميعهم يستخدمون طبقة وكيل / تخزين مؤقّت أمام هذه المصادر.
- •API Pick Academic Search يلفّ arXiv وPubMed وbioRxiv وmedRxiv في نقطة نهاية واحدة مُدارة المعدّل — 5 أرصدة للنداء، عند النجاح فقط.
المشكلة في فقرة واحدة
واجهات الأكاديميا المجانية رائعة، وهي تُلتهم حيّةً. صُمّمت arXiv وPubMed وSemantic Scholar في عصر كان فيه أسوأ حِمل متصوَّر هو 'باحث واحد يكتب سكربتًا يستعلم كل بضع ثوانٍ'. اليوم كل طالب جامعي يعرف Python يكتب وكيل نموذج لغة يتوسّع إلى خمسين نداءً متوازيًا لقراءة مراجع ورقة واحدة. اضربها بآلاف الوكلاء المشابهين فتحصل على النمط الذي يصفه موظّفو arXiv على X بـ "نهاية العالم في arXiv" أواخر 2024 — استجابات Rate Exceeded مستمرّة، وخدمة متدهورة، وموجة من قواعد الخنق الجديدة التي ضربت البنّائين المستقلّين أشدّ مما ضربت الفاعلين السيّئين.
النتيجة: وكيل مراجعة أدبيات يعمل على خمس أوراق في بيئة التطوير ينهار في منتصف جلسة مراجعة حقيقية. يحصل المستخدم على إجابة نصف مكتملة بثلاثة استشهادات بدل خمسة عشر.
هذا المقال عن كيفية بناء الوكيل بحيث لا يحدث ذلك.
ما الذي يخضع لحدّ المعدّل فعلاً وأين
| arXiv | PubMed E-utils | Semantic Scholar | OpenAlex | API Pick Academic | |
|---|---|---|---|---|---|
| التغطية | مسوّدات الفيزياء والرياضيات وعلوم الحاسوب والأحياء | طبّي حيوي (35M+ سجلّ) | متعدّد التخصّصات (>200M) | متعدّد التخصّصات (250M+) | arXiv + PubMed + bioRxiv + medRxiv |
| حدّ المعدّل (غير مصادَق) | 1 طلب / 3 ثوانٍ | 3 طلبات / ثانية | مجمّع مشترك 1k/ثانية (منخفض فعليًا) | 100k طلب / يوم | بالدفع لكل نداء، بلا خنق لكل مستخدم |
| حدّ المعدّل (مع مفتاح) | نفسه — المفاتيح للجملة فقط | 10 طلبات / ثانية | دلو لكل مفتاح (يُمنح ببطء) | نفسه | — |
| هل يُرجع النصّ الكامل؟ | نعم (XML / رابط PDF) | الملخّص فقط | ملخّص + مختارات خارج الجدار المدفوع | ملخّص + مختارات | عنوان + URL + قصاصة على هيئة ملخّص |
| صيغة ملائمة لنماذج اللغة | لا — Atom XML | لا — XML | نعم — JSON | نعم — JSON | نعم — JSON، قصاصات مُشكَّلة مسبقًا |
| التكلفة | مجاني | مجاني (يُنصح بمفتاح) | مجاني، يلزم مفتاح للإنتاج | مجاني | 5 أرصدة/نداء (~$0.005) |
ما الذي تفعله المنتجات العاملة فعلاً
PaperQA2 وUndermind وElicit وResearchRabbit وأوراق RAG الوكيلية (مثل Open-Source Agentic Hybrid RAG Framework، arXiv 2508.05660) تتقارب كلّها على نمط مشابه. ثلاث خطوات هندسية هي الأهمّ:
1. خزّن مؤقّتًا حسب DOI / معرّف arXiv، لا حسب الاستعلام
الورقة نفسها تُطلب من استعلامات مختلفة كثيرة. التخزين المؤقّت على مستوى نتيجة البحث بالكاد يفيد؛ أما التخزين على مستوى معرّف الورقة فيفيد. طبقة Redis صغيرة (أو حتى SQLite) مفتاحها doi:10.1038/... تردّ كلفتها خلال عصرٍ واحد من حركة الوكيل.
2. عامِل بيان الاستشهادات كفهرس بطيء التغيّر
قوّة Semantic Scholar ليست البحث بالكلمات المفتاحية؛ بل بيان الاستشهادات. يستخدمه PaperQA2 للتوسّع من ورقة بذرة واحدة إلى عنقود مرتبط، لا لاكتشاف الأوراق من الصفر. هذا حجم طلبات أصغر بكثير — نداء واحد لكل ورقة لا مئات — ويبقى تحت حدّ المعدّل بأريحية.
3. اقبل زمن الاستجابة كمقايضة، أو وكِّل حدّ المعدّل
إمّا أن تجعل المستخدمين ينتظرون 30-60 ثانية مقابل استعلام متأنٍّ يحترم الخنق (خيار PaperQA2)، أو تضيف طبقةً تجمّع الحركة عبر المستخدمين وتقدّم للوكيل واجهةً واحدةً تتحمّل الدفقات (خيار API Pick). كلاهما يعمل. أمّا خلطهما — تجربة استخدام منخفضة الزمن فوق واجهات عامة محدودة المعدّل دون عازل — فهو ما يفشل.
شيفرة عاملة: وكيل أدبيات يُكمل المهمة
الحدّ الأدنى من الوكيل القابل للحياة الذي يصمد في جلسة مراجعة حقيقية:
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 أرصدة = $0.005-$0.010)
- نداء extract واحد يغطّي 3-5 أوراق (6-10 أرصدة = $0.006-$0.010)
- ~5,000 رمز إدخال + 1,200 رمز إخراج إلى Claude (~$0.04)
تقريبًا: ~5 سنتات لكل إجابة مراجعة أدبيات مع استشهادات. عند 100 سؤال/يوم يكون ذلك $5/يوم — تقريبًا ما تكلّفه قهوة باحث معقول اليومية.
تعديلات حسب التخصّص الفرعي
الأدبيات الطبّية الحيوية
حيِّز الوكيل نحو PubMed (المُحكَّمة) وعلِّم نتائج bioRxiv/medRxiv صراحةً كمسوّدات. عند السؤال "ماذا تقول أحدث الأدلّة"، ينبغي للوكيل أن يرجّح المُحكَّمة أكثر. سطر في موجّه النظام — "إن اختلفت مصادر المسوّدات عن المُحكَّمة، رجّح المُحكَّمة وأشِر إلى التعارض" — يعالج هذا بنظافة.
الرياضيات / علوم الحاسوب
arXiv يهيمن هنا. نسبة الإشارة إلى الضوضاء أفضل منها في الطبّ الحيوي، والاستشهادات أهمّ من الحداثة للأعمال التأسيسية. ابحث باستعلامات أوسع ودع الوكيل يشذّب.
اكتشاف الأدوية / السريري
اقرنه بـ Clinical Search (ClinicalTrials.gov + ملصقات FDA + ChEMBL + DrugBank) للأبعاد التنظيمية والفاعلية الحيوية التي لا يغطّيها البحث الأكاديمي. الجمع — أدبيات مُحكَّمة + سجلّ تجارب + بيانات بنيوية — هو كيف يصبح وكيل إعادة توظيف الأدوية أو اليقظة الدوائية مفيدًا.
أين يتعمّم هذا
مشكلة حدّ المعدّل ليست خاصّة بالبحث الأكاديمي. أيّ مجموعة بيانات عامة مفتوحة شحنت واجهاتها في عصر ما قبل نماذج اللغة تتعرّض الآن لأنماط الحِمل ذاتها: SEC EDGAR، USPTO، EPO، قواعد السجلّات العامة، خدمات الطقس، البيانات الحكومية المفتوحة. النمط الهندسي ذاته يعمل لها جميعًا — خزّن مؤقّتًا على مستوى الكيان، أضِف طبقة وكيل مُدارة، اقبل زمن الاستجابة كبديل حين لا تستطيع تحمّل الوكيل.
التحوّل الأعمق: في 2026 لم يعد معقولًا توقّع أن تمتصّ واجهة عامة مجانية حِمل وكلاء نماذج اللغة مباشرةً. النقاط الطرفية لا تختفي — لكنها تُلفّ بطبقة من الخدمات المُدارة المدفوعة الموجودة لترجمة حدود معدّل "الباحث البشري المهذّب" إلى "حركة وكيل تتحمّل الدفقات". API Pick Academic Search هو إحدى تلك الطبقات لحالة استخدام مراجعة الأدبيات. توقّع المزيد.
الأسئلة الشائعة
لماذا بدأ arXiv بتحديد المعدّل بهذه القسوة في 2024؟
أدوات الكشط المدفوعة بنماذج اللغة. كان موظّفو arXiv صريحين في قائمتهم البريدية للمطوّرين وعلى حساب @arxiv على X بشأن النمط: وكيل نموذج لغة يتوسّع إلى 50 طلبًا متوازيًا لجلب مراجع ورقة واحدة، اضربها بآلاف المستخدمين الذين يشغّلون سير عمل مشابهًا، فيتدهور الفهرس كلّه. كانت قاعدة الـ 3 ثوانٍ بين الطلبات موثّقة دائمًا، لكن التطبيق صار صارمًا بدءًا من أواخر 2024 / أوائل 2025.
هل الـ 1,000 طلب/ثانية في Semantic Scholar مشتركة فعلاً؟
نعم — هذا هو المجمّع غير المصادَق عليه، المشترك بين كل عنوان IP يضرب الواجهة العامة. عمليًا، تبدأ الطلبات غير المصادَق عليها بالفشل خلال ساعات الذروة بصرف النظر عن معدّلك الفردي. النصيحة الرسمية هي التقدّم بطلب مفتاح API، الذي ينقلك إلى دلو خاص بكل مفتاح. يستغرق الطلب أسابيع ويُمنح على افتراض الاستخدام الأكاديمي، لا التجاري.
ماذا عن PubMed E-utils؟
أفضل من البقية — 3 طلبات/ثانية بلا مفتاح، 10 طلبات/ثانية مع مفتاح. تقدّم بطلب مفتاح NCBI API عبر البريد الإلكتروني؛ يُمنح عادةً في اليوم نفسه لأغراض بحثية معلنة. ومع ذلك: 10 طلبات/ثانية تكفي لمستخدم واحد لكنها غير كافية لمنتج متعدّد المستخدمين حيث يتوسّع كل سؤال مستخدم إلى عدّة نداءات PubMed.
لماذا يعمل PaperQA2 حيث يفشل وكيلي المصنوع منزليًا؟
ثلاثة أسباب. (1) PaperQA2 يجمّع ويخزّن مؤقّتًا بقوة — البحث ذاته عن DOI لا يُجرى مرّتين أبدًا. (2) يستخدم Semantic Scholar أساسًا من أجل بيان الاستشهادات (نداء واحد لكل ورقة) لا كفهرس بحث. (3) يقبل زمنًا أطول على الساعة لكل سؤال مقابل عدم تجاوز الحدود. إن أردت التجربة ذاتها في منتج يتوقّع فيه المستخدمون استجابات خلال 5 ثوانٍ، فأنت بحاجة إلى طبقة أعلى إنتاجية.
ما الذي يحلّه API Pick Academic Search فعلاً؟
يدير حدود المعدّل وتغطية المصادر كي لا يضطرّ وكيلك إلى ذلك. نداء واحد POST /api/search/academic يُرجع نتائج مرتّبة من arXiv وPubMed وbioRxiv وmedRxiv معًا، مُشكَّلة مسبقًا لاستهلاك نماذج اللغة. 5 أرصدة للنداء (≈$0.005)، تُخصم فقط عند HTTP 200. تركّز أنت على حلقة الوكيل والموجّه؛ والخنق مشكلتنا نحن.
الواجهات البرمجية المستخدمة في هذا المقال
سارة تشوي هي الرئيسة التنفيذية لشركة API Pick. تكتب عن بناء واجهات برمجية جاهزة للإنتاج لوكلاء الذكاء الاصطناعي وسير عمل نماذج اللغة.