อธิบาย RLCD: ทำไม TypeSafe จึงฝึก Jev ให้ซื่อสัตย์เกี่ยวกับความมั่นใจ แทนที่จะเป็นที่ชื่นชอบ

Jev 1.13 (typesafe/jev-1.13) ได้รับการฝึกด้วยวิธีการที่ผู้สร้างเรียกว่า Reinforcement Learning for Calibrated Decisions — RLCD — และตัวย่อนั้นเป็นคำที่ TypeSafe บัญญัติขึ้นเอง ไม่ใช่ศัพท์ในอุตสาหกรรมที่คุณควรรู้อยู่แล้ว โพสต์เปิดตัวระบุไว้ตรง ๆ อย่างนั้น: บริษัทสร้าง "สถาปัตยกรรมโมเดลแบบใหม่, ตัวสุ่มตัวอย่างแบบขนานเพื่อประสิทธิภาพสูงสุด, และวิธีการฝึกที่เราเรียกว่า Reinforcement Learning for Calibrated Decisions (RLCD)" มันเป็นคำตอบที่สามสำหรับคำถามที่เคยมีสองคำตอบ และเหตุผลที่มันมีอยู่คือความไม่ลงรอยที่ทีมส่วนใหญ่เจอเมื่อแรกที่พยายามนำโมเดลภาษาไปไว้ในกระบวนการตัดสินใจ ก่อนจะไปถึงตรงนั้น มีสองวันที่สำคัญ เพราะหน้านี้ไม่ใช่บทความเปิดตัว TypeSafe ปล่อยโมเดลนี้เมื่อ 2026-09-15 ซึ่งอยู่นอกหน้าต่างเจ็ดวันที่บล็อกนี้เขียนถึง และไม่มีอะไรในนี้ควรถูกอ่านว่าเป็นการวางกรอบให้ Jev เป็นของใหม่ เหตุการณ์ที่ระบุวันที่คือ 2026-09-24 เมื่อ OrcaRouter เพิ่ม typesafe/jev-1.13 เข้าแค็ตตาล็อกของตัวเองและเปิดการ์ดโมเดลสำหรับมัน — เป็นครั้งแรกที่ Jev สามารถถูกเรียกใช้ผ่านเกตเวย์ของบุคคลที่สามได้ ไม่ใช่ผ่านเฉพาะจุดเชื่อมต่อของ TypeSafe เท่านั้น นั่นคือการเปลี่ยนแปลงที่หน้านี้อิงอยู่ และผลในทางปฏิบัติคือเทคนิคด้านล่างนี้ตอนนี้เป็นสิ่งที่คุณลองในโค้ดได้ด้วยคีย์ที่คุณอาจมีอยู่แล้ว แทนที่จะเป็นไอเดียวิจัยที่คุณอ่านเจอ

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

RLHF ปรับให้เหมาะสมกับคำตอบที่บุคคลหนึ่งชื่นชอบ

การเรียนรู้แบบเสริมกำลังจากข้อเสนอแนะของมนุษย์เป็นวิธีการที่เปลี่ยนโมเดลภาษาที่ผ่านการฝึกมาก่อนให้กลายเป็นผู้ช่วย เอกสารแนะนำของ TypeSafe เองกล่าวถึงวัตถุประสงค์อย่างตรงไปตรงมา ในการ์ดที่หัวข้อว่า RLHF: มัน "เปลี่ยนโมเดลที่ผ่านการฝึกมาก่อนให้กลายเป็นแชตบอต มันฝึกโมเดลให้สร้างคำตอบที่ผู้คนชื่นชอบ" InstructGPT และ ChatGPT ถูกฝึกด้วยวิธีนี้ และเอกสารแนะนำได้เพิ่มรายละเอียดที่เกี่ยวข้องในที่นี้ด้วยเหตุผลที่ต่างออกไป — แนวทางนี้ถูกคิดค้นร่วมโดย Diogo Almeida ซึ่งเป็นผู้ร่วมก่อตั้ง TypeSafe และเป็นผู้เขียนโพสต์เปิดตัวของ Jev บริษัทไม่ได้กำลังปฏิเสธวิธีการนี้ เนื่องจากบริษัทถูกก่อตั้งโดยผู้ที่มีส่วนช่วยสร้างมันขึ้นมา บริษัทกำลังโต้แย้งว่าวัตถุประสงค์นั้นผิดสำหรับงานเฉพาะอย่าง

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

โหมดความล้มเหลวที่ TypeSafe ระบุไว้ในไพรเมอร์นั้นเป็นผลสืบเนื่องโดยตรงจากสิ่งนั้น:

• การประจบสอพลอ — โมเดลเรียนรู้ที่จะสร้างสิ่งที่ผู้ให้คะแนนอยากได้ยิน ซึ่งเป็นเป้าหมายที่แตกต่างจากสิ่งที่เป็นความจริง

• อาการหลอนที่ฟังดูมั่นใจ — ความลื่นไหลและความแน่ใจได้รับผลตอบแทนจากความชอบ แม้จะไม่มีอะไรมาสนับสนุนก็ตาม

• Mode dropping — การปรับให้เหมาะสมตามความชอบทำให้การกระจายของเอาต์พุตแคบลง "โดยสนับสนุนสไตล์ใดสไตล์หนึ่ง เช่น การปฏิบัติตามคำสั่ง ขณะเดียวกันก็ลดความน่าจะเป็นของเอาต์พุตแบบอื่นที่เป็นไปได้" Mode dropping เป็นเวอร์ชันที่ไม่รุนแรงของความล้มเหลวแบบ mode collapse สุดคลาสสิกซึ่งสร้างปัญหาให้กับเครือข่ายปฏิปักษ์เชิงกำเนิด (generative adversarial networks) โดยที่ตัวสร้าง (generator) ลู่เข้าสู่เอาต์พุตเพียงแบบเดียวที่ยังหลอกตัวจำแนก (discriminator) อยู่ได้ต่อไป

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

RLVR มุ่งปรับให้เหมาะกับผลลัพธ์ที่โปรแกรมตรวจสอบได้ — และการตัดสินใจแทบไม่มีผลลัพธ์แบบนั้น

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

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

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

สิ่งที่ RLCD ทำ ในคำอธิบายของ TypeSafe เอง

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

โพสต์เปิดตัววางสามวิธีการไว้เคียงข้างกัน และความตัดกันนั้นคือการสื่อถึงแนวคิดที่ชัดเจนที่สุดเท่าที่มีอยู่ อ่านมันเป็นชุดของความตัดกัน มากกว่าเป็นตาราง:

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

• สิ่งที่ป้อนเข้า — สองตัวที่เก่ากว่าจะรับข้อมูลที่ไม่มีโครงสร้าง "โดยเน้นที่ข้อความแบบลำดับ"; โมเดลการตัดสินใจที่ปรับเทียบแล้วจะรับข้อมูลที่ไม่มีโครงสร้าง "โดยเน้นที่สถานะโปรแกรมที่มีโครงสร้าง"

• สิ่งที่ได้ออกมา — สตริงที่ถูกสร้างขึ้นซึ่ง "ต้องถูกแยกวิเคราะห์ + ตรวจสอบความถูกต้อง" โดย "มีความเสี่ยงเสมอที่ AI จะหลุดออกนอกลู่ทาง" เทียบกับค่าที่มีโครงสร้างและปลอดภัยทางชนิดข้อมูล (type-safe) ซึ่ง "ผลลัพธ์และโครงสร้างที่เป็นไปได้ถูกกำหนดไว้ล่วงหน้า" โมเดล "ไม่เคยเกิดข้อผิดพลาดทางชนิดข้อมูล" และ "คำตอบทั้งหมดมาพร้อมกับความน่าจะเป็นที่ปรับเทียบแล้วและคะแนนความเชื่อมั่น"

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

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

• ตอบได้เร็วแค่ไหน — 3 ถึง 329 วินาทีตั้งแต่ต้นจนจบสำหรับโมเดลระดับแนวหน้า เมื่อเทียบกับ 70ms ถึง 500ms ซึ่งผู้ขายระบุว่าเร็วกว่า 40x ถึง 200x สำหรับคิวรีที่มีรูปแบบเหมือน System One

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

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

• ผลลัพธ์ที่กำหนดความน่าจะเป็น 0.2 ควรเกิดขึ้นประมาณ 20% ของจำนวนครั้ง

ผลลัพธ์ที่กำหนดความน่าจะเป็นไว้ที่ 0.8 ควรเกิดขึ้นประมาณ 80% ของจำนวนครั้ง

• ผลลัพธ์ที่กำหนดความน่าจะเป็นที่ 1.0 ควรเกิดขึ้น 100% ของเวลา

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

การเปรียบเทียบแบบสามการ์ดชุดเดียวกันนี้ปรากฏอยู่บนเอกสารของ TypeSafe เอง ซึ่งเป็นแหล่งที่มาของการเปรียบเทียบข้างต้น และเป็นจุดที่ชัดเจนที่สุดในการตรวจสอบถ้อยคำ แทนที่จะเชื่อตามคำของบทสรุป ภาพด้านล่างคือหน้านั้นในสภาพที่เป็นอยู่ในปัจจุบัน: การ์ดสามใบสำหรับแนวทางหลังการฝึกทั้งสามแนวทาง โดยใบที่สามระบุชื่อ RLCD แบบเต็ม

รายละเอียดเพิ่มเติมอีกสองประการในเอกสารของผู้ขายแสดงให้เห็นว่าวิธีนี้หยั่งลึกเข้าไปในผลิตภัณฑ์มากเพียงใด ประการแรกคือ ความเชื่อมั่น (confidence) ถูกอนุมานขึ้นมา มากกว่าจะถูกสร้างขึ้นเอง: โมเดลจะคืนค่าการแจกแจงความน่าจะเป็นแบบเต็มรูปแบบครอบคลุมตัวเลือกหรือระดับที่คุณป้อนให้ และค่าความเชื่อมั่นคือค่าสถิติที่คำนวณจากรูปร่างของการแจกแจงนั้น นั่นคือเหตุผลที่เอกสารสามารถบอกคุณได้ว่านิยามนั้นไม่ได้เป็นส่วนที่ต้องพึ่งพา — คุณจะได้การแจกแจงดิบไม่ว่าจะทางใด และสามารถคำนวณค่าสถิติของคุณเองได้หากค่าของคุณเข้ากันได้ดีกว่า ประการที่สองคือ RLCD เป็นสิ่งเดียวที่กำหนดรูปร่างของเวต (weights) หน้าโมเดลของ TypeSafe ระบุว่า: "Jev ไม่ได้รับการปรับละเอียด (fine-tuned) หรือปรับด้วย LoRA โดยใช้ข้อมูลลูกค้า มันถูกฝึกด้วย RLCD เพื่อคืนค่าการตัดสินใจที่ผ่านการปรับเทียบ และเวตชุดเดียวกันนี้ให้บริการทุกบัญชี" การปรับให้เข้ากับโดเมนเกิดขึ้นในคำขอ — สถานะของคุณ เกณฑ์ของคุณ — ไม่ใช่ในเช็กพอยต์เฉพาะรายลูกค้า ไม่ว่าการปรับเทียบใดที่วิธีนี้สร้างขึ้น ก็คือการปรับเทียบที่ลูกค้าทุกคนได้รับ

ทำไมการปรับเทียบ (calibration) จึงเป็นสิ่งที่ทำให้โมเดลการตัดสินใจต้นทุนต่ำสามารถใช้งานได้

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

• ความเชื่อมั่นสูง — ดำเนินการโดยอัตโนมัติ โมเดลอ่านสถานการณ์ได้อย่างชัดเจน และคุณสามารถดำเนินการต่อได้โดยไม่ต้องมีการมีส่วนร่วมของมนุษย์

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

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

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

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

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

ข้อจำกัดที่ตรงไปตรงมา: การปรับเทียบไม่ได้แปลว่าถูกต้อง

สิ่งที่สำคัญที่สุดที่ต้องเข้าใจให้ถูกต้องเกี่ยวกับ RLCD คือสิ่งที่มันไม่ได้กล่าวอ้าง การคาลิเบรตเป็นคุณสมบัติของค่าความเชื่อมั่น ไม่ใช่การรับประกันเกี่ยวกับคำตอบ และผู้ขายได้ระบุไว้เช่นนั้นในเอกสารของตนเอง แทนที่จะปล่อยให้เป็นหน้าที่ของนักวิจารณ์ หน้า System One ระบุว่า: “โมเดล System One ได้รับการฝึกมาเพื่อการตัดสินใจที่ผ่านการคาลิเบรต: ความน่าจะเป็นของมันถูกปรับให้เหมาะสมกับผลลัพธ์เพื่อสะท้อนความไม่แน่นอน การคาลิเบรตวัดจากกลุ่มของการทำนาย และไม่ได้การันตีว่าคำตอบใดคำตอบหนึ่งจะถูกต้อง” โมเดลหนึ่งอาจคาลิเบรตได้อย่างสมบูรณ์แบบแต่ก็ยังตัดสินใจผิดกับตั๋วของคุณได้ เพราะ 0.9 หมายถึงเก้าในสิบ และครั้งนี้อาจเป็นครั้งที่สิบ

ตัวเลขการให้บริการของเราเองต่างหากที่เป็นตัวถ่วงดุลที่มีประโยชน์ตรงนี้ เพราะมันเป็นการวัดโมเดลในการใช้งานจริง มากกว่าจะเป็นคำกล่าวอ้างว่าวิธีนี้ทำอะไรได้ ในช่วงเจ็ดวันสิ้นสุดวันที่ 2026-09-30 บนทราฟฟิกที่ผ่าน playground ของ OrcaRouter นับตั้งแต่โมเดลนี้ถูกเพิ่มเข้าแค็ตตาล็อก การ์ดของ Jev 1.13 รายงานอัตราข้อผิดพลาด 0.49% ตลอด 76.2 ล้านโทเคน พร้อมด้วยค่า p50 ของเวลาถึงโทเคนแรกเท่ากับ 151 มิลลิวินาที, ค่า p95 เท่ากับ 247 มิลลิวินาที และประมาณ 349 โทเคนเอาต์พุตต่อวินาที มีสองเรื่องเกี่ยวกับตัวเลขนั้นที่ควรพูดให้ตรงไปตรงมา มันเป็นของเรา ไม่ใช่ของผู้ขาย และมันเป็นหน้าต่างแบบเลื่อน ไม่ใช่ชุดทดสอบแบบตายตัว — ฟิลด์เดียวกันนี้เคยอ่านได้ 0.57% ก่อนหน้านี้ในช่วงหน้าต่าง เพราะมันถูกคำนวณใหม่จากเจ็ดวันย้อนหลังของทราฟฟิกสด และการเรียกของเมื่อวานจะหลุดออกไปตามอายุ มันยังไม่ใช่การวัดเพื่อสอบเทียบด้วย อัตราข้อผิดพลาดบอกคุณว่ามีสิ่งผิดพลาดเกิดขึ้นบ่อยแค่ไหนบนทราฟฟิกของเรา; มันไม่ได้บอกคุณว่าค่าความเชื่อมั่นเหล่านั้นซื่อตรงหรือไม่ ซึ่งเป็นคำถามคนละข้อ และเป็นคำถามที่ต้องใช้ข้อมูลที่มีป้ายกำกับเพื่อตอบ

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

ยังมีข้อจำกัดอีกสองข้อที่ควรกล่าวถึงในคราวเดียวกัน ข้อแรกคือ ไม่มีการ์ดผลทดสอบมาตรฐานสาธารณะสำหรับโมเดลนี้ให้ใช้ตรวจสอบสิ่งใด ๆ เทียบได้ — ผู้พัฒนายังไม่ได้เผยแพร่ และไม่มีตารางจัดอันดับของบุคคลที่สามใดที่มีโมเดลนี้อยู่ หน้าโมเดลบน Artificial Analysis คืนค่า 404 ณ วันที่ 2026-09-30 ดังนั้นข้อโต้แย้งเรื่องการปรับเทียบจึงตั้งอยู่บนคำอธิบายการฝึก สัญญาที่บันทึกไว้ และสิ่งที่คุณวัดเอง ไม่ได้ตั้งอยู่บนเส้นโค้งที่เผยแพร่ ข้อที่สองคือ คำกล่าวอ้างเรื่องประสิทธิภาพของผู้พัฒนาเองนั้นล้วนเป็นของผู้พัฒนาเอง โพสต์เปิดตัวระบุอย่างตรงไปตรงมาว่า การประเมินเวิร์กโฟลว์ที่รองรับพาดหัวเรื่องความเร็วและต้นทุนนั้นสร้างขึ้นโดยทีมความสามารถของโมเดลของบริษัทเอง ว่าคำตอบอ้างอิงที่ใช้วัดเทียบนั้นเป็นค่าเฉลี่ยของโมเดลภายนอกสองตัว และว่าตัวเลขเหล่านั้น "อยู่ปลายบนของช่วงผลประโยชน์ในโลกจริง" อีกทั้งยังระบุด้วยว่าการตั้งราคาไม่สามารถพิสูจน์ได้ว่าไม่ได้มาจากการอุดหนุน ทั้งหมดนี้ไม่ได้บั่นทอนวิธีการฝึก ซึ่งเป็นข้อกล่าวอ้างที่แยกจากข้อกล่าวอ้างเรื่องความเร็ว แต่ก็หมายความว่าเหตุผลสนับสนุน RLCD เป็นข้อโต้แย้งเกี่ยวกับการออกแบบวัตถุประสงค์ มากกว่าจะเป็นผลเชิงประจักษ์ที่ยุติแล้ว มองมันเป็นสมมติฐานที่คุณทดสอบได้ในต้นทุนต่ำ ซึ่งเป็นตำแหน่งที่ดีกว่าที่ข้อกล่าวอ้างเรื่องวิธีการฝึกส่วนใหญ่ทิ้งไว้ให้คุณ

สิ่งที่คุณสามารถทำได้กับสิ่งนี้ในวันนี้

สองขั้วของข้อโต้แย้งนี้มาบรรจบกันในจุดเดียว RLCD คือเหตุผลที่ความเชื่อมั่นของโมเดลตัดสินใจควรค่าแก่การแตกกิ่ง เกณฑ์ (threshold) ในโค้ดของคุณคือที่ที่กิ่งนั้นตั้งอยู่ และการยกระดับ (escalation) จะจ่ายไหวก็ต่อเมื่อเส้นทางปกติถูกพอที่จะรันได้ทุกที่ Jev 1.13 เรียกใช้ได้ในชื่อ typesafe/jev-1.13 บน OrcaRouter — API เดียวสำหรับโมเดล 200+ ตัว ไม่บวกกำไร 0% ผ่านราคาตั้งของผู้ให้บริการตรง ๆ ดังนั้นการลดราคาของผู้ขายจึงมีผลที่นี่ในวันเดียวกัน — ซึ่งหมายความว่าเส้นทางเสียงข้างมากที่มั่นใจและเส้นทางยกระดับแบบ generative ถูกคิดเงินบนคีย์เดียวกัน แทนที่จะเป็นสัญญากับผู้ขายสองราย คุณยังคงเรียกมันในรูปแบบของตัวเอง คือ POST /v1/systemone แบบไม่สตรีม กับ context 65,536 โทเคน เพราะนั่นไม่ใช่เส้นทาง chat-completions ของ OpenAI และไม่ได้ถูกพับรวมเข้าใน endpoint แชต บันทึกสองรายการที่มีวันที่จากรีลีส SDK ของผู้ขายนั้นน่ารู้ไว้หากคุณกำลังต่อระบบนี้: เวอร์ชัน 0.7.1 เปิดตัวเมื่อ 2026-09-21 เพิ่มตัวอย่างการใช้งานกับ AI gateway และเวอร์ชัน 0.7.2 เปิดตัวเมื่อ 2026-09-26 เพิ่ม http2 extra ให้แพ็กเกจ Python รายการที่สองเป็นรายละเอียดแบบที่ปรากฏเฉพาะในบันทึกการรีลีส — ไคลเอนต์ HTTP/2 นั้นคุ้มค่าที่จะมีไว้สำหรับโมเดลที่คุณค่าเสนอทั้งหมดอยู่ที่การไป-กลับต่ำกว่า 200 มิลลิวินาที

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

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