TL;DR
Jev เป็นโมเดลตัดสินใจที่พัฒนาโดย TypeSafe AI. TypeSafe เปิดตัว Jev เมื่อวันที่ 15 กันยายน 2026 ในฐานะ System One model ตัวแรก ออกแบบมาเพื่อส่งคืนผลการตัดสินใจแบบมีโครงสร้างและความน่าจะเป็นที่ซอฟต์แวร์นำไปใช้ได้โดยตรง คู่มือนี้อ้างอิงจากเอกสารทางการของ TypeSafe, Quick Start, อ้างอิงโมเดล และ ประกาศอย่างเป็นทางการเกี่ยวกับ Jev
Jev ไม่เขียนร้อยแก้ว ไม่สร้างโค้ด และไม่สนทนา มันประเมิน state ที่เป็นข้อความเทียบกับคำถามแบบมีชนิด (typed questions) และส่งคืนคำตอบที่มีโครงสร้างซึ่งแอปพลิเคชันใช้ได้โดยตรง
ความแตกต่างนี้สำคัญต่อเวิร์กโฟลว์ซอฟต์แวร์ โมเดลภาษาขนาดใหญ่แบบดั้งเดยวจะสร้าง tokens แม้ว่าแอปพลิเคชันต้องการเพียงหมวดหมู่ คะแนน หรือคำตัดสินแบบใช่-ไม่ใช่ Jev ถูกออกแบบโดยยึดผลการตัดสินใจเป็นศูนย์กลาง อินเทอร์เฟซรับ state และคำถามหนึ่งข้อขึ้นไป แล้วส่งคืนค่าที่มีชนิดและการกระจายความน่าจะเป็น คำตอบแบบ Choice และ Score ยังมีค่าความเชื่อมั่น (confidence) ด้วย
Jev ตั้งใจใช้กับงานจำแนกเส้นทาง การจัดเส้นทาง การให้คะแนน การตรวจสอบ การคุ้มกัน (guardrails) และการตัดสินใจแบบมีขอบเขตอื่นๆ มันไม่ใช่ตัวแทนทั่วไปของ GPT, Claude, Gemini หรือโมเดลเชิงกำเนิดอื่นๆ ในตัวแทน AI โมเดลเชิงกำเนิดสามารถวางแผนหรือสร้างเนื้อหา ขณะที่ Jev จัดการการตัดสินใจที่เกิดขึ้นบ่อย เช่น การเลือกเส้นทาง ตรวจสอบความเสี่ยง หรือพิจารณาว่าผลลัพธ์ต้องการการทบทวนหรือไม่
Key Takeaways
- Jev ถูกพัฒนาโดย TypeSafe และนำเสนอเป็น System One model แฟลกชิปในปัจจุบัน
- โมเดลรับ state ที่เป็นข้อความพลัสคำถามแบบมีชนิด และส่งคืนผลการตัดสินใจแบบมีโครงสร้างแทนการสร้างร้อยแก้ว
- Jev รองรับคำถาม 3 ประเภท ได้แก่ Choice, Score และ Noul
- สามารถประเมินหลายคำถามแบบเป็นอิสระและขนานกันกับ state เดียวกันในคำขอเดียว
- TypeSafe ฝึก Jev ด้วย Reinforcement Learning for Calibrated Decisions หรือ RLCD
- หน้ารุ่นทางการปัจจุบันระบุ Jev 1.13 มีขีดจำกัดคำขอ 64,000 tokens และรับเฉพาะอินพุตข้อความ
- ราคาทางการคือ $0.042 ต่อหนึ่งล้าน tokens อินพุต Tokens เอาต์พุตระบุว่าไม่คิดค่าใช้จ่าย
- เอาต์พุตแบบ type-safe ป้องกันการไม่ตรงกันของสคีมา แต่มิได้การันตีว่าทุกการตัดสินใจทางธุรกิจถูกต้อง
- TypeSafe รายงาน latency 70 ถึง 500 มิลลิวินาที และการเพิ่มขึ้นมากในผลประเมินเวิร์กโฟลว์ของตน ตัวเลขเหล่านี้มาจากผู้ให้บริการและใช้กับงานรูปแบบ System One
What Is Jev?
Jev เป็นโมเดลตัดสินใจที่สร้างโดย TypeSafe AI เอกสารทางการ ระบุว่าเป็นโมเดลแฟลกชิปของบริษัทและเป็น System One model ตัวแรก อินพุตมีสองส่วนหลัก
ส่วนแรกคือ state คือข้อมูลที่ Jev ควรตรวจสอบ เช่น ข้อความจากลูกค้า รายงานเหตุการณ์ ชุดบันทึก หรือออบเจ็กต์ JSON ที่มีบริบทของแอปพลิเคชัน
ส่วนที่สองคือชุดคำถามแบบมีชนิด แต่ละคำถามกำหนดคำตัดสินและรูปแบบคำตอบที่อนุญาต Jev ประเมินคำถามเทียบกับ state และส่งคืนผลลัพธ์ที่โค้ดสามารถแตกแขนง จัดเรียง ให้คะแนน หรือจัดเส้นทางได้
ลองพิจารณาคำขอซัพพอร์ตที่รายงานว่าการผสานระบบการชำระเงินล้มเหลวติดต่อกันสามวัน ระบบซัพพอร์ตอาจไม่ต้องการย่อหน้าที่บรรยายสถานการณ์ แต่ต้องการการตัดสินใจแคบๆ สามข้อแทน:
- ทีมใดควรรับทิกเก็ตนี้?
- ลูกค้าดูหงุดหงิดแค่ไหน?
- ข้อความนี้ต้องการความสนใจอย่างเร่งด่วนหรือไม่?
Jev สามารถแทนสิ่งเหล่านี้เป็นคำถาม Choice, Score และ Noul ในคำขอเดียว การตอบกลับมีหมวดที่เลือกหรือคะแนน การกระจายความน่าจะเป็นที่เกี่ยวข้อง และความเชื่อมั่น (เมื่อรองรับ) จากนั้นแอปพลิเคชันตัดสินใจว่าจะทำอย่างไรกับค่านั้น
การแบ่งหน้าที่นี้จงใจ โมเดลจัดหาคำตัดสินที่มีความไม่แน่นอนในรูปแบบที่เสถียร โค้ดแอปพลิเคชันยังคงควบคุมค่าธรณี (thresholds) การอนุญาต ผลข้างเคียง และพฤติกรรมสำรอง
What Is a System One Model?
TypeSafe ใช้คำว่า System One model สำหรับคลาสของโมเดลที่ออกแบบมาเพื่อทำการตัดสินใจแบบมีโครงสร้างอย่างรวดเร็วที่ซอฟต์แวร์สามารถใช้งานได้ ชื่อนี้อ้างอิงความแตกต่างระหว่างการคิดเร็วและช้าในงานของ Daniel Kahneman อธิบายบทบาทที่ตั้งใจของโมเดล ไม่ใช่การกล่าวอ้างว่าโมเดลซอฟต์แวร์จำลองการรับรู้ของมนุษย์
งานแบบ System One มีวัตถุประสงค์จำกัด ผู้ตรวจทานที่มีความรู้ควรสามารถทำคำตัดสินได้อย่างรวดเร็วเมื่อได้รับบริบทเพียงพอ ตัวอย่างรวมถึงการเลือก intent การให้คะแนนความเร่งด่วนบนสเกลที่กำหนด ตรวจว่าข้ออ้างได้รับการสนับสนุนหรือไม่ หรือการตัดสินว่าควรยกระดับคำขอหรือไม่
งานที่ต้องการการวิจัยขยาย การอนุมานหลายขั้นตอน คำอธิบายแบบยาว หรือการสร้างเนื้อหาไม่เหมาะนัก TypeSafe แนะนำให้แยกคำตัดสินกว้างๆ เป็นคำถามแบบอะตอมมิกและรวมผลลัพธ์ในโค้ด
ตัวอย่างเช่น ให้คะแนนพิตช์สตาร์ทอัพนี้กว้างเกินไปสำหรับคำตัดสินที่ตรวจสอบได้ ขนาดตลาด ความเป็นไปได้ทางเทคนิค และความแตกต่าง สามารถประเมินเป็นคำถามแยกกัน แอปพลิเคชันรวมคะแนนเหล่านั้นด้วยสูตรชัดเจน หากลำดับความสำคัญทางธุรกิจเปลี่ยน น้ำหนักสามารถเปลี่ยนในโค้ดโดยไม่ทำให้พรอมต์โมเดลกลายเป็นตรรกะธุรกิจที่ซ่อนอยู่
How Does Jev Work?
สัญญาการทำงานของ Jev สามารถเขียนได้ว่า:
State + typed questions -> typed decisions + probabilities
ซึ่งต่างจากโฟลว์ของโมเดลภาษาปกติ:
Prompt -> generated tokens -> parsing and validation -> application decision
ความแตกต่างไม่ใช่เพียงรูปแบบการตอบ Traditional structured output ยังขอให้โมเดลเชิงกำเนิดสร้างลำดับ tokens ที่สอดคล้องกับสคีมา Jev ถูกออกแบบมาเพื่อส่งคืนค่าจากพื้นที่คำตอบที่กำหนดไว้ล่วงหน้า
API ปัจจุบันรับ state เป็นสตริง ออบเจ็กต์ JSON หรืออาเรย์ของค่าข้อความ อินพุตเป็นข้อความเท่านั้น ภาพ เสียง วิดีโอ และเอกสารไบนารีต้องแปลงเป็นข้อความหรือฟิลด์ที่มีโครงสร้างก่อนส่ง
ทุกคำถามในคำขอจะถูกประเมินอย่างอิสระกับ state เดียวกัน ตามเอกสารของ TypeSafe การเพิ่มคำถามแทบไม่เปลี่ยนเวลาในการตอบเพราะประเมินแบบขนาน ความเป็นอิสระยังป้องกันไม่ให้คำตอบของคำถามหนึ่งกลายเป็นบริบทของอีกคำถามในคำขอเดียวกัน
พฤติกรรมนี้มีผลต่อการออกแบบสำคัญ หากการตัดสินใจหนึ่งขึ้นกับอีกการตัดสินใจจริงๆ ความพึ่งพานั้นควรอยู่ในเวิร์กโฟลว์ของแอปพลิเคชัน รันการประเมินแรก อัปเดต state หรือแตกแขนงในโค้ด แล้วทำการประเมินถัดไป คำขอเดียวเหมาะกับคำถามที่ใช้หลักฐานร่วมกันแต่ไม่ขึ้นต่อกัน
The Three Jev Question Types
Jev เปิดเผย primitive 3 แบบ แต่ละแบบตรงกับการตัดสินใจของซอฟต์แวร์ที่ต่างกัน
| Question type | วัตถุประสงค์ | ส่งคืน | ตัวอย่างที่เหมาะสม |
|---|---|---|---|
| Choice | เลือกหนึ่งตัวเลือกจากชุดที่กำหนด | ตัวเลือกที่เลือก ความน่าจะเป็นของตัวเลือก ค่า confidence | การจำแนก intent การจัดเส้นทางทีม การเลือกโมเดล |
| Score | ให้คะแนน state ตาม rubric แบบลำดับ | คะแนน ความน่าจะเป็นของแต่ละระดับ ค่า confidence | ความเร่งด่วน คุณภาพ ความเสี่ยง เจตนาการซื้อ |
| Noul | ประมาณว่าข้อความหนึ่งเป็นจริงหรือไม่ | ค่า 0 ถึง 1 | ตรวจนโยบาย ตรวจความสมบูรณ์ คุณสมบัติแบบไบนารี |
Choice
คำถามแบบ Choice เลือกหนึ่งตัวเลือกจากเกณฑ์ที่แอปพลิเคชันกำหนด เวิร์กโฟลว์ซัพพอร์ตอาจให้ billing, technical และ sales พร้อมคำอธิบายสำหรับแต่ละหมวด Jev ส่งคืนตัวเลือกที่เลือก การแจกแจงความน่าจะเป็นของทุกตัวเลือก และค่า confidence ที่ได้จากรูปทรงของการแจกแจงนั้น
การออกแบบหมวดหมู่ส่งผลต่อประโยชน์ของผลลัพธ์ ตัวเลือกที่ทับซ้อนสร้างความคลุมเครือ ตัวเลือกที่ขาดบังคับโมเดลไปสู่คำตอบที่อาจไม่เหมาะ แท็กซอนมีในโปรดักชันควรรวมเส้นทางเช่น insufficient_evidence หรือ human_review เมื่อเวิร์กโฟลว์ต้องการรักษาความไม่แน่นอน
ถ้อยคำก็ควรตรงกับคำตัดสินจริง ทีมใดควรตรวจสอบก่อน ถามถึงเส้นทางชั่วคราว ทีมใดเป็นสาเหตุของความล้มเหลว ถามถึงการวินิจฉัย อาจใช้รายชื่อทีมเดียวกัน แต่ไม่ใช่คำถามเดียวกัน
Score
คำถามแบบ Score วาง state บน rubric แบบลำดับ เกณฑ์อาจอธิบายระดับ เช่น calm, frustrated, angry หรือกำหนดสเกลธุรกิจที่ละเอียดกว่า การตอบรวมคะแนนตัวเลข ตำนานเชื่อมตัวเลขกับระดับ การกระจายความน่าจะเป็นข้ามระดับ และค่า confidence
Rubric ของ Score ที่มีประโยชน์จะอธิบายความแตกต่างที่สังเกตได้ ป้ายกำกับที่ไร้นิยามปล่อยให้โมเดลและผู้ตรวจทานตีความมาตรฐานต่างกัน สเกลความเสี่ยงควรระบุสิ่งที่แยกระหว่างแต่ละระดับ สเกลคุณภาพควรระบุข้อกำหนดที่มีหรือขาด
หากคะแนนผสมความกังวลอิสระหลายอย่าง ควรแยกเป็นคำถามต่างหาก ความเกี่ยวข้อง การสนับสนุนด้วยข้อเท็จจริง น้ำเสียง และการปฏิบัติตามนโยบาย สามารถเป็นคำถามแยกกัน โค้ดแอปพลิเคชันคำนวณคะแนนรวมด้วยน้ำหนักที่ยังคงมองเห็นและทดสอบได้
Noul
Noul เป็น primitive การตัดสินใจแบบไบนารีของ TypeSafe มันประมาณความน่าจะเป็นว่าข้อความหนึ่งเป็นจริงและส่งคืนตัวเลข 0 ถึง 1 ค่า 0.9 แทนความน่าจะเป็นสูงกว่าค่า 0.6
Noul ไม่ส่งคืนฟิลด์ confidence แยกเหมือน Choice และ Score เอาต์พุตของมันเป็นความน่าจะเป็นของข้อความที่ประเมินอยู่แล้ว ดังนั้นคำถามควรเขียนเป็นข้อความที่ทดสอบได้ เช่น ข้อความสื่อถึงความเร่งด่วน หรือคำตอบได้รับการสนับสนุนโดยแหล่งข้อมูลที่ให้ไว้
Noul มีประโยชน์สำหรับการตรวจสอบและการกั้น แต่ค่าธรณีเป็นของแอปพลิเคชัน คำแนะนำอินเทอร์เฟซความเสี่ยงต่ำอาจยอมรับค่าธรณีต่ำกว่าการกระทำทางการเงินหรือการบริหารที่ย้อนกลับไม่ได้
Atomic Questions and Composed Workflows
Jev ทำงานได้ดีที่สุดเมื่อแต่ละคำถามถามเพียงสิ่งเดียวแคบๆ การออกแบบนี้ทำให้เอาต์พุตตรวจสอบได้ง่ายและให้ซอฟต์แวร์เป็นเจ้าของนโยบายสุดท้าย
สมมุติตัวแทนต้องตัดสินใจว่าจะ execute การเรียกใช้เครื่องมือหรือไม่ คำถามกว้างๆ เช่น ควรเรียกใช้งานนี้หรือไม่ อาจรวมการอนุญาต การย้อนกลับได้ ความอ่อนไหวของข้อมูล เจตนาของผู้ใช้ และความเสี่ยงเชิงปฏิบัติการ เวิร์กโฟลว์ที่ตรวจสอบได้มากกว่าประเมินมิติแต่ละอย่างแยกกัน:
- การเรียกใช้เครื่องมือสอดคล้องกับคำขอของผู้ใช้หรือไม่?
- มันส่งข้อมูลอ่อนไหวหรือไม่?
- การกระทำนั้นทำลายล้างหรือย้อนกลับยากหรือไม่?
- มันกระทบกับบัญชีภายนอกหรือไม่?
- นโยบายกำหนดให้ต้องยืนยันเพิ่มเติมหรือไม่?
ฮาร์เนสจึงรวมคำตอบด้วยกฎเชิงกำหนด การดำเนินการที่ทำลายล้างสามารถกำหนดให้ต้องยืนยันไม่ว่าความเชื่อมั่นโดยรวมของโมเดลจะเป็นอย่างไร การดำเนินการแบบอ่านอย่างเดียวสามารถใช้เส้นทางที่จำกัดน้อยกว่า การจัดเรียงนี้ทำให้การอนุญาตอยู่ในโค้ดและใช้ Jev เฉพาะคำตัดสินที่ไม่สามารถแสดงเป็นกฎคงที่ได้อย่างเชื่อถือ
Jev vs Traditional LLMs
Jev และโมเดลภาษาขนาดใหญ่มีบทบาทต่างกัน
| มิติ | Jev | Traditional LLM |
|---|---|---|
| เอาต์พุตหลัก | คำตัดสินแบบมีชนิดและความน่าจะเป็น | ข้อความที่สร้าง โค้ด หรือ tokens แบบมีโครงสร้าง |
| พื้นที่คำตอบ | กำหนดก่อนอนุมาน | เปิดกว้างเว้นแต่ถูกจำกัด |
| การสุ่มตัวอย่าง | ประเมินคำถามแบบขนาน | สร้าง tokens แบบลำดับ |
| งานธรรมชาติ | การจำแนก การจัดเส้นทาง การให้คะแนน การตรวจสอบ | การสนทนา เหตุผลเชิงลึก การเขียน การโค้ด |
| ความไม่แน่นอน | การกระจายความน่าจะเป็น; confidence สำหรับ Choice และ Score | ขึ้นกับผู้ให้บริการและวิธีการ |
| พฤติกรรมสคีมา | เอาต์พุตสอดคล้องกับชนิดคำถามที่รองรับ | เอาต์พุตแบบมีโครงสร้างต้องการการสร้างที่จำกัดด้วยสคีมา |
| บทบาทที่ดีที่สุด | ชั้นตัดสินใจภายในซอฟต์แวร์ | ชั้นการวางแผนและการสร้าง |
ไม่ควรเรียก Jev ว่าเป็น chatbot ขนาดเล็ก TypeSafe ไม่ได้เผยแพร่จำนวนพารามิเตอร์หรือรายละเอียดสถาปัตยกรรมเพียงพอที่จะจัดประเภทขนาดของโมเดล ความแตกต่างสาธารณะอิงวัตถุประสงค์การฝึก วิธีการสุ่ม และอินเทอร์เฟซ
Jev ก็ไม่แทนที่โค้ดเชิงกำหนด กฎคงที่ยังเป็นเครื่องมือที่เหมาะเมื่อเงื่อนไขชัดเจนและคงที่ การคำนวณภาษี รายการอนุญาต หรือขีดจำกัดขนาดไฟล์ไม่ควรกลายเป็นการเรียกโมเดลแบบความน่าจะเป็น Jev มีประโยชน์เมื่อกฎที่เขียนด้วยมือเปราะบางเกินไปแต่คำตอบที่ต้องการยังจำกัดได้
Jev vs Structured LLM Output
เอาต์พุตแบบมีโครงสร้างช่วยให้โมเดลภาษา ส่งคืน JSON หรือค่าที่สอดคล้องกับสคีมา มีค่าสำหรับเวิร์กโฟลว์ที่ต้องการทั้งเหตุผลเชิงกำเนิดและผลลัพธ์ที่เครื่องอ่านได้ Jev ตอบโจทย์ที่แคบกว่า
ด้วย LLM สคีมาจำกัดรูปแบบคำตอบที่สร้าง ด้วย Jev คำถามและพื้นที่คำตอบเป็นอินเทอร์เฟซของโมเดล Jev ส่งคืนการกระจายความน่าจะเป็นที่ตั้งใจให้เข้าร่วมตรรกะแอปพลิเคชัน และคำถามอิสระถูกประเมินแยกกันบน state ร่วม
การที่ JSON มีรูปร่างตรงกันไม่ได้แปลว่าพฤติกรรมตรงกัน สองระบบอาจส่งคืนฟิลด์ชื่อ department เหมือนกัน แต่ต่างกันใน latency การปรับเทียบ การจัดการความคลุมเครือ และเสถียรภาพของคำตอบ ทีมที่เทียบ Jev กับเอาต์พุตแบบมีโครงสร้างของ LLM ควรรักษาสคีมาแอปพลิเคชันให้คงที่และทดสอบทั้งสองระบบบนข้อมูลติดป้ายชุดเดียวกัน
RLCD and Calibrated Decisions
TypeSafe ระบุว่า Jev ถูกฝึกด้วย Reinforcement Learning for Calibrated Decisions RLCD ต่างจาก RLHF และ RLVR ในวัตถุประสงค์
RLHF ปรับคำตอบโดยใช้สัญญาณความชอบของมนุษย์ ใช้อย่างแพร่หลายกับผู้ช่วยสนทนา RLVR ใช้รางวัลที่ตรวจสอบได้ เชื่อมโยงกับงานที่ถูกต้องตรวจสอบได้เชิงโปรแกรม RLCD ฝึกโมเดลของ TypeSafe ให้ส่งคืนการตัดสินใจและความน่าจะเป็นที่ปรับเทียบแล้ว แทนการสร้างข้อความ
การปรับเทียบเกี่ยวข้องกับกลุ่มการทำนาย หากโมเดลได้รับการปรับเทียบดี ผลลัพธ์ที่กำหนดความน่าจะเป็นใกล้ 0.8 ควรถูกต้องประมาณ 80 เปอร์เซ็นต์เมื่อพิจารณาชุดกรณีที่เหมาะสม ไม่ได้การันตีว่าการทำนายเฉพาะที่มีความน่าจะเป็น 0.8 จะถูกต้อง
อย่าปฏิบัติต่อความน่าจะเป็นและความเชื่อมั่นว่าแทนกันได้ Choice และ Score เปิดเผยการกระจายความน่าจะเป็นเต็ม TypeSafe คำนวณความเชื่อมั่นจากรูปทรงของการแจกแจง การแจกแจงที่เข้มข้นในตัวเลือกเดียวให้ความเชื่อมั่นสูงกว่า การแจกแจงแบนๆ ชี้ถึงความคลุมเครือ ทีมสามารถใช้ค่า confidence ที่ให้หรือคำนวณสถิติอื่นจากความน่าจะเป็นได้
Noul ไม่มีฟิลด์ confidence แยก ค่าของมันคือความน่าจะเป็นโดยประมาณว่าข้อความเป็นจริง
Jev Model Specifications and Pricing
รายละเอียดต่อไปนี้มาจากเอกสารโมเดลทางการของ TypeSafe ณ วันที่ 21 กันยายน 2026
| รายการ | ค่าที่ระบุอย่างเป็นทางการ |
|---|---|
| โมเดลเสถียรปัจจุบัน | Jev 1.13 |
| รุ่นโมเดลแบบเวอร์ชัน | jev-1.13.0 |
| ชื่อเล่นเสถียร | jev-latest |
| อินพุต | ข้อความ; สตริง ออบเจ็กต์ JSON หรืออาเรย์ของค่าข้อความ |
| ขีดจำกัดบริบทคำขอ | 64,000 tokens ครอบคลุม state และทุกคำถาม |
| กฎบริบทเพิ่มเติม | 32,000 tokens สำหรับ state บวกคำถามที่ยาวที่สุด |
| ราคาอินพุต | $0.042 ต่อหนึ่งล้าน tokens หรือ $42 ต่อหนึ่งพันล้าน tokens |
| ราคาเอาต์พุต | ฟรี |
| ข้อจำกัดอัตราที่เผยแพร่ | 250,000 tokens ต่อวินาที และ 1,200 คำขอต่อนาที |
| ภาษาฝึกหลัก | English |
| อินพุตที่ไม่ใช่ข้อความ | ไม่รองรับโดยตรง |
TypeSafe ระบุว่าข้อจำกัดอัตรากำลังปรับแบบไดนามิกและอาจเปลี่ยนโดยไม่แจ้งให้ทราบ ควรตรวจราคาปัจจุบันก่อนปรับใช้จริง
เอกสารยังระบุว่า English เป็นภาษาฝึกหลักและให้ความแม่นยำดีที่สุดในปัจจุบัน ภาษาอื่นรวมถึงอักษร CJK รองรับแต่ไม่เท่ากัน งานภาษาจีน ญี่ปุ่น หรือเกาหลีควรถูกประเมินด้วยข้อมูลที่แทนจริงก่อนเปิดใช้งานการตัดสินใจอัตโนมัติ
TypeSafe ระบุว่า Jev ไม่ถูก fine-tune หรือ LoRA-adapt ด้วยข้อมูลของลูกค้าแต่ละราย น้ำหนักโมเดลเดียวกันให้บริการทุกบัญชี พฤติกรรมโดเมนถูกกำหนดผ่าน state คำสั่ง เกณฑ์ และการประกอบฝั่งแอปพลิเคชัน บริษัทยังระบุว่าคำขอและคำตอบของลูกค้าไม่ถูกใช้ฝึก Jev ลูกค้าองค์กรสามารถดูเอกสารทางกฎหมายของ TypeSafe สำหรับเงื่อนไข zero data retention
How Fast Is Jev?
TypeSafe รายงานเวลาในการตอบปลายถึงปลาย 70 ถึง 500 มิลลิวินาที โพสต์เปิดตัวเปรียบเทียบช่วงนี้กับ 3 ถึง 329 วินาทีสำหรับการเรียกโมเดลแนวหน้าแบบคัดเลือก และอธิบายว่า Jev เร็วกว่าระหว่าง 40 ถึง 200 เท่าในระดับสติปัญญาที่เทียบได้บนงานรูปแบบ System One
บริษัทยังรายงานการเพิ่มสูงสุด 193.6 เท่าในความเร็วและ 444.6 เท่าในค่าใช้จ่ายบนการประเมินเวิร์กโฟลว์ของตน ตัวเลขเหล่านี้ต้องการบริบท
พวกมันมาจากกรอบประเมินของ TypeSafe เอง เวิร์กโฟลว์เปรียบเทียบโมเดลบนกราฟการตัดสินใจแบบมีโครงสร้าง และใช้ค่าเฉลี่ยการทำนายของโมเดลภายนอกระดับสูงที่คัดเลือกเป็นความน่าจะเป็นอ้างอิง TypeSafe ระบุว่าการเพิ่มที่รายงานอาจอยู่ใกล้ขอบบนของการปรับปรุงในโลกจริง และยอมรับอคติที่เป็นไปได้เพราะสมาชิกทีมความสามารถของโมเดลสร้างเวิร์กโฟลว์เหล่านั้น
ผลลัพธ์เหล่านี้ไม่ควรอ่านว่า Jev เร็วกว่าทุก LLM หลายร้อยเท่าบนทุกงาน Jev สละการสร้างข้อความและมุ่งเป้าการตัดสินใจแบบมีขอบเขต การเปรียบเทียบที่ยุติธรรมควรใช้งานที่ทั้งสองระบบทำได้ วัดคุณภาพการตัดสินใจรวมถึง latency และรวมต้นทุนการตรวจสอบ ความพยายามซ้ำ และการทบทวนโดยมนุษย์
What Is Jev Best for
Jev เหมาะกับเวิร์กโฟลว์ปริมาณสูงที่มีพื้นที่คำตอบกำหนดไว้และต้องการการประมาณความไม่แน่นอน
- Customer Support Triage: จำแนกทิกเก็ตตามแผนก ความเร่งด่วน ความหงุดหงิด ความเสี่ยง churn หรือความจำเป็นในการทบทวนโดยมนุษย์
- Intent and Model Routing: ระบุประเภทคำขอและจัดเส้นทางไปยังเครื่องมือ เวิร์กโฟลว์ ตัวแทน หรือโมเดลที่เหมาะสม ความเชื่อมั่นสามารถกำหนดว่าการจัดเส้นทางเป็นอัตโนมัติหรือไม่
- Agent Tool Risk Checks: ประเมินการเรียกใช้เครื่องมือที่เสนอสำหรับการกระทำที่ทำลายล้าง ข้อมูลอ่อนไหว หรือความไม่สอดคล้องกับคำขอของผู้ใช้ก่อน execute โค้ดแอปยังคงรับผิดชอบการอนุญาต
- LLM Output Evaluation: ตรวจว่าเอาต์พุตของ LLM ได้รับการสนับสนุนโดยบริบทที่ให้ ปฏิบัติตามรูปแบบที่ต้องการ หรือจำเป็นต้องทบทวนโดยมนุษย์
- Content Moderation: ใช้ Choice สำหรับหมวดนโยบาย Score สำหรับความรุนแรง และ Noul สำหรับการตรวจกฎแบบไบนารี เคสความเชื่อมั่นต่ำสามารถส่งต่อให้ผู้ดูแล
- High-Volume Data Processing: ประมวลผลล็อก อีเมล รีวิว ลูกค้าเป้าหมาย โฆษณา หรือส่วนเอกสารเมื่อแต่ละเรคอร์ดประเมินได้อย่างอิสระและเอาต์พุตเป็นหมวด คะแนน หรือความน่าจะเป็น
Where Jev Fits in an AI Agent
ตัวแทน AI โดยทั่วไปผสมผสานโมเดลเชิงกำเนิด เครื่องมือ state ของแอปพลิเคชัน และกฎที่ควบคุมการทำงาน Jev เข้าสู่ระบบในฐานะชั้นการตัดสินใจแบบมีโครงสร้างรอบโมเดลเชิงกำเนิดหลัก
โมเดลเชิงกำเนิดจัดการงานปลายเปิด เช่น การตีความคำขอ วางแผนเวิร์กโฟลว์ เขียนเนื้อหา หรือสร้างโค้ด Jev จัดการการตัดสินใจแคบๆ ที่ต้องเกิดซ้ำระหว่างเวิร์กโฟลว์:
- ควรใช้เครื่องมือหรือโมเดลใด?
- การกระทำที่เสนอมีความเสี่ยงหรือไม่สอดคล้องกับคำขอหรือไม่?
- ตัวแทนควรดำเนินการต่อ ลองใหม่ หยุด หรือขอคำชี้แจงหรือไม่?
- ผลลัพธ์ตรงตามข้อกำหนดที่กำหนดหรือไม่?
- ควรยกระดับงานให้มนุษย์หรือไม่?
แอปพลิเคชันยังคงรับผิดชอบการอนุญาต ค่าธรณี และผลข้างเคียง Jev ให้คำตัดสินและความน่าจะเป็นที่เกี่ยวข้อง ในขณะที่โค้ดแอปกำหนดการกระทำที่จะตามมา
นี่สร้างการแบ่งความรับผิดชอบ โมเดลเชิงกำเนิดจัดการเหตุผลปลายเปิด Jev จัดการการประเมินแบบมีขอบเขต โค้ดเชิงกำหนดบังคับใช้นโยบาย และเครื่องมือทำการกระทำภายนอก ดังนั้น Jev จึงทำงานเป็นส่วนเติมเต็มของตัวแทน AI ไม่ใช่ตัวแทนของโมเดลเหตุผลหลัก
Limitations of Jev
Jev ไม่สร้างร้อยแก้ว โค้ด หรือคำอธิบายปลายเปิด มันถูกออกแบบสำหรับคำถามที่มุ่งเน้นพร้อมพื้นที่คำตอบที่กำหนด
คำตอบแบบ type-safe ยังอาจมีการตัดสินใจผิดได้ ดังนั้นความถูกต้องทางธุรกิจต้องได้รับการประเมินด้วยข้อมูลจริง ปัจจุบันรองรับอินพุตข้อความ และ English ให้ประสิทธิภาพที่มีเอกสารรองรับดีที่สุด ภาษาอื่นต้องทดสอบแยก
ความเร็วและค่าใช้จ่ายของ Jev มาจากการประเมินของ TypeSafe เองและไม่ควรถูกมองเป็นการรับประกันประสิทธิภาพสากล
Jev and CometAPI
ณ เวลาทบทวนเมื่อวันที่ 21 กันยายน 2026 Jev ไม่ได้อยู่ในแคตตาล็อกสาธารณะของ CometAPI ในฐานะโมเดลที่พร้อมใช้งานทั่วไป CometAPI มีแผนประเมินและผสาน Jev เมื่อสามารถเข้าถึงและเปิดการเชื่อมต่อที่ต้องการ นักพัฒนาควรตรวจ CometAPI model directory เพื่อความพร้อมใช้งานล่าสุด
ปัจจุบันเข้าถึง Jev ได้ผ่าน TypeSafe console และ API ทางการ TypeSafe ยังมี SDK ทางการสำหรับ Python และ JavaScript API ปัจจุบันใช้ state และ questions แบบมีชนิด โดย jev-latest ทำหน้าที่เป็นชื่อเล่นโมเดลเสถียร
เมื่อ Jev พร้อมใช้งานผ่าน CometAPI นักพัฒนาจะสามารถดู ID โมเดล เอ็นด์พอยต์ที่รองรับ ราคา และรูปแบบคำขอได้ใน CometAPI API documentation และไดเรกทอรีโมเดล
Frequently Asked Questions
What is Jev AI?
Jev เป็นโมเดลแฟลกชิปของ TypeSafe และเป็น System One model ตัวแรก มันประเมิน state ที่เป็นข้อความเทียบกับคำถามแบบมีชนิด และส่งคืนคำตัดสินที่มีโครงสร้างและความน่าจะเป็นแทนการสร้างข้อความ
Is Jev a large language model?
TypeSafe ไม่นำเสนอ Jev เป็น LLM แบบดั้งเดิม เรียก Jev ว่าเป็น System One model ที่สร้างเพื่อการตัดสินใจแบบมีโครงสร้าง บริษัทไม่ได้เผยแพร่จำนวนพารามิเตอร์ ดังนั้นไม่ควรจัดประเภทว่าใหญ่หรือเล็กจากข้อมูลสาธารณะ
What are Choice, Score, and Noul?
Choice เลือกตัวเลือกจากชุดที่กำหนดและส่งคืนความน่าจะเป็นพร้อมค่า confidence Score จัดระดับ state บน rubric แบบลำดับและส่งคืนความน่าจะเป็นพร้อมค่า confidence เช่นกัน Noul ส่งค่าจาก 0 ถึง 1 แทนความน่าจะเป็นว่าข้อความนั้นเป็นจริง
Does Jev generate text or code?
ไม่ Jev ส่งคืนคำตัดสินแบบจำกัด เมื่อเวิร์กโฟลว์ต้องการร้อยแก้ว บทสนทนา ซอร์สโค้ด หรือคำอธิบายปลายเปิด ต้องใช้โมเดลเชิงกำเนิด
Can Jev replace GPT, Claude, or Gemini?
ไม่ Jev จัดการงานการตัดสินใจแบบมีขอบเขต ขณะที่ LLM ทั่วไปจัดการการสร้างและเหตุผลขยาย ระบบโปรดักชันสามารถใช้ทั้งสองประเภทในขั้นตอนต่างๆ ของเวิร์กโฟลว์เดียวกัน
Does Jev support images, audio, or video?
ไม่โดยตรง โมเดลปัจจุบันรับข้อความเป็นสตริง ออบเจ็กต์ JSON หรืออาเรย์ของค่าข้อความ อินพุตที่ไม่ใช่ข้อความต้องแปลงเป็นข้อความหรือฟิลด์ที่มีโครงสร้างก่อน
Does type-safe output guarantee a correct decision?
ไม่ ความเป็น type-safe การันตีว่าเอาต์พุตสอดคล้องกับโครงสร้างที่รองรับ Jev ยังอาจเลือกตัวเลือกที่ถูกต้องตามสคีมาแต่ไม่ถูกต้องตามธุรกิจ หรือกำหนดความน่าจะเป็นไม่แม่นยำ ความถูกต้องทางธุรกิจต้องวัดกับข้อมูลแทนจริง
Is Jev open source?
TypeSafe ไม่ได้เปิดเผยน้ำหนักโมเดล Jev บริษัทเผยแพร่เอกสาร SDK ตัวอย่าง และโค้ดอินทิเกรชันที่เกี่ยวข้อง แต่ทรัพยากรเหล่านั้นไม่ได้ทำให้โมเดลเป็น open weight
Conclusion
Jev แนะนำอินเทอร์เฟซโมเดลที่สร้างบนการตัดสินใจแทนการสร้างภาษา มันรับ state ร่วมและคำถามแบบอะตอมมิกที่มีชนิด จากนั้นส่งคืนหมวด คะแนน ความน่าจะเป็นแบบไบนารี และมาตรวัดความไม่แน่นอนที่ซอฟต์แวร์ใช้ได้โดยตรง
บทบาทที่น่าเชื่อถือที่สุดไม่ใช่การแทนที่ LLM ทั่วไป แต่เป็นการจัดการคำตัดสินแคบๆ ที่เกิดขึ้นบ่อยรอบๆ LLM นั้น การจัดเส้นทางซัพพอร์ต ลูกค้า การเลือกโมเดล การตรวจความเสี่ยงของเครื่องมือ การตรวจเอาต์พุต การกลั่นกรอง และการจำแนกเวิร์กโฟลว์ ล้วนเข้ากันได้เมื่อพื้นที่คำตอบกำหนดไว้ล่วงหน้า
คุณค่าการใช้งานจริงขึ้นอยู่มากกว่าความหน่วงต่ำหรือสคีมาที่ถูกต้อง ทีมต้องมีการประเมินที่แทนจริง ค่าธรณีที่ปรับเทียบ กฎการอนุญาตที่ชัดเจน การควบคุมเวอร์ชันโมเดล และเส้นทางทบทวนโดยมนุษย์ ตัวเลขความเร็วและค่าใช้จ่ายที่เผยแพร่โดย TypeSafe ทำให้ Jev ควรค่าแก่การทดสอบสำหรับเวิร์กโหลดที่เน้นการตัดสินใจ แต่ข้ออ้างอิงยังผูกกับวิธีการประเมินของบริษัทและควรยืนยันบนข้อมูลแอปจริง
สำหรับทีมที่ใช้งานโมเดลเชิงกำเนิดหลายตัวผ่าน CometAPI อยู่แล้ว Jev แสดงสถาปัตยกรรมที่กว้างขึ้นซึ่งการสร้าง การตัดสินเชิงความน่าจะเป็น นโยบายเชิงกำหนด และการปฏิบัติการด้วยเครื่องมือเป็นองค์ประกอบแยกกัน การแยกนี้ทำให้แต่ละส่วนทดสอบได้ง่ายขึ้นและให้โค้ดแอปควบคุมขั้นสุดท้ายว่าอะไรเกิดขึ้นต่อไป