RSI-Jev คืออะไร? วงจรที่พัฒนาตนเองซึ่งสร้างโมเดลการตัดสินใจสไตล์ Jev

RSI-Jev เป็นโครงการวิจัยเปิดของบุคคลที่สามที่สร้างโมเดลการตัดสินใจ System One สไตล์ Jev และโมเดลที่หน้านี้ว่าด้วยคือรุ่น 4B ของมัน RSI-Jev v6.0-VL ลงวันที่ 2026-10-06 เขียนโดย Shanghua Gao (@gasvn) โดยมี Sufian (@SufianTA) ได้รับเครดิตในกิตติกรรมประกาศของรีโพซิทอรี และมันไม่ใช่ Jev ของ TypeSafe และไม่มีความเกี่ยวข้องกับ TypeSafe AI — บรรทัดสัญญาอนุญาตของโครงการเองระบุไว้อย่างนั้นเลย แนวคิดข้างใต้มันแคบพอที่จะพูดเป็นประโยคเดียว: ถามคำถามแบบกำหนดชนิดคำตอบเกี่ยวกับเอกสาร แชต หรือภาพ — ใช่/ไม่ใช่ เลือกหนึ่งจาก k ให้คะแนนตามรูบริก — และ forward pass หนึ่งครั้งจะคืนค่าความน่าจะเป็นที่ปรับเทียบแล้วสำหรับทุกตัวเลือก ไม่มีอะไรถูกสร้างขึ้น จึงไม่มี reasoning token ที่ต้องใช้จ่าย และไม่มีการใช้จ่ายเลย v6.0-VL ไม่ใช่รุ่นแรกของโครงการ มันเป็นรุ่นที่เจ็ดในสิบสองวัน ซึ่งเป็นสิ่งสำคัญที่สุดเพียงอย่างเดียวที่ต้องเข้าใจเกี่ยวกับมัน เพราะข้อมูลที่มีประโยชน์ตรงนี้อยู่ที่รูปร่างของเส้นมากกว่าอยู่ที่ checkpoint ใด checkpoint หนึ่ง

มีสิ่งหนึ่งที่ต้องกล่าวก่อนตัวเลขใด ๆ ทั้งหมด เพราะมันกำหนดวันที่ให้กับตัวเลขเหล่านั้นทั้งหมด v6.0-VL ครองตำแหน่งหัวแถวอยู่เพียงหนึ่งวันเท่านั้น เมื่อวันที่ 2026-10-07 เวลา 07:56 UTC — เช้านี้เอง — โครงการได้เผยแพร่ RSI-Jev v6.1-VL ซึ่งเป็นค่าเฉลี่ยของ v6.0-VL โดยถ่วงน้ำหนักฝ่ายละ 0.5 ร่วมกับการ fine-tune ครั้งที่สองของ Qwen3.5-4B-Base ตัวเดียวกันที่ฝึกด้วยข้อมูลชุดอื่น และได้คะแนน 50.98 บนชุด Decision Index 0.3 ของโครงการ เทียบกับ 46.23 ของ v6.0-VL บนชุดเดียวกัน ไม่มีการฝึกใด ๆ หลังจากขั้นตอนการเฉลี่ยนั้น การสอบเทียบของมันแย่กว่าของ v6.0-VL และการ์ดของมันเองก็ระบุไว้เช่นนั้น การเผยแพร่ครั้งนั้นเป็นของจริงและเป็นปัจจุบัน หน้านี้ไม่ได้พูดถึงมัน ตัวเลขทุกตัวด้านล่างนี้อ่านมาจากบันทึกการเผยแพร่ของ v6.0-VL ลงวันที่ 2026-10-06 และในจุดที่จำนวนนับมีการเปลี่ยนแปลงไปตั้งแต่นั้น — จำนวนการเผยแพร่ จำนวนการทดลอง — หน้านี้จะแสดงทั้งตัวเลขในแบบที่มันเป็นสำหรับ v6.0-VL และตัวเลขในแบบที่มันเป็นอยู่ในวันนี้

สิ่งที่ RSI-Jev ไม่ใช่ก็ควรกล่าวไว้แต่เนิ่น ๆ เช่นกัน เพราะในบรรดาสมมติฐานที่ชัดเจนสามข้อนั้น มีสองข้อที่ผิด มันไม่ใช่ผลิตภัณฑ์แบบโฮสต์ที่คุณเรียกใช้ได้วันนี้ผ่าน API ทั่วไป และไม่ได้ให้บริการโดย OrcaRouter — แค็ตตาล็อกของเราไม่มีทั้ง id rsi-jev ไม่มี id shgao และไม่มีโมเดลการ์ดสำหรับมัน สิ่งเดียวที่เรามีคือโมเดลที่โปรเจกต์นี้ลอกสัญญา HTTP ของมันมา นั่นคือ Jev เชิงพาณิชย์ของ TypeSafe ซึ่งเราให้บริการในชื่อ typesafe/jev-1.13บนเอนด์พอยต์ systemone หนึ่งในสองตัวนั้นคุณเป็นฝ่ายเรียกใช้ ส่วนอีกตัวคุณดาวน์โหลดและให้บริการด้วยตัวเอง ทุกอย่างด้านล่างนี้มาจากรีโพซิทอรีของโปรเจกต์เอง การ์ดรีลีส และเอกสารการให้บริการ ซึ่งอ่านเมื่อ 2026-10-07 และในกรณีที่ตัวเลขใดเป็นของโปรเจกต์เองมากกว่าการวัดจากภายนอก หน้านี้จะระบุว่าเป็นของใคร

สิ่งที่มันทำจริง ๆ

โครงการนี้อธิบายตัวเองในหนึ่งบรรทัดว่า “ระบบวิจัยที่พัฒนาตนเองแบบเรียกซ้ำซึ่งสร้างโมเดล System One สไตล์ Jev” และอาร์ติแฟกต์ที่มันสร้างขึ้นนั้นเป็นตัวตัดสินใจ มากกว่าจะเป็นตัวสร้าง คุณป้อนสถานะให้มัน — เอกสาร บันทึกการสนทนา ธุรกรรม และในเวอร์ชัน vision สูงสุดถึงสี่ภาพ — พร้อมคำถามที่มีชนิดกำกับหนึ่งข้อหรือมากกว่า ซึ่งมีเกณฑ์ที่ระบุชื่อไว้ สำหรับแต่ละคำถาม มันจะคืนค่าความน่าจะเป็นสำหรับทุกตัวเลือก คำถามสามประเภทครอบคลุมพื้นที่นี้ และเป็นประเภทที่ API ของ TypeSafe กำหนดไว้:

• noul — การตัดสินแบบจริง/เท็จ ส่งกลับเป็นค่าความน่าจะเป็นค่าเดียว โดยไม่มีการแจกแจงและไม่มีค่าความเชื่อมั่น ตรงกับรูปแบบคำตอบของข้อมูลอ้างอิงอย่างแม่นยำ

• ตัวเลือก — เลือกหนึ่งตัวเลือกจากชุดตัวเลือกที่มีป้ายกำกับ ส่งคืนพร้อมการแจกแจงความน่าจะเป็นแบบเต็มและสถิติความเชื่อมั่น

• คะแนน — ให้คะแนนตามเกณฑ์แบบมีลำดับ ส่งกลับเป็นดัชนีฐานศูนย์ที่ถ่วงน้ำหนักด้วยความน่าจะเป็นไปยังระดับต่าง ๆ พร้อมทั้งคำอธิบายสัญลักษณ์และการกระจาย

เพราะไม่มีขั้นตอนการสร้างเอาต์พุต จึงไม่มีการเรียกโมเดลครั้งที่สองและไม่มีการสุ่มตัวอย่าง การตัดสินใจเกี่ยวกับเอกสารที่โมเดลได้อ่านไปแล้วนั้นเป็นปฏิบัติการที่มีต้นทุนต่ำโดยธรรมชาติของการออกแบบ และตัวเลขที่โครงการระบุเองสำหรับค่าใช้จ่ายนั้น — "ประมาณ 10 มิลลิวินาที" — เป็นของยุค 2B ไม่ใช่ของรีลีสปัจจุบัน; ตัวเลขที่วัดได้สำหรับ v6.0-VL ระบุไว้ด้านล่าง

สองข้อเท็จจริงเกี่ยวกับความเป็นเจ้าของสำคัญยิ่งกว่าสิ่งอื่นใดในหน้านี้ RSI-Jev ไม่ใช่ผลงานของ TypeSafe และ TypeSafe ไม่ได้ให้การรับรองมัน บรรทัดสัญญาอนุญาต ซึ่งยกมาทั้งหมด: "โค้ด: MIT. น้ำหนักโมเดล: Apache-2.0 ตามโมเดลฐาน; แหล่งข้อมูลฝึกอบรมภาพบางส่วนไม่ใช่เพื่อการพาณิชย์ โดยระบุไว้ในการ์ดโมเดลแต่ละใบ ไม่มีความเกี่ยวข้องกับ TypeSafe AI" และความสัมพันธ์เป็นไปในทางเดียว: โครงการนี้คัดลอกรูปแบบการส่งข้อมูล (wire format) ของ Jev อย่างจงใจ และบอกเช่นนั้น เพราะเซิร์ฟเวอร์ที่เข้ากันได้คือจุดมุ่งหมาย "Jev-style" เป็นคำของโครงการเองสำหรับประเภทของโมเดลที่มันสร้าง Jev ของ TypeSafe เป็นโมเดลเชิงพาณิชย์แบบปิดที่แตกต่างออกไป และทั้งสองไม่ใช่สิ่งเดียวกันภายใต้ชื่อที่สั้นกว่า

ภายในโมเดลปัจจุบัน: ทาวเวอร์ Qwen ขนาด 4B ที่มีทางออกสามทาง

RSI-Jev v6.0-VL เป็น tower ของ Qwen3.5-4B-Base โดย tower ได้รับการ fine-tune และมี decision head ที่ผ่านการฝึกวางอยู่ด้านบน นั่นคือสถาปัตยกรรมทั้งหมด — ไม่มี mixture of experts ไม่มี router และไม่มีโมเดลที่สอง มันรัน base model ทั้งหมด ซึ่งเป็นเหตุผลว่าทำไมจำนวนพารามิเตอร์จึงเป็น 4.69B และไม่ใช่จำนวนที่เล็กกว่า: 3.57B อยู่ใน 32 decoder layers, 0.64B อยู่ใน token embeddings, 0.33B อยู่ใน vision tower, 0.05B อยู่ใน main decision head และ 0.10B อยู่ใน early-exit heads สองตัว checkpoint ที่เผยแพร่เป็นแบบ self-contained และมีขนาด 9.7 GB ใน bf16

มีการติดตั้งหัวตัดสินใจสามหัวที่เลเยอร์ 16, 20 และ 32 ของฐาน และหัวเหล่านี้คือกลไกเบื้องหลังทุกสิ่งที่ทำให้รุ่นปัจจุบันเป็นที่รู้จัก จุดออกที่สี่ที่เลเยอร์ 12 ถูกสร้างขึ้น วัดผล และตัดทิ้ง — “จุดออกที่เลเยอร์ 12 แพ้ให้กับคาสเคดจาก 16 ในการเปรียบเทียบทุกครั้ง และไม่ได้อยู่ในแพ็กเกจ” — ดังนั้นสามจึงถูกส่งมอบ ส่วนสี่ไม่ถูกส่งมอบ จุดออกเหล่านี้อ่านสำเนาที่แยกออกมาต่างหากของเลเยอร์ตนเอง ซึ่งเป็นรายละเอียดที่โครงการค้นพบด้วยความยากลำบาก: การปรับจูนหัวบนทรังก์ที่จุดออกถูกติดไว้ระหว่างการฝึกไม่ได้กู้คืนความแม่นยำของเลเยอร์ลึก ดังนั้นการแยกพวกมันออกจึงเป็นสิ่งที่กู้คืนความลึก

ตัวเลขตัวเดียวตรงนี้เป็นวิธีที่ทำให้เข้าใจโครงการผิดได้ง่ายที่สุด ทุกอย่างจนถึงและรวม v3.0 เป็นโมเดล 2B บน Qwen3.5-2B-Base และนั่นคือสายตระกูล ไม่ใช่โมเดลปัจจุบัน v4.0-VL เป็น 2B, v5.0-VL ลดโมเดลเหลือ 3B และ v6.0-VL เป็น 4B หน้าที่เรียกโมเดล RSI-Jev ปัจจุบันว่า 2B นั้นล้าสมัยไปสามรุ่นแล้ว

ลูปนั่นแหละคือโปรเจกต์จริง

โมเดลเป็นผลลัพธ์; สิ่งที่กำลังสร้างคือกระบวนการ โครงการระบุว่า "ลูปที่ขับเคลื่อนการวิจัยคือเวอร์ชันถัดไปของ AutoScientists" ซึ่งเป็นระบบทีมเอเจนต์ที่จัดระเบียบตัวเองได้ เผยแพร่โดย Zitnik lab ที่ Harvard และมันทำงานตามที่ประโยคนั้นสื่อ เอเจนต์ AI เสนอสมมติฐาน ลงทะเบียนคำทำนายของตน ก่อนใช้เวลา GPU ทำการทดลอง และปลดระวางแชมเปียนของตนเองเมื่อหลักฐานบ่งชี้ว่าควรทำ ตัวเลขสองตัวทำให้เห็นเป็นรูปธรรม เมื่ออ่าน ณ วันที่ 2026-10-07 พาดหัวของรีโพซิทอรีคือการเผยแพร่แปดครั้งในสิบสามวัน จาก v1.0 ถึง v6.1-VL; สำหรับการเผยแพร่ของ v6.0-VL เองเมื่อ 2026-10-06 ระบุว่าเจ็ดครั้งในสิบสองวัน โดยแต่ละครั้งได้รับการฝึก ประเมิน และจัดทำเอกสารโดยลูป และจำนวนการทดลอง ซึ่งอยู่ที่ 471 เมื่อการเผยแพร่ของหน้านี้ถูกปล่อย วันนี้ระบุว่า 496 — ทุกตัวได้รับการเขียนรายงาน รวมถึงความล้มเหลวด้วย ตัวเลขทั้งสองเป็นของโครงการเอง และทั้งคู่เคลื่อนไหว

วินัยคือสิ่งที่ทำให้ตัวเลขเหล่านั้นมีความหมาย และโครงการก็ระบุไว้อย่างตรงไปตรงมา พื้น null ถูกวัดแทนที่จะสันนิษฐาน — แขนทดลองที่พิสูจน์ได้ว่าเหมือนกับกลุ่มควบคุมทุกประการ ซึ่งตรวจสอบยืนยันด้วยเอกลักษณ์ของออบเจ็กต์ก่อนใช้เวลา GPU ใด ๆ เพื่อให้การกระจายระหว่างพวกมัน คือพื้นเสียงรบกวน และความแตกต่างที่เล็กกว่าการกระจายนั้นไม่ถือเป็นผลลัพธ์ การคาดการณ์ถูกลงทะเบียนก่อนการรัน ดังนั้นเวอร์ชันที่ไม่ผ่านเกณฑ์ของตัวเองจะถูกปล่อยในฐานะความล้มเหลว แทนที่จะถูกตัดแต่งใหม่เงียบ ๆ อาร์ติแฟกต์ได้รับการตรวจสอบ: เช็กพอยต์ถูกโหลดกลับจากดิสก์และให้คะแนนใหม่ และจะเผยแพร่ก็ต่อเมื่อมันทำซ้ำการคาดการณ์รายคำถามของรอบฝึกของมันได้ ซึ่งเช็กพอยต์ v1.0 ทั้งสองทำได้ที่ 1.0000 การปนเปื้อนนั้น "ถูกตรวจสอบ แทนที่จะถูกกล่าวอ้าง" และความล้มเหลวก็ถูกปล่อยออก รวมถึงความล้มเหลวที่สังหารแชมป์ของโครงการเอง

การมีส่วนร่วมคืออะไร ในคำพูดของโครงการเองจากคู่มือการมีส่วนร่วม: “การมีส่วนร่วมที่นี่มักเป็นการวัด ไม่ใช่แพตช์” บันทึกที่เผยแพร่ถูกเก็บเป็นสายโซ่ ไม่ใช่เป็นสแนปช็อต — “versions/ เก็บการ์ดหนึ่งใบต่อหนึ่งรีลีส ทั้งหมด ไว้บน main ตลอดไป… สายโซ่นั้นคือโครงการ” — ซึ่งเป็นเหตุผลว่าทำไมตัวเลขของรีลีสเก่าจึงตรวจสอบเทียบกับสิ่งที่โครงการกล่าวเกี่ยวกับตัวเลขเหล่านั้นในภายหลังได้ และเป็นเหตุผลว่าทำไมการแก้ไขหนึ่งครั้งที่อภิปรายด้านล่างจึงปรากฏให้เห็นแทนที่จะเงียบ

สิ่งที่ v6.0-VL เปลี่ยนแปลงไป: มันใช้ความลึกแทนโทเคน

กลไกของรีลีสปัจจุบันคือการตั้งค่าที่เรียกว่า effort และมันควบคุมสิ่งที่ไม่ธรรมดา: จำนวนเลเยอร์ของโมเดลที่คำขอได้รับอนุญาตให้ใช้ เนื่องจาก head อยู่ที่สามระดับความลึก คำถามที่ง่ายสามารถตอบได้ที่เลเยอร์ 16 และคำถามที่ยากสามารถรันได้ทั้ง 32 เลเยอร์ ต่ำ หยุดที่เลเยอร์ 16, กลาง ที่ 20, สูง ที่ 32 และ อัตโนมัติ ตอบที่ทางออกแรกซึ่งความน่าจะเป็นที่ปรับเทียบแล้วผ่านเกณฑ์ของทางออกนั้น ความหน่วงมัธยฐานต่อคำขอบนตัวอย่าง Decision Index วัดบน H200 หนึ่งตัวใน bf16: 23 มิลลิวินาทีที่ ต่ำ, 27 มิลลิวินาทีที่ กลาง, 40 มิลลิวินาทีที่ สูง และ 40 มิลลิวินาทีสำหรับค่าเริ่มต้นที่ไม่ได้ตั้งค่า สิ่งเหล่านี้เป็นการวัดของโปรเจกต์เองบนฮาร์ดแวร์ของตัวเอง และไม่ควรนำไปผสมกับตัวเลข GB10 ในเอกสารการให้บริการ ซึ่งเป็นเครื่องที่แตกต่างกัน

พฤติกรรมที่วัดได้ของ อัตโนมัติ คือส่วนที่น่าสนใจ: ในชุดเบนช์มาร์ก 15 รายการของโครงการ 20% ของคำถามหยุดที่เลเยอร์ 16, 46% ที่เลเยอร์ 20 และ 34% ไปจนถึง 32 ซึ่งเฉลี่ย 23.3 จาก 32 เลเยอร์ เกณฑ์คงที่ค่าเดียวเฉลี่ย 20.9 และการหยุดเกินคือสิ่งที่เกณฑ์ค่าเดียวให้คุณได้ อัตโนมัติ ไม่ใช่การประนีประนอมด้านคุณภาพ ซึ่งควรกล่าวถึง เพราะโดยทั่วไปแล้วการตั้งค่าแบบปรับตัวก็เป็นเช่นนั้น: มันทำคะแนนแถวของชุดเบนช์มาร์กได้ดีที่สุดในบรรดาการตั้งค่าทั้งหมด (0.771 เทียบกับ 0.770 สำหรับค่าเริ่มต้น), แถว MMLU-Pro ดีที่สุด (0.444 เทียบกับ 0.440) และการสอบเทียบขั้นสุดท้ายดีที่สุด (ECE 0.024 เทียบกับ 0.036) จุดเดียวที่ สูง ชนะคือชุดที่กันไว้ทดสอบ 0.702 เทียบกับ อัตโนมัติ 0.696 งานบางอย่างแย่ลงอย่างเห็นได้ชัดเมื่อเพิ่มความลึก — BANKING77 แย่ลง 0.035, การจับคู่แคปชันของ New Yorker แย่ลง 0.060 — ซึ่งเป็นเหตุผลว่าทำไมระดับความพยายามจึงเป็นทางเลือกที่ผู้เรียกกำหนด ไม่ใช่กฎที่เซิร์ฟเวอร์บังคับ

ผลลัพธ์ที่ทำให้สิ่งนี้เป็นรีลีสแทนที่จะเป็นการทดลอง อยู่บน Decision Index 0.2.1 สาธารณะของโปรเจกต์ โดยคะแนนเพิ่มจาก 38.38 สำหรับ v5.0-VL เป็น 46.24 สำหรับ v6.0-VL ภายในหนึ่งรีลีส บนกระดานสาธารณะลงวันที่ 2026-09-28 นั่นคือคะแนนสูงสุดในหมู่โมเดล 4B และโมเดลที่เล็กกว่าทั้งหมด และเป็นอันดับที่ 14 จากทั้งหมด 71 รายการ; รายการถัดไปที่ขนาดเท่านั้นคือ JPT-4B ที่ 43.04 รีลีสก่อนหน้าในสายนี้เป็นเพียงสายวิวัฒนาการ ไม่ใช่โมเดลปัจจุบัน: v5.0-VL (2026-10-02) ตัดโมเดลให้เหลือ 20 เลเยอร์แรกจาก 32 เลเยอร์ และทำให้มันตอบ "ไม่ทราบ" เมื่อคำถามไม่มีคำตอบ; v4.0-VL (2026-10-01) เป็นรุ่นแรกที่อ่านภาพได้; และ v3.0 (2026-09-28) เป็นรีลีสที่การเรียนรู้แบบเสริมแรงเริ่มช่วยได้เป็นครั้งแรก ผ่านรางวัลการจัดอันดับแบบ listwise — NDCG@5 จากผู้สมัคร 16 ราย — ซึ่งยกระดับ reranking R@1 จาก 0.192 เป็น 0.308 เมื่อเทียบกับโมเดลแม่ที่ฝึกแบบ supervised โดยแลกมาด้วยต้นทุน 0.0028 บนชุดทดสอบ นั่นคือจุดที่เรื่องราว RL ของโปรเจกต์เริ่มต้น และตอนนี้ก็เป็นสามรีลีสก่อนหน้าแล้ว

ตัวเลขเหล่านั้น พร้อมกับข้อแม้ที่ติดตามมาด้วย

ผลลัพธ์หลักของ Decision Index 0.2.1 สำหรับ v6.0-VL คือ 46.24 ในการรันเต็มรูปแบบซึ่งคำขอทั้งหมด 150,759 รายการของชุดทดสอบได้รับการตอบ: ความรู้ 28.8, ภาษา 46.2, การค้นคืน 55.5, เครื่องมือ 65.8, ศิลปะ 37.1 ชุดแบบทดสอบสิบห้ารายการให้ค่า 0.770, ชุดที่กันไว้ 0.698, MMLU-Pro 0.440, และ ECE สุดท้าย 0.024 ด้วย อัตโนมัติ. ข้อควรระวังสองประการต้องอยู่พร้อมกับตัวเลขเหล่านั้น เพราะหากไม่มีพวกมัน ตัวเลขก็จะทำให้เข้าใจผิด

อย่างแรกคือการตัดรายการออกจากชุดทดสอบ งานภายในชุดทดสอบopen_jev_oodซ้อนทับกับแถวข้อมูลฝึก 579 แถว ตัวเลขของมันจึงสูงเกินจริงไปเป็นปริมาณที่ไม่ทราบแน่ชัด ตั้งแต่ v6.0-VL เป็นต้นไป โครงการรายงานชุดทดสอบนี้โดยไม่มีรายการนั้น ที่ค่า 0.770 ค่า 0.764 ของ v5.0-VL นั้นรวมรายการนี้ไว้ และการ์ดของ v6.0-VL ระบุค่าใหม่ของรุ่นนั้นเป็น 0.763 โดยไม่มีรายการนี้ ตัวเลขสองค่านี้เทียบกันไม่ได้ และถ้าคุณจะเทียบมันจริง ๆ คุณต้องใช้ค่า 0.763 ที่ระบุใหม่ และบอกว่านั่นคือสิ่งที่คุณกำลังทำอยู่ ชุด held-out, MMLU-Pro และ BBH ไม่มีการซ้อนทับและไม่ได้รับผลกระทบ การตรวจสอบที่เกี่ยวข้องพบว่ามีราว 1,000 รายการที่เป็นแถวทดสอบของชุด Decision Index อยู่ในคลังข้อมูลฝึก — ANLI 274, RouterBench-GSM8K 90, ARC 5 และข้อความคิวรีของ BRIGHT/ToolRet โดยไม่มีป้ายกำกับ คิดเป็นราว 0.3% ของแถวในชุดนี้ — และการให้คะแนนใหม่โดยไม่มีรายการเหล่านี้ทำให้ดัชนีเปลี่ยนไปไม่เกิน 0.04 ในตัวอย่างของโครงการ นั่นคือการแก้ไขบันทึกของ v5.0-VL ซึ่งเผยแพร่ในการ์ดของ v6.0-VL และเป็นกฎว่าด้วยการปนเปื้อนของโครงการเองที่ทำให้ต้องเสียตัวเลขไปหนึ่งค่า

ประการที่สองคือเรื่องที่ว่า benchmark นี้เป็นของใคร Decision Index เป็นกระดานสาธารณะของ RSI-Jev เอง ไม่ใช่คำตัดสินจากบุคคลที่สาม และ 46.24 เป็นคะแนนบนกระดานนั้น ไม่สามารถนำไปเปรียบเทียบกับสิ่งที่ TypeSafe เผยแพร่ได้ เพราะตัวเลขทั้งสองไม่ได้มาจากชุดทดสอบเดียวกัน และยังไม่มีใครทดสอบแบบเทียบกันตรง ๆ อย่างอิสระระหว่าง RSI-Jev กับ Jev 1.13 สิ่งที่พูดได้คือความแตกต่างเชิงโครงสร้างมากกว่าเชิงตัวเลข ตัวหนึ่งเป็นโมเดลเชิงพาณิชย์ที่โฮสต์อยู่บนเอนด์พอยต์ของผู้ให้บริการ และอีกตัวหนึ่งเป็นเช็กพอยต์ที่คุณดาวน์โหลดและนำไปเสิร์ฟเอง

ข้อมูลบริบทเพิ่มเติมอีกสองส่วนที่ควบอยู่กับชุดนี้ โครงการระบุชัดเจนว่า "สิบในสิบห้าเบนช์มาร์กมีส่วนให้ข้อมูลการฝึกในรูปแบบใดรูปแบบหนึ่ง ดังนั้นไม่มีตัวเลขใดในนี้ที่เป็น zero-shot"; ชุด held-out คือการเปรียบเทียบที่ถูกกันไว้ และแม้แต่ชุดนั้นก็ "ถูกกันออกจากการฝึก ไม่ได้ถูกปิดผนึกจากการค้นหา" และ v6.0-VL รัน 97 arms ในสายของตัวเอง — 93 หากไม่นับการตรวจสอบข้อมูลทั้งสี่ — ซึ่งเป็นขนาดของการค้นหาที่สร้างการเพิ่มขึ้น 7.86 จุดบนดัชนีนั้น

มันใช้ wire format ของ Jev โดยมีความแตกต่างสี่ประการที่ผู้เรียกควรทราบ

พื้นผิวความเข้ากันได้คือเหตุผลที่โปรเจกต์นี้ดำรงอยู่ในรูปแบบที่เป็นอยู่ รูปแบบคำขอเดียวกัน ({state, model, questions}) คำถามสามประเภทเดียวกันที่มีรูปแบบเกณฑ์เดียวกัน รูปแบบคำตอบเดียวกัน จำนวนคำถาม 1 ถึง 64 ข้อต่อคำขอเดียวกัน ซองข้อผิดพลาดเดียวกัน และสถิติความเชื่อมั่นเดียวกัน — ค่าพีค, (K · p_max − 1) / (K − 1), ถูกจำกัดให้อยู่ในช่วง 0..1 ข้ออ้างของโปรเจกต์เองเกี่ยวกับพื้นผิวนั้นคือ "สิ่งใดก็ตามที่เขียนโดยอิงกับ Jev จะทำงานกับสิ่งนี้ได้โดยไม่ต้องแก้ไข" และเซิร์ฟเวอร์ได้จัดทำเอกสารว่า อะไรถูกคัดลอกมาและอะไรไม่ถูก ซึ่งมีประโยชน์มากกว่าข้ออ้างนั้น

• พรอมต์และ readout เป็นของมันเอง RSI-Jev เป็นโมเดลฐานที่มี readout head ซึ่งผ่านการฝึก ให้บริการพร้อมกับ encoder ที่มันถูกฝึกมาด้วย เพราะการใช้พรอมต์ของ reference "จะทำให้โมเดลหลุดออกจาก training distribution ของมัน" สัญญาแบบ wire คือพื้นผิวความเข้ากันได้ ส่วนพรอมต์ไม่ใช่

• คีย์ตัวเลือกนั้นมองเห็นได้โดยโมเดล ข้อมูลอ้างอิงซ่อนคีย์เหล่านี้ไว้ ดังนั้นการเปลี่ยนชื่อคีย์จึงพิสูจน์ได้ว่าไม่สามารถเปลี่ยนคำตอบตรงนั้นได้ แต่ที่นี่ทำได้ และเซิร์ฟเวอร์รายงานเรื่องนี้อย่างตรงไปตรงมาว่าเป็น option_keys_visible_to_model: true.

• เกณฑ์ต้องเป็นสตริงหรือ null เกณฑ์แบบมีโครงสร้าง — ซึ่งเป็นออบเจ็กต์ — จะถูกปฏิเสธด้วย 422 เนื่องจากยังไม่มีรีลีสใดที่ถูกฝึกด้วยเกณฑ์แบบนั้น นี่เป็นจุดเดียวที่คำขอซึ่งเรเฟอเรนซ์ยอมรับจะไม่ทำงานที่นี่

• ไม่มีอะไรถูกตัด การให้บริการรองรับข้อความได้สูงสุด 32,768 โทเคน บวกกับโควตารูปภาพ และคำขอที่ยาวกว่านี้จะถูกปฏิเสธด้วย 422 ที่ระบุว่าเป็นเช่นนั้น แทนที่จะถูกตัดทอนอย่างเงียบ ๆ ตัวเลข 2,048 โทเคนที่ปรากฏในการ์ดรุ่นเก่าคือความยาวที่โมเดลถูกเทรนบนนั้น ไม่ใช่เพดานการให้บริการ และการอธิบายว่าการตัดทอนอย่างเงียบ ๆ เหลือ 2,048 เป็นพฤติกรรมปัจจุบันนั้นผิด

จำนวนตัวเลือกแตกต่างกันมาก โดยฝั่ง serving ได้เปรียบอย่างชัดเจน: สูงสุดถึง 5,120 ตัวเลือกต่อคำถาม (RSIJEV_MAX_ANSWERS) เทียบกับ 160 ใน training และ 64 ที่ reference ยอมรับ อย่าอ้างว่า 160 เป็นเพดานของ serving มีสิ่งหนึ่งที่เป็นของใหม่ในคำตอบของ v6.0-VL ไม่ได้สืบทอดมาจากเดิม: ทุกคำตอบรายงานว่าชั้นใดเป็นผู้ตอบ ใน usage.depth ควบคู่กับค่าความเชื่อมั่นที่ปรับเทียบแล้ว เพื่อให้สามารถตรวจสอบการตัดสินใจแบบปรับตัวได้ภายหลัง รูปภาพเป็นส่วนขยายที่ reference ไม่มี — หนึ่งถึงสี่รูปต่อคำขอ เป็น base64 data URL โดย state อ้างถึงแต่ละรูปด้วยเครื่องหมายตามตัวอักษร

ที่ที่ผู้อ่านสามารถรันมันได้จริง และที่ที่ผู้อ่านไม่สามารถทำได้

RSI-Jev เป็นการดาวน์โหลด โปรเจกต์นี้มาพร้อมเซิร์ฟเวอร์ของตัวเอง ซึ่งพูด API ที่เข้ากันได้กับ Jev และเส้นทางที่ระบุไว้ในเอกสารคือการ pip install จากรีโพซิทอรี ตามด้วยคำสั่ง serve ของมันพร้อม alias ของ checkpoint และการตั้งค่า effort ส่วน weights อยู่บน Hugging Face ภายใต้องค์กร shgao เผยแพร่ภายใต้ Apache-2.0 ตามโมเดลฐาน โดยมีคำถามเปิดหนึ่งข้อที่ตัวโปรเจกต์ระบุไว้เองว่า แหล่งข้อมูลฝึกสอนด้านภาพห้าแห่งเป็นแบบไม่ใช้เชิงพาณิชย์หรือเพื่อการวิจัยเท่านั้น และ "การที่ weights ซึ่งฝึกด้วยข้อมูลที่ไม่ใช้เชิงพาณิชย์จะสืบทอดเงื่อนไขเหล่านั้นหรือไม่นั้นยังไม่มีข้อสรุปที่แน่ชัด" โค้ดเป็น MIT

ฮาร์ดแวร์ไม่ใช่ข้อจำกัด โปรเจกต์นี้พัฒนาบน HP ZGX Nano ซึ่งเป็นเครื่อง NVIDIA GB10 ที่ให้เครดิตแก่ HP และ NVIDIA และเซิร์ฟเวอร์ทำงานบน CUDA GPU ใดก็ได้ บน Apple Silicon หรือบน CPU ธรรมดา โดยกรณีหลังเอกสารระบุว่าใช้เวลา 733 มิลลิวินาทีต่อหนึ่งคำถามบน Arm CPU ของ GB10 เอง จึงใช้งานได้มากกว่าที่จะเรียกว่าเร็ว

สิ่งที่มันไม่ได้ทำ คือการไปปรากฏอยู่ในแคตตาล็อกโมเดลทั่วไป และนี่คือจุดที่เราต้องระบุจุดยืนของตัวเองให้ชัดเจน RSI-Jev ไม่ได้อยู่บน OrcaRouter และไม่มีโมเดลการ์ดให้มันจัดเส้นทางไปถึง สิ่งที่เราให้บริการคือ Jev เชิงพาณิชย์ของ TypeSafe typesafe/jev-1.13 บนเอนด์พอยต์ systemone โดยเฉพาะ ซึ่งเข้าถึงได้ด้วย POST ไปยัง /v1/systemone แทนที่จะเป็นรูปแบบ chat-completions ของ OpenAI — เป็นรูปร่างคำขอและคำตอบเดียวกับที่โปรเจกต์นี้ใช้งานอยู่ จากโมเดลที่สัญญาของมันถูกนำมาเป็นต้นแบบ ความสัมพันธ์มีเพียงเท่านี้: ทั้งสองพูดโปรโตคอลเดียวกัน เราบริการหนึ่งในนั้น และคุณรันอีกตัวด้วยตัวเอง หากคุณมีคีย์กับเราอยู่แล้ว รูปแบบการเรียก Jev 1.13 ก็เป็นเส้นทางระดับแรกบน one API สำหรับโมเดล 200+ รายการ โดยบวกกำไร 0% (ราคาตามรายการของผู้ให้บริการส่งผ่านตรง ๆ ดังนั้นการลดราคาของผู้ขายจึงมีผลที่นี่ในวันเดียวกัน) — ซึ่งสำคัญต่อการเปรียบเทียบในแง่หนึ่งโดยเฉพาะ หน้าแบบนี้ทำตามได้ในต้นทุนต่ำ หากคุณได้ลองสัญญาเชิงพาณิชย์ก่อน แล้วค่อยตัดสินใจว่ารันเช็กพอยต์ 4B แบบเปิดด้วยตัวเองจะคุ้มกับภาระงานด้านปฏิบัติการหรือไม่

วิธีอ่าน RSI-Jev ในวันที่ 2026-10-07

จุดอ่อนที่โครงการเผยแพร่มีความเฉพาะเจาะจงพอ ๆ กับผลลัพธ์ และวันที่ก็สำคัญ การทดสอบภายนอกของ v2.1 พบว่าโมเดลมีแนวโน้มไปทางตัวเลือกที่รุนแรงหรือมีค่าใช้จ่ายสูงกว่าในตัวเลือกแบบเรียงลำดับและคะแนนรูบริก แทบจะไม่เลือก "unknown" เมื่อเอกสารไม่สามารถตอบได้ และตอบคำถามและคำปฏิเสธของคำถามนั้นอย่างไม่สอดคล้องกัน รุ่นที่เปิดตัวในภายหลังมุ่งเป้าข้อมูลไปที่กรณี "unknown" — KoBBQ unknown-when-ambiguous ได้ 0.891 ที่ v4.0-VL, 0.932 ที่ v5.0-VL, และ 0.918 / 0.939 ที่ v6.0-VL — และการ์ด v6.0-VL ก็ตรงไปตรงมาว่าการปรับปรุงนั้นมาจากข้อมูลมากกว่าความลึก และ 10% ของคำถามที่จะไปถึงเลเยอร์ 32 และหยุดที่ 16 หรือ 20 คือจุดที่นโยบายความลึกยังคงเดาอยู่ การจัดอันดับใหม่ยังต้องไปต่อ: ลำดับการดึงข้อมูลของ hippo-memory เองได้คะแนน 0.484 R@1 และยังนำหน้า 0.308 ที่โมเดลทำได้ที่ v3.0 ซึ่งเป็นตัวเลขที่โครงการไม่ได้อ้างว่าปิดช่องว่างได้ตั้งแต่นั้นมา หลักฐาน RL เป็นเพียงหนึ่งซีด และ v3.0 "เองไม่มีการควบคุม SFT ที่จับคู่กัน" คลังข้อมูลการฝึกและชุดพัฒนานโยบายไม่เปิดเผยต่อสาธารณะ ดังนั้นแต่ละขั้นตอนจึงไม่สามารถรันซ้ำได้จากที่เก็บโค้ดเพียงอย่างเดียว และตัวสร้างคลังข้อมูลการจัดอันดับใหม่ — หน่วยความจำประมาณ 96 GB — ไม่ได้ถูกรันซ้ำตั้งแต่ต้นจนจบ

ความสนใจที่วัดกันในวันเดียวกัน: ดาว 73 ดวง, ฟอร์ก 5, ปัญหาที่เปิดค้าง 0, รีลีสบน GitHub 7 ครั้ง ตัวเลขพวกนี้ขยับทุกวัน และรีโพซิทอรีที่อายุสามสัปดาห์ก็ไม่ใช่โปรเจกต์ที่มั่นคงตั้งตัวแล้ว ไม่ว่าจังหวะการออกรีลีสจะเป็นเช่นไร บทสรุปที่ตรงไปตรงมาคือ RSI-Jev เป็นหนึ่งในความพยายามด้านวิจัยที่อ่านออกได้ชัดเจนกว่าภายในมุมนี้ของสาขา — สายของรีลีสที่ระบุวันที่ วัดผล และบางครั้งก็แพ้ โดยมีการเผยแพร่งานค้นคว้าเคียงคู่ไปกับคะแนน — และเป็นหนึ่งในงานที่ได้รับการตรวจสอบอย่างอิสระน้อยที่สุด เนื่องจากตัวเลขแทบทุกตัวบนหน้านี้เป็นของตัวมันเอง และไม่มีบุคคลภายนอกใดวัดเทียบมันกับโมเดลเชิงพาณิชย์ที่มันรองรับร่วมกันได้

สิ่งที่ต้องจับตาดูไม่ใช่การเปิดตัวครั้งถัดไป เพราะจะมีการเปิดตัวภายในไม่กี่วันด้วยจังหวะนี้ แต่เป็นว่ามีสิ่งใดนอกโครงการเริ่มวัดหรือไม่ สองสิ่งที่จะเปลี่ยนภาพคือการรันเบนช์มาร์กอิสระบนเช็คพอยต์ที่เผยแพร่ และการเปรียบเทียบโมเดลการตัดสินใจที่นำทั้ง 4B โอเพนและโมเดลโฮสต์ของ TypeSafe ผ่านฮาร์เนสเดียวกัน ทั้งสองอย่างยังไม่มีในวันนี้ จนกว่าจะมีอย่างใดอย่างหนึ่งเกิดขึ้น วิธีที่มีประโยชน์ในการอ่านคะแนนอย่าง 46.24 คือการมองว่าเป็นข้ออ้างที่มีเอกสารประกอบอย่างดีจากโครงการที่ลงทะเบียนการคาดการณ์ล่วงหน้าและปล่อยกลุ่มทดลองที่ล้มเหลวออกมา — ซึ่งเป็นร่องรอยหลักฐานที่แข็งแกร่งกว่าของส่วนใหญ่ และยังไม่ใช่ผลลัพธ์จากบุคคลที่สาม