รัน FinRobot บน custom OpenAI-compatible endpoint

คำตอบสั้น ๆ: หนึ่ง entry ใน OAI_CONFIG_LIST

คำแนะนำการตั้งค่าของ FinRobot ให้คุณเปลี่ยนชื่อ OAI_CONFIG_LIST_sample เป็น OAI_CONFIG_LIST แล้วกรอก credential ไฟล์นั้นเป็น config list แบบมาตรฐานของ AutoGen: array แบบ JSON ที่แต่ละ entry รับ model และ api_key และตามต้องการคือ base_url ซึ่งไฟล์ sample ที่มาพร้อมระบบก็แสดงตัวอย่างสำหรับ endpoint ที่ไม่ใช่ค่าเริ่มต้นอยู่แล้ว เพิ่ม entry ที่มี key ของ gateway และ base_url ตั้งเป็น https://api.apisrouter.com/v1 แล้ว agent ทุกตัวของ FinRobot ที่โหลดไฟล์นี้จะ route ผ่านมันได้ มีจุดหนึ่งที่ทำให้คนเสียเวลา: tutorial โหลดไฟล์ผ่าน autogen.config_list_from_json พร้อม filter_dict ที่เลือก entry ตามชื่อโมเดล ถ้า entry ใหม่ของคุณบอกว่า claude-sonnet-4-6 แต่ filter ยังขอ id GPT ของ sample entry ของคุณจะถูกกรองออกและการรันจะล้มเหลวบน credential เก่า อัปเดต filter_dict ให้ตรงกับโมเดลที่คุณเพิ่ม หรือปล่อย filter ไว้ตอนทดสอบ

[
    {
        "model": "claude-sonnet-4-6",
        "api_key": "sk-YOUR-APISROUTER-KEY",
        "base_url": "https://api.apisrouter.com/v1"
    }
]

FinRobot ใช้ config LLM ของมันอย่างไร

FinRobot (AI4Finance-Foundation บน GitHub มีดาวประมาณ 7.6K) คือแพลตฟอร์ม AI agent สำหรับการวิเคราะห์การเงินที่สร้างบน AutoGen (pyautogen 0.2.19 หรือใหม่กว่า) agent ของมันคือ workflow แบบสำเร็จรูป: forecaster Market_Analyst ที่ดึงข่าวและ fundamentals ของบริษัทแล้วทำนายการเคลื่อนไหวสัปดาห์หน้า ผู้เขียนรายงานประจำปีที่เปลี่ยน filing เป็น PDF งานวิจัยหุ้น และ agent QA แบบ retrieval-augmented บนการประชุมผลประกอบการและ SEC filing แต่ละ tutorial สร้างรูปทรง llm_config เดียวกัน: dict ที่ config_list มาจาก autogen.config_list_from_json ที่อ่านไฟล์ OAI_CONFIG_LIST llm_config นั้นถูกส่งให้ wrapper class อย่าง SingleAssistant และ SingleAssistantShadow จาก finrobot.agents.workflow ซึ่งเป็นเจ้าของ agent ของ AutoGen ที่อยู่ข้างใต้ การตัดสินใจเรื่อง endpoint จึงอยู่ในไฟล์ JSON ทั้งหมด: OpenAI client ของ AutoGen ส่ง request /v1/chat/completions ไปยัง base_url ใดก็ตามที่ entry ที่เลือกไว้มี และส่งฟิลด์ model ผ่านเป็นสตริงธรรมดา สตริงธรรมดานั้นคือชัยชนะเชิงปฏิบัติ เมื่อ endpoint หลัง base_url เสิร์ฟหลาย vendor id ของ Claude, DeepSeek หรือ Qwen จะขี่ไปกับ config ทรง OpenAI เดียวกันโดยที่ FinRobot ไม่สังเกตเห็นเลย และการสลับโมเดลวิเคราะห์กลายเป็นการแก้ JSON หนึ่งบรรทัดบวก filter_dict ที่ตรงกัน

ตั้งค่าแบบเต็ม: ไฟล์ config, filter และ key ข้อมูล

FinRobot แบ่ง credential ไว้สองไฟล์ และมีแค่ไฟล์เดียวที่เกี่ยวกับ LLM OAI_CONFIG_LIST เก็บ endpoint และ key ของโมเดล config_api_keys เก็บ credential ข้อมูลตลาด (FINNHUB_API_KEY, FMP_API_KEY, SEC_API_KEY และ key โซเชียล) ที่โหลดแยกต่างหากผ่าน register_keys_from_json การ route LLM ผ่าน gateway เปลี่ยนไฟล์แรกและปล่อยไฟล์ที่สองไว้เหมือนเดิม ดังนั้นการดึงข่าว, fundamentals และ filing ทำงานเหมือนเดิมทุกอย่าง รูปแบบ tutorial ด้านล่างคือโครงสร้างของ notebook forecaster ที่เลือก entry ของ gateway ไว้แล้ว llm_config เดียวกันใช้ได้กับ tutorial รายงานประจำปีและ RAG ซึ่งต่างกันแค่ workflow class ที่มัน instantiate

import autogen
from finrobot.utils import register_keys_from_json
from finrobot.agents.workflow import SingleAssistant

llm_config = {
    "config_list": autogen.config_list_from_json(
        "../OAI_CONFIG_LIST",
        filter_dict={"model": ["claude-sonnet-4-6"]},  # match your entry
    ),
    "timeout": 120,
    "temperature": 0,
}

register_keys_from_json("../config_api_keys")  # finnhub/fmp/sec data keys

assistant = SingleAssistant("Market_Analyst", llm_config,
                            human_input_mode="NEVER")
assistant.chat("Analyze NVDA news this week and predict next week's movement.")

เลือกโมเดลตาม workflow ของ FinRobot

loop การทดลองที่สะอาด: fix ticker และช่วงวันที่ รัน workflow เดียวกันหนึ่งครั้งต่อ entry ผู้สมัคร แล้วเปรียบเทียบ output เคียงข้างกัน หลัง endpoint เดียว ผู้สมัครแต่ละคนคือการแก้ filter_dict และ usage log ต่อ key ให้บิล token ต่อผู้สมัครโดยไม่ต้องทำงานสเปรดชีต

• ผู้เขียนรายงานประจำปีคืองาน reasoning ที่หนักที่สุด: มันอ่านส่วนของ filing สังเคราะห์ thesis การลงทุน และร่างรายงานที่มีโครงสร้าง claude-opus-4-7 หรือ gpt-5.5 ใน workflow นั้นคือจุดที่คุณภาพ output เปลี่ยนไปอย่างเห็นได้ชัด
• forecaster ตลาดคืองานที่สั้นกว่าและทำซ้ำบ่อยกว่าบนข่าวและ fundamentals claude-sonnet-4-6 หรือ deepseek-v4-pro จัดการได้ดี และสำคัญเมื่อคุณรันมันทุกวันข้าม watchlist
• RAG QA บนการประชุมผลประกอบการคือการ retrieve บวกการสังเคราะห์บนข้อความยาว ซึ่งเข้าทาง id แบบ context ยาว gemini-3.1-pro-preview คุ้มค่าที่จะทดสอบเทียบกับ claude-sonnet-4-6 ตรงนั้น
• เพราะ entry ถูกเลือกด้วย filter_dict คุณสามารถเก็บไฟล์เดียวที่มี entry แบบ frontier และ entry แบบเร็วกับ base_url เดียวกัน แล้วเลือกต่อ notebook แทนการแก้ credential ต่อการรัน
• model id เป็นสตริงที่ต้องตรงเป๊ะ FinRobot ส่งผ่านมันโดยไม่ตรวจสอบ ดังนั้นรายการ /v1/models ของ endpoint คือการสะกดที่น่าเชื่อถือ

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

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

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

filter_dict ที่ไม่ตรงกันคือปัญหาใหญ่ config_list_from_json คืนแค่ entry ที่ model ตรงกับ filter เท่านั้น filter ที่ไม่ตรงกับอะไรเลยจะเกิด error เรื่อง config list ว่างเปล่า และ filter ที่ตรงกับ entry เก่าของ sample จะส่ง request ไปยัง OpenAI ด้วย key ตัวอย่าง ซึ่งแสดงออกมาเป็น 401 จาก host ที่ผิด เมื่อการเปลี่ยน routing ดูเหมือนไม่มีผล ให้พิมพ์ config_list ที่ resolve แล้วออกมาดูก่อน path แบบ relative คือปัญหาที่สอง tutorial โหลด "../OAI_CONFIG_LIST" เพราะ notebook อยู่ต่ำกว่า root ของ repo หนึ่งระดับ สคริปต์ที่ root ต้องการ "OAI_CONFIG_LIST" แทน และ AutoGen ก็รับตัวแปร environment OAI_CONFIG_LIST ที่ถือสตริง JSON ด้วย ซึ่งเลี่ยงปัญหา path ใน container ได้ บรรทัด comment คือปัญหาที่สาม คำแนะนำการตั้งค่าบอกให้คุณลบ comment ออกจากไฟล์ sample เพราะมันทำให้ JSON ไม่ถูกต้อง JSONDecodeError ตอน startup หมายความว่ามี comment หลงเหลืออยู่ credential ข้อมูลล้มเหลวแยกต่างหาก ถ้า agent แชทได้ปกติแต่ข่าวหรือ fundamentals กลับมาว่างเปล่า นั่นคือปัญหา config_api_keys (Finnhub, FMP, SEC) ไม่ใช่ปัญหา endpoint และโมดูล FinRobot Pro equity แยกต่างหากตั้งค่า key ของมันผ่าน config.ini แทน ณ กรกฎาคม 2026 การตั้งค่าที่มีเอกสารระบุของมันครอบคลุม openai_api_key แต่ไม่มี base-URL override ดังนั้นถือว่าโมดูลนั้นเป็นแบบ direct-vendor จนกว่า upstream จะระบุตัวหนึ่งไว้

ใครที่ route FinRobot ผ่าน gateway

• นักวิเคราะห์ที่สร้างรายงานหุ้นข้ามรายการ coverage context filing ที่ยาวต่อรายงานทำให้ความต่างราคาต่อโมเดลมีนัยสำคัญ และ endpoint เดียวทำให้โมเดลเป็นตัวเลือกต่อการรัน
• ทีม quant ที่รัน forecaster ทุกวันบน watchlist ที่ id ระดับกลางที่เร็วเก็บบิลประจำไว้คงที่โดยไม่ต้องเขียน workflow ใหม่
• นักวิจัยที่เปรียบเทียบตระกูลโมเดลบนงานการเงินเดียวกัน ผู้สมัครแต่ละคนคือ config entry เดียว ไม่ใช่การสลับบัญชี vendor และ SDK
• ทีมที่ทำมาตรฐานให้ stack ที่ใช้ AutoGen FinRobot แชร์ธรรมเนียม OAI_CONFIG_LIST กับโปรเจกต์ AutoGen อื่น ๆ ดังนั้นรูปแบบ entry ของ gateway เดียวใช้ได้กับทุกตัว
• นักพัฒนาที่ไม่มีสิทธิ์เข้าถึงระบบเก็บเงินของ vendor รายหนึ่ง การเข้าถึงแบบเติมเงินโดยไม่ต้องใช้บัตรตัดการพึ่งพาการสมัครต่อ provider ออกไป

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

ลิสต์โมเดลที่ key ของคุณเรียกใช้ได้ก่อนเปิด notebook สตริงโมเดลทุกตัวใน OAI_CONFIG_LIST และค่า filter_dict ทุกค่าต้องตรงกับ id ที่เสิร์ฟจริงเป๊ะ จากนั้นรันแชทที่สั้นที่สุดผ่าน SingleAssistant แล้วเฝ้าดู console 401 หมายความว่า api_key ของ entry ที่เลือกไม่ได้เป็นของ endpoint ใน base_url ของมัน ตรวจสอบว่า filter เลือก entry ไหนจริง ๆ error model-not-found คือ id พิมพ์ผิดใน entry connection error มักหมายความว่า base_url สูญเสีย suffix /v1 ถ้า agent วนลูปโดยไม่มีผล tool ให้สงสัย key ใน config_api_keys ไม่ใช่ LLM endpoint เมื่อ request ไหลลื่นแล้ว console ของ APIsRouter แสดงโมเดลต่อ request, จำนวน token และค่าใช้จ่าย การรันเขียนรายงานคือบทสนทนาหลาย turn ที่ยาว และมุมมอง usage แสดงว่ารายงานหนึ่งฉบับมีต้นทุนจริงเท่าไหร่ก่อนที่คุณจะตั้งเวลารันห้าสิบฉบับ

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

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