{{1}}System One{{/1}} ในฐานะหมวดหมู่ของโมเดล: {{2}}Jev 1.13{{/2}} อยู่ตรงไหนในนั้น

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

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

สิ่งที่ “เหมือนโค้ดมากขึ้น” อ้างจริง ๆ

พิจารณาข้ออ้างทั้งสี่ตามลำดับ เพราะมันไม่ใช่การพูดซ้ำคำว่า “มันดีกว่า” สี่ครั้ง

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

• รวดเร็ว — คำตอบทั้งหมดถูกสร้างขึ้นในรอบเดียว แทนที่จะเป็นทีละโทเคนต่อโทเคน โพสต์เปิดตัวของ TypeSafe ระบุไว้ว่า "Jev ส่งออกความน่าจะเป็นทั้งหมดแบบขนาน แทนที่จะสร้างแบบ autoregressive ทีละโทเคน" ในช่วงหน้าต่างการให้บริการเจ็ดวันของเรา ซึ่งสิ้นสุดวันที่ 2026-09-30 ค่ามัธยฐานของเวลาถึงโทเคนแรกบน typesafe/jev-1.13 คือ 151 มิลลิวินาที และค่า p95 คือ 247 มิลลิวินาที

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

• ปลอดภัยทางชนิด — และนี่คืออันที่มีน้ำหนักมากที่สุด ปลอดภัยทางชนิดไม่ใช่คำคุณศัพท์บอกคุณภาพในที่นี้ แต่เป็นข้อความเกี่ยวกับตำแหน่งของโมเดลเมื่อเทียบกับตัวตรวจสอบชนิดข้อมูล ในไปป์ไลน์แบบเจเนอเรทีฟทั่วไป ระบบชนิดข้อมูลจะเริ่มทำงานหลังจากโมเดลทำงานเสร็จ: โมเดลเขียนข้อความ ตัวแยกวิเคราะห์คาดเดารูปแบบ ตัวตรวจสอบความถูกต้องตรวจสอบมัน และเส้นทางความล้มเหลวจัดการกรณีที่คาดเดาผิด โมเดล System One ย้ายการประกาศชนิดข้อมูลไปไว้ก่อนการเรียก สามพริมิทีฟที่การ์ดของเราอธิบายไว้คือระบบชนิดข้อมูล: noul ซึ่งเป็นการตัดสินจริง/เท็จที่ส่งคืนพร้อมความน่าจะเป็นที่ปรับเทียบแล้ว; choice ซึ่งเป็นป้ายกำกับหนึ่งป้ายที่เลือกจากตัวเลือกที่มีป้ายกำกับสูงสุด 255 ตัว; และ score ซึ่งเป็นการให้คะแนนบนสเกลเรียงลำดับ 2 ถึง 10 ระดับ คุณเลือกพริมิทีฟ คุณระบุป้ายกำกับหรือเกณฑ์ และค่าที่ส่งกลับมาจะถูกดึงมาจากชุดนั้น

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

สองรูปแบบความล้มเหลวที่หยุดมีอยู่

ผลลัพธ์ที่น่าสนใจของ "no prose" ไม่ใช่เรื่องสุนทรียศาสตร์ แต่คือความจริงที่ว่าความล้มเหลวสองประการซึ่งครองไปป์ไลน์การสร้างสรรค์ระดับโปรดักชันนั้นไม่มีอยู่ในดีไซน์นี้ แทนที่จะถูกบรรเทาโดยดีไซน์นี้

การคลาดเคลื่อนของรูปแบบคือปัญหาแรก LLM ที่ถูกสั่งให้คืนค่า JSON จะคืนค่า JSON เป็นส่วนใหญ่ และคืนค่าสิ่งที่ใกล้เคียงกับ JSON ในส่วนที่เหลือ — คอมเมนต์ต่อท้าย, เครื่องหมายครอบ markdown, ฟิลด์ที่ถูกเปลี่ยนชื่อเป็นคำพ้องความหมาย, ออบเจ็กต์ที่ซ้อนกันในจุดที่สคีมาคาดหวังสตริง การแก้ไขที่ระดับพรอมป์ต์ (คำสั่งที่เข้มงวดขึ้น, ตัวอย่าง few-shot, สคีมาในข้อความระบบ) ล้วนเป็นความพยายามที่จะยึดรูปแบบที่โมเดลมีอิสระที่จะทิ้งไป เพราะรูปแบบนั้นเป็นคำขอ ไม่ใช่ข้อบังคับ การวางกรอบของ TypeSafe ทำให้เห็นความแตกต่างอย่างชัดเจน: เมื่อใช้สตริง "ผลลัพธ์และโครงสร้างที่เป็นไปได้" จะถูกขอ และการตอบกลับ "จำเป็นต้องถูกแยกวิเคราะห์ + ตรวจสอบความถูกต้อง" โดย "มีความเสี่ยงเสมอที่ AI จะออกนอกลู่นอกทาง" เมื่อผลลัพธ์ที่เป็นไปได้ถูกประกาศไว้ล่วงหน้า การคลาดเคลื่อนก็ไม่มีที่ให้ไป

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

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

ทำไมราคาจึงเป็นรูปทรง ไม่ใช่ส่วนลด

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

ลองวางสองรูปแบบนี้เทียบกันดู แล้วจะเห็นว่าความแตกต่างไม่ใช่แค่เปอร์เซ็นต์ ต้นทุนของไปป์ไลน์แบบเจเนอเรทีฟจะแปรผันตามปริมาณที่โมเดลพูด: คำตอบที่เยิ่นเย้อมีต้นทุนสูงกว่าคำตอบที่กระชับสำหรับการตัดสินใจเดียวกัน และโมเดลการให้เหตุผลแบบ chain-of-thought จะคิดค่าบริการตามโทเค็นที่มันใช้คิดก่อนจะตอบ ไม่ว่าคำตอบจะดีขึ้นหรือไม่ก็ตาม ต้นทุนของการเรียกใช้ System One แปรผันตามปริมาณที่คุณป้อนให้มันดู — นั่นคือสถานะและคำถาม ถามคำถามเดียวกับเอกสารยาว ๆ คุณก็ต้องจ่ายค่าเอกสารนั้น อัดคำถามสี่สิบข้อเข้ากับสถานะเดียวกัน (งบอินพุตบนการ์ดของเราคือ 65,536 โทเค็นสำหรับสถานะและคำถามรวมกัน ประมาณ 64K; หากคุณเคยเห็นตัวเลข "ประมาณ 32,000 โทเค็น" ในบทความ OrcaRouter ก่อนหน้านี้ นั่นคืองบสำหรับสถานะเพียงอย่างเดียว ไม่ใช่ยอดรวมอีกตัวที่มาแข่งกัน) แล้วคุณจะจ่ายค่าเอกสารครั้งเดียวและได้การตัดสินใจกลับมาสี่สิบครั้ง

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

ตัวเลขของ TypeSafe เอง ซึ่งเป็นตัวเลขที่ผู้ขายรายงานเองและยังไม่มีการทำซ้ำอย่างอิสระ ถูกมุ่งเป้าไปที่การเปรียบเทียบนั้นโดยตรง: “เร็วกว่า 193.6 เท่า ถูกกว่า 444.6 เท่า” มีเชิงอรรถว่า “อ้างอิงจากเวิร์กโฟลว์สำหรับงานของ System One (หลักฐาน)” พร้อมตัวอย่างที่คำนวณไว้ซึ่งระบุว่า “ต้นทุน TypeSafe AI $0.000081 เสร็จสิ้นใน 0.114s / ต้นทุน LLMs $0.013880 เสร็จสิ้นใน 8.566s” หน้าแรกยังระบุ “$42 ต่ออินพุตหนึ่งพันล้านโทเคน” เทียบกับ “ราคาอินพุตต่ำกว่า Claude Fable 5.1 ถึง 238 เท่า” ให้ถือว่าทั้งหมดเป็นข้อโต้แย้งของผู้ขาย ไม่ใช่ผลลัพธ์ที่วัดได้: โพสต์เปิดตัวยอมรับว่า “การประเมินที่เราเผยแพร่โดยทั่วไปรันจากแล็ปท็อปของเราบนชายฝั่งตะวันตก” และว่า “เราไม่สามารถพิสูจน์ได้ว่ามันไม่ได้รับการอุดหนุน เราจะต้องใช้ระยะยาวเพื่อพิสูจน์ความยั่งยืนของราคาของเรา (ซึ่งเราคาดว่าจะลดลง ไม่ใช่เพิ่มขึ้น)” ข้อยอมรับสองข้อนั้นเป็นของผู้ขายเอง และเป็นกรอบที่ถูกต้องสำหรับตัวคูณทุกตัวบนหน้านั้น

การสอบเทียบคือครึ่งหลังของแนวคิด

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

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

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

ตำแหน่งที่ System One ตั้งอยู่ข้าง ๆ System Two

คำศัพท์ fast/slow มีมานานก่อนที่ TypeSafe จะมีขึ้น มาจากหนังสือของ Kahneman ที่ชื่อ คิดเร็ว คิดช้า และมันถูกนักวิจัยด้าน AI ยืมใช้มาหลายปีก่อนหน้านี้ — ป้ายกำกับ "System 2" ถูกนำไปผูกกับโมเดลแบบ chain-of-thought และโมเดลแบบให้เหตุผลอย่างไตร่ตรอง นานก่อนที่ TypeSafe จะมีอยู่ และ TypeSafe ไม่ได้อ้างว่าเป็นผู้บัญญัติคำศัพท์ใดคำศัพท์หนึ่งในสองคำนี้ สิ่งที่พวกเขาทำคือนำความแตกต่างนี้ไปใช้กับขอบเขตของผลิตภัณฑ์ มากกว่าที่จะใช้กับโหมดการพรอมป์

• โมเดลการให้เหตุผลแบบ System Two ใช้การประมวลผลมากขึ้นก่อนที่จะตอบ และเก่งขึ้นกับปัญหาที่ต้องใช้มัน ผลลัพธ์ของมันยังคงเป็นข้อความร้อยแก้ว และการประมวลผลที่เพิ่มขึ้นจะถูกคิดค่าใช้จ่ายเป็นโทเค็นเอาต์พุต

• โมเดล System One ในความหมายของ TypeSafe ไม่ได้ใช้เวลาคิดนานขึ้นเพื่อตอบให้ดีขึ้น มันตอบในรอบเดียว และสิ่งที่มันยอมสละไปเพื่อความเร็วนั้น คือความสามารถในการให้ผลลัพธ์เป็นสิ่งอื่นใดนอกจากค่าที่มีชนิดข้อมูล

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

จุดที่คำศัพท์เริ่มลื่นไหลคือการปฏิบัติต่อ "System One model" ราวกับเป็นหมวดหมู่ที่establishedแล้วซึ่งผู้ขายรายอื่นรับไปใช้ ไม่มีหลักฐานสำหรับเรื่องนั้น และไม่ควรอ่านหน้านี้ว่าเป็นการอ้างเช่นนั้น TypeSafe ใช้คำนี้กับกลุ่มโมเดลของตัวเอง ส่วนข้อจำกัดความรับผิดในการ์ดของเราเองก็กล่าวถึงสิ่งเดียวกันโดยการละเว้น โดยระบุประเภทเอนด์พอยต์เพียงประเภทเดียวสำหรับโมเดลเดียว หากห้องแล็บอื่นเริ่มใช้ถ้อยคำนี้กับสถาปัตยกรรมเดียวกัน นั่นจะเป็นข้อเท็จจริงที่คุ้มค่าแก่การรายงาน และจะต้องใช้ถ้อยคำของพวกเขาเองในการรายงาน

การ์ดของเรายังระบุความขรุขระ (jaggedness) เป็นส่วนหนึ่งของเส้นเขตแดนที่ซื่อตรง มากกว่าจะเป็นเรื่องน่าประหลาดใจ: รูปแบบความล้มเหลวที่มีชื่อเรียกเก้าประการ รายการการอ่านตามตัวอักษรและการอ้อมค้อมเป็นรายการที่ตามมาจากการเปรียบเทียบแบบ "เหมือนโค้ดยิ่งขึ้น" โดยตรง — โมเดลที่ตอบคำถามที่คุณเขียนไว้ แทนที่จะตอบคำถามที่คุณตั้งใจถาม กำลังทำตัวเหมือนฟังก์ชันที่ทำตามที่โค้ดสั่งไว้จริง ๆ ส่วนรายการการนับไม่เป็นเช่นนั้น โมเดลที่ "recognizes the shape of an answer rather than tallying" ไม่เหมือนโค้ดเลย ซึ่งเป็นเหตุผลว่าทำไมคำแนะนำของ TypeSafe เองคือให้นับในโค้ด และในกรณีที่จำเป็นต้องใช้วิจารณญาณจริง ๆ ให้ถามทีละคำถามต่อหนึ่งรายการ แล้วรวมคำตอบด้วยตัวคุณเอง

สองข้อจำกัดที่กำหนดการออกแบบ ไม่ใช่คะแนน

ทั้งสองสิ่งมาจากที่เดียวกัน: การไม่มีสตริงหมายถึงไม่มีอะไรให้สตรีมและไม่มีอะไรให้ส่งเป็นชิ้น ๆ

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

• รูปแบบคำขอเดียว — โมเดลนี้ให้บริการผ่าน POST /v1/systemone บนแคตตาล็อกของเรา แทนที่จะเป็นรูปแบบ chat-completions และนั่นคือคำกล่าวที่ตรงไปตรงมาของข้ออ้างเดิมที่ว่ามัน "มีรูปแบบคำขอเป็นของตัวเอง" นี่คือความแตกต่างจริงในวิธีที่คุณเรียกใช้มัน: ออบเจ็กต์สถานะและแมปคำถามที่มีชื่อถูกส่งเข้าไป; คำตอบแบบมีโครงสร้างต่อคำถามถูกส่งออกมา คุณจะเขียนตัวแมปเปอร์สำหรับมัน และเนื่องจากเอาต์พุตมีการระบุชนิด ตัวแมปเปอร์จึงเป็นการผสานรวมทั้งหมด — ไม่มีเลเยอร์การแยกวิเคราะห์เชิงป้องกันอยู่ข้างใต้มัน

สิ่งที่ควรรู้ก่อนที่คุณจะทดสอบโหลด: ความหน่วงไม่ได้คงที่เท่ากันในทุกประเภทคำถาม TypeSafe อธิบายเหตุผลไว้ด้วยคำพูดของพวกเขาเอง — "สำหรับตัวเลือกที่มีภาวะเชิงจำนวนสูงกว่า เราใช้ระบบ 2 ขั้นตอน คือให้คะแนนอย่างเป็นอิสระ แล้วจึงเลือกอย่างชัดเจน จึงเกิดความช้าลงเป็นครั้งคราว" การตัดสินใจจัดเส้นทางแบบ 4 ตัวเลือก กับการจำแนกแบบ 200 ตัวเลือก บนกระดาษแล้วเป็นพริมิทีฟเดียวกัน แต่ในทางปฏิบัติใช้ปริมาณงานต่างกัน ค่ามัธยฐานรายวันของเราในช่วงเจ็ดวันสิ้นสุด 2026-09-30 อยู่ที่ 175, 170, 163, 161, 170, 147, 143 มิลลิวินาที หนึ่งวันในชุดนั้น คือ 2026-09-28 มี p95 ที่ 2,448 มิลลิวินาที — เป็นค่าผิดปกติของวันเดียวจริง ที่อยู่ในชุดข้อมูลอย่างซื่อตรง แต่ไม่ใช่ลักษณะโดยรวมของบริการ

อีกสิ่งที่ต้องรู้ก่อนการผสานรวมครั้งแรกคือคุณกำลังเชื่อมต่อไปยังอะไร เครื่องมือต่าง ๆ รอบ Jev เป็นโอเพนซอร์สภายใต้สัญญาอนุญาต MIT และ Apache-2.0 — มี Python และ JavaScript SDK, อะแดปเตอร์ที่นำเสนอไคลเอนต์ตัวเดียวกันซึ่งทำงานผ่าน API ของ LLM ทั่วไป, โค้ด workflow-evals และชุดทักษะของเอเจนต์ ทั้งหมดอยู่ในรีโพซิทอรีสาธารณะของ TypeSafe โดยมีจำนวนดาวและวันที่ push ที่เพิ่งขยับล่าสุดเมื่อ 2026-09-26 และ 2026-09-29 แต่โมเดลไม่เปิด ไม่มีรีโพซิทอรีจัดเก็บเวต: สถาปัตยกรรม จำนวนพารามิเตอร์ ทรัพยากรการคำนวณที่ใช้ฝึก และเวตของ Jev ไม่ได้รับการเปิดเผย และผู้อ่านที่ตรวจสอบเรื่องนี้ไม่ควรถูกทำให้เข้าใจผิดโดยสามรีโพซิทอรีในองค์กรนั้นซึ่งเป็นฟอร์กของโปรเจกต์ที่ไม่เกี่ยวข้อง — ฟอร์กของ vLLM, รีลีสโมเดลภาษาดิฟฟิวชันจากปี 2025 และผู้ให้บริการ Pulumi ไม่มีรีโพซิทอรีใดในนั้นบอกอะไรเกี่ยวกับวิธีที่ Jev ถูกสร้างขึ้น คำตอบแบบบรรทัดเดียวคือ เครื่องมือเปิด แต่โมเดลไม่เปิด

การรันมันในวันนี้ และสิ่งที่เปลี่ยนแปลงไปสำหรับผู้อ่าน

Jev 1.13 อยู่บน OrcaRouter ในชื่อ typesafe/jev-1.13 เข้าถึงได้ด้วยคีย์เดียวกับโมเดลอื่นอีกกว่า 200 โมเดล โดยราคาตามรายการของผู้ให้บริการถูกส่งผ่านโดยคิดมาร์กอัป 0% คุณค่าในทางปฏิบัติของสิ่งนี้บนหน้าเกี่ยวกับหมวดหมู่หนึ่งนั้นแคบ และควรค่าแก่การระบุให้ชัดเจน: การลองโมเดล System One ไม่จำเป็นต้องมีบัญชีแยก คีย์แยก และใบแจ้งหนี้แยกสำหรับโมเดลที่คุณอาจยังไม่รู้ว่าตัวเองต้องการ อีกทั้งมันอยู่ข้าง ๆ ครึ่งด้านการสร้างของเวิร์กโฟลว์เดียวกัน — ตัวจำแนกและตัวเขียนบนข้อมูลรับรองเดียว ในที่เดียว พร้อมจำนวนนับของสิ่งที่คุณเรียกใช้จริง

ไม่มีอะไรตรงนี้เปลี่ยนสิ่งที่โมเดลนี้เป็น มันเปิดตัวเมื่อ 2026-09-15 และ TypeSafe ยังคงอธิบายว่ามันอยู่ในสถานะ early access สิ่งที่มันเป็นไม่ได้ขยับไปไหนนับตั้งแต่นั้น สิ่งที่เปลี่ยนไปเมื่อ 2026-09-24 คือตอนนี้ผู้อ่านสามารถรู้ได้ว่ามันมีค่าใช้จ่ายเท่าไรในทางปฏิบัติ โดยไม่ต้องผูกพันกับความสัมพันธ์กับผู้ขายรายที่สองก่อน หากคุณกำลังรออยู่เพื่อดูว่าหมวดหมู่นี้คุ้มค่าที่จะลองทำต้นแบบหรือไม่ นั่นแหละคือสิ่งที่ขยับไปแล้ว