หลักสูตรไอทีสอนสด ครอบคลุมเว็บ โมบายล์ ฐานข้อมูล กราฟิก และอื่น ๆ
โครงการเปลี่ยนระบบจำนวนมากล้มเหลวหรือเลื่อนกำหนด ไม่ใช่เพราะระบบใหม่ทำงานไม่ได้ แต่เพราะข้อมูลเดิมย้ายขึ้นระบบใหม่ไม่สำเร็จ ข้อมูลที่สะสมมาหลายปีมักมีรูปแบบไม่สม่ำเสมอ มีข้อมูลซ้ำ มีค่าที่ไม่มีความหมายทางธุรกิจแล้ว และมีกฎเกณฑ์ที่ไม่เคยมีใครบันทึกไว้…
ระบบงานในองค์กรปัจจุบันแทบไม่มีระบบใดทำงานโดดเดี่ยว ทุกโครงการต้องเชื่อมต่อกับระบบบัญชี ระบบชำระเงิน ระบบของหน่วยงานภายนอก หรือบริการบนคลาวด์ แต่ปัญหาที่พบบ่อยคือ BA และ SA เขียนความต้องการได้เฉพาะกรณีที่ทุกอย่างทำงานปกติ…
BA และ SA จำนวนมากต้องรอทีมพัฒนาหรือทีม DBA ดึงข้อมูลให้ทุกครั้งที่ต้องการตรวจสอบเคสปัญหา ทำให้รอบการทำงานช้าและได้ข้อมูลไม่ตรงกับคำถามที่แท้จริง ทั้งที่การเขียน SQL ในระดับที่ใช้ตรวจสอบข้อมูลได้นั้นไม่ได้ยากอย่างที่คิด…
ปัญหาที่พบบ่อยที่สุดในโครงการพัฒนาระบบไม่ใช่การเขียนโค้ดผิด แต่คือการเข้าใจข้อมูลผิดตั้งแต่ต้น เอกสารความต้องการที่เขียนเป็นข้อความล้วน ไม่ระบุว่าข้อมูลชิ้นไหนเก็บที่ใด สัมพันธ์กับอะไร และมีกฎทางธุรกิจกำกับอย่างไร ทำให้ทีมพัฒนาต้องตีความเอง…
โครงการพัฒนาระบบจำนวนมากไม่ได้ล้มเหลวเพราะเทคโนโลยี แต่ล้มเหลวเพราะเข้าใจความต้องการของลูกค้าไม่ตรงกัน ลูกค้ามักเล่าปัญหาปนกับวิธีแก้ที่ตนคิดไว้แล้ว ส่วนเอกสารความต้องการก็มักเป็นข้อความกว้าง ๆ ที่ทดสอบไม่ได้ ผลคือ Scope ที่ขยายไม่หยุด งานแก้ซ้ำหลังส่งมอบ…
งานสำนักงานจำนวนมากยังใช้เวลาไปกับการรวบรวมตัวเลข ทำตาราง ทำกราฟ เขียนรายงาน และทำสไลด์นำเสนอผู้บริหารซ้ำทุกเดือน ทั้งที่ AI ในปัจจุบันวิเคราะห์ข้อมูลและสร้างไฟล์งานสำนักงานให้ได้โดยตรงแล้ว แต่ผู้ใช้ส่วนใหญ่ยังได้ผลลัพธ์ไม่ตรงความต้องการ เพราะยังสั่งงาน AI…
คำถามที่ผู้บริหารถามบ่อยที่สุดมักเป็นเรื่องอนาคต เดือนหน้าจะขายได้เท่าไร ควรสต็อกสินค้าเท่าไร ลูกค้ากลุ่มไหนควรได้โปรโมชันแบบใด และลูกค้ารายไหนกำลังจะเลิกใช้บริการ หลายองค์กรยังตอบด้วยการดูยอดปีก่อนแล้วบวกเพิ่มเป็นเปอร์เซ็นต์…
ข้อความจากลูกค้าเป็นข้อมูลที่มีค่ามากแต่ถูกใช้น้อยที่สุด ทั้งรีวิวสินค้า ความคิดเห็นบนโซเชียล แชตกับแอดมิน และแบบสอบถามปลายเปิด ข้อความภาษาไทยวิเคราะห์ยากกว่าภาษาอังกฤษ เพราะไม่มีการเว้นวรรคระหว่างคำ มีคำสแลง คำสะกดผิด อีโมจิ และการพิมพ์ซ้ำอย่าง 555…
เมื่อระบบมีบริการจำนวนมาก ทีม IT Operations และ Service Desk มักเจอปัญหาเดียวกัน เหตุขัดข้องครั้งเดียวทำให้ Alert ดังพร้อมกันหลายสิบรายการ Ticket ไหลเข้ามาโดยไม่มีหมวดหมู่ที่ถูกต้อง ปัญหาเดิมถูกแก้ซ้ำเพราะหาวิธีแก้ครั้งก่อนไม่เจอ และ Runbook…
ระบบ RAG ที่ใช้ Vector Search อย่างเดียวตอบคำถามที่คำตอบอยู่ในย่อหน้าเดียวได้ดี แต่มักพลาดเมื่อคำถามต้องเชื่อมข้อมูลหลายเอกสาร เช่น ลูกค้ารายนี้ใช้สินค้ารุ่นไหนที่ได้รับผลจากประกาศฉบับล่าสุด หรือถามภาพรวมของข้อมูลทั้งชุด ขณะเดียวกัน AI Agent…
การเรียก LLM API ให้ได้คำตอบกลับมานั้นใช้โค้ดไม่กี่บรรทัด แต่การสร้างแอปที่ใช้งานได้จริงเป็นอีกเรื่อง นักพัฒนาต้องรับมือกับคำตอบที่รูปแบบไม่แน่นอน ค่าใช้จ่ายที่บานปลาย Rate Limit ข้อมูลที่โมเดลไม่รู้ และคำถามว่าแก้ Prompt แล้วดีขึ้นจริงหรือไม่…
หลายองค์กรอยากให้พนักงานถามข้อมูลในฐานข้อมูลเป็นภาษาคนได้เอง โดยไม่ต้องรอทีม Data เขียน SQL ให้ทุกครั้ง LLM ยุคนี้เขียน SQL ได้เก่งขึ้นมาก แต่เมื่อต่อเข้ากับฐานข้อมูลจริงกลับเจอปัญหาเดิมซ้ำ ๆ ทั้งเลือกตารางผิด นิยามยอดขายไม่ตรงกับที่ฝ่ายบัญชีใช้…
LINE Official Account เป็นช่องทางหลักที่ลูกค้าคนไทยใช้ทักร้านค้าและธุรกิจ แต่แอดมินมักตอบไม่ทันทั้งเรื่องราคา สต็อก สถานะคำสั่งซื้อ และคำถามซ้ำ ๆ บอทแบบเดิมที่ตอบตาม Keyword หรือ Intent ก็ตอบได้เฉพาะคำถามที่เตรียมไว้ ขณะที่ LLM อย่าง Gemini และ ChatGPT…
ทีม SOC ส่วนใหญ่ไม่ได้ขาดข้อมูล แต่จมอยู่กับ Alert จำนวนมากที่ต้องเปิดดูทีละรายการ ต้องสลับหน้าจอไปค้นข้อมูล IP หรือ Hash เขียน Query ใหม่ทุกครั้งที่ต้องล่าภัยคุกคาม และใช้เวลานานกับการสรุปเหตุการณ์เป็นรายงาน AI และ LLM ช่วยงานเหล่านี้ได้มาก…
ลูกค้าจำนวนมากยังเลือกโทรหาธุรกิจเมื่อมีเรื่องด่วน แต่คอลเซ็นเตอร์มักรับสายไม่ทันในช่วงพีค และพนักงานต้องตอบคำถามเดิมซ้ำทั้งวัน Voice AI รุ่นใหม่คุยภาษาไทยได้เป็นธรรมชาติขึ้นมากและตอบได้แทบทันที แต่การสร้าง Voice Agent ที่ใช้กับลูกค้าจริงต่างจากแชตบอตข้อความ…
งานตรวจสอบด้วยสายตาในธุรกิจมีอยู่ทุกที่ ทั้งการตรวจชิ้นงานเสียในสายการผลิต การนับสินค้าบนชั้น การนับคนเข้าออกร้าน หรือการตรวจว่าพนักงานสวมอุปกรณ์ป้องกันครบ งานเหล่านี้ใช้คนจำนวนมาก เหนื่อย และผลไม่สม่ำเสมอ ปัจจุบันโมเดลตระกูล YOLO ทำให้การตรวจจับวัตถุแบบ…
เมื่อพนักงานทุกแผนกเริ่มใช้ AI องค์กรมักเจอปัญหาเดียวกัน แต่ละทีมสมัครบริการคนละเจ้า ถือ API Key กันเอง ไม่มีใครรู้ว่าค่าใช้จ่ายรวมเท่าไร ข้อมูลลูกค้าหรือเอกสารลับอาจถูกส่งออกไปโดยไม่ตั้งใจ และเมื่อเกิดเหตุก็ไม่มี Log ให้ตรวจย้อนหลัง การห้ามใช้ไม่ได้ผล…
Prompt ที่ดีและ RAG แก้ปัญหาได้หลายอย่าง แต่บางงานก็ไปไม่สุด เช่น อยากให้โมเดลตอบในรูปแบบเฉพาะขององค์กรทุกครั้ง ใช้ศัพท์เฉพาะทางได้ถูกต้อง จัดหมวดเอกสารภาษาไทยได้แม่นยำ หรือใช้โมเดลขนาดเล็กที่รันในองค์กรได้แทนโมเดลใหญ่ราคาแพง Fine-tuning ด้วย LoRA และ QLoRA…
การสร้าง Chatbot หรือระบบ RAG ให้ตอบได้ดีในเครื่องของนักพัฒนาใช้เวลาไม่นาน แต่การดูแลให้ระบบตอบได้ดีอย่างสม่ำเสมอใน Production เป็นอีกเรื่องหนึ่ง แก้ Prompt นิดเดียวคำตอบบางกลุ่มก็แย่ลงโดยไม่มีใครรู้ เปลี่ยนรุ่นโมเดลแล้วค่าใช้จ่ายเพิ่มขึ้นหลายเท่า…
ทุกองค์กรมีเอกสารที่ต้องคีย์ข้อมูลซ้ำทุกวัน ทั้งใบแจ้งหนี้ ใบกำกับภาษี ใบเสร็จ แบบฟอร์มสมัคร และสัญญา ซึ่งมักมาเป็น PDF สแกนหรือภาพถ่ายจากมือถือ OCR แบบเดิมอ่านภาษาไทยได้ไม่ดีนักและไม่รู้ว่าตัวเลขไหนคือยอดสุทธิ ขณะที่ AI รุ่นใหม่อ่านเอกสารได้เก่งขึ้นมาก…
หลายองค์กรอยากใช้ LLM กับเอกสารภายใน ข้อมูลลูกค้า หรือซอร์สโค้ด แต่ติดเงื่อนไขว่าข้อมูลห้ามส่งออกไปยังผู้ให้บริการภายนอก ทางออกคือรันโมเดล Open-weight บนเครื่องหรือเซิร์ฟเวอร์ขององค์กรเอง แต่พอลงมือจริงทีม IT ต้องตอบคำถามที่ไม่ง่ายเลย ว่าควรเลือกโมเดลไหน…
แอปที่ใช้ LLM ทั้ง Chatbot ระบบ RAG และ AI Agent ที่เรียกเครื่องมือได้เอง กำลังเข้าไปอยู่ในระบบงานจริงขององค์กร แต่ช่องโหว่ของแอปเหล่านี้ต่างจากเว็บแอปทั่วไป ข้อความธรรมดาในอีเมลหรือเอกสารก็สั่งให้โมเดลทำสิ่งที่ไม่ควรทำได้ ข้อมูลลับใน Context…
งาน Generative AI ในองค์กรวันนี้ไม่ได้จบแค่การเรียก API ของโมเดลภาษา ทีมที่ต้องสร้างแชตบอต ระบบสรุปเอกสาร หรือระบบค้นหาจากความรู้ภายใน ต้องเข้าใจตั้งแต่พื้นฐาน Machine Learning, Tokenization และ Transformer ไปจนถึงการเตรียมข้อมูล การ Fine-tune การวัดผล…
การทำต้นแบบแชตบอตด้วย Generative AI ใช้เวลาไม่กี่ชั่วโมง แต่การพาแอปเดียวกันขึ้นใช้งานจริงในองค์กรเป็นอีกเรื่องหนึ่ง ทีมพัฒนาต้องตอบให้ได้ว่าจะเลือกโมเดลไหน ค่าใช้จ่ายต่อคำขอเท่าไร คำตอบอ้างอิงเอกสารที่ถูกต้องหรือไม่ จะกันข้อมูลส่วนบุคคลรั่วและ Prompt…
