โมเดลตัดสินใจของ AI คืออะไร? วิธีทำงานและตัวอย่างสำคัญ

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

ลองคิดถึงวิธีที่ใช้โมเดลภาษาขนาดใหญ่ (LLMs) ในแอปส่วนใหญ่ทุกวันนี้ เราถามว่า “ทิกเก็ตนี้เกี่ยวกับการเรียกเก็บเงิน การจัดส่ง หรือการคืนสินค้า?” แล้วโมเดลก็เขียนประโยคเต็มกลับมา ซึ่งต้องเขียนโค้ดมาช่วยแยกความหมาย ทั้งที่จริงแล้วมีคำตอบเป็นไปได้แค่สามอย่าง แต่เรากลับจ่ายเงินให้ทั้งกระบวนการคิด

นี่คือช่องว่างที่โมเดลประเภทใหม่นี้พยายามจะเติมเต็ม ในกันยายน 2026 สตาร์ทอัปชื่อ TypeSafe AI เปิดตัว Jev โมเดลที่ไม่เขียนข้อความเลย

แทนที่จะเขียน มันจะให้คะแนนชุดคำตอบที่กำหนดไว้และบอกความเป็นไปได้ของแต่ละคำตอบ ภายในไม่กี่สัปดาห์ OpenAI, Cloudflare, Perplexity และ Microsoft ก็ออกเวอร์ชันของตนเอง แสดงให้เห็นว่าพื้นที่นี้พัฒนาเร็วมาก

ในบทความนี้ จะพาไปรู้จักว่าโมเดลตัดสินใจของ AI คืออะไร ทำงานอย่างไร และแนวคิดนี้มาจากไหนกันแน่ (จริง ๆ เก่ากว่ากระแสฮือฮานี้มาก) พร้อมดูผลการทดสอบอิสระ

สรุปโมเดลตัดสินใจแบบย่อ

• โมเดลตัดสินใจรับอินพุตและรายการคำตอบที่อนุญาต แล้วส่งกลับความน่าจะเป็นของแต่ละคำตอบ แทนการสร้างข้อความ
• เพราะโมเดลให้คะแนนคำตอบได้ในครั้งเดียว TypeSafe รายงานว่า Jev ตอบสนองภายใน 70 ถึง 500 มิลลิวินาที และผลลัพธ์ส่งเข้า if ในโค้ดได้ทันที
• แนวคิดนี้ไม่ใหม่ คลาสสิฟายเออร์แบบ zero-shot, reranker และ verifier ให้คะแนนตัวเลือกมาตั้งนานแล้ว รุ่นปี 2026 จาก TypeSafe, OpenAI, Cloudflare, Perplexity และ Microsoft ส่วนใหญ่เป็นการแพ็กเกจให้ใช้ง่ายขึ้น
• ในการทดสอบ guardrail อิสระของ Red Hat โมเดลตัดสินใจไม่ได้ให้คำตอบที่เร็วกว่า ถูกกว่า หรือดีกว่า LLM-as-a-judge และคลาสสิฟายเออร์ขนาดเล็กที่เทรนมาก็ทำได้ใกล้เคียงกันในโจทย์ prompt injection
• เหมาะที่สุดกับการเป็นเกตที่เร็วและถูก ล้อมรอบ LLM ควรทดสอบความน่าจะเป็นกับข้อมูลของตนเองก่อนตั้งเกณฑ์

โมเดลตัดสินใจของ AI คืออะไร?

โมเดลตัดสินใจของ AI คือโมเดลที่รับอินพุตและชุดของคำตอบที่อนุญาต แล้วส่งกลับความน่าจะเป็นของแต่ละคำตอบ โดยไม่สร้างข้อความอิสระ

แนวคิดหลักคือเอาต์พุตมีโครงสร้างอยู่แล้ว

ไม่ต้องแยกวิเคราะห์ประโยค เพราะโมเดลส่งคืนได้เฉพาะหนึ่งในคำตอบที่ให้ไว้ นั่นหมายความว่าผลลัพธ์ส่งเข้า if ในโค้ดได้ทันที

นึกถึงข้อสอบสองประเภท

โมเดลภาษาขนาดใหญ่ทำข้อสอบอัตนัย เขียนคำตอบทีละคำ ในขณะที่โมเดลตัดสินใจทำข้อสอบปรนัย และยังบอกด้วยว่ามั่นใจแค่ไหนในแต่ละตัวเลือก (คะแนนความมั่นใจ)

สามประเภทของคำถาม

Jev และ ทางเลือกแทน Jev ส่วนใหญ่รองรับคำถามสามแบบ:

• Choice: เลือกหนึ่งตัวเลือกจากรายการ (Jev รองรับสูงสุด 255 ตัวเลือก) พร้อมความน่าจะเป็นของแต่ละตัวเลือก
• Noul: ความน่าจะเป็นว่าข้อความหนึ่งเป็นจริง ซึ่งเป็นชื่อที่ TypeSafe ใช้เรียกคำถามใช่/ไม่ใช่
• Score: ตำแหน่งบนสเกลเรียงลำดับ เช่น รูบริก 1 ถึง 5

TypeSafe ยังมี Box แบบทดลองสำหรับระบุตำแหน่งในภาพ ซึ่งจะไม่กล่าวถึงที่นี่

ยกตัวอย่างจากเอกสารของ TypeSafe

สามารถส่ง state (ข้อความที่ต้องการให้โมเดลดู) และแผนที่ของ questions สำหรับคำถามแบบ choice แต่ละตัวเลือกมีคำอธิบายสั้น ๆ ในฟิลด์ชื่อ criteria

{
  "model": "jev-latest",
  "state": "My running shoes arrived in the wrong size. Can I swap them for a size 10?",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "returns": "Exchanges, wrong or damaged items",
        "shipping": "Delivery status, delays, lost packages",
        "billing": "Charges, invoices, payment problems"
      }
    }
  }
}

และนี่คือคำตอบที่ได้:

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "returns",
      "confidence": 1.0,
      "probabilities": {
        "shipping": 0.0,
        "returns": 1.0,
        "billing": 0.0
      }
    }
  }
}

ไม่มีข้อความให้ต้องแยกวิเคราะห์

ได้ตัวเลือกที่ถูกเลือก ความน่าจะเป็นของทุกตัวเลือก และค่าความมั่นใจที่คำนวณจากความน่าจะเป็นสูงสุด ดังนั้นการกระจายที่แบนกว่าจะหมายถึงความมั่นใจต่ำกว่า ในเอกสาร ตัวอย่างทิกเก็ตที่ซับซ้อนขึ้นซึ่งพูดถึงไซส์ผิดและถูกเรียกเก็บเงินซ้ำ จะแบ่งความน่าจะเป็นระหว่าง returns (0.61) และ billing (0.35) และความมั่นใจลดลงเหลือ 0.42

ทำไม TypeSafe จึงเรียกมันว่าโมเดล “System One”

TypeSafe อธิบาย Jev ว่าเป็น “System One Model” โดยยืมมาจากหนังสือ Thinking, Fast and Slow ของ Daniel Kahneman ทำไมจึงเป็นเช่นนั้น?

แบบง่ายที่สุด System 1 คือการตัดสินใจเร็วจากสัญชาตญาณ ส่วน System 2 คือเหตุผลแบบค่อยเป็นค่อยไป

โมเดลตัดสินใจถูกออกแบบมาให้เป็นแบบเร็ว

ข้อควรระวัง: System 1 ก็เป็นส่วนที่ทำผิดพลาดเร็วด้วย และต้องชื่นชมว่าเอกสารของ TypeSafe เองก็ระบุอย่างเปิดเผยว่า Jev พลาดตรงไหนบ้าง เดี๋ยวจะกลับมาที่จุดนี้

ขอเคลียร์เรื่องชื่อเรียก

สิ่งหนึ่งที่ทำให้งงตอนอ่านครั้งแรกคือ “โมเดลตัดสินใจ” มีความหมายอย่างอื่นอยู่แล้ว อาจหมายถึง:

• ตารางการตัดสินใจในซอฟต์แวร์กฎธุรกิจ
• Decision Transformer ในการเรียนรู้แบบเสริมกำลัง ซึ่งจริง ๆ แล้วสร้าง “การกระทำ” จึงเกือบตรงข้ามกับที่กำลังคุยกัน
• โมเดลตัวเลือกในเศรษฐศาสตร์

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

การสร้างข้อความแบบทีละโทเคนทำงานอย่างไร

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

โมเดลภาษาขนาดใหญ่ทำงานเป็นลูป

มันแปลงข้อความเป็นโทเคน ทำนายความน่าจะเป็นของทุกโทเคนในคลังคำ เลือกหนึ่งโทเคน เพิ่มเข้าในข้อความ แล้วทำซ้ำ

โทเคนเพิ่มทุกตัวหมายถึงการทำ forward pass ผ่านโมเดลอีกครั้ง

ภาพที่ 1: LLM ต้องทำ forward pass หนึ่งครั้งต่อโทเคนที่เขียน ภาพต้นฉบับโดยผู้เขียน

ลูปนี้เหมาะกับการเขียนอีเมล โค้ด หรือคำอธิบาย แต่พอเป็นการตัดสินใจง่าย ๆ อาจเกิดปัญหาบางอย่าง:

• ต้องจ่ายเงินเพื่อสร้างคำที่ท้ายที่สุดทิ้ง
• โมเดลอาจตอบ “ใช่ เพราะ…” ทั้งที่ขอมาแค่ “ใช่” หรือ “ไม่ใช่” ซึ่งทำให้พาร์เซอร์พัง
• ความผิดพลาดเล็ก ๆ อาจสะสมในเอาต์พุตที่ยาว
• ถ้าถาม LLM ว่ามั่นใจแค่ไหน ตัวเลขที่เขียนกลับมามักไม่สัมพันธ์กับความจริง ตามที่ John Berryman แห่ง Arcturus Labs ชี้ไว้ในการวิเคราะห์ Jev

โมเดลตัดสินใจพยายามแก้ปัญหาเหล่านี้โดยตรง

โมเดลตัดสินใจทำงานอย่างไร: การให้คะแนนเอาต์พุต

มาดูเชิงกลไกจริง ๆ กัน

มีสามแนวคิดที่ควรเข้าใจ:

1. หนึ่งครั้งผ่าน แทนลูป
2. ความน่าจะเป็นมาจากไหน
3. “ปรับเทียบ” หมายความว่าอะไร

มาดูทีละข้อ

หนึ่งครั้งผ่าน แทนลูป

โมเดลตัดสินใจอ่านอินพุตและคำถาม แล้วสร้างคะแนนให้คำตอบที่อนุญาตแต่ละข้อ

คะแนนเหล่านั้นมักถูกแปลงเป็นความน่าจะเป็นด้วยฟังก์ชัน softmax อย่างที่เดาได้ ไม่มีลูปยาว ๆ เพราะไม่มีอะไรให้เขียน

เอกสารของ TypeSafe ยังระบุว่าคำถามในคำขอเดียวกันจะประเมินแบบขนาน ดังนั้นการเพิ่มคำถามแทบไม่กระทบเวลา

นี่คือแหล่งที่มาหลักของความเร็ว และ TypeSafe ระบุว่า Jev มักตอบในราว 70 ถึง 500 มิลลิวินาที

ภาพที่ 2: ทิกเก็ตเดียวกัน ตอบโดย LLM และโดยโมเดลตัดสินใจ ภาพต้นฉบับโดยผู้เขียน

ความน่าจะเป็นมาจากไหน

ไม่ได้มี “สถาปัตยกรรมโมเดลตัดสินใจ” แบบเดียว

TypeSafe ไม่ได้เปิดเผยวิธีทำงานของ Jev แต่โดยคร่าว ๆ มีสามวิธีที่จะได้คะแนนเหล่านี้:

• อ่านความน่าจะเป็นโทเคนของ LLM เอง ระบุคำตอบเป็น A, B, C รันโมเดล แล้วดูแค่ว่ามันคิดว่า “A” “B” หรือ “C” เป็นโทเคนถัดไปได้ความน่าจะเป็นเท่าไร John Berryman ที่ Arcturus Labs เดาในตอนแรกว่า Jev เป็นโมเดลเอนโคเดอร์ที่มีเอาต์พุตเฮดแบบกำหนดเอง แล้วชี้ไปที่โพสต์ X ของ Harsha Gundala ที่ทำสิ่งคล้ายกันด้วยความน่าจะเป็นโทเคน ทั้งสองยังไม่ยืนยัน
• เติม scoring head โมเดลเอนโคเดอร์ขนาดเล็กมีเลเยอร์เอาต์พุตที่ให้คะแนนตัวเลือกโดยตรง โมเดลโอเพนซอร์ส Laya ใช้ ModernBERT แบบนี้
• ใช้โมเดลตัวให้คะแนนแยกต่างหาก โมเดลที่สอง เช่น reranker หรือ reward model ให้คะแนนผู้สมัครแต่ละตัว

ไม่ต้องกังวลว่าใครใช้วิธีไหน ทั้งสามทางจบที่จุดเดียวกัน คือได้ตัวเลขให้กับคำตอบที่อนุญาตแต่ละข้อ

“ปรับเทียบ” หมายความว่าอะไร

ส่วนนี้สำคัญที่สุด ขอยกตัวอย่าง

สมมติว่าโมเดลบอก “มีโอกาส 70%” บนคำถาม 100 ข้อ ถ้าโมเดลปรับเทียบดี ประมาณ 70 คำตอบควรจะถูกจริง

การปรับเทียบสำคัญเพราะความน่าจะเป็นที่ปรับเทียบดีจะทำให้เราตั้งเกณฑ์ในโค้ดได้อย่างปลอดภัย เช่น “อนุมัติอัตโนมัติถ้าเกิน 90% ไม่เช่นนั้นส่งให้มนุษย์”

ถ้าความน่าจะเป็นไม่ตรงกับความจริง เกณฑ์เหล่านั้นก็ไร้ความหมาย

ผู้ให้บริการจะฝึกด้วยฟังก์ชันสูญเสียที่ลงโทษความมั่นใจเกินจริง

TypeSafe เรียกวิธีของตนว่า Reinforcement Learning for Calibrated Decisions (RLCD) ส่วน Cloudflare ระบุว่าใช้ cross-entropy คู่กับ Brier loss สำหรับโมเดล Clef

โมเดลตัดสินใจไม่ใช่แนวคิดใหม่

อาจทำให้แปลกใจ แต่แนวคิดการให้คะแนนตัวเลือกแทนการสร้างคำตอบมีมาหลายปีแล้ว

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

ภาพที่ 3: แนวคิดให้คะแนนแทนการสร้างย้อนไปถึงปี 2019 โมเดลตัดสินใจคือเวอร์ชันปี 2026 ภาพต้นฉบับโดยผู้เขียน

คลาสสิฟายเออร์แบบ zero-shot

ย้อนไปปี 2019 โมเดลอย่าง BART-large-mnli ก็สามารถจัดข้อความเข้าเลเบลที่ไม่เคยฝึกมาก่อนได้แล้ว

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

ทีมความปลอดภัย AI ของ Red Hat เสนอว่า โมเดลตัดสินใจอาจเป็นเพียงคลาสสิฟายเออร์ zero-shot ภายใต้ชื่อใหม่

Reranker และ cross-encoder

ถ้าเคยสร้างระบบ RAG น่าจะเคยใช้ คุณจะดึงรายการคร่าว ๆ มาก่อน (เช่น 50 เอกสาร) จากนั้น cross-encoder จะอ่านคำถามคู่กับแต่ละเอกสารและให้คะแนนความเกี่ยวข้องของแต่ละคู่

ไม่มีการสร้างข้อความ เอกสารถูกเรียงใหม่ตามคะแนนเท่านั้น

Reward model และ verifier

เป็นตัวให้คะแนนที่ให้คะแนนคำตอบที่ LLM สร้างมาแล้ว

ในปี 2021 นักวิจัย OpenAI แสดงให้เห็นว่าการเติม verifier ให้โมเดลช่วยเพิ่มผลลัพธ์คณิตศาสตร์ระดับประถมได้ประมาณ เท่ากับทำให้โมเดลใหญ่ขึ้น 30 เท่า ซึ่งน่าสนใจมาก

สองปีต่อมา งาน “Let’s Verify Step by Step” แสดงว่าการให้คะแนนแต่ละขั้นตอนของเหตุผลยิ่งได้ผลกว่าการให้คะแนนเฉพาะคำตอบสุดท้าย

Best-of-N และ generate-then-filter

เวอร์ชันง่าย ๆ คือสร้างหลายคำตอบ ให้คะแนนแต่ละคำ แล้วเก็บอันที่ดีที่สุด AlphaCode ของ DeepMind (2022) ทำขั้นสุดโดยสร้างโปรแกรมสูงสุดล้านโปรแกรมต่อปัญหา ทิ้งประมาณ 99% ด้วยการทดสอบตัวอย่าง แล้วส่งเพียง 10 อัน

ในการประเมินแบบจำลองบนการแข่งขัน Codeforces เก่า ๆ ทำได้เฉลี่ยอันดับท็อป 54.3% ของผู้แข่งขันมนุษย์

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

คำทางเทคนิคเรียก reward overoptimization

LLM-as-a-judge

คือการให้ LLM ขนาดใหญ่มาตัดสินงานของโมเดลอื่น

งานปี 2023 พบว่า GPT-4 เห็นพ้องกับผู้ตัดสินมนุษย์เกิน 80% แต่ก็มีอคติ เช่น ชอบคำตอบยาวกว่า หรือคำตอบที่แสดงก่อน

โมเดลตัดสินใจถูกนำเสนอส่วนหนึ่งว่าเป็นตัวแทนที่ถูกกว่าและมีโครงสร้างสำหรับผู้ตัดสินแบบนี้

โมเดลแบบ energy-based และ JEPA

โมเดล energy-based จะให้ “พลังงาน” ต่ำกับคู่ของอินพุตและคำตอบที่เข้ากันได้ดี และพลังงานสูงกับคู่ที่ไม่เข้ากัน

การเลือกคำตอบจึงหมายถึงการหาพลังงานต่ำสุด ซึ่งก็คือการให้คะแนนตัวเลือกอีกแบบหนึ่ง

Yann LeCun โต้แย้งมาหลายปีว่าการสร้างทีละโทเคนไม่ใช่เส้นทางสู่ความฉลาดแท้ และแนวทาง energy-based และ JEPA น่าจะดีกว่า

โมเดลตัดสินใจเด่นในปี 2026

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

Jev ของ TypeSafe

TypeSafe AI เป็นสตาร์ทอัปซานฟรานซิสโก ก่อตั้งโดย Diogo Almeida อดีตนักวิจัย OpenAI เปิดตัวจากสเตลธ์เมื่อ 15 กันยายน 2026 พร้อม Jev และเงินระดมทุนซีด 40 ล้านดอลลาร์นำโดย DCVC

Jev เป็น API แบบโฮสต์ ในโปรดักชันรับเฉพาะข้อความ อินพุตภาพยังเป็นแบบทดลองและต้องใส่เฮดเดอร์ opt-in คิดราคาเป็นโทเคนอินพุต เอาต์พุตฟรี ซึ่งสมเหตุสมผลเมื่อเอาต์พุตเป็นแค่ตัวเลขไม่กี่ตัว

Jev 1.14 ตามมาเมื่อ 14 ตุลาคม แม้ว่าแอลิแอส jev-latest ยังชี้ไปที่ 1.13.0 ซึ่งเป็นเวอร์ชันที่ Red Hat ทดสอบในบทความนี้

มีเสียงฮือฮามากตอนเปิดตัว Vercel ระบุว่าประมาณ 13% ของทีมแบบเสียค่าบริการลองใช้ Jev ผ่าน AI Gateway ภายใน 24 ชั่วโมงแรก แม้ว่าตอนนั้นใช้ฟรีบนเกตเวย์

Decisions API ของ OpenAI

OpenAI เปิดตัว Decisions API ในงาน DevDay วันที่ 29 กันยายน 2026

ทำงานกับคำถามที่ผู้ใช้กำหนดซึ่งมีชุดคำตอบตายตัว และสร้างบน GPT-6 Luna เข้าสู่ public beta วันที่ 6 ตุลาคม และรับภาพได้ด้วย ขณะที่ Jev รองรับแบบทดลองเท่านั้น

Clef ของ Cloudflare

Cloudflare ออก Clef และ Clef-flash รุ่นเล็กในวันที่ 1 ตุลาคม 2026 พร้อมน้ำหนักโมเดลแบบเปิด และโฮสต์บน Workers AI ทั้งคู่สร้างบนโมเดล Qwen และรับคำขอรูปแบบเดียวกับ Jev ดังนั้นโค้ดที่เขียนให้ Jev สามารถชี้ไปที่ Clef ได้แทบไม่ต้องแก้

โมเดลอื่น ๆ

สิ่งที่สะดุดตาคือ โมเดลแบบเปิดและของบิ๊กเทคส่วนใหญ่ที่นี่เป็นเวอร์ชัน fine-tune ของ LLM ปกติ Laya เป็นข้อยกเว้น: เป็นเอนโคเดอร์ที่มี decision head ภายในของ Jev ไม่เปิดเผย

ในความเห็นนี้ สนับสนุนแนวคิดที่ว่านวัตกรรมจริงคือการแพ็กเกจ (อินเทอร์เฟซและการฝึกเพื่อการปรับเทียบ) มากกว่าสถาปัตยกรรมใหม่หมดจด

โมเดลตัดสินใจ vs LLMs vs คลาสสิฟายเออร์

วิธีตัดสินใจที่ชัดที่สุดว่าเมื่อใดควรใช้อะไรคือเปรียบเทียบกัน:

เมื่อใดควรใช้อะไร

กฎคร่าว ๆ คือ:

• คำตอบมีขอบเขตและไม่มีข้อมูลฝึก: โมเดลตัดสินใจเหมาะมาก
• งานเดียว มีข้อมูลติดเลเบลเยอะและจำกัดเวลาเข้ม: คลาสสิฟายเออร์แบบ fine-tune มักชนะ
• เอาต์พุตปลายเปิด: ใช้ LLM
• ปัญหายากแต่ตรวจสอบคำตอบได้ถูก: ใช้ LLM ร่วมกับ verifier

เชื่อว่าระบบที่ดีที่สุดจะผสมผสานทั้งหมดนี้

มองเห็นภาพว่าโมเดลตัดสินใจทำหน้าที่เป็น “เกต” ที่เร็วและถูก ล้อมรอบ LLM เกตจะตัดสินว่า:

• ควรเรียกเครื่องมือใด
• อินพุตปลอดภัยหรือไม่
• ผลลัพธ์ต้องการมนุษย์หรือไม่

แบบนี้ LLM ที่แพงจะทำงานเฉพาะเมื่อมีอะไรต้อง “เขียน” จริง

ผลการทดสอบอิสระบอกอะไร

ส่วนนี้สำคัญที่สุด เพราะตัวเลขใหญ่ ๆ ออนไลน์ส่วนมากมาจากผู้ขายเอง แม้แต่ TypeSafe ก็ยอมรับว่าตัวเลขความเร็วและต้นทุนระดับพาดหัวเป็นด้านบน ๆ ของสิ่งที่จะเห็นจริง

เบนช์มาร์กการ์ดเรลของ Red Hat

ในตุลาคม 2026 ทีมความปลอดภัย AI ของ Red Hat เปรียบเทียบการตั้งค่าการ์ดเรล 9 แบบบนสองงาน: จับ prompt injection และจับคอนเทนต์ไม่ปลอดภัย

DiffusionGemma คือโมเดล text-diffusion ตระกูล Gemma ให้บริการผ่าน vLLM

ผลลัพธ์ที่น่าสนใจที่สุดมีดังนี้:

Jev ได้ที่หนึ่งด้านความปลอดภัยเนื้อหา แซง DiffusionGemma อยู่ 0.67 จุดเปอร์เซ็นต์ (Qwen เป็นผู้ตัดสินอยู่อันดับสาม) ส่วน Qwen ได้ที่หนึ่งด้าน prompt injection

การแบ่งแบบนี้ทำให้ Red Hat ยังคงสรุปได้ว่าโดยรวมแล้วโมเดลตัดสินใจไม่ได้ให้คุณภาพดีกว่า LLM-as-a-judge

สิ่งที่น่าสนใจที่สุดคือ คลาสสิฟายเออร์ขนาด 200 ล้านพารามิเตอร์ตามหลังเพียง 0.3 จุดเปอร์เซ็นต์บน prompt injection โดยมี latency มัธยฐานต่ำกว่า 100 มิลลิวินาที เทียบกับราว 348 ของ Jev

Latency ของ Jev รวมการข้ามมหาสมุทรแอตแลนติก เพราะทดสอบจากสหราชอาณาจักรและเซิร์ฟเวอร์ของ TypeSafe อยู่ในสหรัฐฯ

การเดินทางนั้นอธิบายช่องว่างกับโมเดลที่รันบน CPU ในเครื่องได้บางส่วน Qwen, Nemotron และ DiffusionGemma ก็รันบนคลัสเตอร์ในสหรัฐฯ เช่นกัน และ Qwen ก็ยังเร็วกว่า Jev

ถึงอย่างนั้น Red Hat ก็สรุปว่า โมเดลตัดสินใจไม่ได้ให้คำตอบที่เร็วกว่า ถูกกว่า หรือดีกว่า LLM-as-a-judge ในการทดสอบของพวกเขา ยกเว้น Laya ที่มีข้อได้เปรียบจากขนาดเล็ก หากสามารถปรับพรอมป์ตล้อมข้อจำกัดได้

งานวิจัย “Just Ask Jev”

งานวิจัยจากนักวิจัยมหาวิทยาลัยที่โพสต์บน arXiv ในกันยายน 2026 ทดสอบ Jev บนเบนช์มาร์ก alignment 44 ชุด

ผลออกมาปะปนในแบบที่น่าสนใจ:

• Jev ทำได้ดีในการจัดอันดับกรณีผิดพลาดด้าน alignment ให้อยู่เหนือกรณีที่ไม่ผิด โดยมีค่า AUROC มัธยฐาน 0.886 บน 31 เบนช์มาร์กที่รองรับคำถามใช่/ไม่ใช่ทั่วไป AUROC วัดความสามารถในการจัดอันดับตัวอย่างบวกให้อยู่เหนือบวกปลอม ที่ 0.5 คือเดาสุ่ม และ 1 คือจัดอันดับสมบูรณ์แบบ
• มีค่าใช้จ่ายราว 0.30 ดอลลาร์สำหรับงานที่ใช้ LLM judges อยู่ราว 18.96 ดอลลาร์ บน 19 เบนช์มาร์กที่ใช้ API judge
• ปรับเทียบได้ดีเมื่อรวมทุกเบนช์มาร์กเข้าด้วยกัน แต่ไม่ดีภายในเบนช์มาร์กรายชุด
• เก็บเฉพาะครึ่งหนึ่งของคำตอบที่ห่างจาก 50% มากที่สุด ทำให้ความแม่นยำมัธยฐานเพิ่มจาก 0.793 เป็น 0.933
• ผู้เขียนระบุข้อจำกัด: ใช้ Jev เวอร์ชันเดียว ภาษาอังกฤษเท่านั้น โมเดลเป้าหมายขนาด 2B ถึง 7B และเลเบลจำนวนมากสร้างโดยตัวให้คะแนนที่มีอยู่

มองว่าประเด็นการคัดเลือกคำตอบที่มั่นใจมีประโยชน์มากในทางปฏิบัติ

มันแสดงว่าดีไซน์ง่าย ๆ ที่ให้โมเดลตัดสินใจจัดการเคสง่าย แล้วส่งเคสไม่มั่นใจไปให้ LLM หรือมนุษย์ เป็นกลยุทธ์ที่ดี

ลงมือทำ: สร้างโมเดลตัดสินใจจาก LLM ขนาดเล็ก

มาสร้างโมเดลตัดสินใจเองกัน

เราจะเปลี่ยน LLM แบบเปิดขนาดเล็กให้เป็นโมเดลตัดสินใจด้วยเทคนิคลความน่าจะเป็นโทเคนจากก่อนหน้า แล้วตรวจว่าความน่าจะเป็นน่าเชื่อถือหรือไม่

ก่อนอื่น ติดตั้งแพ็กเกจด้วยคำสั่งนี้ (ทั้งหมดรันบน Colab ฟรีได้):

pip install transformers torch datasets sentence-transformers numpy

ขั้นที่ 1: เปลี่ยน LLM เป็นตัวให้คะแนน

จะใช้ Qwen2.5-0.5B-Instruct ซึ่งเล็กพอจะรันบน CPU ได้

แนวคิดง่ายมาก: ติดฉลากตัวเลือกด้วยตัวอักษร รันโมเดลครั้งเดียว แล้วดูเฉพาะความน่าจะเป็นของตัวอักษรเหล่านั้นเป็นโทเคนถัดไป

import torch
from transformers import AutoTokenizer, AutoModelForCausalLM

model_name = "Qwen/Qwen2.5-0.5B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)
model.eval()

def option_logits(state, question, options):
    letters = [chr(ord("A") + i) for i in range(len(options))]
    option_text = "\n".join(f"{l}. {o}" for l, o in zip(letters, options))
    messages = [
        {"role": "system", "content": "Answer with a single letter only."},
        {"role": "user", "content": f"{state}\n\nQuestion: {question}\n{option_text}"},
    ]
    prompt = tokenizer.apply_chat_template(
        messages, tokenize=False, add_generation_prompt=True
    )
    inputs = tokenizer(prompt, return_tensors="pt")

    with torch.no_grad():
        next_token_logits = model(**inputs).logits[0, -1].float()

    letter_ids = [tokenizer.encode(l, add_special_tokens=False)[0] for l in letters]
    return next_token_logits[letter_ids]

def decide(state, question, options, temperature=1.0):
    logits = option_logits(state, question, options)
    probs = torch.softmax(logits / temperature, dim=-1)
    return {o: round(p.item(), 3) for o, p in zip(options, probs)}

สังเกตว่าเราไม่เรียก generate() เราทำforward pass ครั้งเดียว เก็บคะแนนของ “A” “B” “C” เป็นต้น แล้วทิ้งส่วนอื่น

print(decide(
    state="My running shoes arrived in the wrong size. Can I swap them for a size 10?",
    question="Which team should handle this?",
    options=["returns", "shipping", "billing"],
))

print(decide(
    state="The app crashes every time I open the settings page.",
    question="Does this message describe a software bug?",
    options=["yes", "no"],
))

เท่านี้เอง เราสร้างโมเดลตัดสินใจที่ใช้งานได้ในราว 30 บรรทัด

คำถามใช่/ไม่ใช่ ก็คือคำถามแบบ choice ที่มีสองตัวเลือก

ขั้นที่ 2: มองหาอาการประหลาด

มาดูว่ารุ่นง่าย ๆ นี้เริ่มลำบากตรงไหน

ลองสลับลำดับของตัวเลือก แล้วรันคำถามเดิมอีกครั้ง:

options = ["returns", "shipping", "billing"]
state = "My shoes arrived late and in the wrong size, and I was charged twice."
question = "Which team should handle this?"

print(decide(state, question, options))
print(decide(state, question, list(reversed(options))))

บนอินพุตที่ยุ่งเหยิงแบบนี้ มักเห็นความน่าจะเป็นเปลี่ยนเพียงเพราะสลับตัวเลือก

นี่เรียกว่า order bias และ TypeSafe เองก็ระบุว่าเอนเอียงไปหาตัวเลือกแรกเป็นหนึ่งในจุดอ่อนของ Jev

อาจเห็นโมเดลให้คำตอบเกือบ 100% บ่อยครั้ง Berryman ทดสอบ Jev ไว้อย่างน่าสนใจ โดยบอกว่ามีโอกาสออกหัว 60% สำหรับการโยนเหรียญ คำถามใช่/ไม่ใช่ให้ค่า 0.58 ซึ่งใกล้เคียง

แต่คำถามแบบ choice (“หัวหรือก้อย?”) ให้0.99 สำหรับหัว เพราะความน่าจะเป็นยุบตัวไปที่คำตอบที่เป็นไปได้มากกว่า

ขั้นที่ 3: วัดและแก้การปรับเทียบ

ขั้นนี้คิดว่าทุกคนควรรัน เราจะใช้ข่าว 400 รายการจากชุดข้อมูล AG News (แต่ละรายการเป็นพาดหัวกับคำอธิบายสั้น ๆ) ซึ่งมี 4 หัวข้อ แล้วตรวจว่าความน่าจะเป็นของเราตรงกับความจริงไหม

import numpy as np
from datasets import load_dataset

data = load_dataset("fancyzhx/ag_news", split="test").shuffle(seed=42).select(range(400))
labels = ["World", "Sports", "Business", "Science and technology"]
question = "What is the topic of this news headline?"

all_logits, targets = [], []
for row in data:
    all_logits.append(option_logits(row["text"], question, labels))
    targets.append(row["label"])

all_logits = torch.stack(all_logits)
targets = torch.tensor(targets)

ต่อไป เราต้องการตัวชี้วัดการปรับเทียบ Expected calibration error (ECE) จะแบ่งการพยากรณ์ตามช่วงความมั่นใจ แล้วตรวจว่าในแต่ละช่วง ค่าเฉลี่ยความมั่นใจห่างจากความแม่นยำจริงเท่าไร

ย้ำว่า ยิ่งต่ำยิ่งดี:

def expected_calibration_error(probs, targets, n_bins=10):
    confidences, predictions = probs.max(dim=-1)
    correct = (predictions == targets).float()
    bins = np.linspace(0, 1, n_bins + 1)
    ece = 0.0
    for lo, hi in zip(bins[:-1], bins[1:]):
        mask = (confidences > lo) & (confidences <= hi)
        if mask.any():
            gap = abs(correct[mask].mean() - confidences[mask].mean())
            ece += mask.float().mean() * gap
    return float(ece), float(correct.mean())

เทคนิคคือ

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

อุณหภูมิมากกว่า 1 จะทำให้การพยากรณ์ที่มั่นใจเกินไปนุ่มลง ขณะที่ต่ำกว่า 1 จะทำให้คำทำนายที่ไม่มั่นใจคมขึ้น

calib_logits, test_logits = all_logits[:200], all_logits[200:]
calib_targets, test_targets = targets[:200], targets[200:]

def nll(temperature):
    probs = torch.softmax(calib_logits / temperature, dim=-1)
    picked = probs[torch.arange(len(calib_targets)), calib_targets]
    return -torch.log(picked + 1e-12).mean().item()

temperatures = [float(t) for t in np.linspace(0.5, 5.0, 46)]
best_t = min(temperatures, key=nll)

before = expected_calibration_error(torch.softmax(test_logits, dim=-1), test_targets)
after = expected_calibration_error(torch.softmax(test_logits / best_t, dim=-1), test_targets)

print(f"Best temperature: {best_t:.2f}")
print(f"Before: ECE={before[0]:.3f}, accuracy={before[1]:.3f}")
print(f"After:  ECE={after[0]:.3f}, accuracy={after[1]:.3f}")

ความแม่นยำจะไม่เปลี่ยน เพราะการหารด้วยอุณหภูมิไม่เปลี่ยนตัวเลือกที่อันดับหนึ่ง

เปลี่ยนเฉพาะความมั่นใจ

ตัวเลขจริงขึ้นกับการรันของคุณ แต่ ECE บนครึ่งทดสอบมักลดลง ด้วยตัวอย่างทดสอบแค่ 200 ชิ้น ค่าประเมินมีนอยส์ จึงไม่ควรอ่านค่าต่างเล็ก ๆ มากเกินไป

บทเรียนง่าย ๆ คือ: โมเดลที่ปรับเทียบบนข้อมูลของคนอื่น ไม่ได้แปลว่าใช้ได้ดีบนข้อมูลของคุณ

ขั้นที่ 4: ให้คะแนนตัวเลือกด้วย cross-encoder

เพื่อให้เห็นว่าแนวคิด “ให้คะแนน ไม่สร้าง” พบได้ทั่วไปแค่ไหน มาดูในบริบท RAG

cross-encoder ให้คะแนนแต่ละพารากราฟเทียบกับคำถาม แล้วเราเพียงเรียงลำดับ:

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L6-v2")

query = "How do I get a refund for a double charge?"
passages = [
    "Our app supports dark mode on all devices.",
    "If you were charged twice, contact billing and we will refund the duplicate payment.",
    "Refunds are processed within five business days.",
    "You can change your password from the settings page.",
]

for result in reranker.rank(query, passages):
    print(round(float(result["score"]), 3), passages[result["corpus_id"]])

อีกครั้ง ไม่มีการสร้างอะไร โมเดลแค่ให้ตัวเลขกับแต่ละตัวเลือก

เคสการใช้งานโมเดลตัดสินใจ

นี่คือเคสใช้งานที่พบบ่อยที่สุด:

ด้านหุ่นยนต์เป็นจุดที่ชอบเป็นการส่วนตัว

Berryman เสนอว่าโมเดลแบบ Jev อาจนั่งอยู่ระหว่าง LLM ช้า ๆ ที่วางแผนระดับสูง กับโมเดลคิเนเมติกที่ขยับข้อต่อหุ่นยนต์

แต่ควรรู้ว่าเดโม Doom ของ TypeSafe ที่โด่งดังนั้นป้อน telemetry แบบข้อความ ให้ Jev ไม่ใช่ภาพดิบ

ข้อจำกัดของโมเดลตัดสินใจ

โมเดลตัดสินใจมีประโยชน์ แต่ไม่อยากขายเกินจริง

ข้อจำกัดหลักที่พบมีดังนี้:

• เลือกได้แค่จากรายการของคุณ ถ้าคำตอบที่ถูกต้องไม่มีในตัวเลือก โมเดลก็สร้างใหม่ไม่ได้ ซึ่งเป็นเหตุผลที่ TypeSafe แนะนำให้มีตัวเลือก “อื่น ๆ” หรือคำถามใช่/ไม่ใช่คู่กัน เพื่อตรวจว่าเข้าข่ายอะไรหรือไม่
• ผิดอย่างมั่นใจก็ยังผิด ไม่มีคำตอบผิดรูปแบบไม่ได้แปลว่าไม่มีความผิดพลาด
• การปรับเทียบไม่ถ่ายโอนอัตโนมัติ ทดสอบเกณฑ์บนตัวอย่างเล็ก ๆ ที่ติดเลเบลจากข้อมูลของตนเอง
• พรอมป์ตไม่ได้ย้ายข้ามโมเดลเสมอไป Red Hat พบว่าพรอมป์ตที่จูนมาเพื่อ Laya เพิ่มความแม่นยำเกือบ 18 จุดเปอร์เซ็นต์ แต่ทำให้ Jev แย่ลงราว 3.7 จุดเปอร์เซ็นต์
• ไม่มีคำอธิบาย ทำให้ตัดสินใจตรวจสอบย้อนหลังยากขึ้น จึงควรล็อกอินพุตและเก็บ LLM ไว้สำหรับเคสที่ต้องมีเหตุผลประกอบ
• มีจุดอ่อนที่ทราบแล้ว เอกสารของ TypeSafe เองระบุเรื่องคณิตศาสตร์ วันที่ บริบทยาวที่ไม่เกี่ยวข้อง ข้อความโจมตี และความเอนเอียงไปหาตัวเลือกแรก

ข้อคิดส่งท้าย

โมเดลตัดสินใจของ AI นำแนวคิดเก่าแก่เรื่องการให้คะแนนตัวเลือกแทนการสร้างคำตอบมาทำให้ง่ายต่อการใช้งานมากขึ้น

ไม่ต้องมีข้อมูลฝึก ได้คำตอบแบบมีชนิดกลับมา และถามหลายคำถามพร้อมกันได้

ในความเห็นนี้ การแพ็กเกจนี่แหละคือนวัตกรรมจริง

คาดว่าโมเดลตัดสินใจจะวางตัวล้อมรอบ LLM เป็นเกตที่เร็วและถูก จัดการการตัดสินใจง่าย ๆ เพื่อให้โมเดลที่แพงทำงานเฉพาะเมื่อจำเป็นต้องเขียนจริง