เมื่อ Benchmark บอกว่าชนะ แต่ Production บอกว่ารอไม่ได้

ผมเคยเชื่อว่าตัวเลขสวยๆ ในหน้าจอจะแปลเป็นผลลัพธ์จริงได้เสมอ แต่เมื่อวานนี้มันสอนบทเรียนราคาแพงให้ผมอีกครั้ง เรื่องราวเริ่มจากไอเดียที่ดูสมเหตุสมผลสุดๆ คือการย้ายแชทบอทดูแลลูกค้าเทรดมาวิ่งบนเครื่อง Mac Mini M4 Pro ที่บ้าน เพื่อลดต้นทุนและเพิ่มความเป็นส่วนตัว แทนที่จะพึ่งพาบริการคลาวด์ภายนอกอย่าง z.ai ที่เราใช้กันมานาน การทดสอบในสภาพแวดล้อมควบคุม (Benchmark) บอกว่าโมเดลใหม่ให้คะแนนความถูกต้อง 8.40 ซึ่งเหนือกว่าเวอร์ชันเดิมที่ 7.68 อย่างชัดเจน ดูเผินๆ แล้วนี่คือชัยชนะครั้งใหญ่ แต่ความจริงในสนามรบจริงกลับเป็นอีกเรื่องหนึ่ง

ความเร็วที่ไม่เคยมาพร้อมความยาว

ปัญหาหลักไม่ใช่ความฉลาดของโมเดล แต่เป็นเรื่องของ "Latency" หรือความหน่วงในการตอบสนอง ผมพยายามให้โมเดลอ่าน Prompt ยาวถึง 6,928 Token เพื่อครอบคลุมบริบทการวิเคราะห์ทองคำและสัญญาณเทรดที่ซับซ้อน ผลลัพธ์คือความเร็ว Prefill อยู่ที่ประมาณ 115 Token ต่อวินาที ซึ่งฟังดูไม่เลวนัก แต่เมื่อคูณกับจำนวน Token ที่ต้องประมวลผลก่อนจะตอบคำถามแรก ลูกค้าต้องรอคอยนานกว่า 85 วินาที สำหรับระบบที่ลูกค้าคาดหวังคำตอบแบบเรียลไทม์ในการเทรด ความล่าช้าเพียงไม่กี่วิก็อาจหมายถึงการพลาดจังหวะทำกำไรหรือขาดทุนได้ การรอเกือบนาทีครึ่งสำหรับแค่เริ่มต้นสนทนาถือเป็นเรื่องที่ยอมรับไม่ได้ในวงการ Forex ที่ทุกวินาทีมีค่า

ตัวเลขเบื้องหลังความล้มเหลว

ลองดูข้อมูลจริงจากเครื่อง Mac Mini M4 Pro เมื่อวันที่ 6 กันยายน 2026 จะเห็นภาพชัดเจนขึ้น โมเดล qwen38-chat:latest ขนาด 25 GB ทำงานบน GPU เต็มที่ 100% พร้อม Context สูงถึง 32,768 Token ในขณะที่การ์ดจอ 16GB ของระบบอื่นก็ทำงานหนักไม่แพ้กัน โดยใช้งานหน่วยความจำเกือบเต็ม เช่น 15,745 จาก 16,311 MiB และอีกเครื่องอยู่ที่ 14,475 จาก 16,311 MiB สิ่งนี้แสดงให้เห็นว่าทรัพยากรถูกใช้จนหมดเกลี้ยง แต่ประสิทธิภาพในการตอบสนองต่อผู้ใช้กลับตกต่ำลงอย่างน่าใจหาย การที่ GPU ทำงานหนัก 100% ไม่ได้หมายความว่าระบบเร็วเสมอไป บางครั้งมันหมายถึงการคอขวด (Bottleneck) ที่ทำให้ทุกอย่างชะงักงัน

บทเรียนจาก Ledger 4,028 แถว

สิ่งที่เจ็บปวดที่สุดคือต้องตัดสินใจ Rollback กลับไปใช้ z.ai ทันที แม้ว่าการทดสอบจะบอกว่าโมเดลใหม่ดีกว่า แต่ใน Production เราไม่สามารถเสี่ยงกับประสบการณ์ลูกค้าที่แย่ลงได้ ผมตรวจสอบ Log ย้อนหลังพบว่ามีบันทึกการสนทนาถึง 4,028 แถว ที่ได้รับผลกระทบจากความล่าช้านี้ การกลับสู่ระบบเดิมไม่ใช่การยอมแพ้ แต่คือการยอมรับว่า "Benchmark" กับ "Production" เป็นคนละโลกกัน ใน Benchmark เราวัดความถูกต้องและประสิทธิภาพในสภาวะนิ่ง แต่ใน Production เราวัดความเสถียรและความเร็วภายใต้ภาระงานจริงที่เปลี่ยนแปลงตลอดเวลา การยึดติดกับตัวเลข 8.40 แทนที่จะมองภาพรวมของประสบการณ์ผู้ใช้ ทำให้ผมเกือบทำผิดพลาดร้ายแรง

ทางออกถัดไป: ตัดทอนเพื่อความเร็ว

จากเหตุการณ์นี้ ผมได้เรียนรู้ว่า Prompt ยาวไม่ใช่คำตอบเสมอไป บางครั้งการตัดทอนข้อมูลที่ไม่จำเป็นออกเพื่อให้โมเดลประมวลผลเร็วขึ้น อาจคุ้มค่ากว่าการพยายามยัดทุกอย่างเข้าไปใน Context ขนาดใหญ่ แผนถัดไปของผมคือการออกแบบระบบที่แยกส่วนการวิเคราะห์สัญญาณออกจากส่วนการสนทนา เพื่อให้แชทบอทใช้ Prompt สั้นกระชับสำหรับตอบคำถามทั่วไป และเรียกใช้โมเดลเฉพาะทางเมื่อจำเป็นต้องคำนวณตัวเลขซับซ้อนเท่านั้น การยอมรับว่าเทคโนโลยีที่ดีที่สุดไม่ได้หมายความว่าดีที่สุดสำหรับทุกสถานการณ์ คือก้าวสำคัญในการเติบโตของ iCafeFX และ SiamCafe ครับ

ผมยังคงเชื่อมั่นในพลังของ AI แต่ต้องเรียนรู้ที่จะใช้อย่างชาญฉลาด ไม่ใช่แค่ตามเทรนด์หรือตัวเลขสวยๆ บนหน้าจอ ความจริงที่โหดร้ายที่สุดคือ ลูกค้าไม่สนใจว่าโมเดลของคุณได้คะแนนเท่าไหร่ พวกเขาแคร์แค่ว่าได้รับคำตอบเร็วพอไหม และถูกต้องพอไหม การปรับจูนระบบต่อไปจึงเน้นไปที่การลด Latency เป็นอันดับหนึ่ง เพื่อให้เทคโนโลยีทำงานเพื่อคน ไม่ใช่ให้คนรอเทคโนโลยีครับ