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

บทความนี้จัดทำขึ้นสำหรับนักพัฒนา, PdM และผู้บริหารที่นำ LLM มาใช้ในธุรกิจ B2B โดยจะรวบรวมแนวคิดพื้นฐานของ推論時スケーリング, เทคนิคหลัก, วิธีการนำไปประยุกต์ใช้กับ AI ในงานธุรกิจ, การออกแบบจุดสมดุลระหว่างต้นทุนและความแม่นยำ ไปจนถึงข้อควรระวังที่พบบ่อย เมื่ออ่านจบ คุณจะมีพื้นฐานที่เพียงพอในการตัดสินใจว่าควร "ใช้ / ไม่ใช้ / หรือใช้ในระดับใด" สำหรับ推論時スケーリング เพื่อให้เหมาะสมกับกรณีการใช้งาน (Use Case) ขององค์กรคุณ

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 といった手法がこの枠組みに含まれる。

従来の LLM 開発で主流だった学習時スケーリング（Pre-training Scaling）は、パラメータ数・学習データ量・学習計算量を増やせば性能が伸びる、という Scaling Law に基づく。しかし大規模学習はコスト・データ・電力の制約に直面しやすく、性能曲線も鈍化が指摘されている。

両者は対立する概念ではなく、補完関係にある。同じ基礎モデルを使っていても、推論時にどれだけ計算を投じるかで実用上の精度は大きく変わる。

→ 関連: LLM コスト最適化ガイド、ファインチューニングと RAG の選び方

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

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

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

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

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

学習側の Scaling Law が頭打ちと指摘される一方で、推論側にはまだ大きな伸びしろがある。さらに、業務 AI の用途が「定型応答」から「判断を伴う処理」へと広がり、精度要求が一段階上がっている。この二つの要因が、推論時スケーリングを実務上の重要なテーマへと押し上げた。

本セクションでは、学習スケーリングの限界と推論コスト最適化への流れ、そして業務 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 structure) พร้อมกับประเมินผลเพื่อเจาะลึกไปยังกิ่งก้านที่มีแนวโน้มดี

• Tree-of-Thoughts (ToT): ขยายกระบวนการคิดเป็นโครงสร้างต้นไม้ โดยประเมินแต่ละโหนดเพื่อเลือกกิ่งก้านที่มีแนวโน้มดี
• MCTS (Monte Carlo Tree Search): นำอัลกอริทึมการค้นหาที่ใช้ใน AI เกมมาประยุกต์ใช้กับการอนุมาน (Inference) โดยทำซ้ำขั้นตอนการจำลองและการประเมินผล
• Beam Search 拡張 (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 มากขึ้น)

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

หากตัดสินใจลงทุนโดยตั้งสมมติฐานว่า "ยิ่งเพิ่มการคำนวณ ความแม่นยำยิ่งเพิ่มขึ้น" จะทำให้ต้นทุนในการถอนตัวสูงขึ้นเมื่อพบกับจุดอิ่มตัวหลังจากการนำไปใช้งานจริง การวัดจุดอิ่มตัว (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 ของเรา