รัน gpt-researcher บน custom OpenAI-compatible endpoint

คำตอบสั้น ๆ: บล็อก .env ห้าบรรทัด

เส้นทาง custom-endpoint ที่มีเอกสารระบุของ gpt-researcher คือตัวแปร environment ตั้ง OPENAI_BASE_URL เป็น https://api.apisrouter.com/v1 ตั้ง OPENAI_API_KEY เป็น key ของ gateway แล้วกำหนดสามช่องโมเดลด้วย prefix provider openai: prefix บอก gpt-researcher ว่าจะใช้ client ตัวไหน ส่วนสตริงหลังเครื่องหมายจุดสองจุดถูกส่งผ่านไปยัง endpoint ดังนั้น id ใดก็ตามที่ gateway เสิร์ฟใช้ได้ รวมถึง id ของ Claude และ Gemini นี่คือการตั้งค่าที่มีเอกสารระบุที่ docs.gptr.dev สำหรับ custom OpenAI-compatible endpoint และมันทำงานเหมือนกันทั้งสำหรับ pip package, เว็บแอป และ flow แบบ multi-agent เพราะทั้งหมดนี้ resolve config เดียวกัน

OPENAI_BASE_URL=https://api.apisrouter.com/v1
OPENAI_API_KEY=sk-APIsRouter-...
FAST_LLM=openai:claude-haiku-4-5-20251001
SMART_LLM=openai:claude-sonnet-4-6
STRATEGIC_LLM=openai:gpt-5.5

gpt-researcher ใช้ token ข้ามสามช่องอย่างไร

gpt-researcher (assafelovic บน GitHub มีดาวประมาณ 28K) เปลี่ยน query ให้เป็นรายงานที่วิจัยแล้วพร้อมการอ้างอิง: มันวางแผนคำถามวิจัย กระจายการค้นหาเว็บผ่าน retriever, scrape และสรุปแหล่งข้อมูล แล้วเขียนรายงานแบบยาว framework นี้แบ่ง pipeline นั้นออกเป็นสามช่องโมเดลที่ตั้งค่าแยกกันได้ แทนที่จะเป็นช่องเดียว FAST_LLM จัดการงานปริมาณสูงความเสี่ยงต่ำ ส่วนใหญ่คือการสรุปหน้าที่ scrape มา SMART_LLM ทำงานเขียนหนัก รวมถึงรายงานสุดท้าย STRATEGIC_LLM จัดการวางแผน: สร้างคำถามวิจัยและตัดสินใจแนวทาง ค่าเริ่มต้นของทั้งสามช่องนี้คือโมเดล OpenAI (gpt-4o-mini, gpt-4.1 และ o4-mini ตามลำดับ ณ เวลาที่เขียน) ซึ่งเป็นเหตุผลที่การ override ด้วย OPENAI_BASE_URL ตัวเดียวได้ผลมาก: ทั้งสามช่องใช้ client ทรง OpenAI ดังนั้น base URL เดียวย้ายทั้ง pipeline เพราะแต่ละช่องรับสตริง provider:model ของตัวเอง ช่องเหล่านั้นไม่จำเป็นต้องใช้ vendor เดียวกัน การรันหนึ่งครั้งสามารถสรุปด้วยโมเดล Claude ที่เร็ว เขียนด้วยโมเดล Claude หรือ GPT ที่แข็งแกร่งกว่า และวางแผนด้วยโมเดลระดับ reasoning ทั้งหมดผ่าน endpoint และ key เดียวกัน บน key ของ vendor เดียว การผสมแบบนี้ต้องใช้สามบัญชี หลัง gateway มันคือสามบรรทัดใน .env

ตั้งค่าแบบเต็ม: .env บวก Python API

สร้างไฟล์ .env ในไดเรกทอรีทำงานของคุณ (หรือ export ตัวแปรใน shell) แล้วรัน gpt-researcher ตามปกติ ทั้ง pip package และเว็บแอปอ่าน environment เดียวกัน Python API ไม่ต้องการโค้ดเฉพาะ endpoint เลย ซึ่งคือประเด็น: routing คือ configuration และโค้ดวิจัยเหมือนเดิมไม่ว่า endpoint จะเป็นของ OpenAI หรือ gateway มีการตั้งค่าข้างเคียงสองอย่างที่สำคัญ การดึงเว็บรันผ่าน retriever ค่าเริ่มต้นคือ Tavily พร้อม key ของตัวเอง (TAVILY_API_KEY) credential นั้นเป็นอิสระจาก LLM endpoint และยังจำเป็นสำหรับการวิจัยเว็บแบบสด และ embedding ค่าเริ่มต้นคือ openai:text-embedding-3-small ซึ่งหมายความว่าการเรียก embedding ตามการตั้งค่า client ทรง OpenAI เดียวกัน ถ้า endpoint หลัง OPENAI_BASE_URL ไม่เสิร์ฟ embedding model นั้น ให้ตั้งค่า EMBEDDING เป็น provider ที่เสิร์ฟ (เอกสารใช้ prefix custom: สำหรับ OpenAI-compatible embedding endpoint และตัวเลือก local อย่าง Ollama ก็รองรับด้วย)

import asyncio
from gpt_researcher import GPTResearcher

async def main():
    researcher = GPTResearcher(
        query="State of small modular reactors in 2026",
        report_type="research_report",
    )
    await researcher.conduct_research()
    report = await researcher.write_report()
    print(report)

asyncio.run(main())  # routing comes entirely from .env

เลือกโมเดลต่อช่อง

ค่าเริ่มต้นจากต้นทางเข้ารหัสรูปทรงที่ถูกต้องไว้แล้ว: โมเดลเล็กสำหรับปริมาณ โมเดลแข็งแกร่งสำหรับการเขียน โมเดล reasoning สำหรับการวางแผน ดังนั้นรักษารูปทรงนั้นไว้และอัปเกรดช่องแทนที่จะทำให้ทุกอย่างแบนเป็นโมเดลเดียว หลัง endpoint เดียว การ A/B ระหว่างนักเขียนสองคนคือการเปลี่ยน .env หนึ่งบรรทัดต่อการรัน และ usage log ต่อ key บอกคุณว่าแต่ละการตั้งค่ารายงานมีต้นทุนจริงเท่าไหร่

• FAST_LLM ยิงมากที่สุด: ทุกแหล่งที่ scrape มาถูกสรุป id ที่เร็ว (claude-haiku-4-5-20251001, deepseek-v4-flash) ป้องกันไม่ให้รายงานที่มีหลายแหล่งถูกครอบงำด้วยต้นทุนการสรุป และการสูญเสียคุณภาพตรงนี้มีขอบเขตเพราะสรุปป้อนให้นักเขียน ไม่ใช่ผู้อ่าน
• SMART_LLM เขียนรายงานที่ผู้ใช้อ่านจริง output ยาว โครงสร้างที่ต่อเนื่อง วินัยการอ้างอิง: นี่คือจุดที่ claude-sonnet-4-6 หรือ gpt-5.5 คุ้มค่ากับที่จ่ายไป และจุดที่การลดคุณภาพจะเห็นผลทันที
• STRATEGIC_LLM กำหนดรูปทรงการรันก่อนเริ่ม คำถามวิจัยที่แย่ทำให้รายงานแย่ไม่ว่านักเขียนจะเก่งแค่ไหน โมเดลที่ reasoning แข็งแกร่งตรงนี้คือ call น้อยแต่มี leverage สูง
• id แบบ context ยาวอย่าง gemini-3.1-pro-preview คุ้มค่าที่จะทดสอบในช่อง SMART สำหรับ detailed_report ที่นักเขียนทำงานบน context สรุปที่สะสมไว้จำนวนมาก

จ่ายตามการใช้งาน · ถูกกว่าราคาทางการ

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

รูปแบบความล้มเหลวเฉพาะของ gpt-researcher

การทิ้ง prefix provider รูปแบบของช่องคือ provider:model และ prefix เลือก client การตั้ง SMART_LLM=claude-sonnet-4-6 โดยไม่มี openai: ไม่ได้ route id ของ Claude ผ่าน base URL ของคุณ มันทำให้ gpt-researcher พยายามตีความสตริงนั้นเป็น provider อื่น ทุกโมเดลของ custom endpoint ต้องคง prefix openai: ไว้ เพราะ "openai" ที่นี่ระบุ protocol ไม่ใช่ vendor embeddings แอบตาม override ไปด้วยอย่างเงียบ ๆ EMBEDDING ค่าเริ่มต้นคือโมเดลทรง OpenAI ดังนั้นเมื่อ OPENAI_BASE_URL ชี้ไปที่ gateway แล้ว request embedding ก็ไปที่นั่นด้วย ถ้า gateway ไม่เสิร์ฟ embedding id นั้น การรันวิจัยจะล้มเหลวระหว่างการประมวลผลแหล่งข้อมูลแทนที่จะเป็นตอนเรียก chat ครั้งแรก ซึ่งทำให้คนดีบักผิดช่อง ตั้ง EMBEDDING อย่างชัดเจนแล้วอาการนี้จะหายไป การโทษ endpoint สำหรับความล้มเหลวของ retriever TAVILY_API_KEY ที่หายไปหรือหมดโควตาจะทำให้เฟสค้นหาพัง และ error แหล่งข้อมูลว่างเปล่าที่ตามมาดูเผิน ๆ เหมือนความล้มเหลวของ LLM retriever เป็นบริการแยกที่มี key แยก ตรวจสอบแยกกัน environment ที่ค้างจากการรันก่อนหน้า ไฟล์ .env ถูกอ่านจากไดเรกทอรีทำงาน การรันเว็บแอปจากไดเรกทอรีหนึ่งและ Python API จากอีกไดเรกทอรีหนึ่งหมายถึง config สองชุดที่ต่างกัน และ "มันทำงานในแอปแต่ไม่ทำงานในสคริปต์ของฉัน" มักเป็นเรื่องนี้เกือบทุกครั้ง การตั้งค่า token-limit แยกจากความสามารถของโมเดล gpt-researcher มี token limit ต่อช่องของตัวเอง (FAST_TOKEN_LIMIT, SMART_TOKEN_LIMIT และการตั้งค่าที่เกี่ยวข้อง) พร้อมค่าเริ่มต้นที่ระมัดระวัง การชี้ SMART_LLM ไปที่โมเดล context ยาวไม่ได้ยกขีดจำกัดเหล่านั้นขึ้นเองโดยอัตโนมัติ ปรับมันอย่างตั้งใจถ้าคุณต้องการ generation ที่ยาวขึ้น

ใครที่ route gpt-researcher ผ่าน gateway

• ทีมที่สร้างรายงานซ้ำ ๆ (market scan, literature review, brief คู่แข่ง) ที่การมองเห็นต้นทุนต่อการรันข้ามสามช่องโมเดลสำคัญกว่าความสัมพันธ์กับ vendor เดียว
• นักวิจัยที่เปรียบเทียบโมเดลนักเขียน คง FAST และ STRATEGIC ไว้คงที่ในขณะที่สลับ SMART ระหว่าง id ของ Claude, GPT และ DeepSeek คือการแก้ .env สามครั้ง ไม่ใช่สามบัญชี vendor
• builder ที่ฝัง gpt-researcher ในผลิตภัณฑ์ ที่ key ของ gateway หนึ่งตัวต่อ environment แทนที่ bundle ของ secret vendor ใน deploy pipeline
• ผู้ใช้ที่ต้องการให้ Claude หรือ Gemini เขียนรายงานในขณะที่คงการตั้งค่าทรง OpenAI มาตรฐานของ gpt-researcher ไว้เหมือนเดิม
• นักพัฒนาที่ไม่มีสิทธิ์เข้าถึงระบบเก็บเงินของ vendor รายหนึ่ง การเข้าถึงแบบเติมเงินโดยไม่ต้องใช้บัตรตัดการพึ่งพาการสมัครต่อ provider ออกไป

ตรวจสอบ endpoint และ debug รายงานแรก

ลิสต์โมเดลของ gateway ก่อน สตริงหลัง openai: ในแต่ละช่องต้องตรงกับ id ที่เสิร์ฟจริงเป๊ะ รวม suffix เวอร์ชันด้วย ความล้มเหลวในการรันครั้งแรกแยกได้ชัดเจน 401 หมายความว่า OPENAI_API_KEY ไม่มีอยู่ใน environment ที่ process เห็นจริง ไฟล์ .env โหลดจากไดเรกทอรีทำงาน ดังนั้นรันจากที่ไฟล์อยู่หรือ export ตัวแปรแบบ global error model-not-found ระบุชื่อช่องที่พิมพ์ผิด ความล้มเหลวระหว่างการประมวลผลแหล่งข้อมูลแทนที่จะเป็นตอนวางแผนชี้ไปที่ embeddings หรือ retriever ไม่ใช่ช่องแชท ตรวจสอบ EMBEDDING และ TAVILY_API_KEY ก่อนแตะ config ของ LLM การรันวิจัยเต็มคือ burst ของ request หลายสิบครั้งข้ามทั้งสามช่อง ดังนั้นเมื่อรันเสร็จแล้ว มุมมองต่อ request ของ console APIsRouter คือวิธีที่เร็วที่สุดในการเห็นการแบ่ง FAST/SMART/STRATEGIC เป็น token และค่าใช้จ่ายจริง และจับช่องที่ใช้เกินกว่าที่บทบาทมันสมควรได้

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" | head -50

คำถามที่พบบ่อย