เพิ่มวิธีค้นหาเป็นสองแบบแล้ว ทำไมผลลัพธ์บางครั้งยังแย่กว่าใช้วิธีเดียว

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

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

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

Hybrid Search คืออะไร และทำไมถึงไม่ใช่แค่เอาสองระบบมาต่อกัน

Hybrid Search คือแนวทางการค้นหาที่รันสองวิธีคู่ขนานกันในคำค้นหาเดียว วิธีแรกคือ Keyword Search หรือ Full-Text Search ที่จับคู่คำในคำค้นหากับคำในเอกสารตรง ๆ ให้ผลลัพธ์แม่นยำเมื่อผู้ใช้รู้คำเฉพาะที่ต้องการอยู่แล้ว วิธีที่สองคือ Vector Search ที่เปรียบเทียบความใกล้เคียงของความหมายผ่านเวกเตอร์ ให้ผลลัพธ์ที่ครอบคลุมกว่าเมื่อผู้ใช้พิมพ์คำถามด้วยภาษาธรรมชาติที่ไม่ตรงกับคำในต้นฉบับ

จุดที่ทำให้ Hybrid Search ต่างจากการรันสองระบบแยกกันแล้วให้ผู้ใช้เลือกเองคือการรวมผลลัพธ์ทั้งสองชุดให้กลายเป็นรายการเดียวที่จัดอันดับอย่างมีเหตุผล ปัญหาคือคะแนนความเกี่ยวข้องของ Keyword Search อย่างค่า Rank จากฟังก์ชัน Full-Text Search กับคะแนนความใกล้เคียงของ Vector Search อย่างค่า Cosine Distance ไม่ได้อยู่บนมาตราส่วนเดียวกัน จะเอาคะแนนสองแบบมาบวกกันตรง ๆ ไม่ได้ เพราะตัวเลขสูงต่ำของแต่ละระบบไม่ได้แปลว่าความเกี่ยวข้องเท่ากัน

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

จุดบอดของ Keyword Search กับจุดบอดของ Vector Search เป็นคนละแบบกัน

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

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

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

รวมผลลัพธ์สองฝั่งด้วย Reciprocal Rank Fusion ทำงานยังไง

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

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

1. รันคำค้นหาเดียวกันผ่าน Full-Text Search ของ Postgres ได้รายการผลลัพธ์พร้อมอันดับชุดที่หนึ่ง
2. รันคำค้นหาเดียวกันผ่าน Vector Search ด้วย pgvector ได้รายการผลลัพธ์พร้อมอันดับชุดที่สอง
3. คำนวณคะแนน RRF ของแต่ละชิ้นจากตำแหน่งอันดับในแต่ละรายการ โดยทั่วไปใช้สูตร 1 หารด้วยค่าคงที่บวกอันดับ
4. รวมคะแนนของชิ้นข้อมูลเดียวกันที่ปรากฏในทั้งสองรายการเข้าด้วยกัน ชิ้นที่ปรากฏในทั้งสองรายการมักได้คะแนนรวมสูงกว่าชิ้นที่ปรากฏแค่รายการเดียว
5. เรียงผลลัพธ์สุดท้ายตามคะแนน RRF รวม แล้วจำกัดจำนวนแถวที่ส่งกลับไปแสดงผลให้ผู้ใช้

ทำไมรวมสองวิธีแล้วบางครั้งผลลัพธ์ยังแย่กว่าใช้วิธีเดียว

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

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

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

ตั้งค่า Hybrid Search บน Supabase ต้องเตรียมอะไรบ้าง

การตั้งค่า Hybrid Search บน Supabase ทำได้โดยไม่ต้องเปิดฐานข้อมูลแยกสองระบบ เพราะ Postgres มีทั้งฟังก์ชัน Full-Text Search ในตัวและรองรับส่วนขยาย pgvector สำหรับ Vector Search อยู่แล้ว ขั้นตอนหลักคือเตรียมคอลัมน์และดัชนีของทั้งสองฝั่งให้พร้อม แล้วเขียนฟังก์ชันหรือ Query ที่รวมผลลัพธ์ด้วยหลักการ RRF ตามที่อธิบายไปก่อนหน้า

1. เพิ่มคอลัมน์ชนิด tsvector สำหรับ Full-Text Search และคอลัมน์ชนิดเวกเตอร์สำหรับ pgvector ในตารางเดียวกัน
2. สร้างดัชนี GIN สำหรับคอลัมน์ tsvector และดัชนีที่เหมาะกับ pgvector สำหรับคอลัมน์เวกเตอร์ เพื่อให้ทั้งสองฝั่งค้นหาได้เร็ว
3. เขียนฟังก์ชันฐานข้อมูลหรือ Edge Function ที่รับคำค้นหาเดียวกัน แล้วรันทั้ง Full-Text Search และ Vector Search แยกกันภายในคำสั่งเดียว
4. คำนวณคะแนน RRF ของแต่ละชิ้นข้อมูลจากอันดับในทั้งสองรายการ แล้วรวมเป็นคะแนนสุดท้ายภายในฟังก์ชันเดียวกัน
5. ทดสอบด้วยชุดคำถามที่ครอบคลุมทั้งกรณีที่ Keyword Search ถนัดและกรณีที่ Vector Search ถนัด ก่อนเปิดใช้งานจริง

ปรับน้ำหนักระหว่าง Keyword กับ Vector ให้เหมาะกับข้อมูลของทีม

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

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

ทีมที่มีทรัพยากรพอควรพิจารณาปรับน้ำหนักแบบไม่ตายตัวตามลักษณะคำค้นหาแต่ละครั้งด้วย เช่น ถ้าคำค้นหาสั้นและมีตัวอักษรพิเศษคล้ายรหัสสินค้า ให้น้ำหนัก Keyword Search มากขึ้นเป็นพิเศษ แต่ถ้าคำค้นหายาวเป็นประโยคคำถาม ให้น้ำหนัก Vector Search มากขึ้น วิธีนี้ซับซ้อนกว่าการตั้งน้ำหนักคงที่ แต่ให้ผลลัพธ์แม่นยำกว่าในระยะยาว

ข้อผิดพลาดที่พบบ่อยตอนทำ Hybrid Search

• บวกคะแนนดิบจากสองระบบเข้าด้วยกันตรง ๆ — ทำแบบนี้แล้วพัง เพราะมาตราส่วนคะแนนของ Full-Text Search กับ Vector Search ไม่เท่ากัน ต้องใช้ตำแหน่งอันดับแบบ RRF แทน
• ให้น้ำหนักสองระบบเท่ากันโดยไม่ทดสอบก่อน — ทำแบบนี้แล้วพัง เพราะลักษณะคำค้นหาของผู้ใช้แต่ละระบบไม่เหมือนกัน ต้องทดสอบด้วยคำถามจริงก่อนตั้งน้ำหนัก
• ทดสอบด้วยคำถามภาษาธรรมชาติอย่างเดียว — ทำแบบนี้แล้วพัง เพราะไม่เห็นว่ากรณีคำค้นหาเฉพาะเจาะจงที่เคยตอบถูกแม่นด้วยวิธีเดียวอาจแย่ลงหลังผสมสองระบบ

กรณีไหนที่ Hybrid Search เกินความจำเป็น

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

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

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

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

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

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

สรุป

Hybrid Search ช่วยแก้จุดบอดของ Keyword Search และ Vector Search ที่เป็นคนละแบบกันได้จริง แต่การรวมสองระบบต้องใช้วิธีจัดอันดับร่วมที่ถูกต้องอย่าง Reciprocal Rank Fusion ไม่ใช่แค่เอาคะแนนดิบมาบวกกันตรง ๆ ไม่งั้นผลลัพธ์อาจสับสนกว่าใช้วิธีเดียวเสียอีก

บน Supabase การตั้งค่าทำได้โดยไม่ต้องเปิดฐานข้อมูลแยก เพราะ Postgres รองรับทั้ง Full-Text Search และ pgvector อยู่แล้ว แต่จุดที่ตัดสินคุณภาพจริง ๆ คือการปรับน้ำหนักระหว่างสองระบบให้เหมาะกับลักษณะคำค้นหาของผู้ใช้ และทดสอบด้วยชุดคำถามที่ครอบคลุมทั้งสองแบบก่อนเปิดใช้งานจริง

• Hybrid Search รวม Keyword Search กับ Vector Search เพื่อครอบคลุมทั้งคำค้นหาเฉพาะเจาะจงและคำถามภาษาธรรมชาติ
• ต้องใช้เทคนิคจัดอันดับร่วมอย่าง Reciprocal Rank Fusion เพราะคะแนนดิบของสองระบบอยู่คนละมาตราส่วน
• สัดส่วนน้ำหนักระหว่างสองระบบไม่มีค่าตายตัว ต้องทดสอบด้วยคำถามจริงก่อนปรับ
• ไม่ใช่ทุกโปรเจกต์ที่ต้องทำ Hybrid Search ถ้าข้อมูลน้อยและคำค้นหาเฉพาะเจาะจงอยู่แล้ว วิธีเดียวอาจเพียงพอ

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