Chunking และ Embedding: หัวใจของ RAG ที่ตอบแม่น

ทำไม RAG ตัวเดียวกันตอบแม่นในบางบริษัทแต่มั่วในอีกบริษัท เข้าใจการหั่นเอกสารและ Embedding พร้อมวิธีตั้งค่าที่ใช้ได้จริง

สองบริษัทใช้โมเดล AI ตัวเดียวกัน ทำ Chatbot ตอบคำถามจากเอกสารเหมือนกัน แต่ที่หนึ่งตอบแม่นจนพนักงานติดใจ อีกที่ตอบมั่วจนไม่มีใครใช้ ความต่างส่วนใหญ่ไม่ได้อยู่ที่โมเดล แต่อยู่ที่ขั้นตอนเตรียมข้อมูลที่คนมักมองข้าม นั่นคือ Chunking และ Embedding

Chunking และ Embedding คืออะไร

ในระบบ RAG เราไม่ได้ส่งเอกสารทั้งเล่มให้ AI อ่าน แต่ต้องหั่นเอกสารเป็นชิ้นเล็กๆ ก่อน การหั่นนี้เรียกว่า Chunking และแต่ละชิ้นเรียกว่า chunk

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

ทำไม Chunking ถึงสำคัญ

Chunk ใหญ่เกินไป

หนึ่ง chunk มีหลายเรื่องปนกัน พิกัดความหมายจึงเบลอ ค้นเจอยาก และส่งข้อความที่ไม่เกี่ยวข้องให้ AI อ่านเยอะเกินจำเป็น

Chunk เล็กเกินไป

ข้อความขาดบริบท เช่น chunk ที่เขียนว่า "วงเงินไม่เกิน 3,000 บาทต่อปี" โดยไม่มีหัวข้อกำกับ AI จะไม่รู้เลยว่าเป็นวงเงินของสวัสดิการอะไร

ปัญหาบริบทหาย

Anthropic อธิบายปัญหานี้ในแนวทางที่เรียกว่า Contextual Retrieval (กันยายน 2024) โดยเติมคำอธิบายสั้นๆ ว่า chunk นั้นมาจากส่วนไหนของเอกสารไว้หน้า chunk ก่อนแปลงเป็น embedding ตามรายงานของ Maginative ที่สรุปผลทดสอบของ Anthropic วิธีนี้ลดการค้นไม่เจอ (failed retrievals) ได้ 35% และลดได้ 49% เมื่อใช้คู่กับการค้นแบบคีย์เวิร์ด BM25

วิธีหั่นเอกสารที่ใช้กันบ่อย

• Fixed-size: ตัดตามจำนวนตัวอักษรหรือ token เท่าๆ กัน ง่ายที่สุดแต่มักตัดกลางประโยค
• Overlap: ให้ chunk ติดกันมีข้อความซ้อนกันเล็กน้อย กันไม่ให้ใจความสำคัญถูกตัดขาดตรงรอยต่อ
• ตามโครงสร้างเอกสาร: ตัดตามหัวข้อ หมวด หรือย่อหน้า เหมาะกับคู่มือ ระเบียบ และสัญญาที่มีโครงสร้างชัด
• ใส่ metadata: แนบชื่อเอกสาร หัวข้อ วันที่ และแผนก ไว้กับทุก chunk เพื่อใช้กรองและอ้างอิง

เลือก Embedding Model ยังไง

Embedding model คือตัวแปลงข้อความเป็นพิกัด ถ้าเอกสารของคุณเป็นภาษาไทยปนอังกฤษ ต้องเลือกโมเดลที่รองรับหลายภาษา ตัวอย่างเช่น BGE-M3 ของ BAAI ซึ่งเอกสารทางการระบุว่ารองรับมากกว่า 100 ภาษา และรับข้อความได้ถึง 8,192 token สิ่งที่ควรดูประกอบกัน คือ

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

ตัวอย่างจริงในออฟฟิศไทย

ฝ่ายบัญชีของบริษัทผลิตชิ้นส่วนแห่งหนึ่งนำ "ระเบียบการเบิกค่าใช้จ่าย" มาทำ RAG รอบแรกใช้ fixed-size chunk ผลคือเมื่อถามว่า "เบิกค่าที่พักต่างจังหวัดได้เท่าไร" ระบบดึงตัวเลขของค่าเบี้ยเลี้ยงมาตอบ เพราะสองเรื่องอยู่ติดกันและถูกตัดรวมใน chunk เดียว

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

ข้อควรระวัง

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

AI ตอบได้ดีแค่ไหน ขึ้นกับว่าเราหั่นความรู้ให้มันดีแค่ไหน

เริ่มต้นยังไง

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

ถ้ายังไม่แน่ใจว่า RAG ทำงานภาพรวมยังไง เริ่มจาก RAG คืออะไร ก่อน และถ้าอยากพัฒนาทักษะ AI สายข้อมูลต่อ ดูคอร์สที่เกี่ยวข้องได้ที่ Plants.work Learn