บอทมี RAG ครบแล้ว ทำไมบางคำถามยังตอบผิดหรือตอบไม่ได้เลย
สรุปสั้น ๆ
RAG หรือ Retrieval-Augmented Generation คือแนวทางที่ให้โมเดลภาษาตอบคำถามโดยอ้างอิงข้อมูลที่ดึงมาจากฐานข้อมูลจริงก่อนสร้างคำตอบ แทนที่จะตอบจากความรู้ที่ฝังอยู่ในโมเดลเพียงอย่างเดียว บน Supabase ทำได้โดยเก็บข้อมูลและ Embedding ไว้ในตารางเดียวกันผ่าน pgvector แต่คุณภาพคำตอบขึ้นอยู่กับขั้นตอนดึงข้อมูล (Retrieval) เป็นหลัก ถ้าดึงข้อมูลผิดหรือไม่ครบ โมเดลภาษาก็ตอบผิดตามไปด้วยแม้จะเก่งแค่ไหนก็ตาม
ทีมที่เพิ่งต่อโมเดลภาษาเข้ากับฐานความรู้ของบริษัทสำเร็จมักตื่นเต้นกับผลลัพธ์ช่วงแรก เพราะบอทเริ่มตอบคำถามที่เกี่ยวกับเอกสารภายในได้ ทั้งที่โมเดลไม่เคยเห็นเอกสารเหล่านั้นมาก่อน แต่พอเปิดให้ทีมงานใช้งานจริงในวงกว้างขึ้น คำร้องเรียนก็เริ่มตามมา บางคำถามบอทตอบผิดทั้งที่คำตอบที่ถูกต้องอยู่ในเอกสารชัดเจน บางคำถามบอทตอบว่าไม่พบข้อมูลทั้งที่มีเอกสารเกี่ยวข้องอยู่จริง
ปัญหาแบบนี้ทำให้หลายทีมสงสัยว่าโมเดลภาษาที่ใช้ไม่เก่งพอหรือเปล่า จึงลองเปลี่ยนไปใช้โมเดลรุ่นใหม่กว่าหรือราคาแพงกว่า แต่ผลลัพธ์กลับไม่ต่างจากเดิมมากนัก เพราะจุดที่พังจริง ๆ มักไม่ได้อยู่ที่ตัวโมเดลภาษาที่สร้างคำตอบ แต่อยู่ที่ขั้นตอนก่อนหน้านั้น คือการดึงข้อมูลที่เกี่ยวข้องมาป้อนให้โมเดลใช้ประกอบคำตอบ ถ้าขั้นตอนนี้ดึงข้อมูลผิดหรือดึงมาไม่ครบ โมเดลก็ไม่มีทางตอบถูกได้ไม่ว่าจะฉลาดแค่ไหน
บทความนี้จะพาไปดูว่า RAG บน Supabase ทำงานยังไงตั้งแต่ต้นจนจบ ควรออกแบบฐานข้อมูลยังไง ขั้นตอนดึงข้อมูลมีจุดไหนที่มักพังบ่อย และวิธีวัดคุณภาพระบบก่อนเปิดใช้งานจริงในวงกว้าง
RAG คืออะไร และต่างจากการต่อโมเดลภาษาตรง ๆ ยังไง
RAG ย่อมาจาก Retrieval-Augmented Generation เป็นแนวทางที่แบ่งการทำงานออกเป็นสองขั้นตอนหลัก ขั้นตอนแรกคือการดึงข้อมูล (Retrieval) ที่เกี่ยวข้องกับคำถามของผู้ใช้ออกมาจากฐานข้อมูล ขั้นตอนที่สองคือการส่งข้อมูลที่ดึงมาได้พร้อมคำถามเดิมไปให้โมเดลภาษาใช้สร้างคำตอบ (Generation) โดยอ้างอิงข้อมูลนั้นเป็นหลัก แทนที่จะให้โมเดลตอบจากความรู้ที่ฝังอยู่ในตัวเองเพียงอย่างเดียว
ข้อดีของแนวทางนี้คือช่วยให้บอทตอบคำถามเกี่ยวกับข้อมูลที่โมเดลไม่เคยเห็นตอนฝึกได้ เช่น เอกสารภายในบริษัท นโยบายที่เพิ่งอัปเดต หรือข้อมูลสินค้าที่เปลี่ยนแปลงบ่อย โดยไม่ต้องฝึกโมเดลใหม่ทุกครั้งที่ข้อมูลเปลี่ยน แค่ปรับปรุงข้อมูลในฐานข้อมูลที่ใช้ดึงก็พอ ซึ่งประหยัดกว่าและทำได้เร็วกว่าการฝึกโมเดลใหม่มาก
จุดที่ทีมมือใหม่มักเข้าใจผิดคือคิดว่า RAG เป็นแค่การส่งเอกสารทั้งหมดให้โมเดลอ่านทุกครั้งที่มีคำถาม ซึ่งไม่สมจริงเมื่อข้อมูลมีจำนวนมาก เพราะโมเดลภาษามีขีดจำกัดของปริมาณข้อความที่รับได้ในแต่ละครั้ง ขั้นตอนดึงข้อมูลจึงสำคัญมาก เพราะต้องเลือกเฉพาะส่วนที่เกี่ยวข้องที่สุดมาป้อนให้โมเดล ไม่ใช่ส่งทุกอย่างไปทั้งหมด
ภาพรวม Pipeline ของ RAG ตั้งแต่รับคำถามถึงส่งคำตอบ
เมื่อผู้ใช้พิมพ์คำถามเข้ามา ระบบ RAG จะแปลงคำถามนั้นเป็นเวกเตอร์ด้วยโมเดลตัวเดียวกับที่ใช้สร้าง Embedding ของข้อมูลต้นฉบับ จากนั้นค้นหาในฐานข้อมูลว่าส่วนของเอกสารไหนมีเวกเตอร์ใกล้เคียงกับคำถามมากที่สุด แล้วดึงข้อความของส่วนเอกสารเหล่านั้นออกมาเป็นบริบท (Context) สำหรับขั้นตอนถัดไป
ขั้นตอนถัดมาคือการประกอบคำสั่ง (Prompt) ที่ส่งให้โมเดลภาษา ซึ่งมักประกอบด้วยคำถามเดิมของผู้ใช้ บริบทที่ดึงมาได้จากขั้นตอนก่อนหน้า และคำสั่งกำกับให้โมเดลตอบโดยอ้างอิงบริบทที่ให้มาเท่านั้น ไม่ใช้ความรู้อื่นนอกเหนือจากที่ให้ไว้ เพื่อลดโอกาสที่โมเดลจะสร้างคำตอบที่ฟังดูสมเหตุสมผลแต่ไม่ตรงกับข้อมูลจริง
ขั้นตอนสุดท้ายคือโมเดลภาษาประมวลผลคำสั่งที่ได้รับแล้วสร้างคำตอบส่งกลับไปให้ผู้ใช้ บางระบบยังเพิ่มขั้นตอนแนบอ้างอิงว่าคำตอบมาจากเอกสารส่วนไหน เพื่อให้ผู้ใช้ตรวจสอบความถูกต้องเพิ่มเติมได้ ซึ่งช่วยเพิ่มความน่าเชื่อถือของระบบในสายตาผู้ใช้จริง
ออกแบบโครงสร้างฐานข้อมูลสำหรับ RAG ต้องเก็บอะไรบ้าง
การออกแบบตารางสำหรับ RAG บน Supabase มักไม่ได้เก็บแค่ข้อความกับเวกเตอร์เท่านั้น แต่ควรเก็บข้อมูลเสริมที่ช่วยให้ตรวจสอบและปรับปรุงระบบได้ง่ายขึ้นในภายหลังด้วย ตารางด้านล่างสรุปคอลัมน์หลักที่ควรมีในตารางสำหรับเก็บข้อมูลที่ใช้ทำ RAG:
| คอลัมน์ | เก็บอะไร | ทำไมต้องมี |
|---|---|---|
| content | ข้อความของส่วนเอกสารย่อยแต่ละชิ้น | เป็นบริบทที่ส่งให้โมเดลภาษาใช้สร้างคำตอบ |
| embedding | เวกเตอร์ที่แปลงมาจากคอลัมน์ content | ใช้เปรียบเทียบความใกล้เคียงกับเวกเตอร์ของคำถาม |
| source_document | ชื่อหรือรหัสเอกสารต้นฉบับที่ส่วนย่อยนี้ตัดมาจาก | ใช้แนบอ้างอิงในคำตอบ และตรวจสอบย้อนกลับเมื่อคำตอบผิด |
| chunk_index | ลำดับของส่วนย่อยภายในเอกสารต้นฉบับ | ช่วยดึงส่วนย่อยที่อยู่ติดกันเพิ่มเติมเมื่อบริบทไม่พอ |
| updated_at | เวลาที่ส่วนย่อยนี้ถูกสร้างหรืออัปเดตล่าสุด | ใช้ตรวจสอบว่าข้อมูลที่ใช้ตอบยังทันสมัยอยู่หรือไม่ |
ขั้นตอนดึงข้อมูลที่ดี ต้องทำอะไรมากกว่าแค่ค้นหาเวกเตอร์ใกล้ที่สุด
- แปลงคำถามของผู้ใช้เป็นเวกเตอร์ด้วยโมเดลตัวเดียวกับที่ใช้สร้าง Embedding ของข้อมูลต้นฉบับเสมอ
- ค้นหาส่วนย่อยเอกสารที่มีเวกเตอร์ใกล้เคียงที่สุด แล้วกำหนดเพดานค่าความใกล้เคียงขั้นต่ำ เพื่อกรองผลลัพธ์ที่ไม่เกี่ยวข้องออกไปตั้งแต่ต้น
- พิจารณาผสม Keyword Search เข้ากับ Vector Search แบบ Hybrid Search เมื่อคำถามมีคำเฉพาะเจาะจงที่ต้องจับคู่ตรงตัว
- ดึงส่วนย่อยที่อยู่ติดกันในเอกสารต้นฉบับเพิ่มเติมถ้าจำเป็น เพื่อให้บริบทที่ส่งให้โมเดลครบถ้วนไม่ขาดตอน
- จำกัดจำนวนส่วนย่อยที่ส่งให้โมเดล ให้อยู่ในขีดจำกัดที่โมเดลรับได้ พร้อมเรียงลำดับความเกี่ยวข้องจากมากไปน้อย
ทำไมมี RAG ครบแล้ว บอทยังตอบผิดหรือตอบไม่ได้อยู่ดี
- ตัดส่วนย่อยเอกสารผิดจุด — ทำแบบนี้แล้วพัง เพราะถ้าตัดกลางประโยคหรือกลางหัวข้อ บริบทที่ดึงมาได้จะไม่ครบความหมาย โมเดลตอบผิดทั้งที่ข้อมูลถูกต้องมีอยู่ในเอกสาร
- ไม่ตั้งเพดานค่าความใกล้เคียงขั้นต่ำในขั้นตอนดึงข้อมูล — ทำแบบนี้แล้วพัง เพราะระบบจะยัดเยียดข้อมูลที่ไม่เกี่ยวข้องให้โมเดลใช้ประกอบคำตอบ ทำให้คำตอบผิดทั้งที่โมเดลไม่ได้ผิดเอง
- ข้อมูลในฐานข้อมูลเก่าไม่ตรงกับความจริงปัจจุบัน — ทำแบบนี้แล้วพัง เพราะ RAG ตอบตามข้อมูลที่ดึงมาได้เท่านั้น ถ้าข้อมูลต้นฉบับไม่ได้อัปเดตตามความจริง คำตอบก็ผิดตามไปด้วยแม้ Pipeline จะทำงานถูกต้องทุกขั้นตอน
- คำสั่งกำกับโมเดลไม่ชัดเจนพอ — ทำแบบนี้แล้วพัง เพราะถ้าไม่กำกับให้โมเดลตอบจากบริบทที่ให้มาเท่านั้น โมเดลอาจผสมความรู้เดิมของตัวเองเข้ามาด้วย ทำให้คำตอบดูสมเหตุสมผลแต่ไม่ตรงกับเอกสารจริง
ผสม Hybrid Search เข้ากับ RAG ช่วยลดคำตอบผิดยังไง
หลายกรณีที่ RAG ตอบผิดเกิดจากขั้นตอนดึงข้อมูลพลาดตั้งแต่ต้น โดยเฉพาะเมื่อคำถามของผู้ใช้มีคำเฉพาะเจาะจง เช่น รหัสสินค้าหรือชื่อเฉพาะ ที่ Vector Search อย่างเดียวอาจดึงข้อมูลผิดชิ้นมาให้โมเดลใช้ การผสม Keyword Search เข้ามาด้วยหลักการ Hybrid Search ช่วยให้ขั้นตอนดึงข้อมูลแม่นยำขึ้นในกรณีแบบนี้ ซึ่งส่งผลตรงไปยังคุณภาพคำตอบสุดท้าย เพราะโมเดลภาษาตอบได้ดีแค่ไหนขึ้นอยู่กับข้อมูลที่ได้รับเป็นหลัก
ทีมที่เจอปัญหาบอทตอบผิดบ่อยควรตรวจสอบก่อนว่าปัญหาอยู่ที่ขั้นตอนดึงข้อมูลหรือขั้นตอนสร้างคำตอบ วิธีตรวจง่าย ๆ คือลองอ่านบริบทที่ระบบดึงมาได้ก่อนส่งให้โมเดลด้วยตัวเอง ถ้าบริบทที่ดึงมาไม่มีคำตอบที่ถูกต้องอยู่เลย ปัญหาอยู่ที่ขั้นตอนดึงข้อมูล แต่ถ้าบริบทมีคำตอบที่ถูกต้องอยู่แล้วแต่โมเดลยังตอบผิด ปัญหาน่าจะอยู่ที่คำสั่งกำกับโมเดลแทน
วัดคุณภาพระบบ RAG ก่อนเปิดใช้งานจริงในวงกว้าง
การวัดคุณภาพ RAG ควรแยกวัดสองส่วนออกจากกัน ส่วนแรกคือคุณภาพของขั้นตอนดึงข้อมูล วัดได้จากการเตรียมชุดคำถามพร้อมคำตอบที่ถูกต้องไว้ล่วงหน้า แล้วตรวจว่าข้อมูลที่ดึงมาได้ในแต่ละคำถามมีคำตอบที่ถูกต้องอยู่ในบริบทที่ดึงมากี่เปอร์เซ็นต์ ถ้าตัวเลขนี้ต่ำ แปลว่าต้องปรับปรุงขั้นตอนดึงข้อมูลก่อน ไม่ใช่ไปแก้ที่โมเดลภาษา
ส่วนที่สองคือคุณภาพของคำตอบสุดท้ายที่โมเดลสร้างขึ้น โดยเทียบกับคำตอบที่ถูกต้องที่เตรียมไว้ ควรมีคนตรวจสอบจริงร่วมด้วย ไม่ใช่ใช้ระบบอัตโนมัติตัดสินอย่างเดียว เพราะคำตอบที่ถูกต้องบางครั้งเขียนได้หลายแบบซึ่งระบบอัตโนมัติอาจตัดสินผิดพลาดได้ การมีคนตรวจสอบร่วมช่วยจับกรณีที่ระบบอัตโนมัติมองข้ามไป
ทีมควรเก็บบันทึกคำถามที่บอทตอบผิดหรือตอบไม่ได้ระหว่างใช้งานจริงไว้เป็นชุดข้อมูลทดสอบเพิ่มเติมอย่างต่อเนื่อง เพราะคำถามจริงจากผู้ใช้มักมีรูปแบบที่ทีมพัฒนาคาดไม่ถึงตอนออกแบบระบบครั้งแรก การนำคำถามเหล่านี้มาทดสอบซ้ำหลังปรับปรุงแต่ละครั้งช่วยยืนยันว่าการแก้ไขได้ผลจริง ไม่ใช่แค่รู้สึกว่าดีขึ้น
หลังตั้งค่า RAG แล้ว ควรดูแลอะไรต่อเนื่อง
ระบบ RAG ไม่ใช่งานที่ทำครั้งเดียวแล้วจบ เพราะข้อมูลต้นฉบับมักเปลี่ยนแปลงอยู่ตลอด ทีมควรมีกระบวนการอัปเดต Embedding เมื่อเอกสารต้นฉบับเปลี่ยน ซึ่งอธิบายไว้ในบทความ อัปเดต Embedding มือทุกคืนจนพัง แล้ว Automatic Embeddings ของ Supabase ช่วยตรงไหน เพื่อลดความเสี่ยงที่บอทจะตอบจากข้อมูลเก่าที่ไม่ตรงกับความจริงปัจจุบัน
ทีมที่ยังไม่ได้ตั้งค่าขั้นตอนดึงข้อมูลแบบผสมสองวิธี ควรอ่าน เพิ่มวิธีค้นหาเป็นสองแบบแล้ว ทำไมผลลัพธ์บางครั้งยังแย่กว่าใช้วิธีเดียว ประกอบ เพื่อลดกรณีที่บอทตอบผิดเพราะดึงข้อมูลผิดตั้งแต่ต้น ส่วนทีมที่ยังไม่คุ้นเคยกับการวัดความใกล้เคียงของเวกเตอร์ ควรอ่าน pgvector คืออะไร: ส่วนขยาย Postgres ที่ทำให้ค้นข้อมูลด้วยความหมายได้ เป็นพื้นฐานก่อนปรับแต่งระบบ RAG ต่อไป
สุดท้าย ทีมที่ต่อ RAG เข้ากับเครื่องมือพัฒนาอย่าง Claude Code เพื่อให้ Agent ช่วยเขียนหรือแก้ Pipeline ควรทบทวนเรื่องสิทธิ์การเข้าถึงข้อมูลควบคู่กันไปด้วย ตามที่อธิบายไว้ในบทความ ตั้ง Token แบบ Read Only กับแบบเขียนได้เต็มสิทธิ์ เสี่ยงต่างกันแค่ไหน เพราะระบบที่ดึงข้อมูลอัตโนมัติควรมีขอบเขตสิทธิ์ที่ชัดเจนเสมอ
สรุป
RAG ช่วยให้บอทตอบคำถามโดยอ้างอิงข้อมูลจริงจากฐานข้อมูล แทนที่จะตอบจากความรู้ที่ฝังอยู่ในโมเดลเพียงอย่างเดียว แต่คุณภาพคำตอบขึ้นอยู่กับขั้นตอนดึงข้อมูลเป็นหลัก ถ้าดึงข้อมูลผิดหรือไม่ครบ โมเดลก็ตอบผิดตามไปด้วยไม่ว่าจะใช้โมเดลรุ่นไหนก็ตาม
การออกแบบฐานข้อมูลที่เก็บข้อมูลเสริมอย่างแหล่งที่มาและเวลาที่อัปเดต ช่วยให้ตรวจสอบและปรับปรุงระบบได้ง่ายขึ้นเมื่อคำตอบผิดพลาด ควบคู่กับการวัดคุณภาพทั้งขั้นตอนดึงข้อมูลและขั้นตอนสร้างคำตอบแยกกันอย่างต่อเนื่อง ไม่ใช่วัดแค่ครั้งเดียวตอนเริ่มโปรเจกต์แล้วปล่อยผ่าน
- RAG แบ่งการทำงานเป็นขั้นตอนดึงข้อมูลและขั้นตอนสร้างคำตอบ คุณภาพคำตอบขึ้นอยู่กับขั้นตอนดึงข้อมูลเป็นหลัก
- ออกแบบตารางให้เก็บข้อมูลเสริม เช่น แหล่งที่มาและเวลาที่อัปเดต เพื่อตรวจสอบและปรับปรุงระบบได้ง่ายขึ้น
- ผสม Hybrid Search เข้ากับขั้นตอนดึงข้อมูลช่วยลดคำตอบผิดเมื่อคำถามมีคำเฉพาะเจาะจง
- วัดคุณภาพแยกสองส่วน คือความแม่นยำของการดึงข้อมูลและความถูกต้องของคำตอบสุดท้าย พร้อมเก็บคำถามที่ตอบผิดไว้ทดสอบซ้ำต่อเนื่อง
คำถามที่พบบ่อย
RAG ต้องใช้ pgvector เสมอไปไหม
ไม่จำเป็นต้องใช้ pgvector เสมอไป แต่เป็นวิธีที่สะดวกบน Supabase เพราะเก็บข้อมูลและเวกเตอร์ไว้ในฐานข้อมูลเดียวกันได้ ทีมสามารถใช้ฐานข้อมูลเวกเตอร์แยกต่างหากได้เช่นกันถ้ามีเหตุผลเฉพาะของโปรเจกต์
ทำไมบางคำถามบอทตอบว่าไม่พบข้อมูลทั้งที่มีเอกสารเกี่ยวข้องอยู่จริง
มักเกิดจากขั้นตอนดึงข้อมูลกำหนดเพดานค่าความใกล้เคียงสูงเกินไป หรือตัดส่วนย่อยเอกสารผิดจุดจนความหมายของส่วนที่เกี่ยวข้องไม่ครบ ควรตรวจสอบทั้งสองจุดนี้ก่อน
ต้องใช้โมเดลภาษาราคาแพงที่สุดถึงจะได้ RAG คุณภาพดีไหม
ไม่จำเป็น คุณภาพของ RAG ขึ้นอยู่กับขั้นตอนดึงข้อมูลเป็นหลักมากกว่าความสามารถของโมเดลภาษาเพียงอย่างเดียว หลายกรณีที่คำตอบผิดพลาดแก้ได้ด้วยการปรับปรุงขั้นตอนดึงข้อมูล โดยไม่ต้องเปลี่ยนโมเดล
ควรตัดเอกสารเป็นส่วนย่อยขนาดเท่าไรสำหรับ RAG
ไม่มีขนาดตายตัว ขึ้นอยู่กับลักษณะเนื้อหา ควรทดลองหลายขนาดแล้วดูผลการทดสอบจริงประกอบการตัดสินใจ พร้อมพิจารณาดึงส่วนย่อยที่อยู่ติดกันเพิ่มเติมเมื่อจำเป็น
RAG แก้ปัญหาโมเดลตอบข้อมูลผิดพลาดได้ทั้งหมดไหม
ไม่ได้ทั้งหมด RAG ช่วยลดปัญหาได้มากเมื่อขั้นตอนดึงข้อมูลแม่นยำและคำสั่งกำกับโมเดลชัดเจน แต่ยังมีโอกาสที่โมเดลจะตีความบริบทผิดได้อยู่บ้าง จึงควรมีขั้นตอนตรวจสอบคำตอบก่อนเปิดใช้งานในวงกว้าง
ทีมเล็กที่ไม่มีคนดูแล Infrastructure เต็มเวลาทำ RAG เองได้ไหม
ทำได้ เพราะ Supabase รวมฐานข้อมูลและ pgvector ไว้ในที่เดียวโดยไม่ต้องเปิดระบบแยก แต่ทีมยังต้องดูแลเรื่องการตัดส่วนย่อยเอกสาร การอัปเดต Embedding และการวัดคุณภาพระบบเองอยู่ดี
อ่านต่อแบบเจาะลึก
ทดลองวัดผลโฆษณาเข้า LINE ฟรี 14 วัน
สมัครแล้วสร้างโปรเจกต์ เชื่อม LINE ติดตั้ง Tracking แล้วเริ่มเห็น Funnel จาก Click ถึง Purchase ได้ทันที ไม่ต้องใช้บัตรเครดิต
เริ่มทดลองใช้ฟรี 14 วันบทความที่เกี่ยวข้อง
ไฟล์ที่อัปโหลดขึ้น Supabase Storage ไม่ได้ปลอดภัยอัตโนมัติ ต้องผูก RLS เอง
Supabase Auth คืออะไร: ออกแบบระบบล็อกอินให้ SaaS ตั้งแต่วันแรก
