คุยกับ AI ตอนที่ 9: จาก LLM สู่ระบบ AI และ Agent

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

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

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

ผม: เล่าต่อ

ChatGPT-5.6 Reasoning Instant:

ได้ครับ คราวนี้เราจะประกอบทุกอย่างเข้าด้วยกันว่า ตั้งแต่คุณกด Send จนเห็นคำตอบ มันเกิดอะไรขึ้นบ้าง และแยก LLM, Model, AI System, Agent ให้ออกจากกัน 🧠🏭

LLM ≠ ChatGPT

นี่คือจุดแรกที่ต้องล็อก mental model ให้แน่น

LLM คือ neural network ที่เราคุยกันมาตลอด:

Tokens
  ↓
Embeddings
  ↓
Transformer × N
  ↓
Logits
  ↓
Next token

มันคือเครื่องยนต์

ส่วนผลิตภัณฑ์ AI ที่เราใช้งานมีของล้อมรอบอีกมาก:

┌──────────────────────────────┐
│          AI SYSTEM           │
│                              │
│   Memory      Retrieval      │
│      ↘           ↙           │
│       Context Builder        │
│             ↓                │
│        ┌─────────┐           │
│        │   LLM   │           │
│        └────┬────┘           │
│             ↓                │
│       Tool Calling           │
│             ↓                │
│ Web / Code / Files / APIs    │
│             ↓                │
│        Verification          │
│             ↓                │
│          Response            │
└──────────────────────────────┘

ดังนั้นเวลา AI ตอบเก่งขึ้น อาจไม่ได้หมายความว่า neural network เก่งขึ้นเพียงอย่างเดียว

ระบบรอบตัวมันอาจดีขึ้นด้วย

แยกศัพท์ 4 ตัวนี้ก่อน

ผมจะใช้คำแบบ practical:

LLM คือ neural network ที่ประมวลผล tokens

Model มักหมายถึงโมเดลที่ถูก train/post-train จนพร้อมใช้งาน แม้ในผลิตภัณฑ์จริงคำนี้อาจถูกใช้กว้างกว่านั้น

AI System คือ model + infrastructure + context + tools + retrieval + safety + serving ฯลฯ

Agent คือ AI system ที่สามารถวนรอบ คิด → ทำ → ดูผล → ปรับ → ทำต่อ เพื่อบรรลุเป้าหมาย

จึงได้ลำดับประมาณ:

LLM
 ↓
Model
 ↓
AI System
 ↓
Agent

ไม่ใช่มาตรฐานนิยามตายตัว แต่เป็น mental model ที่มีประโยชน์มาก

ทีนี้คุณกด Send

สมมติคุณพิมพ์:

ช่วยดู repository นี้แล้วหา bug ให้หน่อย

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

มันต้องสร้าง context

ประมาณ:

System instructions
        +
Developer instructions
        +
Relevant conversation
        +
User message
        +
Potential memory/context
        +
Tool definitions
        ↓
     Context

นี่เป็นเหตุผลว่าทำไม model เดียวกันสามารถมี behavior ต่างกันมากในผลิตภัณฑ์ต่างกัน

System Prompt อยู่ตรงนี้

เช่น conceptual:

SYSTEM:
You are an AI assistant.

Follow these rules...

แล้วอาจมี tool definitions:

Available tools:

search_web(...)
read_file(...)
run_command(...)
...

แล้ว conversation:

USER:
We're working on TidySpace.

ASSISTANT:
...

USER:
Find the MFT performance problem.

ทั้งหมดกลายเป็น context ที่โมเดลใช้ inference

ไม่มี training เกิดขึ้นตรงนี้

จากนั้นอาจมี Context Management

สมมติ conversation ยาว 500,000 tokens แต่ model/system ไม่ต้องการส่งทุกอย่างเข้าไปตรง ๆ

ระบบอาจเลือก:

Recent conversation
        +
Relevant older information
        +
Summary
        +
Retrieved documents

แทน:

EVERYTHING SINCE THE DAWN OF TIME

😆

เพราะ context มีต้นทุน

และข้อมูลเยอะเกินไปไม่ได้แปลว่าดีกว่าเสมอ

แล้ว Routing คืออะไร?

AI system สมัยใหม่อาจมีการตัดสินใจก่อนว่า request นี้ควรจัดการอย่างไร

เช่น:

              User request
                    ↓
                 Router
          ┌─────────┼─────────┐
          ↓         ↓         ↓
        simple    coding    complex
          ↓         ↓         ↓
       path A     path B     path C

หรืออาจตัดสินใจ:

Need web?
Need tools?
Need deeper reasoning?
Need image generation?
Need retrieval?

รายละเอียดจริงเป็น implementation-specific และไม่ได้หมายความว่าทุกผลิตภัณฑ์ต้องมี router แบบเดียวกัน

แต่ concept สำคัญคือ:

สิ่งที่ผู้ใช้มองว่าเป็น “AI ตัวหนึ่ง” อาจมี orchestration อยู่ข้างหลัง

สมมติ request ต้องใช้ Repository

ถ้า LLM ไม่มี access repository แล้วถาม:

MftScanner.cs มี bug ตรงไหน?

มันมีสองทาง

ทางแย่:

ไม่มีไฟล์
 ↓
เดา
 ↓
ตอบอย่างมั่นใจ

☠️

ทางที่ถูก:

Need repository
     ↓
Use file/code tool
     ↓
Search "MftScanner"
     ↓
Receive actual code

ผลจาก tool ถูกนำกลับมาเป็น context

TOOL RESULT:

MftScanner.cs

public async Task...

จากนั้น LLM inference อีกครั้ง

ตรงนี้ Agent เริ่มเกิด

LLM อาจเห็น code แล้วคิดว่า:

ต้องหา caller

จึงเรียก tool:

search("MftScanner")

ได้:

DiskAnalyzer.cs
ScanService.cs
...

อ่านต่อ

read("DiskAnalyzer.cs")

แล้วอาจพบ:

ทุก MFT record
→ allocate buffer
→ parse
→ throw away

ตั้ง hypothesis ว่า allocation อาจเป็น bottleneck

แต่ agent ที่ดีไม่ควรประกาศชัยชนะทันที 🏁

มันควรหาหลักฐานต่อ

Agent Loop จึงเป็นแบบนี้

        ┌──────────────────────┐
        │                      │
        ▼                      │
      MODEL                    │
        │                      │
        ▼                      │
 Decide next action            │
        │                      │
        ▼                      │
      TOOL                     │
        │                      │
        ▼                      │
     RESULT                    │
        │                      │
        ▼                      │
 Update context ───────────────┘

วนไปจน:

Goal achieved

หรือ:

Budget exhausted
Need user input
Blocked
Error

Coding Agent จึงไม่ใช่ "LLM เขียน code"

จริง ๆ ควรคิดว่า:

              LLM
               │
     ┌─────────┼─────────┐
     ↓         ↓         ↓
   Search     Editor    Shell
     │         │         │
     ↓         ↓         ↓
   Source     Files    Compiler
                         │
                         ↓
                       Tests
                         │
                         ↓
                       Result
                         │
                         └────→ LLM

สิ่งที่ทำให้มันเก่งไม่ใช่แค่รู้ C#

แต่คือความสามารถในการ:

inspect
→ reason
→ modify
→ execute
→ observe
→ debug
→ verify

Compiler เป็น Superpower ของ Coding Agent

นี่เป็นเหตุผลที่ coding เป็น domain ที่ AI agents ไปได้เร็วมาก

สมมติ model เขียน:

int x = "hello";

ไม่ต้องมีมนุษย์บอกว่าผิด

dotnet build
      ↓
CS0029
Cannot implicitly convert type
'string' to 'int'

โลกภายนอกส่ง feedback ที่ objective กลับมา

Agent:

Error
 ↓
Understand
 ↓
Fix
 ↓
Build again

นี่คือ feedback loop ที่ยอดเยี่ยม

Web Search ก็เหมือนกัน

ถาม:

CEO ของบริษัท X ตอนนี้คือใคร?

ไม่ควรเป็น:

LLM weights
 ↓
"จำได้ว่า..."

ควรเป็น:

Question
 ↓
Current information required
 ↓
Search
 ↓
Official/reliable source
 ↓
Read
 ↓
Synthesize
 ↓
Cite
 ↓
Answer

ความสามารถจึงเปลี่ยนจาก:

recall

เป็น:

research

ต่างกันเยอะมาก

RAG ก็เป็น Tool แบบหนึ่งในภาพใหญ่

User:
บริษัทให้วันลากี่วัน?
       ↓
Search internal documents
       ↓
Employee-Handbook-2026.pdf
       ↓
Relevant section
       ↓
LLM
       ↓
"12 วัน ตาม handbook..."

LLM ไม่ต้อง memorize handbook

และปีหน้า:

Employee-Handbook-2027.pdf

ก็ใช้ข้อมูลใหม่ได้โดยไม่ train model ใหม่

Memory ก็เป็น External System

เช่น conceptual:

Conversation A
     ↓
Relevant information
     ↓
External memory

เดือนหน้า:

New conversation
      ↓
Retrieve relevant memory
      ↓
Context
      ↓
LLM

ดังนั้น:

Memory
≠
Weights

อันนี้ควรจำไว้เลย

แล้ว Reasoning อยู่ตรงไหน?

บาง request:

2+2?

เส้นทางอาจสั้น:

Input
 ↓
Model
 ↓
4

แต่โจทย์:

วิเคราะห์ distributed architecture นี้แล้วออก migration plan

ระบบอาจยอมใช้ inference-time computation มากขึ้น

conceptually:

Problem
 ↓
Decompose
 ↓
Analyze dependencies
 ↓
Consider alternatives
 ↓
Check constraints
 ↓
Find contradictions
 ↓
Refine plan
 ↓
Answer

จึงใช้:

same/similar learned capabilities
+
more computation

เพื่อเพิ่มคุณภาพ

Verification คือชั้นที่ผมอยากเน้นที่สุด

ระบบ AI ที่ดีไม่ควรถามแค่ว่า:

“โมเดลมั่นใจไหม?”

เพราะ LLM สามารถมั่นใจและผิดได้พร้อมกันอย่างสง่างาม 🎩

ควรถามว่า:

ตรวจจากอะไรได้บ้าง?

เช่น:

Claim about web
→ source

Code
→ build/test

Calculation
→ calculator/code

Database state
→ query database

File
→ read actual file

จึงได้ principle ที่ใช้ได้กว้างมาก:

ใช้ LLM สำหรับ reasoning และ synthesis แต่ใช้แหล่งความจริงภายนอกเมื่อสิ่งนั้นตรวจสอบได้

แล้ว Serving Infrastructure ล่ะ?

ข้างหลังยังมีอีกโลกหนึ่ง

เมื่อ request พร้อมเข้า model:

Request
   ↓
Inference server
   ↓
Scheduler
   ↓
GPU cluster

แต่คุณไม่ได้ใช้ GPU คนเดียว

อาจมี requests จำนวนมาก:

User A ─┐
User B ─┤
User C ─┼→ Scheduler → GPUs
User D ─┤
User E ─┘

ระบบต้องพยายามใช้ GPU ให้คุ้ม

เช่น batching requests บางส่วนเข้าด้วยกัน

Continuous Batching

สมมติ:

User A: generating token 123
User B: generating token 51
User C: just arrived

แทนที่จะรอ A จบก่อน:

A A A A A A ... finish
B B B B ...
C ...

inference engine สามารถจัด batch แบบ dynamic:

Step 1:
[A][B][C]

Step 2:
[A][B][C]

B finished

Step 3:
[A][D][C]

ทำให้ accelerator utilization ดีขึ้น

นี่เป็นอีกโลกของ engineering ที่ผู้ใช้ไม่เห็น

Latency ที่คุณรู้สึกจึงมีหลายส่วน

เวลาคุณกด Send:

Total latency
=
Network
+
Context preparation
+
Routing
+
Queue
+
Prefill
+
Reasoning
+
Tool calls
+
Decode

จึงมี metric สำคัญอย่าง:

Time To First Token

กด Send จนเห็น token แรก

กับ

Tokens per second

หลังจากเริ่มตอบแล้ว ข้อความไหลเร็วแค่ไหน

สองอย่างนี้คนละเรื่อง

บางระบบ:

รอ 10 sec...
↓
จากนั้นพรึ่บพรั่บเร็วมาก

อาจมี TTFT สูงแต่ decode throughput ดี

ทีนี้ลองประกอบ ChatGPT-like system ทั้งตัว

ภาพ conceptual:

                     YOU
                      │
                      ▼
                 User Prompt
                      │
                      ▼
             ┌─────────────────┐
             │ Product Layer   │
             └────────┬────────┘
                      │
          ┌───────────┼───────────┐
          ↓           ↓           ↓
       Memory      Retrieval    Safety/
                               Policies
          │           │           │
          └───────────┼───────────┘
                      ▼
              Context Builder
                      │
                      ▼
                  Routing
                      │
                      ▼
              ┌─────────────┐
              │    MODEL    │
              │             │
              │ Transformer │
              │   Weights   │
              └──────┬──────┘
                     │
                     ▼
                  Decide
              answer or action?
                 ↙       ↘
             Action      Answer
                ↓
       ┌──────────────────┐
       │      TOOLS       │
       │                  │
       │ Web              │
       │ Files            │
       │ Code             │
       │ APIs             │
       │ Database         │
       └────────┬─────────┘
                │
                ▼
              Result
                │
                └────────────→ Model
                                │
                              loop
                                │
                                ▼
                           Final response
                                │
                                ▼
                              YOU

รายละเอียดของผลิตภัณฑ์จริงอาจต่างจากแผนภาพนี้ แต่ mental model นี้ใกล้ความเป็นจริงกว่า:

User → Magic AI → Answer

มาก

และนี่อธิบายสิ่งสำคัญมากเกี่ยวกับอนาคต AI

เราเริ่มต้นบทสนทนานี้จาก:

Train LLM คืออะไร?

ตอนแรกดูเหมือนคำตอบคือ:

More data
+
More GPUs
+
Bigger neural network
=
Better AI

ตอนนี้จะเห็นแล้วว่ามันไม่พอ

ภาพจริงใกล้กับ:

                 TRAINING
                    │
                    ▼
              Better Model
                    │
                    ▼
┌─────────────────────────────────┐
│           AI SYSTEM             │
│                                 │
│ Model                           │
│ + Reasoning compute             │
│ + Context management            │
│ + Memory                        │
│ + Retrieval                     │
│ + Tools                         │
│ + Verification                  │
│ + Agent loops                   │
│ + Serving infrastructure        │
└─────────────────────────────────┘
                    │
                    ▼
                Capability

และตรงนี้นำไปสู่คำถามใหญ่ที่กำลังเป็นหัวใจของวงการ:

ถ้าเรามี compute เพิ่มอีก 100 เท่า ควรเอาไป Train model ให้ใหญ่/เก่งขึ้น หรือเอา compute นั้นมาให้ model เดิม “คิด ทำ ทดลอง และตรวจคำตอบ” ตอน inference?

นี่คือเรื่องของ Scaling Laws, Training-time scaling vs Inference-time scaling และเหตุผลว่าทำไมเส้นทางสู่ AI ที่เก่งขึ้นอาจไม่ได้มีแค่การสร้าง Transformer ที่ใหญ่ขึ้นเรื่อย ๆ

ตรงนั้นเป็นบทต่อที่ดีมาก เพราะเราจะเริ่มตอบได้ว่า “ทำไม AI ถึงพัฒนารวดเร็ว ทั้งที่เราไม่ได้เพิ่ม parameter อย่างบ้าคลั่งทุก generation?” 🚀

← ตอนก่อนหน้า: ตาม token ผ่าน Transformer ทีละขั้น

ตอนถัดไป: เพิ่ม compute ให้ตอนฝึกหรือตอนตอบ →

อ่านทั้งชุด

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