PostHog ปล่อย Jeeves — โมเดลตัดสินใจแบบ Jev ขนาด 9B ที่คิดก่อนตอบ ได้ 0.935 บน JevBench สาธารณะ (Jev 0.866) แต่ต้องแลกกับ latency 3.3 วินาที

กระแส “decision model” ที่เริ่มจาก Jev ของ TypeSafe ได้ตัวใหม่อีกตัว เมื่อ 29 ก.ย. PostHog เปิด repo Jeeves (ขึ้นหน้าแรก Hacker News วันเดียวกัน) เป็นโมเดลขนาด 9B บน Qwen3.5-9B ที่ต่างจาก Kev, Intern-Decision และตัวอื่นก่อนหน้า ตรงที่ เขียน reasoning chain ก่อนตัดสินใจ แทนการตอบจาก forward pass เดียว

ตาม README แนวคิดคือ โมเดลแบบ Jev ให้ความน่าจะเป็นที่ calibrate ดี แต่ความแม่นยังต่ำ ระบบจำนวนมากจึงต้องใช้ reasoning model ตัวใหญ่เป็นตัวสำรอง Jeeves จึงรวมสองอย่างไว้ในโมเดลเดียว ใช้ API แบบเดียวกับ Jev (POST /v1/systemone) รองรับคำถาม yes/no (noul), ตัวเลือก (choice) และให้คะแนน (score) ในคำขอเดียว และมี jeeves_sdk ที่ใช้แทน SDK ของ TypeSafe ได้ทันที

ตัวเลข: ชนะในงานใช้เหตุผล แพ้ในงานความรู้

ทุกตัวเลขเปิด thinking, greedy และจำกัด 2,560 โทเคน คอลัมน์ Kev-9B กับ Jev เป็นตัวเลขที่ Kev เผยแพร่ไว้

ชุดทดสอบ	Kev-9B	Jev	Jeeves
Test overall (นอกโดเมน + held-out)	0.822	0.857	0.889
JevBench overall (231 ข้อสาธารณะ)	0.715*	0.866	0.935
JevBench hard (111 ข้อ)	0.451*	0.730	0.865
JevBench ECE (ยิ่งต่ำยิ่งดี)	–	0.049	0.037
MMLU	0.738	0.900	0.793
MMLU-Pro (10 ตัวเลือก)	0.515	0.840	0.739

* เป็นตัวเลขของ Kev-8B (Qwen3) เพราะไม่มีผล Kev-9B บน JevBench

ข้อควรระวังที่ README เขียนไว้เอง: ตัวเลข JevBench ใช้เฉพาะชุดสาธารณะ ไม่รวม sealed judge tier และการเทียบกับ Kev/Jev นอก JevBench ใช้ข้อทดสอบคนละชุดจากแหล่งเดียวกัน ถ้าปิด thinking โมเดลเดียวกันได้ 0.804 บนชุด test ของตัวเอง เทียบกับ 0.840 เมื่อเปิด

ต้นทุนของการคิด และวิธีลด

ความแม่นที่เพิ่มขึ้นมาพร้อม latency บน H100 ตัวเดียว (FP8) ที่ 325 ข้อของชุด dev

การตั้งค่า	ความแม่น	reasoning tokens เฉลี่ย	latency มัธยฐาน / p90
คิดเต็มที่	0.825	1,138	3.3 s / 17.1 s
max_think 768 + nothink_threshold 0.9	0.806	344	2.0 s / 5.6 s
ไม่คิด	0.775	0	~0.3 s

nothink_threshold ให้โมเดลตอบทันทีเมื่อความมั่นใจแบบไม่คิดสูงพอ และคิดเฉพาะข้อที่ยาก ส่วนที่ทำให้ช่วงคิดเร็วขึ้นคือ diffusion drafter แบบ block-4 ที่ดัดแปลงจาก Orthrus ให้ใช้กับ Gated DeltaNet ของ Qwen3.5 ได้ เพิ่มความเร็วจาก 109 เป็น 176 โทเคนต่อวินาที (1.6×) สำหรับคำถามเดียว และราว 960 โทเคนต่อวินาทีเมื่อรวม 8 คำถาม

โครงสร้างและการเทรน

• สถาปัตยกรรม: Qwen3.5-9B + LoRA (r=16) + pointer head ที่ให้คะแนนแต่ละตัวเลือกจาก hidden state ที่ตำแหน่ง <decide> เทียบกับตำแหน่งท้ายตัวเลือก แล้ว softmax ด้วย temperature ที่ fit ไว้ (1.859)
• การเทรน: SFT 2 epochs บน 19,126 คำถามจาก 12 ชุดข้อมูลสาธารณะรวมกับข้อมูลสังเคราะห์ ตามด้วย RL แบบ CISPO (วิธีจาก MiniMax-M1) ที่หยุดที่ step 402 จาก 624 เพราะหลังจากนั้น head เริ่มมั่นใจเกินจริง
• License: โค้ดบน GitHub เป็น MIT ส่วนน้ำหนักบน Hugging Face เป็น Apache-2.0 ตาม Qwen3.5-9B ต้องรันผ่านโค้ด Jeeves เพราะโหลดด้วย transformers ตรง ๆ ไม่ได้ ต้องใช้ GPU CUDA (kernel FP8 ต้องการ Hopper) และมีสคริปต์เทรนซ้ำครบบน 8 GPU

มุมมอง AI Curator

ในสองสัปดาห์ที่ผ่านมาเราเขียนถึง decision model แบบเปิดไปหลายตัว แต่ Jeeves เป็นตัวแรกที่ตั้งคำถามนี้ตรง ๆ: ความเร็ว 30 ms เป็นสิ่งที่งานทุกงานต้องการจริงหรือ งานอย่างคัดแยก ticket ตรวจ policy หรือตัดสินว่าจะ escalate ให้คนดูหรือไม่ ส่วนใหญ่รอ 2–3 วินาทีได้ แต่ต้องการความแม่นในข้อยาก ตัวเลข JevBench hard ที่ขึ้นจาก 0.730 เป็น 0.865 จึงมีความหมายกว่าอันดับบนตาราง ส่วนข้อจำกัดด้านความรู้ (MMLU แพ้ Jev ชัด) ก็บอกว่าขนาด 9B มีขีดจำกัด การคิดนานขึ้นไม่ช่วยให้โมเดลรู้สิ่งที่ไม่มีอยู่ในน้ำหนัก

ที่น่าสนใจคือผู้ปล่อยเป็น PostHog บริษัท product analytics ไม่ใช่แล็บ AI บริษัทที่มีปัญหาจัดหมวดข้อมูลปริมาณมากเริ่มเทรนโมเดลเฉพาะงานเองแล้วเปิดสู่สาธารณะ ข้อนี้ทีมไทยทำตามได้ base model เป็น Qwen3.5 ที่รองรับหลายภาษา และสคริปต์ prep/ กับ train.py ครบพอให้ใส่ข้อมูลตัดสินใจภาษาไทยของตัวเอง เช่น ticket ลูกค้าหรือข้อความรีวิว แล้วเทรนซ้ำ ต้นทุนสูงสุดอยู่ที่การเตรียมชุด test ที่เชื่อถือได้ ส่วนการเช่า GPU 8 ตัวไม่กี่ชั่วโมงเป็นต้นทุนที่เล็กกว่า ข้อควรระวังคือ README บอกเองว่า reasoning chain ไม่ได้ถูกบังคับภาษา จึงอาจอ่านไม่ออก ใช้ตรวจย้อนหลังได้จำกัด

แหล่งข่าว

• PostHog/jeeves — GitHub (โค้ด, ผลทดสอบ, MIT)
• PostHog/jeeves — Hugging Face (น้ำหนัก 9B, Apache-2.0)
• Jeeves. Reasoning improves Jev-like decision models — Hacker News