ทุกวันนี้คนส่วนใหญ่ใช้ ChatGPT, Claude, Gemini, Cursor หรือ AI ผู้ช่วยเขียนโค้ดกันทุกวัน เขียน prompt ได้คำตอบ แล้วก็คิดว่าแค่นี้พอแล้ว แต่ในโปรดักต์จริง วิธีนี้พังเร็วมาก: โมเดลทำตัวคาดเดาไม่ได้ ไม่ทำตามคำสั่ง “ลืม” context เผางบ API และให้ผลลัพธ์ไม่นิ่ง
ปัญหาไม่ได้อยู่ที่คุณภาพของโมเดล ปัญหาคือคนใช้มันแบบงมโข่ง โดยไม่เข้าใจว่าเบื้องหลังมันทำงานอย่างไร
บทความนี้แกะหลักการพื้นฐานของ LLM ตั้งแต่ token และ attention ไปจนถึง context window ต้นทุนการสร้างคำตอบ เอเจนต์ และ context engineering นี่ไม่ใช่คอร์ส ML และไม่ใช่คณิตศาสตร์ แต่เป็นความเข้าใจเชิงวิศวกรรมที่ส่งผลตรง ๆ ต่อความเสถียร ความเร็ว และต้นทุนของระบบโปรดักชัน
Prompt ไม่ใช่สถาปัตยกรรม
ความเข้าใจผิดที่เจอบ่อย: ถ้าเขียน prompt เก่งพอ โมเดลจะ “ทำงานได้เอง” ในทางปฏิบัติ prompt เป็นแค่ชั้นบนสุดของการควบคุม เหมือนพวงมาลัยรถ: สำคัญก็จริง แต่ถ้าไม่เข้าใจเครื่องยนต์ เบรก และเกียร์ ก็ไปได้ไม่ไกล
ในโปรดักชัน ความผิดพลาดมีราคาแพง คุณอาจใช้เวลาหลายสัปดาห์สร้างระบบที่บางทีก็ทำงาน บางทีก็ไม่ คุณอาจเผาเงินค่า API วันละหลายร้อยดอลลาร์โดยไม่รู้ตัว แค่เพราะไม่เข้าใจว่าตรงไหนต้องใช้แคช ตรงไหนควรใช้โมเดลโลคัล และตรงไหนต้องเปลี่ยนแนวทางสถาปัตยกรรม
ความต่างระหว่าง “บางทีก็ทำงาน” กับ “ทำงานได้อย่างน่าเชื่อถือ” คือความเข้าใจแนวคิดพื้นฐานของ LLM
Token: ทำไมคำจึงเป็นหน่วยวัดที่แย่
ความผิดพลาดแรก ๆ คือคิดว่าโมเดลทำงานกับคำ ซึ่งไม่ใช่
Token คือหน่วยพื้นฐานของข้อความสำหรับโมเดลภาษา token อาจเป็น:
- คำทั้งคำ
- ส่วนหนึ่งของคำ
- ตัวอักษรหนึ่งตัว
- หรือตัวอักษรหลายตัวรวมกัน
คำเดียวกันอาจถูกตัดเป็นจำนวน token ไม่เท่ากันในแต่ละโมเดล เช่น คำยาว ๆ ในภาษารัสเซียคำหนึ่ง ใน tokenizer ตัวหนึ่งอาจกลายเป็น 3 token อีกตัวเป็น 6 และอีกตัวเป็น 15–17
เรื่องนี้สำคัญมากด้วยสามเหตุผล:
- ต้นทุน
- API ทุกเจ้าคิดเงินตาม token ยิ่ง token เยอะ คำขอก็ยิ่งแพง
- Context window
- โมเดลไม่ได้เห็น “ข้อความ” แต่เห็น token ในจำนวนที่จำกัด ในโมเดลยอดนิยม ภาษารัสเซียมักใช้ token มากกว่าภาษาอังกฤษ 1.5–2 เท่า เพราะโมเดลส่วนใหญ่ฝึกด้วยข้อมูลภาษาอังกฤษเป็นหลัก
- ความเร็ว
- ยิ่ง token เยอะ ก็ยิ่งประมวลผลช้า
ตัวอย่างเช่น context window ขนาด 128,000 token เท่ากับประมาณ:
- ข้อความภาษาอังกฤษ 250–300 หน้า
- หรือแค่ 100–150 หน้าถ้าเป็นเนื้อหาเท่ากันในภาษารัสเซีย
Attention: โมเดลเข้าใจความหมายได้อย่างไร
ลองดูประโยคง่าย ๆ นี้:
“นักพัฒนาระดับซีเนียร์มองโค้ด แล้วมันก็พัง”
คนเข้าใจได้เองว่า “มัน” หมายถึงโค้ด ไม่ใช่นักพัฒนา โมเดลก็ทำแบบเดียวกัน ผ่านกลไก self-attention
กลไก attention ทำงานแบบนี้:
- token แต่ละตัวมองไปยัง token ก่อนหน้าทั้งหมด
- คำนวณน้ำหนักของความเชื่อมโยง
- ตัดสินว่าตัวไหนสำคัญที่สุดสำหรับขั้นตอนปัจจุบัน
แต่มันไม่ได้เกิดขึ้นแค่ครั้งเดียว
Multi-head attention
โมเดลยุคใหม่ใช้ attention head หลายสิบหัว ในแต่ละเลเยอร์ซึ่งก็มีหลายสิบเลเยอร์ “หัว” แต่ละหัวมองข้อความจากมุมของตัวเอง
เทียบกับการรีวิวโค้ด:
- “หัว” หนึ่งหาความเชื่อมโยงทางไวยากรณ์
- อีกหัวติดตามชนิดข้อมูล
- หัวที่สามวิเคราะห์ business logic
ทุกหัวทำงานพร้อมกัน แล้วผลลัพธ์ของทุกหัวก็รวมกันเป็นภาพรวมเดียว
ที่สำคัญ: ความถนัดของ attention head แต่ละหัว ไม่ได้ถูกกำหนดไว้ล่วงหน้า แต่เกิดขึ้นเองระหว่างการฝึก
ทำไม transformer จึงชนะ
ก่อนมี transformer เราใช้ recurrent neural network ซึ่งอ่านข้อความไปตามลำดับทีละคำ ช้าและขยายสเกลได้ไม่ดี
Transformer ประมวลผล token ทั้งหมดพร้อมกัน ด้วยกลไก attention ซึ่ง:
- ทำให้การฝึกเร็วขึ้นแบบก้าวกระโดด
- ทำให้ขยายโมเดลไปถึงหลายร้อยพันล้านพารามิเตอร์ได้
- กลายเป็นรากฐานของ LLM สมัยใหม่ทั้งหมด: GPT, Claude, LLaMA, Gemini
แต่ transformer มีปัญหาพื้นฐานอยู่ข้อหนึ่ง
ความซับซ้อนแบบกำลังสองและราคาของ context ยาว ๆ
Attention เชื่อม token ทุกตัวเข้ากับทุกตัว
- 2,000 token: คำนวณ ~4 ล้านครั้ง
- 4,000 token: คำนวณ ~16 ล้านครั้ง
Context ยาวขึ้นสองเท่า การคำนวณเพิ่มขึ้น สี่เท่า
ผลที่ตามมา:
- context ยาว = ช้า
- context ยาว = แพง
- context หลายแสนหรือหลายล้าน token ยังเป็นโจทย์ยากทางวิศวกรรม
เพราะอย่างนี้จึงเริ่มมีสถาปัตยกรรมแบบไฮบริดและแนวทางใหม่ ๆ แต่ตอนนี้ transformer ยังเป็นมาตรฐานโดยพฤตินัย และถ้าวันนี้คุณใช้เครื่องมือ AI อยู่ เบื้องหลังก็คือ transformer
Context window คือหน่วยความจำทำงานของโมเดล
Context window คือ สิ่งที่โมเดลเห็นได้พร้อมกันในครั้งเดียว นึกภาพเป็นโต๊ะทำงานจะเข้าใจง่าย
- โต๊ะเล็ก (4,000 token): แล็ปท็อปกับกาแฟหนึ่งแก้ว
- โต๊ะใหญ่ (200,000 token): จอหลายจอ หนังสือ โน้ต หูฟัง
แต่โต๊ะรกเร็วมาก
สิ่งที่เข้าไปอยู่ใน context:
- system prompt
- ประวัติบทสนทนา
- คำขอปัจจุบัน
- คำตอบของโมเดล (ซึ่งต่อมาก็จะกลายเป็นส่วนหนึ่งของประวัติด้วย)
ใน AI ผู้ช่วยยังมีมากกว่านั้นอีก:
- คำอธิบาย tools
- ไฟล์ที่เปิดอยู่
- output ของคำสั่ง
- ผลการค้นหา
- ประวัติการกระทำ
ตัวอย่างจริง:
ห้าไฟล์ ไฟล์ละ 200 บรรทัด + คำสั่งเทอร์มินัลอีกไม่กี่คำสั่ง = 15,000 token ในขั้นตอนเดียวของเอเจนต์
รู้ได้อย่างไรว่า context เต็ม
อาการที่เจอบ่อย:
- คำตอบขาดกลางคัน
- โมเดลลืมคำสั่งตอนเริ่มต้น
- ทำขั้นตอนที่ทำไปแล้วซ้ำ
- ขอเปิดไฟล์ที่เคยเปิดไปแล้วอีกรอบ
ผู้ช่วยส่วนใหญ่จะสรุปบทสนทนาส่วนเก่าให้อัตโนมัติ สะดวกแต่อันตราย: ตอนสรุป การตัดสินใจเชิงสถาปัตยกรรม เหตุผลของการแก้ไข และบริบทของการกระทำจะหายไป
การบีบอัดอัตโนมัติเป็นแค่การแก้ขัด ไม่ใช่ทางแก้จริง
Prefill และ Decode: ทำไมคำตอบจึงพิมพ์ออกมาทีละคำ
การสร้างคำตอบมีสองขั้นที่ต่างกันโดยสิ้นเชิง
1. Prefill (โหลดล่วงหน้า)
โมเดลประมวลผล prompt ขาเข้าทั้งหมด แบบขนาน
500 token ใช้เวลาไม่ถึงวินาที
2. Decode (การสร้างคำตอบ)
คำตอบถูกสร้าง ตามลำดับ ทีละ token
200 token ใช้เวลาหลายวินาที
Token ถัดไปแต่ละตัวขึ้นอยู่กับ token ก่อนหน้าทั้งหมด งานนี้จึงทำแบบขนานไม่ได้
KV-cache: ทำไม token แรกจึงช้าที่สุด
ถ้าไม่มีการ optimize โมเดลจะต้องคำนวณ attention ของ context ทั้งหมดใหม่ทุกครั้งที่สร้าง token แต่ละตัว
ทางแก้คือ Key-Value cache:
- ในขั้น prefill โมเดลเก็บผลลัพธ์ของ attention ไว้
- ในขั้น decode โมเดลใช้แคชนั้น
- คำนวณใหม่เฉพาะ token ใหม่
ผลที่ได้:
- token แรกออกมาช้ากว่า
- ตัวที่เหลือออกเร็วกว่า
ทำไม output จึงแพงกว่า input
Input ประมวลผลแบบขนาน
Output สร้างตามลำดับ และต้องใช้แคชที่โตขึ้นเรื่อย ๆ
ผู้ให้บริการส่วนใหญ่จึงคิดราคาแบบนี้:
- output แพงกว่า input 3–5 เท่า
นี่ไม่ใช่การตลาด แต่เป็นผลจากสถาปัตยกรรม
เศรษฐศาสตร์ของคำขอในชีวิตจริง
ลองดูตัวอย่าง:
- system prompt + เอกสารประกอบ: 10,000 token
- คำถามของผู้ใช้: 100 token
- คำตอบของโมเดล: 500 token
ที่ราคามาตรฐานทั่วไป:
- คำขอหนึ่งครั้ง ~ไม่กี่เซนต์
- 1,000 คำขอต่อวัน ก็หลายสิบดอลลาร์
- ต่อเดือนก็หลักพัน
ถ้าไม่ optimize งบจะหายไปแบบไม่ทันรู้ตัว
แคชคือวิธีประหยัดเงิน
แคชช่วยให้:
- เขียน context ลงไปครั้งเดียวในราคาแพง
- แล้วอ่านซ้ำได้หลายครั้งในราคาถูก
ประหยัดได้ ถึง 70–90% สำหรับคำขอที่ซ้ำกัน
นี่ไม่ใช่การ optimize แบบ “ไว้ทีหลัง” แต่เป็นความจำเป็นพื้นฐานของสถาปัตยกรรม
โมเดลไม่ได้เรียนรู้จากบทสนทนาของคุณ
ต้องแยกให้ชัด:
- Training คือการฝึกโมเดล (หลายเดือน คลัสเตอร์ GPU หลายล้านดอลลาร์)
- Inference คือการใช้งานโมเดล (ไม่กี่วินาที ไม่กี่เซนต์)
ระหว่าง inference ค่าน้ำหนัก (weights) ของโมเดล ไม่เปลี่ยน
สิ่งที่ดูเหมือน “การเรียนรู้” จริง ๆ คือการทำงานกับ context และหน่วยความจำ:
- ประวัติแชท
- ข้อเท็จจริงที่บันทึกไว้
- การดึงข้อมูลที่เกี่ยวข้อง
นี่ไม่ใช่การเรียนรู้ แต่คือ context engineering ที่ทำอย่างถูกวิธี
Temperature, Top-P และ Top-K
โมเดลคือเครื่องทำนาย token ถัดไป
Temperature คุมว่าโมเดลจะ:
- เลือกตัวเลือกที่น่าจะเป็นที่สุด
- หรือยอมเลือกตัวเลือกที่น่าจะเป็นน้อยกว่า
- T — 0: แทบจะเลือก token ที่น่าจะเป็นที่สุดเสมอ
- T — ∞: วุ่นวายไร้ระเบียบ
ช่วงที่ใช้ได้จริงคือ 0–1.2
Top-P และ Top-K คือตัวกรองความน่าจะเป็นเพิ่มเติม:
- Top-P คือชุด token แบบไดนามิกตามผลรวมความน่าจะเป็น
- Top-K คือจำนวนตัวเลือกแบบตายตัว
ทั้งหมดนี้คือเครื่องมือคุมพฤติกรรม ไม่ใช่ปุ่มวิเศษ
LLM, Reasoning model และเอเจนต์คือคนละระดับกัน
LLM
Stateless คำขอหนึ่งครั้ง ได้คำตอบหนึ่งครั้ง
เหมาะกับ:
- ถาม-ตอบ
- วิเคราะห์เอกสารฉบับเดียว
- สร้างข้อความ
Reasoning model
คิดทีละขั้น
แพงกว่าและช้ากว่า แต่:
- ผิดพลาดน้อยกว่า
- เหมาะกับตรรกะซับซ้อน
เอเจนต์
ระบบที่ทำงานได้เอง:
- สังเกต
- ใช้เหตุผล
- ลงมือทำ
- เก็บสถานะ
ทำได้:
- อ่านและแก้ไฟล์
- รันเทสต์
- ดีพลอยโค้ด
- ตรวจผลลัพธ์
LLM คือที่ปรึกษา
Reasoning คือนักวิเคราะห์
เอเจนต์คือวิศวกร
Context engineering สำคัญกว่า prompt
Prompt คือบรรทัดสุดท้าย
Context คือทุกอย่างที่เหลือ
ตัวอย่างการจองโรงแรมเห็นภาพชัด:
- prompt สมบูรณ์แบบแต่ไม่มี context ให้ผลลัพธ์แย่
- prompt เดิมแต่มี context ที่ถูกต้อง ได้คำตอบที่แม่นยำ
Context engineering คือ:
- การจัดการหน่วยความจำ
- retrieval (RAG)
- สถานะ
- เครื่องมือ
- การประกอบคำขอแบบไดนามิก
In-context, RAG และ Fine-tuning: เมื่อไรควรใช้อะไร
In-context learning
- เร็ว
- ไม่ต้องฝึก
- แพงเมื่อสเกลใหญ่
- ถูกจำกัดด้วยขนาด context
RAG
- ขยายสเกลได้
- ข้อมูลสดใหม่
- โครงสร้างพื้นฐานซับซ้อนกว่า
- ขึ้นอยู่กับคุณภาพของ retrieval
Fine-tuning
- ความรู้ถูก “อบ” เข้าไปในโมเดล
- inference เร็วกว่า
- แพงและใช้เวลานาน
- เหมาะกับโดเมนที่นิ่งแล้ว
ลำดับที่ถูกต้อง:
- in-context
- ต่อด้วย RAG
- แล้วค่อย fine-tuning เป็นอย่างสุดท้าย
ทำไม foundation model จึงเปลี่ยนทุกอย่าง
ฝึกโมเดลตั้งแต่ศูนย์ใช้เงินหลายร้อยล้านดอลลาร์
Foundation model ทำให้เรา:
- เอาฐานที่มีอยู่แล้วมาใช้
- ปรับให้เข้ากับงานของเรา
มีให้เลือก:
- โมเดลปิด (คุณภาพดี แต่ต้องพึ่งพาเจ้าของ)
- โมเดล open-source (ควบคุมได้ แต่คุณภาพต่ำกว่า)
ใจความสำคัญ:
คุณไม่ได้สอนโมเดลให้เข้าใจโลก แต่สอนให้มันเข้าใจงานของคุณ
อนาคต: MCP, MoE และความปลอดภัย
- MCP ทำให้การเชื่อมเอเจนต์เข้ากับระบบต่าง ๆ เป็นมาตรฐานเดียวกัน
- Mixture of Experts เปิดใช้เฉพาะส่วนของโมเดลที่จำเป็น
- AI Security กลายเป็นเรื่องสำคัญมาก: prompt injection, shadow AI, การโจมตีผ่าน supply chain
โปรเจกต์ AI ส่วนใหญ่พังไม่ใช่เพราะคุณภาพของโมเดล แต่เพราะไม่มีสถาปัตยกรรมและไม่มีความปลอดภัย
สรุป
LLM ไม่ใช่เวทมนตร์
มันคือระบบวิศวกรรมที่ซับซ้อน แต่เข้าใจได้
Token, attention, context, แคช, เอเจนต์, RAG ไม่ใช่ทฤษฎี
แต่เป็นเครื่องมือที่:
- ลดต้นทุน
- เพิ่มความเสถียร
- ทำให้ระบบคาดเดาได้
เมื่อเข้าใจว่าเบื้องหลังทุกอย่างทำงานอย่างไร คุณก็เลิกเป็นแค่ผู้ใช้
คุณกลายเป็นวิศวกรที่สร้างระบบ AI อย่างรู้ว่ากำลังทำอะไรอยู่
บทความที่มีประโยชน์และการพูดคุยอยู่ที่นี่ (ภาษารัสเซีย)
โมเดลพลาดตรงไหน
LLM เลือกข้อความต่อที่น่าจะเป็น ไม่ได้ตรวจความจริงให้อัตโนมัติ ข้อเท็จจริง การคำนวณ โค้ด และลิงก์จึงต้องตรวจแยกด้วยเครื่องมืออื่นหรือเทียบกับแหล่งต้นทาง โดยเฉพาะเมื่อความผิดพลาดกระทบเรื่องเงิน ความปลอดภัย หรือสิทธิของคน
