AWS กับ Cloudflare แจกโมเดลตัดสินใจให้ AI agent ฟรี

วันที่ 1 ตุลาคม 2026 AWS และ Cloudflare ปล่อย “โมเดลตัดสินใจ” (decision model) แบบเปิดให้โหลดฟรีในวันเดียวกัน ฝั่ง AWS คือ Strands Decider 2B ฝั่ง Cloudflare คือ Clef กับ Clef-flash โมเดลกลุ่มนี้ไม่เขียนคำตอบเป็นข้อความเหมือน LLM ทั่วไป แต่รับสถานการณ์กับตัวเลือกที่เรากำหนดไว้ แล้วตอบกลับเป็นตัวเลือกพร้อมตัวเลขความมั่นใจ เรื่องนี้สำคัญเพราะงานส่วนใหญ่ใน AI agent ไม่ใช่การเขียนยาว ๆ แต่เป็นการตัดสินใจเล็ก ๆ นับร้อยครั้ง (ใช้เครื่องมือไหน ทำต่อหรือหยุด ส่งต่อให้คนไหม) ซึ่งตอนนี้มีโมเดลเฉพาะทางที่ทำได้เร็วและถูกกว่ามาก

สรุปสั้น ๆ: Strands Decider 2B ขนาดราว 1.9B พารามิเตอร์ ใบอนุญาต Apache 2.0 ติดตั้งด้วย pip install strands-decider รันบนการ์ดจอบ้านหรือ Mac ได้ ตอบกลางที่ราว 115 มิลลิวินาทีบน RTX 3090 ส่วน Clef (27B) และ Clef-flash (9B) ของ Cloudflare ก็ Apache 2.0 เช่นกัน มีบน Hugging Face และ Workers AI ตอบกลางที่ 209 และ 38.8 มิลลิวินาทีตามลำดับ ทั้งหมดตามหลังกระแสที่เริ่มจากสตาร์ตอัป TypeSafe AI กับโมเดล Jev และ OpenAI ที่เพิ่งเปิด Decisions API แบบพรีวิว ตัวเลขทุกตัวยังเป็นผลวัดของผู้ผลิตเอง เราเลยลองเองกับข้อความลูกค้าภาษาไทย 30 ข้อ ผลคือ Strands Decider แบ่งงานถูก 47 ถึง 60% เทียบกับ 83% เมื่อส่งข้อความเดียวกันเป็นภาษาอังกฤษ (รายละเอียดอยู่ในหัวข้อ “เราลองกับภาษาไทยแล้ว”)

จุดเริ่มต้น: ทำไมจู่ ๆ ทุกเจ้าถึงมีโมเดลตัดสินใจ

ต้นเรื่องอยู่ที่สตาร์ตอัปชื่อ TypeSafe AI ซึ่งเปิดตัวโมเดล Jev ช่วงกลางเดือนกันยายน 2026 Jev ไม่ได้เก่งเรื่องแต่งข้อความ แต่ถูกออกแบบมาให้ “เลือก” อย่างเดียว นักพัฒนาส่งสถานการณ์กับชุดตัวเลือกไป แล้ว Jev ตอบกลับเป็นความน่าจะเป็นของแต่ละตัวเลือก ราคาถูกและเร็ว TechCrunch รายงานว่าในเดโมงานแฮกกาธอน งานเฝ้าดูการกระทำของ agent ชุดหนึ่งเสียค่าใช้จ่าย 2.94 ดอลลาร์เมื่อใช้ Jev เทียบกับ 372 ดอลลาร์เมื่อใช้ LLM รุ่นท็อป (ตัวเลขนี้เป็นผลเดโม ไม่ใช่เบนช์มาร์กทางการ)

หลังจากนั้นไม่ถึงสองสัปดาห์ OpenAI ก็เปิด Decisions API ที่งาน DevDay ปลายเดือนกันยายน เป็นการเอาโมเดล Luna (รุ่นเล็กสุดและถูกสุดในไลน์อัปปัจจุบัน) มาโฟกัสที่คำถามแบบมีตัวเลือกจำกัด ตอนนี้ยังเป็นพรีวิวแบบจำกัดคน OpenAI ยังไม่ประกาศราคา รูปแบบ request หรือ endpoint ที่แน่นอน

แล้ววันที่ 1 ตุลาคม AWS กับ Cloudflare ก็ปล่อยของตัวเองออกมาพร้อมกัน ต่างจาก OpenAI ตรงที่ ทั้งสองเจ้าแจกน้ำหนักโมเดล (weights) ให้โหลดไปรันเองได้ ภายในสามสัปดาห์ “โมเดลตัดสินใจ” จึงกลายจากไอเดียของสตาร์ตอัปเจ้าเดียว เป็นหมวดใหม่ที่ผู้เล่นใหญ่ลงมาแข่งครบทั้งฝั่ง API ปิดและฝั่งเปิด

โมเดลตัดสินใจทำงานต่างจาก LLM ยังไง

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

โมเดลตัดสินใจตัดขั้นตอนนั้นทิ้ง เราส่งข้อมูลสองส่วน คือ สถานะ (state) หรือบริบทของเรื่อง กับ คำถามแบบมีชนิด (typed question) ซึ่งมีสามแบบเหมือนกันทั้ง Strands Decider และ Clef (ทั้งคู่ทำ interface ให้เข้ากับ Jev)

• choice — เลือกหนึ่งจาก N ตัวเลือก เช่น ส่งให้ทีม billing, sales หรือ retail
• noul — คำถามใช่หรือไม่ใช่ เช่น ข้อความนี้เร่งด่วนไหม
• score — ให้ระดับบนสเกลที่เรียงลำดับ เช่น ความรุนแรง ไม่กระทบ / เล็กน้อย / หนัก / วิกฤต

คำตอบที่ได้กลับมาเป็นตัวเลขล้วน ตัวอย่างใน model card ของ Strands Decider ส่งข้อความลูกค้าที่บ่นว่าการจ่ายเงินล้มเหลวมา 3 วัน โมเดลตอบว่าควรส่งทีม billing ด้วยความน่าจะเป็น 0.846 ข้อความนี้เร่งด่วนที่ 0.829 และระดับความหงุดหงิดน่าจะเป็น “frustrated” ที่ 0.574 โค้ดของเราเอาตัวเลขพวกนี้ไปใช้แตกทางต่อได้ทันที ไม่ต้องแกะข้อความ

เบื้องหลังทางเทคนิคก็ต่างจาก LLM ชัดเจน AWS เอาโมเดลฐาน Qwen3.5-2B-Base มาถอดหัวที่ใช้เดาคำถัดไปออก แล้วใส่ “pointer head” ขนาดราว 1 ล้านพารามิเตอร์ที่ทำหน้าที่ให้คะแนนตัวเลือกแทน บวก LoRA adapter อีกชั้น ส่วน Cloudflare อธิบายว่า Clef อ่านข้อมูลรอบเดียว (prefill) แล้วให้คะแนนทุกตัวเลือกพร้อมกัน ไม่ต้องสร้างข้อความทีละคำ จึงเร็วกว่ามาก

Strands Decider 2B: ตัวเล็ก รันในเครื่องได้

Strands Decider มาจากทีม Strands Labs ของ AWS (ทีมเดียวกับ Strands Agents SDK) จุดเด่นคือเล็กพอจะรันบนเครื่องธรรมดา

สเปกและวิธีใช้

• ขนาด ราว 1.9B พารามิเตอร์ ใบอนุญาต Apache 2.0 ใช้เชิงพาณิชย์ได้
• ติดตั้ง pip install strands-decider มีตัวเลือกสำหรับ CUDA, Mac (MPS) และ CPU
• ใช้งาน ผ่านคำสั่ง strands-decider ask ในเทอร์มินัล หรือเปิดเป็นเซิร์ฟเวอร์ด้วย strands-decider serve แล้วยิง HTTP เข้า /v1/systemone
• ความเร็ว ตาม README บน RTX 3090 ค่ากลางอยู่ที่ 115 มิลลิวินาทีต่อคำถาม (p95 ที่ 299) บน Mac ชิป M3 Pro ค่ากลางราว 153 มิลลิวินาที และบน Apple Silicon ถ้าใช้ MLX จะเร็วกว่า MPS อีกราว 1.4 ถึง 1.6 เท่า
• ความเปิด สคริปต์เทรน แหล่งข้อมูลพร้อมใบอนุญาตของแต่ละชุด และผลรันทุกครั้งอยู่ใน repo ทั้งหมด เทรนซ้ำเองได้ในราว 11 ชั่วโมงบน RTX 3090 ใบเดียว

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

ผลวัดและข้อจำกัดที่ AWS บอกเอง

บน JevBench ชุดสาธารณะ (231 งาน) รุ่น v19 ตอบถูก 167 ข้อ (72.3%) ส่วนรุ่น v21 ที่ตอนนี้เป็นรุ่นอ้างอิงตอบถูก 176 ข้อ (76.2%) แต่ README เตือนเองว่าผลต่างไม่ถึง 10 ข้อระหว่างการรันสองครั้งยัง “สรุปไม่ได้” ถือเป็นความตรงไปตรงมาที่หาได้ยาก

ข้อจำกัดที่ระบุไว้ชัดมีหลายข้อ เอกสารที่ยาวและต้องคิดหลายขั้นทำได้อ่อน (งานระดับยากได้แค่ราว 55%) ถ้อยคำในคำถามมีผล ต้องเขียนให้ความหมายที่ตั้งใจเป็นความหมายที่ชัดที่สุด และค่าความมั่นใจถูกปรับเทียบมากับงานจำแนกสั้น ๆ เท่านั้น AWS บอกว่าบนงานแบบนั้น คำตอบที่มั่นใจ 0.9 ขึ้นไปถูกราว 95% ต่ำกว่านั้นควรยืนยันอีกชั้นหรือส่งให้คน แต่ก็ย้ำว่าต้องวัดกับข้อมูลจริงของเราเองก่อนตั้งเกณฑ์

อีกเรื่องที่ต้องรู้ เซิร์ฟเวอร์ที่มากับแพ็กเกจ ไม่มีระบบยืนยันตัวตน และผูกไว้กับ 127.0.0.1 เท่านั้น เอกสารบอกตรง ๆ ว่าใช้ทดลองในเครื่อง ถ้าจะใช้ในระบบจริงต้องห่อด้วยชั้นความปลอดภัยของเราเอง

มีคนลองบน Mac แล้ว

ทีมนักพัฒนาของ Classmethod ในญี่ปุ่นลองรันบน Mac mini ชิป M4 Pro แรม 24GB ใช้จัดลำดับความยากของคำสั่ง 20 ข้อทั้งภาษาญี่ปุ่นและอังกฤษ ผลที่น่าสนใจ:

• โหลดน้ำหนักโมเดลครั้งแรกราว 4.3GB ใช้หน่วยความจำขณะรัน 5.2GB เปิดใหม่ครั้งต่อไปใช้แค่ 5 วินาที
• ภาษาญี่ปุ่นจัดลำดับถูกช่วง 19 ถึง 20 จาก 20 ข้อ เวลาเฉลี่ย 210 ถึง 379 มิลลิวินาทีต่อข้อ ความแม่นเท่าหรือดีกว่า Jev ในเทสนั้น แต่ช้ากว่า Jev ที่ตอบเฉลี่ยราว 200 มิลลิวินาที (Jev รันผ่าน API และรันแค่รอบเดียว เทียบตรง ๆ ได้ไม่เต็มที่)
• ถ้าไม่ใส่คำอธิบายให้แต่ละตัวเลือก โมเดลจะปฏิเสธคำขอทั้งหมด (HTTP 422) ต้องเขียนคำอธิบายตัวเลือกเสมอ
• รันบน CPU ล้วนก็ได้คำตอบเดิมทุกข้อ แต่ช้าลงราว 10 ถึง 17 เท่า (เฉลี่ยราว 3.5 วินาทีต่อข้อ)

Clef และ Clef-flash: ตัวใหญ่กว่า ดูรูปได้ และมีบริการโฮสต์ให้

Cloudflare เลือกอีกทาง คือทำสองขนาดให้เลือกตามงาน

• Clef สร้างบน Qwen3.8-27B (ล็อกน้ำหนักไว้ไม่เทรนส่วนฐาน) เน้นความแม่น มีตัวเข้ารหัสภาพจึงจำแนกรูปได้ด้วย ซึ่ง Jev ทำไม่ได้
• Clef-flash สร้างบน Qwen3.5-9B เน้นความเร็วสำหรับจุดที่ต้องตอบไว
• ทั้งคู่ใบอนุญาต Apache 2.0 น้ำหนักอยู่บน Hugging Face รองรับบริบท 64k token (Jev รองรับ 32k) และเรียกใช้แบบโฮสต์บน Workers AI ได้ทันที โดย Cloudflare ยืนยันว่าไม่อ่าน ไม่เก็บ และไม่เอาข้อมูลไปเทรน เว้นแต่ลูกค้าเลือกเข้าโปรแกรมปรับจูนเอง

ตัวเลขที่ Cloudflare วัดเอง

ด้านความเร็ว ค่ากลางของ Clef อยู่ที่ 209.3 มิลลิวินาที Clef-flash 38.8 มิลลิวินาที ส่วน Jev อยู่ที่ 524.1 มิลลิวินาที ด้านความแม่น Clef ชนะ Jev ในหลายชุด เช่น จำแนกเจตนาลูกค้าธนาคาร (BANKING77) ได้ 94.20 เทียบ 79.74 แต่ก็ ไม่ได้ชนะทุกอย่าง Jev ยังนำในชุดที่วัดว่าควรเรียกเครื่องมือตอนไหน (When2Call 80.97 เทียบ 72.37) และในงานเฝ้าดู trace ของ agent ส่วน Clef-flash ตกไปเหลือ 66.77 ในชุด CLINC150 แปลว่าตัวเร็วแลกมากับความแม่นในบางงานจริง

ตัวอย่างใช้งานจริงที่ Cloudflare เล่า คือทีม Threat Intelligence ใช้ Clef จำแนกโดเมน เปิดหน้าเว็บ เรนเดอร์ แล้วตัดสินว่าเป็นร้านแฟชั่นหรือเว็บฟิชชิง ทั้งกระบวนการใช้ 2.2 วินาที เทียบกับ gpt-oss-120b ที่ใช้ 4.7 วินาทีและได้คำตอบน้อยกว่า

Cloudflare ยังประกาศบริการปรับจูนด้วย reinforcement learning ให้ลูกค้าเอา Clef ไปปรับกับข้อมูลของตัวเอง ระยะแรกเป็นบริการที่ทีมวิศวกรทำให้ ระยะต่อไปจะเป็นแบบบริการตัวเอง แต่ในโพสต์ยังไม่บอกราคาทั้งการเรียกใช้และการปรับจูน และบอกเองว่าผลิตภัณฑ์ยัง “อยู่ช่วงแรก”

เราลองกับภาษาไทยแล้ว: ถูกแค่ราวครึ่งเดียว

ไม่มีผู้ผลิตรายไหนวัดภาษาไทยให้ดู เราเลยลองเองบน MacBook ชิป M5 แรม 32GB ติดตั้งตามเอกสารด้วย pip คำสั่งเดียว แล้วทดสอบทั้งรุ่น v21 (รุ่นอ้างอิงปัจจุบัน) และ v19

วิธีทดสอบ

• ข้อความลูกค้าร้านออนไลน์ภาษาไทย 30 ข้อ เขียนแบบที่คนพิมพ์จริงในแชต มีคำลงท้ายอย่าง “คะ” “น้า” “เนี่ย” มีคำเฉพาะอย่างพร้อมเพย์ เคอรี่ PDPA และ สคบ. ปนอยู่ ทุกข้อมีคำแปลภาษาอังกฤษไว้เป็นตัวเทียบ
• ถาม 3 อย่างต่อข้อความ ควรส่งให้ทีมไหน (เลือกจาก 6 ทีม คือ ชำระเงิน จัดส่ง สอบถามสินค้า เปลี่ยนคืน บัญชี และเรื่องอื่น ๆ โดยเขียนคำอธิบายให้ทุกทีม) ต้องรีบจัดการภายในไม่กี่ชั่วโมงไหม และลูกค้าไม่พอใจแค่ไหน (ใจเย็น / ไม่พอใจ / โกรธมาก)
• เฉลยเขียนไว้ก่อนรัน ไม่ได้ปรับตามผลทีหลัง และลองสามแบบ คือ ข้อความไทยกับคำถามอังกฤษ ข้อความไทยกับคำถามไทย และข้อความอังกฤษล้วนเป็นตัวเทียบ

ผลที่ได้ (รุ่น v21)

• แบ่งงานถูกทีม ข้อความไทยกับคำถามอังกฤษได้ 47% ข้อความไทยกับคำถามไทยได้ 60% ส่วนข้อความอังกฤษได้ 83% (รุ่น v19 ได้ใกล้กัน คือ 43% / 63% / 90%)
• ไม่เข้าใจก็โยนเข้า “เรื่องอื่น ๆ” ตอนใช้คำถามอังกฤษ โมเดลส่งข้อความไทยเข้าทีมเรื่องอื่น ๆ ถึง 18 จาก 30 ข้อ เช่น “ตัดบัตรเครดิตไป 2 รอบค่ะ” ซึ่งฉบับภาษาอังกฤษตอบถูกว่าเป็นเรื่องชำระเงิน
• ตัดตัวเลือกเรื่องอื่น ๆ ทิ้งก็ยังไม่ดีขึ้นมาก เหลือ 5 ทีม 26 ข้อ ข้อความไทยได้ 58 ถึง 69% ขณะที่ภาษาอังกฤษได้ครบ 100% แปลว่าปัญหาไม่ใช่แค่การหนีไปตอบตัวเลือกกลาง ๆ แต่โมเดลอ่านภาษาไทยได้ไม่ดีจริง
• คำถามภาษาไทยช่วยได้นิดหน่อย แบ่งทีมดีขึ้นจาก 47% เป็น 60% แต่ตอนวัดอารมณ์ลูกค้ากลับตอบว่า “ไม่พอใจ” แทบทุกข้อ (27 จาก 30) ส่วนการดูความเร่งด่วนได้ราว 60% ทั้งสองแบบ เทียบกับ 77% ในภาษาอังกฤษ
• ความเร็วไม่ต่างกัน ถามคำถามเดียวใช้ราว 95 มิลลิวินาทีทั้งไทยและอังกฤษ ถามสามคำถามพร้อมคำอธิบาย 6 ทีมใช้ราว 430 มิลลิวินาที และขึ้นเป็นราว 690 มิลลิวินาทีถ้าคำอธิบายเป็นภาษาไทย เพราะข้อความไทยแตกเป็นโทเคนมากกว่า รันซ้ำแล้วได้คำตอบเดิมทุกข้อ

ข่าวดีที่ซ่อนอยู่: ความมั่นใจไม่โกหก

ตัวเลขความมั่นใจของโมเดลตรงไปตรงมากับภาษาไทย ค่ากลางของความมั่นใจในการเลือกทีมอยู่ที่ราว 0.3 ถึง 0.4 สำหรับข้อความไทย เทียบกับ 0.73 ในภาษาอังกฤษ และทุกข้อที่มั่นใจตั้งแต่ 0.9 ขึ้นไปตอบถูกหมดทั้งสองภาษา ถ้าตั้งระบบตามที่ AWS แนะนำ (มั่นใจ 0.9 ขึ้นไปทำต่ออัตโนมัติ ต่ำกว่านั้นส่งให้คน) จะไม่มีข้อความไทยถูกส่งผิดทีมเลย แต่ก็จะมีแค่ 1 ถึง 2 ข้อจาก 30 ที่ผ่านเกณฑ์ ที่เหลือต้องให้คนดูเองทั้งหมด ซึ่งก็คือแทบไม่ได้ช่วยประหยัดแรงอะไร

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

ข้อควรระวังก่อนตื่นเต้น

• ตัวเลขเกือบทั้งหมดมาจากผู้ผลิตเอง ทั้งของ AWS และ Cloudflare ยังไม่มีผลทดสอบอิสระชุดใหญ่ และ JevBench เองก็เปลี่ยนเวอร์ชันบ่อยจนคะแนนข้ามเวอร์ชันเทียบกันไม่ได้
• ข้อความที่ agent อ่านเข้ามาบิดคำตัดสินได้ นักวิเคราะห์หลายคนเตือนว่า ถ้า state มีข้อความที่ผู้ไม่หวังดีแทรกมา (prompt injection) โมเดลตัดสินใจก็โดนหลอกได้เหมือน LLM จึงไม่ควรใช้เป็นด่านความปลอดภัยด่านเดียว
• ถูกหรือไม่ถูกต้องคิดค่าเครื่องเอง การรันเองไม่มีค่า API แต่มีค่าฮาร์ดแวร์และคนดูแล ยังไม่มีใครแสดงตัวเลขชัด ๆ ว่ารันเองถูกกว่าบริการโฮสต์ที่ระดับปริมาณงานเท่าไร
• ภาษาไทยยังอ่อน ข้อมูลเทรนส่วนใหญ่เป็นภาษาอังกฤษ ผลภาษาญี่ปุ่นที่ดีไม่ได้แปลว่าภาษาไทยจะดีตาม ผลที่เราลองเองอยู่ในหัวข้อด้านบน

วิเคราะห์: agent กำลังแยกเป็นสมองช้ากับสมองเร็ว

ชื่อ endpoint ของ Strands Decider คือ /v1/systemone ซึ่งยืมคำมาจากแนวคิด “ระบบ 1 / ระบบ 2” ของนักจิตวิทยา Daniel Kahneman ระบบ 1 คือการตัดสินใจเร็วแบบอัตโนมัติ ระบบ 2 คือการคิดช้าอย่างตั้งใจ ภาพที่ทุกเจ้ากำลังวาดตรงกันคือ agent ในอนาคตจะมีสองชั้น LLM ตัวใหญ่ทำงานที่ต้องคิดจริง ส่วนการตัดสินใจเล็ก ๆ ระหว่างทางยกให้โมเดลตัวเล็กที่เร็วและบอกได้ว่ามั่นใจแค่ไหน

กระทบนักพัฒนาและคนทำ agent ยังไง

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

นี่คือชิ้นส่วนของสิ่งที่เรียกว่า harness หรือ “บังเหียน” รอบ agent ซึ่งเป็นเรื่องที่เราเล่าไว้ในข่าว Claude Code เปิดให้ Mod ได้ และบทความ ทำไม AI agent ถึงพังเมื่อปล่อยทำงานลำพัง ปัญหาหลักของ agent ไม่ใช่โมเดลโง่ แต่คือไม่มีด่านกั้นที่ดีพอระหว่างทาง โมเดลตัดสินใจทำให้การวางด่านแบบนั้นถูกและเร็วพอจะวางได้ทุกจุด ไม่ใช่วางเฉพาะจุดที่คุ้มค่าเรียก LLM

กระทบคนไทยและองค์กรไทยโดยเฉพาะ

• ข้อมูลไม่ต้องออกนอกบ้าน โมเดลที่รันในเครื่องได้หมายความว่าข้อความลูกค้า เอกสารภายใน หรือ log ของระบบ ไม่ต้องส่งไป API ต่างประเทศเพื่อแค่ตัดสินว่า “ส่งให้ทีมไหน” ช่วยเรื่อง PDPA และการเก็บข้อมูลในประเทศได้ตรง ๆ แนวคิดเดียวกับที่เราเขียนไว้ในเรื่อง Local AI
• SME ทำ agent ได้ถูกลง งานคัดแยกแชตลูกค้า จัดคิวเรื่องร้องเรียน หรือคัดอีเมลเข้าแผนก เป็นงาน “เลือก” ล้วน ๆ ตัว 2B ที่รันบน Mac หรือพีซีการ์ดจอเกมได้ ทำให้ร้านเล็กเริ่มได้โดยไม่ต้องจ่ายค่า API ตามจำนวนข้อความ
• ภาษาไทยคือด่านใหญ่ตอนนี้ ผลที่เราลองเองบอกว่าตัว 2B แบบสำเร็จรูปแบ่งแชตลูกค้าไทยถูกแค่ราวครึ่งเดียว ร้านไทยที่อยากใช้ต้องมองไปที่การปรับจูนด้วยข้อความไทยของตัวเอง (AWS เปิดสคริปต์เทรนไว้ เทรนซ้ำได้ในราว 11 ชั่วโมงบน RTX 3090 ใบเดียว) หรือรอดูว่า Clef ที่ตัวใหญ่กว่าทำภาษาไทยได้ดีกว่าไหม ระหว่างนี้งานแยกแชตภาษาไทยยังต้องพึ่ง LLM ตัวใหญ่ไปก่อน
• Clef บน Workers AI ยังไม่มีราคา ใครจะใช้แบบโฮสต์ต้องรอดูราคาก่อนวางงบ ส่วนรุ่น 27B ถ้าจะรันเองต้องใช้การ์ดจอหน่วยความจำสูง ไม่ใช่ของสำหรับเครื่องทั่วไป

ควรเตรียมหรือปรับตัวอะไร

• หาจุดที่ใช้ LLM ตัวใหญ่ตอบคำถามแบบมีตัวเลือก ในระบบของคุณ เช่น prompt ที่ลงท้ายว่า “ตอบแค่ใช่หรือไม่” หรือ “เลือกหนึ่งในหมวดต่อไปนี้” จุดพวกนี้คือผู้สมัครอันดับแรกที่จะย้ายไปใช้โมเดลตัดสินใจ
• เริ่มเก็บข้อมูลการตัดสินใจของ agent ไว้ตั้งแต่วันนี้ เก็บ state คำถาม และคำตอบที่ถูกต้อง แม้แค่ 50 ถึง 100 ตัวอย่างภาษาไทยก็พอใช้เป็นชุดทดสอบเทียบโมเดลได้ และถ้าวันหนึ่งจะปรับจูนก็มีข้อมูลพร้อม
• ลองกับข้อความของคุณเองก่อนเชื่อตัวเลขใด ๆ ติดตั้งด้วย pip คำสั่งเดียว ใช้เวลาไม่ถึงชั่วโมง ถ้างานเป็นภาษาอังกฤษ (เช่น log ระบบ หรืองานลูกค้าต่างประเทศ) ใช้ได้ดีตั้งแต่ตอนนี้ ถ้าเป็นภาษาไทย ให้คาดไว้ก่อนว่าต้องปรับจูน
• ออกแบบเกณฑ์ความมั่นใจคู่กับทางหนี อย่าให้โมเดลตัดสินใจตัดสินทุกอย่างเอง ตั้งเกณฑ์ว่าต่ำกว่าเท่าไรต้องส่งต่อ LLM ตัวใหญ่หรือคน และวัดเกณฑ์นั้นกับข้อมูลจริง ไม่ใช่ใช้ตัวเลขจากเอกสาร
• อย่าเปิดเซิร์ฟเวอร์ทดลองออกอินเทอร์เน็ต และอย่าใช้โมเดลตัดสินใจเป็นด่านความปลอดภัยด่านเดียว ให้มองเป็นชั้นเสริมที่ทำงานคู่กับกติกาแบบเขียนโค้ดตายตัว
• จับตาราคา Decisions API ของ OpenAI กับ Workers AI เมื่อประกาศเมื่อไร ค่อยคำนวณว่างานของคุณคุ้มกว่าที่จะเช่าหรือรันเอง

หมวด “โมเดลตัดสินใจ” เพิ่งเกิดไม่ถึงเดือน ยังไม่มีผู้ชนะและตัวเลขยังขยับทุกสัปดาห์ แต่ทิศทางชัดแล้วว่า agent ที่ดีจะไม่ได้มีแค่โมเดลฉลาดตัวเดียว แต่มีโครงสร้างรอบตัวที่ตัดสินใจเรื่องเล็กได้เร็ว รู้ว่าตัวเองมั่นใจแค่ไหน และรู้ว่าเมื่อไรควรส่งต่อให้คน ใครเริ่มคิดเรื่องนี้ก่อนจะได้เปรียบตอนเครื่องมือนิ่งแล้ว อ่านพื้นฐานของ agent เพิ่มได้ที่ AI agent ทำงานยังไง ส่วนรายละเอียดทางเทคนิคดูได้ที่ model card ของ Strands Decider และบล็อกของ Cloudflare ที่ลิงก์ไว้ด้านล่าง