โมเดลฉลาดขึ้นไม่สำคัญเท่าต้นทุนกับความเร็ว

ทุกครั้งที่มีโมเดลใหม่ออก ไทม์ไลน์ผมจะเต็มไปด้วยตาราง benchmark ครับ

ตัวนี้ชนะข้อสอบคณิต ตัวนั้นทำคะแนนโค้ดได้สูงสุด อีกตัวบอกว่า reasoning ดีกว่าเดิมไม่กี่เปอร์เซ็นต์

ผมเคยตื่นเต้นกับมันทุกรอบ รีบสลับไปใช้ตัวใหม่ทันที

แต่ช่วงหลังผมเริ่มสังเกตว่า สิ่งที่ทำให้งานผมกับทีมเสร็จเร็วขึ้นจริง ๆ แทบไม่เคยเป็นคะแนน benchmark เลย

มันคือ ราคาต่องาน กับ ความเร็วที่ได้คำตอบกลับมา

ความฉลาดเริ่มอิ่มตัว

ถ้าย้อนไปสองสามปีก่อน ส่วนต่างระหว่างโมเดลท็อปกับโมเดลรอง ๆ ชัดมาก ตัวหนึ่งเขียนโค้ดรันได้ อีกตัวมั่วจนต้องแก้ใหม่หมด

ทุกวันนี้ไม่ใช่แบบนั้นแล้ว

โมเดลชั้นนำจากหลายเจ้าไล่ตามกันจนส่วนต่างเรื่อง "ความฉลาด" แคบลงเรื่อย ๆ และโมเดลขนาดกลางที่ราคาถูกกว่าหลายเท่าก็ทำงานทั่วไปได้ดีพอจนแยกไม่ค่อยออก

ผมเรียกปรากฏการณ์นี้ว่า intelligence saturation

ไม่ได้แปลว่าโมเดลหยุดเก่งขึ้นนะครับ แต่แปลว่างานส่วนใหญ่ที่เราทำในแต่ละวัน มันถึงเพดานความฉลาดที่ต้องการไปแล้ว

เขียน CRUD endpoint, ร่าง test, แปลง JSON, สรุป PR, เขียน commit message, refactor ฟังก์ชันยาว ๆ

งานพวกนี้ไม่ได้ต้องการโมเดลที่แก้โจทย์โอลิมปิกได้ มันต้องการโมเดลที่ตอบเร็ว ตอบถูกพอ และไม่แพง

ผมเรียนรู้เรื่องนี้จากบิล

ผมเป็นเดฟที่ต้องทำงาน PM ด้วย ดูแลทีม junior อยู่ไม่กี่คน แล้วก็มี side project ที่ปั่นช่วงเสาร์อาทิตย์

ช่วงหนึ่งผมตั้งค่าให้ทุกคนในทีมใช้โมเดลที่แพงที่สุดเป็นค่าเริ่มต้น คิดง่าย ๆ ว่าใช้ตัวที่เก่งที่สุดไว้ก่อน งานจะได้ดี

สิ้นเดือนบิลออกมา ผมนั่งเงียบไปพักหนึ่ง

พอไล่ดู log ว่าเงินหายไปไหน คำตอบคือส่วนใหญ่ไปกับงานซ้ำ ๆ เช่นให้ agent อ่านไฟล์ทั้ง repo วนหลายรอบ แก้ lint ทีละบรรทัด หรือถามคำถามที่ค้นใน docs ได้ใน 10 วินาที

คุณภาพที่ได้เพิ่มจากโมเดลแพงในงานพวกนั้นแทบเป็นศูนย์ แต่ค่าใช้จ่ายเพิ่มขึ้นหลายเท่า

ที่แย่กว่านั้นคือ junior บางคนเริ่มรู้สึกผิดเวลาใช้ AI เพราะกลัวบิล ซึ่งเป็นผลตรงข้ามกับที่ผมอยากได้เลย

สิ่งที่ควร optimize แทนคะแนน benchmark

หลังจากรอบนั้น ผมเปลี่ยนคำถามจาก "โมเดลไหนฉลาดที่สุด" เป็น "โมเดลไหนทำให้งานนี้จบเร็วที่สุดในงบที่รับได้"

พอถามแบบนี้ เกณฑ์ที่ผมดูก็เปลี่ยนไป

Latency ใน loop เขียนโค้ด

เวลาเขียนโค้ดกับ AI เราไม่ได้ถามครั้งเดียวจบ เราวนถาม แก้ รัน ถามใหม่ สิบรอบยี่สิบรอบ

ถ้าแต่ละรอบช้ากว่ากันแค่ 10 วินาที ทั้งวันมันคือเวลาที่หายไปหลายสิบนาที และที่เสียหนักกว่าคือ flow ของเรา เพราะระหว่างรอเรามักเปิดแท็บอื่นแล้วหลุดโฟกัส

โมเดลที่ฉลาดน้อยกว่านิดหน่อยแต่ตอบไวกว่ามาก หลายครั้งพาเราไปถึงคำตอบเร็วกว่า

ราคาต่องาน ไม่ใช่ราคาต่อ token

ราคาต่อ token ดูในหน้า pricing ได้ แต่ตัวเลขที่สำคัญจริงคือ "ปิดหนึ่ง ticket ใช้เงินเท่าไร"

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

ต้องวัดจากงานจริงของเรา ไม่ใช่จากตาราง

Context window ที่พอใช้

ใหญ่ไม่ได้ดีเสมอ ใส่ context เยอะ ทั้งแพงขึ้นและช้าลง สิ่งที่ต้องการคือพอสำหรับงานที่เราทำบ่อย และเครื่องมือที่ช่วยเลือกไฟล์ที่เกี่ยวข้องได้ฉลาด

Tool use ที่เสถียร

สำหรับงาน agent ผมให้น้ำหนักเรื่องนี้มากกว่าความฉลาดดิบ โมเดลที่เรียก tool ถูก format ทุกครั้ง ไม่หลุด schema ไม่วนลูปแก้ไฟล์เดิม มีค่ากว่าโมเดลที่เก่งกว่าแต่ต้องคอยเฝ้า

ความคุ้นมือของทีม

ข้อนี้คนมักมองข้าม ทีมที่ใช้เครื่องมือเดิมจนรู้ว่ามันเก่งตรงไหน พลาดตรงไหน เขียน prompt ยังไงให้ได้ผล จะทำงานได้เร็วกว่าทีมที่สลับโมเดลใหม่ทุกเดือน

การเปลี่ยนเครื่องมือมีต้นทุนเสมอ แม้ตัวใหม่จะเก่งกว่าบนกระดาษ

แยกงานที่ต้อง frontier กับงานที่โมเดลถูกพอ

สิ่งที่ผมทำกับทีมตอนนี้คือแบ่งงานเป็นสองกลุ่มง่าย ๆ

กลุ่มที่คุ้มจ่ายแพง

• ออกแบบ architecture หรือตัดสินใจที่แก้ทีหลังยาก
• debug บั๊กแปลก ๆ ที่ข้ามหลาย service
• รีวิวโค้ดส่วนที่เกี่ยวกับ security หรือเงิน
• งานที่ต้องเข้าใจ context ยาวและซับซ้อนจริง ๆ

กลุ่มที่โมเดลถูกทำได้สบาย

• เขียน boilerplate, test เคสธรรมดา, migration
• แปลง format, เขียน regex, สรุปเอกสาร
• แก้ lint, เปลี่ยนชื่อตัวแปร, เขียน docstring
• ร่าง commit message และ PR description

ผมตั้งค่าเริ่มต้นของทีมเป็นโมเดลขนาดกลางที่เร็วและถูก แล้วบอกว่า "ถ้าติดเกินสองรอบ ค่อยสลับขึ้นไปตัวใหญ่"

กฎนี้ง่ายพอที่ junior จำได้โดยไม่ต้องคิด และทำให้เขากล้าใช้ AI โดยไม่ต้องกังวลเรื่องบิล

ทำให้เป็นระบบ ไม่ใช่ความรู้สึก

ถ้าจะเอาไปใช้จริง ผมแนะนำสามอย่างนี้ครับ

1. ตั้งงบต่อโปรเจกต์

แยก API key หรือ workspace ตามโปรเจกต์ แล้วตั้ง limit รายเดือน แค่นี้ก็เห็นแล้วว่าโปรเจกต์ไหนกินเงินผิดปกติ และ side project จะไม่แอบกินงบงานหลัก

2. วัดเวลา-ต่อ-ผลลัพธ์ ไม่ใช่แค่คุณภาพคำตอบครั้งเดียว

ลองเอางานจริงสักห้างานที่ทีมทำบ่อย แล้วรันกับสองสามโมเดล จดว่าแต่ละตัวใช้เวลารวมกี่นาที ใช้เงินเท่าไร และต้องแก้ตามหลังมากแค่ไหน

ตัวเลขชุดนี้มีประโยชน์กับทีมเรามากกว่า benchmark ไหน ๆ เพราะมันวัดจากงานของเราเอง

3. มี fallback เป็นโมเดลถูกสำหรับงานซ้ำ ๆ

งานที่รันอัตโนมัติ เช่น สรุป log, จัดหมวด issue, ร่าง release note ควรผูกกับโมเดลถูกตั้งแต่แรก และออกแบบให้สลับโมเดลได้ด้วยการแก้ config บรรทัดเดียว

วันที่มีโมเดลใหม่ที่ถูกกว่าออกมา เราจะได้ย้ายได้ทันทีโดยไม่ต้องรื้อโค้ด

ท้ายที่สุด

ผมยังชอบอ่านข่าวโมเดลใหม่เหมือนเดิมครับ มันสนุก และบางครั้งก็มีความสามารถใหม่ที่เปลี่ยนวิธีทำงานจริง ๆ

แต่ผมเลิกถามว่า "ตัวไหนฉลาดที่สุด" แล้ว

คำถามที่ผมถามตอนนี้คือ ตัวไหนทำให้ทีมผมส่งงานได้เร็วที่สุด ในงบที่ไม่ต้องลุ้นตอนสิ้นเดือน และ junior หยิบไปใช้ได้โดยไม่ต้องมีผมยืนข้าง ๆ

ถ้าความฉลาดกำลังกลายเป็นของที่ทุกเจ้ามีพอ ๆ กัน สิ่งที่ทำให้เราได้เปรียบก็คือการเลือกใช้ให้เข้ากับงาน

เลือกโมเดลเหมือนเลือกเครื่องมือในกล่องครับ ไม่จำเป็นต้องหยิบอันที่แพงที่สุดมาตอกตะปูทุกตัว