[ blog · tutorial ]10 min read

วิธีสร้าง agent ทบทวนวรรณกรรมวิทยาศาสตร์โดยไม่โดนจำกัดอัตราการเรียก

Sarah Choy·เผยแพร่ 3 พฤษภาคม 2569·อ่าน 10 นาที

ลองสร้าง agent ทบทวนวรรณกรรมบน arXiv + PubMed + Semantic Scholar แบบดิบ ๆ วันนี้ แล้วคุณจะชน 429 ก่อนจะอ่านครบสิบเปเปอร์ นี่คือเหตุผลว่าทำไม rate limit ถึงแย่ลง PaperQA / Undermind ทำอะไรอยู่เบื้องหลังจริง ๆ และแพตเทิร์นที่ใช้งานได้จริงซึ่งรอดผ่านเซสชันทบทวนของจริง

สรุปสั้น

• •arXiv เริ่ม throttle อย่างดุดันช่วงปลายปี 2024 หลังจาก scraper ของ LLM ก่อพายุ 429; limit ที่ระบุในเอกสารคือ 1 request ทุก 3 วินาที แต่ความทนต่อ burst ในโลกจริงต่ำกว่านั้น
• •1,000 req/วินาที ของ Semantic Scholar เป็นค่าที่ใช้ร่วมกันในหมู่ผู้เรียกที่ไม่ได้ยืนยันตัวตนทั้งหมด — ในทางปฏิบัติแทบใช้ไม่ได้กับ agent ระดับ production
• •PubMed E-utils จำกัดทราฟฟิกที่ไม่ยืนยันตัวตนไว้ที่ 3 req/วินาที; หากมี API key จะได้ 10 req/วินาที
• •agent ที่ใช้งานได้จริง (PaperQA2, Undermind, Elicit) ล้วนใช้เลเยอร์ proxy / cache วางไว้หน้าแหล่งข้อมูลเหล่านี้
• •API Pick Academic Search ห่อ arXiv, PubMed, bioRxiv และ medRxiv ไว้ใน endpoint เดียวที่จัดการอัตราให้แล้ว — 5 เครดิตต่อการเรียก หักเฉพาะเมื่อสำเร็จ

ปัญหาในย่อหน้าเดียว

API วิชาการฟรีนั้นวิเศษมาก และกำลังถูกกลืนกินทั้งเป็น arXiv, PubMed และ Semantic Scholar ถูกออกแบบในยุคที่ 'นักวิจัยหนึ่งคนเขียนสคริปต์ที่ poll ทุกไม่กี่วินาที' คือกรณีโหลดที่หนักที่สุด ทุกวันนี้นักศึกษาปริญญาตรีทุกคนที่เขียน Python ได้ก็สร้าง agent LLM ที่กระจายห้าสิบการเรียกพร้อมกันเพื่ออ่านรายการอ้างอิงของเปเปอร์เดียว คูณด้วย agent คล้าย ๆ กันหลายพันตัว แล้วคุณจะได้รูปแบบที่ทีมงาน arXiv เรียกบน X ว่า "arXiv-pocalypse" ของปลายปี 2024 — คำตอบ Rate Exceeded ต่อเนื่อง บริการเสื่อมสภาพ และคลื่นของกฎ throttle ใหม่ที่กระทบนักพัฒนาอิสระหนักกว่ากลุ่มผู้ไม่หวังดี

ผลลัพธ์: agent ทบทวนวรรณกรรมที่ทำงานได้กับห้าเปเปอร์ในสภาพแวดล้อม dev กลับล้มกลางคันระหว่างเซสชันทบทวนของจริง ผู้ใช้ได้คำตอบครึ่ง ๆ กลาง ๆ พร้อมสามการอ้างอิงแทนที่จะเป็นสิบห้า

บทความนี้ว่าด้วยการสร้าง agent อย่างไรให้เรื่องนั้นไม่เกิดขึ้น

อะไรที่ถูกจำกัดอัตราจริง ๆ และตรงไหน

ผลิตภัณฑ์ที่ใช้งานได้จริงทำอะไรกันจริง ๆ

PaperQA2, Undermind, Elicit, ResearchRabbit และเปเปอร์ RAG แบบ agentic (เช่น Open-Source Agentic Hybrid RAG Framework, arXiv 2508.05660) ล้วนบรรจบสู่แพตเทิร์นคล้าย ๆ กัน สามหมัดเด็ดด้านวิศวกรรมที่สำคัญที่สุด:

1. cache ตาม DOI / arXiv ID ไม่ใช่ตาม query

เปเปอร์เดียวกันถูกร้องขอโดยหลาย query ที่ต่างกัน การ cache ที่ระดับผลการค้นหาแทบไม่ช่วยอะไร; การ cache ที่ระดับตัวระบุเปเปอร์ต่างหากที่ช่วย เลเยอร์ Redis เล็ก ๆ (หรือแม้แต่ SQLite) ที่ทำ index ด้วย doi:10.1038/... คืนทุนตัวเองภายในทราฟฟิก agent เพียงหนึ่งบ่าย

2. มองกราฟการอ้างอิงเป็น index ที่เปลี่ยนแปลงช้า

จุดแข็งของ Semantic Scholar ไม่ใช่การค้นหาด้วยคีย์เวิร์ด แต่คือกราฟการอ้างอิง PaperQA2 ใช้มันเพื่อขยายจากเปเปอร์ตั้งต้นหนึ่งชิ้นไปสู่คลัสเตอร์ที่เกี่ยวข้อง ไม่ใช่เพื่อค้นหาเปเปอร์จากศูนย์ นั่นคือปริมาณ request ที่น้อยกว่ามาก — หนึ่งการเรียกต่อเปเปอร์ ไม่ใช่หลายร้อย — และอยู่ต่ำกว่า rate limit ได้สบาย ๆ

3. ยอมรับ latency เป็นการแลกเปลี่ยน หรือ proxy ตัว rate limit ไปเลย

คุณเลือกให้ผู้ใช้รอ 30-60 วินาทีสำหรับ query ที่รอบคอบและเคารพ throttle (ทางเลือกของ PaperQA2) หรือคุณเพิ่มเลเยอร์ที่รวมทราฟฟิกข้ามผู้ใช้แล้วนำเสนออินเทอร์เฟซเดียวที่ทน burst ให้กับ agent (ทางเลือกของ API Pick) ทั้งสองแบบใช้ได้ การผสมมันเข้าด้วยกัน — UX latency ต่ำบน API สาธารณะที่โดนจำกัดอัตราโดยไม่มี buffer — คือสิ่งที่ล้มเหลว

โค้ดที่ใช้งานได้จริง: agent วรรณกรรมที่ไปจนจบ

agent ขั้นต่ำที่ใช้ได้จริงและรอดผ่านเซสชันทบทวนของจริง:

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

ค่าใช้จ่ายต่อคำถาม:

• การเรียก academic_search 1-2 ครั้ง (5-10 เครดิต = $0.005-$0.010)
• การเรียก extract 1 ครั้ง ครอบคลุม 3-5 เปเปอร์ (6-10 เครดิต = $0.006-$0.010)
• token ขาเข้า ~5,000 + ขาออก 1,200 ไปยัง Claude (~$0.04)

ปัดเป็นตัวเลขกลม ๆ: ~5 เซนต์ต่อคำตอบทบทวนวรรณกรรมพร้อมการอ้างอิง ที่ 100 คำถาม/วัน ก็คือ $5/วัน — ราว ๆ ค่ากาแฟรายวันของนักวิจัยคนหนึ่ง

การปรับแต่งตามแนวดิ่งย่อย

วรรณกรรมชีวการแพทย์

เอนเอียง agent ไปทาง PubMed (ผ่านการทบทวนโดยผู้เชี่ยวชาญ) และทำเครื่องหมายรายการที่มาจาก bioRxiv/medRxiv อย่างชัดเจนว่าเป็น preprint เมื่อถามว่า "หลักฐานล่าสุดว่าอย่างไร" agent ควรให้น้ำหนักงานที่ผ่านการทบทวนสูงกว่า หนึ่งบรรทัดใน system prompt — "หากแหล่ง preprint กับแหล่งที่ผ่านการทบทวนขัดแย้งกัน ให้ยึดแหล่งที่ผ่านการทบทวนและระบุความไม่สอดคล้อง" — จัดการเรื่องนี้ได้สะอาดหมดจด

คณิตศาสตร์ / CS

ที่นี่ arXiv ครองตลาด อัตราส่วนสัญญาณต่อสัญญาณรบกวนดีกว่าในสายชีวการแพทย์ และสำหรับงานพื้นฐาน การอ้างอิงสำคัญกว่าความใหม่ ค้นด้วย query ที่กว้างขึ้นแล้วปล่อยให้ agent ตัดทอนเอง

การค้นพบยา / คลินิก

จับคู่กับ Clinical Search (ClinicalTrials.gov + ฉลาก FDA + ChEMBL + DrugBank) สำหรับมิติด้านกำกับดูแลและฤทธิ์ทางชีวภาพที่การค้นหาวิชาการครอบคลุมไม่ได้ การผสมผสานนี้ — วรรณกรรมที่ผ่านการทบทวน + ทะเบียนการทดลอง + ข้อมูลเชิงโครงสร้าง — คือสิ่งที่ทำให้ agent สำหรับ repurposing ยาหรือเฝ้าระวังความปลอดภัยของยาใช้งานได้จริง

เรื่องนี้ขยายผลไปได้ที่ไหน

ปัญหา rate limit ไม่ได้มีเฉพาะกับการค้นหาวิชาการ ชุดข้อมูลสาธารณะแบบเปิดทุกชุดที่ปล่อย API ออกมาในยุคก่อน LLM ตอนนี้ล้วนเผชิญกับรูปแบบโหลดแบบเดียวกัน: SEC EDGAR, USPTO, EPO, ฐานข้อมูลระเบียนสาธารณะ, บริการพยากรณ์อากาศ, ข้อมูลเปิดของรัฐบาล แพตเทิร์นด้านวิศวกรรมแบบเดียวกันใช้ได้กับทั้งหมด — cache ที่ระดับ entity, วางเลเยอร์ proxy ที่มีการจัดการทับไว้, ยอมรับ latency เป็นทางเลือกเมื่อคุณจ่ายค่า proxy ไม่ไหว

การเปลี่ยนแปลงที่ลึกกว่านั้น: ในปี 2026 มันไม่สมเหตุสมผลอีกต่อไปที่จะคาดหวังให้ API สาธารณะฟรีรับโหลดจาก agent LLM โดยตรง endpoint ไม่ได้หายไปไหน — แต่กำลังถูกห่อด้วยเลเยอร์ของบริการที่มีการจัดการแบบเสียเงิน ซึ่งมีอยู่เพื่อแปลง rate limit แบบ "นักวิจัยมนุษย์ที่สุภาพ" ให้เป็นทราฟฟิกแบบ "agent ที่ทน burst" API Pick Academic Search คือหนึ่งในเลเยอร์เหล่านั้นสำหรับกรณีใช้งานทบทวนวรรณกรรม และจะมีอีกมาก

เขียนโดย

Sarah Choy

CEO, API Pick

Sarah Choy เป็น CEO ของ API Pick เธอเขียนเกี่ยวกับการสร้าง API พร้อมใช้งานจริงสำหรับ AI agent และเวิร์กโฟลว์ LLM