BLOG // 0x626c6f67
6 min readFars AI Teamทุกครั้งที่ layer ของ AI stack กลายเป็น commodity ทักษะใหม่จะผุดขึ้นที่รอยต่อถัดไป — Prompt engineering ผ่านจุดสูงสุดแล้ว RAG กลายเป็น standard แล้ว ถัดไปคือ Dataset Engineering
ทุกครั้งที่ layer ของ AI stack กลายเป็น commodity จะมีทักษะใหม่ผุดขึ้นที่รอยต่อถัดไปเสมอ
Cloud compute ถูกลง — DevOps ก็เกิดขึ้น
Storage ถูกลง — Data Engineering ก็เกิดขึ้น
Foundation model เปิดให้เข้าถึงได้ — Prompt Engineering ก็เกิดขึ้น
RAG tooling กลายเป็น standard — AI/LLM Engineering สำหรับ integration ก็เกิดขึ้น
นี่ไม่ใช่การคาดการณ์ แต่มันคือ pattern ที่เกิดซ้ำทุกรอบ
ตอนนี้ fine-tuning infrastructure กำลังกลายเป็น commodity ด้วย LoRA และ QLoRA — และทักษะที่กำลังก่อตัวตรงรอยต่อนั้นยังไม่ค่อยมีใครพูดถึง แต่คนที่ทำงานกับข้อมูลองค์กรจริงๆ จะเริ่มสัมผัสได้ว่ามันสำคัญแค่ไหน: Dataset Engineering
เมื่อสองปีก่อน การ fine-tune โมเดลขนาด 7B parameters ต้องลงทุน GPU cluster ราคาหลักล้าน วันนี้ QLoRA รันบน RTX 4090 ตัวเดียว หรือจะใช้ cloud ก็ราว 70-170 บาทต่อรอบ training
| วิธี | Hardware ขั้นต่ำ | ค่าใช้จ่าย (cloud/รอบ) | Performance vs Full FT |
|---|---|---|---|
| Full Fine-tuning | A100 80GB x4+ | ~3,500-17,000 บาท | 100% (baseline) |
| LoRA | A100 80GB x1 | ~350-1,700 บาท | 90-95% |
| QLoRA | RTX 4090 24GB | ~70-170 บาท | 80-90% |
สำหรับ use case ส่วนใหญ่ขององค์กร — ปรับ writing style, domain terminology, output format, task-specific reasoning — QLoRA เพียงพอ ไม่ต้องเสียเงินหลักแสนต่อรอบ วิธีที่ตรงไปตรงมาที่สุดคือ SFT (Supervised Fine-Tuning): เตรียมคู่ instruction-response ที่ดี 500-5,000 ตัวอย่าง แล้ว train — จบ ไม่ต้องมี reward model ไม่ต้องมี preference pipeline ลงทุนน้อย วัดผลได้ชัด อธิบายให้ผู้บริหารฟังได้
Compute barrier หายไปแล้ว Infrastructure ถูก solve แล้ว
คำถามคือ: ถ้า technical barrier ไม่ใช่ปัญหา แล้ว bottleneck ที่เหลืออยู่คืออะไร?
RAG เป็น standard ไปแล้ว เราเขียนถึงเรื่อง Document Ingestion ที่หลายคนมองข้าม ก่อนหน้านี้ และใช้มันเป็น core architecture ในงาน consulting แทบทุกโปรเจกต์
แต่ RAG ทำได้แค่ครึ่งเดียวของปัญหา
RAG = knowledge retrieval — บอกโมเดลว่า "ข้อมูลอยู่ตรงนี้" ให้มันหยิบไปใช้ตอบคำถาม
Fine-tuning = behavioral calibration — สอนโมเดลว่า "องค์กรนี้คิดยังไง ตอบแบบไหน ในบทบาทอะไร"
สองสิ่งนี้แก้คนละปัญหา แต่มักถูกเหมารวมเป็นเรื่องเดียวกัน
ลองนึกภาพ: พนักงานขายใช้ AI ช่วยเขียนอีเมลถึงลูกค้า RAG ดึงข้อมูลสินค้าและราคามาให้ได้ถูกต้อง แต่ tone ไม่ใช่ tone ของบริษัท ลำดับการนำเสนอไม่ตรง format ที่ทีมใช้ ตัว closer ไม่ตรงกับ sales playbook
ผลคือพนักงานต้อง แก้ output ทุกครั้ง — ใส่ tone ใหม่ จัด format ใหม่ ปรับ closer ใหม่ ซ้ำทุกวัน (หรือ เคยให้ AI ช่วยทำ slide มั้ย... นั่นแหละ ชัดเลย)
นี่ไม่ใช่ปัญหา retrieval — นี่คือปัญหา behavior โมเดลไม่รู้ว่า "ตำแหน่งนี้" และ "งานนี้" ต้องการ output แบบไหน และ prompt engineering มี ceiling ที่ชัดเจน — ยิ่ง prompt ยาวและซับซ้อน ยิ่งเปราะบาง ยิ่ง maintain ยาก นี่คือสาเหตุหนึ่งที่โปรเจกต์ AI ส่วนใหญ่ไม่รอดถึง production — ปัญหาไม่ใช่เทคนิค แต่คือสิ่งที่ถูกสอนให้โมเดลทำกับสิ่งที่องค์กรต้องการจริงไม่ตรงกัน
หมายเหตุจากผู้เขียน: pattern "ใช้ได้ แต่ต้องแก้ทุกครั้ง" นี้เกิดซ้ำแทบทุกองค์กรที่เราเข้าไปดูงาน ถ้าต้อง reshape output ทุกรอบ มันไม่ใช่ productivity gain — มันคือ overhead ที่มี UI สวยขึ้น ข้อมูลจาก McKinsey (2025) ยืนยันว่า 43% ของ enterprise cite data quality and readiness เป็นอุปสรรค #1 ของ AI — ไม่ใช่ model ไม่ใช่ compute power ไม่ใช่งบประมาณ
Dataset Engineering ไม่ใช่ "การเก็บข้อมูล" เหมือนกับที่ Data Engineering ไม่ใช่แค่ "การดูแล database" — มันเป็น engineering discipline ที่มี pipeline, tools, quality metrics, และ failure modes เฉพาะตัว
จากหนังสือ AI Engineering (Chip Huyen, 2025) และงานวิจัยด้าน data curation ล่าสุด pipeline ของ Dataset Engineering ประกอบด้วย 6 ขั้นตอนหลัก:
| ขั้นตอน | ทำอะไร | ตัวอย่างในบริบทองค์กร |
|---|---|---|
| 1. Collection | รวบรวม raw data | SOPs, email templates, sales scripts, decision logs |
| 2. Preprocessing | ทำความสะอาด แปลง format | ถอด HTML, normalize encoding, แยกภาษา |
| 3. Filtering | คัดกรองคุณภาพ | ตัด document ที่สั้น/เก่า/ไม่ตรง domain |
| 4. Deduplication | ตัดข้อมูลซ้ำ | MinHash LSH สำหรับ near-duplicate detection |
| 5. Blending | ผสมสัดส่วน data source | high-quality 70% + diverse edge cases 30% |
| 6. Synthetic Generation | สร้าง data เพิ่มจาก LLM | 10-20 seed examples → LLM สร้าง 2,000 variations → filter → 500-1,000 usable |
ขั้นตอนที่ 6 คือจุดที่เปลี่ยนเกม — องค์กรไม่ต้องมี labeled dataset หมื่นตัวอย่างเพื่อเริ่มต้น แค่ 10-20 ตัวอย่างที่ดี ให้ LLM อย่าง Claude สร้าง variations แล้ว filter ด้วย quality criteria ก็ได้ training set ที่ใช้ fine-tune ได้จริง วิธีนี้เรียกว่า Self-Instruct และเป็นพื้นฐานของ dataset หลายตัวที่ใช้ในวงการจริง ตั้งแต่ Stanford Alpaca ไปจนถึง synthetic data pipelines ที่ใช้ align โมเดลระดับ production ในปัจจุบัน
แต่ทักษะที่แพงที่สุดใน pipeline นี้ไม่ได้อยู่ที่ขั้นตอนไหนข้างบน — มันอยู่ก่อนขั้นตอนที่ 1 เสียอีก: Task Formulation คือการตั้งโจทย์ให้ถูกว่าจะ "สอน" โมเดลให้ทำอะไร ในรูปแบบไหน วัดผลยังไง ผิดตรงนี้ ทั้ง pipeline ผิดหมด
และนี่คือสิ่งที่งานวิจัยยืนยันซ้ำแล้วซ้ำเล่า:
| สิ่งที่วิจัยพบ | แหล่งข้อมูล |
|---|---|
| 1,000 ตัวอย่างที่ดี ชนะ 1 ล้านตัวอย่างที่พอใช้ | LIMA paper (2023), Phi series (Microsoft) |
| Noisy training data ลด precision จาก 89% → 72% | Controlled fine-tuning studies |
| SFT ด้วย 500-5,000 curated examples ให้ behavioral change ที่วัดได้ | AI Engineering, Ch.7-8 |
| Dataset design สำคัญเท่า model architecture สำหรับ terminal performance | NVIDIA Nemotron (Feb 2026) |
ROI ของ fine-tuning ถูกกำหนดโดยคุณภาพ dataset แทบทั้งหมด — ไม่ใช่ hyperparameters ไม่ใช่ model selection
สำหรับ use case ที่ต้องการ alignment ในเชิง style หรือ preference ที่ละเอียดกว่า SFT ยังมีวิธีอย่าง DPO (Direct Preference Optimization) ที่ทำงานกับ preference pairs — ถ้ามีจังหวะ อาจจะเขียนถึงการใช้ DPO ในอีก use cases
ถ้า dataset engineering สำคัญขนาดนี้ — แล้วใครในองค์กรควรทำ?
คำตอบที่หลายคนคิดก่อนคือ ML Engineer หรือ AI Researcher แต่ในบริบทไทย — และ SMEs ทั่วโลก — ตำแหน่งเหล่านั้นแทบไม่มีอยู่จริง ไม่มีบริษัทขนาดกลางไหนจ้าง ML Researcher มานั่งสร้าง training dataset
คนที่มีทักษะใกล้เคียงที่สุดและมีอยู่แล้วในองค์กรคือ Data Engineer
| ทักษะที่ Dataset Engineering ต้องการ | Data Engineer มีอยู่แล้ว? |
|---|---|
| รู้ว่า clean data อยู่ที่ไหนในองค์กร | ✓ |
| เข้าใจ schema และ semantic ของข้อมูล | ✓ |
| สร้าง data pipeline (ETL/ELT) | ✓ |
| รู้ edge cases ของ data source แต่ละตัว | ✓ |
| ออกแบบ quality filtering criteria | ✓ |
| Task formulation: ตั้งโจทย์ instruction-response pairs | ✗ (ต้องเรียนเพิ่ม) |
| Evaluation design: สร้าง test set วัดผล | ✗ (ต้องเรียนเพิ่ม) |
จาก 7 ทักษะหลัก Data Engineer มี 5 อยู่แล้ว สิ่งที่ขาดคือ 2 ทักษะที่เป็น ML-specific: task formulation กับ evaluation design — ซึ่งเรียนรู้ได้ในเวลาไม่กี่สัปดาห์สำหรับคนที่มี foundation ของ data work อยู่แล้ว
นี่คือ role expansion ไม่ใช่ new hire
หมายเหตุจากผู้เขียน: ในทีมของเราเอง AI Engineer กับ Data Engineer ทำงานร่วมกันตั้งแต่ต้น สิ่งที่เห็นชัดคือ Data Engineer ที่เข้าใจ fine-tuning pipeline สร้าง dataset ที่ใช้ได้จริงเร็วกว่า AI Engineer ที่ไม่รู้ข้อมูลขององค์กร ปัจจัยที่ต่างกันไม่ใช่ ML knowledge แต่คือ domain data intuition — การรู้ว่าข้อมูลตรงไหน clean ตรงไหนมี bias ตรงไหนเป็น exception ไม่ใช่ pattern
มีมุมหนึ่งที่มักถูกมองข้ามเมื่อพูดถึง fine-tuning: สิ่งที่ได้จากกระบวนการนี้ไม่ใช่แค่ "โมเดลที่ตอบดีขึ้น" — แต่คือ organizational asset ที่ compound ได้
Base model รู้ว่า "โลก" คิดอย่างไร — มันถูก train จากข้อมูลอินเทอร์เน็ตทั้งหมด
Fine-tuned model รู้ว่า "องค์กรนี้" คิดอย่างไร — มันถูก train จากข้อมูลการทำงานจริง
RAG ให้โมเดลเข้าถึง ความรู้ ขององค์กร Fine-tuning ให้โมเดลเข้าใจ พฤติกรรม ขององค์กร
ทั้งสองชั้นจำเป็น — แต่ตอนนี้แทบทุกบริษัทสร้างแค่ชั้นแรก
และ dataset ที่สร้างจาก domain expertise ขององค์กรไม่ได้มีประโยชน์แค่ fine-tuning อย่างเดียว — มันใช้ได้กับ evaluation, quality assurance, onboarding, และ knowledge management เป็น byproduct ที่มีมูลค่าในตัวเอง ยิ่ง dataset ถูก iterate และสะสมมากขึ้น organizational intelligence ก็ยิ่ง compound — เหมือน codebase ที่ดูแลดีมีมูลค่ามากกว่า codebase ที่เขียนครั้งเดียวแล้วทิ้ง
ทุกครั้งที่ชั้นหนึ่งของ AI stack กลายเป็น commodity ทักษะใหม่จะก่อตัวที่รอยต่อถัดไป Prompt engineering มีจุดสูงสุดแล้ว RAG engineering กลายเป็น standard practice แล้ว Fine-tuning infrastructure กำลังถึงจุดเดียวกันด้วย LoRA และ QLoRA
ทักษะที่ก่อตัวตรงรอยต่อนั้น — การแปลง organizational knowledge ให้เป็น training signal ที่มีคุณภาพ — คือ Dataset Engineering และคนที่พร้อมที่สุดจะทำสิ่งนี้ไม่ใช่ ML Researcher ที่องค์กรไม่มี แต่คือ Data Engineer ที่เข้าใจข้อมูลขององค์กรตั้งแต่วันแรก
โมเดลฉลาดแค่ไหนไม่สำคัญเท่ากับว่าใครสอนมัน ด้วยข้อมูลอะไร — และ dataset ที่ดีไม่ได้เกิดจาก algorithm มันเกิดจากคนที่เข้าใจว่าข้อมูลนั้นหมายความว่าอะไร
อ้างอิง:
