หนึ่งวันหลัง TypeSafe เปิด Jev ก็มีคนทำ Jevlike ออกมาแจกฟรีใต้ MIT — สถาปัตยกรรม one-pass option scoring ที่เปิดโค้ดทั้งหมด พร้อมเดโม Doom กับหมากรุก และคำสารภาพว่ายังไม่ได้พิสูจน์ว่าเทียบเท่า

16 ก.ย. 2026 เวลา 10:26 UTC — ราว 15 ชั่วโมงหลังTypeSafe AI เปิดตัว Jev และคลาสโมเดลที่เรียกว่า System One Models พร้อมคำอ้างว่าเร็วกว่า 193.6 เท่าและถูกกว่า 444.6 เท่า แต่ไม่เปิดสถาปัตยกรรม ไม่เปิดเบนช์มาร์กสาธารณะ และเปิดรับแค่ waitlist — มีนักพัฒนาชื่อบัญชี vinnylarouge สร้าง repo ชื่อ jevlike ขึ้นบน GitHub ใต้สัญญาอนุญาต MIT ปล่อยทั้งโค้ดเทรน โค้ดประเมินผล และ checkpoint

repo เขียนสิ่งที่มันเป็นและไม่เป็นไว้ตรงไปตรงมาในย่อหน้าแรก: “Jev is TypeSafe’s commercial model for this kind of task. TypeSafe has not published its design. This repository is an independent starter model with the same input and output shape.” — ไม่ใช่การแกะ Jev ออกมา แต่เป็นการสร้างของที่รับเข้า-คืนออกในรูปแบบเดียวกัน แล้วเปิดให้ทุกคนดูว่ามันทำงานยังไง ณ เวลาที่เขียน repo นี้มี 428 ดาว

สถาปัตยกรรมที่เปิดให้เห็น: option คือ query, ไม่ใช่ token ที่ต้องเขียนออกมา

หัวใจของ System One Models ที่ TypeSafe อธิบายไว้กว้าง ๆ คือ “ไม่สร้างสตริง” jevlike แสดงให้เห็นว่าเวอร์ชันที่เรียบที่สุดของแนวคิดนี้หน้าตาเป็นอย่างไร และมันสั้นกว่าที่คิด:

1. ตัวเลือกแต่ละตัวถูกแปลงเป็น query vector
2. query นั้นกระจาย attention weight ไปบน context token
3. weight เหล่านั้นประกอบเป็น context vector หนึ่งตัวต่อหนึ่งตัวเลือก
4. dot product ที่ใช้ร่วมกันแปลงคู่ (ตัวเลือก, context) เป็นคะแนนเดียว
5. softmax รันข้ามตัวเลือก ไม่ใช่ข้าม vocabulary

ผลลัพธ์คือความน่าจะเป็นของทุกตัวเลือกที่รวมกันได้ 1 ใน การประมวลผลรอบเดียว แทนที่จะให้ decoder เขียนคำตอบทีละโทเคน และเพราะ softmax รันข้ามรายการตัวเลือกที่ส่งเข้ามาตอนนั้น รายการจึงเปลี่ยนได้ทุกครั้ง — แต่ละแถวของข้อมูลมีจำนวนตัวเลือกไม่เท่ากันได้ ขั้นต่ำสองตัว

encoder เริ่มต้นเรียน byte embedding จากศูนย์ ตัด context ที่ 192 ไบต์และแต่ละตัวเลือกที่ 32 ไบต์ (ปรับได้ด้วย --context-tokens / --option-tokens) หรือจะเสียบ encoder ที่เทรนแล้วจาก Hugging Face แบบแช่แข็งน้ำหนักก็ได้ — README ยกตัวอย่างด้วย Qwen/Qwen2.5-0.5B โดย checkpoint จะเก็บแค่ scorer head ที่เทรน ไม่ก๊อป encoder มาด้วย รันได้ทั้ง CPU, Apple MPS และ CUDA

รูปแบบข้อมูลคือ JSONL บรรทัดละหนึ่งอ็อบเจกต์ ซึ่งอ่านแล้วเข้าใจทันทีว่าโมเดลคลาสนี้เอาไปทำอะไร:

{"context":"The customer needs a refund.","options":["refund","sales","technical support"],"label":0}

CLI มีสี่ตัว: jevlike-data สร้างข้อมูลสังเคราะห์, jevlike-train, jevlike-eval และ jevlike-predict

ตัวเลขที่รายงาน และ control ที่ทำให้ตัวเลขนั้นอ่านออก

สิ่งที่ทำให้ repo นี้น่าเชื่อกว่าประกาศของ TypeSafe เองในบางแง่ คือมันรายงานผลพร้อม control และแยกให้ชัดว่าตัวเลขไหนมาจากไหน README เขียนกำกับว่า “These numbers describe local experiments, not this quickstart run”:

• เมนูสังเคราะห์: ความแม่นราว 98%
• Wikispeedia (ข้อมูล next-click จริงจาก SNAP ของ West & Leskovec, WWW 2012) แบบแยก target ไม่ให้ปนกัน: encoder Qwen2.5-0.5B แบบแช่แข็ง + scorer ได้ 26% เทียบกับ control ที่สลับ context และ control ที่ใช้ encoder สุ่ม ซึ่งได้ราว 8%
• โมเดลเล็กที่เทรนจากศูนย์บนคลิก 40,000 ครั้ง ได้ 29% — สูงกว่าการเสียบ encoder ใหญ่แบบแช่แข็ง
• ที่ 8 ตัวเลือก การทำ pass เดียวเร็วกว่า decoder เล็กที่ถูกบังคับให้เขียน 400 โทเคนราว 100 เท่า

jevlike-eval เองก็พิมพ์ top-1, top-3, expected calibration error และ shuffled-context control ออกมาทุกครั้ง พร้อมประโยคกำกับว่า “A useful model should beat that control” — คือบังคับให้คนที่รันเห็นเส้นฐานควบคู่กับตัวเลขของตัวเองเสมอ ซึ่งเป็นสิ่งที่ประกาศโมเดลเชิงพาณิชย์แทบไม่เคยทำ

เดโม Doom กับหมากรุก ที่กล้าโชว์ว่าตัวเองแพ้

jevlike.vision ใช้ option-attention head ตัวเดียวกันให้คะแนนปุ่มคอนโทรลเลอร์จาก image patch ได้ และ repo ปล่อยฟิล์มสิบวินาทีที่ต่อจากสอง window: การยิงใน deadly_corridor ของ Doom บนปุ่ม 7 ปุ่ม แล้วต่อด้วยคอนโทรลเลอร์หมากรุกที่เดินหมากด้วยปุ่ม 5 ปุ่ม

แต่สิ่งที่น่าชมคือตัวเลขที่แปะมาด้วย:

• checkpoint แบบ joint บน Doom: เฉลี่ย 0.60 kills และ reward -97.50 ตลอด 10 episode ที่บันทึก
• checkpoint เฉพาะหมากรุก: ชนะ 4 เสมอ 46 แพ้ 0 ใน 50 เกมที่สุ่มมาแข่งกับผู้เล่นที่เดินสุ่ม แต่ ชนะ 0 เสมอ 2 แพ้ 48 เมื่อเจอ Stockfish ระดับ 0
• README ระบุเองว่า window ที่เลือกมา “were selected for activity and are not typical-play or competence claims”

ส่วน Limitations เขียนไว้หกข้อ รวมถึง “This is a research starter, not a copy of Jev”, “The byte encoder is cheap but weak on language meaning”, “One-pass scoring requires the complete option list before prediction” และข้อที่สำคัญที่สุดสำหรับการอ่านตัวเลขข้างบน: “The speed comparison used a small local decoder rather than a large commercial model”

มุมมอง AI Curator

เมื่อวานผมเขียนถึง Jev ด้วยความระแวง เพราะทุกตัวเลขที่ TypeSafe อ้าง — 193.6 เท่า, 444.6 เท่า, hallucination 0% — เป็นเบนช์มาร์กที่บริษัทออกแบบเอง รันเอง ตัดสินเองด้วย ground truth ที่เป็นค่าเฉลี่ยของ Astra กับ Fable และไม่มีใครตรวจสอบได้เพราะโมเดลอยู่หลัง waitlist วันนี้มีคนตอบคำถามที่สำคัญที่สุดไปแล้วหนึ่งข้อ: แนวคิดนี้ทำงานได้จริง และมันไม่ได้ซับซ้อนอย่างที่ประกาศทำให้รู้สึก

นี่คือสิ่งที่วัฒนธรรมโอเพนซอร์สทำได้และการตลาดทำไม่ได้ ระยะเวลา 15 ชั่วโมงจากประกาศถึง repo ที่รันได้จริงเป็นบทเรียนเรื่องความเร็วของการทำซ้ำในยุคนี้ แต่บทเรียนที่ผมคิดว่าสำคัญกว่าคือ มันแยกสองอย่างที่ประกาศของ TypeSafe มัดรวมกันไว้ออกจากกันได้ — แยก “สถาปัตยกรรม one-pass option scoring” ซึ่งกลายเป็นของสาธารณะไปแล้ววันนี้ ออกจาก “โมเดลระดับ frontier ที่เทรนด้วยวิธี RLCD ที่ TypeSafe ไม่เปิด” ซึ่งยังเป็นของเขาอยู่ ใครที่อ่านข่าวเมื่อวานแล้วคิดว่า TypeSafe มีคูเมืองทางเทคนิค วันนี้ควรปรับความคิดใหม่ว่าคูเมืองอยู่ที่ข้อมูลและการเทรน ไม่ใช่ที่รูปทรงของโมเดล

สำหรับนักพัฒนาไทย ผมคิดว่านี่คือของที่ควรลองมือมากกว่าที่ควรอ่านผ่าน เพราะงานที่คลาสโมเดลนี้เกิดมาแก้คืองานที่ทีมไทยทำกันเยอะมาก: routing, classification, การเลือกหนึ่งตัวเลือกจากรายการที่เปลี่ยนไปเรื่อย ๆ — จัดสายลูกค้าเข้าแผนก, แมปข้อความเข้า intent, เลือก SKU จากแคตตาล็อกที่อัปเดตทุกวัน, เลือก tool ถัดไปให้ agent งานพวกนี้ทุกวันนี้ถูกยัดใส่ LLM ตัวใหญ่ที่ถูกขอให้ตอบเป็น JSON แล้วจ่ายค่า token ขาออกกับ latency ของการ decode ทีละโทเคนไปฟรี ๆ ทั้งที่คำตอบมีแค่ไม่กี่สิบความเป็นไปได้ ตัวเลข Wikispeedia ที่ 26% เทียบกับ control 8% ไม่ใช่ตัวเลขที่สวย แต่มันมาจากงานจริงที่มีตัวเลือกเยอะและเป็น open data ที่คุณดาวน์โหลดมารันซ้ำได้เอง — และที่สำคัญคือ โมเดลเล็กที่เทรนจากศูนย์บนคลิก 40,000 ครั้งได้ 29% ซึ่งชนะการเสียบ encoder ใหญ่แบบแช่แข็ง สัญญาณนี้ตรงกับสิ่งที่เราเห็นซ้ำ ๆ ในปีนี้: สำหรับ task แคบ ๆ ที่มีข้อมูลของตัวเอง ของเล็กที่เทรนตรงงานชนะของใหญ่ที่ยืมมา และ 40,000 แถวคือจำนวนที่ทีมไทยขนาดกลางมีอยู่แล้วใน log

แต่ต้องพูดข้อจำกัดให้ครบด้วย ตัวเลขทั้งหมดในนี้เป็นการทดลองของผู้เขียนคนเดียวบนเครื่องตัวเอง ไม่มีใครรีวิว ไม่มี paper และเปรียบเทียบความเร็ว 100 เท่ากับ decoder เล็ก ๆ ในเครื่อง ไม่ใช่กับโมเดลเชิงพาณิชย์จริง — ซึ่งผู้เขียนเขียนไว้เองใน Limitations ข้อสุดท้าย และข้อจำกัดเชิงออกแบบที่ใหญ่ที่สุดคือ คุณต้องรู้รายการตัวเลือกทั้งหมดก่อนทำนาย นั่นตัดงานสร้างข้อความ งานสรุป และงานที่พื้นที่คำตอบเปิดออกทั้งหมด คลาสโมเดลนี้จึงไม่ได้มาแทน LLM แต่มาเป็นชั้นที่ควรอยู่ ก่อน LLM ในสถาปัตยกรรมของคุณ

ที่ผมชอบที่สุดคือประโยคที่ repo ยอมเขียนออกมาเอง: “We did not show equal quality with Jev or reproduce TypeSafe’s private training method.” กับตัวเลขหมากรุกที่แพ้ Stockfish ระดับ 0 ไป 48 จาก 50 เกม ในสัปดาห์ที่เราเพิ่งเขียนถึงทั้งเบนช์มาร์กที่พองเพราะ sandbox รั่วและโมเดลที่ปล่อยตัวเลขของตัวเองโดยไม่ให้ใครตรวจ การเจอ README ที่กล้าโชว์ว่าตัวเองแพ้ตรงไหน คือมาตรฐานการรายงานที่ควรเป็นค่าเริ่มต้น ไม่ใช่ข้อยกเว้นที่ต้องมาชม

แหล่งข่าว

• vinnylarouge/jevlike — Train a small model that chooses among a changing list of text options (MIT), GitHub, 16 ก.ย. 2026
• Introducing System One Models and Jev — TypeSafe AI, 15 ก.ย. 2026
• Wikispeedia navigation paths — SNAP, Stanford (West & Leskovec, WWW 2012)
• บทความก่อนหน้าของเรา: TypeSafe AI เปิด Jev — โมเดลที่ยอมทิ้งความสามารถในการสร้างสตริง