Inference-time Scaling คืออะไร? วิธีปรับสมดุลระหว่างต้นทุนและความแม่นยำของ AI

Test-Time Compute (การประมวลผลขณะอนุมาน) คือคำเรียกโดยรวมของกลุ่มเทคนิคที่เพิ่มปริมาณการคำนวณอย่างตั้งใจในขั้นตอนที่ LLM กำลังสร้างคำตอบ เพื่อยกระดับความแม่นยำในการอนุมาน ในขณะที่กฎการขยายขนาด (Scaling Laws) แบบดั้งเดิมเน้นการใช้ข้อมูลและพลังการคำนวณจำนวนมากในระหว่างการฝึกฝน แนวคิดเรื่องการเพิ่มประสิทธิภาพด้วยการคำนวณเพิ่มเติมในขณะอนุมานกำลังแพร่หลายอย่างรวดเร็วพร้อมกับการมาถึงของโมเดลสำหรับการอนุมาน (Reasoning Models)

บทความนี้จัดทำขึ้นสำหรับนักพัฒนา, PdM และผู้บริหารที่ใช้ LLM ในเชิงธุรกิจ B2B โดยจะสรุปแนวคิดพื้นฐานของ Test-Time Compute, เทคนิคหลัก, วิธีการนำไปประยุกต์ใช้กับ AI ในงานธุรกิจ, การออกแบบจุดสมดุลระหว่างต้นทุนและความแม่นยำ ไปจนถึงข้อควรระวังที่พบบ่อย เมื่ออ่านจบ คุณจะมีความเข้าใจพื้นฐานที่สามารถตัดสินใจได้ว่าควร "ใช้หรือไม่ใช้ หรือควรใช้มากน้อยเพียงใด" สำหรับ Test-Time Compute ให้เหมาะสมกับกรณีการใช้งานขององค์กรคุณ

Inference-time scaling (การขยายขนาดขณะอนุมาน) ไม่ใช่แนวทางที่เน้นการ "เพิ่มการเรียนรู้" แต่เป็นแนวทางที่เน้นการ "เพิ่มเวลาในการคิด" โดยเฉพาะอย่างยิ่ง คือกลุ่มวิธีการที่ช่วยยกระดับคุณภาพของคำตอบด้วยการเพิ่มปริมาณการคำนวณขณะอนุมาน เช่น การคิดแบบทีละขั้นตอน (step-by-step thinking), การสุ่มตัวอย่างหลายครั้ง (multiple sampling) และการเปรียบเทียบคำตอบเชิงสำรวจ

ในส่วนนี้จะสรุปคำนิยาม ความแตกต่างจากการขยายขนาดขณะเรียนรู้ (training-time scaling) และความเป็นมาของการเกิดขึ้นของโมเดลสำหรับการอนุมาน (inference models) การทำความเข้าใจความแตกต่างของทั้งสองสิ่งนี้จะทำให้เห็นภาพว่าเหตุใดแนวคิดนี้จึงจำเป็นต่อการออกแบบ AI สำหรับธุรกิจ

การขยายขนาดขณะอนุมาน (Inference-time scaling) คือคำเรียกโดยรวมของวิธีการเพิ่มประสิทธิภาพของโมเดลโดยการเพิ่มปริมาณการคำนวณในขั้นตอนการอนุมาน (จำนวนการสร้างโทเค็น, จำนวนครั้งในการสุ่มตัวอย่าง, ความลึกในการค้นหา) วิธีการอย่าง Chain-of-Thought (CoT), Self-consistency, Best-of-N, Tree-of-Thoughts และ Reflection ต่างก็รวมอยู่ในกรอบแนวคิดนี้

การขยายขนาดขณะเรียนรู้ (Pre-training Scaling) ซึ่งเป็นกระแสหลักในการพัฒนา LLM แบบดั้งเดิมนั้น อ้างอิงตามกฎการขยายขนาด (Scaling Law) ที่ว่าประสิทธิภาพจะเพิ่มขึ้นหากเพิ่มจำนวนพารามิเตอร์, ปริมาณข้อมูลการเรียนรู้ และปริมาณการคำนวณในการเรียนรู้ อย่างไรก็ตาม การเรียนรู้ขนาดใหญ่มักเผชิญกับข้อจำกัดด้านต้นทุน, ข้อมูล และพลังงานไฟฟ้า อีกทั้งยังมีการชี้ให้เห็นว่าเส้นโค้งประสิทธิภาพเริ่มชะลอตัวลงด้วย

ทั้งสองแนวคิดไม่ใช่สิ่งที่ขัดแย้งกัน แต่เป็นความสัมพันธ์ที่ส่งเสริมซึ่งกันและกัน แม้จะใช้โมเดลพื้นฐานเดียวกัน แต่ความแม่นยำในการใช้งานจริงจะเปลี่ยนไปอย่างมากตามปริมาณการคำนวณที่ใช้ในขณะอนุมาน

→ ที่เกี่ยวข้อง: คู่มือการเพิ่มประสิทธิภาพต้นทุน LLM, วิธีการเลือกใช้ Fine-tuning และ RAG

การขยายขนาดในขณะประมวลผล (Inference-time scaling) เริ่มได้รับความสนใจอย่างจริงจังจากการที่โมเดลตระกูล Reasoning ของ OpenAI, โมเดลที่เน้นการใช้เหตุผลของ DeepSeek และโมเดล Reasoning ของ Google ได้นำสถาปัตยกรรมที่ใช้โทเค็นจำนวนมหาศาลในกระบวนการคิดภายในมาใช้ โมเดลเหล่านี้จะสร้างโทเค็นสำหรับการ "คิด" ภายในเป็นจำนวนมากก่อนที่จะให้คำตอบสุดท้าย

ผลกระทบต่ออุตสาหกรรมนั้นมีมหาศาล และกำลังเกิดการถกเถียงในสองทิศทางหลัก:

ประการแรกคือ การเปลี่ยนแปลงโครงสร้างต้นทุนการประมวลผล จากเดิมที่การออกแบบต้นทุนตั้งอยู่บนสมมติฐานว่า "เรียกใช้โมเดลขนาดเล็กจำนวนมาก" แต่โมเดล Reasoning กลับมีปริมาณการคำนวณต่อหนึ่งคำขอ (Request) สูงกว่าอย่างเทียบไม่ได้ การคำนวณต้นทุนจึงจำเป็นต้องออกแบบใหม่โดยไม่เพียงแค่พิจารณาจากราคาต่อโทเค็นขาเข้าและขาออกเท่านั้น แต่ยังต้องรวมถึงโครงสร้างราคาของโทเค็นที่ใช้ในการคิดภายใน (ซึ่งผู้ให้บริการหลายรายคิดราคาแยกต่างหาก) เข้าไปด้วย

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

สิ่งที่ผู้เขียนสัมผัสได้จากโปรเจกต์ B2B ในช่วงที่ผ่านมาคือ ความคาดหวังที่ว่า "ใช้โมเดล Reasoning แล้วจะแก้ปัญหาได้ทุกอย่าง" กับความกังวลที่ว่า "ไม่สามารถคาดการณ์ต้นทุนการประมวลผลได้ จึงนำไปใช้จริงไม่ได้" กำลังเพิ่มสูงขึ้นพร้อมๆ กัน การออกแบบการแลกเปลี่ยนผลประโยชน์ (Trade-off) ที่จะกล่าวถึงในช่วงหลังของบทความนี้ คือการสรุปแนวทางเพื่อตัดสินใจเชิงกลยุทธ์ในการนำไปใช้งานจริงท่ามกลางความกังวลทั้งสองประการนี้

ในขณะที่มีการชี้ให้เห็นว่า Scaling Law ในฝั่งการเรียนรู้ (Training) เริ่มถึงจุดอิ่มตัว แต่ฝั่งการอนุมาน (Inference) ยังคงมีช่องว่างให้เติบโตได้อีกมาก ยิ่งไปกว่านั้น การใช้งาน AI ในเชิงธุรกิจได้ขยายขอบเขตจาก "การตอบกลับตามรูปแบบเดิม" ไปสู่ "การประมวลผลที่ต้องอาศัยการตัดสินใจ" ทำให้ความต้องการด้านความแม่นยำเพิ่มสูงขึ้นอีกระดับ ปัจจัยทั้งสองประการนี้จึงผลักดันให้การขยายขนาดขณะอนุมาน (Inference-time scaling) กลายเป็นหัวข้อสำคัญในการปฏิบัติงานจริง

ในส่วนนี้ จะทำการสรุปถึงขีดจำกัดของการขยายขนาดการเรียนรู้ แนวโน้มไปสู่การเพิ่มประสิทธิภาพต้นทุนการอนุมาน และสถานการณ์ทั่วไปที่ความต้องการด้านความแม่นยำของ AI ในเชิงธุรกิจเพิ่มสูงขึ้น

การพัฒนา LLM ในช่วงปี 2020 เป็นต้นมา ดำเนินไปภายใต้สมมติฐานที่เรียบง่ายว่า "ยิ่งเพิ่มพารามิเตอร์และข้อมูลการเรียนรู้ โมเดลก็จะยิ่งฉลาดขึ้น" อย่างไรก็ตาม เมื่อต้นทุนการพัฒนา Frontier Model พุ่งสูงขึ้นถึงระดับหลายแสนล้านเยน งานวิจัยหลายฉบับได้รายงานถึงผลตอบแทนด้านประสิทธิภาพที่ลดลงเมื่อเทียบกับเงินลงทุนที่เพิ่มขึ้น (กฎการลดน้อยถอยลงของผลตอบแทน หรือ Diminishing Returns)

ทางเลือกที่กำลังได้รับความสนใจคือการหันไปเน้นการคำนวณที่ฝั่งการอนุมาน (Inference) แทน โดยเฉพาะอย่างยิ่งวิธีการต่างๆ เช่น:

• การให้แก้ปัญหาเดิมหลายครั้งผ่านเส้นทางที่แตกต่างกัน แล้วเลือกคำตอบด้วยวิธีเสียงข้างมาก
• การให้ LLM อีกตัววิจารณ์คำตอบที่สร้างขึ้นแล้วสั่งให้แก้ไขใหม่
• การใช้ขั้นตอนวิธีค้นหา (Search Algorithm) เพื่อเปรียบเทียบแนวทางการคิดที่หลากหลาย

วิธีการเหล่านี้ไม่จำเป็นต้องอาศัยการเรียนรู้เพิ่มเติม (Additional Training) และสามารถนำไปประยุกต์ใช้กับโมเดลที่มีอยู่เดิมได้ ในขณะที่การเติบโตฝั่งการเรียนรู้เริ่มชะลอตัว พื้นที่ในการสร้างความแตกต่างให้กับ AI สำหรับธุรกิจจึงย้ายมาอยู่ที่การออกแบบฝั่งการอนุมานแทน

ในขณะเดียวกัน ผู้ให้บริการแต่ละรายกำลังปรับปรุงโครงสร้างราคาสำหรับโมเดลการอนุมาน โดยเริ่มมีการคิดค่าบริการเพิ่มจาก "Internal Thought Tokens" นอกเหนือไปจาก Input/Output Tokens ตามปกติ ซึ่งกล่าวได้ว่าสมรภูมิหลักของการเพิ่มประสิทธิภาพด้านต้นทุนได้เปลี่ยนจากการลงทุนด้านการเรียนรู้ ไปสู่การออกแบบเวิร์กโฟลว์การอนุมานแล้ว

→ ที่เกี่ยวข้อง: Context Engineering, Hybrid LLM × SLM Routing

การขยายขนาดในขณะอนุมาน (Inference-time scaling) มีประสิทธิภาพเป็นพิเศษกับ "ปัญหาที่ไม่สามารถหาคำตอบได้ในการประมวลผลเพียงครั้งเดียว" โดยมีตัวอย่างดังนี้:

• การตรวจสอบทางกฎหมายและสัญญา: การตรวจสอบความสอดคล้องระหว่างข้อสัญญา และการคัดแยกข้อสัญญาที่มีความเสี่ยง ซึ่งการสร้างคำตอบเพียงครั้งเดียวมักทำให้เกิดการมองข้ามจุดสำคัญได้ง่าย
• การตรวจสอบโค้ดและการตรวจหาช่องโหว่: จำเป็นต้องพิจารณาจากหลายมุมมอง (ความปลอดภัย / ความสามารถในการอ่าน / ประสิทธิภาพ) ควบคู่กันไปและเปรียบเทียบข้อสรุป
• การสนับสนุนการตัดสินใจในการวิเคราะห์ข้อมูล: จำเป็นต้องมีวงจรของการตั้งสมมติฐาน → การพิสูจน์หักล้าง → การตรวจสอบซ้ำ
• การวิจัยหลายขั้นตอน: งานที่ต้องสืบค้นผ่านหลายเส้นทางโดยเปลี่ยนสมมติฐานไปเรื่อยๆ แล้วนำข้อสรุปมาบูรณาการเข้าด้วยกัน
• การวางแผนของ Agent: การเลือกเส้นทางที่เหมาะสมที่สุดจากลำดับการเรียกใช้เครื่องมือหลายๆ อย่าง

ในหน้างานการพัฒนาผลิตภัณฑ์ B2B แห่งหนึ่งที่ผู้เขียนเคยให้การสนับสนุน เมื่อมอบหมายให้ LLM ตรวจสอบร่างสัญญาล่วงหน้า พบว่าหากเป็นการสร้างคำตอบเพียงครั้งเดียว อัตราการตรวจพบข้อสัญญาที่มีความเสี่ยงจะถึงจุดอิ่มตัว แต่เมื่อเปลี่ยนมาใช้โมเดลเดิมโดยเปิดใช้งานการคิดภายใน (Internal thought) ร่วมกับการสุ่มตัวอย่างแบบขนานหลายชุดแล้วนำมาเปรียบเทียบกัน พบว่าการตรวจพลาดลดลงอย่างเห็นได้ชัด อย่างไรก็ตาม เนื่องจาก Latency เพิ่มขึ้นหลายเท่าและต้นทุนต่อรายการสูงขึ้น จึงต้องปรับการใช้งานให้จำกัดเฉพาะ "สัญญาสำคัญเท่านั้น"

เมื่อมีความจำเป็นต้องเพิ่มความแม่นยำให้กับ AI ในการทำงาน แนวคิดที่จะเพิ่มข้อมูลการเรียนรู้ก่อนเป็นอันดับแรกนั้นเป็นเรื่องปกติ แต่ควรตระหนักไว้ด้วยว่ายังมีช่องว่างอีกมากในการแก้ไขปัญหาด้วยการปรับแต่งฝั่งการอนุมาน (Inference)

การขยายขนาดขณะอนุมาน (Inference-time scaling) แบ่งออกเป็น 3 ประเภทหลัก ได้แก่ การขยายขนาดภายใน (Internal scaling), การขยายขนาดแบบขนาน (Parallel scaling) และการขยายขนาดแบบสำรวจ (Search scaling) เนื่องจากวิธีการแต่ละแบบมีอัตราการเพิ่มขึ้นของต้นทุนการคำนวณและงานที่เหมาะสมแตกต่างกัน การเลือกใช้ให้สอดคล้องกับกรณีการใช้งาน (Use case) จึงเป็นสิ่งสำคัญ

ในที่นี้จะขอสรุปกลไก งานที่เหมาะสม และระดับต้นทุนของทั้ง 3 ประเภทหลัก ดังนี้

Internal Scaling คือแนวทางที่ทำให้โมเดลใช้เวลาคิดนานขึ้นภายในคำขอ (Request) เดียวกัน ตัวอย่างที่สำคัญมีดังนี้:

• Chain-of-Thought (CoT): การกระตุ้นด้วยคำสั่ง "ให้คิดทีละขั้นตอน" เพื่อสร้างกระบวนการอนุมานก่อนที่จะสรุปผล
• Reflection / Self-correction: การให้โมเดลตรวจสอบคำตอบที่สร้างขึ้นมาเองว่า "มีข้อผิดพลาดหรือไม่" แล้วทำการแก้ไข
• Internal Thinking ของโมเดลเชิงอนุมาน (Reasoning Models): โมเดลเชิงอนุมานจากผู้ให้บริการหลักจะใช้โทเค็นภายในที่ผู้ใช้มองไม่เห็นเพื่อคิดอย่างลึกซึ้งก่อนที่จะตอบกลับ

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

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

การทำ Parallel Scaling คือแนวทางที่ให้โมเดลตอบคำถามเดิมซ้ำหลายครั้งอย่างอิสระ แล้วนำผลลัพธ์มารวมกัน

• Self-consistency: เพิ่มค่า Temperature เพื่อสร้างคำตอบที่หลากหลาย และเลือกข้อสรุปที่ปรากฏบ่อยที่สุดเป็นคำตอบสุดท้าย
• Best-of-N: สร้างคำตอบ N รูปแบบ แล้วใช้โมเดลประเมินผลหรือฟังก์ชันการให้คะแนนเพื่อเลือกคำตอบที่ดีที่สุด 1 รายการ
• Majority voting: ตัดสินข้อสรุปด้วยการลงคะแนนเสียงข้างมาก มีประสิทธิภาพสูงในงานด้านคณิตศาสตร์และการจำแนกประเภท

ในการใช้งานจริง หลายกรณีพบว่าการทำ Parallel 3-5 ครั้งก็เพียงพอที่จะเห็นการปรับปรุงที่ชัดเจน และการเพิ่มระดับการทำ Parallel ต่อไปเรื่อยๆ จะทำให้ความแม่นยำเริ่มอิ่มตัว ทั้งนี้ ก่อนการประมวลผลแบบขนาน จำเป็นต้องตรวจสอบขีดจำกัดการเรียกใช้ API ของโมเดล (Rate Limit / Concurrency Limit) ด้วย

→ เกี่ยวข้อง: การประเมินผลลัพธ์ AI ด้วย LLM-as-a-Judge

การขยายขอบเขตการค้นหา (Search Scaling) คือแนวทางที่ใช้วิธีการแตกแขนงคำตอบที่เป็นไปได้ออกมาเป็นโครงสร้างแบบต้นไม้ พร้อมกับประเมินผลเพื่อเจาะลึกไปยังเส้นทางที่มีแนวโน้มดีที่สุด

• Tree-of-Thoughts (ToT): แตกกระบวนการคิดออกเป็นโครงสร้างต้นไม้ โดยประเมินแต่ละโหนดเพื่อเลือกกิ่งก้านที่มีแนวโน้มดี
• MCTS (Monte Carlo Tree Search): นำอัลกอริทึมการค้นหาที่ใช้ใน AI สำหรับเล่นเกมมาประยุกต์ใช้กับการอนุมาน โดยใช้วิธีการจำลองสถานการณ์และประเมินผลซ้ำๆ
• Beam Search Extension: เก็บรักษาคำตอบที่เป็นไปได้จำนวน k อันดับแรกในแต่ละขั้นตอน และเลือกเส้นทางที่ดีที่สุดในท้ายที่สุด

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

→ ดูเพิ่มเติม: Multi-agent AI

การขยายขนาดในขณะอนุมาน (Inference-time scaling) ไม่ใช่สิ่งที่ "ใช้แล้วจะดีขึ้นเสมอไป" แต่จำเป็นต้องมีการตัดสินใจเชิงออกแบบโดยคำนึงถึงความยากของงาน, ค่าความหน่วง (Latency) ที่ยอมรับได้ และขีดจำกัดของต้นทุน การกำหนดตัวชี้วัดการประเมินและภาพรวมการใช้งานให้ตรงกันก่อนเริ่มนำไปใช้จริง คือกุญแจสำคัญในการเปลี่ยนจาก PoC ไปสู่การใช้งานจริง

ในส่วนนี้ จะสรุปวิธีการเลือกเทคนิคตามระดับความยากของงาน, การออกแบบเพื่อสร้างสมดุล (Trade-off) และวิธีการกำหนดตัวชี้วัดสำหรับการประเมิน PoC

การแบ่งระดับความยากของงานออกเป็น 3 ระดับ จะช่วยให้เลือกวิธีการที่เหมาะสมได้ง่ายขึ้น

การใช้วิธีที่มีต้นทุนสูงกับงานที่มีความยากต่ำถือเป็นการสิ้นเปลืองและทำให้ Latency แย่ลง ในทางกลับกัน หากใช้การสร้างคำตอบแบบครั้งเดียว (Single-shot) กับงานที่มีความยากสูง อาจนำไปสู่คำตอบที่ผิดพลาดซึ่งกลายเป็นความเสี่ยงทางธุรกิจได้

เคล็ดลับในการตัดสินใจคือการใช้เกณฑ์ว่า "ผู้เชี่ยวชาญที่เป็นมนุษย์สามารถตอบได้ภายใน 1 นาทีหรือไม่" หากตอบได้ภายใน 1 นาที ก็ไม่จำเป็นต้องทำ Inference-time scaling แต่หากต้องใช้เวลาพิจารณามากกว่า 5 นาทีขึ้นไป การใช้โมเดลการอนุมานหรือการทำ Scaling แบบขนานมักจะให้ผลลัพธ์ที่ดีกว่า

ในเวิร์กโฟลว์ของ Agent การออกแบบโดยจำแนกประเภทของงานตั้งแต่เริ่มต้น แล้วส่งต่อไปยังเส้นทางการอนุมาน (Inference path) ที่แตกต่างกันตามระดับความยาก เป็นแนวทางปฏิบัติทั่วไป

→ ที่เกี่ยวข้อง: คู่มือการวัด ROI ของ AI Agent

การขยายขนาดขณะอนุมาน (Inference-time scaling) เป็นการออกแบบที่แลกมาด้วยต้นทุนและเวลาแฝง (Latency) เพื่อให้ได้ความแม่นยำที่สูงขึ้น จึงจำเป็นต้องกำหนดสมดุลของทั้ง 3 แกนนี้อย่างตั้งใจ

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

ทางเลือกอื่นที่มีประสิทธิภาพคือ การประมวลผลเฉพาะคำขอที่สำคัญแบบอะซิงโครนัสแล้วส่งกลับทางอีเมลหรือแดชบอร์ด หรือ การให้โมเดลขนาดเล็กประเมินความยากของคำขอก่อน หากเป็นคำขอที่มีความยากสูงจึงค่อยส่งต่อไปยังโมเดลอนุมาน ในโครงการ B2B ของเรา มีกรณีศึกษาที่เปลี่ยนจากการส่งคำขอทั้งหมดผ่านโมเดลอนุมาน มาเป็นการ "ส่งเฉพาะคำขอที่ตัวจำแนกประเภท (Classifier) ระบุว่าจำเป็นต้องใช้โมเดลอนุมานเท่านั้น" ซึ่งช่วยลดต้นทุนรายเดือนลงได้อย่างมากในขณะที่ยังคงรักษาความแม่นยำในส่วนที่สำคัญไว้ได้

→ ดูเพิ่มเติม: คู่มือการเพิ่มประสิทธิภาพต้นทุน LLM

เพื่อให้ PoC พร้อมสำหรับการตัดสินใจนำไปใช้งานจริง การออกแบบการประเมินที่สามารถ "อธิบายด้วยตัวเลข" สำหรับการทำ Inference-time scaling จึงเป็นสิ่งสำคัญ โดยต้องมีอย่างน้อย 4 แกนหลักดังนี้:

1. ความแม่นยำของงาน (Task Accuracy): อัตราความสำเร็จที่มีความหมายในเชิงธุรกิจ (เช่น ค่า F1 ของงานสกัดข้อมูล, อัตราความถูกต้องของคำตอบ, อัตราการมองข้ามข้อผิดพลาดในการรีวิว)
2. ต้นทุนต่อรายการ (Cost/Item): วัดต้นทุนการอนุมานจริงต่อ 1 รายการ (Input/Output + Thinking tokens + จำนวนการประมวลผลแบบขนาน)
3. P50 / P95 Latency: ใช้ค่าเปอร์เซ็นไทล์แทนค่าเฉลี่ย เพื่อดูว่าสามารถรองรับ SLA ของธุรกิจได้มากน้อยเพียงใด
4. การกระจายตัวของรูปแบบความล้มเหลว (Failure Mode Distribution): ประเภทของความล้มเหลวที่ยังคงอยู่ (การสกัดข้อมูลผิดพลาด, อาการหลอน (Hallucination), ความมั่นใจที่มากเกินไป) เพื่อตัดสินว่าสามารถใช้ระบบป้องกัน (Guardrail) ในขั้นตอนถัดไปจัดการได้หรือไม่

โดยใช้การสร้างคำตอบแบบครั้งเดียวโดยไม่มี Inference-time scaling เป็นเกณฑ์มาตรฐาน (Baseline) และออกแบบการเปรียบเทียบส่วนต่างในรูปแบบ "ความแม่นยำเพิ่มขึ้นกี่ % / ต้นทุนเพิ่มขึ้นกี่เท่า"

ควรเตรียมข้อมูลสำหรับการประเมินอย่างน้อย 100 รายการ และถ้าเป็นไปได้ควรมี 500 รายการขึ้นไป เพื่อป้องกันไม่ให้ระดับความยาก หมวดหมู่ และรูปแบบข้อยกเว้นมีความเอนเอียง ควรใช้วิธีการสุ่มแบบแบ่งชั้น (Stratified sampling) จากบันทึกการใช้งานจริง (Operational logs)

→ ที่เกี่ยวข้อง: AI Observability, คู่มือการประเมิน LLM-as-a-Judge

「หากเพิ่มปริมาณการคำนวณ ความแม่นยำจะเพิ่มขึ้นเสมอ」「หากนำไปติดตั้งเพิ่มในแอป LLM ที่มีอยู่เดิม จะช่วยยกระดับประสิทธิภาพได้」— ความคาดหวังที่รายล้อมเรื่อง Inference-time scaling (การขยายขนาดขณะประมวลผล) นั้น เต็มไปด้วยความเข้าใจผิดที่มักนำไปสู่ปัญหาเมื่อนำไปประยุกต์ใช้ในงานจริง

ในที่นี้ เราจะหยิบยกความเข้าใจผิดสองประการที่มักพบได้บ่อยในหน้างาน พร้อมทั้งสรุปแนวทางแก้ไขเพื่อหลีกเลี่ยงปัญหาดังกล่าว

การขยายขนาดขณะอนุมาน (Inference-time scaling) มีการเพิ่มขึ้นของความแม่นยำที่แตกต่างกันอย่างมาก ขึ้นอยู่กับการผสมผสานระหว่างงานและวิธีการ สัญชาตญาณที่ว่า "ความสัมพันธ์ระหว่างปริมาณการคำนวณและความแม่นยำนั้นเพิ่มขึ้นแบบทางเดียวโดยรวม" จะเป็นจริงได้ก็ต่อเมื่ออยู่ภายใต้เงื่อนไขที่จำกัดเท่านั้น

แนวโน้มที่ปรากฏให้เห็นจากรายงานการวิจัยและการตรวจสอบโดยชุมชนมีดังนี้:

• คณิตศาสตร์, การเขียนโค้ด, ตรรกศาสตร์เชิงรูปแบบ: ปรับปรุงอย่างเห็นได้ชัดด้วยการขยายขนาด
• การสนทนาแบบปลายเปิด, การสร้างสรรค์ผลงาน: มีบางสถานการณ์ที่ความแม่นยำถึงจุดอิ่มตัวหรือลดลง
• การตอบคำถามโดยอิงจากข้อเท็จจริง: ข้อมูลที่โมเดลไม่ทราบ ไม่สามารถสร้างขึ้นมาได้ด้วยการเพิ่มการคำนวณ (อาจทำให้เกิดอาการประสาทหลอนหรือ Hallucination มากขึ้น)

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

หากตัดสินใจลงทุนโดยตั้งสมมติฐานว่า "ยิ่งเพิ่มการคำนวณ ความแม่นยำยิ่งเพิ่มขึ้น" จะทำให้ต้นทุนในการถอนตัวสูงขึ้นเมื่อพบกับจุดอิ่มตัวหลังจากการนำไปใช้งานจริง การวัดค่าจุดอิ่มตัว (Saturation point) ให้เห็นจริงในขั้นตอน PoC จึงเป็นวิธีที่แน่นอนที่สุดในการหลีกเลี่ยงการลงทุนที่เกินความจำเป็น

→ เกี่ยวข้อง: รูปแบบความล้มเหลวในการสร้าง RAG

การเพิ่มการขยายขนาดขณะอนุมาน (Inference-time scaling) เข้าไปในแอป LLM ที่เปิดใช้งานจริงอยู่แล้วในภายหลัง มักจะก่อให้เกิดผลข้างเคียงที่ไม่คาดคิด นี่คือข้อควรระวังหลักๆ บางประการ:

• การละเมิด SLA ด้านความหน่วง (Latency SLA): ใน UI แชท การเพิ่มโทเค็นการคิด (Thinking tokens) เข้าไปทำให้การตอบกลับล่าช้าลงหลายวินาที ซึ่งส่งผลให้อัตราการเลิกใช้งานของผู้ใช้เพิ่มขึ้น
• โครงสร้างต้นทุนพังทลาย: การคาดการณ์ต้นทุนรายเดือนคลาดเคลื่อน ซึ่งไม่ใช่เรื่องแปลกที่จะพบปัญหานี้ก็ต่อเมื่อเห็นใบแจ้งหนี้แล้วเท่านั้น
• การสูญเสียความเข้ากันได้ของ Prompt: Prompt ที่มีอยู่เดิมไม่ได้ถูกปรับให้เหมาะสมกับโมเดลการอนุมาน (Inference model) ทำให้รูปแบบเอาต์พุตผิดเพี้ยนไป
• สินทรัพย์การทดสอบเสื่อมสภาพ: การทดสอบอัตโนมัติที่ตั้งอยู่บนสมมติฐานของการสร้างคำตอบแบบครั้งเดียวไม่สามารถผ่านการทดสอบได้

ในโครงการที่ผู้เขียนเคยมีส่วนร่วม หลังจากนำโมเดลการอนุมานมาใช้เสริมในการช่วยรีวิวโค้ด ผลปรากฏว่าเวลาในการทำ CI ยาวนานขึ้นอย่างมาก จนทำให้ทีมพัฒนาเกิดความไม่พอใจ ในท้ายที่สุดจึงต้องปรับเปลี่ยนโดยจำกัดขอบเขตการรีวิวไว้ที่ "เฉพาะการเปลี่ยนแปลงที่เกี่ยวข้องกับความปลอดภัยเท่านั้น" และให้ส่วนที่เหลือคงไว้กับโมเดลเดิม

หลักการสำคัญในการนำมาใช้งานคือ ต้องทำการทดสอบล่วงหน้าในกลุ่มย่อย (ผู้ใช้เฉพาะกลุ่ม หรือประเภทงานเฉพาะ) ก่อนที่จะขยายไปใช้กับทุกคำขอ โดยควรติดตั้ง Feature flag หรือเลเยอร์การกำหนดเส้นทาง (Routing layer) เพื่อให้สามารถสลับกลับเป็นแบบเดิมได้ทันที

→ ที่เกี่ยวข้อง: คู่มือการใช้งาน AI Guardrails

หลังจากนำ Inference-time scaling ไปใช้งานจริงแล้ว จำเป็นต้องสร้างวงจรการทำงานที่คอยติดตาม 3 แกนหลักอย่างต่อเนื่อง ได้แก่ ต้นทุน (Cost), ความหน่วง (Latency) และความแม่นยำ (Accuracy) พร้อมทั้งปรับแต่งค่าการทำงาน (Operational Knobs) อยู่เสมอ ไม่ใช่ว่าออกแบบเสร็จแล้วจบไป

สรุปประเด็นสำคัญที่ควรทราบในการใช้งานจริงมีดังนี้:

1. ข้อกำหนดขั้นต่ำในการสังเกตการณ์ (Observability)

• บันทึก Input/Output Tokens, Thinking Tokens และระดับการประมวลผลแบบขนาน (Parallelism) ของแต่ละคำขอลงใน Log
• ตรวจสอบ P50 / P95 / P99 Latency ตามช่วงเวลา และทำ Visualization เพื่อดูเงื่อนไขที่ทำให้เกิดค่าผิดปกติ (Outliers)
• วัดผล ตัวชี้วัดความแม่นยำแยกตามหมวดหมู่งาน อย่างต่อเนื่อง โดยใช้การสุ่มตัวอย่างร่วมกับการตรวจสอบโดยมนุษย์ หรือใช้ LLM-as-a-Judge

2. การออกแบบระบบแจ้งเตือน (Alerting)

• ตรวจจับทันทีเมื่อต้นทุนสูงเกินกว่าราคาที่คาดการณ์ไว้ 1.5 ถึง 2 เท่า
• แยกการตรวจสอบระบบขัดข้องหรือความหน่วงที่เพิ่มขึ้นจากฝั่ง Inference Model (ที่เกิดจากผู้ให้บริการ) ออกเป็นอีกระบบหนึ่ง
• ตรวจจับอัตราความผิดพลาดของรูปแบบผลลัพธ์ (เช่น JSON ล้มเหลว หรือโครงสร้างข้อมูลพัง) ที่พุ่งสูงขึ้นอย่างกะทันหัน

3. การออกแบบค่าการทำงาน (Operational Knobs)

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

• จำนวนการสุ่มตัวอย่างแบบขนาน (N)
• อัตราการใช้งาน Inference Model (การทำ Routing ที่สามารถสลับเปลี่ยนได้แบบ A/B Testing)
• เกณฑ์การจำแนกความยากง่ายของงาน
• โมเดลสำรอง (Fallback Model) ในกรณีที่ Inference Model หลักมีปัญหา

การจัดโครงสร้างให้สามารถเปลี่ยนค่าเหล่านี้ได้ผ่านไฟล์ตั้งค่า (Config File) หรือหน้าจอจัดการ จะช่วยให้รับมือกับเหตุขัดข้องหรือกรณีต้นทุนเกินได้อย่างรวดเร็ว

4. วงจรการปรับปรุง (Improvement Cycle)

ในทุกเดือนหรือทุกไตรมาส ให้ทบทวนสิ่งต่อไปนี้พร้อมกับการเปลี่ยนข้อมูลประเมินผล:

• ทบทวนวิธีการทำ Scaling (ว่าจะเพิ่มระดับการประมวลผลแบบขนาน หรือเปลี่ยนโมเดล)
• การเพิ่มหรือลดประเภทงานที่นำไปใช้
• การรองรับการอัปเดต Base Model (การตัดสินใจเปลี่ยนโมเดลเมื่อมีโมเดลใหม่เปิดตัว)

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

→ ที่เกี่ยวข้อง: AI Observability, คู่มือการวัด ROI ของ AI Agent

Inference-time scaling คือกลุ่มเทคนิคที่ช่วยกู้คืนประสิทธิภาพที่เริ่มถึงจุดอิ่มตัวในฝั่งการเรียนรู้ (Training) กลับคืนมาในฝั่งการอนุมาน (Inference) ไม่ใช่ว่า "ใช้แล้วจะดีขึ้นเสมอไป" แต่หัวใจสำคัญคือการตัดสินใจเชิงออกแบบที่ต้องเลือกใช้ให้เหมาะสมกับแต่ละกรณีการใช้งาน โดยคำนึงถึงสามเหลี่ยมความสมดุลระหว่างความยากของงาน ต้นทุน และความหน่วง (Latency)

ประเด็นสำคัญของบทความนี้มีดังนี้:

• Inference-time scaling แบ่งออกเป็น 3 สายหลัก ได้แก่ ภายใน (Internal), ขนาน (Parallel) และการค้นหา (Search) ซึ่งควรเลือกใช้ตามประเภทของงานและค่าความหน่วงที่ยอมรับได้
• การชะลอตัวของ Scaling Law ในฝั่งการเรียนรู้และการมาถึงของโมเดลการอนุมาน ทำให้คุณค่าเปลี่ยนไปอยู่ที่การปรับแต่งในฝั่งการอนุมาน
• ในการทำ PoC จำเป็นต้องมีการออกแบบเพื่อเปรียบเทียบความแม่นยำ ต้นทุน และความหน่วงเชิงปริมาณโดยเทียบกับค่าพื้นฐาน (Baseline)
• แนวคิดที่ว่า "ยิ่งเพิ่มการคำนวณ ความแม่นยำยิ่งเพิ่มขึ้น" นั้นมีเงื่อนไขกำกับ ต้องประเมินจุดอิ่มตัวและงานที่เหมาะสมให้ชัดเจน
• การเพิ่มเทคนิคนี้เข้าไปในแอปพลิเคชัน LLM ที่มีอยู่เดิมมักก่อให้เกิดผลข้างเคียงได้ง่าย ควรเริ่มทดสอบในส่วนเล็กๆ ก่อน
• ในการใช้งานจริง (Production) ต้องรวมการสังเกตการณ์ (Observability), การแจ้งเตือน (Alert), ปุ่มปรับแต่งการทำงาน (Operational knobs) และวงจรการปรับปรุงไว้เป็นส่วนหนึ่งของการออกแบบ

Inference-time scaling เป็นเครื่องมืออันทรงพลังที่จะเป็นจุดเริ่มต้นในการปรับโครงสร้างการออกแบบต้นทุนและความแม่นยำของ AI ในองค์กร ในฐานะที่เราให้การสนับสนุนการพัฒนา AI สำหรับ B2B เราได้สั่งสมองค์ความรู้จากการออกแบบเวิร์กโฟลว์การอนุมานที่เหมาะสมที่สุดสำหรับแต่ละกรณีการใช้งาน และพร้อมดูแลตั้งแต่ขั้นตอนการออกแบบ PoC ไปจนถึงการใช้งานจริง หากคุณกำลังประสบปัญหาในการตัดสินใจนำไปใช้หรือต้องการการตรวจสอบการออกแบบ สามารถดูข้อมูลเพิ่มเติมได้ที่ บริการที่ปรึกษาด้าน AI ของเรา