RAG คืออะไร: ทำ AI ค้นเอกสารภาษาไทยให้ตอบถูกและตรวจสอบได้

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

บทความนี้เขียนสำหรับ IT Manager ทีมพัฒนา และเจ้าของข้อมูลที่กำลังพิจารณาทำระบบถามตอบจากเอกสารภายใน เนื้อหาครอบคลุมว่า RAG ต่างจาก fine-tune และ AI Agent อย่างไร ทำไมภาษาไทยต้องออกแบบการค้นเป็นพิเศษ วัดความถูกต้องอย่างไร ต้องคุมสิทธิ์และคิดเรื่อง PDPA อย่างไร และควรติดตั้งภายในหรือใช้ cloud ข้อมูลผลิตภัณฑ์และเอกสารอ้างอิงตรวจ ณ วันที่ 1 พฤศจิกายน 2026

RAG คืออะไร ต่างจาก fine-tune อย่างไร?

RAG ส่งเนื้อหาที่ค้นได้เข้าไปพร้อมคำถามตอนตอบ ส่วน fine-tune ฝึกโมเดลต่อด้วยข้อมูลเฉพาะทาง RAG จึงแก้ปัญหา "โมเดลไม่รู้" ส่วน fine-tune แก้ปัญหา "โมเดลรู้แต่ทำไม่สม่ำเสมอ"

คำว่า RAG มาจากงานวิจัย Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks ของ Patrick Lewis และคณะ (ส่งขึ้น arXiv เมื่อ 22 พฤษภาคม 2020 และตีพิมพ์ใน NeurIPS 2020) งานนี้รวมความรู้ที่ฝังอยู่ในโมเดลภาษาเข้ากับการค้นจากดัชนี vector ของ Wikipedia เพราะโมเดลภาษาอย่างเดียวดึงความรู้มาใช้ได้ไม่แม่น บอกที่มาของคำตอบไม่ได้ และอัปเดตความรู้ยาก ในการทดลอง RAG ตอบได้เฉพาะเจาะจงและตรงข้อเท็จจริงกว่าโมเดลที่ใช้แต่ความรู้ในตัว

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

OpenAI อธิบาย fine-tune ว่าเป็นการฝึก LLM ต่อด้วยชุดข้อมูลเฉพาะทางที่เล็กกว่า เพื่อให้แม่นยำขึ้นกับงานเฉพาะ หรือเพื่อให้ใช้ token น้อยลงหรือใช้โมเดลที่เล็กลงได้ และระบุว่า RAG แก้ได้เฉพาะปัญหาเรื่องบริบท ถ้าปัญหาคือโมเดลต้องเรียนรู้วิธีทำงานให้สม่ำเสมอ ต้องใช้ fine-tune

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

RAG ต่างจาก AI Agent อย่างไร?

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

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

ระบบ RAG ทำงานอย่างไร?

ระบบ RAG มีสองช่วง ช่วงเตรียมข้อมูลทำครั้งแรกและทำซ้ำเมื่อเอกสารเปลี่ยน ช่วงตอบคำถามทำทุกครั้งที่ผู้ใช้ถาม

1. ดึงข้อความ: อ่านไฟล์จากแหล่งเก็บเอกสาร เช่น file share, intranet หรือฐานข้อมูล แปลง PDF และไฟล์ Office เป็นข้อความ ไฟล์สแกนต้องผ่าน OCR ก่อน และเก็บ metadata ที่ต้องใช้ภายหลัง ได้แก่ ชื่อเอกสาร ฉบับ วันที่ เจ้าของ และสิทธิ์
2. แบ่งเป็นช่วง (chunking): ตัดเอกสารเป็นช่วงที่สั้นพอจะส่งให้โมเดล แต่ยังมีบริบทครบ โดยพยายามตัดตามหัวข้อหรือข้อของเอกสาร ไม่ตัดกลางตาราง
3. ทำดัชนี: เก็บแต่ละช่วงทั้งในดัชนีคำ (หลังตัดคำภาษาไทย) และในรูป vector จาก embedding model
4. ค้นและกรองสิทธิ์: เมื่อมีคำถาม ค้นทั้งสองดัชนี กรองให้เหลือเฉพาะเอกสารที่ผู้ถามมีสิทธิ์เห็น แล้วรวมและจัดอันดับผลใหม่ (re-rank)
5. สร้างคำตอบ: ส่งคำถามพร้อมช่วงเอกสารที่ได้ให้ LLM โดยกำหนดให้ตอบจากเอกสารที่ให้เท่านั้น อ้างอิงแหล่งที่มา และตอบว่าไม่พบข้อมูลเมื่อเอกสารไม่มีคำตอบ
6. บันทึกและวัดผล: เก็บว่าคำถามใดได้เอกสารใดและตอบอะไร ตามนโยบายการเก็บ log เพื่อใช้ตรวจย้อนหลังและปรับปรุง

ทำไม RAG ภาษาไทยยากกว่า และ hybrid search ช่วยอย่างไร?

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

การตัดคำภาษาไทย

เอกสาร thai tokenizer ของ OpenSearch ระบุว่าเพราะภาษาไทยไม่เว้นวรรคระหว่างคำ tokenizer ต้องหาขอบเขตคำด้วยกฎเฉพาะของภาษา ตัวอย่างในเอกสารคือ "ฉันชอบไปเที่ยวที่เชียงใหม่" ซึ่งตัดเป็น ฉัน / ชอบ / ไป / เที่ยว / ที่ / เชียงใหม่ ตัวเลือกที่ใช้กันมีดังนี้

• thai tokenizer (Elasticsearch/OpenSearch): เอกสารของ Elastic ระบุว่าใช้อัลกอริทึมตัดคำไทยที่มากับ Java ปรับแต่งไม่ได้ และอาจไม่รองรับในทุก JRE ถ้าต้องการให้ย้ายระบบได้ง่าย Elastic แนะนำ ICU tokenizer แทน OpenSearch ยังมี thai analyzer สำเร็จรูปที่ประกอบด้วย thai tokenizer กับ filter lowercase, decimal_digit, stop (ภาษาไทย) และ keyword
• ICU tokenizer: plugin analysis-icu ตัดคำตามขอบเขตคำของ Unicode (UAX #29) และใช้วิธีอิงพจนานุกรมสำหรับภาษาไทย ลาว จีน ญี่ปุ่น และเกาหลี
• PyThaiNLP: ฟังก์ชัน word_tokenize ใช้ engine newmm เป็นค่าตั้งต้น ซึ่งเป็นวิธี maximum matching อิงพจนานุกรม และมี engine แบบเรียนรู้จากข้อมูล เช่น attacut และ deepcut เหมาะกับขั้นเตรียมข้อมูลด้วย Python เช่น ตัดคำก่อนทำ chunk หรือตรวจผลการตัดคำ

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

Hybrid search: BM25 คู่กับ vector

Hybrid search คือการค้นแบบ keyword กับแบบ semantic (vector) ในคำขอเดียว แล้วรวมผลเป็นอันดับเดียว Elastic อธิบายไว้แบบนี้และแนะนำให้รวมอันดับด้วย Reciprocal Rank Fusion (RRF) ส่วน OpenSearch รองรับ hybrid search ตั้งแต่รุ่น 2.11 (รวมผลใน search pipeline แบบ normalize คะแนน) และเพิ่มการรวมแบบ RRF ตั้งแต่รุ่น 2.19

• ฝั่ง keyword: BM25 เป็น similarity ตั้งต้นของ Elasticsearch เก่งกับคำที่ต้องตรงตัว เช่น เลขที่หนังสือ รหัสสินค้า ชื่อเฉพาะ และคำย่อ แต่ขึ้นกับคุณภาพการตัดคำ
• ฝั่ง vector: จับคำถามที่ใช้คำต่างจากเอกสารแต่ความหมายเดียวกันได้ แต่อาจให้ผลที่ "ความหมายใกล้" กับคำที่ต้องตรงตัว เช่น ได้ระเบียบฉบับใกล้เคียงแทนฉบับที่ถาม
• การรวม: RRF ให้คะแนนแต่ละเอกสารเป็นผลรวมของ 1/(k + อันดับ) จากผลค้นแต่ละชุด Elastic ระบุว่าไม่ต้องจูน และคะแนนของแต่ละวิธีไม่จำเป็นต้องเทียบกันได้

สองวิธีนี้พลาดคนละแบบ การรวมกันจึงช่วยลดช่องว่างของแต่ละฝั่ง หลังรวมแล้วอาจใช้ re-ranker จัดอันดับช่วงเอกสารอีกรอบก่อนส่งให้ LLM ผลจริงของแต่ละแบบต้องวัดกับชุดคำถามขององค์กรเอง ไม่ควรเชื่อตัวเลขจาก benchmark ภาษาอื่น

ใช้ระบบค้นหาองค์กรอย่าง Fess เป็นฐานของ RAG ได้ไหม?

ได้ และเป็นทางที่ช่วยลดงานหลายส่วน เพราะงานดึงข้อความ ทำดัชนี และกรองสิทธิ์เป็นงานเดียวกับที่ระบบค้นหาองค์กรต้องทำอยู่แล้ว Fess เป็นซอฟต์แวร์ open source ภายใต้ Apache License ติดตั้งบนเครื่องขององค์กรเอง และสร้างบน OpenSearch

• crawl ได้ทั้งเว็บไซต์ file system, Windows shared folder และฐานข้อมูล และดึงข้อความจาก HTML, PDF และไฟล์ Microsoft Office
• รองรับ Single Sign-On (Active Directory, SAML) และแสดงผลตามสิทธิ์ของผู้ใช้ มีพจนานุกรมผู้ใช้และพจนานุกรมคำพ้องให้แก้ไขได้
• mapping ตั้งต้นของ Fess กำหนด thai_analyzer ให้ฟิลด์ภาษาไทยใช้ thai tokenizer พร้อม filter thai_stop และ thai_keywords
• ตาม release notes รุ่น 15.8.0 เพิ่มขั้นตอน chunking และ embedding ที่ใช้เลือกบริบทให้ RAG chat และใช้เป็นฝั่ง semantic ของการค้นปกติ ส่วนรุ่น 15.9.0 (15 ตุลาคม 2026) เพิ่มการรวมอันดับฝั่ง engine ให้ RAG Chat จำกัดตัวเองตาม role และ label ที่ได้รับอนุญาต และเพิ่ม OCR สำหรับรูปภาพและ PDF สแกนตอน crawl

UNIXDEV ติดตั้ง Fess พร้อม backend OpenSearch ตั้งค่า crawler ปรับพจนานุกรมคำพ้อง ปรับ analyzer ภาษาไทยให้ตัดศัพท์เฉพาะขององค์กรได้ถูก (เช่น เปลี่ยนไปใช้ ICU tokenizer จาก plugin analysis-icu เมื่อ thai tokenizer ตั้งต้นตัดศัพท์เฉพาะไม่ถูก) และเชื่อมสิทธิ์กับ Active Directory/LDAP ส่วนจะใช้ RAG Chat ของ Fess เอง หรือใช้ Fess เป็นฝั่งค้นให้ระบบ RAG ที่พัฒนาแยก ขึ้นกับโจทย์และข้อกำหนดของแต่ละองค์กร ควรทดสอบกับเอกสารจริงก่อนตัดสินใจ

วัดความถูกต้องของ RAG อย่างไร?

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

ไลบรารีประเมินผล Ragas มีตัวชี้วัดที่แยกสองฝั่งนี้ชัดเจน

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

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

ฝั่ง prompt ใช้แนวทางจาก คู่มือลด hallucination ของ Anthropic ได้โดยตรง ได้แก่ อนุญาตให้โมเดลตอบว่า "ไม่ทราบ" ให้ยกประโยคจากเอกสารมาประกอบแต่ละประเด็นในคำตอบ และตัดประเด็นที่หาประโยคอ้างอิงไม่ได้ออก เมื่อเปลี่ยนโมเดล prompt วิธีตัดคำ หรือวิธีแบ่ง chunk ให้รันชุดทดสอบเดิมซ้ำก่อนปล่อยใช้งาน แนวทางนำระบบจากงานทดลองขึ้นใช้งานจริงอยู่ในบทความ นำ AI/LLM ไปใช้จริงในองค์กรไทย: จาก Pilot สู่ Production

สิทธิ์เข้าถึงเอกสารและ PDPA ต้องคิดอะไรบ้าง?

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

กรองสิทธิ์ที่ระดับเอกสาร

• OpenSearch: document-level security (DLS) กำหนดว่า role ใดดึงเอกสารใดได้ระหว่างการอ่าน เช่น search และ get แต่ไม่ได้จำกัดการเขียน
• Elasticsearch: document level security จำกัดเอกสารที่ผู้ใช้อ่านได้ ข้อที่ต้องระวังคือ role ที่ไม่ได้กำหนดสิทธิ์ระดับเอกสารจะเห็นเอกสารทั้งหมดใน index
• Fess: role-based search กรองผลตาม role, group หรือ user ที่กำหนดไว้ในการตั้งค่า crawl ผู้ใช้ที่ไม่มี role ที่กำหนดจะไม่เห็นเอกสารนั้นแม้ค้นด้วยคำเดียวกัน

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

PDPA กำหนดอะไรที่เกี่ยวกับ RAG

เอกสารภายในจำนวนมากมีข้อมูลส่วนบุคคลปนอยู่ เช่น แฟ้มบุคลากร คำร้อง หรือสัญญา ระบบ RAG ที่อ่านเอกสารเหล่านี้จึงอยู่ในขอบเขตของ พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (ราชกิจจานุเบกษา เล่ม 136 ตอนที่ 69 ก วันที่ 27 พฤษภาคม 2562) มาตราที่เกี่ยวข้องโดยตรงมีดังนี้

• มาตรา 6: นิยามข้อมูลส่วนบุคคลว่าเป็นข้อมูลเกี่ยวกับบุคคลที่ทำให้ระบุตัวบุคคลนั้นได้ ไม่ว่าทางตรงหรือทางอ้อม และแยกบทบาทผู้ควบคุมข้อมูลส่วนบุคคล (ผู้ตัดสินใจเรื่องการเก็บ ใช้ หรือเปิดเผย) ออกจากผู้ประมวลผลข้อมูลส่วนบุคคล (ผู้ดำเนินการตามคำสั่งหรือในนามของผู้ควบคุม)
• มาตรา 26: ข้อมูลอ่อนไหว เช่น ข้อมูลสุขภาพ ประวัติอาชญากรรม ความเชื่อทางศาสนา ข้อมูลชีวภาพ และข้อมูลพันธุกรรม ห้ามเก็บรวบรวมโดยไม่ได้รับความยินยอมโดยชัดแจ้ง เว้นแต่เข้าข้อยกเว้นที่กฎหมายกำหนด เอกสารกลุ่มนี้ควรแยกออกจากคลังที่ใช้ทำ RAG หรือคุมสิทธิ์เข้มกว่าปกติ
• มาตรา 28: การส่งหรือโอนข้อมูลส่วนบุคคลไปต่างประเทศ ประเทศปลายทางต้องมีมาตรฐานคุ้มครองข้อมูลที่เพียงพอตามหลักเกณฑ์ของคณะกรรมการ เว้นแต่เข้ากรณียกเว้น ข้อนี้เกี่ยวข้องโดยตรงเมื่อส่งช่วงเอกสารไปให้ LLM API ที่ประมวลผลนอกประเทศ
• มาตรา 37(1): ผู้ควบคุมต้องจัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม เพื่อป้องกันการสูญหาย เข้าถึง ใช้ เปลี่ยนแปลง แก้ไข หรือเปิดเผยโดยปราศจากอำนาจหรือโดยมิชอบ และทบทวนเมื่อจำเป็นหรือเมื่อเทคโนโลยีเปลี่ยน การกรองสิทธิ์ในระบบ RAG เป็นส่วนหนึ่งของมาตรการนี้
• มาตรา 37(2): เมื่อให้ข้อมูลแก่บุคคลอื่น ต้องป้องกันไม่ให้ผู้นั้นใช้หรือเปิดเผยโดยมิชอบ
• มาตรา 37(4): เมื่อเกิดการละเมิดต้องแจ้งสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุเท่าที่จะทำได้ เว้นแต่ไม่มีความเสี่ยงที่จะกระทบสิทธิและเสรีภาพของบุคคล และถ้ามีความเสี่ยงสูงต้องแจ้งเจ้าของข้อมูลด้วย
• มาตรา 40: ผู้ประมวลผลต้องทำตามคำสั่งของผู้ควบคุมเท่านั้น จัดให้มีมาตรการความปลอดภัยที่เหมาะสม แจ้งผู้ควบคุมเมื่อเกิดการละเมิด และจัดทำบันทึกรายการกิจกรรมการประมวลผล (ยกเว้นได้สำหรับกิจการขนาดเล็กตามที่คณะกรรมการประกาศกำหนด) ส่วนผู้ควบคุมต้องมีข้อตกลงควบคุมการดำเนินงานของผู้ประมวลผล ผู้ให้บริการ API หรือผู้รับจ้างที่ประมวลผลเอกสารแทนองค์กรจึงควรมีข้อตกลงนี้

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

ติดตั้งภายใน (on-premises) หรือใช้ cloud API ดี?

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

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

เช็กลิสต์ความพร้อมข้อมูลก่อนเริ่มทำ RAG

• โจทย์: ใครถาม ถามเรื่องอะไร และคำตอบแบบไหนถือว่าใช้ได้ เลือกโจทย์เดียวสำหรับงานนำร่อง
• ขอบเขตเอกสาร: ชุดเอกสารที่ตอบโจทย์นั้นอยู่ที่ไหน ใครเป็นเจ้าของ และฉบับไหนคือฉบับที่มีผล
• รูปแบบไฟล์: ดึงข้อความได้หรือไม่ มีไฟล์สแกนที่ต้องทำ OCR ตาราง หรือรูปที่มีข้อมูลสำคัญหรือไม่
• สิทธิ์: ข้อมูลสิทธิ์อยู่ที่ไหน (file share, AD/LDAP, ระบบเอกสาร) และระบบค้นจะอ่านสิทธิ์นั้นได้อย่างไร
• ข้อมูลส่วนบุคคล: มีข้อมูลส่วนบุคคลหรือข้อมูลอ่อนไหวตามมาตรา 26 ปนอยู่หรือไม่ ต้องตัดออก ปกปิด หรือคุมสิทธิ์อย่างไร
• ศัพท์เฉพาะ: รายการชื่อหน่วยงาน ชื่อระบบ คำย่อ และศัพท์เทคนิค สำหรับปรับพจนานุกรมตัดคำและคำพ้อง
• ชุดทดสอบ: คำถามจริงพร้อมคำตอบและเอกสารอ้างอิงที่เจ้าของเรื่องยืนยัน รวมคำถามที่ไม่มีคำตอบและคำถามที่ผู้ถามไม่มีสิทธิ์
• การอัปเดต: เอกสารเปลี่ยนบ่อยแค่ไหน และดัชนีต้องตามทันภายในเวลาเท่าไร

เริ่มจากประเมินความพร้อมข้อมูล

UNIXDEV ออกแบบและพัฒนา RAG สำหรับเอกสารภาษาไทย ตั้งแต่ดึงข้อความ ตัดคำ hybrid retrieval และ re-ranker ไปจนถึงชุดประเมินคำตอบด้วยชุดคำถามภาษาไทย และการเชื่อมสิทธิ์กับระบบเดิม ภายใต้บริการ AI Agent และ RAG สำหรับองค์กร เลือกได้ทั้งแบบใช้ API ภายนอก ติดตั้งภายใน หรือแบบผสม โดยเทียบด้วยชุดทดสอบเดียวกันก่อนตัดสินใจ

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

แหล่งอ้างอิงและอ่านต่อ

• Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv 2005.11401, NeurIPS 2020)
• OpenAI — Optimizing LLM Accuracy
• Anthropic — Reduce hallucinations
• OpenSearch — Thai tokenizer
• OpenSearch — Thai analyzer
• Elastic — Thai tokenizer
• Elastic — ICU tokenizer
• PyThaiNLP — pythainlp.tokenize
• OpenSearch — Hybrid search
• OpenSearch — Score ranker processor (RRF)
• Elastic — Hybrid search
• Elastic — Reciprocal rank fusion
• Elastic — Similarity settings (BM25)
• Ragas — Faithfulness
• Ragas — Answer Relevancy
• Ragas — Context Precision
• Ragas — Context Recall
• OpenSearch — Document-level security
• Elastic — Controlling access at the document and field level
• Fess — Enterprise Search Server
• Fess — Role-based search
• Fess — Release notes (GitHub)
• พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล)
• บทความที่เกี่ยวข้อง: AI Agent ในองค์กร ควรเริ่มจากงานไหน และวัดอย่างไรว่าคุ้ม
• บทความที่เกี่ยวข้อง: นำ AI/LLM ไปใช้จริงในองค์กรไทย
• ความสามารถด้าน Generative AI · LLM ของ UNIXDEV
• ความสามารถด้าน Fess ของ UNIXDEV
• บทความทั้งหมดในหมวด AI Agent และ RAG สำหรับองค์กร

บทความโดย UNIXDEV Team · 1 พฤศจิกายน 2026 · ข้อมูลผลิตภัณฑ์และเอกสารอ้างอิงตรวจ ณ วันที่เขียน (1 พฤศจิกายน 2026) ซึ่งอาจเปลี่ยนแปลงได้ ส่วนที่เกี่ยวกับกฎหมายเป็นการสรุปบทบัญญัติ ไม่ใช่คำปรึกษาทางกฎหมาย