คุยกับ AI ตอนที่ 4: ทำไมคิดนานขึ้นจึงอาจตอบได้ดีขึ้น

ตอนที่ 4 จาก 11 ตอนในชุด คุยกับ AI: จากการ Train LLM ถึง AGI

บันทึกบทสนทนาระหว่าง นพ.สุทธิศักดิ์ เด่นดวงใจ กับ ChatGPT-5.6 Reasoning Instant จากแชตต้นฉบับ คงคำอธิบายและตัวอย่างของ ChatGPT ไว้ โดยปรับหัวข้อ ตาราง และสัญลักษณ์สมการให้อ่านบนเว็บได้สะดวก

ดูสารบัญทั้งชุด

ผม: เล่าต่อ

ChatGPT-5.6 Reasoning Instant:

ทีนี้มาถึงจุดที่ทำให้ LLM ยุคใหม่เริ่มดูไม่เหมือน autocomplete แล้วครับ 🧠⚙️

คำถามคือ:

ถ้า weights เท่าเดิม ทำไมให้โมเดล “คิดมากขึ้น” แล้วตอบดีขึ้นได้?

เพราะความฉลาดที่เราเห็นตอนใช้งานไม่ได้ขึ้นกับสิ่งที่ถูกเก็บใน weights อย่างเดียว แต่ขึ้นกับว่า เราอนุญาตให้โมเดลใช้ computation เพื่อหาคำตอบมากแค่ไหนตอน inference

เรียกว่า inference-time compute หรือ test-time compute

เริ่มจาก LLM ธรรมดาก่อน

สมมติถาม:

ร้านขายปากกา 17 บาท ดินสอ 8 บาท ซื้อปากกา 7 ด้ามกับดินสอ 13 แท่ง ต้องจ่ายเท่าไร?

วิธีตรง ๆ คือ:

17 × 7 = 119
8 × 13 = 104

119 + 104 = 223

แต่โมเดลไม่จำเป็นต้องสร้างขั้นตอนเหล่านี้ทั้งหมด มันอาจพยายามกระโดด:

Question
   ↓
Transformer
   ↓
"223 บาท"

โจทย์ง่ายก็ไม่มีปัญหา

แต่ถ้าเป็น:

วิเคราะห์ architecture นี้
หา race condition
ตรวจ security implications
เปรียบเทียบ 4 approaches
แล้วเสนอ migration plan

การกระโดดจากโจทย์ไป final answer ทันทีเริ่มอันตราย

ให้ computation เพิ่มทำอะไรได้?

แทนที่จะเป็น:

Problem
   ↓
Answer

สามารถเป็นแนวคิดประมาณ:

Problem
   ↓
Analyze
   ↓
Decompose
   ↓
Check assumptions
   ↓
Try solution
   ↓
Verify
   ↓
Revise
   ↓
Answer

จุดสำคัญคือ weights อาจเหมือนเดิม

แต่เส้นทาง computation ยาวขึ้น

เปรียบเทียบกับคนก็พอช่วยให้เห็นภาพ:

47 × 83 = ?

คุณอาจไม่ได้มี “สมองรุ่นใหม่” หลังจากหยิบกระดาษมา

แต่จาก:

คิดในหัว 1 วินาที

เปลี่ยนเป็น:

47 × 80 = 3760
47 × 3  = 141
3760 + 141 = 3901
ตรวจอีกครั้ง

ความน่าจะเป็นที่จะตอบถูกสูงขึ้น เพราะใช้ computation เพิ่ม

Reasoning model จึงไม่ได้หมายถึงแค่ "LLM ตัวใหญ่"

นี่เป็น distinction สำคัญ

เรามีสองแกน:

Training compute
      ↑
ใช้ตอนสร้างโมเดล

Inference compute
      ↑
ใช้ตอนตอบคำถาม

สมมติเชิงแนวคิด:

                 Inference Compute
                       ↑
                       │
             Reasoning │       ●
                       │
                       │
                       │
Normal assistant       │ ●
                       │
                       └────────────→
                         Training
                         capability

เราสามารถลงทุนเพิ่มได้ทั้งสองด้าน

แล้วมัน "คิด" อะไรอยู่?

ตรงนี้ต้องระวังคำ

เราไม่ควรจินตนาการว่ามีมนุษย์ตัวจิ๋วนั่งพูดใน neural network ว่า:

“อืม... วันนี้เราจะแก้สมการยังไงดีนะ”

😂

สิ่งที่เกิดจริงคือ computation ของ neural network และระบบ inference ที่ถูกออกแบบให้ใช้ขั้นตอน/ทรัพยากรมากขึ้นเพื่อไปถึง output ที่ดีขึ้น

รายละเอียดของ reasoning system ของแต่ละบริษัทก็ไม่เหมือนกัน และหลายส่วนไม่ได้เปิดเผย

แต่ในระดับ concept เราสามารถคิดได้ว่า:

Input
 ↓
intermediate computation
 ↓
evaluate possibilities
 ↓
refine
 ↓
Output

ตัวอย่างที่เห็นชัดมากคือ Programming

สมมติคุณบอก coding agent:

TidySpace สแกน NTFS MFT ช้า ช่วย optimize

ถ้าใช้วิธี:

Prompt
 ↓
LLM
 ↓
แก้ FileA.cs
 ↓
เสร็จ

โอกาสพังสูงมาก 💣

เพราะมันยังไม่รู้ด้วยซ้ำว่า bottleneck อยู่ตรงไหน

Agent ที่ดีกว่าควรทำ:

Read repository
      ↓
Find MFT scanner
      ↓
Trace call path
      ↓
Inspect allocations
      ↓
Inspect I/O pattern
      ↓
Form hypothesis
      ↓
Change implementation
      ↓
Build
      ↓
Benchmark/Test
      ↓
        FAIL?
       ↙    ↘
     Yes     No
      ↓       ↓
Investigate  Review diff
      ↓       ↓
    Fix    Final answer

สังเกตว่าตัว LLM ไม่จำเป็นต้องเปลี่ยน

สิ่งที่เพิ่มขึ้นคือ จำนวน interaction กับ environment และ computation

นี่คือ Agentic Loop

LLM ธรรมดา:

User → LLM → Answer

Agent:

             ┌──────────────┐
             │              ↓
User → LLM → Action → Result
        ↑              │
        └──────────────┘
             repeat

ตัวอย่าง:

LLM:
ต้องหา implementation ก่อน

→ search code

Result:
MftScanner.cs

LLM:
เปิดไฟล์

→ read file

Result:
...

LLM:
ตรงนี้ allocate byte[] ทุก record
ต้องตรวจว่า hot path จริงไหม

→ search usages

...

→ edit

→ build

Build failed

→ inspect compiler error

→ edit again

→ build

PASS

→ tests

PASS

นี่คือความแตกต่างมหาศาลระหว่าง:

LLM

กับ

AI Agent

Agent จึงมี "โลกภายนอก"

LLM ล้วน ๆ ถูกขังอยู่ในข้อความ:

        ┌─────────┐
Text →  │   LLM   │ → Text
        └─────────┘

Agent มีมือและตาเพิ่ม:

              ┌───────────┐
              │    LLM    │
              └─────┬─────┘
                    │
       ┌────────────┼─────────────┐
       ↓            ↓             ↓
     Files        Browser        Shell
       ↓            ↓             ↓
     Code          Web          Program
       │            │             │
       └────────────┼─────────────┘
                    ↓
                 Results
                    │
                    └────→ LLM

และเครื่องมืออาจรวมถึง:

Git
GitHub
Compiler
Tests
Database
Email
Calendar
AWS
Browser
APIs
Python
...

ดังนั้นความสามารถของระบบทั้งหมดไม่ได้เท่ากับความสามารถของ LLM เพียงอย่างเดียว

นี่ทำให้เกิดสมการที่ผมอยากให้จำ

แบบไม่ใช่สมการวิชาการนะครับ แต่ใช้คิดได้ดี:

AI System Capability
≈
Model
× Context
× Tools
× Compute
× Feedback

โมเดลเก่งมากแต่ไม่มีข้อมูล:

Great Model × Bad Context
             ↓
          🤷

โมเดลเก่งแต่ใช้ข้อมูลเก่า:

Great Model × Stale Data
             ↓
        Confident nonsense

โมเดลเก่ง + repository + compiler:

Model
 + Code Search
 + Compiler
 + Tests
 + Git
 + Iteration
        ↓
Coding Agent

นี่คือเหตุผลที่การเปรียบเทียบ AI ด้วย benchmark ของ model อย่างเดียว เริ่มไม่พอสำหรับงาน agentic

Verification สำคัญมาก

LLM มีปัญหาพื้นฐานอย่างหนึ่ง:

มันสามารถสร้างคำตอบที่ฟังดูน่าเชื่อได้ แม้คำตอบจะผิด

แต่ถ้ามี environment ตรวจได้ เราสามารถเปลี่ยนโจทย์ได้

จาก:

LLM:
"ผมคิดว่า code นี้ compile ได้"

เป็น:

LLM
 ↓
write code
 ↓
dotnet build
 ↓
Compiler:
CS1503 ...

ตอนนี้ไม่ต้อง “เชื่อ” LLM แล้ว

Compiler เป็นกรรมการ 🧑‍⚖️

แก้อีกครั้ง:

LLM
 ↓
Fix
 ↓
dotnet build
 ↓
PASS
 ↓
dotnet test
 ↓
137 passed
 ↓
ตรวจ diff

นี่ทรงพลังกว่าการเพิ่มความฉลาดของโมเดลอย่างเดียวเสียอีก

Reinforcement Learning กลับมาอีกครั้งตรงนี้

จำตอนแรกที่เราคุยเรื่อง training ได้ไหม:

Model
 ↓
Output
 ↓
Reward
 ↓
ปรับ weights

ถ้าเราสามารถสร้าง environment ที่มีคำตอบตรวจสอบได้ เช่น:

Math
Coding
Games
Formal proofs

เราสามารถให้ reward ได้ค่อนข้างชัด

เช่น coding:

Generated patch
      ↓
Tests
      ↓
150/150 PASS
      ↓
Reward ↑

หรือ:

Generated patch
      ↓
Tests
      ↓
73 failures
      ↓
Reward ↓

จึงมี feedback ที่ดีกว่าแค่ถามมนุษย์ว่า:

“คำตอบนี้ดูดีไหม?”

แล้วทำไม Math กับ Code ถึงสำคัญกับการ Train reasoning?

เพราะมีสิ่งที่เรียกว่า verifiable rewards

โจทย์:

Solve:
x² - 5x + 6 = 0

ตรวจได้ว่า:

x = 2, 3

Code:

Implement function X

ตรวจด้วย:

unit tests

Chess:

win / lose

Formal theorem:

proof valid / invalid

จึงสร้าง training signal ที่คมมาก

โลกจริงอย่าง:

“ออกแบบ architecture ที่ดีที่สุด”

ตรวจยากกว่ามาก เพราะไม่มี:

ArchitectureTests.exe

PASS: This is objectively the best architecture.

น่าเสียดาย 😆

แล้ว "Thinking level" ที่คุณเห็นใน ChatGPT คืออะไร?

ในระดับ product concept การเลือกให้ระบบใช้ reasoning มากขึ้น หมายถึงยอมแลก:

Compute ↑
Latency ↑
Cost ↑

เพื่อเพิ่มโอกาสได้:

Analysis quality ↑
Planning ↑
Verification ↑
Complex problem solving ↑

จึงไม่ควรใช้ระดับสูงสุดกับทุกอย่าง

ถาม:

“HTTP 404 คืออะไร?”

ไม่จำเป็นต้องส่ง AI เข้าถ้ำไปนั่งสมาธิ 40 นาที 🧘

แต่:

“วิเคราะห์ architecture ของ HealthTAG ทั้งระบบ แล้วออก migration plan โดยห้าม downtime”

ตรงนี้ reasoning budget เพิ่มมีประโยชน์มาก

และนี่นำไปสู่แนวคิดที่ใหญ่กว่า "Model"

เมื่อก่อนเราคิดว่า:

Better AI
=
Bigger model

ตอนนี้ภาพเริ่มเป็น:

Better AI System
=
Good Model
+
Reasoning Compute
+
Context Management
+
Memory
+
Retrieval
+
Tools
+
Environment
+
Verification
+
Agent Loop

และคุณจะเห็นว่าหลายอย่าง ไม่ได้อยู่ใน neural network เลย

นี่สำคัญมาก

ลองเอาทุกตอนที่เราเรียนมาประกอบกัน

ตอนนี้ภาพทั้งหมดเป็น:

                    TRAINING
                       │
          ┌────────────▼────────────┐
          │       Training Data     │
          └────────────┬────────────┘
                       ↓
                Token prediction
                       ↓
                  Backprop
                       ↓
                Update weights
                       ↓
              ┌────────────────┐
              │      LLM       │
              │ Transformer    │
              │    Weights     │
              └───────┬────────┘
                      │
══════════════════════╪══════════════════════
                      │
                  INFERENCE
                      │
             ┌────────▼────────┐
             │     Context     │
             │ prompt / files  │
             │ retrieved info  │
             └────────┬────────┘
                      ↓
              ┌────────────────┐
              │      LLM       │
              └───────┬────────┘
                      ↓
                 Reasoning
                      ↓
               Need a tool?
                  ↙       ↘
                Yes        No
                 ↓          ↓
        ┌────────────────┐  │
        │ Web / Code /   │  │
        │ Git / DB / API │  │
        └───────┬────────┘  │
                ↓           │
              Result        │
                ↓           │
                └─────┬─────┘
                      ↓
                   Verify
                      ↓
               Good enough?
                 ↙       ↘
               No         Yes
               ↓           ↓
             Loop        Answer

นี่ใกล้เคียงกับ mental model ของ AI system สมัยใหม่มากกว่าคำว่า “chatbot” เยอะ

และยังเหลือจิ๊กซอว์ชิ้นใหญ่ที่สุดอีกชิ้น 🧩:

ตอน Train จริง ๆ เราเอา GPU เป็นหมื่นตัวมาทำอะไร? Parameters หลายแสนล้านตัวอยู่ตรงไหน? ทำไมต้องใช้ VRAM มหาศาล? FP32, BF16, FP8 คืออะไร? Tensor Parallel, Data Parallel และ MoE คืออะไร?

ถ้าเข้าเรื่องนี้ต่อ คุณจะเริ่มเห็นระดับ hardware/infrastructure ว่า LLM จากสมการ ทาย token ถัดไป กลายเป็น data center ที่กินไฟระดับมหึมาได้อย่างไรครับ ⚡🏭

← ตอนก่อนหน้า: Context, Attention และความจำระหว่างคุย

ตอนถัดไป: GPU, VRAM และโครงสร้างพื้นฐานที่ใช้ฝึก LLM →

อ่านทั้งชุด

กลับไปหน้าบันทึกและบทความ