RAG คืออะไร ธุรกิจควรใช้ AI ตอบจากเอกสารเมื่อไร

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

1. 01โจทย์ธุรกิจ
2. 02ข้อมูล
3. 03สาเหตุ
4. 04สิ่งที่ทำต่อ

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

RAG ทำงานอย่างไร

1. เตรียมความรู้: คัดเอกสาร ทำความสะอาด แบ่งเป็นส่วน และบันทึกข้อมูลกำกับ
2. รับคำถาม: ระบบตรวจสิทธิ์และอาจปรับคำถามให้ค้นได้ดีขึ้น
3. ค้น: ดึงข้อความที่เกี่ยวข้องด้วย Keyword, Semantic หรือ Hybrid search
4. เพิ่มบริบท: ส่งข้อความที่ค้นพบพร้อมคำสั่งและคำถามให้โมเดล
5. สร้างคำตอบ: โมเดลเรียบเรียงจากบริบทและควรแสดงแหล่งอ้างอิง
6. ตรวจ: ใช้กฎ ความปลอดภัย การประเมิน และ Human review ตามความเสี่ยง

คำศัพท์ที่ต้องเข้าใจก่อน

คำ	ความหมายภาษางาน
Chunk	ส่วนย่อยของเอกสารที่ระบบนำไปค้น
Embedding	ตัวแทนเชิงตัวเลขที่ช่วยเทียบความหมายของข้อความ
Vector store/index	ที่เก็บและดัชนีสำหรับค้นความใกล้เคียงเชิงความหมาย
Retriever	ส่วนที่เลือกข้อความเกี่ยวข้องกับคำถาม
Grounding	ทำให้คำตอบยึดกับหลักฐานที่จัดเตรียม
Reranking	จัดลำดับผลค้นอีกครั้งให้ข้อความที่เหมาะขึ้นก่อน
Citation	ลิงก์หรือ Reference กลับไปยังแหล่งที่คำตอบใช้

RAG เหมาะกับงานแบบใด

• ค้นนโยบาย ขั้นตอน และคู่มือปฏิบัติงานที่มี Version ชัด
• ช่วยพนักงานหาคำตอบจาก Product documentation
• สรุปข้อกำหนดจากชุดเอกสารที่ผู้ใช้มีสิทธิ์
• ช่วยทีมบริการลูกค้าร่างคำตอบจาก Knowledge base
• ค้นบทเรียนหรือแนวทางจากโครงการเดิมที่ผ่านการจัดสิทธิ์
• ตอบคำถามจากเอกสารจำนวนมากพร้อมอ้างแหล่ง

เมื่อไรไม่ควรเริ่มด้วย RAG

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

RAG ต่างจาก Search และ Fine-tuning อย่างไร

แนวทาง	เหมาะกับ	ข้อจำกัด
Search	พาผู้ใช้ไปอ่านแหล่งต้นฉบับ	ผู้ใช้ต้องอ่าน/สังเคราะห์เอง
RAG	ค้นและเรียบเรียงคำตอบจากความรู้ที่เปลี่ยนได้	ผิดได้ทั้งการค้นและการเรียบเรียง
Fine-tuning	ปรับรูปแบบ พฤติกรรม หรืองานเฉพาะจากตัวอย่าง	ไม่ใช่วิธีง่ายที่สุดในการอัปเดตข้อเท็จจริง
Tool/API	เรียกข้อมูลสด คำนวณ หรือทำรายการ	ต้องออกแบบสิทธิ์ Validation และ Error handling

เริ่มจากคำถามธุรกิจ ไม่เริ่มจาก Vector Database

1. ระบุผู้ใช้และการตัดสินใจที่ต้องช่วย
2. รวบรวมคำถามจริง 30–100 คำถามจากงาน ไม่สร้างจากทีมเทคนิคอย่างเดียว
3. กำหนดคำตอบที่ยอมรับได้ หลักฐาน และกรณีต้องปฏิเสธ
4. เลือก Source of truth และเจ้าของแต่ละชุดข้อมูล
5. กำหนดความเสี่ยง สิทธิ์ และ Human review
6. ทำ Baseline ด้วย Search/Prompt แบบง่าย
7. สร้าง Pilot กับขอบเขตเล็กและวัดผลก่อนขยาย

เตรียมเอกสารให้ค้นได้จริง

สิ่งที่ต้องทำ	เหตุผล
ลบฉบับซ้ำ/หมดอายุ	ลดคำตอบขัดกัน
เก็บ Title, Owner, Version, Effective date	กรองและอ้างอิงได้
แบ่ง Chunk ตามความหมาย	ไม่ตัดหัวข้อออกจากเงื่อนไข
รักษาตาราง/รายการ/หัวข้อ	ช่วยให้บริบทไม่แตก
กำหนด Access label	ป้องกันการค้นข้ามสิทธิ์
สร้าง Change/Deletion process	ให้ดัชนีตรงกับต้นทาง

สิทธิ์ต้องตรวจตอนค้น ไม่ใช่หลังตอบ

ระบบต้องรู้ว่าใครถามและมีสิทธิ์เห็น Source ใดก่อน Retrieval หากค้นเอกสารลับแล้วค่อยซ่อน Citation ข้อมูลอาจถูกเปิดเผยในคำตอบไปแล้ว ต้องมี:

• Identity และ Role ที่เชื่อถือได้
• Access control ตามเอกสาร/กลุ่ม
• Tenant isolation เมื่อให้บริการหลายองค์กร
• Audit log ที่เหมาะสมโดยไม่บันทึกข้อมูลเกินจำเป็น
• Retention/Deletion ที่สอดคล้องกับนโยบาย
• Red-team test สำหรับการขอข้ามสิทธิ์และ Prompt injection

RAG ผิดได้สองชั้น

1. Retrieval ผิด

ระบบดึงเอกสารไม่เกี่ยวข้อง พลาดคำตอบ หรือเลือกฉบับเก่า สาเหตุอาจมาจาก Chunk, Metadata, Query, Synonym, Access filter หรือ Index lag

2. Generation ผิด

เอกสารถูกแต่โมเดลสรุปผิด ผสมหลายแหล่ง ตีความเกินหลักฐาน หรือสร้าง Citation ที่ไม่รองรับข้อความ

จึงต้องวัดทั้ง “ค้นเจอหลักฐานถูกหรือไม่” และ “คำตอบยึดหลักฐานหรือไม่” ไม่ใช้ความพึงพอใจอย่างเดียว

ชุดทดสอบที่ระบบต้องผ่าน

กลุ่มคำถาม	คาดหวัง
ตอบได้ตรงเอกสาร	คำตอบและ Citation ถูก
ต้องรวมหลายแหล่ง	ไม่ข้ามเงื่อนไข/ความขัดแย้ง
ข้อมูลไม่มี	บอกว่าไม่พบและขอข้อมูลเพิ่ม
เอกสารขัดกัน	แสดงความขัดแย้ง/Version ไม่เลือกเอง
ผู้ใช้ไม่มีสิทธิ์	ไม่ค้น ไม่อ้าง ไม่เผย Metadata ลับ
คำถามกำกวม	ถามกลับก่อนสรุป
Prompt injection ในเอกสาร	ไม่ทำตามคำสั่งแฝง
ข้อมูลเปลี่ยน	Index/คำตอบอัปเดตตาม SLA

ตัวชี้วัดสำหรับ Pilot

• Retrieval recall: คำถามที่ดึงหลักฐานจำเป็นได้
• Precision/relevance: ข้อความที่ดึงมาเกี่ยวข้องจริง
• Groundedness: ข้อความในคำตอบรองรับด้วย Source
• Citation accuracy: Citation ชี้หลักฐานตรงประโยค
• Answer completeness: ครบเงื่อนไขสำคัญ
• Abstention: ปฏิเสธอย่างถูกต้องเมื่อไม่มีข้อมูล
• Security test pass: ไม่ข้ามสิทธิ์/ไม่รั่ว
• Task outcome: เวลา Rework/Error/Resolution ดีขึ้น
• Cost/latency: ค่าใช้จ่ายและเวลาตอบต่อคำถาม

Workflow การดูแลหลังเปิดใช้

1. เจ้าของความรู้อนุมัติ Source/Version
2. ระบบ Ingest และตรวจจำนวน/Checksum/Error
3. Evaluation suite รันก่อนเปลี่ยน Index/Prompt/Model
4. Reviewer ตรวจ Sample ตามระดับความเสี่ยง
5. ผู้ใช้ Feedback ด้วยเหตุผล เช่น “ไม่พบแหล่ง/ฉบับเก่า/ตอบเกินเอกสาร”
6. ทีม Triage แยก Retrieval, Content, Generation, Permission
7. บันทึก Change และ Rollback
8. ทบทวนสิทธิ์ ความสด ค่าใช้จ่าย และ Failure รายเดือน/ไตรมาส

ข้อผิดพลาดที่พบบ่อย

• นำ Shared drive ทั้งหมดเข้า Index โดยไม่คัด Source
• ใช้ Similarity score เป็นหลักฐานว่าคำตอบถูก
• ไม่มี Version/Owner/Effective date
• แสดง Citation แต่ลิงก์เปิดไม่ได้ตามสิทธิ์
• ทดสอบแต่ Happy path
• ใช้ผู้ใช้จริงเป็นผู้ทดสอบความปลอดภัยแทน Red-team
• ไม่กำหนดคำตอบเมื่อข้อมูลไม่พอ
• เปลี่ยน Model/Chunk/Prompt พร้อมกันจนหาสาเหตุไม่ได้
• วัดจำนวนคำถาม แต่ไม่วัดงานสำเร็จและ Rework

Checklist ก่อนเปิดให้ทีมใช้

• Use case, Audience และ Decision boundary ชัด
• Source of truth มี Owner/Version/Review date
• สิทธิ์กรองก่อน Retrieval และทดสอบข้ามบทบาท
• ข้อมูลส่วนตัว/ลับมี Retention และ Redaction
• Golden question set ครอบคลุมกรณีผิดปกติ
• วัด Retrieval และ Generation แยกกัน
• คำตอบมี Source และเปิดดูได้
• มี Abstain/Escalation/Human review
• Monitoring, Incident, Change และ Rollback พร้อม
• ผู้ใช้รู้ว่าคำตอบ AI ยังต้องตรวจตามความเสี่ยง

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

RAG ทำให้ AI ไม่หลอนได้หรือไม่

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

ต้องมี Vector Database เสมอหรือไม่

ไม่เสมอ ระบบเล็กอาจใช้ Full-text search หรือ Hybrid search ที่มีอยู่ วิธีเลือกขึ้นกับข้อมูล ภาษา คำถาม สิทธิ์ คุณภาพ และต้นทุน

เอกสารภายในปลอดภัยทันทีเมื่อใช้ RAG หรือไม่

ไม่ ความปลอดภัยขึ้นกับผู้ให้บริการ การตั้งค่า สิทธิ์ Data flow Logging Retention และสัญญา ต้องทำ Data/Threat assessment ก่อนใช้งานจริง

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

• AWS Prescriptive Guidance: Understanding RAG
• Microsoft Learn: Enhance AI responses with RAG
• Microsoft Learn: Advanced RAG systems
• Google Cloud: Generative AI glossary — RAG

อ่านต่อ: ทำความเข้าใจ AI Assistant กับ AI Agent, วาง AI Governance และตรวจ ข้อมูลที่ไม่ควรส่งเข้า AI

ผู้เขียน: อาจารย์หลิง ณิชชา ทัตพงษ์พฤธา ผู้ก่อตั้ง AJLinkOfficial และบริษัท อินดิจิทัล จำกัด เรียบเรียงเรื่อง AI และ Digital Marketing ให้เชื่อมกับการตัดสินใจและการทำงานของธุรกิจ