ค้นด้วยคำที่พิมพ์เป๊ะไม่เจอ แต่ธุรกิจเล็กจำเป็นต้องทำ Semantic Search แล้วหรือยัง

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

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

บทความนี้จะช่วยประเมินว่าโปรเจกต์แบบไหนคุ้มค่าที่จะทำ Semantic Search แบบไหนที่ยังไม่จำเป็น แล้วถ้าตัดสินใจทำจริง ควรออกแบบตั้งแต่การเก็บ Embedding ไปจนถึงการเขียน Query ค้นหาบน Supabase อย่างไรให้ได้ผลลัพธ์ที่ใช้งานได้จริง

Semantic Search ต่างจากการค้นหาแบบข้อความปกติตรงไหน

การค้นหาแบบข้อความปกติ (Keyword Search) ทำงานโดยจับคู่คำที่ผู้ใช้พิมพ์กับคำที่มีอยู่ในข้อมูลตรง ๆ ถ้าคำไม่ตรงกัน ต่อให้ความหมายใกล้เคียงกันแค่ไหนก็หาไม่เจอ เช่น ผู้ใช้พิมพ์ 'ยกเลิกสมาชิก' แต่เอกสารใช้คำว่า 'ปิดบัญชี' การค้นหาแบบนี้จะไม่พบผลลัพธ์เลยแม้เนื้อหาจะตรงกับสิ่งที่ผู้ใช้ต้องการ

Semantic Search แก้ปัญหานี้ด้วยการแปลงทั้งคำค้นหาและข้อมูลต้นฉบับให้กลายเป็นเวกเตอร์ที่แทนความหมาย แล้วเปรียบเทียบว่าเวกเตอร์สองชุดอยู่ใกล้กันแค่ไหนในเชิงคณิตศาสตร์ ทำให้ระบบจับได้ว่า 'ยกเลิกสมาชิก' กับ 'ปิดบัญชี' มีความหมายใกล้เคียงกัน แม้ตัวอักษรจะไม่เหมือนกันเลยก็ตาม

บน Supabase การทำ Semantic Search อาศัย pgvector เป็นแกนหลัก เพราะเก็บและค้นหาข้อมูลแบบเวกเตอร์ได้ในฐานข้อมูลเดียวกับข้อมูลธุรกิจปกติ ไม่ต้องเปิดระบบฐานข้อมูลเวกเตอร์แยกต่างหาก ทำให้ทีมที่ใช้ Supabase อยู่แล้วเริ่มต้นได้เร็วกว่าการเปิดระบบใหม่ทั้งหมด

โปรเจกต์แบบไหนควรทำ แบบไหนยังไม่จำเป็น

ตารางด้านล่างช่วยประเมินคร่าว ๆ ว่าโปรเจกต์ของทีมอยู่ในกลุ่มไหน:

สัญญาณที่บอกว่าถึงเวลาต้องทำ Semantic Search แล้วจริง ๆ

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

ขั้นตอนสร้าง Semantic Search บน Supabase ตั้งแต่ต้นจนจบ

1. เปิดใช้งานส่วนขยาย pgvector ในโปรเจกต์ แล้วเพิ่มคอลัมน์ชนิดเวกเตอร์ในตารางที่เก็บข้อมูลที่ต้องการให้ค้นหาได้
2. แปลงข้อมูลต้นฉบับที่มีอยู่แล้วให้เป็น Embedding ทั้งหมด ไม่ว่าจะผ่าน Automatic Embeddings หรือเขียนสคริปต์เรียกโมเดลเองครั้งแรก
3. เขียนฟังก์ชันหรือ Edge Function ที่รับคำค้นหาจากผู้ใช้ แปลงเป็นเวกเตอร์ด้วยโมเดลตัวเดียวกับที่ใช้สร้าง Embedding ของข้อมูล
4. เขียน Query เปรียบเทียบความใกล้เคียงระหว่างเวกเตอร์คำค้นหากับเวกเตอร์ในตาราง เรียงผลลัพธ์จากใกล้เคียงมากไปน้อย แล้วจำกัดจำนวนแถวที่ดึงมาแสดง
5. ทดสอบด้วยคำถามจริงหลายรูปแบบจากผู้ใช้ตัวจริงหรือทีมงาน เพื่อดูว่าผลลัพธ์ตรงกับความตั้งใจมากน้อยแค่ไหน แล้วปรับพารามิเตอร์ตามผลทดสอบก่อนเปิดใช้งานจริง

เลือกข้อมูลส่วนไหนมาสร้าง Embedding ถึงจะได้ผลลัพธ์ที่ดี

การเลือกว่าจะแปลงข้อมูลส่วนไหนเป็นเวกเตอร์มีผลต่อคุณภาพการค้นหามาก ถ้าเอกสารยาวมากแล้วแปลงทั้งเอกสารเป็นเวกเตอร์เดียว ความหมายของแต่ละส่วนย่อยจะถูกเฉลี่ยรวมกันจนความแม่นยำลดลง หลายทีมจึงเลือกตัดเอกสารยาวออกเป็นส่วนย่อย (Chunk) ก่อนสร้าง Embedding แยกแต่ละส่วน แล้วค้นหาระดับส่วนย่อยแทนระดับเอกสารทั้งฉบับ

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

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

วัดคุณภาพผลการค้นหายังไง ไม่ใช่แค่ลองพิมพ์แล้วรู้สึกว่าดี

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

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

ข้อผิดพลาดที่พบบ่อยตอนเริ่มทำ Semantic Search

• แปลงเอกสารยาวทั้งฉบับเป็นเวกเตอร์เดียว — ทำแบบนี้แล้วพัง เพราะความหมายของแต่ละส่วนถูกเฉลี่ยรวมกัน ทำให้ผลการค้นหาไม่แม่นยำเมื่อผู้ใช้ถามเรื่องเฉพาะจุดในเอกสาร
• ไม่ตั้งเพดานค่าความใกล้เคียงขั้นต่ำ — ทำแบบนี้แล้วพัง เพราะระบบจะยัดเยียดคำตอบที่ไม่เกี่ยวข้องให้ผู้ใช้แทนที่จะบอกตรง ๆ ว่าไม่พบข้อมูล
• ใช้โมเดลคนละตัวสร้าง Embedding ของคำค้นหากับข้อมูลต้นฉบับ — ทำแบบนี้แล้วพัง เพราะเวกเตอร์จากคนละโมเดลเทียบความใกล้เคียงกันไม่ได้อย่างสมเหตุสมผล

เปิดใช้งานจริงยังไงให้ไม่กระทบระบบค้นหาเดิมที่มีอยู่แล้ว

ทีมที่มีระบบค้นหาแบบข้อความปกติทำงานอยู่แล้วไม่จำเป็นต้องปิดของเดิมทันทีแล้วเปลี่ยนมาใช้ Semantic Search ทั้งหมดในคราวเดียว วิธีที่ปลอดภัยกว่าคือเปิดใช้งานคู่ขนานกันไปก่อน แล้ววัดผลเทียบกันจริงว่าวิธีไหนตอบโจทย์ผู้ใช้ได้ดีกว่าในแต่ละสถานการณ์ ก่อนตัดสินใจว่าจะใช้วิธีไหนเป็นหลักในระยะยาว

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

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

ทำ Semantic Search แล้ว ก้าวต่อไปคืออะไร

หลายทีมพบว่า Semantic Search อย่างเดียวยังไม่ใช่คำตอบสุดท้ายเสมอไป เพราะบางกรณีผู้ใช้ต้องการค้นหาคำเฉพาะเจาะจง เช่น รหัสสินค้าหรือชื่อเฉพาะ ที่การค้นหาด้วยความหมายอาจไม่แม่นยำเท่าการจับคู่คำตรง ๆ แนวทางที่หลายทีมเลือกใช้คือผสมสองวิธีเข้าด้วยกัน ซึ่งอธิบายรายละเอียดไว้ในบทความ Supabase Hybrid Search รวม Keyword Search กับ Vector Search อย่างไร ของชุดนี้

สำหรับทีมที่อยากต่อยอดไปทำระบบตอบคำถามด้วยโมเดลภาษา ไม่ใช่แค่แสดงรายการเอกสารที่เกี่ยวข้อง สามารถอ่านต่อในบทความ สร้างระบบตอบคำถามจากเอกสารด้วย Supabase ต้องออกแบบอะไรบ้าง ส่วนทีมที่ยังไม่ได้ตั้งค่า Pipeline อัปเดต Embedding อัตโนมัติ แนะนำให้อ่าน Automatic Embeddings คืออะไร และลดงานจัดการ Vector Pipeline ได้อย่างไร ควบคู่กันไปด้วย

สรุป

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

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

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

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