RAG คืออะไร? คู่มืออธิบายแบบเข้าใจง่ายสำหรับผู้บริหาร

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

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

RAG คืออะไร?

RAG ย่อมาจาก Retrieval-Augmented Generation เป็นรูปแบบการออกแบบระบบ AI ที่แยก ขั้นตอนการตอบคำถาม (generation) ออกจากขั้นตอนการจัดเก็บความรู้ (retrieval)

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

หน้าที่ของโมเดลลดลงเหลือแค่ "อ่านข้อความนี้แล้วตอบคำถาม" ซึ่งเป็นงานที่โมเดลภาษาทำได้ดีมาก

ทำไม RAG ถึงมีอยู่: ปัญหาของ ChatGPT ทั่วไป

โมเดลภาษามาตรฐานอย่าง GPT-4 หรือ Claude ถูก train บนข้อมูลสาธารณะจนถึงวันที่กำหนด โมเดลไม่เคยเห็น:

ระเบียบขั้นตอนภายในของบริษัท
สเปกสินค้าหรือแคตาล็อก
สัญญาลูกค้าหรือ SLA
เอกสารการปฏิบัติตามกฎระเบียบ (เช่น PDPA, พ.ร.บ. ความมั่นคงไซเบอร์)
เอกสารที่สร้างขึ้นหลังวันที่ตัดข้อมูล

การ fine-tuning (train โมเดลใหม่ด้วยข้อมูลของคุณ) เป็นทางเลือกหนึ่ง แต่แพง ช้า และมากเกินไปสำหรับงานส่วนใหญ่ RAG ให้ประโยชน์ 90% ด้วยต้นทุน 10% และ knowledge base อัปเดตได้ภายในไม่กี่นาที

RAG ทำงานอย่างไร: อธิบายทีละขั้นตอน

flowchart TD
  A["ผู้ใช้ถามคำถาม"] --> B["Embedding model แปลงคำถามเป็น vector"]
  B --> C["Vector database ค้นหา document chunks ที่ใกล้เคียง"]
  C --> D["ดึง chunks อันดับต้นมา N รายการ"]
  D --> E["ใส่ chunks เป็น context ใน prompt ของ LLM"]
  E --> F["LLM สร้างคำตอบจากข้อความที่ดึงมา"]
  F --> G["ส่งคำตอบพร้อมอ้างอิงแหล่งที่มาให้ผู้ใช้"]

ขั้นตอนที่ 1 — จัดทำดัชนีเอกสาร

ก่อนรับคำถามใดๆ เอกสาร (PDF, Word, wiki, ฐานข้อมูล) จะถูกแบ่งเป็นชิ้นๆ ประมาณ 300–800 token แต่ละชิ้น แล้วแปลงเป็น vector embedding เก็บไว้ใน vector database เช่น pgvector

การจัดทำดัชนีทำครั้งเดียวต่อเอกสาร เมื่อเอกสารเปลี่ยน จะ re-index เฉพาะส่วนที่เปลี่ยน

ขั้นตอนที่ 2 — ค้นหาเมื่อมีคำถาม

เมื่อผู้ใช้ถามคำถาม คำถามนั้นจะถูกแปลงเป็น vector เดียวกัน แล้ว vector database ค้นหาชิ้นที่ใกล้เคียงที่สุด ส่งคืนมา 5–10 รายการ

นี่ไม่ใช่ keyword search แต่เป็น semantic similarity — "สาเหตุที่เครื่องจักรหยุดบ่อย" จะดึงเนื้อหาเดียวกับ "root cause ของ machine downtime" แม้คำจะต่างกัน

ขั้นตอนที่ 3 — สร้างคำตอบที่อิงเอกสาร

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

RAG vs Fine-Tuning vs Prompt ธรรมดา

วิธีการ	แหล่งความรู้	ความเร็วในการอัปเดต	ต้นทุน	เหมาะกับ
Prompt ธรรมดา	ข้อมูล training ของโมเดล	N/A	ต่ำ	คำถามทั่วไป
Fine-tuning	Weights ที่ train ใหม่	สัปดาห์ / เดือน	สูง	สไตล์ภาษา, คำศัพท์เฉพาะสาขา
RAG	คลัง document ภายนอก	นาที	กลาง	ดึงข้อมูลเฉพาะองค์กร

สำหรับงาน document ขององค์กรส่วนใหญ่ RAG คือสถาปัตยกรรมที่ถูกต้อง

RAG หน้าตาเป็นอย่างไรในธุรกิจจริง

ระบบ Knowledge Base ภายในองค์กร
พนักงานถามด้วยภาษาธรรมชาติ ระบบดึงคำตอบจากนโยบาย HR, คู่มือ IT, ระเบียบการเงิน แทนที่จะค้น SharePoint แบบเดิม

ผู้ช่วยตอบคำถามลูกค้า
ลูกค้าถามเรื่องสเปกสินค้า ความเข้ากันได้ หรือการแก้ปัญหา ระบบดึงจากคู่มือและ FAQ ลด ticket support

ค้นหาสัญญาและการปฏิบัติตามกฎหมาย
ทีมกฎหมายและจัดซื้อค้นสัญญาโดยไม่ต้องอ่านทุกฉบับ — พร้อมระบุข้อความต้นฉบับ ซึ่งสำคัญมากสำหรับการปฏิบัติตาม PDPA

สิ่งที่ RAG ทำไม่ได้

ข้อจำกัด	คำอธิบาย
Garbage in, garbage out	เอกสารคุณภาพต่ำให้คำตอบคุณภาพต่ำ
Context window จำกัด	เอกสารยาวมากอาจเกินขีดจำกัด input ของโมเดล
ไม่ reasoning ข้ามคลังทั้งหมด	โมเดลเห็นแค่ chunks ที่ดึงมา ไม่เห็นทุกเอกสาร
ไม่มี real-time data นอกจากจะ integrate	RAG ตอบจาก snapshot ที่จัดทำดัชนีไว้ ข้อมูล live ต้อง integrate เพิ่ม
ภาษาไม่ตรงกัน	Query ภาษาไทยกับเอกสารภาษาอังกฤษต้องใช้ embedding model หลายภาษา

แนวทาง simpliDoc

simpliDoc คือผลิตภัณฑ์ของ Simplico ที่สร้างบนสถาปัตยกรรมนี้ เชื่อมต่อกับ repository เอกสารที่มีอยู่ — SharePoint, Google Drive, ERP document store, file server ภายใน — จัดทำดัชนีด้วย embedding model หลายภาษา และรันบนสถาปัตยกรรม LLM แบบ self-hosted เมื่อต้องการ data residency

รองรับภาษา: ภาษาไทย, อังกฤษ, ญี่ปุ่น, จีน

การปฏิบัติตาม PDPA: pipeline ทั้งหมดสามารถ deploy ภายใน infrastructure ของคุณ — เอกสารไม่ออกจากเครือข่ายองค์กร ตรงตามข้อกำหนดของ พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 และ พ.ร.บ. การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562

มีคำถามเกี่ยวกับ RAG สำหรับองค์กรของคุณ?
คุยกับทีม simpliDoc → hello@simplico.net

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

RAG ย่อมาจากอะไร?

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

RAG เหมือนกับ fine-tuning ไหม?

ไม่ใช่ Fine-tuning แก้ไข weights ของโมเดลโดยใช้ข้อมูลของคุณ ช้า แพง และอัปเดตยาก RAG ไม่เปลี่ยนโมเดล แต่ดึงเอกสารที่เกี่ยวข้องมาในเวลา query สำหรับ knowledge base ขององค์กร RAG เร็วกว่า ถูกกว่า และดูแลง่ายกว่า

RAG ทำงานกับเอกสารภาษาไทยได้ไหม?

ได้ หากใช้ multilingual embedding model ที่รองรับภาษาไทย simpliDoc ใช้ embedding model หลายภาษาที่รองรับ TH, EN, JA และ ZH รวมถึงการ query ข้ามภาษา เช่น ถามภาษาไทยกับเอกสารภาษาอังกฤษ

RAG ต้องส่งเอกสารออกไปยัง cloud ไหม?

ไม่จำเป็น RAG สามารถ deploy แบบ on-premise ทั้งหมดโดยใช้ open-source language model (เช่น Llama, Mistral) และ vector database แบบ self-hosted (เช่น pgvector) ซึ่งเป็นสถาปัตยกรรมที่ simpliDoc แนะนำสำหรับลูกค้าที่มีข้อกำหนด PDPA หรือ data residency

ใช้เวลานานแค่ไหนในการ implement RAG?

Proof-of-concept ขั้นพื้นฐานสามารถรันได้ภายใน 2–4 สัปดาห์ การ deploy production พร้อม security hardening, authentication และ integration กับ document repository ที่มีอยู่ มักใช้เวลา 6–12 สัปดาห์ขึ้นอยู่กับความซับซ้อนของ infrastructure

Vector database คืออะไร?

Vector database เก็บเนื้อหาเอกสารเป็น numerical representation หลายมิติที่เรียกว่า embeddings การค้นหาเป็นแบบ semantic ไม่ใช่ keyword — ค้นหาเนื้อหาที่มีความหมายคล้ายกันแม้ใช้คำต่างกัน ตัวเลือกทั่วไปได้แก่ pgvector (PostgreSQL extension), Pinecone, Weaviate และ Chroma

RAG ต่างจาก chatbot ทั่วไปอย่างไร?

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