RAG คืออะไร? AI ที่รู้เรื่องเอกสารบริษัทคุณ ทำงานยังไง (ฉบับธุรกิจไทย)

RAG คือ เทคนิคที่ให้ AI ไป ค้นเอกสารของคุณก่อน แล้วค่อยตอบ ย่อมาจาก Retrieval-Augmented Generation โมเดลไม่ได้ "เรียนรู้" เอกสารบริษัทคุณ แต่ถูกยื่นข้อความที่เกี่ยวข้องให้อ่านสด ๆ ตอนคำถามเข้ามา แล้วตอบจากสิ่งที่เพิ่งอ่าน นี่คือสิ่งที่ธุรกิจไทยต้องการจริง ๆ เวลาพูดว่า "อยากได้ AI ที่รู้เรื่องเอกสารบริษัทเรา" — ไม่ใช่ fine-tuning ไม่ต้องเทรนโมเดลใหม่ ไม่ต้องมี GPU ของตัวเอง

RAG ทำงานยังไง — 4 ขั้นตอนที่เกิดขึ้นทุกครั้งที่มีคำถาม

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

1. 1.Index (ครั้งเดียว) — หั่นเอกสารเป็นชิ้น (chunk) แปลงเป็นเวกเตอร์ด้วย embedding model เก็บลง vector database
2. 2.Retrieve — คำถามถูกแปลงเป็นเวกเตอร์แบบเดียวกัน ระบบดึงชิ้นที่ใกล้ที่สุด k ชิ้น (ปกติ 4-8)
3. 3.Augment — แปะชิ้นที่ได้เข้า prompt พร้อมคำสั่งว่า ตอบจากข้อมูลนี้เท่านั้น ถ้าไม่มีให้บอกว่าไม่ทราบ
4. 4.Generate — โมเดลตอบจากข้อความที่เพิ่งอ่าน และชี้ได้ว่ามาจากไฟล์ไหนหน้าไหน

ทำไม RAG เหมาะกว่า Fine-tuning สำหรับงานนี้

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

ข้อได้เปรียบที่คนไทยมักมองข้าม: PDPA

ถ้าเอกสารมีข้อมูลส่วนบุคคล — ประวัติลูกค้า เบอร์โทร ที่อยู่จัดส่ง แฟ้มพนักงาน — พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคลให้สิทธิเจ้าของข้อมูลขอให้ลบได้ กับ RAG ลบแถวใน vector database แล้วจบ พิสูจน์ได้ว่าลบจริง แต่กับ fine-tuning ข้อมูลถูกหลอมเข้าไปในน้ำหนักแล้ว ไม่มีวิธีลบทีละรายการ ทางเดียวคือเทรนใหม่ทั้งก้อน นี่คือเหตุผลเชิงกฎหมายที่ทำให้ RAG เป็นสถาปัตยกรรมตั้งต้นที่ถูกต้องสำหรับเอกสารภายในองค์กรไทย

ต้นทุนจริงของ RAG สำหรับ SME ไทย

ตัวเลขข้างล่างเป็น การคำนวณสมมติ ไม่ใช่บิลของลูกค้าจริง สมมติบริษัทมีเอกสารภายใน 2,000 หน้า (SOP ใบราคา นโยบายรับประกัน คู่มือพนักงาน) ตีคร่าว ๆ หน้าละ ~1,200 token = ราว 2.4 ล้าน token:

• •ทำ index ครั้งแรก — text-embedding-3-small $0.02 ต่อ 1M token → 2.4M × $0.02 = $0.048 ≈ ฿1.70 ครั้งเดียว (Gemini Embedding $0.15 ต่อ 1M และมี free tier) · re-index รายเดือนถ้าเอกสารเปลี่ยน 5% ≈ ไม่ถึง 10 สตางค์
• •ตอบ 3,000 คำถาม/เดือน — ต่อคำถาม ~3,900 token เข้า (6 chunk + system prompt + คำถาม) ~300 token ออก บน Gemini 2.5 Flash-Lite ($0.10/$0.40 ต่อ 1M) = $1.53 ≈ ฿55/เดือน · ย้ายไป GPT-5.6 Luna ($0.20/$1.20) = $3.42 ≈ ฿123/เดือน
• •Vector database — pgvector บน Postgres ที่มีอยู่แล้ว = ฿0 บิลที่ทำให้คนตกใจมักมาจาก managed vector DB ที่คิดเงินตามขนาด index ไม่ใช่จากค่าโมเดล

ค่าโมเดลทั้งหมดรวมกันไม่ถึง ฿150 ต่อเดือน นี่คือประเด็นสำคัญที่สุด: ต้นทุนของ RAG ไม่ใช่ค่า token แต่คือคน-วันที่หมดไปกับการหาวิธีตัด chunk ที่ถูก สร้างชุดคำถามไว้วัดผล และทำให้ re-index เกิดเองเมื่อเอกสารเปลี่ยน ใครเสนอราคาโปรเจกต์ RAG โดยพูดถึงแต่ค่า API แปลว่ายังไม่เคยทำของขึ้น production

ทำไมภาษาไทยตัดชิ้น (chunk) ยากกว่าภาษาอังกฤษ

เครื่องมือ RAG แทบทั้งหมดออกแบบบนสมมติฐานของภาษาอังกฤษ และสมมติฐานเหล่านั้นพังกับภาษาไทยทันที

• •ไม่มีช่องว่างระหว่างคำ — chunker ที่ตัดตามช่องว่างแล้วนับ "500 คำ" มองย่อหน้าไทยทั้งย่อหน้าเป็นก้อนเดียว จึงถอยไปตัดตามจำนวนอักขระ ซึ่งมักตัดกลางคำ
• •ไม่มีจุดจบประโยค — sentence splitter ที่หา . ? ! เจอศูนย์จุดตัดในเอกสารไทย ทั้งไฟล์เลยกลายเป็น chunk เดียวแล้วโดนตัดทิ้งตรงลิมิต
• •กิน token มากกว่าต่อเนื้อความเท่ากัน — tokenizer ฝึกมาจากข้อความอังกฤษเป็นหลัก จึงซอยอักษรไทยเป็นชิ้นย่อย chunk ขนาด 500 token ของไทยจึง บรรจุใจความน้อยกว่า ของอังกฤษ อย่าเชื่อสัญชาตญาณจากภาษาอังกฤษ ให้นับด้วย tokenizer จริง
• •embedding รู้จักภาษาไทยน้อยกว่า — โมเดล multilingual เห็นข้อมูลไทยน้อยกว่ามาก recall ของคำถามไทยจึงต่ำกว่าโดยธรรมชาติ ยิ่งลูกค้าพิมพ์ผิดหรือพิมพ์ติดกันยิ่งพลาด

แก้ยังไงให้ retrieval ภาษาไทยแม่นขึ้น

ทั้งสี่ข้อแก้ได้ และไม่ยากถ้ารู้ตั้งแต่ต้น:

• •ตัดตามโครงสร้างเอกสาร ไม่ใช่ตามจำนวนอักขระ — เอกสารธุรกิจไทยเกือบทั้งหมดมีเลขข้อกำกับอยู่แล้ว (ข้อ 1, ข้อ 2, บทที่ 3) ตัดตรงนั้น และอย่าให้หัวตารางหลุดจากแถว — ใบราคาที่หัวตารางหายคือสาเหตุอันดับหนึ่งที่บอทตอบราคาผิด
• •ตัดคำด้วยตัวตัดคำไทยก่อน — PyThaiNLP (engine newmm) ใส่ขอบเขตคำให้ก่อนส่งเข้า chunker และใช้ผลเดียวกันกับ BM25 ได้
• •hybrid search + ตารางคำพ้องไทย-อังกฤษ — vector อย่างเดียวมักพลาดรหัสสินค้า ให้ BM25 ทำงานคู่กัน และผูกคำที่ลูกค้าใช้ ("เครื่องซักผ้าฝาหน้า") เข้ากับชื่อในเอกสาร (Front Load Washer WM-2200)

RAG พังตรงไหน — และเกือบทุกครั้งมันพังแบบเงียบ ๆ

เวลา RAG พัง มันไม่ขึ้น error มันตอบผิดด้วยน้ำเสียงมั่นใจเท่าเดิม

1. 1.Chunk ตัดคำตอบขาดครึ่ง — เงื่อนไขรับประกันอยู่ท้ายชิ้นที่ 1 ข้อยกเว้นอยู่ต้นชิ้นที่ 2 ดึงมาชิ้นเดียว ลูกค้าได้คำตอบที่ถูกครึ่งเดียว
2. 2.Retrieval พลาด — chunk ที่ถูกอยู่อันดับ 7 แต่ตั้ง k=5 โมเดลไม่เคยเห็นคำตอบที่ถูก แล้วก็เดาให้อย่างสุภาพ
3. 3.Index ค้าง — ฝ่ายขายอัปโหลดใบราคาใหม่ แต่ pipeline ไม่ได้ re-index บอทยังยืนยันราคาปีที่แล้ว ต้อง re-index ตอนไฟล์เปลี่ยน ไม่ใช่ตอนนึกได้
4. 4.เอกสารขัดกันเอง — ใบราคา 4 เวอร์ชันในโฟลเดอร์เดียว ระบบดึงมา 2 โมเดลเลือกให้เอง RAG ไม่ได้ทำให้เอกสารที่มั่วอยู่แล้วดีขึ้น มันแค่ตอบเร็วขึ้น
5. 5.RAG ไม่ได้ทำให้โมเดลเก่งในเรื่องที่มันไม่เก่ง — ป้อนประมวลรัษฎากรให้โมเดลที่ไม่เข้าใจภาษีไทย ก็ยังตีความผิดอยู่ดี retrieval ให้ ข้อความ ไม่ได้ให้ ความเข้าใจ

เมื่อไหร่ที่ไม่ควรทำ RAG (ความเห็นตรง ๆ)

ผมเชื่อว่าโปรเจกต์ RAG ในไทยที่ล้ม เกินครึ่งล้มเพราะไม่ควรเริ่มตั้งแต่แรก สี่กรณีนี้ให้หยุดก่อน:

• •เอกสารทั้งหมดใส่ context ได้หมด — คู่มือพนักงาน 80 หน้าใส่เข้า prompt ได้สบายบนโมเดลปัจจุบัน และ prompt caching ทำให้ถูกลงอีก สร้าง vector pipeline ให้เอกสาร 80 หน้าคือวิศวกรรมเพื่อความรู้สึกว่าได้ทำ
• •คำตอบมีไม่กี่แบบและแทบไม่เปลี่ยน — คำถาม 30 ข้อแบบ "ร้านเปิดกี่โมง" ควรเป็นตารางคำตอบตายตัวหรือ rich menu ใน LINE OA ระบบที่ถูก 100% ชนะระบบที่ถูก 92% เสมอ (ดู คู่มือ LINE OA Chatbot)
• •เอกสารยังขัดกันเอง — ถ้ายังไม่มีใครรู้ว่าใบราคาเวอร์ชันไหนคือของจริง อย่าเพิ่ง index ทำความสะอาดเอกสารก่อน งานนี้ไม่มีใครอยากทำ และเป็นงานที่ตัดสินว่าโปรเจกต์จะสำเร็จหรือไม่
• •คำถามต้องการการรวมตัวเลข — "ยอดขายไตรมาสที่แล้วรวมเท่าไหร่" RAG ดึงมาแค่ top-k chunk บวกเลข 4,000 แถวไม่ได้ งานนี้คือ SQL ไม่ใช่ retrieval

ถ้าจะเริ่มทำจริง เริ่มจากตรงไหน

ลำดับนี้ตั้งใจให้ล้มเหลวถูกจุดตั้งแต่ยังไม่เสียเงิน:

1. 1.รวบรวมคำถามจริง 50 ข้อจากแชทลูกค้า พร้อมระบุว่าคำตอบที่ถูกอยู่ไฟล์ไหน — ชุดนี้คือเกณฑ์วัดของทั้งโปรเจกต์
2. 2.ทำความสะอาดเอกสาร ลบเวอร์ชันเก่า ตั้งให้ชัดว่าใครเป็นเจ้าของและมีสิทธิ์แก้แต่ละไฟล์
3. 3.เริ่มด้วยวิธีที่เรียบง่ายที่สุดที่ยังใช้ได้ — ตัดตามหัวข้อ + pgvector บน Postgres เดิม อย่าเพิ่งซื้อ managed vector DB
4. 4.วัด recall@k ก่อนต่อ LLM แล้วค่อยเพิ่ม hybrid search กับ reranker เมื่อวัดแล้วเห็นว่าพลาดตรงไหน