หลังจากเลี้ยงโมเดล thai-chat (qwen38) บนเครื่องของทีมได้สักพัก คำถามที่ต้องตอบให้ได้ด้วยตัวเลขคือ "มันดีพอแทน z.ai จริงไหม" คำตอบแบบไม่มีตัวเลขไม่มีสิทธิ์พูด เลยจัดชุดทดสอบเต็ม 50 เคส 5 หมวด รันคู่ทั้งสองระบบ แล้วให้โมเดลตัดสินคะแนนแบบไม่รู้ว่าข้อไหนมาจากใคร
วิธีทดสอบ
- ฝั่ง bomLLM: โมเดล thai-chat ผ่าน llm.siam2r.com (router LiteLLM บนเครื่องเรา)
- ฝั่งคลาวด์: glm-4.5-flash ตรงผ่าน API ของ z.ai (ปิด thinking, max_tokens 2000 ตามงบ)
- 5 หมวด หมวดละ 10 เคส: LINE Q&A ภาษาไทย, สรุปสัญญาณ (RAGSA), ตัวจำแนกหมวด, แปลภาษา, และ edge cases แบบ format เข้มงวด
- ตัวตัดสินหลัก: โมเดล qwen38 ให้คะแนน 1–10 ต่อเคส และมี Gemini 2.5 Flash เป็นตัวตัดสินข้าม (cross-grader) ใน 18 เคสที่โควตาเหลือ
ผลคะแนนรวม
| หมวด | bomLLM | z.ai | ratio |
|---|---|---|---|
| LINE Q&A (ไทย) | 8.93 | 6.33 | 1.41 |
| สรุปสัญญาณ RAGSA | 8.53 | 5.80 | 1.47 |
| ตัวจำแนกหมวด | 1.00 (accuracy) | 1.00 | เสมอ |
| แปลภาษา | 9.63 | 8.50 | 1.13 |
| Edge cases (JSON เข้มงวด) | 8.10 | 8.47 | 0.96 |
| รวม 50 เคส | 7.24 | 6.02 | 1.20 |
ด้านความเร็วห่างกันยิ่งกว่า: bomLLM p50 = 5.19 วินาที (p95 = 19.9) ส่วน z.ai p50 = 35.1 วินาที (p95 = 85.6) — เร็วกว่าราว 7 เท่าที่ค่ากลาง และอัตรา error ของ bomLLM อยู่ที่ 2/50 เคส (ทั้งคู่เป็น format เข้มงวดที่ runtime เกิน 30 วินาที)
สิ่งที่ต้องซื่อสัตย์กับตัวเอง
benchmark นี้มีจุดที่ต้องอ่านให้ดีก่อนเอาไปใช้ตัดสินใจใหญ่:
- ตัวตัดสินกับผู้เข้าแข่งเป็นสายเดียวกัน — qwen38 ตัดสินคำตอบ qwen38 ย่อมเอื้อ ตัวเลข subset ที่ Gemini ตัดสินเองลดลงเหลือ ratio 1.28 ซึ่งยังชนะ แต่ไม่โหดแบบ 1.44
- prompt ทดสอบสั้น (~310 tokens) — งานจริงที่ส่ง context ยาวหลายพัน tokens เป็นอีกเรื่อง เราเจอกรณีจริงที่ prompt 7,000 tokens ทำให้เครื่อง local ช้าเกินขีด 90 วินาทีของ EA จนต้องย้อนกลับไปใช้คลาวด์ (อ่านบทความ prompt 6,928 tokens ประกอบ)
- Edge cases คือจุดอ่อนจริง — เคส JSON เข้มงวดและปนภาษา คือหมวดเดียวที่แพ้ (0.96) งาน format ตายตัวควร route ไป fallback
สรุปสำหรับทีมเรา
สำหรับงานแชทภาษาไทย สรุปสัญญาณ และการแปล — bomLLM บนเครื่องเราชนะขาดทั้งคุณภาพและความเร็ว โดยไม่มีค่าใช้จ่ายต่อ token ส่วนงานที่ prompt ยาวเกิน 3–4K tokens หรือ format เข้มงวดผิดไม่ได้ เส้นทางที่ปลอดภัยที่สุดในตอนนี้คือคลาวด์ + fallback สลับกันตามชนิดงาน ซึ่งเป็นสถาปัตยกรรมที่เราตั้งไว้บน router อยู่แล้ว
การตัดสินใจย้ายระบบจริง ผมเป็นคนเคาะเองเสมอ — benchmark หน้าที่แค่ยกตัวเลขจริงขึ้นมาให้เห็น ไม่ใช่กดปุ่มแทน
