Laya อธิบาย: โมเดลการตัดสินใจที่ตอบได้โดยไม่ต้องเขียนแม้แต่โทเคนเดียว

สิ่งที่น่าสนใจที่สุดเกี่ยวกับ Laya ไม่ใช่ความเร็วของมัน แต่คือทุกตัวเลือกที่คุณเสนอให้มันจะถูกให้คะแนนที่ [MASK] โทเคนของตัวเอง จากนั้นความน่าจะเป็นจะถูกทำ softmax เหนือตัวเลือกของคำถามข้อนั้นเพียงข้อเดียว Convai Innovations เผยแพร่เวตของ Laya บน Hugging Face เมื่อวันที่ 18 กันยายน 2026 ภายใต้ Apache 2.0 — สามเช็กพอยต์ หนึ่งรีโพซิทอรี 421M พารามิเตอร์สำหรับโมเดลภาษาอังกฤษ ไม่มีโทเคนเอาต์พุต ไม่มีลูปถอดรหัส ไม่มี JSON ให้แยกวิเคราะห์ ไม่มีวงเล็บปีกกาให้ลืมปิด คุณป้อนสถานะและชุดคำถามที่ระบุชนิดไว้ให้มัน และหลังจากการส่งผ่านไปข้างหน้าหนึ่งครั้ง คุณจะได้การเลือกจากตัวเลือกที่มีชื่อ คะแนนแบบออร์ดินัลพร้อมระดับที่คาดหมาย หรือความน่าจะเป็นที่ข้อความหนึ่งเป็นจริง การออกแบบนี้มีผลที่คนมักมองข้าม เพราะพื้นที่คำตอบถูกประกอบขึ้นต่อคำขอ แทนที่จะถูกอบไว้ในหัวคำศัพท์ สคีมาที่คุณคิดขึ้นเองบ่ายนี้จึงไม่ต้องเทรนใหม่ มันยังมีข้อจำกัด และโครงการก็ระบุไว้ตรง ๆ บนการ์ดโมเดลของตัวเองว่า เช็กพอยต์ฐานได้ 0.362 บนเบนช์มาร์ก typed-decisions เทียบกับ 0.318 สำหรับการเดาสุ่ม และ 0.461 สำหรับการตอบคลาสส่วนใหญ่เสมอ ประโยคของ Convai เองคือประโยคที่ควรจดจำไว้ — "Laya เป็นฐานที่เร็วสำหรับการปรับให้เชี่ยวชาญ ไม่ใช่เอนจินตัดสินใจแบบ zero-shot" จุดเปรียบเทียบที่ชัดเจนคือ Jev ของ TypeSafe AI ซึ่งเป็นโมเดล System One ที่โฮสต์ให้บริการ โดยไม่มีการเผยแพร่เวต ไม่มีการเผยแพร่จำนวนพารามิเตอร์ และไม่มีการเผยแพร่โมเดลฐาน Laya คือคำตอบแบบเปิดเวตสำหรับสิ่งนั้น ว่าคำตอบนั้นจะมีประโยชน์กับคุณหรือไม่นั้น แทบจะขึ้นอยู่ทั้งหมดกับว่าคุณกำลังพยายามแทนที่ครึ่งใดของไปป์ไลน์

Laya แท้จริงคืออะไร และไม่ใช่อะไร

เริ่มจากด้านลบก่อน เพราะนี่คือจุดที่งานเขียนส่วนใหญ่มักเข้าใจผิด Laya ไม่ใช่ LLM มันเป็นแบบ non-autoregressive: การ forward pass เพียงครั้งเดียวก็สร้างคำตอบ และโมเดลไม่เคยส่งออกข้อความ การนำความหน่วงของมันไปเปรียบเทียบกับ tokens-per-second ของโมเดลแชต ก็คือการเปรียบเทียบการทำงานที่แตกต่างกันสองแบบ — อย่างหนึ่งจำแนกประเภท อีกอย่างหนึ่งสร้างข้อความ ถ้าคุณต้องการย่อหน้า สรุป แผน หรือลำดับการให้เหตุผล Laya ไม่สามารถให้สิ่งนั้นได้ และก็ไม่ได้พยายามจะทำด้วย

สิ่งที่มันคือ: เอนโคเดอร์แบบสองทิศทางที่มีหัวตัดสินใจติดตั้งไว้ด้านบน เช็กพอยต์ภาษาอังกฤษคือ ModernBERT-large — 395M พารามิเตอร์ ไฟน์ทูนเต็มรูปแบบ — บวกกับหัวที่เทรนจากศูนย์ซึ่งประกอบด้วยเลเยอร์ทรานส์ฟอร์เมอร์สองชั้น ตัวให้คะแนนเครื่องหมายตัวเลือก และหัว act/escalate รวมทั้งหมด 421M เช็กพอยต์แบบหลายภาษาจะสลับแกนหลักเป็น mmBERT-base 22 เลเยอร์ และคำศัพท์ 256k รวมทั้งหมด 322M มีเช็กพอยต์สามตัวจัดส่งอยู่ในรีพอซิทอรีเดียว และจะดาวน์โหลดเฉพาะตัวที่คุณร้องขอเท่านั้น:

• convaiinnovations/laya — ModernBERT-large, พารามิเตอร์ 421M, บริบท 512 โทเคน, ภาษาอังกฤษ, ประมาณ 808 MB บนดิสก์

• convaiinnovations/laya-multilingual — mmBERT-base, พารามิเตอร์ 322M, คอนเท็กซ์ 1,024 โทเคน (เอนโคเดอร์รองรับได้ถึง 8,192 โทเคนด้วย RoPE), มากกว่า 100 ภาษา, เร็วกว่าประมาณ 2.2 เท่า, ประมาณ 647 MB

• convaiinnovations/laya-typed-decisions — ModernBERT-large จำนวนพารามิเตอร์ 421M คอนเท็กซ์ 1,024 โทเคน และเป็นเพียงตัวเดียวในสามตัวที่มีตัวเลข 0.766 ซึ่งคุณจะเห็นถูกอ้างอิงกันทุกที่

Router ตั้งอยู่ด้านหน้าและเลือก checkpoint ต่อคำขอ โดยตรวจจับสคริปต์และภาษาได้ภายในเวลาไม่ถึงครึ่งมิลลิวินาที ด้วย Python ล้วน ก่อนที่ forward pass ใด ๆ จะเกิดขึ้น นั่นไม่ใช่ฟีเจอร์เพื่อความสะดวก แต่เป็นฟีเจอร์เพื่อความถูกต้อง และหลักฐานของตัวโครงการเองก็แสดงให้เห็นว่าทำไม: checkpoint ภาษาอังกฤษได้คะแนนความแม่นยำ 0.000 บนภาษาเขมร ขณะที่รายงานความมั่นใจที่ 0.952 โมเดลที่ยังคงมั่นใจทั้งที่ผิดอย่างสิ้นเชิงคือกรณีที่การกรองด้วยความมั่นใจช่วยคุณไม่ได้เลย ดังนั้นการตัดสินใจเรื่อง routing จึงต้องเกิดขึ้นก่อนที่โมเดลจะเห็นข้อมูลนำเข้า จากการกวาดทดสอบ 51 ภาษา Router ทำให้ 45 จาก 51 ภาษาสามารถใช้งานได้ — ซึ่งนิยามว่าต้องเอาชนะการสุ่มได้สามเท่า — เทียบกับ 23 จาก 51 สำหรับ checkpoint ภาษาอังกฤษเพียงอย่างเดียว

ข้อเท็จจริงด้านการออกแบบที่ควรทำความเข้าใจ: หนึ่งโทเค็น [MASK] ต่อหนึ่งตัวเลือก

ถ้าคุณจะหยิบอะไรไปเพียงอย่างเดียวจากบทความนี้ ให้หยิบสิ่งนี้ ในหัวจำแนกประเภทแบบทั่วไป ชุดป้ายกำกับถูกกำหนดตายตัวตั้งแต่ตอนฝึก โดยเลเยอร์สุดท้ายมีหนึ่งเอาต์พุตต่อหนึ่งคลาส และการเพิ่มคลาสหมายถึงต้องฝึกใหม่ Laya ไม่ทำแบบนั้น มันเรนเดอร์แต่ละตัวเลือกเป็นข้อความพร้อมเครื่องหมาย และตัวให้คะแนนเครื่องหมายของตัวเลือกอ่านคะแนนจากตำแหน่ง [MASK] ของตัวเลือกนั้นเอง จากนั้นจึงทำ softmax ข้ามตัวเลือกทั้งหมดที่เป็นของคำถามนั้น

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

มีงบประมาณสองส่วนที่กำหนดว่าการทำงานนั้นได้ผลดีเพียงใด และทั้งสองถูกใช้ร่วมกัน แต่ละซีเควนซ์จะแยกออกเป็นงบประมาณสำหรับ option-prompt (head_max_len ซึ่งใช้ 192 โทเคนบน checkpoint ภาษาอังกฤษ และ 256 บนอีกสองตัว) และงบประมาณสำหรับเอกสาร (ส่วนที่เหลือทั้งหมดของ max_len) ทุกคำถามในหนึ่งการเรียกจะได้รับคำตอบใน forward pass เดียวกันนั้น ดังนั้นการเรียกที่มีหกคำถามจึงไม่ใช่การเรียกโมเดลหกครั้ง แต่ตัวเลือกต่าง ๆ ใช้ร่วมงบประมาณ option เดียวกัน นี่คือเหตุผลที่คำถามที่มี 77 ตัวเลือกอย่าง Banking77 จัดสรรงบประมาณราวสามถึงสี่โทเคนต่อป้ายกำกับ และความแม่นยำก็ตกลงอย่างรวดเร็ว — 0.425 เทียบกับ 0.870 ที่ Jev เผยแพร่ไว้ วิธีแก้ไขมีการบันทึกไว้อย่างชัดเจนแทนที่จะซ่อนไว้: เพิ่ม head_max_len และ max_len หรือแบ่งชุดตัวเลือกขนาดใหญ่ออกเป็นตัวเลือกแบบหยาบไปละเอียดสองขั้น

สามสิ่งพื้นฐาน

ทุกสิ่งที่ Laya ทำคือหนึ่งในสามประเภทคำถาม และแต่ละประเภทจะส่งคืนรูปทรงที่แตกต่างกัน:

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

• คะแนน — การแจกแจงบนมาตรวัดแบบเรียงลำดับ บวกกับระดับที่คาดหวัง นี่คือ primitive ประเภทลำดับ (ordinal): ความเร่งด่วน ความหงุดหงิด ความรุนแรง

• noul — ความน่าจะเป็นที่ปรับเทียบแล้วว่าข้อความหนึ่งเป็นจริง ตั้งแต่ 0.0 ถึง 1.0 ฟิชชิง ความเสี่ยงลูกค้าลาออก การฉีดพรอมป์ต์

ชนิดข้อมูลมีความเข้มงวดในแบบที่ส่งผลต่อการปฏิบัติงานจริง คำถามแบบเลือกตอบไม่สามารถคืนตัวเลือกที่คุณไม่ได้จัดเตรียมไว้ได้ เพราะตัวเลือกเดียวที่มันให้คะแนนได้คือตัวเลือกที่คุณเรนเดอร์ออกมาเท่านั้น สิ่งนี้กำจัดความล้มเหลวในการผลิตไปได้ทั้งประเภท — ค่า enum ที่ถูกกุขึ้นมา, JSON ที่ถูกตัดทอน, ลูป retry ที่วนรอบตัวแยกวิเคราะห์ แต่มันไม่ได้กำจัดความผิดพลาดเชิงความหมาย โมเดลที่คืนค่า billing: 0.94 สำหรับตั๋วที่ควรถูกส่งไปยังฝ่ายสนับสนุนด้านเทคนิคนั้นผิด และมันผิดอย่างมั่นใจ ผลลัพธ์แบบมีชนิดรับประกันรูปร่างของคำตอบ ไม่เคยรับประกันความถูกต้องของมัน

RLCD หรือเหตุใดความน่าจะเป็นจึงควรจะมีความหมาย

ตัวจำแนกส่วนใหญ่ถูกฝึกให้ตอบถูก Laya ถูกฝึกให้ซื่อสัตย์ว่าตัวเองถูกต้องแค่ไหน และสูตรการฝึกคือที่มาของสิ่งนั้น

วิธีการนี้เรียกว่า RLCD — Reinforcement Learning for Calibrated Decisions นโยบายจะส่งออกเป็นการแจกแจงแทนที่จะเป็น argmax; การสำรวจจะเพิ่มสัญญาณรบกวนเกาส์เซียนที่มีค่าเฉลี่ยศูนย์ลงใน logits; และรางวัลเป็นกฎการให้คะแนนแบบ strictly proper — log บวก spherical โดยเพิ่ม ranked probability score สำหรับคำถามแบบอันดับ คำว่า "proper" นั่นแหละที่ทำหน้าที่สำคัญ กฎการให้คะแนนแบบ strictly proper จะถูกทำให้สูงสุดในค่าคาดหมายได้ก็ต่อเมื่อรายงานความเชื่อที่แท้จริงของคุณเท่านั้น ดังนั้นการเลี่ยงความชัดเจนหรือการกล่าวอ้างเกินจริงจึงเสียรางวัลโดยโครงสร้างการออกแบบ ไม่ใช่เพราะมีคำสั่งบอก การอัปเดตใช้ REINFORCE กับ baseline แบบค่าเฉลี่ยกลุ่ม ในสไตล์ GRPO และบทสนทนาหลายรอบใช้ TD(λ=1.0) บนสไลซ์คำนำหน้า

ผลลัพธ์ในทางปฏิบัติก็คือ เกณฑ์ความเชื่อมั่นเป็นสิ่งที่สมเหตุสมผลที่จะสร้างตรรกะของแอปพลิเคชันบนนั้นได้ — ซึ่งเป็นข้อกล่าวอ้างที่คุณไม่อาจใช้กับ softmax จากตัวจำแนกที่ฝึกด้วย cross-entropy ได้ และยังเป็นข้อกล่าวอ้างที่มีข้อควรระวังซึ่งโครงการระบุไว้ตรง ๆ ว่า เช็กพอยต์ที่เผยแพร่นั้นมั่นใจเกินจริง และคุณควรปรับเทียบอุณหภูมิ (temperature) ใหม่บนข้อมูลของคุณเองก่อนจะเชื่อถือตัวเลขเหล่านั้น การปรับเทียบอุณหภูมิหนึ่งค่าต่อประเภทคำถามและจำนวนตัวเลือก ทำให้ค่า ECE เฉลี่ยเปลี่ยนจาก 0.466 เป็น 0.081 บนเช็กพอยต์ภาษาอังกฤษ และจาก 0.314 เป็น 0.106 บนเช็กพอยต์หลายภาษา เกณฑ์เริ่มต้นที่โครงการแนะนำสำหรับการอนุมัติอัตโนมัติเทียบกับการตรวจทานโดยมนุษย์อยู่ที่ประมาณ 0.85

ค่าใช้จ่ายในการใช้งาน

ตัวเลขความหน่วงเป็นของโปรเจกต์เอง วัดบน Tesla T4 โดยทุก checkpoint ตอบคำถามที่เหมือนกันทุกไบต์ในการรันครั้งเดียวกัน:

• หนึ่งคำถาม — 39.5 ms บน laya, 32.8 ms บน laya-multilingual.

• ห้าคำถาม — 84.5 ms และ 40.1 ms

• สิบคำถามแบบเป็นชุด — 158.6 มิลลิวินาที (15.9 มิลลิวินาทีต่อคำถาม) และ 72.3 มิลลิวินาที (7.2 มิลลิวินาทีต่อคำถาม)

• ห้าสิบคำถาม — 771 ms และ 337 ms หรือ 6.8 ms ต่อคำถามบนเช็กพอยต์แบบหลายภาษา

• ปริมาณงานแบบแบตช์บน T4 ตัวเดียว — 103 ถึง 332 คำถามต่อวินาที

หากคุณเคยเห็นคำกล่าวอ้าง “เร็วกว่า Jev 50 เท่า” ที่แพร่กระจายอยู่ นั่นไม่ใช่ตัวเลขของโปรเจกต์ และเบนช์มาร์กของโปรเจกต์เองก็ไม่ได้สนับสนุนคำกล่าวอ้างนั้น การเปรียบเทียบที่ Convai เผยแพร่คือ 7.8 เท่าในด้านความหน่วง p50 สำหรับคำถามหนึ่งข้อ: 32.8 มิลลิวินาที เทียบกับ 236–276 มิลลิวินาที การเปรียบเทียบนั้นก็เป็นสิ่งที่ต้องอ่านอย่างระมัดระวังเช่นกัน เพราะการ์ดของ Laya ระบุฝั่ง Jev ว่าเป็นตัวเลขที่เผยแพร่โดยบุคคลที่สามซึ่ง Convai ไม่เคยวัด — เนื่องจากไม่มีการเข้าถึง TypeSafe API — และเพราะมันนำการทำ forward pass บน GPU ภายในเครื่องมาเทียบกับการเรียก API ที่โฮสต์ไว้ ซึ่งรวมเวลาไปกลับผ่านเครือข่ายและการเข้าคิว ส่วนที่เป็นสถาปัตยกรรมของช่องว่างนั้นเป็นของจริง ส่วนที่เป็นโครงสร้างพื้นฐานไม่ใช่คุณสมบัติของโมเดล

ในเรื่องหน่วยความจำ footprint อยู่ที่ไม่กี่ร้อยเมกะไบต์ต่อ checkpoint และตารางการดีพลอยเป็นสิ่งที่ควรรู้ก่อนกำหนดขนาดโฮสต์ ค่าเริ่มต้นแบบ lazy เก็บ checkpoint ไว้ในหน่วยความจำสองตัว (อังกฤษและหลายภาษา ซึ่งเป็นสองตัวเดียวที่ router เลือกสลับให้อัตโนมัติ) ดังนั้นหลังจากการโหลดครั้งแรกของแต่ละภาษา การสลับจะเสียเวลาแค่การตรวจจับเท่านั้น Router(max_loaded=1) บนเครื่องที่มีหน่วยความจำจำกัดจะโหลดใหม่ทุกครั้งที่สลับภาษา วัดค่ามัธยฐานได้ 7.4 วินาทีบน CPU และ 10.3 วินาทีบน T4 Router(preload=True) คือการตั้งค่าสำหรับเซิร์ฟเวอร์: ไม่มีการโหลดใหม่ และ latency ต่อคำขอคือ 32.8 ms บน GPU หรือ 193–464 ms บน CPU

ครึ่งที่ซื่อสัตย์

นี่คือจุดที่ชิ้นงานนี้พิสูจน์คุณค่าของตัวเอง เพราะพื้นผิวรอบ ๆ Laya นั้นจัดจ้าน และข้อจำกัดก็เจาะจงชัดเจน

ก่อนอื่น ตัวเลขพาดหัวข่าวเป็นตัวเลขที่ผ่านการปรับแต่งมาแล้ว ความแม่นยำ 0.766 นั้นเป็นของ laya-typed-decisions ซึ่งเป็นเช็กพอยต์ที่ไฟน์จูนบนชุดฝึกของเบนช์มาร์กนั้นเอง ส่วนเช็กพอยต์ฐานได้คะแนน 0.362 และ 0.342 ในโหมด zero-shot เมื่อเทียบกับเส้นฐานแบบสุ่มที่ 0.318 และเส้นฐานของคลาสส่วนใหญ่ที่ 0.461 — พูดอีกอย่างคือต่ำกว่าเส้นฐานพื้นฐานด้วยซ้ำ โครงการระบุเรื่องนี้ไว้ในรายการข้อจำกัดของตัวเองแทนที่จะปกปิดไว้ และเช็กพอยต์ที่ไฟน์จูนแล้วนั้นผ่านเพดานความสอดคล้องกันเองของครูที่ 0.735 ซึ่งถือเป็นผลลัพธ์ที่แข็งแกร่งจริง ๆ สำหรับเอนโคเดอร์ขนาด 421M บนเวิร์กโฟลว์เฉพาะทางแคบ ๆ สี่แบบ (การประมวลผลใบแจ้งหนี้ 0.804, เหตุการณ์ด้านความปลอดภัย 0.766, บริการลูกค้า 0.764, การสังเกตการณ์แบบ agent-trace 0.730) แต่มันเป็นผลลัพธ์เกี่ยวกับการเฉพาะทาง ไม่ใช่เกี่ยวกับโมเดลฐาน และใครก็ตามที่ยก 0.766 มาอ้างว่าเป็นความสามารถทั่วไปกำลังอ่านการ์ดผิด

ประการที่สอง องค์ประกอบพื้นฐานเหล่านี้ไม่ได้ดีเท่ากันทั้งหมด เมื่อดูความแม่นยำบนเช็กพอยต์ที่ปรับละเอียดแล้ว: noul 0.857, choice 0.733, score 0.723 ตัวโครงการเรียก score แบบออร์ดินัลว่า "องค์ประกอบพื้นฐานที่อ่อนที่สุด" อย่างตรงไปตรงมา โดยมี SST-5 อยู่ที่ 0.372 หากพื้นผิวการตัดสินใจของคุณคือการให้คะแนนความรุนแรง 1 ถึง 5 นั่นคือองค์ประกอบพื้นฐานที่คุณมีเหตุผลน้อยที่สุดที่จะเชื่อถือตั้งแต่เริ่มต้น

ประการที่สาม มีการบันทึกพฤติกรรมสองอย่างไว้เป็นบั๊กในระบบติดตามปัญหาของตัวโปรเจกต์เอง และทั้งสองอย่างจะทำคุณเจ็บตัวในโปรดักชันถ้าคุณไม่อ่านมัน action.act_probability ยังไม่มีสัญญาณที่ใช้งานได้ — ปัญหาหมายเลข #185 — เพราะเอาต์พุตของ decision head ไม่ได้ถูกปรับให้เป็นบรรทัดฐาน (unnormalised) โดยมีขนาดราว 300 เท่าของสเกลของ encoder ซึ่งทำให้ act head อิ่มตัวจนอ่านค่าได้ 1.0 สำหรับอินพุตเกือบทุกตัว logits ดิบของมันสวนทางกับความถูกต้อง โดยมี AUROC อยู่ที่ 0.30 จาก 396 การตัดสินใจที่มีป้ายกำกับ ให้ใช้ confidence แทนเป็นเกณฑ์ ซึ่งทำ AUROC ได้ 0.77 บนรายการเดียวกัน ส่วนอีกเรื่องหนึ่ง noul สามารถทำตามป้ายตัวเลือกของตัวเองแทนที่จะตาม state — ปัญหาหมายเลข #156 — เพราะ render_options ฮาร์ดโค้ดป้ายของ noul ให้เป็น false: / true: และคู่ป้ายนั้นสามารถครอบงำคำตอบได้ ทำให้ได้คำตอบ "no" อย่างมั่นใจสำหรับอินพุตที่เป็นบวกชัดเจน วิธีเลี่ยงที่ระบุไว้คือการถามคำถามเดียวกันในรูปแบบ choice สองตัวเลือก ที่ใช้คีย์กลาง ๆ และใช้คำว่า yes/no ของคุณเป็นคำอธิบาย

ประการที่สี่ รายละเอียดด้านการคาลิเบรตที่มองข้ามได้ง่ายและควรกล่าวถึงอย่างแม่นยำ เช็กพอยต์มาพร้อมค่าอุณหภูมิที่ฟิตไว้ที่ 0.1006 สำหรับบัคเก็ต choice:11+ และตัวโหลดจะหนีบอุณหภูมิทุกค่าให้อยู่ในช่วง [0.5, 5.0] การหนีบนั้นกำลังช่วยคุณอยู่ อุณหภูมิที่คมขนาดนั้นอาจรับการแจกแจงที่แตกออกจริง ๆ แล้วรายงานว่าเกือบแน่นอน ส่วนการหนีบหมายความว่ากรณีเลวร้ายที่สุดคือคำตอบที่นุ่มนวลกว่าที่การฟิตตั้งใจไว้ และตัวโหลดจะส่งคำเตือนที่ระบุชื่อบัคเก็ตที่ได้รับผลกระทบ พร้อมบอกให้คุณถือว่าความมั่นใจนั้นยังไม่ได้คาลิเบรต จงอ่านคำเตือนตอนโหลดแทนที่จะปิดกั้นมัน

ประการที่ห้า การใช้ภาษาอังกฤษเท่านั้นที่รากของ repo และโหมดความล้มเหลวเมื่อพ้นจากภาษาอังกฤษก็ไม่ได้ราบรื่นนัก — จึงต้องมีเราเตอร์ และจึงเป็นเหตุผลที่แนะนำให้ใช้laya-multilingual สำหรับสิ่งใดก็ตามที่ไม่ใช่ร้อยแก้วภาษาอังกฤษ

ภาพจากแหล่งอิสระ ในกรณีที่มีอยู่จริงนั้น แคบกว่าภาพจากผู้ขาย และไม่ได้ขัดแย้งกับภาพนั้น การเปรียบเทียบแบบตรงต่อตัวที่เป็นอิสระ — sysone-bench มี 751 สถานะจากเก้าชุดทดสอบ ลงวันที่ 2026-09-21 รันบนอินพุตที่เหมือนกันทุกไบต์ โดยตรวจสอบแฮชของคำถามว่าเหมือนกันก่อนเปรียบเทียบ — พบว่า Jev นำในด้าน triage, guardrails, moderation, banking77 และ multilingual intent ส่วน Laya นำใน AG News (0.940 ต่อ 0.910) และ MNLI (0.983 ต่อ 0.867) ผลลัพธ์ด้าน confidence gating คือสิ่งที่ผมจะเอาไปวางแผนจริง ๆ: การตั้งเกตที่ความมั่นใจ 0.85 เก็บทราฟฟิกของ Laya ไว้ได้ 58% ด้วยความแม่นยำ 0.878 เทียบกับ 78% ของ Jev ที่ 0.917 นั่นคือรูปทรงของการแลกเปลี่ยนนี้ — Laya ทำงานอัตโนมัติกับทราฟฟิกได้น้อยกว่า ด้วยความแม่นยำที่ต่ำกว่าในส่วนที่เก็บไว้ และการรันเราเตอร์ของตัวเองก็ยกระดับ multilingual intent จาก 0.360 ขึ้นเป็น 0.840

พื้นผิวรอบ ๆ มัน ซึ่งกว้างผิดปกติ

สำหรับโปรเจกต์ที่เวตมีอายุแค่ไม่กี่วัน สิ่งที่น่าประหลาดใจกลับอยู่ที่พื้นผิวการเชื่อมต่อ ทั้งหมดนี้อยู่ในรีโพซิทอรีต้นทางที่ NandhaKishorM/laya ซึ่งมียอดดาว 19,871 ดวงบน GitHub ณ เวลาที่เขียนเรื่องนี้ และใช้สัญญาอนุญาต Apache 2.0 ตลอดทั้งโปรเจกต์:

• laya-serve — เซิร์ฟเวอร์ HTTP ที่เปิดให้เข้าถึง Router บนPOST /v1/systemone ที่มีรูปแบบคำขอและคำตอบแบบเดียวกับ Jev API ที่โฮสต์โดย TypeSafe ดังนั้นไคลเอนต์ TypeSafe ที่มีอยู่จึงย้ายได้โดยเปลี่ยน base URL โปรดทราบค่าเริ่มต้นด้านความปลอดภัยอย่างตรงไปตรงมา: มันผูกกับ0.0.0.0 โดยไม่มีการยืนยันตัวตน เว้นแต่LAYA_API_KEY ถูกตั้งค่า ซึ่งในกรณีนั้นจะต้องใช้ bearer token มีโมดูล NixOS แบบเสริมความปลอดภัยที่ทำงานภายใต้ยูนิต systemd แบบ DynamicUser และส่งโทเคนผ่านLoadCredential แทนการใส่ไว้ใน store

• พอร์ต TypeScript แบบเต็มใน laya-ts/ สำหรับ Node และเบราว์เซอร์ พร้อมเส้นทางเอเจนต์ ONNX (laya.onnx_agent.ONNXAgent) สำหรับรันโมเดลที่ส่งออกบน ONNX Runtime โดยไม่ต้องใช้ PyTorch ขณะรันไทม์

• เซิร์ฟเวอร์ MCP ที่อยู่ภายใต้ส่วนเสริมแบบไม่บังคับ โดยเปิดเผย laya_predict, laya_route, laya_preset และ laya_status เป็นเครื่องมือ

• การผสานรวม LangChain และ LangGraph — LayaRouter สำหรับการกำหนดเส้นทางแบบมีเงื่อนไขด้วยเกณฑ์ความเชื่อมั่นและกลไก fallback และ LayaGuardrail

• Nix flake ที่มี nix run .#laya-serve และ โมดูล services.laya-serve, ไฟล์ compose สี่ไฟล์, เส้นทาง Docker image พร้อมคู่มือเริ่มต้นอย่างรวดเร็วที่มีเอกสารประกอบ, และโน้ตบุ๊ก Kaggle ที่รันลูป fine-tuning RLCD แบบเต็มบน GPU 2xT4 ฟรีภายในสี่ถึงห้าชั่วโมงจากคำถามประมาณ 30k ข้อ

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

จุดที่สิ่งนี้ลงตัวจริง ๆ คือ: decision head อยู่ด้านหน้า และ routed LLM อยู่ด้านหลัง

รูปแบบที่ควรค่าแก่การซึมซับไว้ไม่ใช่ “โมเดลการตัดสินใจแทน LLM” แต่เป็นไปป์ไลน์สองขั้นตอน และทั้งสองขั้นตอนต่างมีอยู่เพราะอีกขั้นตอนหนึ่งทำบางสิ่งได้ไม่ดี

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

นั่นคือจุดที่ OrcaRouter ตั้งอยู่ และก็คุ้มค่าที่จะพูดให้ชัดเจนถึงขอบเขตตรงนี้ เราไม่ได้ให้บริการ Laya — มันคือเอนโคดเดอร์ขนาด 421M ที่คุณรันเอง และจุดสำคัญทั้งหมดของมันก็คือมันทำงานอยู่ในที่ที่ข้อมูลของคุณอยู่แล้ว เราไม่ได้ให้บริการ Jev เช่นกัน — มันคือเอนด์พอยต์ช่วง Early Access ของ TypeSafe สิ่งที่เราครอบคลุมคือครึ่งหนึ่งที่เป็นฝั่งสร้างสรรค์ของไปป์ไลน์เดียวกันนั้น: โมเดลกว่า 200+ ตัวภายใต้คีย์เดียวที่เข้ากันได้กับ OpenAI ที่ ราคาตามรายการของผู้ให้บริการซึ่งส่งผ่านโดยไม่บวกกำไร 0% พร้อมการสลับไปใช้ผู้ให้บริการรายอื่นอัตโนมัติเมื่อเกิดปัญหา เหตุผลในทางปฏิบัติที่สำคัญตรงนี้คือรอยต่อระหว่างสองครึ่งนั้น ทันทีที่คุณเริ่มส่งต่อการตัดสินใจไปยังโมเดลแบบสร้างสรรค์สำหรับกรณีที่ส่วนหัวตัดสินใจปฏิเสธไป คุณก็จะมีงานเชื่อมต่อระบบชุดที่สอง ใบเรียกเก็บเงินชุดที่สอง และรูปแบบความล้มเหลวชุดที่สอง คีย์เดียวสำหรับฝั่งการสร้าง พร้อมการสลับสำรองหากผู้ให้บริการรายใดมีประสิทธิภาพลดลง หมายความว่าเส้นทางการยกระดับของเลเยอร์ตัดสินใจกลายเป็นเพียงการเปลี่ยนการตั้งค่า ไม่ใช่การสร้างความสัมพันธ์กับผู้ขายรายที่สอง นั่นเป็นข้ออ้างเล็ก ๆ และมันเป็นข้ออ้างที่เป็นจริง

ใครควรนำไปใช้ และใครควรรอ

เริ่มใช้ Laya ตอนนี้เลยถ้าคุณมีข้อมูลที่ติดป้ายกำกับและลูปการฝึก และมีพื้นผิวการตัดสินใจที่เสถียรพอที่จะคุ้มค่าต่อการทำให้เชี่ยวชาญเฉพาะทาง สมุดบันทึก Kaggle มีขึ้นเพื่อให้ขั้นตอนการปรับละเอียดไม่ใช่โครงการวิจัย เช็กพอยต์ฐานโหลดได้ในประมาณสองวินาทีบน CPU และสัญญาอนุญาตให้คุณจัดส่งผลลัพธ์ในเชิงพาณิชย์ได้โดยไม่ต้องเผยแพร่เวตของคุณ งานที่เหมาะที่สุดคือสิ่งที่โครงการได้วัดประสิทธิภาพไว้แล้ว: การคัดแยกตั๋ว, การประมวลผลใบแจ้งหนี้, การจำแนกเหตุการณ์ด้านความปลอดภัย, การ์ดเรลและการกลั่นกรอง และการสังเกตการณ์ร่องรอยของเอเจนต์ เก็บคำถามแบบเลือกให้ต่ำกว่าประมาณ 20 ตัวเลือก ปรับเทียบอุณหภูมิบนข้อมูลที่กันไว้ของคุณเองก่อนที่คุณจะตั้งค่าเกณฑ์ในโปรดักชัน และให้ตัดสินด้วย confidence ไม่ใช่ act_probability.

รอก่อน หากการตัดสินใจของคุณต้องพร้อมใช้ทันทีโดยไม่มีข้อมูลที่มีป้ายกำกับ base checkpoint ที่ได้คะแนนต่ำกว่า baseline ของคลาสส่วนใหญ่บน benchmark ที่มันถูกเผยแพร่โดยเทียบด้วย ไม่ใช่ zero-shot engine และการอ่านตัวเลขจากผู้ขายเทียบกับตัวเลขจากหน่วยทดสอบอิสระอย่างตรงไปตรงมาคือ hosted decision API ที่ดูแลมาอย่างดีในปัจจุบันเป็นตัวเลือก zero-shot ที่แข็งแกร่งกว่า ควรรอเช่นกันหากชุดตัวเลือกของคุณมีขนาดใหญ่และคุณไม่ยินดีปรับจูน head budget หากการให้คะแนนแบบ ordinal ของคุณต้องเชื่อถือได้ทันที หรือหากคุณต้องการอินพุตรูปภาพ เสียง หรือเอกสารยาว — Laya รองรับเฉพาะข้อความ และงบ context ของมันอยู่ที่ 512 ถึง 1,024 โทเคนโดยค่าเริ่มต้น ซึ่งเป็นการเลือกหลักฐานบางส่วนมากกว่าเอกสารทั้งฉบับ

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