Case Study: Workshop 2 วัน Local AI สำหรับทีม IT ภายในของบริษัทไทย

สรุปสั้น: Scenario สมมติ — บริษัทเทคไทยเบื่อการพึ่ง agency ส่ง IT/data engineer 10 คนเข้าเวิร์กช็อป 2 วันแบบ hands-on วันแรกครอบคลุมเลือกฮาร์ดแวร์ ติดตั้ง Ollama เลือกโมเดล และการใช้งานพื้นฐาน วันที่สองสร้าง RAG chatbot บนเอกสารของตัวเอง สิ้นสุดวันที่สองทีม maintain Local AI ได้เอง ค่าใช้จ่ายรวมประมาณเท่ากับ retainer agency 1 เดือน

ข้อเท็จจริงสำคัญ

• นี่คือ scenario สมมติเพื่อแสดงแนวคิด ไม่ใช่ engagement จริง บริษัทที่อธิบายเป็นสมมติ
• Workshop มาตรฐาน 2 วัน (16 ชั่วโมงรวม) 8 ชั่วโมง/วันรวมพักเที่ยง
• ขนาดกลุ่ม: ต่ำสุด 4 คน สูงสุด 10 คน เกิน 10 คุณภาพลดลง เราเปิด session ที่ 2 แทน
• Delivery default: in-house ที่ออฟฟิศลูกค้าในกรุงเทพและปริมณฑล (ไม่มีค่าเดินทาง); ต่างจังหวัด quote แยก
• ค่าใช้จ่ายทั่วไป 15,000 บาท/คนสำหรับ open-enrolment หรือ 60,000 บาท/วันสำหรับ in-house (ถึง 10 คน)
• ผู้เข้าร่วมเดินออกพร้อม: Local AI stack ทำงานบนเครื่องตัวเอง, starter-code repo, RAG demo บนเอกสารของตัวเอง, และ email support 30 วัน
• ประมาณ 80% ของทีมที่เข้าร่วมไม่ต้องการ support ภายนอกหลัง 3 เดือน

ทำไมถึงเขียน case study ชิ้นนี้

Disclosure เหมือน case อื่น: นี่ไม่ใช่ engagement จริง ไม่มีทีมเทคไทยจ้างเราทำ workshop นี้ตรง ๆ เราเขียนเพราะ “จริง ๆ แล้วใน Local AI workshop เกิดอะไรขึ้นบ้าง?” คือคำถามที่ทีมถามก่อน commit และบรรทัดคลุม ๆ ว่า “2 วัน hands-on” ในหน้าบริการตอบไม่ได้ workshop จริงพร้อม consent จะแยกเผยแพร่

Workshop เป็นแพ็กเกจที่เราได้คำถามโดยไม่ถูก prompt มากที่สุด เพราะทีมอยากเห็น scope และ pace ก่อนอนุมัติค่าใช้จ่าย case study นี้เดินผ่าน workshop ทั่วไปนาทีต่อนาที

Scenario (สมมติ)

บริษัทเทคไทยขนาดกลาง (B2B SaaS ทำ logistics ประมาณ 100 พนักงาน ทีมวิศวกรรม 12 คน) CTO ต้องการให้บริษัทรัน AI tools ภายในเอง — สรุป support tickets, Q&A บน runbook ภายใน, ช่วยเขียน code — แทนที่จะส่งทุกอย่างไป OpenAI API ปัจจุบันจ่าย cloud AI call ประมาณ 25,000 บาท/เดือนบวก agency AI ท้องถิ่นที่ maintain Ollama server ที่เขาไม่เข้าใจเต็มที่อีก 40,000 บาท/เดือน ทั้งสองรายจ่ายเครียด: อันแรกเพราะ customer-support ticket มี PDPA-sensitive user data ที่คงไม่ควรออกนอกประเทศ; อันที่สองเพราะจ่าย premium สำหรับสิ่งที่ทีมรู้สึกว่าควรทำเองได้

CTO จอง workshop in-house 2 วัน 10 คน: backend engineer 4 คน (สำหรับ integration), data engineer 2 คน (สำหรับ data pipeline), infrastructure engineer 2 คน (สำหรับ ops), security engineer 1 คน (สำหรับ review), และ product manager 1 คน (สำหรับเข้าใจ scope)

ทำไมเรื่องนี้สำคัญต่อทีมเทคไทยในปี 2026

Local AI ในปี 2026 ไม่ใช่ setup แปลก ๆ อีกต่อไปแล้ว — Ollama รันบน GPU ล่าสุดใด ๆ ได้เชื่อถือได้, Qwen3 และ Gemma ให้ open weight คุณภาพ production, และ documentation สุกพอให้วิศวกรที่มีความสามารถติดตั้งระบบพื้นฐานได้ภายใน 1 วัน แต่ “ระบบพื้นฐานรันอยู่” ต่างจาก “ทีมมั่นใจเป็นเจ้าของ stack นี้ระยะยาว” gap ระหว่าง 2 state นี้คือสิ่งที่ workshop ปิดใน 2 วัน

ทางเลือกอื่น — เรียนรู้ด้วยการลองผิดลองถูกขณะรัน production — คือสิ่งที่ทีมส่วนใหญ่ทำจริง และมีต้นทุน 2-3 เท่าของงบ workshop ในแง่เวลาสูญเปล่าและ deployment ครึ่ง ๆ กลาง ๆ ที่ไม่มีใครอยาก maintain

เงื่อนไขที่เราจะทำงานภายใน

• เวลา: 2 วัน ไม่เกิน วิศวกรหยุดงาน 1 สัปดาห์เพื่อ training ไม่ได้
• พื้นฐานต่างกัน: ผู้เข้าร่วม 10 คนมี ML exposure ต่างกันตั้งแต่ไม่มีถึงกลาง ๆ เนื้อหาต้องทำงานให้ค่ากลางโดยไม่น่าเบื่อคนแข็งและไม่ทิ้งคนอ่อน
• Stack ของเขา: ไม่มีประโยชน์สอนเครื่องมือที่เขาไม่ได้ใช้ ถ้ารัน AWS เรา demo cloud GPU; ถ้ารัน on-prem เรา demo บนฮาร์ดแวร์เขา
• Self-sufficiency หลัง workshop: เป้าหมายหลักคือ 3 เดือนหลังนั้นทีมไม่ต้องโทรหาเรา สอนตกปลาไม่ใช่ให้ปลา

Agenda 2 วันจริง ๆ หน้าตาแบบไหน

Day 1 — พื้นฐานและการติดตั้ง

ช่วงเช้า (9:00-12:00): ทำไม Local AI และชิ้นส่วนต่าง ๆ ประกอบกันอย่างไร

• ทำไม self-host: cost, privacy, control — และเมื่อไหร่คือคำตอบที่ผิด
• Mental model ของ Local LLM stack: weights, inference runtime, API, client
• ภูมิทัศน์ปี 2026: Ollama vs. vLLM vs. llama.cpp เลือกตัวไหนเมื่อไหร่
• Open weights vs. open source; licence gotcha สำหรับใช้เชิงพาณิชย์ (Apache 2.0, Gemma terms, Qwen licence)

ผู้เข้าร่วมติดตั้ง Ollama บนเครื่องตัวเองตามระหว่าง block นี้

ช่วงบ่าย (13:00-17:00): โมเดลแรกที่รัน

• ดาวน์โหลด Qwen3-8B (เล็กพอสำหรับ laptop ทุกคน) และ chat ผ่าน CLI และ Open WebUI
• เข้าใจ parameter: temperature, top_p, context window, num_predict
• Benchmark tokens/sec บนฮาร์ดแวร์เฉพาะของเขา — ตัวเลขจริงไม่ใช่คำอ้าง
• เมื่อไหร่เลือก 8B vs. 32B vs. 70B ตาม task; สัญญาณว่าถึงเวลา step up
• การบ้าน: ทุกคนรัน 5 test prompt เดียวกันบน rig ข้ามคืน และนำผลมาวันที่ 2

Day 2 — สร้างอะไรที่ใช้งานได้จริง

ช่วงเช้า (9:00-12:00): RAG จากศูนย์

• RAG คืออะไรและทำไมเหนือกว่า fine-tuning ใน 90% ของปัญหา “สอนโมเดลเรื่องข้อมูลเรา”
• กลยุทธ์ chunking สำหรับเอกสารประเภทต่างกัน (code, long-form docs, Q&A pair)
• Embedding model: nomic-embed-text, bge-m3 เลือกอันไหนเมื่อไหร่
• Vector database ปี 2026: Qdrant, Weaviate, Chroma — เปรียบเทียบเร็ว ๆ
• สร้าง RAG pipeline ที่ใช้งานได้ภายใน ~100 บรรทัด Python ที่ query เอกสารของเขาเอง

ช่วงบ่าย (13:00-16:00): เอาเข้า production

• สถาปัตยกรรม deployment ที่สมจริง: Ollama หลัง nginx, auth ด้วย bearer token, logging
• Monitoring: log อะไร, alert เมื่อไหร่, เมื่อไหร่ model update ผิดทาง
• Failure mode ที่พบบ่อย: VRAM OOM, context overflow, prompt drift หลัง update, CUDA แตก
• Q&A บน use case เฉพาะของเขา (เอาปัญหาตัวเองมา)

ช่วงสุดท้าย (16:00-17:00): สรุปและก้าวต่อไป

• ใครในทีมเป็นเจ้าของแต่ละส่วน
• Roadmap 30-60-90 วันที่แนะนำสำหรับทีม
• ตรวจสอบ stack รายไตรมาสอย่างไร
• Resource และวิธีติดต่อบรรณาธิการสำหรับ follow-up

ผลลัพธ์ที่คาดหวัง

Honest framing — อธิบายสิ่งที่ workshop มอบโดยปกติ ไม่ใช่คำสัญญาเฉพาะ:

• สิ้น Day 1: ผู้เข้าร่วมทุกคนมี Ollama + Qwen3-8B รันบน laptop ตัวเอง chat ได้ภาษาไทยและอังกฤษ
• สิ้น Day 2: RAG demo ที่ใช้งานได้จริง ตอบคำถามจากเอกสารภายในของทีม; ผู้เข้าร่วมแต่ละคนมี starter repo ที่ fork เข้า project จริงได้
• 30 วันหลัง: อย่างน้อย 1 use case ที่ deploy ภายในบริษัท; พบบ่อยที่สุดคือ internal Q&A bot บนเอกสารตัวเอง
• 3 เดือนหลัง: ทีมรัน shared GPU server, integrate Local AI ใน 2-3 workflow, และยกเลิก cloud-AI contract หรือลด 60-80%
• สิ่งที่ไม่ได้ทำ: เปลี่ยน backend engineer เป็น ML engineer เป้าหมายคือ operation และใช้งาน pragmatic ไม่ใช่ train model ตั้งแต่ต้นหรือตีพิมพ์ paper

คำคัดค้านที่พบบ่อย

“2 วันน้อยไป” สำหรับความลึก ใช่ สำหรับ operational self-sufficiency พร้อม follow-up supervised ใช่ — นี่คือสิ่งที่เราเห็นสม่ำเสมอใน workshop international คล้ายกัน เป้าหมายไม่ใช่ความเชี่ยวชาญ เป็นแค่ความสามารถพอเป็นเจ้าของ stack

“ทีมเรา senior เกินไปสำหรับเนื้อหา workshop” ในทางปฏิบัติพบน้อย วิศวกรที่คิดว่ารู้ LLM ops ค้นพบภายใน 2 ชั่วโมงแรกว่า mental model ของตัวมี gap (tokenisation edge case, quantisation tradeoff, กฎ licensing) ถ้าทีม senior จริง ๆ เรา pivot Day 2 ไป advanced topic: fine-tuning, multi-GPU, custom embedding

“อัด session ให้คนที่ขาดได้ไหม?” ได้ การอัดรวมอยู่แล้ว ไม่ค่าใช้จ่ายเพิ่ม แต่คนที่ไม่มาได้ประโยชน์ประมาณ 70% จาก recording อย่างเดียว hands-on exercise ไม่ transfer ผ่าน video

“สอนเป็นภาษาไทยแทนอังกฤษได้ไหม?” ได้ Default คือภาษาไทยพร้อมศัพท์เทคนิคอังกฤษ อังกฤษล้วนได้ถ้าทีม international

Pattern นี้เหมาะกับใคร

• ทีมเทค in-house (5-15 วิศวกร) ที่อยากเป็นเจ้าของ Local AI ระยะยาว แทนที่จะ outsource ตลอดไป
• Agency ที่อยากเพิ่ม Local AI ใน service offering โดยไม่จ้าง specialist
• หลักสูตร CS ในมหาวิทยาลัย หรือ bootcamp (rate เจรจาได้ ปกติลดสำหรับการศึกษา)
• หน่วยงานรัฐบาลที่ต้องการความสามารถ sovereign AI สำหรับ workload ที่ sensitive PDPA

ไม่เหมาะกับ: ทีม 1-2 คน (open-enrolment คุ้มกว่า), ทีมต้องการ production deployment วันนี้ (จ้าง setup package ไม่ใช่ workshop), และทีมที่อยากได้ใบรับรองมากกว่าทักษะ

วิธีเริ่มต้น

จุดเริ่มต้นคือ call 30 นาทีเพื่อ scope ขนาดทีม, skill mix, และ custom content ส่งอีเมลถึง บรรณาธิการ พร้อมจำนวนผู้เข้าร่วมคร่าว ๆ และปัญหาที่คุณอยากให้เขาเรียนแก้

รายละเอียด Workshop ดูที่ หน้าบริการ; หลักการทำงานของ editorial ดูที่ standards page