Blog

2026.08.25

การพัฒนาแชทบอท ทำเองหรือจ้างภายนอก และวิธีเลือกแนวทางปี 2026

การพัฒนาแชทบอท ทำเองหรือจ้างภายนอก และวิธีเลือกแนวทางปี 2026

เมื่อมีคนในบริษัทเอ่ยขึ้นมาว่า “อยากเอาแชทบอทมาใช้” สิ่งแรกที่ต้องตัดสินใจไม่ใช่ชื่อผลิตภัณฑ์ แต่คือโครงสร้างของทีมว่าใครจะเป็นคนทำ และทำลึกถึงระดับไหน คำว่าการพัฒนาแชทบอทครอบคลุมตั้งแต่การเซ็นสัญญาใช้บริการ SaaS สำเร็จรูป การประกอบขึ้นเองด้วยเครื่องมือ AI แบบ no-code การเขียนขึ้นใหม่ทั้งหมดแบบ full scratch ไปจนถึงการผสม generative AI เข้ากับ RAG เพื่อให้ระบบตอบจากเอกสารภายในบริษัท ค่าใช้จ่ายตั้งต้นจึงกว้างตั้งแต่หลักหมื่นเยนไปจนถึงมากกว่า 11,000,000 เยน บทความนี้เขียนสำหรับผู้ดูแลงาน IT และ DX ของโรงงานสัญชาติญี่ปุ่นในไทยและอาเซียน โดยเรียบเรียงจากข้อมูลสาธารณะและสถานการณ์ ณ ปี 2026 ว่าควรเลือกทำเองหรือจ้างภายนอก และควรไปทางแบบ generative AI หรือไม่

การพัฒนาแชทบอทคืออะไร มี 4 รูปแบบที่ตัดสินกันด้วยผู้ลงมือทำ

ในทางปฏิบัติ คำว่าการพัฒนาแชทบอทถูกใช้เรียกงานที่ต่างกันอย่างสิ้นเชิงถึง 4 แบบ ถ้าปล่อยให้ทั้ง 4 แบบปนกันแล้วเดินเรื่องขออนุมัติภายใน สิ่งที่เกิดขึ้นคือพูดว่าพัฒนาแต่เนื้อแท้เป็นแค่การต่อสัญญา SaaS หรือกลับกัน พูดว่าแค่นำมาใช้แต่กลายเป็นโครงการพัฒนาระบบมูลค่าหลายล้านเยน จึงต้องแยก 4 รูปแบบให้ชัดก่อน

รูปแบบที่ 1 แบบ SaaS ซื้อบริการสำเร็จรูปแล้วตั้งค่า

เป็นการทำสัญญาใช้ผลิตภัณฑ์สำเร็จรูปของผู้ให้บริการ แล้วเข้าไปลงทะเบียนสคริปต์คำตอบและคำถามที่คาดว่าจะเจอผ่านหน้าจอผู้ดูแลระบบ ถึงจะใช้คำว่าพัฒนา แต่สิ่งที่เขียนจริงไม่ใช่โค้ด หากเป็นการตั้งค่าและเนื้อหา

จุดแข็งคือความเร็วในการเริ่มต้น นับจากเซ็นสัญญาไม่กี่สัปดาห์ก็เปิดใช้ได้ จุดอ่อนคือออกนอกกรอบที่ผู้ให้บริการวางไว้ไม่ได้ การเชื่อมต่อเฉพาะของบริษัทตัวเอง เช่นดึงยอดสต็อกจากระบบหลักมาตอบ หรือคืนค่าผลผลิตจริงจากระบบบริหารการผลิต จะมีเพดานอยู่ที่ว่าฟังก์ชันมาตรฐานรองรับหรือไม่เท่านั้น

รูปแบบที่ 2 แบบ no-code และ low-code AI ประกอบขึ้นเอง

เป็นการวางผังบทสนทนาผ่าน GUI แล้วต่อกับระบบภายนอกด้วย API หรือสคริปต์สั้นเฉพาะส่วนที่จำเป็น ระยะหลังมีผลิตภัณฑ์ที่เสริมความสามารถสร้างคำตอบด้วย generative AI เข้าไปในบางส่วนได้มากขึ้น ทำให้กลุ่มนี้กลายเป็นตัวกลางระหว่างแบบ SaaS กับแบบ full scratch และเป็นช่วงที่ถูกเลือกมากที่สุดในทางปฏิบัติ

เนื่องจากผู้ดูแลของบริษัทเองลงมือทำเป็นหลัก รูปแบบนี้จึงมักกลายเป็นรูปแบบกลางที่จะบอกว่าทำเองก็ไม่เชิง จ้างภายนอกก็ไม่เชิง การแบ่งงานแบบให้ภายนอกช่วยเฉพาะการติดตั้งครั้งแรก แล้วปรับปรุงต่อด้วยคนในบริษัท จึงเกิดขึ้นได้จริง

รูปแบบที่ 3 แบบ full scratch ออกแบบและสร้างตั้งแต่ต้น

เป็นการสร้างตั้งแต่การกำหนดความต้องการ หน้าจอ เอนจินบทสนทนา ฟังก์ชันผู้ดูแล ไปจนถึงการเชื่อมต่อกับระบบภายนอก แลกกับอิสระในการออกแบบให้เข้ากับกระบวนการทำงานของตัวเอง ทั้งค่าใช้จ่ายและระยะเวลาจะขยับขึ้นหนึ่งหลัก

ในภาคการผลิต รูปแบบนี้จำเป็นในกรณีเช่น รหัสเครื่องจักรหรือระบบรหัสชิ้นงานของโรงงานมีกติกาการตีความเฉพาะตัว จนตรรกะการค้นหาของผลิตภัณฑ์สำเร็จรูปเข้าไม่ถึงคำตอบที่ถูกต้อง พูดกลับกันคือ ถ้าอธิบายความจำเป็นแบบนี้ไม่ได้ ก็ไม่มีเหตุผลที่จะเลือก full scratch

รูปแบบที่ 4 แบบ generative AI และ RAG ให้ตอบจากเอกสารภายใน

เป็นการให้โมเดลภาษาขนาดใหญ่อ้างอิงคู่มือ ระเบียบปฏิบัติ และประวัติการสอบถามที่ผ่านมาของบริษัท แล้วสร้างคำตอบขึ้นมา เรียกกันว่า RAG ซึ่งย่อมาจาก Retrieval-Augmented Generation หรือการสร้างคำตอบเสริมด้วยการค้นคืน ความต่างที่ใหญ่ที่สุดคือไม่ต้องเขียนสคริปต์คำตอบไว้ล่วงหน้า ขอแค่มีเอกสารครบก็เริ่มตอบได้

แต่ประโยคที่ว่า “ใส่เอกสารเข้าไปแล้วมันทำงานเอง” ถูกเพียงครึ่งเดียว ในความเป็นจริง สิ่งที่ตัดสินคุณภาพคือการตัดสินใจเชิงออกแบบ เช่นจะเอาเอกสารชุดไหนเข้าระบบ จะซอยเอกสารละเอียดแค่ไหนก่อนนำไปค้น และจะให้ตอบว่าอย่างไรเมื่อหาหลักฐานไม่เจอ ถ้ามองข้ามชั่วโมงงานออกแบบส่วนนี้ ใบเสนอราคาจะเหลือแค่ครึ่งเดียวของงานจริง

จัดตำแหน่งของทั้ง 4 รูปแบบไว้ในตารางเดียว

เมื่อเรียงทั้ง 4 รูปแบบตามผู้ลงมือทำ ช่วงค่าใช้จ่าย และงานที่เหมาะ จะได้ภาพดังนี้

รูปแบบคนที่ลงมือทำเป็นหลักช่วงค่าใช้จ่ายตั้งต้นงานที่เหมาะ
แบบ SaaSผู้ให้บริการร่วมกับผู้ดูแลในบริษัทหลักหมื่นถึงหลักแสนเยนรับคำถามที่พบบ่อยเป็นด่านแรก
แบบ no-code AIผู้ดูแลในบริษัทเป็นแกนหลัก50,000 ถึงมากกว่า 800,000 เยนตอบงานประจำอัตโนมัติและเชื่อมต่อแบบง่าย
แบบ full scratchจ้างภายนอกหรือทีมพัฒนาในองค์กร1,000,000 ถึงมากกว่า 11,000,000 เยนเชื่อมลึกกับระบบหลักตามโจทย์เฉพาะตัว
แบบ generative AI และ RAGจ้างภายนอกร่วมกับทีมในบริษัทผันผวนมากตามโครงสร้างที่เลือกตอบโดยมีเอกสารภายในเป็นหลักฐาน

สิ่งสำคัญในตารางนี้ไม่ใช่จำนวนหลักของค่าใช้จ่าย แต่คือความสัมพันธ์ระหว่างสองคอลัมน์กลาง นั่นคือคนที่ลงมือทำเป็นหลักกับช่วงค่าใช้จ่ายตั้งต้น ถ้าตัดสินใจได้ว่าใครเป็นคนทำ ช่วงค่าใช้จ่ายก็แทบถูกล็อกไปด้วย และถ้าเริ่มจากงบก่อน จะเลือกผู้ลงมือทำผิดตัว ส่วนการเปรียบเทียบฟังก์ชันของแต่ละรูปแบบนั้น เราแยกไว้ในเปรียบเทียบแชทบอท 4 ประเภทและวิธีเลือกให้เหมาะกับโรงงานในไทย แล้ว บทความนี้จึงจะโฟกัสที่การตัดสินใจเรื่องโครงสร้างทีมเป็นหลัก

การพัฒนาแชทบอท ทำเองหรือจ้างภายนอก และวิธีเลือกแนวทางปี 2026 - figure 1

ทำเองหรือจ้างภายนอก ตัดสินด้วย 4 เกณฑ์

แทบทุกบริษัทมีความหวังว่า “ถ้าทำเองได้ก็อยากทำเอง” ปัญหาคือการเอาความหวังไปปนกับการประเมินว่าทำได้จริงหรือไม่ การประเมินควรทำอย่างเป็นระบบด้วย 4 เกณฑ์ต่อไปนี้

เกณฑ์ที่ 1 มีคนดูแล AI และโครงสร้างพื้นฐานข้อมูลอยู่จริงในองค์กรหรือไม่

คำถามตรงนี้ไม่ใช่ “มีคนที่เก่ง AI ไหม” แต่คือ ใครจะเป็นคนรวบรวมเอกสารภายในที่แชทบอทต้องอ้างอิง ใครจะจัดรูปแบบเอกสาร และใครจะอัปเดตต่อเนื่อง ว่ามีตัวตนอยู่จริงหรือไม่

ในกรณีของแบบ generative AI ไม่จำเป็นต้องสร้างโมเดลขึ้นเอง สิ่งที่จำเป็นคืองานเก็บไฟล์ PDF ของคู่มือ คัดฉบับที่เลขเวอร์ชันเก่าออก และแก้เอกสารที่ตารางกับเลย์เอาต์เพี้ยนให้อยู่ในรูปที่เครื่องอ่านได้ งานขั้นนี้ไม่ใช่งานของวิศวกร AI แต่เป็นงานที่มีแต่คนในบริษัทซึ่งรู้เนื้องานเท่านั้นที่ทำได้ พูดกลับกันคือถ้าหาคนคนนี้ไม่ได้ ต่อให้จ้างภายนอกก็ไม่เกิดผล เว้นแต่ขอบเขตงานที่จ้างจะรวมการรวบรวมและจัดรูปแบบเอกสารเหล่านี้ไว้ด้วย

เกณฑ์ที่ 2 ความลึกของความต้องการที่ต้องสร้างความต่าง

คำตอบจะเปลี่ยนไปตามว่าเนื้อหาที่ต้องตอบนั้นแค่ระดับคำถามพบบ่อยทั่วไปก็พอ หรือต้องแตะข้อมูลที่มีอยู่เฉพาะในบริษัทเรา

เวลาทำการ วันหยุด ปลายทางที่ต้องยื่นใบคำร้อง ข้อมูลเหล่านี้มีโครงสร้างเหมือนกันในทุกบริษัท ตรงนี้ฟังก์ชันมาตรฐานของ SaaS เพียงพอแล้วและไม่คุ้มที่จะลงแรงสร้างเอง ในทางกลับกัน ขั้นตอนการตรวจเช็กแยกตามรุ่นเครื่องจักรของเรา กฎความปลอดภัยเฉพาะของโรงงานในไทย หรือเงื่อนไขการส่งมอบแยกตามคู่ค้า ไม่มีทางติดมากับผลิตภัณฑ์ของเจ้าอื่นตั้งแต่แรก การแยกให้ออกว่าจะลงแรงสร้างเฉพาะพื้นที่ที่ต้องสร้างความต่าง คือปัจจัยที่กระทบความคุ้มค่ามากที่สุด

เกณฑ์ที่ 3 ข้อกำหนดด้านความมั่นคงปลอดภัยของข้อมูลและที่ตั้งของข้อมูล

เอกสารภายในจะถูกส่งออกไปยังคลาวด์ภายนอกได้หรือไม่ คือสิ่งแรกที่ฝ่าย IT ต้องตรวจสอบ ในกรณีของโรงงานสัญชาติญี่ปุ่น มีหลายรายที่นโยบายของสำนักงานใหญ่จำกัดการส่งเอกสารซึ่งมีแบบวิศวกรรม ต้นทุน หรือชื่อลูกค้าออกนอกประเทศ

เมื่อใช้งานที่ฐานในไทย ขอบเขตของพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล หรือ PDPA ก็เข้ามาเกี่ยวข้องด้วย ถ้าประวัติการสอบถามของพนักงานมีชื่อหรือรหัสพนักงานอยู่ ก็ต้องถือว่าเป็นข้อมูลส่วนบุคคล และต้องออกแบบเรื่องที่จัดเก็บ ระยะเวลาเก็บ และขั้นตอนการลบเข้าไปในระบบตั้งแต่ต้น ยิ่งข้อกำหนดข้อนี้เข้มเท่าไร SaaS สำเร็จรูปยิ่งตอบโจทย์ไม่ได้ และน้ำหนักจะเอียงไปทางรูปแบบที่บริษัทกำหนดโครงสร้างเองได้

เกณฑ์ที่ 4 ทีมดูแลหลังใช้งาน ใครจะเลี้ยงมันต่อ

แชทบอทไม่ได้เสร็จตอนเปิดใช้ ตรงนั้นคือจุดเริ่มต้น ต้องมีคนที่ดูรายการคำถามที่ระบบตอบไม่ได้ทุกสัปดาห์ แล้วตัดสินว่าจะเติมเอกสารหรือจะปรับขอบเขตของคำตอบ

หน้างานที่เปิดใช้โดยไม่วางบทบาทนี้ไว้ มักพบว่าผู้ใช้ค่อยๆ หายไปภายในราว 3 เดือน เพราะเมื่อเจอประสบการณ์ “ถามแล้วก็ไม่ได้คำตอบ” ติดกัน 2 ครั้ง คนก็เลิกใช้ ถ้าหาคนดูแลหลังใช้งานไม่ได้ การจ้างภายนอกแบบรวมงานดูแลไว้ด้วยกลับถูกกว่าในผลลัพธ์สุดท้าย

กระแสหลักของปี 2026 คือแบบผสม

เมื่อวางเกณฑ์ทั้งสี่เรียงกัน จะเห็นว่าหลายบริษัทไม่ได้มีคำตอบเป็นทางเลือกสองทาง มีการชี้ให้เห็นว่าในการนำไปใช้ระดับองค์กรของปี 2026 นั้น การซื้อ SaaS มาใช้กับงานตอบแบบมาตรฐาน แล้วสร้างเฉพาะงานที่ต้องการความต่างขึ้นเองหรือจ้างภายนอก คือรูปแบบผสมซึ่งครองสัดส่วนราว 70 เปอร์เซ็นต์

นี่ไม่ใช่การประนีประนอม แต่เป็นการออกแบบที่สมเหตุสมผล ถ้าสร้างเองทั้งหมดค่าใช้จ่ายจะพุ่ง ถ้าซื้อทั้งหมดก็สร้างความต่างไม่ได้ การตัดสินใจว่าจะลากเส้นแบ่งระหว่างส่วนที่ซื้อกับส่วนที่สร้างไว้ตรงไหน จึงเป็นเนื้อแท้ของการตัดสินใจเรื่องการพัฒนาแชทบอทในวันนี้

ค่าใช้จ่ายในการพัฒนาแชทบอท จำนวนหลักเปลี่ยนตามรูปแบบ

เข้าเรื่องค่าใช้จ่าย ตรงนี้ช่วงราคาต่างกันมากตามรูปแบบ การพูดรวบว่าราคากลางอยู่ที่เท่าไรจึงไม่มีความหมายในตัวมันเอง

ช่วงค่าใช้จ่ายของแบบ no-code AI

กรณีสร้างแชทบอท AI ด้วยเครื่องมือ no-code ค่าใช้จ่ายตั้งต้นโดยประมาณเป็นดังนี้

ความซับซ้อนของโครงสร้างค่าใช้จ่ายตั้งต้นโดยประมาณ
โครงสร้างขั้นต่ำ50,000 ถึง 150,000 เยน
โครงสร้างพื้นฐาน150,000 ถึง 400,000 เยน
โครงสร้างซับซ้อน400,000 ถึง 800,000 เยน
โครงสร้างซับซ้อนมาก800,000 เยนขึ้นไป

ระยะเวลาพัฒนาของช่วงนี้อยู่ที่ 1 ถึง 2 เดือน และค่าดูแลรายเดือนหลังเปิดใช้อยู่ที่ 10,000 ถึง 50,000 เยนโดยประมาณ ถ้าเป็นตัวแรกที่ทำเพื่อลดปริมาณการสอบถามภายในองค์กร ส่วนใหญ่จะจบอยู่ในกรอบนี้

ช่วงค่าใช้จ่ายของแบบ full scratch

ในทางกลับกัน การพัฒนาแบบ full scratch จะอยู่ที่ระดับต่อไปนี้

ความซับซ้อนของโครงสร้างค่าใช้จ่ายตั้งต้นโดยประมาณ
โครงสร้างขั้นต่ำ1,000,000 ถึง 3,000,000 เยน
โครงสร้างพื้นฐาน3,000,000 ถึง 6,000,000 เยน
โครงสร้างซับซ้อน6,000,000 ถึง 11,000,000 เยน
โครงสร้างซับซ้อนมาก11,000,000 เยนขึ้นไป

ระยะเวลาพัฒนาอยู่ที่ 2 ถึง 9 เดือนขึ้นไป ค่าดูแลรายเดือนอยู่ที่ 40,000 ถึง 200,000 เยน เทียบกับแบบ no-code แล้ว ค่าใช้จ่ายตั้งต้นต่างกันราว 14 ถึง 20 เท่าแล้วแต่ช่วง ส่วนค่าดูแลต่างกัน 4 เท่าพอดี การมีหรือไม่มีความต้องการที่ทำให้ส่วนต่างนี้มีเหตุผลรองรับ คือเกณฑ์เดียวที่ใช้ตัดสินว่าจะเลือก full scratch หรือไม่

แบบ generative AI กับ RAG และค่าแรงเมื่อทำเอง

ถ้าดูราคากลางในตลาดที่ใช้ภาษาอังกฤษ จะพบการอ้างถึงช่วงราคาที่ว่าแชทบอทแบบ generative AI สำหรับองค์กรอยู่ราว 30,000 ถึง 250,000 ดอลลาร์ และแบบ RAG ที่ทำขึ้นเฉพาะอยู่ราว 30,000 ถึง 150,000 ดอลลาร์ เมื่อคิดเป็นเงินเยนจะอยู่ในช่วงหลายล้านถึงหลายสิบล้านเยน ซึ่งทับกับช่วงบนของแบบ full scratch

สิ่งที่มักถูกมองข้ามคือค่าแรงเมื่อเลือกทำเอง มีการประเมินว่าการตั้งทีมเฉพาะขึ้นมาทำเองนั้น ลำพังค่าแรงก็อยู่ที่ 400,000 ถึง 700,000 ดอลลาร์ต่อปี และการเปลี่ยนไปจ้างภายนอกเปิดช่องลดต้นทุนได้ราว 40 ถึง 60 เปอร์เซ็นต์ ประเด็นที่ต้องจับให้มั่นก่อนเดินเรื่องขออนุมัติคือ การทำเองไม่ได้แปลว่าไม่มีค่าใช้จ่าย เพียงแต่ค่าใช้จ่ายย้ายไปอยู่ในบัญชีอีกหมวดหนึ่งที่ชื่อว่าค่าแรงเท่านั้น

กรอบเวลาคืนทุน

มีการให้ตัวเลขคร่าวของระยะเวลาคืนทุนไว้เช่นกัน หากเป็นการนำมาใช้ระดับพื้นฐานจะคืนทุนที่ 6 ถึง 9 เดือน ส่วนการสร้างระดับองค์กรจะอยู่ที่ 18 ถึง 24 เดือน

ส่วนต่างนี้ไม่ได้มาจากขนาดอย่างเดียว แต่มาจากลักษณะการออกผลที่ต่างกันด้วย การรับคำถามที่พบบ่อยเป็นด่านแรกจะลดจำนวนการสอบถามได้ทันทีหลังเปิดใช้ ขณะที่โครงสร้างซึ่งเชื่อมกับระบบหลักจะไม่ออกผลถ้าไม่เปลี่ยนตัวกระบวนการทำงานเอง ถ้าตั้งสมมติฐานระยะคืนทุนไว้สั้นเกินไป ครึ่งปีให้หลังจะถูกตัดสินว่า “ไม่เห็นผล” แล้วโครงการจะถูกหยุดก่อนที่ระบบจะได้โต

อนึ่ง สำหรับการลงทุนภายในประเทศญี่ปุ่น มีบางกรณีที่ใช้เงินอุดหนุนการนำ IT มาใช้ของรัฐบาลญี่ปุ่นบีบค่าใช้จ่ายตั้งต้นลงได้ราว 2 ใน 3 โดยปกติการลงทุนที่ฐานในไทยจะไม่เข้าข่าย แต่ถ้าเรียงลำดับเป็นให้สำนักงานใหญ่ในญี่ปุ่นนำร่องก่อนเพื่อสร้างต้นแบบ แล้วค่อยขยายผลงานนั้นมายังไทย ก็ยังมีช่องที่จะใช้ประโยชน์จากมาตรการนี้ได้

ส่วนวิธีมองรายละเอียดของค่าใช้จ่าย และการเปลี่ยนมุมจากค่ารายเดือนมาเป็นต้นทุนต่อการตอบหนึ่งครั้ง เราเรียบเรียงไว้อย่างละเอียดในค่าใช้จ่ายแชทบอท คิดเป็นต่อการตอบหนึ่งครั้งแทนค่ารายเดือน

สิ่งที่ต้องเคาะให้จบเมื่อเลือกทำแบบ generative AI หรือ RAG

เมื่อเลือกแบบ generative AI ประเด็นที่โผล่ขึ้นมาเสมอตั้งแต่ประตูแรกของการเลือกเทคโนโลยีคือ จะเอา RAG หรือจะทำ fine-tuning

การพัฒนาแชทบอท ทำเองหรือจ้างภายนอก และวิธีเลือกแนวทางปี 2026 - figure 2

ทำไม RAG จึงเป็นกระแสหลัก

ณ ปี 2026 มีการระบุว่าการใช้ LLM ในระดับองค์กรนั้น ราว 80 เปอร์เซ็นต์เลือกวิธีแบบ RAG เหตุผลมี 3 ข้อ

ข้อแรก แค่เปลี่ยนข้อมูลต้นทางก็พอ ไม่ต้องเทรนโมเดลใหม่ พอคู่มือถูกปรับปรุง แค่สลับไฟล์เข้าไป วันรุ่งขึ้นระบบก็ตอบด้วยเนื้อหาใหม่ ข้อสอง ผูกคำตอบกลับไปยังเอกสารต้นทางที่เป็นหลักฐานได้ ในหน้างานการผลิต การตามรอยได้ว่าทำไมถึงตอบแบบนั้นสำคัญพอกันกับความถูกต้องของคำตอบ ข้อสาม โครงสร้างแบบนี้เปลี่ยนโมเดลได้ง่าย โมเดล generative AI เปลี่ยนรุ่นกันในรอบครึ่งปี การไม่ผูกติดกับโมเดลใดโมเดลหนึ่งจึงกลายเป็นอายุการใช้งานของสินทรัพย์โดยตรง

แบ่งงานกันอย่างไรระหว่าง RAG กับ fine-tuning

Fine-tuning คือการให้โมเดลเรียนรู้ข้อมูลของบริษัทเข้าไปในตัวโมเดลเอง จึงได้ความแม่นยำสูงกับสำนวนและศัพท์เฉพาะของโดเมนนั้น แต่ในอีกด้าน มีการระบุว่าต้นทุนการพัฒนาสูงกว่า RAG ราว 40 ถึง 80 เปอร์เซ็นต์ และทุกครั้งที่ข้อมูลถูกอัปเดตก็ต้องกลับไปเทรนใหม่

ประเด็นRAGFine-tuning
การรับมือกับข้อมูลที่อัปเดตสลับเอกสารต้นทางแล้วจบต้องเทรนใหม่
ต้นทุนการพัฒนาต่ำกว่าโดยเปรียบเทียบสูงกว่า RAG ราว 40 ถึง 80 เปอร์เซ็นต์
การแสดงหลักฐานของคำตอบยกเอกสารอ้างอิงขึ้นมาแสดงได้ทำได้ยาก
ความแม่นยำเฉพาะโดเมนขึ้นกับคุณภาพของเอกสารสูง
การเปลี่ยนไปใช้โมเดลอื่นเปลี่ยนได้ง่ายสินทรัพย์ที่เทรนไว้ถูกล็อกกับโมเดลเดิม

มีรายงานว่าในการใช้งานจริง หลายรายมาบรรจบที่โครงสร้างผสมซึ่งใช้ RAG เป็นฐาน แล้วซ้อน fine-tuning แบบเบาเฉพาะบางส่วน เช่นการตีความศัพท์เฉพาะ ถ้าตั้งใบเสนอราคาโดยมี fine-tuning เป็นเงื่อนไขตั้งแต่แรก ต้นทุนจะบานและการอัปเดตจะหยุดชะงัก

4 เรื่องที่ต้องเคาะก่อนในโครงสร้าง RAG

สาเหตุที่ใบเสนอราคาของแบบ RAG แกว่งแรงระหว่างบริษัท คือการออกตัวเลขประมาณการทั้งที่ 4 ข้อต่อไปนี้ยังไม่ถูกเคาะ

  • ขอบเขตของเอกสารที่นำเข้า จะเอาโฟลเดอร์ไหน และเวอร์ชันถึงรุ่นใด ถ้าเหมาเอกสารทั้งบริษัท ลำพังการจัดชั้นความลับก็กินเวลาหลายเดือน
  • ระดับการเตรียมเอกสารก่อนนำเข้า ถ้ามีคู่มือที่เป็น PDF สแกนหรือเป็นภาพล้วนปนอยู่ ต้องเผื่อชั่วโมงงานแปลงเป็นข้อความไว้ต่างหาก เอกสารหน้างานของภาคการผลิตมักหนักที่จุดนี้
  • พฤติกรรมเมื่อหาหลักฐานไม่เจอ จะให้สร้างคำตอบขึ้นมา หรือให้ส่งต่อไปยังผู้รับผิดชอบ ถ้าไม่เคาะตรงนี้ ระบบจะปล่อยคำตอบผิดที่ดูน่าเชื่อออกมา
  • ผู้รับผิดชอบและความถี่ในการอัปเดต ใครจะสลับเอกสาร และรอบเท่าไร RAG ที่ขาดการออกแบบงานดูแลจะล้าสมัยภายในครึ่งปี

วิธีเดินงานอย่างเป็นรูปธรรมและวิธีคิดเรื่องค่าใช้จ่ายของการสร้าง RAG บนเอกสารทางเทคนิคของโรงงาน เราเขียนไว้ในการสร้าง RAG ค่าใช้จ่ายและขั้นตอนการดำเนินงาน

ประเด็นเฉพาะเมื่อพัฒนาแชทบอทที่ฐานในไทยและอาเซียน

การพัฒนาแชทบอทที่ฐานในไทยมีประเด็นหลายข้อที่บทความซึ่งเขียนสำหรับตลาดญี่ปุ่นในประเทศไม่ได้แตะถึง

การพัฒนาแชทบอท ทำเองหรือจ้างภายนอก และวิธีเลือกแนวทางปี 2026 - figure 3

ความคุ้นเคยกับ AI ของพนักงานในไทยกำลังเปลี่ยนอย่างรวดเร็ว

รัฐบาลไทยดำเนินมาตรการเปิดให้ประชาชนใช้บริการ generative AI มากกว่า 30 บริการ ซึ่งรวมถึง ChatGPT และ Gemini ฟรีเป็นเวลา 1 ปี โดยเปิดลงทะเบียนล่วงหน้าตั้งแต่วันที่ 19 สิงหาคม 2026 และเริ่มใช้งานได้ตั้งแต่วันที่ 31 สิงหาคม กลุ่มเป้าหมายคือประชาชนอายุ 15 ปีขึ้นไป จำนวน 5,000,000 คน งบประมาณอยู่ที่ราว 1,600 ล้านบาท หรือประมาณ 7,700 ล้านเยน มีรายงานว่ายอดลงทะเบียนล่วงหน้าทะลุ 1,000,000 คนภายในเวลาไม่นานหลังเปิด

เป้าหมายที่ภาครัฐประกาศไว้คือการพัฒนากำลังคนดิจิทัลและยกระดับผลิตภาพแรงงาน พร้อมกับดันอัตราการใช้ AI ซึ่งมีการระบุว่าปัจจุบันอยู่ที่ 10.7 เปอร์เซ็นต์ ให้เกิน 20 เปอร์เซ็นต์ภายในปี 2027

ผลกระทบของมาตรการนี้ต่องานจริงชัดเจนมาก เงื่อนไขตั้งต้นเปลี่ยนไปเป็นว่า แชทบอทภายในองค์กรจะถูกเปิดใช้ในสภาพที่พนักงานคนไทยคุ้นเคยกับการถาม generative AI แล้วได้คำตอบอยู่แล้ว อุปสรรคที่ใหญ่ที่สุดของการนำระบบไปใช้ที่หน้างานในบริษัทญี่ปุ่นซึ่งเคยเป็นเรื่อง “ไม่มีใครยอมใช้” จึงเปลี่ยนลักษณะไป และเกิดเกณฑ์ใหม่ขึ้นมาแทนว่า “ถ้าใช้ยากกว่า AI ทั่วไปที่ใช้ฟรีได้ ก็จะไม่มีคนใช้” การตั้งเกณฑ์คุณภาพของแชทบอทภายในองค์กรด้วยความรู้สึกแบบเมื่อไม่กี่ปีก่อนจึงเป็นการประเมินที่ผิดพลาด

มองทรัพยากรการพัฒนาในประเทศอย่างไร

ในประเทศไทยมีผู้ประกอบการที่รับงานพัฒนาแชทบอทอยู่จำนวนหนึ่ง ทั้งบริษัทข้อมูลและ AI จากต่างประเทศอย่าง Adastra ที่มีผลงานแชทบอท generative AI สำหรับภาคการผลิต และสตาร์ทอัพสัญชาติไทยอย่าง ZWIZ.AI ที่รองรับทั้งภาษาไทยและภาษาอังกฤษ จึงไม่ใช่ว่าไม่มีตัวเลือก

แต่สำหรับโรงงานสัญชาติญี่ปุ่น เกณฑ์ตัดสินไม่ได้มีแค่ความสามารถทางเทคนิค คุยรู้เรื่องทั้งกับฝ่ายระบบสารสนเทศของสำนักงานใหญ่ในญี่ปุ่นและกับบริษัทในไทยหรือไม่ ทำบันทึกการประชุมกำหนดความต้องการเป็นภาษาญี่ปุ่นได้หรือไม่ ให้คำตอบที่ทนต่อการตรวจสอบด้านความมั่นคงปลอดภัยของฝั่งญี่ปุ่นได้หรือไม่ ถ้าไม่ตกลงกันก่อนเซ็นสัญญาว่าฝ่ายใดจะรับภาระเป็นสะพานเชื่อมด้านภาษาและธรรมเนียมธุรกิจ ชั่วโมงงานในขั้นกำหนดความต้องการจะบานเป็นสองเท่าของที่คาดไว้ ส่วนเกณฑ์คัดเลือกบริษัทพัฒนาและวิธีอ่านสัญญากับใบเสนอราคา เราเรียบเรียงไว้ในวิธีเลือกบริษัทพัฒนา AI

หลายภาษาไม่ใช่ปัญหาการแปล แต่เป็นปัญหาการรวมคำศัพท์

แชทบอทของฐานในไทยส่วนใหญ่ต้องเผื่อไว้ 3 ภาษา คือภาษาไทย ภาษาอังกฤษ และภาษาญี่ปุ่น ปัญหาที่เกิดขึ้นตรงนี้ไม่ใช่ความแม่นยำของการแปล แต่คือ คำที่ใช้เรียกเครื่องจักรหรือกระบวนการเดียวกันมีอยู่ถึง 3 แบบที่หน้างาน

ตัวอย่างที่เกิดขึ้นเป็นปกติคือ กระบวนการเดียวกันนั้นพนักงานญี่ปุ่นที่ประจำอยู่เรียกด้วยคำย่อภาษาญี่ปุ่น หัวหน้างานคนไทยเรียกเป็นภาษาไทย ส่วนรหัสในระบบเป็นตัวอักษรโรมัน เนื่องจากแบบ RAG ค้นด้วยคำที่ปรากฏในเอกสาร ความไม่ตรงกันของคำเรียกนี้จึงกลายเป็นการค้นไม่เจอโดยตรง ทางแก้ไม่ใช่การเลือกโมเดลที่แรงกว่า แต่คือ การทำพจนานุกรมคำพ้องความหมายขึ้นมาแล้วลงทะเบียนเข้าระบบ งานนี้จ้างภายนอกไม่ได้ ต้องให้คนที่รู้หน้างานใช้เวลาสองสามวันทำขึ้นมาเท่านั้น ถ้างานนี้ไม่ถูกใส่ไว้ในใบเสนอราคา สาเหตุส่วนใหญ่ของอาการตอบไม่ได้หลังเปิดใช้จะมากองอยู่ตรงนี้

ที่ตั้งของข้อมูลกับนโยบายของสำนักงานใหญ่

จะประมวลผล generative AI ที่ภูมิภาคใด เป็นเรื่องที่ต้องสอดคล้องกับนโยบายความมั่นคงปลอดภัยสารสนเทศของสำนักงานใหญ่ จะประมวลผลที่ศูนย์ข้อมูลในญี่ปุ่น หรือประมวลผลภายในอาเซียนซึ่งรวมถึงสิงคโปร์ ทางเลือกนี้เปลี่ยนทั้งความเร็วในการตอบและค่าใช้จ่าย ถ้าผลักการยืนยันเรื่องนี้ไปทีหลัง พอพัฒนาเสร็จแล้วจะไปติดที่การตรวจสอบของสำนักงานใหญ่ และต้องรื้อโครงสร้างใหม่ ทางที่แน่นอนกว่าคือขอความเห็นชอบเรื่องภูมิภาคที่ใช้ประมวลผลกับฝ่ายระบบสารสนเทศของสำนักงานใหญ่ให้จบก่อนลงมือ

สิ่งที่ควรจัดระเบียบให้เรียบร้อยก่อนไปคุยกับผู้รับงาน

ความแม่นยำของใบเสนอราคาถูกตัดสินด้วยว่าฝ่ายผู้ว่าจ้างจัดระเบียบมาถึงระดับไหนก่อนเข้าไปปรึกษา รายการต่อไปนี้คือสิ่งที่ต้องเคาะก่อนเหมือนกัน ไม่ว่าจะจ้างภายนอกหรือทำเอง

สำรวจคำถามที่คาดว่าจะเจอจากข้อมูลจริง

เริ่มจากรวบรวมบันทึกการสอบถามย้อนหลังครึ่งปี จะเป็นทิกเก็ตของเฮลป์เดสก์ อีเมลที่ส่งถึงฝ่ายธุรการ หรือแม้แต่โน้ตคำถามที่หัวหน้างานหน้าไลน์ได้รับมาก็ใช้ได้ จากนั้นเรียงตามความถี่จากมากไปน้อย แล้วหาให้ได้ว่า 30 อันดับแรกกินสัดส่วนกี่ส่วนของทั้งหมด

ในทางปฏิบัติพบได้บ่อยว่า 30 อันดับแรกกินสัดส่วนที่มีนัยสำคัญของการสอบถามทั้งหมด พอรู้สัดส่วนนี้ ขอบเขตของเฟสแรกก็จะถูกกำหนดขึ้นเองโดยธรรมชาติ ไม่จำเป็นต้องสร้างบอทที่ตอบได้ทุกเรื่อง บอทที่ตอบ 30 อันดับแรกได้อย่างมั่นใจให้ประโยชน์จริงมากกว่า ขั้นตอนการสำรวจการสอบถามภายในองค์กรอย่างเป็นรูปธรรม เราแตะไว้ในระบบตอบคำถามภายในองค์กรอัตโนมัติ เช่นกัน

เคาะขอบเขตที่ห้ามตอบไว้ก่อน

เรื่องที่กลายเป็นปัญหาในการพัฒนาแชทบอทไม่ใช่คำถามที่ระบบตอบไม่ได้ แต่คือกรณีที่ระบบดันไปตอบคำถามที่ไม่ควรตอบ

เงินเดือน การประเมินผลบุคลากร ปัญหาแรงงานสัมพันธ์ การตัดสินใจหน้างานที่กระทบความปลอดภัยโดยตรง และการตีความเงื่อนไขในสัญญา ทั้งหมดนี้เป็นพื้นที่ที่ไม่มีอะไรรับประกันว่าจะคืนคำตอบที่ถูกต้อง และความเสียหายเมื่อตอบผิดสูงมาก จึงควรออกแบบให้ กำหนดไว้ล่วงหน้าว่าอยู่นอกขอบเขต แล้วส่งต่อให้ผู้รับผิดชอบ ถ้าเขียนเส้นแบ่งนี้ไว้ในเอกสารกำหนดความต้องการ ก็นำไปใช้เป็นเกณฑ์ตัดสินในการทดสอบตรวจรับได้ทันที

ตั้งเกณฑ์ตรวจรับเป็นตัวเลข

การเขียนว่า “ต้องมีความแม่นยำสูง” ใช้ตรวจรับงานไม่ได้ ในทางปฏิบัติจะเขียนออกมาในรูปแบบต่อไปนี้

ประเภทของเกณฑ์ตัวอย่างวิธีตั้ง
อัตราตอบถูกสัดส่วนที่ระบบยกเอกสารอ้างอิงที่ถูกต้องขึ้นมาได้ จากชุดคำถามที่เตรียมไว้ล่วงหน้า 100 คำถาม
การจัดการคำตอบผิดจำนวนครั้งที่ระบบสร้างคำตอบในพื้นที่ซึ่งระบุว่าอยู่นอกขอบเขต ต้องเป็นศูนย์
เวลาตอบสนองเพดานของเวลานับตั้งแต่ส่งคำถามจนแสดงคำตอบ
อัตราการส่งต่อสัดส่วนที่เกิดการส่งต่อให้ผู้รับผิดชอบ พร้อมรายละเอียดแยกตามประเภท

ชุดทดสอบ 100 คำถามนี้เป็นสิ่งที่ฝ่ายผู้ว่าจ้างต้องทำเอง ถ้าปล่อยให้ผู้รับงานทำ สิ่งที่จะได้คือรายการคำถามที่ระบบตอบได้อยู่แล้วเท่านั้น

กำหนดทีมดูแลและรอบการปรับปรุง

เคาะให้ชัดว่าหลังเปิดใช้แล้ว ใครจะดูแลด้วยความถี่เท่าไร สิ่งที่ต้องมีอย่างน้อยคือผู้รับผิดชอบที่ตรวจล็อกคำถามซึ่งระบบตอบไม่ได้สัปดาห์ละ 1 ครั้ง แล้วตัดสินว่าจะเพิ่มเอกสารหรือจะปรับขอบเขตที่ระบบรับผิดชอบตอบ ในแง่ชั่วโมงงานคือราว 1 ถึง 2 ชั่วโมงต่อสัปดาห์ แต่การมีหรือไม่มีเวลาส่วนนี้ทำให้อัตราการใช้งานในอีกครึ่งปีถัดไปต่างกันคนละเรื่อง

คำถามที่พบบ่อย

การพัฒนาแชทบอทหมายถึงอะไรกันแน่

คำนี้ถูกใช้เรียกงาน 4 ประเภท ตั้งแต่งานตั้งค่า SaaS การประกอบขึ้นด้วยเครื่องมือ no-code การพัฒนาระบบแบบ full scratch ไปจนถึงการสร้างด้วย generative AI และ RAG เนื่องจากค่าใช้จ่ายกว้างตั้งแต่หลักหมื่นเยนไปจนถึงมากกว่า 11,000,000 เยน เวลาคุยกันในองค์กรจึงควรยืนยันก่อนเป็นอันดับแรกว่ากำลังพูดถึงรูปแบบไหน

การพัฒนาแชทบอทมีค่าใช้จ่ายเท่าไร

ถ้าเป็นแบบ no-code AI ค่าใช้จ่ายตั้งต้นอยู่ที่ 50,000 ถึงมากกว่า 800,000 เยน และรายเดือน 10,000 ถึง 50,000 เยนโดยประมาณ ส่วนแบบ full scratch อยู่ในช่วงตั้งต้น 1,000,000 ถึงมากกว่า 11,000,000 เยน และรายเดือน 40,000 ถึง 200,000 เยน แบบ generative AI และ RAG อยู่ตรงกลางค่อนไปทางบน และผันผวนมากตามปริมาณเอกสารที่นำเข้าและความหนักของงานเตรียมเอกสาร

ควรทำเองหรือจ้างภายนอกดี

ให้ตัดสินจากว่า มีผู้รับผิดชอบที่จะรวบรวมเอกสารภายใน จัดรูปแบบ และอัปเดตต่อเนื่องหลังเปิดใช้หรือไม่ ไม่ใช่ตัดสินจากว่ามีวิศวกร AI ในองค์กรหรือไม่ ถ้าหาคนคนนี้ได้ ให้ทำเองหรือจ้างภายนอกบางส่วน ถ้าหาไม่ได้ การจ้างภายนอกแบบรวมงานจัดเตรียมเอกสารและงานดูแลไว้ด้วยจะสมเหตุสมผลกว่า ณ ปี 2026 รูปแบบผสมที่ซื้อส่วนมาตรฐานแล้วสร้างเฉพาะส่วนที่ต้องการความต่างครองสัดส่วนราว 70 เปอร์เซ็นต์

ถ้าเลือกแบบ generative AI จะตอบคำถามภายในองค์กรได้โดยไม่ต้องเทรนใช่หรือไม่

ถ้าเป็นวิธีแบบ RAG ระบบอ้างอิงเอกสารภายในเพื่อตอบได้โดยไม่ต้องเทรนโมเดลใหม่ แต่ในสภาพที่เอกสารเก่า ยังเป็นภาพสแกนที่ไม่ได้แปลงเป็นข้อความ หรือคำที่ใช้เรียกเครื่องจักรเดียวกันมีหลายแบบที่หน้างาน ระบบก็ค้นได้ไม่ถูกต้อง สิ่งที่ตัดสินคุณภาพคำตอบคือสภาพของเอกสารที่ให้ระบบอ้างอิง ไม่ใช่สมรรถนะของโมเดล

ควรเผื่อระยะเวลาพัฒนาไว้เท่าไร

แบบ no-code AI อยู่ที่ 1 ถึง 2 เดือน แบบ full scratch อยู่ที่ 2 ถึง 9 เดือนขึ้นไปโดยประมาณ และต้องบวกระยะเวลาทำงานของฝั่งผู้ว่าจ้างเข้าไปด้วย ทั้งการรวบรวมและจัดระเบียบเอกสารภายใน การสำรวจคำถามที่คาดว่าจะเจอ และการสร้างชุดทดสอบ ความเร็วในการเริ่มใช้งานจริงถูกตัดสินด้วยว่าเดินงานเตรียมการเหล่านี้คู่ขนานไปได้หรือไม่

สรุป

ประเด็นสำคัญของบทความนี้มีดังนี้

  • การพัฒนาแชทบอทแบ่งเป็น 4 รูปแบบ คือแบบ SaaS แบบ no-code AI แบบ full scratch และแบบ generative AI กับ RAG เมื่อตัดสินใจได้ว่าใครเป็นผู้ลงมือทำ ช่วงค่าใช้จ่ายก็แทบถูกกำหนดตามไปด้วย
  • การตัดสินว่าจะทำเองหรือจ้างภายนอก ให้ใช้ 4 เกณฑ์ คือการมีอยู่จริงของผู้รับผิดชอบที่รวบรวมและอัปเดตเอกสารภายใน ความลึกของความต้องการที่ต้องสร้างความต่าง ข้อกำหนดด้านความมั่นคงปลอดภัยของข้อมูล และทีมดูแลหลังใช้งาน ไม่ใช่ดูว่ามีวิศวกร AI หรือไม่
  • ในการนำไปใช้ระดับองค์กรของปี 2026 รูปแบบผสมที่ซื้อส่วนมาตรฐานเป็น SaaS แล้วสร้างเฉพาะส่วนที่ต้องการความต่างครองสัดส่วนราว 70 เปอร์เซ็นต์
  • ค่าใช้จ่ายแบบ no-code AI อยู่ที่ตั้งต้น 50,000 ถึงมากกว่า 800,000 เยน และรายเดือน 10,000 ถึง 50,000 เยน ส่วนแบบ full scratch อยู่ที่ตั้งต้น 1,000,000 ถึงมากกว่า 11,000,000 เยน และรายเดือน 40,000 ถึง 200,000 เยน
  • มีการประเมินว่าค่าแรงของทีมเฉพาะเมื่อทำเองอยู่ที่ 400,000 ถึง 700,000 ดอลลาร์ต่อปี และการจ้างภายนอกเปิดช่องลดต้นทุนได้ราว 40 ถึง 60 เปอร์เซ็นต์ การทำเองไม่ได้ทำให้ค่าใช้จ่ายหายไป เพียงแต่ย้ายหมวดบัญชีเท่านั้น
  • กรอบเวลาคืนทุนอยู่ที่ 6 ถึง 9 เดือนสำหรับการนำมาใช้ระดับพื้นฐาน และ 18 ถึง 24 เดือนสำหรับระดับองค์กร
  • ในแบบ generative AI นั้น RAG เป็นกระแสหลักที่ครองราว 80 เปอร์เซ็นต์ ขณะที่ fine-tuning มีต้นทุนการพัฒนาสูงกว่า RAG ราว 40 ถึง 80 เปอร์เซ็นต์ การใช้งานจริงส่วนใหญ่มาบรรจบที่โครงสร้างผสมซึ่งมี RAG เป็นแกน
  • ในไทย มาตรการของรัฐเปิดลงทะเบียนล่วงหน้าเมื่อวันที่ 19 สิงหาคม 2026 และเริ่มให้ประชาชนอายุ 15 ปีขึ้นไป จำนวน 5,000,000 คน ใช้บริการ generative AI มากกว่า 30 บริการฟรี 1 ปี ตั้งแต่วันที่ 31 สิงหาคม ความคุ้นเคยกับ AI ของพนักงานในประเทศจะถูกยกระดับอย่างรวดเร็ว และเกณฑ์คุณภาพของแชทบอทภายในองค์กรก็ต้องถูกยกขึ้นตาม
  • สิ่งที่ต้องจัดระเบียบก่อนไปคุยกับผู้รับงานมี 4 ข้อ คือคำถามที่คาดว่าจะเจอ 30 อันดับแรก ขอบเขตที่ห้ามตอบ เกณฑ์ตรวจรับที่แปลงเป็นตัวเลข และผู้ดูแลหลังเปิดใช้

บริษัทส่วนใหญ่ที่สะดุดกับการพัฒนาแชทบอท ไม่ได้เลือกเทคโนโลยีผิด แต่เริ่มขอใบเสนอราคาทั้งที่ยังไม่ได้เคาะเรื่องผู้ลงมือทำและทีมดูแล เมื่อสองเรื่องนี้ถูกเคาะแล้ว การเลือกรูปแบบจะถูกคัดกรองให้แคบลงเองโดยอัตโนมัติ

จะอยู่ในขั้นตอนที่ยังต้องแยกแยะว่าบริษัทของเราเข้าข่ายรูปแบบไหน และควรซื้อถึงตรงไหนแล้วเริ่มสร้างจากตรงไหนก็ไม่เป็นไร TOMAS TECH มีฐานอยู่ที่กรุงเทพมหานคร ให้การสนับสนุนโรงงานสัญชาติญี่ปุ่นในพื้นที่ตั้งแต่การกำหนดความต้องการของระบบตอบคำถามภายในองค์กรอัตโนมัติและระบบแบบ generative AI กับ RAG ไปจนถึงการสร้างและการออกแบบงานดูแลหลังเปิดใช้ เรารับปรึกษาแม้เพียงเรื่องการสำรวจคำถามที่คาดว่าจะเจอหรือแนวทางการเดินงาน หากอยู่ในขั้นพิจารณา ติดต่อเราได้ที่แบบฟอร์มติดต่อสอบถาม

แหล่งอ้างอิง