เมื่อวันที่ 6 กรกฎาคม 2026 มีบทความปรากฏใน ITmedia
"อุปสรรคของการใช้ AI กำลังเปลี่ยนจากประสิทธิภาพของโมเดลไปสู่ 'การประเมินผล' 'การกำกับดูแล' และ 'ความคุ้มค่าด้านต้นทุน'" โจนาธาน แฟรงเคิล หัวหน้านักวิทยาศาสตร์ AI ของ Databricks และผู้ร่วมก่อตั้ง MosaicML กล่าว
ข้อโต้แย้งของเขานั้นเรียบง่าย:
- AI ฉลาดพออยู่แล้ว การแค่คิดถึงวิธีใช้โมเดลที่มีอยู่ก็เหลือ "งานอีกหลายสิบปี"
- สิ่งที่จำเป็นสำหรับการนำ AI ไปใช้ให้ดีขึ้นไม่ใช่การพัฒนาโมเดลที่ฉลาดขึ้น แต่คือ การลงทุนในการประเมินผลและการกำกับดูแล
- AI "ยังไม่พอที่ความแม่นยำ 70% หรือ 90%" มันต้องการ การประเมินผลที่เข้มงวดมากขึ้นอีกหลายเท่า
- และความท้าทายที่ใหญ่ที่สุดคือ การแปลมาตรฐานของมนุษย์ว่า "งานที่ดีคืออะไร" ให้เป็นรายการตรวจสอบ ซึ่ง "ยากกว่าการพัฒนาโมเดลยักษ์ตัวต่อไปมาก และอาจใช้เวลามากกว่า 10 ปี"
เมื่ออ่านสิ่งนี้ ฉันรู้สึกสะกิดใจอย่างแรง
ช่วงนี้ฉันกำลังทดลองวัด "ปริมาณการใช้งาน" AI อยู่ ฉันมีแดชบอร์ดที่ดึงข้อมูลเทเลเมทรีการใช้งาน "Databricks" x "Claude Code/Codex/Cowork" ผ่าน OpenTelemetry เข้าสู่ Databricks และอัปเดตทุกเช้าว่า "ใครใช้เครื่องมือไหน เท่าไหร่ และเสียค่าใช้จ่ายเท่าไหร่"
แต่ประเด็นของบทความไม่ใช่สิ่งนั้น "งานนั้นดีไหม?" — การประเมินคุณภาพของ Agent เป็นช่องโหว่ขนาดใหญ่
ฉันให้บทความกับ Fable และถามว่า "ลองคิดดูว่าเราควรประเมินอะไร"
ดังนั้น ฉันจึงให้ URL ของบทความกับ Claude (Fable 5) ซึ่งฉันใช้เป็นประจำ แล้วถามว่า:
อ่านบทความนี้แล้วลองคิดดูว่าเราควรประเมินอะไรบ้าง
หลังจากตรวจสอบโครงสร้างพื้นฐานบันทึกภายในและการกำหนดค่าแดชบอร์ดของเรา Fable ก็ได้ออกแบบที่ประกอบด้วย "สามชั้นของสิ่งที่ต้องประเมิน"
คำตอบของ Fable: สามชั้นของ "สิ่งที่ต้องประเมิน"
คำแนะนำด้านล่าง """""""""""""""""""""""""""""""""
ชั้นที่ 1: สัญญาณความเสียดทาน (รายวัน, ทุกคน, การตัดสินเชิงกล)
มี "สัญญาณของคุณภาพต่ำ" ที่สามารถตรวจจับได้โดยอัตโนมัติจากบันทึก โดยไม่ต้องถาม LLM ด้วยซ้ำ
- สงสัยว่าติดลูป: ใช้เครื่องมือเดียวกันมากกว่า 5 ครั้งติดต่อกัน
- ต้นทุนผิดปกติ: ใช้เงินเกิน $5 ในเซสชันเดียว
- ความถี่ในการบล็อก: หยุดหลายครั้งเพื่อรอการยืนยันจากมนุษย์
- ประสิทธิภาพแคช: การใช้บริบทซ้ำไม่ดี (เช่น อ่านซ้ำทุกครั้ง)
- การเชื่อมต่อเครื่องมือล้มเหลว: ล้มเหลวในการเชื่อมต่อกับเซิร์ฟเวอร์ MCP อย่างต่อเนื่อง
ชั้นที่ 2: คุณภาพงาน (รายสัปดาห์, LLM Judge)
สร้างระบบที่ส่งบันทึกการทำงานของ AI Agent (traces) ไปยัง LLM Judge เพื่อให้คะแนนใน 8 แกน
- การบรรลุเป้าหมาย / ความแม่นยำ / การเลือกเครื่องมือ / ความสอดคล้องกับหลักฐาน / ความถูกต้องของขั้นตอน / การกู้คืนจากความล้มเหลว / ความปลอดภัย / ประสิทธิภาพ
- ผ่านหากคะแนนเฉลี่ย 3.5 หรือสูงกว่า อย่างไรก็ตาม หาก "การบรรลุเป้าหมาย" หรือ "ความปลอดภัย" ได้ 2 หรือต่ำกว่า ให้ถือว่า ล้มเหลวทันที (hard fail) แม้ว่าคะแนนอื่นจะสมบูรณ์แบบก็ตาม
ให้คะแนนเซสชันล่าสุดโดยอัตโนมัติทุกคืนวันอาทิตย์ เพื่อให้ "อัตราการผ่านประจำสัปดาห์" ปรากฏในการประชุมประจำวันจันทร์ เฉพาะการแจ้งเตือนกรณีความปลอดภัยล้มเหลวเท่านั้นที่จะส่งอีเมลแจ้งเตือนในเช้าวันถัดไป
ชั้นที่ 3: ทำให้การประเมินผลเป็นผลิตภัณฑ์
งานที่บทความบอกว่า "ใช้เวลา 10 ปี" — "การแปลเกณฑ์สำหรับงานที่ดีให้เป็นรายการตรวจสอบ" — คือสิ่งที่เราควรมอบให้ลูกค้าในฐานะที่ปรึกษา AI และผู้ฝึกอบรมองค์กร แดชบอร์ดที่ทำงานภายในก็กลายเป็นตัวอย่างการขายได้ทันที
"""""""""""""""""""""""""""""""""
และมันก็ถูกนำไปใช้ในวันเดียวกันนั้น
นี่คือส่วนที่น่าทึ่งของยุค Agent: ทั้งสามชั้น เริ่มทำงานในวันนั้นเอง
- มุมมอง SQL สำหรับชั้นที่ 1 ถูกเพิ่มเป็นแท็บ "คุณภาพ" ในแดชบอร์ดองค์กรและเผยแพร่
- การทำงานรายสัปดาห์สำหรับชั้นที่ 2 ถูกกำหนดเวลา และการแจ้งเตือนด้านความปลอดภัยถูกรวมเข้ากับระบบตรวจสอบ
- เอกสารการออกแบบข้อเสนอสำหรับชั้นที่ 3 ถูกบันทึกไว้
สิ่งที่ฉันทำคือเลือกนโยบาย คลิกปุ่มอนุมัติสองสามครั้ง และรันคำสั่งลงทะเบียนตัวกำหนดเวลาหนึ่งครั้ง
"พบ" ในวันแรก
และในวันแรกของการดำเนินการ ก็มีการค้นพบทันทีสองอย่าง
อย่างแรก: เรากำลังแพ้อย่างยับเยินเมื่อวัดผล
เมื่อเราให้คะแนนเซสชัน Agent ภายใน 8 เซสชันล่าสุดโดยใช้ Judge 8 แกน ผลลัพธ์คือ — ผ่าน 1 ครั้ง, ล้มเหลว 7 ครั้ง มีช่องว่างระหว่าง "การให้ AI ทำงานเยอะ" กับ "AI ทำงานที่ดี" ซึ่งจะมองเห็นได้ก็ต่อเมื่อวัดผลแล้วเท่านั้น
อย่างที่สอง: พบ "ความเสียดทานที่แก้ไขได้หากสอน"
ใน Cowork (พื้นที่ทำงาน Agent ของ Claude) ของสมาชิกคนหนึ่ง แดชบอร์ดตรวจพบว่า การเชื่อมต่อเซิร์ฟเวอร์ MCP ล้มเหลวเพิ่มขึ้นจาก 4 ครั้งในวันก่อนหน้าเป็น 12 ครั้งในวันนั้น การรับรองความถูกต้องของปลั๊กอินเสียหายเป็นเวลาสองวันแล้ว และพวกเขาก็ยังคงใช้มันต่อไป
คนๆ นั้นอาจจะแค่คิดว่า "มันดูแปลกๆ นิดหน่อย" แล้วก็ทำงานต่อไป มันแก้ไขได้ภายใน 5 นาทีโดยการพูดออกมาและแก้ไขการรับรองความถูกต้อง "ความเสียดทานที่แก้ไขได้หากสอน" สะสมโดยไม่มีใครรายงาน — นี่คือสิ่งที่ไม่มีวันมองเห็นได้บนแดชบอร์ดการใช้งาน
สามสิ่งที่ฉันเรียนรู้จากการลองทำ
1. การประเมินผลคือการดำเนินการ ไม่ใช่เครื่องมือ
ถ้าคุณแค่สร้างกลไกการให้คะแนนแล้วหยุด มันก็เหมือนกับไม่ได้มี มันจะถือว่าคุณ "กำลังประเมิน" ก็ต่อเมื่อคุณเชื่อมต่อมันเข้ากับการทำงานประจำสัปดาห์และการแจ้งเตือน และตัวเลขปรากฏในการประชุมวันจันทร์ "การลงทุนในการประเมินผล" ที่แฟรงเคิลพูดถึงน่าจะเกี่ยวกับการดำเนินการ ไม่ใช่เครื่องมือ
2. วางชั้นการตัดสินเชิงกลไว้ก่อน LLM Judge
การประเมินด้วย Judge 8 แกนนั้นทรงพลัง แต่ต้องใช้เวลาและเงินเพราะต้องรัน LLM การรันสัญญาณเชิงกำหนด เช่น ลูป ต้นทุนผิดปกติ และการเชื่อมต่อล้มเหลวแบบเต็มปริมาณทุกวัน และใช้ Judge สำหรับการสุ่มตัวอย่างรายสัปดาห์นั้นเป็นเรื่องที่ทำได้จริง
3. การนำ "90% ยังไม่พอ" ไปใช้หมายถึงการล้มเหลวทันที
เมื่อดูคะแนนเฉลี่ย ปัญหาด้านความปลอดภัยจะถูกกลบด้วยคะแนนอื่นๆ เฉพาะเมื่อออกแบบให้ "ถ้าความปลอดภัยได้ 2 หรือต่ำกว่า ให้ถือว่าล้มเหลวแม้คะแนนอื่นจะสมบูรณ์" เราจึงจะก้าวเข้าใกล้ "การประเมินผลที่เข้มงวดมากขึ้นอีกหลายเท่า" ที่กล่าวถึงในบทความ อัตราการผ่าน 1/8 นั้นเจ็บปวด แต่ความเจ็บปวดนี้คือจุดเริ่มต้นของการปรับปรุง
บทสรุป
"AI ฉลาดพออยู่แล้ว"
— นั่นคือเหตุผลที่การต่อสู้ครั้งต่อไปคือ ใครเป็นคนให้คะแนนงานที่มอบหมายให้ AI ที่ฉลาด และทำอย่างไร
แฟรงเคิลบอกว่านี่คืองาน 10 ปี
สิ่งที่ใช้เวลา 10 ปีจะกลายเป็นตัวสร้างความแตกต่าง ยิ่งคุณเริ่มเร็วเท่าไหร่ก็ยิ่งดี และการเริ่มต้นนั้นเป็นไปได้ในวันเดียวด้วย AI Agent
ที่บริษัทของฉัน (AI Brain Partners) เราช่วยสร้างระบบ "การวัดและการประเมินผลการใช้งาน AI" นี้ผ่านการฝึกอบรมองค์กรที่เชี่ยวชาญด้าน Claude Code และการให้คำปรึกษา AI หากคุณกำลังสงสัยว่า "จริงๆ แล้วการใช้ AI ของเราเป็นอย่างไร?" โปรดตรวจสอบลิงก์ด้านล่าง
- การฝึกอบรม AI Agent สำหรับองค์กร: https://ai-agent.camp/ja/lab/corporate-training
- รายงานฟรี "วิธีนำ AI เข้าสู่องค์กร": https://ai-agent.camp/ja/lab/whitepaper-ai-enterprise
(บทความต้นฉบับ: ITmedia AI+ "อุปสรรคของการใช้ AI กำลังเปลี่ยนไปสู่การประเมินผลและการกำกับดูแล" 6 กรกฎาคม 2026)
