Kev — โมเดลตัดสินใจแบบ Jev ฉบับเปิด Apache-2.0 ขนาด 0.8B/4B/9B บน Qwen3.5 ใช้ API เดียวกับ TypeSafe ได้เลย แต่ Kev-9B ยังตาม Jev อยู่ 3.5 จุด

เมื่อ 15 ก.ย. TypeSafe AI เปิดตัว Jev โมเดลที่ไม่สร้างข้อความ คืนแค่คำตอบตาม schema พร้อมความน่าจะเป็น แต่เปิดแบบ waitlist ไม่บอกขนาด และไม่มีเบนช์มาร์กสาธารณะ สองวันถัดมา (17 ก.ย.) Jared Palmer ผู้สร้าง Turborepo และ Formik เปิด repo ชื่อ Kev ซึ่งเป็นโมเดลตระกูลเดียวกันที่ใครก็รันเองได้ ตอนนี้มีสามขนาดคือ 0.8B, 4B และ 9B บน Qwen3.5 Base เป็น Apache-2.0 ทั้งโค้ด น้ำหนัก และชุดประเมิน repo นี้ขึ้นหน้าแรก Hacker News ในวันที่ 21 ก.ย. และมีดาวเกิน 2,600 แล้ว

สิ่งที่น่าสนใจที่สุดไม่ใช่ว่า Kev ชนะ Jev (มันไม่ชนะ) แต่เป็นความโปร่งใส README เขียนตัวเลขที่ Kev แพ้ไว้ตรง ๆ แยกชุด dev กับ test ชัดเจน และบอกว่าชุด test ถูกอ่าน “ครั้งเดียวต่อ checkpoint หลังเลือกโมเดลเสร็จแล้ว” ซึ่งเป็นสิ่งที่ Jev เองยังไม่ได้ให้

ทำงานอย่างไร

แต่ละ checkpoint คือ LoRA adapter rank 16 บวก pointer head ขนาดเล็ก ที่ติดอยู่บนโมเดล Qwen ส่วนน้ำหนักของ base ไม่ถูกแตะ ข้อความ state กับคำถามจะถูกเรียงเป็น token แบบนี้ <state> … <q> คำถาม <opt> ตัวเลือก </opt> … <decide> จากนั้น pointer head จะให้คะแนนแต่ละตัวเลือกโดยเทียบ hidden state ของ </opt> กับของ <decide> แล้วผ่าน softmax เพื่อได้ความน่าจะเป็น

• คำถาม 3 แบบในคำขอเดียว: noul (ความน่าจะเป็นที่คำตอบคือ yes), choice (1–255 ตัวเลือก) และ score (ระดับที่เรียงลำดับ คืนค่าเฉลี่ยของระดับ)
• คำถามแยกกันจริง: ทุกคำถามอ่าน state ร่วมกันได้แต่มองไม่เห็นคำถามอื่น บน Qwen3 ทำได้ด้วย attention mask แต่ Qwen3.5 มีเลเยอร์ Gated DeltaNet ที่เป็น recurrent และไม่สนใจ mask เลยต้องรันคำถามละแถว แล้ว cache ส่วน state ไว้ใช้ซ้ำ
• Calibrate มาให้แล้ว: แต่ละ checkpoint เก็บค่า temperature (ประมาณ 2.1–2.4) ไว้ ทำให้ calibration error ของ Kev-9B บนข้อมูลชุดใหม่ลดจาก 0.106 เหลือ 0.042 โดยคำตอบไม่เปลี่ยน
• เข้ากับ API ของ TypeSafe: endpoint POST /v1/systemone มีรูปแบบเดียวกับ System One ชี้ base_url ของ SDK TypeSafe มาที่ localhost:8009 ได้เลย ผู้เขียนระบุด้วยว่า “No Jev outputs were used for training”

รันได้ใน 2 บรรทัดด้วย uv sync --extra serve แล้ว python -m kev.serve --run jaredpalmer/kev-4b บน CUDA, ROCm และ Apple Silicon รุ่น 4B และ 9B แบบ bf16 ใส่ Mac 32GB ได้

ตัวเลข: ใกล้ แต่ยังไม่ถึง

ตาราง accuracy บนข้อมูลจาก “แหล่งใหม่” ที่ไม่ได้ใช้เทรน (dev / test):

โมเดล	Accuracy (แหล่งใหม่)	Brier (แหล่งใหม่, ต่ำ = ดี)
Kev-0.8B	0.652 / 0.684	0.499 / 0.460
Kev-4B	0.797 / 0.837	0.299 / 0.255
Kev-9B	0.822 / 0.852	0.286 / 0.237
Jev (hosted)	0.857 / –	0.211 / –

Kev-9B ตาม Jev อยู่ 3.5 จุดบนชุด dev ส่วนชุด test ยังเทียบไม่ได้เพราะยังไม่เคยรัน Jev บนชุดนั้น และผู้เขียนเตือนเองว่า “this isn’t a controlled comparison” เพราะไม่รู้ว่า Jev เทรนด้วยข้อมูลอะไร

ช่องว่างที่ชัดที่สุดคือ คำถามเชิงความรู้: MMLU ได้ 0.74 เทียบ Jev 0.90 และ MMLU-Pro ได้ 0.52 เทียบ 0.84 README บอกว่าส่วนนี้ขึ้นกับ base model และลองเทรนบน Qwen3.5-35B-A3B แล้วตัวเลขก็ไม่ขยับ อีกจุดที่ต้องระวังคือ สัดส่วนของการตัดสินใจที่ปล่อยอัตโนมัติได้ ที่ error budget 5% ซึ่ง Kev ได้ 0.45–0.57 ส่วน Jev ได้ 0.70 ในงานจริงนี่คือตัวเลขที่ชี้ว่าจะลดงานคนได้แค่ไหน

ชุดทดสอบภายนอกสองชุดที่มีผล Jev เผยแพร่ไว้แล้วให้ภาพที่ต่างกัน บนชุด support ticket 900 ใบของ scienthoon Kev-9B ได้ 0.952 ในการจัดเส้นทาง ticket ซึ่งสูงกว่า Jev ที่ได้ 0.897 (ส่วนการอ่านน้ำเสียงลูกค้าได้ 0.911 ใกล้กับ Jev ที่ 0.914) แต่บนชุด 144 ข้อที่เขียนขึ้นเองของ SemIf Kev-9B ได้ 0.917 ส่วน Jev ได้ 0.965 แปลว่าในงานแคบ ๆ ที่มีโครงชัด โมเดลเปิดขนาด 9B ใช้แทนได้แล้ว แต่ในงานที่ต้องใช้เหตุผลมากกว่า Jev ยังนำอยู่

ข้อจำกัดที่ต้องรู้ก่อนใช้

• ช้าบน Mac: DeltaNet ยังไม่มี kernel เร็วบน Apple Silicon เลยต้องใช้โค้ดอ้างอิงของ PyTorch ทำให้ Kev-4B ตอบคำขอ 5 คำถามใน 779ms เทียบกับรุ่น Qwen3 เดิมที่ 174ms ถ้าต้องการ latency ต่ำบน Mac ผู้เขียนแนะนำให้ใช้รุ่น Qwen3 (kev-4b@qwen3) ไปก่อน ส่วน backend MLX เป็นงานถัดไป
• ลำดับตัวเลือกยังมีผล: การแยกคำถามไม่ได้ป้องกันเรื่องนี้ มี endpoint /permute ไว้ทดสอบ
• เซิร์ฟเวอร์รับได้ทีละคำขอ ไม่มี batching และ bind ที่ 127.0.0.1 แบบไม่มี auth
• Context ที่เทรนสั้น: เทรนด้วย state ไม่เกิน 384 token แม้ตอนเสิร์ฟจะรับได้ถึง 8,192 token
• ต้องใช้ transformers >= 5.17

สำหรับคนที่อยากปรับใช้กับงานตัวเอง repo มีเส้นทาง fine-tune ด้วย JSONL รูปแบบเดียวกับคำขอ API แค่เพิ่ม label แล้วใช้ --init_from jaredpalmer/kev-4b ต่อยอดจาก checkpoint ที่ปล่อยออกมา บนรุ่น 0.8B ใช้ GPU แค่ 4GB ตัวอย่างใน README แสดงว่าการเริ่มจาก base เปล่าทำให้คะแนนบนชุดประเมินเดิมตกจาก 0.84 เหลือ 0.33 แต่ถ้าเริ่มจาก checkpoint ที่ปล่อยมาจะยังรักษาไว้ได้ 0.83 และขึ้นเป็น 0.88 บนโดเมนใหม่ นอกจากนี้ยังมี agent skill kev-finetune ที่ติดตั้งด้วย npx skills add jaredpalmer/kev@kev-finetune เพื่อให้ coding agent ทำขั้นตอนทั้งหมดบน Modal

มุมมอง AI Curator

Kev เปลี่ยนคำถามเรื่อง Jev จาก “แนวคิดนี้ใช้ได้ไหม” เป็น “แนวคิดนี้มีมูลค่าเท่าไร” ภายในหนึ่งสัปดาห์ เพราะเมื่อมีโมเดลเปิดขนาด 9B ที่ตามหลังแค่ 3.5 จุด สิ่งที่ TypeSafe ต้องขายจริง ๆ คือส่วนต่างนั้น (บวก calibration ที่ดีกว่าและความรู้ของโมเดลที่ใหญ่กว่า) ไม่ใช่ตัวสถาปัตยกรรม และการที่งานนี้สร้างจาก blog post ที่แกะสถาปัตยกรรมของ Jev ร่วมกับเอกสาร API สาธารณะ ก็ย้ำอีกครั้งว่าความได้เปรียบจากสถาปัตยกรรมเพียงอย่างเดียวอยู่ได้ไม่นานในปี 2026

ข้อที่ควรชมคือวิธีรายงาน การ freeze ชุด test แล้วอ่านครั้งเดียว การใส่ confidence interval และการเขียนตัวเลขที่แพ้ไว้ในตารางหลัก ควรเป็นมาตรฐานของทุกการปล่อยโมเดล และดีกว่าหลาย lab ใหญ่ที่เราเพิ่งเห็นตัวเลขประกาศกับตัวเลขที่วัดอิสระห่างกันเป็นสิบจุด

สำหรับทีมไทย งานประเภทจัดเส้นทาง ticket ตรวจนโยบาย หรือคัดกรองเอกสาร เป็นงานที่เหมาะกับ Kev ที่สุด เพราะรันในเครื่องได้ ข้อมูลลูกค้าไม่ต้องออกนอกองค์กร (ช่วยเรื่อง PDPA) และจ่ายแค่ค่าไฟ ข้อควรระวังคือชุดเทรนทั้งหมดเป็นภาษาอังกฤษ README เองก็แนะนำว่าถ้าใช้ภาษาอื่นควร fine-tune ด้วยตัวอย่างที่ติด label สักไม่กี่ร้อยชิ้น และไม่ควรเชื่อ threshold 0.9 จนกว่าจะวัดกับข้อมูลภาษาไทยของตัวเอง

แหล่งข่าว

• jaredpalmer/kev — GitHub (README, ตาราง benchmark, ข้อจำกัด)
• Kev-9B — Hugging Face model card
• Kev demo — Hugging Face Spaces
• TypeSafe System One API docs