Test-time compute

Test-time compute คือแรงประมวลผลที่โมเดลใช้ตอนกำลังตอบคำถามของคุณ ไม่ใช่ตอนที่มันถูกฝึกในศูนย์ข้อมูลเมื่อหลายเดือนก่อน บางแห่งเรียกว่า inference-time compute เพราะช่วงที่โมเดลถูกเรียกใช้งานจริงเรียกว่า inference แนวคิดของมันเรียบง่ายกว่าที่ชื่อทำให้รู้สึก ถ้าปล่อยให้โมเดลตัวเดิมใช้แรงคิดต่อคำถามหนึ่งข้อมากขึ้น เช่น ไล่ขั้นตอนการคิดให้ยาวขึ้นแบบ chain-of-thought ลองหลายเส้นทางแล้วคัดเส้นที่ดีที่สุด หรือทบทวนแก้คำตอบของตัวเองอีกรอบก่อนส่งออกมา คุณภาพคำตอบมีแนวโน้มดีขึ้นทั้งที่น้ำหนักภายในตัวโมเดลไม่ได้เปลี่ยนเลยสักตัวเดียว นี่คือคนละแกนกับ scaling-laws แบบดั้งเดิมที่เพิ่มความเก่งด้วยการขยายจำนวนพารามิเตอร์และกองข้อมูลฝึก และเป็นที่มาของโมเดลตระกูลคิดก่อนตอบที่เราใช้กันอยู่ทุกวันนี้

งานที่คนอ้างถึงมากที่สุดเวลาพูดเรื่องนี้คือเปเปอร์ชื่อ Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters ของ Charlie Snell และคณะ ซึ่งขึ้นคลัง arXiv เมื่อวันที่ 6 สิงหาคม 2024 ทีมวิจัยทดลองสองกลไก กลไกแรกคือให้โมเดลค้นหาคำตอบหลายเส้นแล้วใช้ verifier ที่ให้คะแนนการคิดเป็นรายขั้นช่วยคัดว่าเส้นไหนน่าเชื่อถือ กลไกที่สองคือให้โมเดลปรับคำตอบของตัวเองระหว่างที่ตอบ ข้อค้นพบหลักคือความคุ้มค่าของการเติมแรงคิดขึ้นอยู่กับความยากของโจทย์อย่างมาก พอเปลี่ยนมาจัดสรรแรงคิดตามความยากรายข้อแทนที่จะเทเท่ากันทุกข้อ ประสิทธิภาพของการใช้แรงคิดดีขึ้นกว่าวิธี best-of-N มากกว่า 4 เท่า คือได้ผลเท่าเดิมโดยใช้แรงคิดน้อยลง ไม่ใช่คะแนนความถูกต้องเพิ่มขึ้น 4 เท่า และในการเทียบแบบคุมปริมาณการคำนวณ (FLOPs) ให้เท่ากัน บนโจทย์ที่โมเดลเล็กพอทำถูกได้อยู่บ้างแล้ว การเติมแรงคิดตอนตอบทำคะแนนชนะโมเดลที่ใหญ่กว่าถึง 14 เท่าได้

ข้อสรุปอีกครึ่งหนึ่งของเปเปอร์เดียวกันมักหายไปเวลาคนเล่าต่อ ทีมวิจัยเขียนไว้ว่าบนโจทย์ง่ายถึงปานกลาง การเติมแรงคิดตอนตอบมักคุ้มกว่าการเอางบไปเทรนโมเดลเพิ่ม แต่เมื่อสัดส่วนการใช้งานจริงเทียบกับการเทรนสูงขึ้นและโจทย์ยากขึ้น การลงทุนกับ pretraining กลับให้ผลดีกว่า พูดอีกแบบคือการเพิ่มแรงคิดตอนตอบไม่ได้มาแทนที่การเทรนโมเดลใหญ่ มันแค่ย้ายจุดที่คุ้มที่สุดไปตามความยากของงาน ข้อควรทราบคือฉบับที่คนอ้างกันมากที่สุดเป็น preprint บน arXiv ซึ่งมีแค่ v1 และหน้ารายการไม่ได้ระบุวารสาร แต่งานชิ้นนี้ผ่าน peer review แล้วจริง โดยได้รับเลือกเป็น Oral ของงานประชุม ICLR 2025 ในชื่อ Scaling LLM Test-Time Compute Optimally Can be More Effective than Scaling Parameters for Reasoning

คนทำงานเจอเรื่องนี้ในรูปของใบแจ้งหนี้ที่โตขึ้นและปุ่มปรับความลึกของการคิด เอกสารของ anthropic ระบุว่าโทเค็นที่ Claude ใช้ระหว่างคิดถูกคิดเงินเป็น output-tokens และเตือนไว้ตรงๆ ว่ายอดที่ถูกเรียกเก็บคือความคิดเต็มจำนวนที่โมเดลสร้างขึ้นภายใน ไม่ใช่ข้อความสรุปความคิดสั้นๆ ที่โผล่บนหน้าจอ ฝั่ง gemini ของ Google เขียนไว้ในทางเดียวกันว่าราคาของการตอบหนึ่งครั้งคือผลรวมของ output token กับ thinking token และคิดจากความคิดเต็มจำนวนแม้ API จะคืนมาแค่บทสรุป ปุ่มควบคุมของแต่ละเจ้าต่างกันที่ชื่อ ฝั่ง Claude ใช้พารามิเตอร์ effort ที่มีระดับ low ถึง max โดยค่าเริ่มต้นคือ high และระดับ low แปลว่าโมเดลจะคิดให้น้อยที่สุดและข้ามการคิดไปเลยในงานง่ายที่ต้องการความเร็ว ส่วน Gemini ใช้ thinking_level ที่มีระดับ minimal, low, medium และ high โดยเอกสารแนะนำให้ดันขึ้นสูงสุดกับงานเขียนโค้ดขั้นสูง คณิตศาสตร์ และการวางแผนหลายขั้น และให้ใช้ระดับต่ำกับงานอย่างการดึงข้อมูลตรงไปตรงมา ในทางเทคนิคทั้งหมดนี้แปลว่าเวลาบน gpu ต่อคำถามหนึ่งข้อยาวขึ้น ซึ่งเป็นเหตุผลที่ทั้งค่าใช้จ่ายและเวลารอเพิ่มขึ้นพร้อมกัน

สิ่งที่ต้องระวังมากที่สุดคือการเหมาว่ายิ่งคิดนานยิ่งดีเสมอ เอกสารของ Anthropic เองเขียนว่างบการคิดที่สูงขึ้นให้การวิเคราะห์ที่ครอบคลุมขึ้นก็จริง แต่ผลตอบแทนลดลงเรื่อยๆ ตามลักษณะงาน และแลกมาด้วยเวลาที่ช้าลง มีงานวิจัยชื่อ Inverse Scaling in Test-Time Compute ที่ตีพิมพ์ในวารสาร TMLR เดือนธันวาคม 2025 สร้างชุดโจทย์ที่ยิ่งยืดความยาวของการคิด โมเดลยิ่งตอบแย่ลง โดยพบรูปแบบความล้มเหลวห้าแบบ เช่น โมเดลฝั่ง Claude ถูกข้อมูลที่ไม่เกี่ยวข้องดึงความสนใจมากขึ้นเมื่อคิดยาวขึ้น ส่วนโมเดล o-series ของ OpenAI ทนต่อตัวรบกวนได้ดีกว่าแต่ไปติดกับดักของกรอบโจทย์ที่ถูกเขียนมาหลอก ข้อจำกัดที่ต้องบอกไว้คือโจทย์ชุดนี้ถูกออกแบบมาเพื่อล่าจุดอ่อนโดยเฉพาะ ไม่ใช่ภาพเฉลี่ยของงานทั่วไป อีกกับดักที่เจอบ่อยในทางปฏิบัติคือค่า max_tokens ที่เคยตั้งไว้พอดีกับคำตอบล้วนๆ มักเล็กเกินไปเมื่อโมเดลเริ่มคิด เพราะโทเค็นการคิดถูกนับรวมอยู่ในเพดานเดียวกัน ผลคือคำตอบถูกตัดกลางคัน ซึ่งแก้ได้ด้วยการขยายเพดานหรือลดระดับการคิดลง

ตัวอย่างจากบทสนทนาจริง

ฝ่ายการเงิน: "เดือนนี้บิลค่า AI เพิ่มเกือบเท่าตัว ทั้งที่ทีมส่งคำถามจำนวนเท่าเดิมและคำตอบที่ได้ก็ยาวพอๆ กับเดิม เกิดอะไรขึ้นคะ"

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

ฝ่ายการเงิน: "ถ้าอย่างนั้นตั้งให้คิดหนักสุดทุกงานไปเลย จะได้คำตอบดีที่สุดใช่ไหมคะ"

หัวหน้าฝ่ายไอที: "ไม่จริงทุกงานครับ เอกสารของผู้ให้บริการเองก็เขียนว่าเพิ่มงบการคิดแล้วผลตอบแทนจะลดลงเรื่อยๆ และแลกมากับความช้า แถมมีงานวิจัยที่สร้างโจทย์ซึ่งยิ่งบังคับให้คิดยาวยิ่งตอบผิดมากขึ้นด้วย ทางที่ปลอดภัยกว่าคือทดสอบกับงานจริงของเราเองแล้วค่อยตั้งค่า"

ระวังสับสนกับ

• reasoning-model : test-time compute คือแนวคิดเรื่องปริมาณแรงคิดที่ใช้ตอนตอบ ส่วน reasoning model คือตัวโมเดลที่ถูกฝึกมาให้ใช้แรงคิดก้อนนั้นเป็น พูดง่ายๆ คืออันหนึ่งเป็นทรัพยากร อีกอันเป็นผู้ใช้ทรัพยากร
• effort : effort คือพารามิเตอร์จริงที่คุณตั้งค่าได้ในคำขอแต่ละครั้ง ส่วน test-time compute คือปริมาณแรงคิดที่ถูกใช้จริงหลังจากตั้งค่านั้นไปแล้ว ซึ่งเอกสารระบุว่าเป็นเพียงคำแนะนำแบบหลวมๆ ไม่ได้การันตีจำนวนโทเค็นตายตัว
• overthinking : เป็นอาการที่เกิดเมื่อเติมแรงคิดเลยจุดคุ้มไปแล้ว คำตอบวนเวียนหรือหลุดประเด็น ส่วน test-time compute คือปุ่มที่ถูกหมุน overthinking คือสิ่งที่เกิดตอนหมุนแรงเกินไป