คะแนน Benchmark ของ LLM ที่คุณต้องการนั้นไม่มีอยู่จริง
Leaderboard ของ LLM ส่วนใหญ่กำลังหลอกคุณ
เมื่อเดือนที่แล้ว ผมได้ประเมินโมเดลสำหรับ agentic pipeline ผมต้องการความสามารถในการสร้างโค้ด (code generation) และการใช้เหตุผลแบบหลายขั้นตอน (multi-step reasoning) ผมจึงเลือกโมเดลที่อยู่อันดับต้นๆ บน leaderboard ยอดนิยมตัวหนึ่ง แล้วนำไปใช้งานจริง แต่ปรากฏว่ามันล้มเหลวในงานพื้นฐานอย่างการใช้เครื่องมือ (tool-use)
คะแนนบน leaderboard นั้นเป็นของจริง แต่มันกลับไร้ประโยชน์สำหรับงานของผม
Public benchmarks ทดสอบโมเดลแบบแยกส่วน แต่ในการใช้งานจริง (production) คุณต้องรัน agents ซึ่ง agents จะต้องเรียกใช้เครื่องมือ, ค้นหาข้อมูลบนเว็บ และรันโค้ด ซึ่ง benchmark มาตรฐานไม่ได้วัดผลในส่วนนี้
รายงานจาก LXT แสดงให้เห็นถึงช่องว่างขนาดใหญ่ ในเดือนกุมภาพันธ์ 2026 เมื่อมีการเข้าถึงเครื่องมือ (tool access) คะแนนเป็นดังนี้:
• Claude Opus 4.6: 53.1% • GPT-5.3 Codex: 36% • GLM-5: 32%
หากไม่มีการเข้าถึงเครื่องมือ คะแนนเหล่านี้จะลดลง ช่องว่างระหว่างคะแนนแบบที่มีเครื่องมือช่วย (tool-assisted) กับแบบที่ไม่มีเครื่องมือ คือตัวชี้วัดเดียวที่มีความสำคัญสำหรับ agents
โมเดลที่ชนะในการทดสอบความรู้ทั่วไป (trivia) หรือการทดสอบแบบคงที่ (static tests) มักจะล้มเหลวแม้แต่ในการเขียน function call เพียงครั้งเดียว
หากคุณกำลังสร้าง agents ให้มุ่งเน้นไปที่ 3 ด้านนี้:
- ความน่าเชื่อถือในการเรียกใช้เครื่องมือ (Tool call reliability): โมเดลสามารถจัดรูปแบบการเรียกใช้ได้อย่างถูกต้องแม้จะมีสิ่งรบกวนหรือไม่? และสามารถกู้คืนจากข้อผิดพลาดได้หรือไม่?
- ความคุ้มค่าของ Context window: การตั้งค่าเครื่องมือบางอย่างอาจใช้ token มากขึ้นถึง 10 ถึง 32 เท่า Context window ขนาดใหญ่จะกลายเป็นเรื่องสิ้นเปลืองทันทีหากมันเผาผลาญงบประมาณของคุณในทุกๆ การเรียกใช้งาน
- การวางแผนแบบหลายขั้นตอน (Multi-step planning): โมเดลสามารถรักษาแผนการ 5 ขั้นตอนไว้ได้หรือไม่? โมเดลหลายตัวมักจะหลุดประเด็นตั้งแต่ขั้นตอนที่ 3
เลิกใช้ public leaderboards เป็นแนวทางเดียวของคุณ และลองทำสิ่งนี้แทน:
• ทำ mini-benchmark: ใช้การเรียกใช้เครื่องมือจริง 20 ถึง 50 ครั้งจาก log ของคุณเอง เพื่อวัดความแม่นยำตาม schema เฉพาะของคุณ • ทดสอบสภาวะที่เกิดข้อผิดพลาด (Error conditions): ดูว่าโมเดลมีปฏิกิริยาอย่างไรเมื่อเครื่องมือส่งคืนข้อผิดพลาดหรือข้อมูลว่างเปล่า • วัดต้นทุนต่อภารกิจ: โมเดลที่เก่งกว่า 5% แต่แพงกว่า 3 เท่า มักจะเป็นทางเลือกที่ผิด • ใช้ leaderboard เฉพาะทาง: ให้ดูคะแนนด้าน tool-use และ coding agent บน BenchLM.ai แทนที่จะดูอันดับโดยรวม
โมเดลที่อยู่อันดับ #3 อาจจะสมบูรณ์แบบสำหรับการเขียน prompt เพียงครั้งเดียว แต่อาจจะเป็นหายนะสำหรับการใช้งานเป็น agent
สละเวลาสักบ่ายหนึ่งเพื่อทดสอบเครื่องมือของคุณเอง มันจะช่วยประหยัดเวลาในการแก้บั๊ก (debugging) ได้เป็นสัปดาห์ในภายหลัง
คุณมีวิธีการประเมินโมเดลของคุณอย่างไร? บอกให้ผมรู้ในคอมเมนต์ได้เลย
ชุมชนแห่งการเรียนรู้ (ไม่บังคับ): https://t.me/GyaanSetuAi