1,000 ตัวอย่างที่ดี > 1 ล้านตัวอย่าง: Dataset Engineering ทักษะถัดไปของ AI Stack

FARS-AI

AI / Automation Consulting

ENTH

ทุกครั้งที่ 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-tuning กำลังกลายเป็น Commodity

เมื่อสองปีก่อน การ 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 ทำได้ถึงแค่ไหน — และจุดไหนที่มันไม่ช่วย

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 คืออะไรจริงๆ

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

ทำไม Data Engineer คือคนที่ถือกุญแจ

ถ้า 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

Organizational Intelligence ที่สะสมได้

มีมุมหนึ่งที่มักถูกมองข้ามเมื่อพูดถึง 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 มันเกิดจากคนที่เข้าใจว่าข้อมูลนั้นหมายความว่าอะไร

อ้างอิง: