ออกแบบฐานข้อมูลให้ AI Chatbot บน LINE OA ตอบจากข้อมูลจริงของร้าน ไม่ใช่เดาไปเอง

เจ้าของธุรกิจจำนวนมากอยากมี AI Chatbot บน LINE OA ที่ตอบคำถามลูกค้าได้ฉลาดเหมือนพนักงานที่รู้จักร้านดี แต่พอเริ่มลองต่อ AI เข้ากับ LINE OA ตรง ๆ โดยไม่มีข้อมูลของธุรกิจป้อนเข้าไป มักเจอปัญหาว่า AI ตอบข้อมูลทั่วไปที่ไม่ตรงกับสินค้าหรือบริการจริงของร้าน บางครั้งถึงขั้นตอบราคาหรือโปรโมชันที่ไม่มีอยู่จริง

ปัญหานี้เกิดจาก AI Model ทั่วไปถูกฝึกมาจากข้อมูลสาธารณะจำนวนมหาศาล ไม่รู้จักข้อมูลเฉพาะของธุรกิจแต่ละราย การจะทำให้ AI ตอบจากข้อมูลจริงของร้านได้ ต้องมีระบบที่ดึงข้อมูลที่เกี่ยวข้องมาป้อนให้ AI ก่อนตอบทุกครั้ง ซึ่งเป็นแนวคิดที่เรียกว่า Retrieval-Augmented Generation หรือ RAG

บทความนี้จะพาไล่ดูวิธีออกแบบฐานข้อมูลบน Supabase ให้รองรับการค้นหาแบบ Vector ควบคู่กับข้อมูลโครงสร้างปกติ และวิธีเชื่อมผลลัพธ์ที่ค้นเจอเข้ากับ LINE OA ให้ AI ตอบได้ตรงกับธุรกิจจริง โดยอ้างอิงหลักการวางระบบ Webhook พื้นฐานจาก line-webhook-vercel และการจัดการ Database บน Supabase ที่เคยพูดถึงใน line-bot-supabase

ทำไม AI Chatbot ที่ไม่มีข้อมูลของร้านถึงตอบมั่วบ่อย

AI Model ทำงานด้วยการทำนายคำถัดไปจากรูปแบบที่เรียนรู้มาจากข้อมูลจำนวนมหาศาล เมื่อถูกถามคำถามที่ไม่มีข้อมูลจริงรองรับ เช่น ราคาสินค้าของร้านใดร้านหนึ่งโดยเฉพาะ AI จะพยายามสร้างคำตอบที่ฟังดูสมเหตุสมผลจากรูปแบบที่เคยเห็น แม้ว่าคำตอบนั้นจะไม่ตรงกับความจริงเลยก็ตาม พฤติกรรมนี้เรียกว่า Hallucination

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

ทางแก้ที่ตรงจุดคือไม่ปล่อยให้ AI ตอบจากความรู้ทั่วไปเพียงอย่างเดียว แต่ต้องมีขั้นตอนค้นหาข้อมูลจริงของธุรกิจมาแนบไปกับคำถามก่อนส่งให้ AI ประมวลผล ทำให้ AI มีบริบทที่ถูกต้องเป็นฐานในการตอบ แทนที่จะเดาเอาเอง

Vector Search คืออะไร และทำไมค้นหาได้แม่นกว่าการค้นแบบ Keyword

การค้นหาแบบ Keyword ทั่วไปจะจับคู่คำที่พิมพ์ตรงกับคำที่มีในข้อมูล เช่น ถ้าลูกค้าถามว่า 'ร้านเปิดกี่โมง' แต่ข้อมูลในระบบเขียนไว้ว่า 'เวลาทำการ' การค้นแบบ Keyword อาจหาไม่เจอเพราะคำไม่ตรงกัน ทั้งที่ความหมายเหมือนกันทุกประการ

Vector Search แก้ปัญหานี้ด้วยการแปลงข้อความเป็นตัวเลขชุดหนึ่งที่เรียกว่า Embedding ซึ่งแทนความหมายของข้อความนั้นในเชิงตำแหน่งบนพื้นที่หลายมิติ ข้อความที่มีความหมายใกล้เคียงกันจะมีตำแหน่ง Embedding ใกล้กัน แม้จะใช้คำคนละคำกันก็ตาม ทำให้ค้นหาได้จาก 'ความหมาย' ไม่ใช่แค่ 'คำที่ตรงกัน'

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

ตั้งค่า pgvector บน Supabase เพื่อเก็บและค้นหา Embedding

Supabase รองรับ Extension ชื่อ pgvector ที่เพิ่มความสามารถให้ Postgres เก็บและค้นหาข้อมูลแบบ Vector ได้โดยตรง โดยไม่ต้องใช้ฐานข้อมูลแยกต่างหากสำหรับงานนี้ ทำให้ทีมที่เก็บข้อมูลธุรกิจไว้ใน Postgres อยู่แล้วสามารถเพิ่มความสามารถ Vector Search เข้าไปในระบบเดิมได้โดยไม่ต้องเพิ่ม Stack ใหม่ทั้งชุด

ขั้นตอนพื้นฐานคือเปิดใช้ Extension pgvector ในโปรเจกต์ สร้างตารางที่มีคอลัมน์เก็บ Embedding เป็นชนิดข้อมูล vector พร้อมกำหนดจำนวนมิติให้ตรงกับโมเดลที่ใช้สร้าง Embedding จากนั้นเขียนข้อมูลของธุรกิจ เช่น รายละเอียดสินค้า คำถามที่พบบ่อย หรือนโยบายร้าน ลงในตารางพร้อมกับ Embedding ของแต่ละรายการ

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

แบ่งเนื้อหาเป็นชิ้นเล็กให้ถูกวิธี ก่อนแปลงเป็น Embedding

ข้อผิดพลาดที่พบบ่อยของทีมที่เพิ่งเริ่มทำ RAG คือนำเอกสารทั้งหน้าหรือทั้งไฟล์มาแปลงเป็น Embedding เดียวก้อนใหญ่ ซึ่งทำให้การค้นหาไม่แม่นยำ เพราะ Embedding ของเนื้อหายาวมากจะเป็นค่าเฉลี่ยของหลายประเด็นปนกัน ไม่สะท้อนรายละเอียดเฉพาะจุดที่ลูกค้าถาม

วิธีที่ทำงานได้ดีกว่าคือแบ่งเนื้อหาเป็นชิ้นเล็ก ๆ ที่มีความหมายสมบูรณ์ในตัวเอง เรียกว่า Chunking เช่น แยกข้อมูลสินค้าแต่ละชิ้นเป็นหนึ่ง Chunk แยกคำถามที่พบบ่อยแต่ละข้อเป็นหนึ่ง Chunk ทำให้เมื่อค้นหา ระบบดึงมาได้เฉพาะส่วนที่ตรงกับคำถามจริง ไม่ปนข้อมูลที่ไม่เกี่ยวข้อง

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

ต่อผลลัพธ์ที่ค้นเจอเข้ากับ Prompt ก่อนส่งให้ AI ตอบ

เมื่อระบบค้นหา Chunk ที่เกี่ยวข้องกับคำถามของลูกค้าได้แล้ว ขั้นตอนถัดมาคือนำ Chunk เหล่านั้นมาใส่ไว้ใน Prompt ที่ส่งให้ AI พร้อมกับคำถามของลูกค้า โดยกำหนดชัดเจนว่าให้ AI ตอบโดยอ้างอิงจากข้อมูลที่ให้มาเท่านั้น ไม่ใช่ใช้ความรู้ทั่วไปที่อาจไม่ตรงกับธุรกิจ

การเขียน Prompt ที่ดีควรระบุด้วยว่าถ้าไม่มีข้อมูลที่เกี่ยวข้องเพียงพอ ให้ AI ตอบว่าไม่มีข้อมูลหรือแนะนำให้ติดต่อแอดมิน แทนที่จะพยายามเดาคำตอบเอง เพราะการยอมรับว่าไม่รู้ดีกว่าการตอบผิดที่อาจทำให้ลูกค้าเข้าใจผิดเกี่ยวกับสินค้าหรือบริการ

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

อัปเดตข้อมูลให้ทันเวลา เมื่อราคาหรือสต็อกสินค้าเปลี่ยน

ปัญหาที่มักถูกมองข้ามคือหลังจากตั้งระบบ RAG เสร็จแล้ว ข้อมูลในฐานข้อมูลไม่ได้อัปเดตตามการเปลี่ยนแปลงจริงของธุรกิจโดยอัตโนมัติ ถ้าราคาสินค้าเปลี่ยนหรือสินค้าหมดสต็อก แต่ไม่มีใครไปอัปเดต Chunk ที่เกี่ยวข้อง AI ก็ยังคงตอบข้อมูลเก่าต่อไปเรื่อย ๆ โดยที่ทั้ง AI และระบบไม่รู้ว่าข้อมูลนั้นล้าสมัยแล้ว

ทีมควรออกแบบกระบวนการอัปเดตข้อมูลให้เป็นส่วนหนึ่งของ Workflow ปกติ เช่น เมื่อแอดมินอัปเดตราคาสินค้าในระบบหลัก ให้มีขั้นตอนอัตโนมัติสร้าง Embedding ใหม่และแทนที่ข้อมูลเก่าในตาราง Vector ทันที แทนที่จะต้องรอให้มีคนจำได้ว่าต้องไปอัปเดตฐานข้อมูล RAG แยกต่างหากด้วยมือ

สำหรับข้อมูลที่เปลี่ยนบ่อยมาก เช่น สต็อกสินค้าแบบ Real-time อาจไม่เหมาะกับการเก็บผ่าน Vector Search โดยตรง แต่ควรออกแบบให้ AI ค้นเจอว่ามีสินค้านี้อยู่ในระบบ แล้วไปเรียก Query สต็อกปัจจุบันแยกอีกครั้งก่อนตอบ เพื่อให้ตัวเลขที่ตอบลูกค้าเป็นข้อมูลล่าสุดจริง ไม่ใช่ค่าที่ Cache ไว้นานแล้ว

เชื่อมระบบ RAG เข้ากับ LINE OA ให้ทำงานเป็นขั้นตอนเดียวกัน

เมื่อมีระบบค้นหาข้อมูลและ Prompt ที่ออกแบบไว้แล้ว ขั้นตอนสุดท้ายคือเชื่อมทั้งหมดเข้ากับ Webhook ที่รับ Event จาก LINE OA โดย Flow การทำงานโดยรวมคือรับข้อความจากลูกค้า แปลงเป็น Embedding ค้นหา Chunk ที่เกี่ยวข้อง ประกอบ Prompt ส่งให้ AI แล้วนำคำตอบที่ได้ส่งกลับไปยัง LINE OA

เพราะขั้นตอนทั้งหมดนี้ใช้เวลารวมกันหลายวินาที ทีมควรพิจารณาส่งข้อความแจ้งลูกค้าว่า 'กำลังตรวจสอบข้อมูล' ก่อนถ้าระบบต้องใช้เวลานานกว่าปกติ เพื่อไม่ให้ลูกค้ารู้สึกว่า Bot ไม่ตอบสนอง โดยเฉพาะในกรณีที่ต้อง Query ข้อมูล Real-time เพิ่มเติมนอกเหนือจากผลการค้นหาแบบ Vector

ควรมีการบันทึกคำถามของลูกค้าและคำตอบที่ AI ให้ไว้ในตาราง Log แยกต่างหาก เพื่อให้ทีมกลับมาตรวจสอบได้ว่า AI ตอบถูกต้องแค่ไหน และใช้เป็นข้อมูลปรับปรุงเนื้อหาในฐานข้อมูลต่อไป เช่น ถ้าพบว่ามีคำถามประเภทหนึ่งที่ AI ตอบไม่ได้บ่อย ๆ นั่นเป็นสัญญาณว่าควรเพิ่มข้อมูลในหัวข้อนั้นเข้าไปในระบบ

เทียบวิธีค้นหาข้อมูลแบบต่าง ๆ ที่ใช้ประกอบ RAG ได้

นอกจาก Vector Search ยังมีวิธีค้นหาอื่นที่ใช้ประกอบกันได้ตามลักษณะข้อมูล ตารางนี้สรุปจุดต่างเพื่อช่วยตัดสินใจว่าควรใช้แบบไหนสำหรับข้อมูลแต่ละประเภทของธุรกิจ:

สรุป

การทำให้ AI Chatbot บน LINE OA ตอบจากข้อมูลจริงของธุรกิจได้ ไม่ใช่แค่เรื่องเลือก AI Model ที่ดี แต่ต้องออกแบบระบบดึงข้อมูลที่ถูกต้องรองรับอยู่เบื้องหลัง ตั้งแต่การเก็บข้อมูลแบบ Vector บน Supabase การแบ่ง Chunk ที่เหมาะสม ไปจนถึงการอัปเดตข้อมูลให้ทันเวลา

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

• ใช้ pgvector บน Supabase เก็บ Embedding คู่กับข้อมูลโครงสร้างเดิมในฐานข้อมูลเดียวกัน
• แบ่งเนื้อหาเป็น Chunk เล็กที่มีความหมายสมบูรณ์ในตัวเอง ไม่ใช่แปลงทั้งเอกสารเป็นก้อนเดียว
• ออกแบบให้ AI ตอบว่าไม่มีข้อมูลได้ ดีกว่าปล่อยให้เดาคำตอบเมื่อไม่มีข้อมูลรองรับ

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