รัน paper-qa บน custom OpenAI-compatible endpoint
Updated 2026-07-30
paper-qa ตั้งค่าโมเดลของมันผ่าน dict router ของ LiteLLM และ litellm_params รับ api_base ตั้งเป็น https://api.apisrouter.com/v1 ส่ง key เดียว แล้วช่องคำตอบ, สรุป และ agent แต่ละช่องจะรันโมเดลในแคตตาล็อกใดก็ได้บน paper library ของคุณเอง
คำตอบสั้น ๆ: dict router ที่มี api_base ใช้ซ้ำต่อช่อง
object Settings ของ paper-qa รับชื่อโมเดลบวก config router ของ LiteLLM ที่เป็นตัวเลือกต่อช่อง config router คือ model_list ที่ litellm_params ของมันพก api_base และ api_key ซึ่งเป็นรูปแบบที่มีเอกสารระบุเดียวกับที่ README ใช้สำหรับ OpenAI-compatible server แบบ local ที่โฮสต์เอง gateway ก็แค่รูปแบบนั้นที่มี URL สาธารณะและ key จริง ตั้ง llm และ summary_llm เป็น model_name ที่คุณประกาศไว้ ผูก config เข้ากับทั้งสองช่อง แล้ว paper-qa จะ route ผ่าน gateway สตริงโมเดลข้างใน litellm_params คงธรรมเนียม provider ของ litellm ไว้: openai/<id> บอก litellm ให้พูด chat-completions กับ api_base ของคุณ และ id หลังเครื่องหมาย / ถูกส่งผ่านไปยัง endpoint ดังนั้น id ของ Claude, GPT, Gemini และ GLM ล้วนเรียกใช้ได้ด้วย dict เดียวกัน
gateway_config = dict(
model_list=[
dict(
model_name="claude-sonnet-4-6",
litellm_params=dict(
model="openai/claude-sonnet-4-6",
api_base="https://api.apisrouter.com/v1",
api_key=os.getenv("APISROUTER_API_KEY"),
temperature=0.1,
),
)
]
)paper-qa ใช้ token ที่ไหน: สามช่องบวก embedding
paper-qa (Future-House บน GitHub มีดาวประมาณ 9K) ทำ retrieval-augmented question answering บน PDF วิทยาศาสตร์พร้อม agentic loop อยู่ด้านบน: agent ตัดสินใจว่าเมื่อไหร่จะค้นหาใน library ของคุณ รวบรวม evidence chunk สรุปความเกี่ยวข้องของมัน แล้วประกอบคำตอบพร้อมการอ้างอิง สิ่งนั้น map เข้ากับ LLM slot ที่ตั้งค่าแยกกันได้สามช่อง summary_llm ประเมินและย่อ evidence ต่อ chunk ที่ retrieve มา ซึ่งทำให้มันเป็นช่องปริมาณ llm เขียนคำตอบสุดท้ายจาก evidence ที่ประกอบแล้ว ซึ่งเป็นขั้นตอนที่คุณภาพสำคัญ และ agent_llm (ข้างใน agent settings) ตัดสินใจเลือก tool ที่ชี้นำ loop ทั้งสามช่องมีค่าเริ่มต้นเป็นโมเดล OpenAI และแต่ละช่องมีฟิลด์ _config คู่กัน (llm_config, summary_llm_config, agent_llm_config) ที่รับ dict router เดียวกัน ดังนั้น config gateway หนึ่งชิ้นสามารถผูกกับแต่ละช่องได้ ในขณะที่ชื่อโมเดลต่อช่องยังเป็นอิสระต่อกัน การแบ่งที่พบบ่อยคือ id ที่เร็วสรุป evidence และ id ระดับ frontier เขียนคำตอบ ทั้งคู่ผ่าน endpoint และ key เดียว embedding คือ workload ที่สี่และแยกออกมาโดยตั้งใจ: การตั้งค่า embedding (ค่าเริ่มต้น text-embedding-3-small) สร้าง vector index ของ paper คุณ การย้ายช่องแชทไปที่ gateway ไม่ได้ย้าย embedding ไปด้วย และ paper-qa รองรับ sentence-transformers แบบ local (prefix st- ผ่าน local extras) ถ้าคุณต้องการให้ index เป็นอิสระจาก endpoint ระยะไกลใด ๆ อย่างสมบูรณ์
ตั้งค่าแบบเต็ม: Settings พร้อม config ต่อช่อง
รูปแบบเต็มประกาศ router entry หนึ่งตัวต่อโมเดลที่คุณต้องการเรียกใช้ได้ แล้วผูก config ทีละช่อง การประกาศสอง entry ตัวหนึ่งเร็วสำหรับสรุปและอีกตัวแข็งแกร่งสำหรับคำตอบ เก็บการตั้งค่าทั้งหมดไว้ใน dict เดียว การ routing เดียวกันทำงานได้จาก CLI ด้วย เพราะ pqa เปิด settings surface แต่เส้นทาง Python คือเส้นทางที่ทำซ้ำได้สำหรับงานวิจัย: object Settings ที่สร้างคำตอบสามารถถูกบันทึกไว้ข้าง ๆ คำตอบนั้นเอง
import os
from paperqa import Settings, ask
from paperqa.settings import AgentSettings
def entry(model_id, **params):
return dict(
model_name=model_id,
litellm_params=dict(
model=f"openai/{model_id}",
api_base="https://api.apisrouter.com/v1",
api_key=os.getenv("APISROUTER_API_KEY"),
**params,
),
)
gateway = dict(model_list=[
entry("claude-sonnet-4-6", temperature=0.1),
entry("claude-haiku-4-5-20251001", temperature=0.1),
])
answer = ask(
"What is the evidence for LK-99 room-temperature superconductivity?",
settings=Settings(
llm="claude-sonnet-4-6",
llm_config=gateway,
summary_llm="claude-haiku-4-5-20251001",
summary_llm_config=gateway,
agent=AgentSettings(
agent_llm="claude-sonnet-4-6",
agent_llm_config=gateway,
),
paper_directory="./papers",
),
)เลือกโมเดลต่อช่อง
ปรับจูนโดย fix evidence pipeline ไว้: library เดียวกัน คำถามเดียวกัน สลับทีละช่อง หลัง endpoint เดียว ผู้สมัครแต่ละคนคือสตริง model_name และ usage log ต่อ key ตั้งราคาแต่ละ configuration ต่อคำถาม ซึ่งเป็นตัวเลขที่ lab ใช้ตั้งงบประมาณจริง
- summary_llm รันหนึ่งครั้งต่อ evidence chunk ทุกคำถาม บน library จริงจังนี่คือส่วนใหญ่ของ call ทั้งหมด ดังนั้น id ที่เร็ว (claude-haiku-4-5-20251001) ตั้งพื้นต้นทุนของทั้งระบบ ในขณะที่ต้องแค่ตัดสินความเกี่ยวข้อง ไม่ใช่เขียนร้อยแก้ว
- llm ประกอบคำตอบพร้อมการอ้างอิงจาก evidence ที่ประกอบแล้ว นี่คือจุดที่การเขียนวิทยาศาสตร์แบบ hedge และแม่นยำเกิดขึ้นหรือไม่เกิด claude-sonnet-4-6 และ gpt-5.5 คือตัวเลือกที่ไว้ใจได้ และช่องนี้มี call น้อยต่อคำถาม ดังนั้นพรีเมียมมีขอบเขต
- agent_llm ชี้นำ loop: จะค้นหาซ้ำ, รวบรวม evidence เพิ่ม หรือตอบ การตัดสินใจที่อ่อนแอตรงนี้เสีย token ทุกที่อื่น ทำให้ id ระดับกลางหรือดีกว่าเป็นตัวเลือกที่คุ้มค่าแม้ปริมาณของช่องนี้จะต่ำ
- id แบบ context ยาวอย่าง gemini-3.1-pro-preview คุ้มค่าที่จะทดสอบเป็นช่องคำตอบเมื่อคำถามดึง evidence จากหลาย paper พร้อมกัน
จ่ายตามการใช้งาน · ถูกกว่าราคาทางการ
Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.
| โมเดล | ราคาทางการ | ราคาของเรา |
|---|---|---|
| Claude Sonnet 4.6 | $3.00 / $15.00 per M | $2.40 / $12.00 per M |
| Claude Haiku 4.5 20251001 | $1.00 / $5.00 per M | $0.80 / $4.00 per M |
| GPT-5.5 | $5.00 / $30.00 per M | $4.00 / $24.00 per M |
| Gemini 3.1 Pro Preview | $2.00 / $12.00 per M | $1.60 / $9.60 per M |
| GLM-5.2 | $1.14 / $4.00 per M | $1.10 / $4.00 per M |
รูปแบบความล้มเหลวเฉพาะของ paper-qa
ช่องที่ปล่อยไว้ที่ค่าเริ่มต้น การตั้ง llm และ llm_config แต่ไม่ตั้ง summary_llm_config จะปล่อยให้การสรุปอยู่บนโมเดล OpenAI ค่าเริ่มต้น ซึ่งจะขอ OPENAI_API_KEY แล้วล้มเหลว (หรือแบ่ง routing ของคุณไปสองอย่างเงียบ ๆ ระหว่างสอง endpoint ถ้า key นั้นมีอยู่) แต่ละช่องมีฟิลด์ _config ของตัวเอง ผูก dict ของ gateway กับทุกช่องที่คุณตั้งใจจะย้าย รวม agent_llm_config ด้วย ชื่อที่ไม่ตรงกัน Settings.llm ต้องเท่ากับ model_name หนึ่งใน model_list; litellm_params.model คือสิ่งที่ไปบนสายจริง ๆ ถ้าชื่อภายนอกไม่ตรง router จะไม่มีเส้นทาง ถ้า id ภายในพิมพ์ผิด gateway จะคืน model-not-found เมื่อดีบัก ตรวจสอบสองสตริงนี้แยกกันเพราะพวกมันล้มเหลวต่างกัน การสมมติว่า embedding จะตามไปด้วย ช่อง embedding สร้างและ query vector index และมีค่าเริ่มต้นและ config ของตัวเอง ถ้าคุณไม่มี key OpenAI สำหรับ embedding ค่าเริ่มต้น ให้ตั้งค่า embedding อย่างชัดเจน หรือใช้ sentence-transformers แบบ local ผ่าน prefix st- การเปลี่ยน endpoint ของ embedding ในภายหลังยังหมายถึงการ re-index ด้วย: vector จากโมเดล embedding ต่างกันไม่ผสมกัน ขาดขีดจำกัด generation สำหรับคำตอบยาว litellm_params รับ max_tokens ต่อ entry และตัวอย่าง local-endpoint ต้นทางก็ตั้งค่ามันอย่างตั้งใจ ช่องคำตอบที่ไม่มีขีดจำกัดที่สมเหตุสมผลอาจตัดคำตอบพร้อมอ้างอิงที่ยาวทิ้ง ซึ่งดูเหมือนโมเดลอ่อนแอแต่จริง ๆ เป็นพารามิเตอร์ การโทษ routing สำหรับปัญหา parsing คุณภาพของ paper-qa ขึ้นกับการ parse และแบ่งชิ้น PDF ก่อนที่โมเดลใดจะเห็นข้อความ ถ้าคำตอบไม่อ้างอิงอะไรเลยบน library ที่คุณรู้ว่าเกี่ยวข้อง ตรวจสอบขั้นตอน indexing gateway เห็นแค่สิ่งที่ retrieval ส่งให้มันเท่านั้น
ใครที่ route paper-qa ผ่าน gateway
- กลุ่มวิจัยที่รัน literature QA บน library ที่ใช้ร่วมกัน ที่ usage ต่อ key เปลี่ยน "lab ใช้เท่าไหร่ต่อคำถาม" จากการเดาให้เป็นรายงาน
- ทีมที่ต้องการงานเขียนวิทยาศาสตร์คุณภาพ Claude ในช่องคำตอบ ในขณะที่เก็บปริมาณการสรุปไว้บน id ที่เร็ว ทั้งคู่บน key เดียว
- builder ที่ฝัง paper-qa ในเครื่องมือภายใน แทนที่ bundle ของ secret vendor ด้วย credential ของ gateway เดียวต่อ environment
- ผู้ทำ benchmark ที่เปรียบเทียบโมเดลคำตอบบน evidence pipeline ที่ fix ไว้ ที่ผู้สมัครแต่ละคนคือสตริง config ไม่ใช่การผสาน vendor
- นักพัฒนาที่ไม่มีสิทธิ์เข้าถึงระบบเก็บเงินของ vendor รายหนึ่ง การเข้าถึงแบบเติมเงินโดยไม่ต้องใช้บัตรตัดการพึ่งพาการสมัครต่อ provider ออกไป
ตรวจสอบ endpoint และ debug คำถามแรก
ยืนยันว่า gateway เสิร์ฟ id ที่คุณประกาศไว้ สตริง litellm_params.model หลัง openai/ ต้องตรงกับ id ที่เสิร์ฟจริงเป๊ะ ลำดับความล้มเหลวบน ask() แรก: error ที่ขอ OPENAI_API_KEY หมายความว่ามีช่องหนึ่งยังอยู่บนโมเดลค่าเริ่มต้นโดยไม่มี config ผูกไว้ หาว่า llm, summary_llm หรือ agent_llm ตัวไหนที่คุณยังไม่ได้ย้าย 401 จาก gateway คือ api_key ข้างใน litellm_params error router เกี่ยวกับโมเดลที่ไม่รู้จักหมายความว่า Settings.llm ไม่ตรงกับ model_name ใดใน list ความล้มเหลวระหว่าง indexing แทนที่จะเป็นตอนตอบชี้ไปที่การตั้งค่า embedding หรือ PDF parsing ไม่ใช่ chat routing คำถามหนึ่งกระจายเป็น call สรุปจำนวนมากบวกขั้นตอน agent บวกคำตอบสุดท้าย ดังนั้นหลังการรันสำเร็จครั้งแรก มุมมองต่อ request ของ console APIsRouter แสดงการแบ่งช่องเป็น token จริง นั่นคือตัวเลขที่ควรเฝ้าดูเมื่อ library ใหญ่ขึ้น เพราะปริมาณการสรุปขยายตาม evidence ที่ retrieve มา ไม่ใช่แค่จำนวนคำถามอย่างเดียว
curl -s https://api.apisrouter.com/v1/models \
-H "Authorization: Bearer $APISROUTER_API_KEY" | head -50คำถามที่พบบ่อย
paper-qa รองรับ custom OpenAI-compatible base URL อย่างไร?
ผ่าน config router ของ LiteLLM: llm_config, summary_llm_config และ agent_llm_config แต่ละอันรับ model_list ที่ litellm_params ของมันมี api_base และ api_key นี่คือรูปแบบเดียวกับที่ paper-qa มีเอกสารระบุสำหรับ OpenAI-compatible server แบบ local ที่โฮสต์เอง เพียงแต่ชี้ไปที่ URL ของ gateway แทน
โมเดลคำตอบและสรุปมาจากคนละ vendor ได้ไหม?
ได้ แต่ละช่องจับคู่ชื่อโมเดลกับ config ของตัวเอง ดังนั้น id ของ Claude ที่เร็วสามารถสรุป evidence ในขณะที่ GPT-5.5 หรือ Gemini เขียนคำตอบสุดท้าย ทั้งหมดผ่าน api_base และ key เดียว ประกาศ model_list entry หนึ่งต่อ id แล้วอ้างอิงต่อช่อง
ฉันต้องเปลี่ยนโมเดล embedding ด้วยไหม?
ไม่ต้อง และปกติไม่ควรทำในขั้นตอนเดียวกัน การตั้งค่า embedding เป็นอิสระจากช่องแชท และการเปลี่ยนโมเดล embedding ทำให้ vector index ที่มีอยู่ใช้ไม่ได้ ถ้าคุณไม่มี key สำหรับ embedding ค่าเริ่มต้น ให้ตั้ง embedding อย่างชัดเจน หรือใช้ sentence-transformers แบบ local พร้อม prefix st-
ช่อง agent_llm คืออะไร และต้องมี config ด้วยไหม?
agent_llm ข้างใน AgentSettings ขับเคลื่อนการเลือก tool: จะค้นหา, รวบรวม evidence หรือตอบเมื่อไหร่ มันมีค่าเริ่มต้นเป็นโมเดล OpenAI เหมือนช่องอื่น ดังนั้นผูก agent_llm_config ด้วย dict ของ gateway เดียวกัน ไม่เช่นนั้นมันจะยังพยายาม route ไปที่ provider ค่าเริ่มต้นอยู่
ทำไม paper-qa ยังขอ OPENAI_API_KEY หลังจากฉัน override แล้ว?
อย่างน้อยหนึ่งช่องยังอยู่บนโมเดลค่าเริ่มต้นโดยไม่มี router config ผูกไว้ ตรวจสอบ llm, summary_llm และ agent_llm บวกฟิลด์ _config ของแต่ละตัว error จะระบุชื่อโมเดลที่มันพยายามเรียก ซึ่งบอกช่องที่คุณพลาดไป
ใช้ได้จาก CLI ของ pqa เหมือนกับ Python ไหม?
CLI เปิด settings surface เดียวกัน แต่สำหรับ gateway routing เส้นทาง Python เป็นทางที่ใช้ได้จริงกว่า: dict router ใช้เป็น command-line flag ยาก และ object Settings ที่บันทึกไว้ข้าง ๆ ผลลัพธ์ทำให้การรันงานวิจัยทำซ้ำได้