Jev 1.13 อธิบาย: ทำไมโมเดลจึงตอบเป็นป้ายกำกับแทนที่จะเป็นประโยค

Jev 1.13 (typesafe/jev-1.13) ไม่ใช่โมเดลแชต และวิธีที่เร็วที่สุดที่จะทำความเข้าใจมันก็คือเลิกอ่านสเปกของมันแบบที่คุณอ่านสเปกของตัวอื่น ๆ ทุกตัว TypeSafe ปล่อยมันเมื่อ 2026-09-15 ในฐานะสมาชิกตัวแรกของคลาสที่บริษัทเรียกว่าโมเดลตระกูล System One: คุณยื่นสถานะชิ้นหนึ่งกับชุดคำถามที่มีชื่อกำกับให้มัน แล้วมันจะคืนคำตอบที่มีการกำหนดชนิดหนึ่งคำตอบต่อหนึ่งคำถาม — ป้ายกำกับจากรายการที่คุณให้มา ระดับบนสเกลที่คุณนิยามไว้ หรือค่าจริง/เท็จที่แนบความน่าจะเป็นมาด้วย ไม่มีร้อยแก้ว ไม่มีโค้ด ไม่มีคำอธิบาย นี่ไม่ใช่บทความเปิดตัว ตัวโมเดลเองมีอายุจาก 2026-09-15 สิบห้าวันแล้ว และอยู่นอกหน้าต่างเจ็ดวันที่บล็อกนี้เขียนถึง จึงไม่ได้หน้าเพจจากการเปิดตัวของมันเอง สิ่งที่เกิดขึ้นภายในหน้าต่างนั้นคือ OrcaRouter เพิ่ม typesafe/jev-1.13 เข้าแค็ตตาล็อกของตัวเองเมื่อ 2026-09-24 และเปิดการ์ดโมเดล Jev 1.13 ที่ https://www.orcarouter.ai/models/typesafe/jev-1.13 — เป็นครั้งแรกที่ Jev เรียกใช้ได้ผ่านเกตเวย์ของบุคคลที่สาม ไม่ใช่เพียงผ่านเอนด์พอยต์ของ TypeSafe เองเท่านั้น และเป็นข้อมูลการให้บริการจริงชุดแรกที่ใครก็ตามนอก TypeSafe เผยแพร่เกี่ยวกับมัน นั่นคือการเปลี่ยนแปลงที่ควรค่าแก่การอ่าน: โมเดลนี้กลายเป็นสิ่งที่รันได้ในที่ที่มันเคยรันไม่ได้

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

Jev เป็นโมเดลประเภทไหน

โพสต์เปิดตัวของ TypeSafe ระบุไว้ในประโยคเดียวว่า "โมเดลสาธารณะตัวแรกของเราคือ Jev พร้อมใช้งานวันนี้ในรูปแบบ early access" จากนั้นโพสต์ได้วางกรอบโมเดลนี้ว่าเป็น "การเรียกฟังก์ชันของสติปัญญาระดับแนวหน้า: สถานะที่ไม่มีโครงสร้างเข้าไป การตัดสินใจเชิงความน่าจะเป็นที่มีการระบุชนิดออกมา" นั่นเป็นคำอธิบายที่ยุติธรรมของอินเทอร์เฟซ และเป็นคำอธิบายที่สำคัญ เพราะความคาดหวังที่ผิดเกือบทั้งหมดเกี่ยวกับ Jev เกิดจากการประเมินมันเป็นโมเดลภาษาขนาดเล็ก มันไม่ใช่โมเดลภาษาขนาดเล็ก มันคือโมเดลการตัดสินใจที่มีไวยากรณ์เอาต์พุตแบบตายตัว และไวยากรณ์คือตัวผลิตภัณฑ์

อินเทอร์เฟซนี้มีอินพุตสองรายการพอดี สถานะคือเนื้อหาที่จะถูกประเมิน เช่น อีเมล ตั๋วสนับสนุน บรรทัดล็อก เรกคอร์ด JSON อาร์เรย์พิกัดในเกม คำถามคือแมปของรายการที่มีชื่อ โดยแต่ละรายการมีประเภท มีคำแนะนำของตัวเอง และ — สำหรับสองประเภทที่มีโครงสร้าง — มีเกณฑ์ของตัวเอง คำถามทุกข้อถูกประเมินเทียบกับสถานะเดียวกันนั้น และคำตอบจะกลับมาเป็นเพย์โหลด JSON แบบมีโครงสร้างชุดเดียว เอกสารของ TypeSafe อธิบายว่าคำถามเหล่านั้นทำงานแบบพร้อมกันและเป็นอิสระต่อกัน และกล่าวอ้างสองประการที่ตามมาจากการออกแบบนั้นมากกว่าจากการปรับแต่ง: การเพิ่มคำถามแทบไม่เปลี่ยนเวลาตอบสนอง และการเพิ่มคำถามไม่ได้ก่อให้เกิด context rot เพราะคำถามแต่ละข้อถูกประเมินโดยแยกจากกัน แทนที่จะอยู่ปลายน้ำของคำถามข้อก่อน ๆ

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

โมเดลนี้เป็นแบบปิดในทุกแง่มุมที่สำคัญสำหรับวิศวกรที่ต้องวิเคราะห์ความเสี่ยง สถาปัตยกรรม จำนวนพารามิเตอร์ ทรัพยากรการประมวลผลที่ใช้ฝึก และเวตของ Jev ล้วนไม่ได้รับการเปิดเผย ไม่มีรีโพซิทอรีเวตอยู่ในองค์กร TypeSafe บน GitHub — รีโพซิทอรีสาธารณะทั้งสิบเอ็ดแห่งที่นั่นเป็นเครื่องมือ, SDK, เวิร์กโฟลว์ และฟอร์กที่ไม่เกี่ยวข้องอีกสามแห่ง และไม่มีรีโพซิทอรีใดในนั้นที่เป็นโมเดลนี้

"Typed" คือผลิตภัณฑ์ทั้งหมด

การ์ดโมเดลของ OrcaRouter เผยแพร่พริมิทีฟทั้งสาม และที่สำคัญคือขีดจำกัดของแต่ละตัว ทุกคำถามที่คุณถาม Jev จะเป็นหนึ่งในสามรูปแบบนี้เท่านั้น:

• noul — การตัดสินว่าจริง/เท็จ ซึ่งส่งคืนมาพร้อมความน่าจะเป็นที่ปรับเทียบแล้ว แทนที่จะเป็นค่าบูลีนเปล่า ๆ ดังนั้น "น่าจะจริง" กับ "จริงแน่นอน" จึงเป็นค่าที่แยกออกจากกันได้

• choice — เลือกหนึ่งตัวเลือกจากตัวเลือกที่มีป้ายกำกับได้สูงสุด 255 ตัวเลือก โดยแต่ละตัวเลือกมีข้อความเกณฑ์ของตัวเอง เพื่อให้โมเดลรู้ว่าอะไรที่ทำให้ป้ายกำกับของคุณแตกต่างกัน

• score — ให้คะแนนบนมาตรวัดแบบเรียงลำดับ 2–10 ระดับ โดยมีคำจำกัดความของแต่ละระดับที่กำหนดไว้เป็นเกณฑ์

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

สามประเภทนี้ยังเป็นเหตุผลที่ผู้ตรวจสอบไม่สามารถประเมิน Jev ได้แบบเดียวกับที่ประเมินโมเดลแชต ไม่มีคะแนน MMLU-Pro ให้เทียบ ไม่มีตัวอย่างงานเขียนให้อ่าน ไม่มีร่องรอยการให้เหตุผลให้ตรวจสอบ คำถามเดียวที่มีความหมายคือคำตอบที่ระบุประเภทนั้นถูกต้องหรือไม่ และความน่าจะเป็นที่แนบมากับคำตอบนั้นซื่อสัตย์หรือไม่ ทั้งสองอย่างนี้วัดผลได้ แต่ต้องวัดกับข้อมูลและป้ายกำกับของคุณเท่านั้น

ความแตกต่างที่ได้รับการบันทึกไว้ประการหนึ่งน่าที่จะชี้ให้เห็นมากกว่าจะเข้าไปแก้ให้จบ: เอกสารของ TypeSafe เองแสดงตัวอย่าง Score ที่ทำดัชนีเริ่มจากศูนย์ ขณะที่การ์ดของ OrcaRouter เผยแพร่สเกลเป็น 2–10 ระดับ เอกสารของผู้ขายระบุเป็นระดับ ส่วนการ์ดของเราเผยแพร่ 2–10 หากคุณกำลังสร้าง rubric บนพื้นฐานของ Score ให้อ่านคำจำกัดความของระดับในคำตอบของคุณเองแทนที่จะสมมติว่ามีดัชนี

ทำไมจึงไม่มี output tokens ที่จะเรียกเก็บเงิน

การกำหนดราคาเป็นสิ่งที่สะท้อนสถาปัตยกรรมได้ชัดเจนที่สุด Jev มีค่าใช้จ่าย $0.042 ต่อโทเคนอินพุตหนึ่งล้านโทเคนบน OrcaRouter และอัตราเอาต์พุตอยู่ที่ $0.000000 ต่อหนึ่งล้าน — ไม่ใช่ส่วนลด ไม่ใช่โปรโมชันเปิดตัว แต่คือการที่ไม่มีปริมาณที่วัดได้ โมเดลเชิงสร้างถูกคิดค่าบริการจากข้อความที่มันเขียน ส่วน Jev ไม่ได้เขียนข้อความใด ๆ มันคืนค่ากลับมาเป็นป้ายกำกับ ระดับ และความน่าจะเป็น จึงไม่มีอะไรให้นับฝั่งเอาต์พุต ดังนั้นจึงไม่มีการคิดค่าบริการตรงนั้น

TypeSafe ระบุตัวเลขเดียวกันจากอีกทิศทางหนึ่งบนหน้าแรกของตน — "$42 ต่อพันล้านโทเคนอินพุต" — และแนบข้อกล่าวอ้างเชิงเปรียบเทียบไว้กับตัวเลขนั้นว่า "ราคาอินพุตต่ำกว่า Claude Fable 5.1 ถึง 238 เท่า" การเปรียบเทียบนั้น เช่นเดียวกับทุกสิ่งอื่นบนหน้าแรก เป็นของเจ้าของผลิตภัณฑ์เอง และไม่มีใครทำซ้ำ แต่การคำนวณที่เป็นรากฐานของการเปรียบเทียบนี้เป็นสิ่งที่ผู้อ่านตรวจสอบกับบิลของตัวเองได้ง่าย ซึ่งนั่นคือส่วนที่มีประโยชน์ ปริมาณของเวิร์กโหลดการตัดสินใจถูกกำหนดเกือบทั้งหมดจากจำนวนสถานะที่คุณป้อนเข้าไป และสถานะนั้นมีราคาถูกในแบบที่โทเคนที่สร้างขึ้นไม่ได้เป็น

ตัวเลขพาดหัวของผู้ขายใหญ่กว่าบรรทัดราคา และสมควรได้รับการติดป้ายกำกับแบบเดียวกัน TypeSafe โฆษณาว่า "เร็วขึ้น 193.6 เท่า ถูกกว่า 444.6 เท่า" โดยมีเชิงอรรถจำกัดขอบเขตไว้เฉพาะ "เวิร์กโฟลว์สำหรับงานของ System One" และเผยแพร่ตัวอย่างที่แสดงวิธีคำนวณไว้ด้านล่าง: TypeSafe AI ที่ราคา $0.000081 ทำงานเสร็จใน 0.114 วินาที เทียบกับ LLMs ที่ราคา $0.013880 ทำงานเสร็จใน 8.566 วินาที โพสต์เปิดตัวเองก็ยอมรับความเสี่ยงจากการวางกรอบ — มีการระบุว่า 193.6 เท่าและ 444.6 เท่าน่าจะอยู่ "ปลายบนของผลประโยชน์ในโลกจริง" — และระบุว่าการสาธิตแบบวางเทียบกันใช้คำค้นที่ "เรียบง่ายมาก" พร้อมคีย์ที่มนุษย์อ่านได้ซึ่งผู้ขายเลือกเอง เพื่อ "วาดภาพโมเดลของเราให้ดูได้เปรียบ" ไม่มีตัวเลขใดเหล่านี้ได้รับการทำซ้ำโดยอิสระ และการ์ดเบนช์มาร์กของผู้ขายเองยังคงถูกทำเครื่องหมายว่ารอดำเนินการ

คำว่า "calibrated" หมายถึงอะไร และ RLCD คืออะไร

TypeSafe ตั้งชื่อวิธีการฝึกของตนเองว่า "Reinforcement Learning for Calibrated Decisions (RLCD)" RLCD เป็นคำศัพท์เฉพาะของ TypeSafe เอง ไม่ใช่ตัวย่อแมชชีนเลิร์นนิงทั่วไปที่มีมาก่อนบริษัท และเป้าหมายการปรับให้เหมาะที่สุดของมันระบุไว้ในตารางเปรียบเทียบของโพสต์เปิดตัวว่า "การตัดสินใจที่ปรับคาลิเบรตแล้ว: คำตอบที่มีความน่าจะเป็นที่ซื่อตรงเชิงญาณวิทยาบนงาน System One" ตารางเดียวกันนี้เปรียบเทียบกับ RLHF ซึ่งปรับให้เหมาะกับความชอบของมนุษย์ — งานเขียนและคำตอบแชตที่ผู้ให้คะแนนชื่นชอบ — และ RLVR ซึ่งปรับให้เหมาะกับเอาต์พุตที่สามารถตรวจสอบยืนยันได้ด้วยโปรแกรม RLCD ปรับให้เหมาะกับเป้าหมายที่สาม: ความน่าจะเป็นที่แนบมากับคำตอบ ว่าคำตอบนั้นเป็นการระบุความไม่แน่ใจของโมเดลเองได้อย่างแม่นยำ

ในทางปฏิบัติ "calibrated" เป็นข้อกล่าวอ้างเกี่ยวกับค่าความมั่นใจ ไม่ใช่การรับประกันว่าคำตอบจะถูกต้อง โมเดลที่ปรับเทียบแล้วซึ่งบอกค่า 0.8 กับคำถามชุดหนึ่ง ควรตอบถูกประมาณ 80% ของทั้งชุดนั้น แต่มันก็ยังผิดในข้อใดข้อหนึ่งได้ ความแตกต่างนี้คือวิธีอ่านข้อความบนหน้าแรกของ TypeSafe อย่างตรงไปตรงมา: “Zero Hallucinations — ทุกการตัดสินใจของ Jev มาพร้อมค่าประเมินความมั่นใจ ดังนั้นซอฟต์แวร์ของคุณจึงดำเนินการได้เมื่อความมั่นใจสูง และส่งต่อเมื่อความมั่นใจไม่สูง” มันเป็นข้อกล่าวอ้างเรื่องการประเมินความมั่นใจ ไม่ใช่ข้อพิสูจน์ว่าปราศจากข้อผิดพลาด และสิ่งที่ถ่วงดุลคือข้อมูลของเราเอง: ในช่วงเจ็ดวันที่สิ้นสุดวันที่ 2026-09-30 การ์ดของเราวัดอัตราความผิดพลาดได้ 0.49% บนทราฟฟิก Jev ที่ผ่าน OrcaRouter — ตัวเลขที่เคยอ่านได้ 0.57% ก่อนหน้านั้นในหน้าต่างเดียวกัน เพราะคำนวณจากเจ็ดวันแบบเลื่อนของทราฟฟิก playground สด แทนที่จะเป็นชุดทดสอบแบบตายตัว ข้อเท็จจริงทั้งสองอย่างควรอยู่ในย่อหน้าเดียวกัน: ค่าความมั่นใจคือจุดสำคัญของโมเดล และโมเดลก็ยังล้มเหลวประมาณหนึ่งคำขอในสองร้อยคำขอบนทราฟฟิกของเรา

เรื่องราวการคาลิเบรตยังอธิบายพฤติกรรมความหน่วงที่มิฉะนั้นอาจดูเหมือนเป็นบั๊ก โพสต์เปิดตัวของ TypeSafe ระบุว่า "สำหรับตัวเลือกที่มีคาร์ดินาลิตีสูงขึ้น เราจะใช้ระบบ 2 ขั้นตอน คือให้คะแนนแยกกันอย่างอิสระก่อน แล้วจึงเลือกอย่างชัดเจน ดังนั้นจึงเกิดความหน่วงเป็นครั้งคราว" ตัวเลือกที่มี 255 ตัวเลือกไม่ใช่การเปรียบเทียบไปข้างหน้าครั้งเดียว ผู้ขายจะให้คะแนนก่อนแล้วจึงเลือก หากคุณเห็นคำขอที่เทียบกับชุดเลเบิลขนาดใหญ่ใช้เวลานานกว่าที่เทียบกับ noul อย่างเห็นได้ชัด นั่นคือกลไกที่ระบุไว้ในเอกสาร ไม่ใช่ปัญหาความคับคั่ง

วันนี้คุณเรียกมันว่าอย่างไร

บน OrcaRouter โมเดลนี้คือ typesafe/jev-1.13 ซึ่งมีชื่อว่า "TypeSafe: Jev 1.13" ในแคตตาล็อก โดยมี context_length อยู่ที่ 65,536 โทเคน และมี endpoint type ที่รองรับเพียงหนึ่งประเภทเท่านั้น คือ systemone คุณเรียกใช้งานมันด้วย POST /v1/systemone โดยใช้คีย์ OrcaRouter ของคุณ ส่งฟิลด์ model ฟิลด์ state (สตริง, ออบเจ็กต์ หรืออาร์เรย์) และแมป questions ซึ่งแต่ละรายการประกอบด้วย type (noul, choice หรือ score) คำแนะนำของมัน และเกณฑ์ของมัน คำตอบที่ได้จะเป็นเพย์โหลด JSON แบบมีโครงสร้างชุดเดียว และไม่มีการสตรีม — ไม่มีโหมดสตรีมมิ่งให้เลือกใช้

ถ้อยคำของการ์ดสำหรับสัญญาคือ "ข้อความเข้า, JSON แบบมีโครงสร้างออก" และขีดจำกัดที่เผยแพร่คือสิ่งที่ต้องออกแบบให้สอดคล้อง: ไม่สตรีมมิ่ง สูงสุดประมาณ 64K โทเค็นอินพุตสำหรับ state และคำถามรวมกัน โดยคำขอที่เกินขีดจำกัดนั้นจะถูกปฏิเสธก่อนถึงโมเดล รายการในแคตตาล็อกระบุราคาตั้งไว้ที่ $0.042 ต่อล้านโทเค็นอินพุต และแสดงอัตราการคอมพลีชันเป็นศูนย์ นั่นคือตัวเลขของผู้ขายที่ส่งผ่านโดยไม่เปลี่ยนแปลง — รูปแบบตามสัดส่วนของวิธีที่เราคิดราคา: มาร์กอัป 0% จากราคาตั้งของผู้ให้บริการ

มีงบโทเคนสองก้อนที่ใช้กับโมเดลนี้ และทั้งสองไม่ได้ขัดแย้งกัน ดังนั้นจงแยกมันออกจากกัน ตัวเลข 65,536 คือ context_length ของการ์ด และมีเอกสารระบุว่าเป็นอินพุตประมาณ 64K เมื่อรวมสถานะและคำถามเข้าด้วยกัน “ประมาณ 32,000 โทเคน” ที่บทความ OrcaRouter ก่อนหน้านี้อ้างถึงเป็นเพียงงบสำหรับสถานะเท่านั้น — คือพื้นที่ที่เนื้อหาของคุณได้รับก่อนที่คำถามจะเข้ามาแบ่งส่วน หากคุณกำลังจัดงบสำหรับคำขอ งบสำหรับสถานะคือตัวเลขที่จำกัดเพย์โหลดที่คุณสร้าง ส่วนตัวเลขรวมคือเพดานของทั้งการเรียก

สิ่งที่ Jev ทำไม่ได้ กล่าวอย่างตรงไปตรงมา

มันไม่สามารถเขียนร้อยแก้ว สรุป แปล หรือสนทนาได้ นั่นคือการออกแบบ ไม่ใช่ข้อจำกัดที่ต้องขอโทษ: โพสต์เปิดตัวกล่าวว่า Jev "ยอมแพ้ต่อการสร้างสตริง" และหน้า jaggedness ของ TypeSafe เองก็ระบุ "Generation" เป็นโหมดความล้มเหลวที่มีชื่อ พร้อมกับคำแนะนำ "ใช้โมเดลเชิงสร้าง" ข้าง ๆ การสร้างแบบบังคับนั้นช้าและแย่ หากไปป์ไลน์ของคุณต้องการสรุปเป็นลายลักษณ์อักษร Jev ก็เป็นคอมโพเนนต์ที่ผิด และไม่ว่าคุณจะเขียนพรอมต์เก่งแค่ไหนก็ไม่เปลี่ยนสิ่งนั้น

มันไม่ใช่สิ่งทดแทนโมเดลแบบเจเนอเรทีฟ เวิร์กโฟลว์ที่ Jev เป็นส่วนหนึ่งมีโมเดลสองตัวอยู่ด้วยกัน: ตัวหนึ่งเป็นแบบเจเนอเรทีฟที่อ่าน เขียน และให้เหตุผลด้วยข้อความ กับ Jev ที่นั่งอยู่ข้าง ๆ แล้วทำการเรียกแบบมีชนิดภายในเวลาไม่กี่มิลลิวินาที นั่นคือกรอบอธิบายที่ตรงไปตรงมาของการเปรียบเทียบต้นทุนทุกอันบนโฮมเพจของผู้ขาย — คอลัมน์ "LLMs" ไม่ใช่คู่แข่งที่กำลังถูกแทนที่ แต่เป็นอีกครึ่งหนึ่งของระบบเดียวกัน และเหตุผลที่การจับคู่นี้น่าสนใจก็คือ ครึ่งที่ทำหน้าที่ตัดสินใจตอนนี้ใช้คีย์เดียวกับครึ่งที่เป็นเจเนอเรทีฟ แทนที่จะอยู่ภายใต้สัญญาของตัวเอง

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

การอ่านตัวเลขอย่างตรงไปตรงมา

ตัวเลขการให้บริการทุกตัวบนการ์ดของเรามาจากทราฟฟิกของเราเองผ่าน playground ของ OrcaRouter ในหน้าต่างเจ็ดวันแบบเลื่อน ไม่ใช่จาก benchmark ของผู้ขาย และหน้าต่างนั้นเลื่อนไปขณะที่บทความนี้กำลังถูกเขียน — โปรดมองมันเป็นค่าที่อ่านได้ ไม่ใช่ข้อกำหนด สำหรับเจ็ดวันสิ้นสุดวันที่ 2026-09-30: ค่ามัธยฐานของเวลาถึงโทเคนแรก 151 ms, p95 247 ms, ปริมาณงานส่งออกประมาณ 349 โทเคนต่อวินาที, อัตราข้อผิดพลาด 0.49% และให้บริการไป 76.2 ล้านโทเคน p50 รายวันตลอดหน้าต่างอยู่ที่ 175, 170, 163, 161, 170, 147 และ 143 ms — เป็นเส้นที่ค่อย ๆ ดีขึ้น p95 ของวันที่ 09-28 ที่ 2,448 ms เป็นค่าผิดปกติของวันเดียวจริง ๆ ที่อยู่ในชุดข้อมูลนั้น และการอ้างอิงค่านั้นเป็นค่าปกติจะผิดในแบบเดียวกับการตัดมันออกไปทั้งหมดซึ่งก็ไม่ซื่อสัตย์

ข้อควรระวังเพิ่มเติมอีกอย่างเกี่ยวกับตัวเลขทราฟฟิก: 349 โทเค็นเอาต์พุตต่อวินาทีฟังดูเหมือนอัตราความสามารถในการประมวลผลของโมเดลแบบเจนเนอเรทีฟ จนกว่าคุณจะนึกได้ว่า Jev ไม่ได้สร้างข้อความใด ๆ ออกมา มิเตอร์กำลังวัดสิ่งที่ playground ของเรานับทางฝั่ง response สำหรับเพย์โหลดแบบมีโครงสร้าง และมันมีประโยชน์สำหรับการจับสัญญาณความเสื่อมถอยระหว่างวัน มากกว่าสำหรับการนำ Jev ไปเปรียบเทียบกับโมเดลแชต

นั่นคือตัวเลขของเรา ตัวเลขของผู้ขายคือ 193.6x, 444.6x, ตัวอย่างการคำนวณที่ $0.000081 และการเปรียบเทียบ 238x กับ Claude Fable 5.1 — ทั้งหมดเป็นของ TypeSafe เอง ไม่มีรายการใดได้รับการทำซ้ำโดยอิสระ และทั้งหมดถูกจำกัดโดยเชิงอรรถของพวกเขาเองให้ใช้เฉพาะกับเวิร์กโฟลว์งานของ System One คำกล่าวอ้างด้านประสิทธิภาพเพียงข้อเดียวที่ TypeSafe หยิบยกขึ้นมา ซึ่งไม่ใช่การทดสอบวัดประสิทธิภาพเลย และมีค่ามากกว่าตัวคูณเหล่านั้น คือข้ออ้างเชิงโครงสร้าง: เนื่องจากคำตอบมีชนิดข้อมูลกำกับ การผสานรวมจึงไม่มีขั้นตอนการแยกวิเคราะห์และไม่มีขั้นตอนการตรวจสอบสคีมา และนั่นคือต้นทุนที่ไม่ปรากฏในตารางความหน่วงใด ๆ

อะไรที่เปิด และอะไรที่ไม่เปิด

ตรวจสอบเมื่อ 2026-09-30 องค์กร TypeSafe บน GitHub เผยแพร่รีโพซิทอรีจำนวนสิบเอ็ดแห่ง ไม่มีแห่งใดมี Jev รีโพซิทอรีที่มีความสำคัญสำหรับนักพัฒนาที่ผสานรวมโมเดลนี้ ล้วนใช้สัญญาอนุญาต MIT หรือ Apache-2.0: skills (MIT), system-one-adapter-python (MIT ซึ่งอธิบายว่าเป็น "ตัวแทน TypeSafeClient แบบใช้แทนได้ทันทีซึ่งขับเคลื่อนด้วย API ของ LLM"), typesafe-sdk-js (MIT), typesafe-sdk-python (MIT), daggerverse (Apache-2.0), WorkflowEvals (Apache-2.0 โดยมีโค้ดเวิร์กโฟลว์เผยแพร่ที่ evals.typesafe.ai), n8n-nodes-typesafe-ai (MIT), typesafe-ai.github.io และ pulumi-clickhouse จำนวนดาวและวันที่ push มีการเปลี่ยนแปลงอยู่เสมอ ดังนั้นหากคุณอ่านข้อนี้ในภายหลัง โปรดตรวจสอบซ้ำแทนที่จะเชื่อรายการนี้

สามในสิบเอ็ดเป็นฟอร์กของโปรเจกต์ที่ไม่เกี่ยวข้อง และไม่ได้พิสูจน์อะไรเกี่ยวกับวิธีการทำงานของ Jev: ฟอร์กของ vLLM ที่พุชครั้งล่าสุดในเดือนพฤษภาคม 2025, ฟอร์กของ LLaDA จากเดือนมิถุนายน 2025 — LLaDA เป็นการเปิดตัวโมเดลภาษาการแพร่กระจายที่ไม่เกี่ยวข้อง — และผู้ให้บริการ Pulumi สำหรับ ClickHouse Cloud เป็นเรื่องน่าดึงดูดที่จะอ่านสถาปัตยกรรมจากรายการฟอร์ก อย่าทำเช่นนั้น: ไม่มีอะไรเกี่ยวกับการออกแบบของ Jev ที่ตามมาจากสามสิ่งนั้น และโดยเฉพาะอย่างยิ่ง Jev ไม่ใช่โมเดลการแพร่กระจาย ไม่ว่าการมีอยู่ของฟอร์ก LLaDA จะชี้แนะเช่นนั้นมากเพียงใด

คำตอบสั้น ๆ อย่างตรงไปตรงมาต่อคำถามที่ว่า "Jev เป็นโอเพนซอร์สหรือไม่" ก็คือ เครื่องมือนั้นเปิด แต่ตัวโมเดลไม่เปิด นี่เป็นรูปแบบปกติสำหรับโมเดลระดับแนวหน้าที่ให้บริการแบบโฮสต์ และเป็นรูปแบบที่คุณควรตั้งสมมติฐานไว้เมื่อวางแผนโดยอิงกับ Jev: API ที่มีราคาประกาศไว้ สัญญาที่มีเอกสารกำกับ และจำนวนพารามิเตอร์ที่ไม่เปิดเผย

ตรงที่ผู้ขายบอกว่า Jev ไม่น่าเชื่อถือ

TypeSafe เผยแพร่หน้าแสดงความขรุขระของตนเองสำหรับ jev-1.13 ซึ่งตรวจทานล่าสุดเมื่อ 2026-09-17 โดยระบุจุดที่โมเดลล้มเหลว เนื้อหานั้นตรงไปตรงมาอย่างหาได้ยาก และเป็นจุดเริ่มต้นที่เหมาะสมสำหรับส่วนข้อจำกัด เพราะเป็นรายการของเจ้าของผลิตภัณฑ์เอง ไม่ใช่ของคู่แข่ง:

• การอ่านตามตัวอักษร — จะตีความถ้อยคำตามความหมายตรงตัว คำที่กำหนดขอบเขต คำปฏิเสธ และเงื่อนไขที่บอกเป็นนัยจะไม่ถูกอนุมาน; มัน “ตอบคำถามที่คุณเขียนไว้ ไม่ใช่คำถามที่คุณตั้งใจจะถาม” วิธีแก้ของผู้ขายคือการเขียนเงื่อนไขที่แน่นอนและเกณฑ์สำหรับทุกตัวเลือก

• คณิตศาสตร์และตัวเลข — มันไม่ใช่เครื่องคิดเลข และไม่สามารถนับได้อย่างแม่นยำ ให้คำนวณทางคณิตศาสตร์ในโค้ดเท่านั้น

• การเปรียบเทียบวันที่และเวลา — วันที่ถูกอ่านเป็นข้อความ ไม่ใช่ปริมาณที่เรียงลำดับได้ ดังนั้นการเรียงลำดับ ช่องว่าง และช่วงเวลาจึงไม่น่าเชื่อถือ ยิ่งแย่ลงเมื่อมีรูปแบบผสมกัน

• ความอ้อม — การปฏิเสธซ้อนและการให้เหตุผลแบบหลายขั้นลดความแม่นยำ ลดจำนวนขั้นและชี้ไปที่สถานะที่เกี่ยวข้อง

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

• เนื้อหาที่เป็นปฏิปักษ์ — สถานะไม่ถูกมองว่าเป็นภัยคุกคาม ดังนั้นคำสั่งที่ถูกแทรกเข้ามาหรือการวางกรอบที่ชี้นำผิดจึงอาจทำให้คำตอบเปลี่ยนไปได้

• คำสั่งและเกณฑ์ที่ขัดแย้งกัน — เมื่อทั้งสองต้องการสิ่งที่แตกต่างกัน โมเดล "อาจสับสน"

• ค่าคงที่เชิงโครงสร้างตามสามัญสำนึก — P(noul) และ 1 − P(not noul) ไม่รับประกันว่าจะสอดคล้องกัน ถามแต่ละการตัดสินใจในทิศทางเดียว และบังคับใช้เอกลักษณ์ในโค้ด

• การสร้าง — ครอบคลุมไปแล้ว และคำแนะนำของผู้ขายเองก็คือให้ใช้โมเดลเชิงสร้าง

สองข้อในนี้สมควรได้รับการเน้นย้ำ ข้อที่เป็นเชิงปฏิปักษ์นั้นสำคัญ เพราะข้อเสนอคุณค่าทั้งหมดของ Jev คือการตัดสินเนื้อหาที่ไม่น่าเชื่อถือ และสถานะที่มีคำสั่งอยู่สามารถเปลี่ยนคำตอบได้ ถ้าสถานะของคุณมาจากผู้ใช้ นั่นก็เป็นพื้นผิวการฉีดพรอมป์ต์ที่มีรูปแบบเดียวกับพื้นผิวอื่น ๆ ส่วนข้อเกี่ยวกับค่าคงที่เชิงโครงสร้าง (structural invariants) นั้นสำคัญ เพราะโมเดลที่ “คาลิเบรตแล้ว” ชวนให้คุณคำนวณทางคณิตศาสตร์กับความน่าจะเป็นของมัน และผู้ขายกำลังบอกคุณว่าอย่าไปถือว่าการคำนวณนั้นปิดลงตัว

สิ่งที่โพสต์เปิดตัวให้คำมั่นไว้ และสิ่งที่ไม่ได้ให้คำมั่น

คำกล่าวอ้างของผู้ให้บริการเกือบทุกข้อที่ถูกยกมาในบทความนี้สืบย้อนกลับไปยังหน้าเดียว: ประกาศของ TypeSafe เอง ซึ่งจัดอยู่ในหมวด Company News ลงวันที่ 2026-09-15 และลงนามโดย Diogo Almeida ผู้ก่อตั้ง การอ่านประกาศนั้นโดยตรงคุ้มค่ากับเวลาสองนาที เพราะถ้อยคำในบรรทัดหนึ่งกำหนดเงื่อนไขสำหรับทุกสิ่งนับตั้งแต่นั้นมา “โมเดลสาธารณะตัวแรกของเราคือ Jev พร้อมให้ใช้งานวันนี้ในรูปแบบ early access” Early access เป็นคำอธิบายของผู้ให้บริการเองเกี่ยวกับความพร้อมใช้งานบนแพลตฟอร์มของผู้ให้บริการเอง และเป็นถ้อยแถลงที่จำกัดกว่าที่เห็น — มันผูกพัน TypeSafe ในการให้บริการโมเดลนี้แก่ผู้ใช้ที่ได้รับอนุมัติ และไม่ได้กล่าวถึงว่าใครอื่นอาจให้บริการมันได้ นั่นคือช่องว่างที่การเพิ่มในแค็ตตาล็อกเมื่อวันที่ 2026-09-24 เข้ามาปิดพอดี และเป็นเหตุผลที่การ์ดโมเดลสำคัญกว่าโพสต์สำหรับใครก็ตามที่กำลังประเมิน Jev ในวันนี้

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

คำถามที่อินเทอร์เฟซนี้ก่อให้เกิด

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

คอนเท็กซ์ 65,536 โทเคนหมายถึงสถานะ 65,536 โทเคนหรือไม่ไม่ใช่ งบประมาณที่ประกาศไว้อยู่ที่ประมาณ 64K โทเคน เมื่อรวมสถานะและคำถามทั้งหมดเข้าด้วยกัน และตัวเลข "ประมาณ 32,000 โทเคน" ที่ปรากฏในบทความเก่า ๆ นั้นเป็นงบประมาณของสถานะเพียงอย่างเดียว ให้จัดสรรเพย์โหลดของคุณเทียบกับตัวเลขของสถานะ ไม่ใช่ตัวเลขรวม และจำไว้ว่าคำขอที่เกินขีดจำกัดจะถูกปฏิเสธก่อนที่จะไปถึงโมเดล

จะทำอะไรกับสิ่งนี้ดี

Jev 1.13 น่าลองดูด้วยเหตุผลเฉพาะเจาะจงเหตุผลหนึ่ง ไม่ใช่ด้วยเหตุผลทั่วไป ถ้าคุณมีขั้นตอนหนึ่งในไปป์ไลน์ของคุณที่ตอนนี้เป็นโมเดลแชตซึ่งถูกขอให้ส่งคืนป้ายกำกับ และถูกเชื่อใจว่ามันจะส่งคืนมาในรูปแบบที่ถูกต้อง — ไม่ว่าจะเป็นเราเตอร์ ตัวให้คะแนน การตรวจสอบนโยบาย หรือคะแนนตามรูบริกที่นำไปใช้กับเรกคอร์ดหลายพันรายการ — ขั้นตอนนั้นคือสิ่งที่โมเดลนี้เข้ามาแทนที่ ในราคา $0.042 ต่อโทเคนอินพุตหนึ่งล้านโทเคน โดยฝั่งเอาต์พุตไม่มีการคิดวัดใด ๆ ถ้าคุณมีขั้นตอนที่ต้องได้คำตอบเป็นข้อความเขียน Jev ไม่ใช่เครื่องมือที่เหมาะ และผู้ขายของมันเองก็บอกไว้เช่นนั้น

สิ่งที่เปลี่ยนไปในสัปดาห์ที่ผ่านมาไม่ใช่ตัวโมเดล แต่คือการที่การลองใช้มันไม่จำเป็นต้องมีความสัมพันธ์กับผู้ขายรายที่สองอีกต่อไป แปดวันก่อน การประเมิน Jev หมายถึงบัญชีแยกต่างหากและการผสานรวมแยกต่างหาก วันนี้มันคือ model id หนึ่งรายการบนคีย์ที่เข้าถึงโมเดลมากกว่า 200 รายการอยู่แล้ว โดยราคาตามรายการของผู้ขายถูกส่งผ่านไปโดยไม่เปลี่ยนแปลง และคำตอบที่พิมพ์กลับมาจากที่เดียวกับทุกสิ่งทุกอย่าง สำหรับโมเดลที่ผิดปกติเช่นนี้ ความสามารถในการทดสอบกับป้ายกำกับของคุณเองโดยไม่ต้องผูกมัดกับสัญญาใหม่คือส่วนสำคัญของการตัดสินใจ