Hybrid Search คือสถาปัตยกรรมการค้นหาที่รวมเอา Vector Search (Dense Model) และ Full-text Search (Sparse Model เช่น BM25) เข้าด้วยกัน เพื่อเสริมจุดแข็งและลดจุดอ่อนของแต่ละวิธี

ความแม่นยำของระบบ RAG (Retrieval-Augmented Generation) ขึ้นอยู่กับคุณภาพของขั้นตอนการค้นหาโดยตรง แม้ว่า Vector Search จะมีความโดดเด่นในด้านความคล้ายคลึงเชิงความหมาย (Semantic Similarity) แต่ก็มักจะเกิดปัญหาการค้นหาไม่พบในกรณีที่ต้องการการจับคู่คำสำคัญแบบตรงตัว (Keyword Exact Match) เช่น หมายเลขรุ่น, ชื่อเฉพาะ หรือโค้ดสนิปเป็ต

บทความนี้จะอธิบายความรู้ที่นำไปใช้ได้จริงอย่างเป็นระบบ ตั้งแต่กลไกของ Hybrid Search, การรวมคะแนนด้วย RRF (Reciprocal Rank Fusion), ตัวอย่างการใช้งานใน Weaviate, Qdrant, Elasticsearch และ PostgreSQL ไปจนถึงวิธีการประเมินความแม่นยำ เนื้อหานี้เหมาะสำหรับวิศวกรที่กำลังพิจารณาปรับปรุงความแม่นยำในการค้นหาของระบบ RAG และทีมงานที่กำลังเตรียมนำระบบไปใช้งานจริงในสภาพแวดล้อมการผลิต (Production)

ハイブリッド検索とは、**ベクトル検索（Dense Model）と全文検索（BM25などのSparse Model）**を組み合わせた検索手法です。ベクトル検索は意味的な類似性に、BM25はキーワードの一致にそれぞれ強みを持ちますが、単独ではカバーしきれないクエリがあります。2つを併用することで、意味的な類似性とキーワードの一致を同時に捉えられるようになります。RAGシステムの検索精度を高める上で、現在最も実用的なアプローチの一つです。

Hybrid Search (การค้นหาแบบไฮบริด) คือวิธีการค้นหาที่รวมเอา Vector Search (Dense Model) และ Full-text Search (Sparse Model เช่น BM25) เข้าด้วยกัน โดย Vector Search จะมีความโดดเด่นในด้านความคล้ายคลึงทางความหมาย (Semantic Similarity) ในขณะที่ BM25 จะมีความโดดเด่นในด้านการจับคู่คำสำคัญ (Keyword Matching) ซึ่งทั้งสองวิธีต่างก็มีข้อจำกัดในการจัดการกับ Query บางประเภทหากใช้เพียงวิธีใดวิธีหนึ่ง การใช้งานทั้งสองวิธีร่วมกันจึงช่วยให้สามารถจับคู่ได้ทั้งความคล้ายคลึงทางความหมายและการจับคู่คำสำคัญไปพร้อมกัน ซึ่งถือเป็นหนึ่งในแนวทางที่ใช้งานได้จริงมากที่สุดในปัจจุบันสำหรับการเพิ่มความแม่นยำในการค้นหาของระบบ RAG

การค้นหาแบบเวกเตอร์ (Dense Model) จะแสดงความใกล้เคียงทางความหมายผ่าน Embedding ซึ่งสามารถรองรับคำพ้องความหมายหรือการใช้คำอื่นแทนได้ อย่างไรก็ตาม การค้นหาประเภทนี้จะอ่อนแอต่อคำค้นหาที่ต้องอาศัยการตรงกันของคำศัพท์จึงจะมีความหมาย เช่น รหัสรุ่น, ชื่อเฉพาะ, หรือรหัสต่างๆ ตัวอย่างเช่น หากค้นหาคำว่า "PS-3200A" ในพื้นที่เวกเตอร์ ระบบจะให้ความสำคัญกับเอกสารที่มีความหมายใกล้เคียงกันก่อน ทำให้เอกสารที่มีรหัสรุ่นที่ถูกต้องอาจถูกกลบไป

ข้อจำกัดหลักของการค้นหาแบบเวกเตอร์

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

การค้นหาแบบเต็มรูปแบบ (Full-text search หรือ BM25) จะคำนวณคะแนนจากความถี่ของคำที่ปรากฏและความถี่ผกผันของเอกสาร โดยประเมินโดยตรงว่ามีคำหลักอยู่ในเอกสารหรือไม่ จึงมีความแข็งแกร่งในการค้นหารหัสรุ่นและชื่อเฉพาะ แต่หากคำมีรูปแบบต่างกันแม้จะมีความหมายเดียวกัน เช่น "ซื้อ" (購入する) และ "ซื้อ" (買う) ระบบก็จะไม่สามารถดึงเอกสารที่เกี่ยวข้องมาได้เลย

ข้อจำกัดหลักของการค้นหาแบบเต็มรูปแบบ (BM25)

• การรองรับคำพ้องความหมาย, การใช้คำอื่นแทน, และคำย่อ ขึ้นอยู่กับการจัดทำพจนานุกรม
• ไม่สามารถจับใจความของคำค้นหาที่ยาวได้เนื่องจากไม่ได้พิจารณาบริบท
• ในภาษาญี่ปุ่นหรือภาษาไทย คุณภาพการค้นหาจะลดลงอย่างมากหากไม่ได้ตั้งค่า analyzer/tokenizer ที่เหมาะสมสำหรับผลิตภัณฑ์นั้นๆ

การนำทั้งสองวิธีมาผสมผสานกันจะช่วยให้สามารถจับทั้งความคล้ายคลึงทางความหมายและการตรงกันของคำหลักได้พร้อมกัน หากรวมคะแนนด้วย RRF จะช่วยให้เอกสารที่เกี่ยวข้องซึ่งไม่เคยติดอันดับสูงจากการใช้วิธีใดวิธีหนึ่งเพียงอย่างเดียวสามารถถูกดึงขึ้นมาได้ และยังช่วยลดอัตราการไม่พบผลลัพธ์ (Zero-hit rate) อีกด้วย

ความแม่นยำของ RAG ขึ้นอยู่กับคุณภาพของขั้นตอนการค้นหา (Retrieval phase) เป็นอย่างมาก ไม่ว่าคุณจะใช้ LLM ที่ยอดเยี่ยมเพียงใด หากพลาดเอกสารที่เกี่ยวข้องไป คุณภาพของคำตอบก็จะลดลง การพึ่งพาเพียง Semantic search อาจทำให้เกิดการตกหล่นในกรณีที่เป็นคำค้นหาประเภท "ที่ควรตรงกันแบบตัวอักษรไม่ใช่ความหมาย" เช่น หมายเลขรุ่น (Model number) หรือคำนามเฉพาะ (Proper noun)

จุดอ่อนของ Semantic Search นั้นชัดเจน รหัสรุ่นสินค้าอย่าง "ABC-1234-X" นั้นแยกแยะออกจากรหัสที่คล้ายคลึงกันใน Embedding space ได้ยาก ส่วนชื่อเฉพาะอย่างชื่อคนหรือชื่อสถานที่มักมีค่าความหมายเวกเตอร์ที่ไม่เสถียรเนื่องจากมีความถี่ในการปรากฏต่ำ นอกจากนี้ git rebase --onto และ git rebase แม้จะมีความหมายใกล้เคียงกัน แต่การทำงานกลับแตกต่างกันอย่างสิ้นเชิง

ตัวอย่างเช่น หากสอบถาม "ข้อมูลจำเพาะของชิ้นส่วนหมายเลข XR-990" ในฐานความรู้ของบริษัท ระบบ Vector Search อาจส่งคืนเอกสารข้อมูลจำเพาะของ XR-991 หรือ XR-880 ขึ้นมาเป็นอันดับต้นๆ ซึ่งถือเป็นเรื่องร้ายแรงในอุตสาหกรรมการผลิตหรืออุปกรณ์ทางการแพทย์ที่เพียงแค่ตัวอักษรของรหัสรุ่นต่างกันเพียงตัวเดียว ก็อาจทำให้ข้อมูลจำเพาะเปลี่ยนไปโดยสิ้นเชิง

BM25 คำนวณคะแนนโดยใช้ความถี่ของโทเค็นและค่า IDF (Inverse Document Frequency) รหัสรุ่นสินค้าและชื่อเฉพาะมักมีความถี่ในการปรากฏต่ำในคลังข้อมูลทั้งหมด ทำให้ค่า IDF สูงขึ้นและส่งผลให้คะแนน BM25 เพิ่มขึ้นอย่างมาก หากนำ Hybrid Search มาใช้ จะสามารถแบ่งหน้าที่กันได้โดย "ใช้ BM25 ในการค้นหารหัสรุ่น และใช้ Vector Search ในการเสริมบริบท" โดยเฉพาะในระบบที่ความถูกต้องของสตริงส่งผลต่อคุณภาพ เช่น การค้นหาคู่มือผลิตภัณฑ์ ฐานข้อมูลกฎหมาย และเอกสาร API ควรพิจารณาการรวม Full-text search เข้าไปเป็นลำดับความสำคัญแรกๆ

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

• การปะปนของเอกสารที่คล้ายคลึงกัน: เมื่อสอบถามเกี่ยวกับ "สเปกของผลิตภัณฑ์ A" แต่ระบบกลับดึง "สเปกของผลิตภัณฑ์ B" ขึ้นมาเป็นอันดับต้นๆ ทำให้ LLM แสดงผลเลขรุ่นหรือสเปกที่ผิดพลาด
• ความสับสนของเวอร์ชัน: บันทึกการเปลี่ยนแปลง (Release Notes) ของ v2.1 และ v2.0 มักจะอยู่ใกล้กันในพื้นที่เวกเตอร์ (Embedding Space) ทำให้ยากต่อการแยกแยะคะแนนการค้นหา แม้ว่าจะมีการอ้างอิงข้อมูลเวอร์ชันเก่าก็ตาม
• การมองข้ามเงื่อนไขปฏิเสธหรือข้อยกเว้น: คำว่า "ไม่สามารถ..." หรือ "ยกเว้น..." มักไม่ถูกสะท้อนออกมาในเวกเตอร์ความหมาย ทำให้เอกสารเชิงยืนยันมักถูกจัดลำดับความสำคัญสูงกว่า

BM25 จะให้คะแนนจากการจับคู่คำศัพท์โดยตรง จึงมีความแม่นยำสูงกว่าการค้นหาด้วยเวกเตอร์ในส่วนของเลขรุ่น หมายเลขเวอร์ชัน และคำเฉพาะ (Proper Nouns) การใช้เพียงการค้นหาเชิงความหมายอย่างเดียวมีความเสี่ยงที่ LLM จะสร้างข้อมูลเท็จที่ดูน่าเชื่อถือโดยอ้างอิงจากเอกสารที่ "เกี่ยวข้องแต่ไม่ถูกต้อง" ดังนั้น การค้นหาแบบไฮบริด (Hybrid Search) จึงเป็นวิธีที่มีประสิทธิภาพในการลดความเสี่ยงนี้ในเชิงโครงสร้าง

วิธีทำให้ Vector Database และ BM25 Index อยู่ร่วมกันได้ รวมถึงการออกแบบ Chunk Size และ Embedding Model หากไม่กำหนดสองประเด็นนี้ให้ชัดเจนตั้งแต่ต้น มักจะนำไปสู่การทำ Refactoring ครั้งใหญ่ในขั้นตอนการรวมระบบ ต่อไปนี้คือคำอธิบายรายละเอียดของแต่ละประเด็น

จุดตัดสินใจแรกคือการเลือกโครงสร้างพื้นฐาน (Infrastructure) หากต้องการให้การค้นหาแบบเวกเตอร์ (Vector search) และการค้นหาด้วยคำสำคัญ (Keyword search) ทำงานบนระบบเดียวกัน คุณต้องเลือกระหว่างแพลตฟอร์มที่มีทั้งสองฟังก์ชันในตัว หรือใช้เครื่องมือเฉพาะทางร่วมกัน

• Weaviate: รองรับทั้ง keyword search (BM25F) และ vector index ภายในคอลเลกชันเดียว รองรับ hybrid query เป็นฟังก์ชันหลัก (first-class support) ไม่จำเป็นต้องใช้บริการภายนอกเพิ่มเติม ช่วยลดต้นทุนการดำเนินงาน
• Qdrant: จัดเก็บทั้ง Dense vectors และ sparse named vectors ไว้ในคอลเลกชันเดียว โดยฝั่ง sparse สามารถแสดงผลได้ตั้งแต่การค้นหาแบบ classic BM25 ไปจนถึง learned sparse retrieval อย่าง SPLADE และสามารถรวมผลลัพธ์แบบ hybrid ได้ที่ฝั่งเซิร์ฟเวอร์ผ่าน Query API
• Elasticsearch: BM25 มีความเสถียรสูง ในเวอร์ชันปัจจุบันรองรับ vector search แบบเนทีฟ และมีฟังก์ชันมาตรฐานสำหรับการทำ hybrid search ผ่าน RRF และการรวมเชิงเส้น (linear combination)
• PostgreSQL (pgvector + tsvector): ช่วยให้ทำ hybrid search บนโครงสร้างพื้นฐานเดิมได้ โดยมี Supabase ให้คำแนะนำอย่างเป็นทางการ ช่วยให้ไม่ต้องเพิ่ม Vector DB เฉพาะทางเข้ามา

จุดที่ควรคำนึงถึงในการออกแบบระบบที่ใช้งานร่วมกัน

• เนื่องจาก vector index และ keyword index ถูกสร้างแยกกันสำหรับเอกสารชุดเดียวกัน จึงจำเป็นต้องมีกลไกที่ทำให้ จังหวะการอัปเดตอินเด็กซ์ตรงกัน
• การตั้งค่า analyzer/tokenizer สำหรับฟิลด์ข้อความที่ใช้ค้นหาด้วยคำสำคัญมีผลโดยตรงต่อคุณภาพการค้นหา (โดยเฉพาะในสภาพแวดล้อมภาษาญี่ปุ่น)
• หากเป็นการสร้างระบบใหม่ (Greenfield) การใช้ Weaviate หรือ Qdrant จะช่วยให้การออกแบบระบบทำได้ง่ายขึ้น แต่หากมี Elasticsearch ใช้งานอยู่แล้ว การใช้ฟีเจอร์ hybrid แบบเนทีฟจะช่วยลดต้นทุนในการย้ายระบบได้มากกว่า

การเปลี่ยนขนาด Chunk และ Embedding model ในภายหลังมีค่าใช้จ่ายในการทำ Re-indexing สูง ดังนั้นการกำหนดนโยบายให้ชัดเจนตั้งแต่ต้นจึงเป็นเรื่องสำคัญ

แนวทางการออกแบบขนาด Chunk

• Chunk ขนาดสั้น (128–256 tokens): เหมาะสำหรับการดึงข้อมูลเฉพาะจุด เข้ากันได้ดีกับ BM25 และช่วยเพิ่มอัตราการค้นหาด้วยคำสำคัญ (Keyword hit rate)
• Chunk ขนาดยาว (512–1024 tokens): เหมาะสำหรับข้อความอธิบายหรือคู่มือการใช้งานที่ต้องการความต่อเนื่องของบริบท ช่วยให้ค่าความคล้ายคลึงเชิงความหมาย (Semantic similarity) ของการค้นหาด้วยเวกเตอร์มีความเสถียรมากขึ้น
• วิธีการ Sliding window: การกำหนดให้มีส่วนที่ซ้อนทับกัน (Overlap) ระหว่าง Chunk ประมาณ 50–100 tokens จะช่วยลดการสูญเสียข้อมูลที่อยู่บริเวณรอยต่อได้

สำหรับคู่มือทางเทคนิคหรือเอกสารข้อกำหนด มักนิยมใช้ขนาดประมาณ 256–512 tokens อย่างไรก็ตาม เนื่องจากค่าที่เหมาะสมที่สุดจะแตกต่างกันไปตามลักษณะของเอกสารและกรณีการใช้งาน (Use case) การเตรียมตัวเลือกไว้ 2–3 รูปแบบแล้วนำมาเปรียบเทียบตรวจสอบด้วย Recall@K จึงเป็นวิธีที่ใช้งานได้จริงมากกว่า

ประเด็นการเลือก Embedding model

• การรองรับหลายภาษา: หากเอกสารประกอบด้วยภาษาญี่ปุ่นหรือภาษาไทย ควรเลือกโมเดลที่รองรับหลายภาษา (เช่น multilingual-e5, Gemini Embedding 2) เนื่องจากโมเดลที่รองรับเฉพาะภาษาอังกฤษมักมีความแม่นยำในการแสดงผลข้อความภาษาอื่นต่ำ
• จำนวนมิติและต้นทุน: จำนวนมิติจะแตกต่างกันไปตามแต่ละโมเดล (เช่น Gemini Embedding 2 มีค่าเริ่มต้นที่ 3072 มิติ และสามารถลดขนาดลงได้) ควรเลือกให้สมดุลระหว่างพื้นที่จัดเก็บ (Storage), ความหน่วง (Latency) และความแม่นยำตามความต้องการ
• ความเหมาะสมกับโดเมน: ในสาขาที่มีศัพท์เฉพาะทางจำนวนมาก โมเดลที่ปรับแต่งมาเฉพาะทาง (Domain-specific model) มักจะให้ความแม่นยำในการค้นหาที่ดีกว่า

เนื่องจากขนาด Chunk และ Embedding model มีผลกระทบต่อกันและกัน การประเมินผลทั้งสองส่วนควบคู่กันไปจึงเป็นสิ่งที่ขาดไม่ได้

เนื่องจากคะแนนของเวกเตอร์ค้นหา (Vector Search) และ BM25 มีหน่วยที่แตกต่างกัน การนำมาบวกกันโดยตรงจึงไม่ให้ผลลัพธ์ที่มีความหมาย วิธีแก้ปัญหานี้คือ RRF (Reciprocal Rank Fusion) โดย RRF จะใช้ "อันดับ" (Rank) แทนค่าสัมบูรณ์ของคะแนนในการรวมผลลัพธ์ ทำให้สามารถผสานผลลัพธ์จากวิธีการค้นหาที่แตกต่างกันได้อย่างเสถียร

RRF จะคำนวณคะแนนของแต่ละเอกสารด้วยสูตร Σ 1/(k + rank_i) โดยที่ rank_i คืออันดับในวิธีการค้นหาที่ i และ k คือค่าคงที่สำหรับการปรับให้เรียบ (smoothing constant) ค่าเริ่มต้นของ k จะแตกต่างกันไปตามแต่ละผลิตภัณฑ์ โดย Elasticsearch ใช้ 60, Qdrant ใช้ 2 และตัวอย่างอย่างเป็นทางการของ Supabase ใช้ 50

ตัวอย่างเช่น หากกำหนดให้ k=60 และเอกสารหนึ่งได้อันดับที่ 1 จากการค้นหาด้วยเวกเตอร์ (Vector Search) และอันดับที่ 3 จาก BM25 คะแนนจะเป็น 1/61 + 1/63 ≈ 0.0323 ในขณะที่อีกเอกสารหนึ่งได้อันดับที่ 5 จากเวกเตอร์และอันดับที่ 2 จาก BM25 คะแนนจะเป็น 1/65 + 1/62 ≈ 0.0315 ส่งผลให้เอกสารแรกถูกแสดงผลในอันดับที่สูงกว่า

แนวทางการปรับค่า k

• การลดค่า k จะทำให้คะแนนกระจุกตัวอยู่ที่อันดับต้นๆ มากขึ้น ส่วนการเพิ่มค่า k จะช่วยลดผลกระทบจากความแตกต่างของอันดับ
• โดยทั่วไปควรตรวจสอบค่าเริ่มต้นของแพลตฟอร์มที่ใช้งาน และปรับค่าโดยพิจารณาจาก Recall@K หรือ MRR

การขยายไปสู่ Weighted RRF (RRF แบบถ่วงน้ำหนัก)

นอกจากนี้ยังสามารถขยายผลโดยการคูณน้ำหนักให้กับวิธีการค้นหาแต่ละแบบได้ เช่น α × 1/(k + rank_เวกเตอร์) + β × 1/(k + rank_BM25) ซึ่งหากเป็นเอกสารทางเทคนิคที่มีหมายเลขรุ่นจำนวนมาก สามารถเพิ่มค่า β ให้สูงขึ้นได้ หรือหากเป็น FAQ เชิงแนวคิดก็สามารถเพิ่มค่า α ให้สูงขึ้นได้ ทั้งนี้ การปรับค่า α และ β ให้รวมกันได้ 1 จะช่วยให้การตั้งค่าเกณฑ์ (threshold) มีความเสถียรมากขึ้น ขอแนะนำให้กำหนดค่าที่แน่นอนโดยการประเมินแบบออฟไลน์ (offline evaluation) โดยใช้ชุดข้อมูลทดสอบมาตรฐาน (golden set)

主要プラットフォームはそれぞれ異なるアプローチでハイブリッド検索をサポートしている。

Weaviate — hybrid クエリで keyword search (BM25F) とベクトル検索を単一 API から実行。alpha (0〜1、0=pure keyword、1=pure vector) で比重を調整する。融合方式は Relative Score Fusion (v1.24 以降の既定) と Ranked Fusion (1/(rank+60) の順位ベース融合) の 2 種類が選択可能。日本語には gse や kagome_ja など CJK 向け tokenization を設定する必要がある。

Qdrant — prefetch + fusion で dense vectors と sparse vectors のハイブリッド検索を実装。sparse 側は classic BM25 ベースの検索から SPLADE 等の learned sparse retrieval まで対応し、RRF と Distribution-Based Score Fusion がサーバーサイドで選択可能。RRF の定数 k の既定値は 2 (Elasticsearch の 60 とは異なる)。

Elasticsearch — ネイティブのハイブリッド検索をサポート。retriever API で RRF と線形結合の両方が標準機能として提供されている (8.14 で追加、8.16 で GA)。既存インフラの BM25 チューニング知見をそのまま活かせる点が強み。日本語には kuromoji analyzer、タイ語には thai analyzer や ICU tokenizer が利用可能。

PostgreSQL / Supabase — pgvector + tsvector/tsquery で実装可能。Supabase が公式にハイブリッド検索を案内しており、GIN インデックス (全文検索) と HNSW (ベクトル検索) を併用するサンプルを提供している。RRF は SQL 関数で実装する形になる。

いずれも仕様変更が頻繁なため、実装前に最新ドキュメントを確認すること。

RRF คือ "การรวมอันดับ" (Reciprocal Rank Fusion) ซึ่งไม่ได้วัดความสอดคล้องเชิงความหมายระหว่างคิวรีและเอกสารโดยตรง ดังนั้น การเพิ่ม Reranking model เข้าไปในขั้นตอนหลังจึงเป็นโครงสร้างที่นิยมใช้กันอย่างแพร่หลาย

โครงสร้างไปป์ไลน์ทั่วไป

• ขั้นตอนที่ 1 (Retrieve): ดึงข้อมูล Top-50 ถึง 100 รายการด้วย Hybrid Search
• ขั้นตอนที่ 2 (Rerank): ให้คะแนนคู่ของคิวรีและเอกสารแต่ละฉบับด้วย Cross-Encoder
• ขั้นตอนที่ 3 (Generate): ส่งข้อมูล 3 ถึง 10 อันดับแรกไปให้ LLM ในฐานะบริบท (Context)

Cross-Encoder จะทำการเข้ารหัสคิวรีและเอกสารพร้อมกันเพื่อส่งออกคะแนนความเกี่ยวข้อง แม้จะมีต้นทุนการคำนวณสูงกว่าการค้นหาด้วยเวกเตอร์แบบ Bi-Encoder แต่ให้ความแม่นยำที่เหนือกว่า และหากนำมาใช้ในขั้นตอนหลังจากการคัดกรองตัวเลือกแล้ว จะสามารถรักษาค่า Latency ให้อยู่ในระดับที่ยอมรับได้

ตัวเลือกที่เป็นที่นิยม ได้แก่ Cohere Rerank API (รองรับหลายภาษา/คลาวด์), bge-reranker-v2-m3 (รองรับหลายภาษา/OSS) และ cross-encoder/ms-marco-MiniLM (ภาษาอังกฤษ/น้ำหนักเบา) สำหรับ RAG หลายภาษา ขอแนะนำให้ประเมินความแม่นยำในภาษาเป้าหมายด้วย Golden Set ล่วงหน้า ทั้งนี้ เมื่อเพิ่มการทำ Reranking ควรระมัดระวังเรื่อง Latency ที่เพิ่มขึ้น และควรใช้การประมวลผลแบบอะซิงโครนัส (Asynchronous) หรือการทำ Cache เพื่อรักษา Throughput ไว้

การเร่งรีบในการนำไปใช้งานจริงมักนำไปสู่กับดักที่ไม่คาดคิด หากตั้งค่าวิธีการรวมคะแนน (Score integration) หรือการประมวลผลภาษาผิดพลาด อาจส่งผลให้ความแม่นยำต่ำกว่าการใช้รูปแบบการค้นหาแบบเดี่ยวได้ การทำความเข้าใจประเด็นเหล่านี้ตั้งแต่ขั้นตอนการออกแบบจะช่วยลดการทำงานซ้ำซ้อนลงได้อย่างมาก

ข้อผิดพลาดในการนำไปใช้งานที่พบบ่อยที่สุดคือ การรวมคะแนนโดยไม่ปรับสเกล (Scale) ให้เท่ากัน

คะแนนฝั่ง Vector Search มีความหมายแตกต่างกันไปตามเอนจินหรือฟังก์ชันระยะทางที่ใช้ เช่น Cosine similarity / Cosine distance / คะแนนที่แปลงภายใน (โดยที่ค่า Cosine similarity ทางคณิตศาสตร์จะมีค่าตั้งแต่ -1 ถึง 1) ในขณะที่คะแนนของ BM25 ก็มีช่วงค่าที่ผันผวนอย่างมากตามขนาดของชุดเอกสารและความยาวของข้อความ ซึ่งอาจสูงถึงหลักสิบหรือหลักร้อย หากนำมาบวกกันโดยตรงในสภาพนี้ ฝั่ง BM25 จะเป็นตัวกำหนดผลลัพธ์ และทำให้ประโยชน์ของ Semantic Search แทบจะเป็นศูนย์

รูปแบบที่มักพบเป็นอาการ:

• Chunk สั้นๆ ที่มีคำสำคัญ (Keyword) จะครองอันดับต้นๆ ในขณะที่ Chunk ยาวที่มีความเกี่ยวข้องทางบริบทสูงกลับหลุดจากอันดับ
• ผลลัพธ์อันดับต้นๆ เปลี่ยนไปอย่างมากเพียงแค่เปลี่ยนการใช้คำใน Query เล็กน้อย
• พบได้ชัดเจนเป็นพิเศษในการใช้งานที่รวมคะแนนด้วย Weighted Sum โดยไม่ใช้ RRF

หากเลือกใช้ RRF จะช่วยลดขั้นตอนการทำ Normalization ได้ แต่หากต้องการใช้ประโยชน์จากความมากน้อยของคะแนน การทำ Linear Combination พร้อมกับการทำ Normalization อย่างชัดเจนจะเป็นทางเลือกที่ใช้งานได้จริงมากกว่า การสร้างนิสัยในการบันทึก Log และทำ Visualization ของการกระจายตัวของคะแนนทั้งสองฝั่งในช่วงพัฒนา จะช่วยให้ค้นพบความคลาดเคลื่อนได้ตั้งแต่เนิ่นๆ

キーワード検索側のanalyzer/tokenizerが原因で、検索精度が大きく低下するケースがある。英語を前提としたBM25実装は空白区切りでトークン分割を行うため、日本語やタイ語のように単語間にスペースがない言語では正しく分割されない。

よく起きる問題

• 日本語で「自然言語処理」を検索すると、適切なtokenizationなしでは1トークンとして扱われ、部分一致が機能しない
• タイ語は単語境界の検出に専用の処理が必要だが、デフォルト設定では無視される
• 英語・日本語・タイ語が混在するドキュメントでは言語ごとにトークン粒度が異なり、スコア比較が不公平になる

プラットフォーム別の対処

• Elasticsearch / OpenSearch: 日本語にkuromoji analyzer、タイ語にthai analyzerやICU tokenizerが標準提供されている。言語ごとにフィールドマッピングを分ける設計を推奨する
• Weaviate: CJK言語向けにgseやkagome_jaなどのtokenizationオプションを提供している。デフォルトでは日本語の分割精度が落ちるため、設定変更が必要である
• PostgreSQL / Supabase: PGroongaが日本語・中国語などCJK言語に対応している。pg_bigmによるbigramインデックスも選択肢となる

多言語ドキュメントが混在する場合は言語検出ステップを挟み、言語ごとに異なるanalyzerを適用する。ベクトル検索側は多言語対応エンベディングモデルで言語差を吸収できるが、キーワード検索側はanalyzer/tokenizerの設定を製品ごとに確認・設計しなければ精度が担保されない。

การนำ Hybrid Search มาใช้จะไม่สามารถสร้างวงจรการปรับปรุง (Improvement Cycle) ได้เลย หากไม่มีการตรวจสอบเชิงปริมาณว่าความแม่นยำดีขึ้นจริงหรือไม่ ความรู้สึกส่วนตัวที่ว่า "รู้สึกว่าดีขึ้น" ไม่สามารถนำมาใช้เป็นเกณฑ์ตัดสินสำหรับการใช้งานจริงได้ ดังนั้น การทดสอบแบบ Regression Test โดยใช้ Recall@K, MRR, NDCG และ Golden Set จึงเป็นสิ่งจำเป็นพื้นฐาน

Recall@K — วัดว่ามีเอกสารที่ถูกต้องรวมอยู่ในผลลัพธ์ K อันดับแรกกี่รายการ ใน RAG จะใช้เพื่อตรวจสอบว่า "มีการตกหล่นหรือไม่" โดยทั่วไปในทางปฏิบัติจะใช้ K=5 หรือ K=10

MRR (Mean Reciprocal Rank) — ค่าเฉลี่ยของส่วนกลับของอันดับที่ผลลัพธ์ที่ถูกต้องปรากฏขึ้นเป็นครั้งแรก หากอยู่อันดับที่ 1 จะได้ 1.0 หากอยู่อันดับที่ 3 จะได้ 0.33 มีประสิทธิภาพในการประเมินคุณภาพของผลลัพธ์ที่ผู้ใช้เห็นเป็นอันดับแรก และเหมาะกับ RAG รูปแบบแชทบอท

NDCG — ดัชนีที่สามารถให้คะแนนความเกี่ยวข้องแบบเป็นระดับได้ (ตรงทั้งหมด/ตรงบางส่วน/ไม่เกี่ยวข้อง) ยิ่งเอกสารที่มีความเกี่ยวข้องสูงอยู่ในอันดับต้นๆ คะแนนก็จะยิ่งสูง เนื่องจากมีต้นทุนในการทำ Labeling สูง จึงแนะนำให้ประเมินอย่างรวดเร็วด้วย Recall@K และ MRR ก่อน แล้วค่อยเจาะลึกด้วย NDCG เมื่อผลลัพธ์ความแม่นยำใกล้เคียงกัน

ในทางปฏิบัติ จะเปรียบเทียบ 3 เงื่อนไข ได้แก่ Vector Search เพียงอย่างเดียว, BM25 เพียงอย่างเดียว และ Hybrid โดยใช้ชุดทดสอบเดียวกัน เพื่อยืนยันระดับการปรับปรุงเป็นตัวเลข จุดสำคัญคือการแบ่งบทบาทของแต่ละดัชนีในการตีความ โดย Recall@K ใช้สำหรับตรวจจับ "การตกหล่น" และ MRR ใช้สำหรับตรวจสอบ "ความแม่นยำในอันดับต้นๆ"

Golden Set คือชุดข้อมูลทดสอบที่กำหนดขึ้นโดยมนุษย์ ซึ่งประกอบด้วยคู่ของ "Query" และ "Expected Answer Document" โดยควรเริ่มต้นที่จำนวนอย่างน้อย 50-100 รายการ

จุดสำคัญในการสร้าง

• Coverage: ต้องครอบคลุมทั้ง Keyword-matching query และ Semantic query
• Difficulty Distribution: ใส่กรณีที่เป็นขอบเขต (Edge cases) เช่น คำพ้องความหมาย, คำย่อ, หรือการผสมผสานหลายภาษาเข้าไปด้วย
• Domain Representativeness: การดึงข้อมูลจาก Log การใช้งานจริงหรือประวัติการสอบถามของผู้ใช้จะช่วยให้ได้ระดับความยากที่สมจริง

การรวมเข้ากับ CI/CD

Golden Set ควรได้รับการจัดการเวอร์ชันเช่นเดียวกับโค้ด และนำไปรวมไว้ในขั้นตอนการทดสอบของ CI/CD Pipeline ทุกครั้งที่มีการเปลี่ยนขนาด Chunk หรืออัปเดตโมเดล ระบบจะคำนวณค่า Recall@K และ MRR โดยอัตโนมัติเพื่อเปรียบเทียบกับเวอร์ชันก่อนหน้า หากตัวชี้วัดลดลงเกินกว่าที่กำหนด จะทำการบล็อกการ Merge ทันที

เนื่องจากป้ายกำกับคำตอบที่ถูกต้อง (Answer labels) อาจล้าสมัยเมื่อมีการอัปเดตเอกสาร จึงแนะนำให้สร้าง Feedback loop เพื่อรวบรวมกรณีที่การค้นหาล้มเหลวจาก Log การใช้งานจริงโดยอัตโนมัติ และนำมาเพิ่มลงใน Golden Set อย่างสม่ำเสมอ

ハイブリッド検索は検索層の基盤技術だが、フラットなドキュメント検索だけでは対応しきれない複雑なクエリも存在する。

**GraphRAG**はナレッジグラフと組み合わせるアプローチだ。ハイブリッド検索でヒットしたチャンクから固有名詞を抽出してグラフ上のノードに紐付け、「製品X → 関連規格 → 適用地域」のように複数ホップ先の情報まで横断取得できる。Neo4jやAmazon Neptuneをグラフ層に、QdrantやWeaviateをベクトル層に置き、並列で呼び出す設計が現実的だ。

**Agentic RAG**はマルチステップ推論エージェントにハイブリッド検索を組み込むアプローチだ。エージェントが質問を分解し、固有名詞を含むサブクエリはキーワード検索主体、概念的なサブクエリはベクトル検索主体でalphaを動的に切り替える。LangGraphやLlamaIndex Workflowsでハイブリッド検索ノードを独立したステートとして定義すると、リトライや分岐処理が容易になる。

ただし、複雑化するほど運用コストも増す。多くの場合、まずはシンプルなハイブリッド検索で精度の天井を確認してから段階的に拡張するアプローチが採用されている。

การค้นหาแบบไฮบริด (Hybrid Search) มีค่าใช้จ่ายสูงขึ้นหรือไม่?

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

การใช้งานบนคลาวด์และแบบ On-premise แตกต่างกันหรือไม่?

แตกต่างกัน บนคลาวด์จะมีบริการอย่าง Azure AI Search หรือ Amazon OpenSearch Service ที่รองรับการค้นหาแบบไฮบริดรวมถึง RRF ในระดับ API ทำให้ภาระในการจัดการโครงสร้างพื้นฐานมีน้อย และการขยายระบบ (Scale-out) จะเป็นหน้าที่ของผู้ให้บริการ ส่วนการใช้งานแบบ On-premise มักจะเป็นการโฮสต์ Qdrant หรือ Elasticsearch ด้วยตนเอง ซึ่งทั้งสองระบบมีฟังก์ชันการรวมคะแนน (Score Fusion) ฝั่งเซิร์ฟเวอร์มาให้ ทำให้ไม่จำเป็นต้องพัฒนาทุกอย่างในระดับแอปพลิเคชัน อย่างไรก็ตาม หากมีข้อกำหนดด้านกฎระเบียบที่ไม่สามารถนำข้อมูลออกไปภายนอกได้ (เช่น ภาคการเงิน การแพทย์ หรือหน่วยงานรัฐ) การใช้งานแบบ On-premise จะเป็นสิ่งที่จำเป็นอย่างยิ่ง

Hybrid Search เป็นแนวทางปฏิบัติที่นำ Vector Search และ BM25 มาผสมผสานกัน เพื่อครอบคลุมคำค้นหาที่อาจตกหล่นหากใช้วิธีใดวิธีหนึ่งเพียงอย่างเดียว โดยสามารถรองรับได้ทั้งกรณีที่ต้องการการจับคู่คำสำคัญ (Keyword matching) เช่น หมายเลขรุ่น, ชื่อเฉพาะ, และโค้ดสคริปต์ (Code snippet) รวมถึงกรณีที่ต้องการค้นหาเอกสารจากความใกล้เคียงทางความหมาย (Semantic proximity)

สรุปประเด็นสำคัญจากบทความนี้:

• ขั้นตอนการออกแบบ: การเลือก Vector DB, ขนาดของ Chunk และ Embedding model ให้เหมาะสมตั้งแต่ต้น คือรากฐานของความแม่นยำ
• การรวมคะแนน (Score integration): RRF เป็นวิธีที่นำไปใช้งานได้ง่ายและให้ผลลัพธ์ที่ดี แต่ต้องตรวจสอบค่าเริ่มต้นของ k ในแต่ละแพลตฟอร์มเนื่องจากมีความแตกต่างกัน
• การรองรับหลายภาษา: ความไม่สอดคล้องกันของ Analyzer/Tokenizer ในภาษาญี่ปุ่น ภาษาไทย และภาษาอื่นๆ เป็นสาเหตุหลักที่ทำให้ความแม่นยำลดลง
• การออกแบบการประเมินผล: ควรตรวจสอบคุณภาพอย่างต่อเนื่องด้วย Recall@K, MRR และชุดข้อมูลมาตรฐาน (Golden set)

สำหรับการพัฒนาในขั้นต่อไป การขยายไปสู่ GraphRAG หรือ Agentic RAG เป็นสิ่งที่น่าสนใจ แต่ในทางปฏิบัติควรเริ่มจากการยกระดับความแม่นยำด้วย Hybrid Search แบบเรียบง่ายก่อนแล้วจึงค่อยๆ พัฒนาต่อยอดไป การลดอาการหลอน (Hallucination) และการปรับปรุงคุณภาพคำตอบนั้นทำได้ยากหากไม่มีการปรับปรุงในส่วนของชั้นการค้นหา (Search layer) ดังนั้น ขอให้มองว่าการนำ Hybrid Search มาใช้เป็นจุดเริ่มต้นของวงจรการปรับปรุงคุณภาพของ RAG โดยรวม