การสร้างระบบ RAG ในโรงงานไทย ค่าใช้จ่าย 5 ชั้นและการค้นข้ามภาษา

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

องค์กรไทยอยู่ตรงไหนบนเส้นทาง AI ตัวเลขล่าสุดที่ควรรู้ก่อนตั้งงบ

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

ผลสำรวจ Thailand Digital Outlook 2026 ซึ่งเก็บข้อมูลจากผู้ประกอบการทั่วประเทศ 834 ราย พบว่าระดับความสมบูรณ์ทางดิจิทัลเฉลี่ยของผู้ประกอบการไทยอยู่ที่ 2.12 จากคะแนนเต็ม 4 และเป็นครั้งแรกที่ขึ้นมาอยู่ในระดับกลาง จากเดิม 1.56 ในปี พ.ศ. 2568 (ค.ศ. 2025) คิดเป็นการเพิ่มขึ้น 0.56 คะแนน หรือเติบโตราว 36% (ข้อมูลของประเทศไทย)

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

ตัวเลขที่ตรงกับหัวข้อของบทความนี้มากที่สุดคือสองตัวถัดไป

• องค์กรไทยที่นำ AI เข้าไปฝังอยู่ในกระบวนการทำงานจริงมีอยู่ราว 18% เท่านั้น (อ้างอิงผลสำรวจของ ETDA, ข้อมูลของประเทศไทย) พลิกกลับด้านคือมากกว่า 80% ยังไม่ได้ฝัง AI เข้าไปในงานประจำ
• องค์กรในภาคการผลิตราว 65% ระบุว่า “ความกังวลเรื่องคุณภาพข้อมูล” เป็นอุปสรรคสำคัญของการนำ AI มาใช้ (ข้อมูลของประเทศไทย)

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

เทียบระดับภูมิภาค เวียดนามนำเรื่องความสนใจ แต่ก็ติดที่ PoC เหมือนกัน

เพื่อให้เห็นภาพว่าปัญหานี้ไม่ได้เกิดเฉพาะในประเทศไทย ผลสำรวจของ Deloitte พบว่าองค์กรในประเทศเวียดนาม 93% นำ AI มาใช้แล้วหรืออยู่ระหว่างพิจารณา ซึ่งเป็นสัดส่วนสูงที่สุดในเอเชียตะวันออกเฉียงใต้ แต่กลุ่มที่ขยายผลได้ทั้งองค์กรมีเพียง 13.8% (ข้อมูลของประเทศเวียดนาม)

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

PDPA คือฐานทางกฎหมาย ส่วนกฎหมาย AI ของไทยยังไม่ได้ประกาศใช้

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

ณ ปี พ.ศ. 2569 (ค.ศ. 2026) ประเทศไทย ยังไม่ได้ประกาศใช้กฎหมาย AI ฉบับเดี่ยว ETDA อยู่ระหว่างรวมร่างกฎหมายที่เคยเสนอไว้ให้เป็นกรอบกำกับดูแล AI ฉบับเดียวที่ใช้แนวทางแบ่งตามระดับความเสี่ยง โดยคาดว่าจะมีการจัดประเภทความเสี่ยงที่ห้ามดำเนินการและความเสี่ยงสูง การกำหนดให้ต้องประเมินผลกระทบ และการกำกับการตัดสินใจอัตโนมัติที่เข้มขึ้น

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

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

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

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

เอกสารที่ควรกันออกจากคลังความรู้ตั้งแต่แรก

ในทางปฏิบัติ ให้ตั้งเป็นค่าเริ่มต้นว่าเอกสารกลุ่มนี้ไม่เข้าระบบ RAG

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

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

ที่จัดเก็บข้อมูล ต้องดูให้ครบทั้ง 4 ประเภท ไม่ใช่แค่ที่ตั้งของ LLM

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

1. ไฟล์เอกสารต้นฉบับ
2. ข้อความที่สกัดออกมาจากเอกสาร
3. เวกเตอร์ความหมายหรือ embedding
4. บันทึกคำถามและคำตอบของผู้ใช้

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

กฎหมาย AI ของเวียดนามบังคับใช้แล้วตั้งแต่เดือนมีนาคม พ.ศ. 2569 (ค.ศ. 2026)

สำหรับบริษัทที่มีโรงงานทั้งในไทยและเวียดนาม ต้องระวังว่าสถานะทางกฎหมายของสองประเทศต่างกัน รัฐสภาเวียดนามผ่านกฎหมาย AI ฉบับเดี่ยวฉบับแรกของเอเชียตะวันออกเฉียงใต้เมื่อเดือนธันวาคม พ.ศ. 2568 (ค.ศ. 2025) และมีผลบังคับใช้ในเดือนมีนาคม พ.ศ. 2569 (ค.ศ. 2026) โดยกำหนดการจัดประเภทความเสี่ยง ความรับผิดชอบในการอธิบายได้ และหน้าที่ด้านธรรมาภิบาลสำหรับระบบ AI ที่มีผลกระทบสูง (ข้อมูลของประเทศเวียดนาม)

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

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

ความจริงของหน้างานโรงงานในไทย เอกสารกับผู้ใช้อยู่คนละภาษา

หัวข้อนี้คือจุดที่บทความ RAG ทั่วไปแทบไม่พูดถึง แต่เป็นเงื่อนไขตั้งต้นของโรงงานในประเทศไทย

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

ภาษาไทยไม่มีช่องว่างระหว่างคำ การค้นหาแบบจับคู่คำจึงไม่ทำงานเอง

ปัญหาทางเทคนิคที่ถูกมองข้ามบ่อยที่สุดคือระบบการเขียนของภาษาไทย ภาษาไทยเขียนติดกันโดยไม่มีช่องว่างระหว่างคำ เมื่อระบบค้นหาต้องการจับคู่คำสำคัญ จึงต้องมีขั้นตอนคาดเดาขอบเขตของคำก่อน ซึ่งเรียกว่าการตัดคำหรือ word segmentation

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

รหัสรุ่นเครื่องจักรและอักษรย่อ ห้ามให้ระบบแปล

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

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

เอกสารส่วนใหญ่ยังไม่อยู่ในรูปที่ค้นหาได้

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

RAG เป็นกลไกที่ค้นหาจากตัวอักษร ไฟล์ PDF ที่เป็นภาพจึงไม่ถูกนับเป็นเป้าหมายการค้นหาเลย จุดนี้คือที่มาของค่าใช้จ่ายชั้นที่ 1 ซึ่งจะอธิบายต่อไป

ก่อนลงมือ ตรวจก่อนว่าเลี่ยงการสร้างระบบ RAG ได้หรือไม่

ตอนนี้ขอเข้าเรื่องที่บทความส่วนใหญ่ไม่เขียน RAG เป็นกลไกที่ถ้าเลี่ยงการสร้างได้ ก็ควรเลี่ยง

Anthropic ซึ่งเป็นผู้พัฒนา LLM ได้ระบุเกณฑ์ไว้ชัดเจนในเอกสารเทคนิคของตน (ข้อมูลระดับ global) ว่าถ้าคลังความรู้มีขนาดเล็กกว่า 200,000 โทเคน หรือประมาณ 500 หน้าเอกสาร ก็ไม่จำเป็นต้องสร้างระบบค้นคืน ให้ใส่คลังความรู้ทั้งก้อนลงไปในพรอมต์ได้เลย และเมื่อใช้ร่วมกับการแคชพรอมต์ วิธีนี้จะตอบเร็วกว่า ถูกกว่า และไม่ต้องพัฒนาระบบค้นคืนที่ซับซ้อน

ลองคิดเป็นตัวเลข 200,000 โทเคนหารด้วย 500 หน้า เท่ากับประมาณ 400 โทเคนต่อหน้า ให้นึกถึงคู่มือที่มีอยู่ในมือ คู่มือการใช้งานเครื่องจักรขนาด A4 หนา 50 หน้า จำนวน 10 เล่ม จึงจะแตะระดับนี้ พูดอีกอย่างคือ ถ้าโจทย์ยังอยู่แค่ “อยากค้นมาตรฐานการทำงาน 10 ฉบับ” หรือ “มีไฟล์ PDF ระเบียบคุณภาพอยู่ 30 ไฟล์” การทดลองด้วยวิธีส่งเอกสารทั้งชุดให้ LLM อ่านตรง ๆ สมเหตุสมผลกว่าการลงทุนก้อนใหญ่กับการสร้างระบบ RAG

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

เงื่อนไข 3 ข้อที่ทำให้จำเป็นต้องสร้างระบบ RAG

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

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

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

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

RAG คืออะไร เข้าใจได้ใน 3 ขั้น ค้นคืน เติมบริบท สร้างคำตอบ

RAG ย่อมาจาก Retrieval-Augmented Generation หมายถึงการสร้างคำตอบโดยเสริมด้วยการค้นคืนเอกสาร กลไกมีเพียง 3 ขั้น

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

ขั้นที่ 2 การเติมบริบท ระบบส่งชิ้นส่วนที่ดึงมาไปพร้อมกับคำถามให้ LLM ในรูปแบบที่บอกว่า ให้อ้างอิงเอกสารต่อไปนี้เพื่อตอบคำถามนี้

ขั้นที่ 3 การสร้างคำตอบ LLM เรียบเรียงคำตอบภายในขอบเขตของเอกสารที่ได้รับ พร้อมระบุว่าใช้ส่วนใดของเอกสารฉบับใดเป็นหลักฐาน

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

ตกลงคำศัพท์ให้ตรงกันก่อน

บทความนี้ใช้คำสามคำที่มักถูกใช้ปนกัน จึงขอกำหนดความหมายไว้ให้ชัด

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

ต่างจากการปรับจูนโมเดลอย่างไร

เมื่อได้ยินคำว่า “ให้ LLM เรียนรู้ข้อมูลของบริษัท” หลายคนนึกถึงการปรับจูนโมเดลหรือ fine-tuning เปรียบเทียบสามวิธีได้ตามนี้

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

งานในโรงงานที่ RAG ได้ผล และงานที่ RAG ไม่ได้ผล

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

งานที่ได้ผล คือขอบเขตที่คำตอบเขียนอยู่ในเอกสาร

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

งานที่ไม่ได้ผล คือขอบเขตของตัวเลขและสถานะปัจจุบัน

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

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

ค่าใช้จ่ายระบบ RAG ให้ประเมินโดยแบ่งเป็น 5 ชั้น

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

ทำไมชั้นที่ 1 จึงแพงที่สุดในโรงงาน

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

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

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

ราคาตลาดในประเทศญี่ปุ่น PoC 1 ถึง 3 ล้านเยน และระบบใช้งานจริง 3 ถึง 10 ล้านเยน

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

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

คิดให้ดู ผลรวมของ PoC ขอบล่างคือ 300,000 บวก 100,000 บวก 200,000 เท่ากับ 600,000 เยน ขอบบนคือ 500,000 บวก 100,000 บวก 500,000 เท่ากับ 1.1 ล้านเยน ส่วนระบบใช้งานจริง ขอบล่างคือ 1 ล้าน บวก 600,000 บวก 500,000 เท่ากับ 2.1 ล้านเยน ขอบบนคือ 1.5 ล้าน บวก 600,000 บวก 2 ล้าน เท่ากับ 4.1 ล้านเยน

เมื่อนำไปเทียบกับยอดรวมคือ PoC 1 ถึง 3 ล้านเยน และระบบใช้งานจริง 3 ถึง 10 ล้านเยน จะได้ส่วนต่างของ PoC เท่ากับ 400,000 ถึง 1.9 ล้านเยน และของระบบใช้งานจริงเท่ากับ 900,000 ถึง 5.9 ล้านเยน ทั้งนี้เป็นการเทียบขอบล่างกับขอบล่าง และขอบบนกับขอบบน ไม่ใช่ช่วงที่เป็นไปได้ทั้งหมดทางคณิตศาสตร์ จึงควรใช้เพื่อดูโครงสร้าง ไม่ใช่เพื่ออ้างเป็นตัวเลขเป๊ะ ๆ

ส่วนต่างก้อนนี้คืออะไร คำตอบคืองานกำหนดความต้องการ งานบริหารโครงการ และ ชั้นที่ 4 คือการเชื่อมต่อระบบเดิมกับการออกแบบสิทธิ์การเข้าถึง ในกรณีระบบใช้งานจริง หากดูที่ขอบบน ส่วนนี้คิดเป็น 5.9 จาก 10 ล้านเยน หรือ 59% ซึ่งเกินครึ่งของยอดรวม ขอให้จำโครงสร้างนี้ไว้ว่า ฐานข้อมูลเวกเตอร์อยู่ที่ 600,000 เยน แต่การออกแบบสิทธิ์และการเชื่อมต่อแพงกว่านั้นหลายเท่า

ราคาตลาดระดับสากล การพัฒนา RAG อยู่ที่ 15,000 ถึง 150,000 ดอลลาร์สหรัฐ (global)

ดูราคาตลาดของการพัฒนา RAG ในระดับสากลประกอบด้วย ตัวเลขต่อไปนี้เป็นระดับ global และเป็นสกุลดอลลาร์สหรัฐ ไม่ได้แปลงเป็นสกุลอื่นเพราะแหล่งอ้างอิงไม่ได้ระบุอัตราแลกเปลี่ยน

ลองหารทั้งสองขอบ RAG สำหรับใช้งานจริงแพงกว่า RAG แบบเรียบง่ายประมาณ 2.7 ถึง 3.2 เท่า โดยขอบล่างหารกัน 40,000 หารด้วย 15,000 เท่ากับประมาณ 2.7 เท่า และขอบบนหารกัน 80,000 หารด้วย 25,000 เท่ากับ 3.2 เท่า ส่วน RAG ระดับองค์กรแบบติดตั้งภายใน แพงกว่า RAG สำหรับใช้งานจริงอีกประมาณ 1.9 ถึง 2.0 เท่า โดยขอบล่างหารกัน 80,000 หารด้วย 40,000 เท่ากับ 2.0 เท่า และขอบบนหารกัน 150,000 หารด้วย 80,000 เท่ากับประมาณ 1.9 เท่า ทั้งนี้ช่วงสุดท้ายระบุว่า “ขึ้นไป” ตัวคูณจริงจึงอาจสูงกว่านี้

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

ในเอกสารขออนุมัติ ให้เขียนชั้นที่ 1 ถึง 4 เป็นเงินลงทุน และชั้นที่ 5 เป็นค่าดำเนินงานรายปี

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

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

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

ลองตรวจด้วยตัวอย่างที่เผยแพร่ในประเทศญี่ปุ่น (ข้อมูลของประเทศญี่ปุ่น) กรณีบริษัทที่มีพนักงาน 300 คนทำระบบตอบคำถามที่พบบ่อยของฝ่ายระบบสารสนเทศ PoC อยู่ที่ 1 ล้านเยน ใช้เวลา 2 สัปดาห์ ระบบใช้งานจริงอยู่ที่ 6 ล้านเยน ใช้เวลา 3 เดือน และค่าดำเนินงานรายเดือนประมาณ 200,000 เยน เมื่อใส่ลงในนิยามข้างต้นจะได้

• เงินลงทุน ชั้นที่ 1 ถึง 4 เท่ากับ PoC 1 ล้านเยน บวกระบบใช้งานจริง 6 ล้านเยน เท่ากับ 7 ล้านเยน
• ค่าดำเนินงานรายปี ชั้นที่ 5 เท่ากับ 200,000 เยน คูณ 12 เดือน เท่ากับ 2.4 ล้านเยน
• ต้นทุนรวมตลอด 3 ปี เท่ากับ 7 ล้าน บวก 2.4 ล้าน คูณ 3 ปี เท่ากับ 14.2 ล้านเยน
• ต้นทุนรวมตลอด 5 ปี เท่ากับ 7 ล้าน บวก 2.4 ล้าน คูณ 5 ปี เท่ากับ 19 ล้านเยน

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

สมมติวางผลประหยัดต่อปีไว้ที่ 4.8 ล้านเยน จะได้ 7 หารด้วย 4.8 ลบ 2.4 เท่ากับประมาณ 2.9 ปี แต่ตัวเลข 4.8 ล้านเยนนี้ไม่ใช่ตัวเลขที่มีแหล่งอ้างอิง เป็นเพียงค่าสมมติเพื่อแสดงรูปของสูตร เวลาเขียนขออนุมัติจริง ให้วัดเวลาที่ใช้ค้นหาข้อมูลในงานเป้าหมายด้วยตนเอง แล้วเติมช่องนี้ด้วยตัวเลขของบริษัทท่านเอง ผลประหยัดที่ไม่ได้มาจากการวัดจริงจะถูกตีตกในชั้นทบทวน

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

ความแม่นยำไม่ถึงเป้า ต้นเหตุอยู่ที่ชั้นค้นคืน ไม่ใช่ชั้นสร้างคำตอบ

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

สามขั้นของการปรับปรุง Contextual Retrieval, BM25 และการจัดอันดับใหม่

Anthropic เผยแพร่ผลวัดจริงของการปรับปรุงฝั่งค้นคืนไว้ (ข้อมูลระดับ global) ทุกตัวเลขใช้ ค่าฐานคือ RAG แบบดั้งเดิมที่ใช้ embedding อย่างเดียว และเปรียบเทียบอัตราการค้นคืนล้มเหลวเมื่อดึงชิ้นส่วนข้อความ 20 อันดับแรก

ตรวจการคำนวณกันอีกรอบ จาก 5.7% เหลือ 3.7% คือ 1 ลบ 3.7 หารด้วย 5.7 เท่ากับลดลงประมาณ 35% เหลือ 2.9% คือ 1 ลบ 2.9 หารด้วย 5.7 เท่ากับลดลงประมาณ 49% และเหลือ 1.9% คือ 1 ลบ 1.9 หารด้วย 5.7 เท่ากับลดลงประมาณ 67%

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

แปลสามวิธีนี้เป็นภาษาของหน้างานได้ดังนี้

• Contextual Embeddings คือการเติมคำอธิบายสั้น ๆ ให้แต่ละชิ้นส่วนข้อความว่าเป็นส่วนไหนของเอกสารใด ก่อนจะแปลงเป็นเวกเตอร์ ลำพังข้อความว่า “ปรับความดันเป็น 0.3 MPa” ไม่รู้ว่าเป็นเครื่องอะไร แต่ถ้าเติมบริบทว่าเป็นหัวข้อการปรับความดันในขั้นตอนตรวจประจำวันของเครื่องบรรจุ B ก็จะค้นเจอ
• การใช้ BM25 ร่วมด้วย คือการผสมการค้นหาแบบจับคู่คำเข้ากับการค้นหาด้วยความใกล้เคียงของความหมาย ได้ผลกับคำอย่างรหัสรุ่นและรหัสชิ้นงาน ที่ค้นด้วยความหมายไม่ได้แต่ตรงกันในระดับตัวอักษร ในเอกสารโรงงานเรื่องนี้สำคัญมาก
• การจัดอันดับใหม่ คือขั้นตอนที่ดึงชิ้นส่วนข้อความที่เข้าข่ายมาเผื่อไว้จำนวนมากก่อน แล้วใช้อีกโมเดลหนึ่งเรียงลำดับใหม่ตามความเกี่ยวข้องกับคำถาม

ตัวอย่างความผิดพลาดของการตัดชิ้นส่วนข้อความ

ข้อผิดพลาดของการตัด chunk ที่เกิดบ่อยกับเอกสารโรงงานมีดังนี้

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

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

ออกแบบให้ระบบพูดได้ว่า “ไม่พบข้อมูล”

เพื่อให้หน้างานไว้ใจ ให้ตัดสินใจสามข้อนี้ตั้งแต่ต้น

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

ออกแบบให้ถามเป็นภาษาไทยแล้วค้นคู่มือภาษาญี่ปุ่นได้

กลับมาที่โจทย์หลายภาษาที่ตั้งไว้ตอนต้น หัวข้อนี้คือส่วนออกแบบทางแก้

เปรียบเทียบ 3 แนวทาง ว่าจะแปลที่ชั้นไหน

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

สิ่งที่ต้องตรวจเพิ่มเมื่อระบบต้องรองรับหลายภาษา

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

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

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

คำตอบให้ใช้ภาษาของผู้ถาม ส่วนหลักฐานให้ลิงก์เป็นภาษาต้นฉบับ

รูปแบบการใช้งานที่แนะนำสำหรับแชทบอทหลายภาษาคือแบบนี้

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

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

6 รูปแบบที่ทำให้การสร้างระบบ RAG ล้มเหลว

สรุปเนื้อหาทั้งหมดเป็นรูปแบบความล้มเหลว 6 ข้อ

1. โยนเอกสารเข้าไปทั้งหมดโดยไม่จัดระเบียบก่อน ฉบับเก่ากับฉบับปัจจุบันปนกัน ระบบตอบด้วยขั้นตอนเก่า แล้วเสียความไว้วางใจ ทางแก้คือนับสต๊อกเอกสารเป้าหมายและกำหนดการจัดการเวอร์ชัน โดยลงเป็นชั่วโมงงานของชั้นที่ 1
2. เลื่อนการออกแบบสิทธิ์การเข้าถึงไปทีหลัง ตอน PoC ตั้งค่าให้ทุกคนเห็นทุกเอกสาร พอจะขึ้นระบบจริงถึงค่อยใส่สิทธิ์ กลายเป็นต้องทำใหม่ ดังที่เห็นจากรายละเอียดค่าใช้จ่าย การออกแบบสิทธิ์เป็นหนึ่งในชั้นที่หนักที่สุด ให้รวมไว้ในการออกแบบตั้งแต่แรก
3. ไม่มีเกณฑ์ตัดสินผลของ PoC ถ้าใช้ความรู้สึกหลังลองใช้เป็นเกณฑ์ ความเห็นจะแตกและสรุปไม่ได้ แก้ด้วยการทำชุดข้อมูลประเมินไว้ก่อน ตามที่จะอธิบายต่อไป
4. ไม่ได้กำหนดผู้รับผิดชอบการอัปเดตเอกสาร ครบครึ่งปีหลังขึ้นระบบ เอกสารเริ่มเก่า ไม่มีใครแก้ คุณภาพคำตอบจึงตกลง ให้ระบุชั่วโมงงานอัปเดตเอกสารไว้ในชั้นที่ 5 และกำหนดหน่วยงานผู้รับผิดชอบก่อนขึ้นระบบ
5. หยุดพิจารณาทั้งโครงการเพราะ AI ตอบผิดครั้งเดียว RAG ไม่ใช่กลไกที่ตอบถูก 100% สิ่งสำคัญคือเมื่อเกิดข้อผิดพลาด มีทีมที่แยกได้หรือไม่ว่าเป็นปัญหาฝั่งค้นคืนหรือฝั่งสร้างคำตอบ และแก้การตัดชิ้นส่วนหรือวิธีค้นคืนได้หรือไม่ ให้กำหนดตั้งแต่ต้นว่าจะบันทึกคำตอบที่ผิดไว้แล้วนำเข้าสู่วงจรปรับปรุง ไม่ใช่หยุดทั้งระบบเพราะตอบผิดหนึ่งครั้ง
6. เส้นแบ่งระหว่างทำเองกับจ้างภายนอกไม่ชัด ทั้งการยกให้ภายนอกทำทั้งหมดและการทำเองทั้งหมด ล้วนไปไม่รอด หัวข้อถัดไปจะขีดเส้นให้

เส้นแบ่งงานที่ทำเองกับงานที่จ้างภายนอก และ 8 คำถามที่ควรถามผู้ให้บริการ

งานที่มีแต่บริษัทท่านเท่านั้นที่ทำได้

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

งานที่เหมาะกับการจ้างภายนอก

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

สำหรับการคัดเลือกผู้ให้บริการในประเทศไทย อ่านประกอบได้ที่วิธีเลือกบริษัทพัฒนาระบบในประเทศไทย

8 คำถามที่ควรถามผู้ให้บริการ

รายการที่ควรตรวจสอบตอนรับข้อเสนอ

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

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

เดินหน้าการสร้างระบบ RAG ด้วย 4 ขั้นตอน

วิธีดำเนินการสรุปได้เป็น 4 ขั้นตอน

ขั้นตอนที่ 1 จำกัดงานเป้าหมายให้เหลืองานเดียว

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

ขั้นตอนที่ 2 ทำชุดข้อมูลประเมิน 30 ข้อไว้ก่อน

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

ใน 30 ข้อ ให้ผสมคำถามประเภทต่อไปนี้

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

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

ขั้นตอนที่ 3 ตัดสินผลด้วย PoC

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

ระยะเวลาโดยประมาณตามราคาตลาดในประเทศญี่ปุ่นอยู่ที่ 2 ถึง 6 สัปดาห์ (ข้อมูลของประเทศญี่ปุ่น)

ขั้นตอนที่ 4 สร้างระบบใช้งานจริงและเริ่มดำเนินงาน

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

ระยะเวลาโดยประมาณตามราคาตลาดในประเทศญี่ปุ่นอยู่ที่ 2 ถึง 4 เดือน (ข้อมูลของประเทศญี่ปุ่น)

คำถามที่พบบ่อยเกี่ยวกับการสร้างระบบ RAG

RAG คืออะไร

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

ค่าใช้จ่ายระบบ RAG อยู่ที่เท่าไร

ราคาตลาดในประเทศญี่ปุ่นระบุว่า PoC อยู่ที่ 1 ถึง 3 ล้านเยน การสร้างระบบใช้งานจริงอยู่ที่ 3 ถึง 10 ล้านเยน และค่าดำเนินงานรายเดือนอยู่ที่ 100,000 ถึง 500,000 เยน (ข้อมูลของประเทศญี่ปุ่น) ส่วนราคาตลาดระดับ global ระบุว่า RAG แบบเรียบง่ายอยู่ที่ 15,000 ถึง 25,000 ดอลลาร์สหรัฐ RAG สำหรับใช้งานจริงอยู่ที่ 40,000 ถึง 80,000 ดอลลาร์สหรัฐ และ RAG ระดับองค์กรแบบติดตั้งภายในอยู่ที่ 80,000 ถึง 150,000 ดอลลาร์สหรัฐขึ้นไป (global) อย่างไรก็ตาม ในกรณีของโรงงาน หากเอกสารยังเป็นกระดาษหรือภาพสแกน ค่าใช้จ่ายชั้นที่ 1 คือการแปลงเป็นดิจิทัลและการเตรียมข้อมูลจะสูงกว่ากรอบเหล่านี้ และในเอกสารขออนุมัติให้แยกเขียนชั้นที่ 1 ถึง 4 เป็นเงินลงทุน กับชั้นที่ 5 เป็นค่าดำเนินงานรายปี

ควรเลือก RAG หรือการปรับจูนโมเดล

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

ถ้าคู่มือของบริษัทมีแต่กระดาษ ยังสร้าง RAG ได้หรือไม่

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

ถามเป็นภาษาไทยแล้วค้นคู่มือภาษาญี่ปุ่นได้หรือไม่

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

การสร้างระบบ RAG ใช้เวลานานเท่าใด

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

สรุปสาระสำคัญของการสร้างระบบ RAG

สรุปตามค่าใช้จ่าย 5 ชั้น

• ชั้นที่ 1 การแปลงเอกสารเป็นดิจิทัลและการเตรียมข้อมูล เป็นชั้นที่หนักที่สุดในโรงงาน การจัดระเบียบกระดาษ PDF สแกน แบบงาน และ Excel รวมถึงการยืนยันเวอร์ชัน มีแต่บริษัทเองที่ทำได้ และก่อนลงมือ ถ้าเอกสารเป้าหมายเล็กกว่า 200,000 โทเคน หรือประมาณ 500 หน้า ให้พิจารณาทางเลือกที่ไม่สร้าง RAG แต่ใส่ลงพรอมต์แทน (global)
• ชั้นที่ 2 โครงสร้างพื้นฐานการค้นคืน ตามรายละเอียดของประเทศญี่ปุ่น ฐานข้อมูลเวกเตอร์อยู่ที่ระดับ 600,000 เยนสำหรับระบบใช้งานจริง (ข้อมูลของประเทศญี่ปุ่น) ถือเป็นชั้นที่เบากว่าชั้นอื่นโดยเปรียบเทียบ
• ชั้นที่ 3 แอปและหน้าจอใช้งาน ยิ่งฝังเข้าไปในเครื่องมือที่พนักงานใช้อยู่แล้ว ยิ่งอยู่ตัวเร็ว
• ชั้นที่ 4 การเชื่อมต่อระบบเดิมและการออกแบบสิทธิ์การเข้าถึง คือที่มาของส่วนต่างในรายละเอียดของประเทศญี่ปุ่น และเป็นปัจจัยต้นทุนหลักที่แหล่งอ้างอิงระดับ global ชี้ไว้ตรงกัน อีกทั้งเป็นชั้นที่ทำให้การขยายผลทั้งองค์กรหยุดชะงัก
• ชั้นที่ 5 การดำเนินงาน ได้แก่ค่าใช้งาน LLM การอัปเดตเอกสาร และแรงงานภายในเพื่อปรับปรุงคุณภาพ ในเอกสารขออนุมัติให้แยกออกจากเงินลงทุน แล้วลงเป็นค่าดำเนินงานรายปี

เรื่องคุณภาพ สมรภูมิหลักอยู่ที่ฝั่งค้นคืน เมื่อซ้อน Contextual Embeddings การใช้ BM25 ร่วม และการจัดอันดับใหม่ตามลำดับ มีผลวัดจริงว่าอัตราการค้นคืนล้มเหลวลดจาก 5.7% เหลือ 1.9% หรือลดลง 67% โดยใช้ค่าฐานเป็น RAG ที่ใช้ embedding อย่างเดียว (global) ย้ำอีกครั้งว่านี่คือการลดลงของอัตราล้มเหลว ไม่ใช่ความแม่นยำของคำตอบที่เพิ่มขึ้น 67%

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

ด้านกฎหมาย ประเทศไทยมี PDPA เป็นฐาน ส่วนกฎหมาย AI ยังอยู่ในขั้นร่างและยังไม่ได้ประกาศใช้ (ข้อมูลของประเทศไทย) ขณะที่ประเทศเวียดนามมีกฎหมาย AI บังคับใช้แล้วตั้งแต่เดือนมีนาคม พ.ศ. 2569 (ค.ศ. 2026) (ข้อมูลของประเทศเวียดนาม) สถานะจึงต่างกัน รายละเอียดให้สอบถามหน่วยงานกำกับดูแลหรือที่ปรึกษากฎหมายในพื้นที่เป็นลายลักษณ์อักษร และหากต้องประเมินผลกระทบทางภาษี ให้สอบถามที่ปรึกษาด้านภาษี

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

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

• Anthropic “Introducing Contextual Retrieval” https://www.anthropic.com/news/contextual-retrieval
• GXO “รายละเอียดค่าใช้จ่ายการสร้างระบบ RAG” ลงวันที่ 14 เมษายน พ.ศ. 2569 หรือ ค.ศ. 2026 https://gxo.co.jp/column/rag-implementation-cost-breakdown-2026
• AITIP “ขั้นตอนและราคาตลาดของการสร้างระบบ RAG” https://aitip.jp/rag-construction/
• ScalaCode “RAG Development Cost” https://www.scalacode.com/blog/rag-development-cost/
• Bangkok Post “AI adoption helps Thai firms become digitally mature” https://www.bangkokpost.com/business/general/3283789/ai-adoption-helps-thai-firms-become-digitally-mature
• Bangkok Post “Data quality concerns a barrier to adoption of AI” https://www.bangkokpost.com/business/general/3051260/data-quality-concerns-a-barrier-to-adoption-of-ai
• DataGuidance “Thailand: ETDA announces AI 2026 strategy to promote trust” https://www.dataguidance.com/news/thailand-etda-announces-ai-2026-strategy-promote-trust
• Vietnam Briefing “Vietnam’s AI Law: Regulatory Milestone and Business Implications” https://www.vietnam-briefing.com/news/vietnams-ai-law-regulatory-milestone-business-implications.html/