Hybrid Search (Vector + Keyword): เพื่อความแม่นยำและประสิทธิภาพในการค้นหา

---

ผมขอเริ่มจากตัวอย่างการค้นหาด้วย keyword ก่อนเช่น

“เครื่องกรองอากาศรุ่นไหนใช้ไส้กรองอะไหล่ AF-240B ได้บ้าง?”

คำถามแบบนี้ต้องใช้การค้นหาแบบ keyword ในการค้นหาครับ เพราะระบบที่ค้นหาด้วยความหมาย(vector search) ไม่สามารถเข้าใจ ความหมายของรหัสรุ่นหรือเลขรหัส ที่ไม่ได้มีความหมายได้ LLM ไม่สามารถรับรู้รหัสพิเศษนี้ได้ว่าคืออะไร ถ้าระบบไม่ให้ความสำคัญกับรหัส AF-240B มากพอ ผลลัพธ์ที่ได้ก็อาจเป็นเอกสารเกี่ยวกับไส้กรองรุ่นอื่น ซึ่งยังเป็นเรื่องเดียวกันอยู่แต่ตอบคำถามนี้ไม่ได้

กลับกัน ถ้าผู้ใช้ถามว่า “ทำยังไงให้เครื่องกรองอากาศกลับมาทำงานได้ดีขึ้น?” คำตอบอาจอยู่ในคู่มือใต้หัวข้อ “การเปลี่ยนแผ่นกรอง” โดยไม่มีคำว่า “ทำงานได้ดีขึ้น” อยู่เลย (เพราะระบบใช้ LLM model ในการค้นหาด้วยความหมาย) การค้นหาที่จับเฉพาะ keyword คำตรงๆ ก็อาจพลาดไป

นี่คือเหตุผลที่ระบบค้นหาแบบ Hybrid Search รวมการค้นหา สองแนวทางเข้าด้วยกัน:

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

ในบทความก่อนหน้า เราได้เห็นภาพรวมของการค้นหาแบบ Lexical และ Semantic แล้ว คราวนี้เราจะลงลึกคำถามสำคัญว่า ทำไม Vector Search ซึ่งดูเหมือน “เข้าใจความหมาย” ถึงยังคงไม่เพียงพอ และเราควรนำผลค้นหาทั้งสองแบบมารวมกันอย่างไรครับ

---

Vector Search เก่งเรื่องอะไร?

Vector Search เริ่มจากการแปลงข้อความให้เป็น Embedding หรือชุดตัวเลขที่แทนลักษณะเชิงความหมายของข้อความ (array of float) จากนั้นระบบเปรียบเทียบเวกเตอร์ของคำถามกับเวกเตอร์ของเนื้อหา เพื่อหาชิ้นข้อมูลที่อยู่ใกล้กันในเชิงความหมาย

สมมติในเอกสารเขียนว่า:

“พนักงานสามารถปฏิบัติงานจากที่พักได้ไม่เกินสองวันต่อสัปดาห์”

ผู้ใช้อาจถามว่า:

“บริษัทอนุญาตให้ทำงานที่บ้านกี่วัน?”

แม้คำที่ ถามจะไม่ตรงกับเอกสาร แต่ระบบ Vector ก็อาจค้นเจอได้ เพราะ “ทำงานที่บ้าน” มีความหมายใกล้กับ “ปฏิบัติงานจากที่พัก” สิ่งที่ทำให้คำสองคำนี้มีความหมายใกล้เคียงกันได้มากขนาดไหน ก็ขึ้นยู่กับ Model นั่นเองครับ

ความสามารถนี้มีประโยชน์มากกับคำถามภาษาธรรมชาติ คำพ้อง การเปลี่ยนสำนวน และคำถามที่สื่อแนวคิดเดียวกับเอกสารโดยใช้คนละคำ

แต่คำว่า “เข้าใจความหมาย” ไม่ได้แปลว่า Vector เข้าใจรายละเอียดทุกชนิดได้ดีเท่ากัน โดยเฉพาะรายละเอียดที่ความต่างเพียงตัวอักษรเดียวก็เปลี่ยนคำตอบไปคนละเรื่อง ดังนั้นในการนำข้อมูลเข้า เราจึงต้อง ควบคุม context ให้ดีครับ นี่คือศิลปะ

ขอเสริมเรื่อง floating point นี้นิดนึงนะครับ

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

โดยทั่วไปแล้ว การทำ Embedding จะนิยมใช้ความละเอียดของทศนิยมที่ ==32-bit floating point (float32)== หรือ เลขทศนิยม ประมาณ 6 - 9 ตำแหน่ง ขึ้นอยู่กับความแม่นยำ (แม่นยำที่ 7 ตำแหน่ง) แต่เพื่อช่วยประหยัดพื้นที่จัดเก็บข้อมูลและความเร็วในการค้นหาเราสามารถทำ Vector Quantization (คล้ายๆการบีบอัดลงมา)

- float16 / bfloat16 (16-bit): ใช้พื้นที่ลดลงครึ่งหนึ่ง (50%) แต่ยังคงรักษาความแม่นยำเชิงความหมายไว้ได้เกือบเท่าเดิม นิยมใช้มากในโมเดลยุคใหม่เพื่อลดการใช้หน่วยความจำ

- int8 (8-bit): เป็นการแปลงทศนิยมให้เป็นเลขจำนวนเต็ม (Quantized) ช่วยลดขนาดฐานข้อมูลลงถึง 75% และทำให้ค้นหาได้เร็วขึ้นมาก โดยแลกกับความแม่นยำที่ลดลงเล็กน้อย (ประมาณ 1-2%)

ถ้าจะให้เปรียบเทียบให้เห็นภาพ คล้ายๆกับ หน้าจอ 2k, 4k, 8k นั่นแหล่ะครับ ขนาดลงและความละเอียดลดลงและคุณภาพก็ลดลงเช่นกัน ขึ้นอยู่กับการยอมรับได้ของเราเองครับ

---

ทำไมถึงใช้ Vector Search อย่างเดียวถึงสามารถค้นหาพลาดได้?

1. การค้นหาด้วยรหัสต่างๆและคำเฉพาะบางอย่าง ที่อาจมีความหมายคล้ายกันแต่ไม่ใช่สิ่งเดียวกัน

ให้ลองพิจารณารหัสสินค้า AF-240B กับ AF-2408 หรือเลขรุ่น X100 กับ X100 Pro พวกนี้ดูคล้ายกันมากถ้ามองภาพรวม แต่ในระบบจริงมันอาจหมายถึงสินค้า คนละตัว คนละอะไหล่ หรือคนละสิทธิ์การใช้งาน

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

ข้อมูลรหัส หรือ code ที่ต้องค้นหาแบบเปรียบเทียบไม่ใช่เชิงความหมายผมหมายถึงเช่น:

• หมายเลขคำสั่งซื้อ ใบแจ้งหนี้ และ Serial Number
• ชื่อบุคคล ชื่อบริษัท และชื่อผลิตภัณฑ์
• เวอร์ชันซอฟต์แวร์ เช่น 2.10 กับ 2.1
• ตัวเลข วงเงิน วันที่ และเลขข้อในสัญญา
• ชื่อ Field, API, Error Code หรือคำศัพท์เฉพาะขององค์กร

2. ความใกล้เคียงของความหมายอาจทำให้กลบเงื่อนไขหรือบริบทที่สำคัญ

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

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

วิธีการแก้ปัญหาพวกนี้ไม่ได้มีแค่การเพิ่ม Keyword Search แต่เรายังต้องใช้ Metadata, การกรองข้อมูล บริบทหรือสิทธิของผู้ที่ถาม และการจัดการ Version ให้ถูกต้องด้วย

3. การค้นหาด้วย Vector ไม่ได้รับประกันว่าจะค้นหาเจอทุกคำที่เราต้องการ

ผลการค้นหาด้วย Vector มักเรียงลำดับตามคะแนนความคล้ายของความหมาย แล้วเราเลือกเพียงบางรายการ เช่น Top 5 หรือ Top 10 การตั้งค่า Top-K, คุณภาพของ Embedding, วิธีแบ่ง Chunk, ภาษาของข้อมูล และรูปแบบคำถาม ทุกอย่างมีผลกับผลลัพท์ที่ถูกดึงขึ้นมา

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

---

สิ่งที่ Keyword Search เข้ามาเติมช่องว่างของ Vector Search

Keyword Search หรือ Lexical Search ค้นจากคำหรือหน่วยคำที่มีในเอกสารจริง ระบบค้นหาสมัยใหม่มักใช้ Inverted Index และอัลกอริทึมจัดอันดับอย่าง BM25 ซึ่งพิจารณาปัจจัย เช่น ความถี่ของคำในเอกสาร ความหายากของคำนั้นในชุดเอกสาร และความยาวของเอกสาร

จุดแข็งของการค้นหาแบบนี้คือช่วยให้ระบบให้ความสำคัญกับคำที่เฉพาะเจาะจง เช่น AF-240B, ERR_CONNECTION_RESET หรือชื่อผลิตภัณฑ์ที่ผู้ใช้พิมพ์มา

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

สรุปอย่างง่าย:

วิธีค้นหา	มองหาอะไรเป็นหลัก	เด่นในกรณี	จุดที่อาจพลาด
Vector / Dense Retrieval	ความใกล้เคียงเชิงความหมาย	คำถามภาษาธรรมชาติ คำพ้อง และการเปลี่ยนสำนวน	รหัส ชื่อเฉพาะ ตัวเลข หรือค่าที่ต้องตรงตัว
Keyword / Lexical Retrieval	คำหรือ Token ที่ปรากฏในข้อความ	Exact term, ชื่อเฉพาะ, Error Code และรหัส	คำพ้องหรือคำถามที่ใช้ถ้อยคำต่างจากเอกสาร
Hybrid Search	ได้ผลประโยชน์จากทั้งสองวิธี	คำถามที่มีทั้งบริบทและรายละเอียดเฉพาะ, ชื่อเฉพาะ	เพิ่มความซับซ้อน และยังต้องทดสอบการจัดอันดับ ของน้ำหนักจากการค้นหาด้วยความหมายและค้นหาด้วยการเปรียบเทียบคำ

ภาพรวมนี้ ไม่ได้หมายความว่า Search Engine ทุกตัวจะทำงานเหมือนกันทั้งหมด รายละเอียดขึ้นอยู่กับ Analyzer, Tokenizer, ภาษาที่ใช้, การตั้งค่า Index และวิธีรวมผลลัพธ์

---

Hybrid Search ทำงานอย่างไร?

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

คำถามจากผู้ใช้
      │
      ├──► Vector Search ──► รายการที่ความหมายใกล้เคียง
      │
      └──► Keyword / BM25 ──► รายการที่มีคำหรือรหัสตรงกัน
                              │
                              ▼
                     รวมและจัดอันดับผลลัพธ์
                              │
                              ▼
                 ตรวจสิทธิ์ / กรอง / Rerank
                              │
                              ▼
                   ส่งหลักฐานที่เกี่ยวข้องให้ LLM

ตัวอย่างคำถาม:

“เครื่องกรองอากาศรุ่นไหนใช้ไส้กรอง AF-240B ได้บ้าง?”

• Vector Search อาจค้นหาเจอเอกสารเกี่ยวกับการเปลี่ยนไส้กรองและอุปกรณ์รุ่นที่เกี่ยวข้อง
• Keyword Search ช่วยยืนยันว่ามีรหัส AF-240B อยู่ในเอกสารใดบ้าง
• ขั้นตอนรวมผลลัพธ์ทำให้ระบบพิจารณาทั้งความเกี่ยวข้องเชิงความหมายและการตรงกับรหัส
• ก่อนส่งให้ LLM ระบบยังต้องตรวจว่าเอกสารเป็น version ปัจจุบันและผู้ใช้มีสิทธิ์เห็นข้อมูลนั้น(ไม่ใช่เอาผลการค้นหาที่เป็นรุ่นที่ยังไม่เปิดตัวหรือกำลังวิจัยอยู่ออกไป หรือเป็นความลับทางการค้าที่คนในเข้าถึงได้เท่านั้น เป็นต้น)

Hybrid Search ไม่ได้ทำให้ระบบเข้าใจคำถามทั้งหมดโดยอัตโนมัติ แต่เพิ่มโอกาสให้ Retrieval พบหลักฐานที่หลากหลายขึ้น จากนั้นยังต้องคัดเลือกหลักฐานให้เหมาะกับคำถามก่อนสร้างคำตอบ

---

รวมคะแนนอย่างไรไม่ให้ Search แบบหนึ่งครอบอีกแบบ?

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

แนวทางอาจมีสองแบบ:

1. ปรับสเกลแล้วรวมคะแนน (Score Normalization / Weighted Fusion)

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

แนวทางนี้ tune ด้วยวิธี Normalize และปรับน้ำหนักด้วยความระมัดระวัง เพราะการกระจายตัวของคะแนนเปลี่ยนได้ตามคำถาม ชุดข้อมูล และ Search Engine ที่ใช้

2. รวมอันดับด้วย Reciprocal Rank Fusion (RRF)

Reciprocal Rank Fusion (RRF) รวมผลจากหลายรายการโดยใช้ตำแหน่งของเอกสารในแต่ละ Ranking List แทนการนำคะแนนดิบจากคนละระบบมาเทียบกันโดยตรง

สูตรอย่างย่อคือ:

RRF score(document) = Σ 1 / (k + rank(document))

โดย rank(document) คือลำดับของเอกสารในผลค้นหาแต่ละชุด และ k เป็นค่าคงที่ที่ใช้ปรับน้ำหนักของอันดับ เอกสารที่ติดอันดับดี (rank สูง) ในหลายรายการมีแนวโน้มได้คะแนนรวมสูงขึ้น (คล้ายๆ page rank ของ google ที่ให้น้ำหนักจาก rank เป็นคะแนนการค้นหา)

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

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

---

ประเมินคุณภาพอย่างไรให้รู้ว่าดีขึ้นจริง?

ให้ลองเปรียบเทียบ Vector, Keyword และ Hybrid ด้วยชุดคำถามเดียวกัน โดยดูอาจจะดูจาก Benchmark ประมาณนี้ก่อนครับ:

• Recall@k: ในผลลัพธ์ k อันดับแรก มีหลักฐานที่เกี่ยวข้องติดมาหรือไม่
• MRR หรือ nDCG: หลักฐานสำคัญอยู่ในลำดับต้นๆพอในรายการจัดอันดับหรือไม่
• Evidence completeness: ข้อความที่ส่งให้ LLM มีทั้งข้อกำหนด ข้อยกเว้น และเงื่อนไขที่จำเป็นหรือไม่
• Answer correctness / groundedness: คำตอบถูกต้องและอ้างอิงจากหลักฐานที่ค้นมาได้หรือไม่
• Latency และต้นทุน: เวลาตอบและค่าใช้จ่ายเพิ่มขึ้นเท่าใด
• สิทธิ์และการกรอง: ผลค้นหายังเป็นไปตามสิทธิ์ของ user และเงื่อนไขการเข้าถึงหรือไม่

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

---

สรุป: ใช้ Vector เพื่อเข้าใจบริบท ส่วน Keyword ใช้กับข้อมูลตรงตัว

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

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

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

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