จุดแยกของการนำ RAG มาใช้ในองค์กร 2026 | หยุดแค่ PoC หรือคืนทุน

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

RAG คืออะไร | ตั้งหลักเรื่องการใช้ข้อมูลภายในองค์กรกับ Generative AI ให้ตรงกันก่อน

RAG ย่อมาจาก Retrieval-Augmented Generation หมายถึงกลไกที่ก่อนจะให้ Generative AI ตอบ ระบบจะค้นหาและดึงส่วนที่เกี่ยวข้องออกมาจากเอกสารภายในองค์กรก่อน แล้วส่งสิ่งที่ดึงมานั้นให้เป็นหลักฐานประกอบ จากนั้นจึงให้สร้างคำตอบขึ้นมา

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

จากโครงสร้างนี้เอง เราสามารถอนุมานได้โดยตรงว่าคำถามแบบไหนที่ RAG ถนัดและแบบไหนที่ไม่ถนัด

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

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

จุดแยกของบริษัทที่นำ RAG มาใช้ | บริษัทที่หยุดอยู่แค่ PoC ต่างกันตรงไหน

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

คำทำนาย 2 ข้อของ Gartner ที่ชี้ให้เห็นหลุมพราง

Gartner ทำนายไว้ในข่าวประชาสัมพันธ์วันที่ 29 กรกฎาคม 2024 ว่า โครงการ Generative AI อย่างน้อย 30% จะถูกล้มเลิกหลังจากขั้น PoC หรือการพิสูจน์แนวคิด ภายในสิ้นปี 2025 สาเหตุของการล้มเลิกที่ถูกยกขึ้นมาคืออย่างใดอย่างหนึ่งในสี่ข้อนี้ ได้แก่ คุณภาพข้อมูลที่ต่ำ การควบคุมความเสี่ยงที่ไม่รัดกุม ค่าใช้จ่ายที่บานปลาย และคุณค่าทางธุรกิจที่ไม่ชัดเจน

นอกจากนี้ Gartner ยังออกคำทำนายที่เจาะจงกว่าเดิมในข่าวประชาสัมพันธ์วันที่ 26 กุมภาพันธ์ 2025 นั่นคือ ภายในปี 2026 องค์กรจะละทิ้งโครงการ AI ที่ไม่ได้รับการรองรับด้วยข้อมูลที่อยู่ในสภาพพร้อมใช้กับ AI ไปถึง 60% สิ่งที่มองข้ามไม่ได้ตรงนี้คือ มันไม่ได้บอกว่าโครงการ AI ทั้งหมด 60% จะล้มเหลว เป้าหมายถูกจำกัดไว้เฉพาะโครงการที่ “ไม่ได้รับการรองรับด้วยข้อมูลที่ถูกจัดให้อยู่ในสภาพที่ AI ใช้งานได้” เท่านั้น คำขยายที่จำกัดขอบเขตนี้เองคือคุณค่าในเชิงปฏิบัติของคำทำนายข้อนี้

ในข่าวประชาสัมพันธ์ฉบับเดียวกันยังแสดงผลสำรวจที่ทำกับผู้รับผิดชอบด้านการบริหารจัดการข้อมูลจำนวน 248 คน ในไตรมาสที่ 3 ของปี 2024 ว่า 63% ขององค์กรตอบว่าตนเองไม่มีแนวปฏิบัติด้านการบริหารจัดการข้อมูลที่เหมาะกับ AI หรือไม่ทราบว่ามีหรือไม่ พูดอีกอย่างคือ 2 ใน 3 บริษัทไม่สามารถบอกได้ว่าข้อมูลของตัวเองอยู่ในสภาพที่ AI ใช้งานได้หรือยัง

ผลวัดจริงของ Canon IT Solutions ที่บอกว่า “ตัวที่แย่ไม่ใช่ LLM”

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

ผลลัพธ์ตรงไปตรงมา รายการที่ได้รับการประเมินว่า “Good” อยู่ที่ราว 1 ใน 3 ของทั้งหมดเท่านั้น แต่สิ่งที่ต้องสังเกตอยู่ถัดจากนั้น เพราะมีการเปิดเผยสัดส่วนของสาเหตุที่ทำให้ถูกประเมินว่า “Bad” ด้วย

เราคิดว่าตารางนี้คือตัวเลขชุดแรกที่ทุกบริษัทซึ่งกำลังพิจารณาการนำ RAG มาใช้ควรได้เห็น ในบรรดาสาเหตุของคำตอบที่แย่ สิ่งที่เกิดจากตัว Generative AI เองมีเพียง 12% เท่านั้น ส่วนที่เหลืออีก 88% เกิดจากการที่เอกสารต้นทางมีไม่พอหรือไม่ได้ถูกจัดให้เรียบร้อย และจากการที่ระบบหาเอกสารที่ต้องการไม่เจอ แปลว่าพื้นที่ซึ่งแนวคิดแบบ “เปลี่ยนไปใช้ LLM ที่ฉลาดกว่าเดี๋ยวก็ดีขึ้น” เอื้อมไปไม่ถึงนั้น ใหญ่กว่ากันอย่างเทียบไม่ติด

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

จุดแยกที่ 1 ตัดสินใจว่า “ค่อยไปจัดการข้อมูลทีหลัง” เมื่อไร ก็แพ้ตั้งแต่ตอนนั้น

ปัจจัยที่แยกบริษัทที่จบแค่ PoC ออกจากบริษัทที่เดินไปถึงการใช้งานจริงมากที่สุด คือท่าทีที่มีต่อคุณภาพของข้อมูล บทความที่ AQUA LLC สรุปสาเหตุความล้มเหลวของการนำ RAG มาใช้ ชี้ว่า การเตรียมข้อมูลใช้ปริมาณงานราว 40% ถึง 60% ของทั้งโครงการ แต่หลายองค์กรกลับประเมินส่วนนี้ต่ำเกินไป

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

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

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

จุดแยกที่ 2 การขยายขอบเขตแบบไร้ขีดจำกัดเริ่มต้นจากคำว่า “ใช้ทั้งบริษัท”

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

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

ในบรรดาสาเหตุการล้มเลิกที่ Gartner ยกมา ข้อ “ค่าใช้จ่ายที่บานปลาย” กับ “คุณค่าทางธุรกิจที่ไม่ชัดเจน” ส่วนใหญ่ปรากฏขึ้นในฐานะผลลัพธ์ของการขยายขอบเขตแบบนี้ วิธีที่แน่นอนที่สุดในการคุมค่าใช้จ่ายคือ ไม่เล็งการใช้ทั้งบริษัทตั้งแต่แรก แต่ทำ PoC กับงาน 1 หรือ 2 งาน ยืนยันผลลัพธ์ให้ได้ก่อน แล้วค่อยขยาย

จุดแยกที่ 3 อย่าเริ่มใช้งานจริงโดยยังไม่กำหนดโครงสร้างการดูแลระบบ

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

ในบทความของ AQUA LLC ที่กล่าวถึงข้างต้น ระบุว่า ควรเผื่อค่าใช้จ่ายในการดูแลระบบต่อปีไว้ราว 15% ถึง 25% ของค่าพัฒนาเริ่มต้น แต่สิ่งที่สำคัญกว่าจำนวนเงินคือ การกำหนดให้ชัดก่อนเริ่มใช้งานว่าใครจะเป็นคนทำงานเหล่านี้ ถ้าวางโครงไว้แบบให้ผู้รับผิดชอบของฝ่ายไอทีที่ควบตำแหน่งอื่นอยู่ทำ “ตอนที่ว่าง” ภายใน 3 เดือนการอัปเดตจะหยุดลง และ RAG ที่การอัปเดตหยุดลงจะกลายเป็นกลไกที่ตอบข้อมูลเก่าอย่างมั่นอกมั่นใจ ซึ่งอันตรายกว่าตอนก่อนนำมาใช้เสียอีก

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

ตรวจสอบว่าบริษัทของเราอยู่ฝั่งไหน

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

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

ค่าใช้จ่ายในการนำ RAG มาใช้ ปี 2026 | ช่วงราคาและ 3 ปัจจัยที่ทำให้ใบเสนอราคาขยับ

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

ช่วงราคาแยกตามขนาด

ราคากลางที่แบ่งตามเฟส ตามตัวเลขที่ GXO เปิดเผยคือ PoC อยู่ที่ 1,000,000 ถึง 3,000,000 เยน ใช้เวลา 2 ถึง 6 สัปดาห์ การสร้างระบบสำหรับใช้งานจริงอยู่ที่ 3,000,000 ถึง 10,000,000 เยน ใช้เวลา 2 ถึง 4 เดือน และค่าดูแลระบบรายเดือนอยู่ที่ 100,000 ถึง 500,000 เยน มุมมองที่แยกย่อยรายละเอียดของแต่ละเฟสลงไปเป็นชั้น ๆ ได้กล่าวไว้ในค่าใช้จ่ายและแนวทางการสร้าง RAG แล้ว ตรงนี้จึงขอวางราคากลาง แยกตามขนาด ที่ Root Team เปิดเผย ในฐานะอีกมุมหนึ่งที่เชื่อมตรงกับการตัดสินใจลงทุน ตอนกำหนดว่าบริษัทของเราจะเล็งขั้นไหน การแบ่งแบบนี้น่าจะใช้ง่ายกว่า

เมื่อวางสองชุดนี้เรียงกัน จะเห็นว่าช่วงราคาของ PoC และการสร้างระบบสำหรับใช้งานจริงทับซ้อนกันเป็นส่วนใหญ่ ขณะที่ค่าดูแลระบบรายเดือนนั้นเหลื่อมกันทั้งช่วง โดย GXO อยู่ที่ 100,000 ถึง 500,000 เยน ส่วน Root Team อยู่ที่ 200,000 ถึง 800,000 เยน ความต่างนี้มาจากนิยามว่าจะนับอะไรเข้าไปในคำว่าดูแลระบบ ดังนั้นตอนขอใบเสนอราคา ขอให้ตรวจสอบว่า “ค่าบำรุงรักษาครอบคลุมงานอะไรบ้าง” ก่อนดูจำนวนเงิน อนึ่ง ทั้งสองแหล่งเป็นตัวเลขประมาณการที่บริษัทผู้พัฒนาเปิดเผยเอง ไม่ใช่ผลสำรวจตลาดจากบุคคลที่สามที่เป็นอิสระ อีกทั้งยังเป็นระดับราคาของตลาดในประเทศญี่ปุ่น จึงใช้เป็นภาพรวมของโครงสร้างค่าใช้จ่ายได้ แต่แปลงมาเทียบกับใบเสนอราคาในประเทศไทยตรง ๆ ไม่ได้ การที่ใบเสนอราคาของบริษัทเราหลุดออกจากช่วงนี้จึงไม่ใช่ปัญหาในตัวมันเอง สิ่งที่สำคัญคืออธิบายเหตุผลที่หลุดออกไปได้หรือไม่

สิ่งที่ต้องระวังคือ การใช้งานจริงเต็มรูปแบบนั้นไม่มีเพดานอยู่จริง การเขียนว่า 15,000,000 เยนขึ้นไป หมายความว่ามันพุ่งขึ้นได้ไม่จำกัดตามจำนวนระบบที่ต้องเชื่อมต่อและความซับซ้อนของการจัดการสิทธิ์ ตัว Root Team เองก็สรุปไว้เช่นกันว่า หากต้องการคุมค่าใช้จ่าย อย่าเล็งการใช้ทั้งบริษัทตั้งแต่แรก แต่ให้ยืนยันผลลัพธ์ด้วย PoC ขนาดเล็กก่อนแล้วค่อยขยายขอบเขต

ค่าใช้จ่ายส่วนใหญ่ไม่ได้ไปที่โมเดล แต่ไปที่ข้อมูลกับหน้าจอ

สิ่งที่สำคัญกว่าช่วงของจำนวนเงินคือโครงสร้างของรายการย่อย GXO ได้เปิดเผยตัวอย่างรายการย่อยแยกตามหมวดค่าใช้จ่าย สำหรับ PoC ขนาดเล็กที่มีเป้าหมายเป็นการค้นหา FAQ ของฝ่ายไอที รายละเอียดของตัวจำนวนเงินเอง และการที่มันสะสมขึ้นอย่างไรในแต่ละขั้นของการสร้างระบบและการดูแลระบบ ขอยกไปไว้ที่ค่าใช้จ่ายและแนวทางการสร้าง RAG ตรงนี้จะดึงออกมาเฉพาะ สัดส่วนองค์ประกอบ ที่เชื่อมตรงกับการตัดสินใจลงทุนเท่านั้น

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

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

3 ปัจจัยที่ทำให้ใบเสนอราคาขยับ

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

• จำนวนและรูปแบบของเอกสารเป้าหมาย ใบเสนอราคาที่ตั้งอยู่บนเอกสาร 100 ฉบับ กับใบที่ตั้งอยู่บนเอกสาร 1,000 ฉบับ ปริมาณงานในการจัดเตรียมข้อมูลต่างกันคนละหลัก ขอให้แจ้งสัดส่วนของ PDF ที่มาจากการสแกนด้วยเสมอ
• จำเป็นต้องมีการจัดการสิทธิ์หรือไม่ ฟังก์ชันควบคุมว่าใครค้นหาเอกสารใดได้บ้างนั้น ไม่ปรากฏเป็นหมวดค่าใช้จ่ายในตัวอย่างรายการย่อยของ PoC และตามธรรมเนียมจะตั้งขึ้นครั้งแรกตอนใช้งานจริง ถ้าจัดการเอกสารที่มีข้อมูลบุคลากรหรือเงื่อนไขการค้าอยู่ด้วย ก็ละข้อนี้ไม่ได้ ลำพังการมีหรือไม่มีหัวข้อนี้ก็ทำให้ราคาต่างกันตั้งแต่หลักหลายแสนไปจนถึงหลักล้านเยน
• วิธีฝังเข้ากับระบบเดิม จะสร้างหน้าจอเฉพาะขึ้นใหม่ หรือจะไปวางบนพอร์ทัลภายในองค์กรหรือแชตที่ใช้ทำงานอยู่แล้ว ทำให้ค่าพัฒนา UI ขยับมาก และตรงนี้คือหัวข้อที่มีช่องต่อรองมากที่สุดในสามปัจจัย

เกณฑ์ปริมาณงานที่ทำให้คืนทุนได้

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

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

สมมติว่างานรับคำถามใช้เวลา 20 นาทีต่อเรื่อง และทำโดยผู้รับผิดชอบที่มีค่าแรง 3,000 เยนต่อชั่วโมง ถ้า RAG ทำให้เวลาที่ใช้ลดลง 30% มูลค่าที่ลดได้ต่อเรื่องคือ 30% ของ 20 นาที เท่ากับ 6 นาที หรือคิดเป็น 300 เยน เมื่อยึด 300 เยนนี้เป็นแกน เราก็ย้อนคำนวณปริมาณงานที่ต้องมีได้ ฝั่งการลงทุนเราจะวางไว้ที่ การใช้งานจริงเต็มรูปแบบ ซึ่งหมายถึงการใช้ทั้งบริษัทและเชื่อมต่อหลายระบบ อันเป็นระดับที่หนักที่สุดในช่วงราคาแยกตามขนาดข้างต้น เงินลงทุนเริ่มต้นเอาค่ากลาง ๆ ของช่วง 5,000,000 ถึง 15,000,000 เยน มาเป็น 10,000,000 เยน ส่วนค่าดูแลระบบต่อปี เอาค่าค่อนไปทางล่างของช่วง 200,000 ถึง 800,000 เยนต่อเดือน มาเป็น 400,000 เยนต่อเดือน จึงได้เป็น 4,800,000 เยนสำหรับ 12 เดือน สำหรับเงินลงทุนในกรณีที่เริ่มเล็กแล้วไล่ไปทีละขั้น ได้สรุปไว้เป็น 3 ขั้นคือ PoC การสร้างระบบใช้งานจริง และการดูแลระบบ อยู่ในค่าใช้จ่ายและแนวทางการสร้าง RAG แล้ว ขอให้ใช้ขั้นตอนเดียวกันนี้แทนค่าตามขนาดของบริษัทเราเอง

ในการวางสมมติฐานแบบนี้ ค่าดูแลระบบรายปี 4,800,000 เยน คิดเป็น 48% ของเงินลงทุนเริ่มต้น 10,000,000 เยน ซึ่งสูงกว่าเกณฑ์ 15% ถึง 25% ที่ AQUA LLC เสนอไว้ข้างต้นอยู่มาก แปลว่าเมื่อตั้งต้นจากการใช้ทั้งบริษัท ต่อให้หยิบค่าค่อนไปทางล่างของช่วงค่าดูแลระบบมาใช้ ก็ยังได้อัตราส่วนเท่านี้ ค่าดูแลระบบจริงจะขึ้นลงตามจำนวนเอกสารเป้าหมายและความถี่ของการอัปเดต ตอนคำนวณให้บริษัทของเราเอง การทำออกมา 2 แบบโดยขยับสมมติฐานของค่าดูแลระบบขึ้นและลง จะทำให้การตัดสินใจไม่แกว่ง

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

ประเด็นเพิ่มเติมที่บริษัทซึ่งนำ RAG มาใช้ในฐานปฏิบัติการที่ไทยและอาเซียนต้องพิจารณา

ที่ผ่านมาเป็นเรื่องที่ใช้ร่วมกันได้แม้ในประเทศญี่ปุ่น แต่กรณีที่นำมาใช้ในฐานปฏิบัติการที่ประเทศไทยและประเทศอื่นในอาเซียน จะมีปัจจัยประกอบการตัดสินใจเพิ่มขึ้นอีก 4 ข้อ ทุกข้อถ้าจัดระเบียบไว้ก่อนยื่นขออนุมัติงบประมาณ จะลดจำนวนรอบของการตีกลับเพื่อขออนุมัติลงได้ อนึ่ง ประเด็นที่เกิดร่วมกันใน Generative AI ทั้งหมดโดยไม่จำกัดแค่ RAG อย่างเช่นความพร้อมด้านทักษะของพนักงานท้องถิ่นและความสอดคล้องกับแนวปฏิบัติของสำนักงานใหญ่ ได้สรุปไว้ในความล้มเหลวของการนำ Generative AI มาใช้ ปี 2026 และโครงสร้างที่ทำให้ 95% หยุดนิ่ง ตรงนี้จะจำกัดอยู่ที่การตัดสินใจเฉพาะของ RAG เท่านั้น

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

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

ที่เก็บข้อมูลและระเบียบภายในองค์กร ประเทศไทยมีพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล หรือ PDPA บังคับใช้อยู่ กรณีที่จัดการเอกสารซึ่งมีข้อมูลส่วนบุคคล จำเป็นต้องกำหนดฐานทางกฎหมายในการประมวลผลและแนวทางการโอนข้อมูลข้ามพรมแดนให้ชัดเจน นอกจากนี้ หากระเบียบการจัดการสารสนเทศที่สำนักงานใหญ่ในญี่ปุ่นกำหนดไว้ถูกใช้กับฐานปฏิบัติการในต่างประเทศด้วย ถ้าไม่ได้ตกลงการตีความไว้ล่วงหน้าว่าตามระเบียบแล้วส่งข้อมูลไปยัง API ภายนอกได้ถึงระดับใด งานจะหยุดตอนใกล้เริ่มใช้งานจริง หลุมพรางเฉพาะของ RAG อยู่ที่ว่า สิ่งที่ต้องตรวจสอบไม่ได้มีแค่เอกสารต้นฉบับ เราต้องตรวจสอบที่เก็บของทั้ง 4 ชนิด ได้แก่ ตัวเอกสารต้นฉบับ ข้อความที่สกัดออกมาจากเอกสารนั้น ข้อมูลที่แปลงเป็นตัวเลขเพื่อใช้ค้นหา และบันทึกการใช้งาน เรื่องนี้เขียนไว้อย่างละเอียดในค่าใช้จ่ายและแนวทางการสร้าง RAG ที่อ้างถึงข้างต้น ส่วนการเลือกฝั่งโครงสร้างพื้นฐานว่าจะใช้ API ภายนอก จะวางโมเดลไว้ในสภาพแวดล้อมของบริษัทเอง หรือจะใช้ทั้งสองอย่างแบ่งตามงาน มีผลอย่างมากทั้งต่อค่าใช้จ่ายและความแม่นยำ จึงคุ้มค่าที่จะพิจารณาแยกออกจากการออกแบบ RAG แกนของการตัดสินใจได้สรุปไว้ในการนำ LLM มาใช้ถูกกำหนดด้วยวิธีถือครองโครงสร้างพื้นฐาน ทั้งแบบ API แบบโฮสต์เอง และแบบไฮบริด

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

ก่อนขยายไปสู่ AI ที่ทำงานอัตโนมัติ ให้ขีดเส้นไว้ก่อน

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

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

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

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

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

ตอนเลือกผู้ให้บริการ ให้ดูตรงไหนของข้อเสนอ

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

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

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

สิ่งที่ TOMAS TECH ช่วยได้

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

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

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

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

RAG คืออะไร เหมาะกับคำถามแบบไหน

RAG ย่อมาจาก Retrieval-Augmented Generation คือกลไกที่ก่อนจะให้ Generative AI ตอบ ระบบจะค้นหาและดึงส่วนที่เกี่ยวข้องจากเอกสารภายในองค์กรออกมาก่อน แล้วส่งให้เป็นหลักฐานประกอบ จากนั้นจึงให้สร้างคำตอบ สิ่งที่เหมาะกับมันคือคำถามที่คำตอบถูกเขียนเป็นข้อความอยู่ในเอกสารสักฉบับภายในองค์กรอยู่แล้ว เช่น การตีความระเบียบ การยืนยันขั้นตอน และการค้นหางานที่คล้ายกันในอดีต ในทางกลับกัน มันไม่ถนัดคำถามที่คำตอบมีอยู่ในรูปตัวเลขของระบบหลัก คำถามที่ต้องรวบยอดหรือเปรียบเทียบข้ามหลายเอกสาร และความรู้ฝังลึกที่ไม่เคยถูกทำเป็นเอกสารตั้งแต่แรก ถ้าไม่ทำให้เส้นแบ่งนี้เข้าใจตรงกันภายในองค์กรก่อนเข้าสู่ PoC ก็จะถูกทดลองแต่ด้วยคำถามที่ระบบไม่ถนัด แล้วมีแต่คะแนนประเมินที่ตกลง

ค่าใช้จ่ายในการนำ RAG มาใช้ประมาณเท่าไร

ในคู่มือราคาของ GXO ที่แบ่งตามเฟส ณ ปี 2026 ระดับราคาคือ PoC อยู่ที่ 1,000,000 ถึง 3,000,000 เยน และการสร้างระบบสำหรับใช้งานจริงอยู่ที่ 3,000,000 ถึง 10,000,000 เยน ส่วนค่าดูแลระบบรายเดือนมีช่วงต่างกันไปตามผู้เปิดเผย โดย GXO อยู่ที่ 100,000 ถึง 500,000 เยน และ Root Team อยู่ที่ 200,000 ถึง 800,000 เยน เมื่อแบ่งตามขนาด PoC ขนาดเล็กที่เจาะเฉพาะ 1 ถึง 2 งานอยู่ที่ 500,000 ถึง 2,000,000 เยน การใช้งานจริงแบบเบาที่ครอบคลุม 1 ถึง 2 แผนกและรวมการจัดการสิทธิ์อยู่ที่ 3,000,000 ถึง 5,000,000 เยน และการใช้งานจริงเต็มรูปแบบที่ใช้ทั้งบริษัทและเชื่อมต่อหลายระบบอยู่ที่ 5,000,000 ถึง 15,000,000 เยนขึ้นไป ในตัวอย่างรายการย่อยของ PoC ที่เปิดเผยไว้ ค่าใช้บริการ API ของ LLM อยู่ที่เพียง 2% ของค่าใช้จ่ายทั้งหมด ขณะที่รายการใหญ่ที่สุดคือการจัดเตรียมข้อมูลที่ 40% การรู้ว่าโครงสร้างค่าใช้จ่ายส่วนใหญ่ไม่ได้ไปที่โมเดลแต่ไปที่ข้อมูลกับหน้าจอแบบนี้ จะทำให้ตัดสินความสมเหตุสมผลของใบเสนอราคาได้ง่ายขึ้น อนึ่ง ตัวเลขเหล่านี้เป็นระดับราคาของตลาดในประเทศญี่ปุ่น รายละเอียดจำนวนเงินของแต่ละขั้นสรุปไว้ในบทความที่เกี่ยวข้องเรื่องค่าใช้จ่ายและแนวทางการสร้าง RAG

ถ้าไม่อยากให้จบแค่ PoC ต้องตรวจสอบอะไรบ้าง

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

ถ้าใช้ข้อมูลภายในองค์กรกับ Generative AI ข้อมูลจะรั่วไหลหรือไม่

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

สรุป

สำหรับบริษัทที่กำลังพิจารณาการนำ RAG มาใช้ การตัดสินใจไม่ได้ถูกกำหนดด้วยว่าเทคโนโลยีดีหรือไม่ดี แต่ถูกกำหนดด้วยสถานะความพร้อมของข้อมูลและการดูแลระบบ Gartner ทำนายว่าโครงการ Generative AI อย่างน้อย 30% จะถูกล้มเลิกหลังขั้น PoC ภายในสิ้นปี 2025 และทำนายต่อไปว่าภายในปี 2026 โครงการ AI ที่ไม่ได้รับการรองรับด้วยข้อมูลที่อยู่ในสภาพพร้อมใช้กับ AI จะถูกละทิ้งไป 60% คำขยายที่จำกัดขอบเขตนี้สำคัญ เพราะมันไม่ได้บอกว่าโครงการที่จัดข้อมูลเรียบร้อยแล้วจะล้มเหลวด้วยความน่าจะเป็นเท่ากัน

ในผลวัดจริง 228 รายการที่ Canon IT Solutions เปิดเผย ในบรรดาสาเหตุของคำตอบที่แย่ สิ่งที่เกิดจากตัว Generative AI เองมีเพียง 12% ขณะที่เอกสารบกพร่องหรือมีไม่พอคิดเป็น 46% และความแม่นยำของการค้นหาที่ต่ำคิดเป็น 42% สิ่งที่ต้องดูในการตัดสินใจลงทุนจึงไม่ใช่ว่าจะใช้โมเดลไหน แต่คือเอกสารของบริษัทเราเรียบร้อยแค่ไหน

ด้านค่าใช้จ่าย ระดับที่คู่มือราคาของแต่ละเจ้าให้ไว้คือ PoC อยู่ที่ 1,000,000 ถึง 3,000,000 เยน และการสร้างระบบสำหรับใช้งานจริงอยู่ที่ 3,000,000 ถึง 10,000,000 เยน ส่วนค่าดูแลระบบรายเดือนมีช่วงกว้างตามผู้เปิดเผยคือ 100,000 ถึง 800,000 เยน แต่สิ่งที่สำคัญกว่ายอดรวมคือรายการย่อย ในตัวอย่างรายการย่อยของ PoC ที่เปิดเผยไว้ 58% ของค่าใช้จ่ายถูกใช้ไปกับการจัดเตรียมข้อมูลและการประเมินความแม่นยำ ส่วนค่าใช้บริการ API ของ LLM เป็นเพียง 2% เท่านั้น และการคืนทุนจะได้หรือไม่นั้นถูกกำหนดด้วยปริมาณงาน บนสมมติฐาน 20 นาทีต่อเรื่อง ค่าแรง 3,000 เยนต่อชั่วโมง และอัตราการลด 30% เมื่อวางขนาดของการใช้ทั้งบริษัทไว้ที่เงินลงทุนเริ่มต้น 10,000,000 เยนและค่าดูแลระบบรายปี 4,800,000 เยน ถ้าไม่เกินราว 1,330 เรื่องต่อเดือนก็ไม่สามารถครอบคลุมแม้แต่ค่าดูแลระบบรายปีได้ และถ้าจะคืนทุนเงินลงทุนเริ่มต้นภายใน 3 ปีด้วยก็ต้องมีราว 2,260 เรื่องต่อเดือน การแทนค่าการคำนวณชุดนี้ด้วยตัวเลขของบริษัทเราเอง คือการบ้านชิ้นแรกก่อนจะเขียนเอกสารขออนุมัติงบประมาณ

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

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

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

ข้อมูลอ้างอิง

• GXO — ราคากลางและรายการย่อยของค่าใช้จ่ายในการนำ RAG มาใช้ ทั้งช่วงราคาของ PoC การสร้างระบบใช้งานจริง และการดูแลระบบรายเดือน พร้อมตัวอย่างรายการย่อยของ PoC ที่สมมติองค์กรขนาดพนักงาน 300 คน
• Root Team — ราคากลางของการพัฒนา RAG และประเด็นของการจ้างภายนอก ค่าใช้จ่ายแยกตามขนาดตั้งแต่ PoC ขนาดเล็กถึงการใช้งานจริงเต็มรูปแบบ และค่าบำรุงรักษาดูแลระบบ
• Gartner — คำทำนายว่าโครงการ Generative AI อย่างน้อย 30% จะถูกล้มเลิกหลังขั้น PoC ภายในสิ้นปี 2025 ประกาศวันที่ 29 กรกฎาคม 2024
• Gartner — คำทำนายว่าโครงการ AI ที่ไม่ได้รับการรองรับด้วยข้อมูลที่พร้อมใช้กับ AI จะถูกละทิ้ง 60% ภายในปี 2026 และผลสำรวจผู้รับผิดชอบ 248 คนที่พบ 63% ประกาศวันที่ 26 กุมภาพันธ์ 2025
• Canon IT Solutions — ผลการประเมินการทดลองใช้งาน RAG ภายในองค์กรจำนวน 228 รายการ สัดส่วนสาเหตุของการประเมินว่า Bad คือเอกสารบกพร่องหรือมีไม่พอ 46% ความแม่นยำของการค้นหาต่ำ 42% และ Generative AI 12%
• AQUA LLC — การสรุปสาเหตุที่การนำ RAG มาใช้ล้มเหลว การเตรียมข้อมูลใช้ปริมาณงาน 40% ถึง 60% ของทั้งโครงการ และค่าดูแลระบบรายปีอยู่ที่ 15% ถึง 25% ของค่าพัฒนาเริ่มต้น