
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" ในพื้นที่เวกเตอร์ ระบบจะให้ความสำคัญกับเอกสารที่มีความหมายใกล้เคียงกันก่อน ทำให้เอกสารที่มีรหัสรุ่นที่ถูกต้องอาจถูกกลบไป
ข้อจำกัดหลักของการค้นหาแบบเวกเตอร์
การค้นหาแบบเต็มรูปแบบ (Full-text search หรือ BM25) จะคำนวณคะแนนจากความถี่ของคำที่ปรากฏและความถี่ผกผันของเอกสาร โดยประเมินโดยตรงว่ามีคำหลักอยู่ในเอกสารหรือไม่ จึงมีความแข็งแกร่งในการค้นหารหัสรุ่นและชื่อเฉพาะ แต่หากคำมีรูปแบบต่างกันแม้จะมีความหมายเดียวกัน เช่น "ซื้อ" (購入する) และ "ซื้อ" (買う) ระบบก็จะไม่สามารถดึงเอกสารที่เกี่ยวข้องมาได้เลย
ข้อจำกัดหลักของการค้นหาแบบเต็มรูปแบบ (BM25)
การนำทั้งสองวิธีมาผสมผสานกันจะช่วยให้สามารถจับทั้งความคล้ายคลึงทางความหมายและการตรงกันของคำหลักได้พร้อมกัน หากรวมคะแนนด้วย 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) ในรูปแบบเฉพาะ โดยมีสาเหตุมาจากปัญหาเชิงโครงสร้างที่ว่า "แม้จะดึงเอกสารที่มีความหมายใกล้เคียงกันออกมาได้ แต่เอกสารนั้นอาจไม่มีข้อมูลที่จำเป็นอย่างถูกต้อง"
BM25 จะให้คะแนนจากการจับคู่คำศัพท์โดยตรง จึงมีความแม่นยำสูงกว่าการค้นหาด้วยเวกเตอร์ในส่วนของเลขรุ่น หมายเลขเวอร์ชัน และคำเฉพาะ (Proper Nouns) การใช้เพียงการค้นหาเชิงความหมายอย่างเดียวมีความเสี่ยงที่ LLM จะสร้างข้อมูลเท็จที่ดูน่าเชื่อถือโดยอ้างอิงจากเอกสารที่ "เกี่ยวข้องแต่ไม่ถูกต้อง" ดังนั้น การค้นหาแบบไฮบริด (Hybrid Search) จึงเป็นวิธีที่มีประสิทธิภาพในการลดความเสี่ยงนี้ในเชิงโครงสร้าง
วิธีทำให้ Vector Database และ BM25 Index อยู่ร่วมกันได้ รวมถึงการออกแบบ Chunk Size และ Embedding Model หากไม่กำหนดสองประเด็นนี้ให้ชัดเจนตั้งแต่ต้น มักจะนำไปสู่การทำ Refactoring ครั้งใหญ่ในขั้นตอนการรวมระบบ ต่อไปนี้คือคำอธิบายรายละเอียดของแต่ละประเด็น
จุดตัดสินใจแรกคือการเลือกโครงสร้างพื้นฐาน (Infrastructure) หากต้องการให้การค้นหาแบบเวกเตอร์ (Vector search) และการค้นหาด้วยคำสำคัญ (Keyword search) ทำงานบนระบบเดียวกัน คุณต้องเลือกระหว่างแพลตฟอร์มที่มีทั้งสองฟังก์ชันในตัว หรือใช้เครื่องมือเฉพาะทางร่วมกัน
จุดที่ควรคำนึงถึงในการออกแบบระบบที่ใช้งานร่วมกัน
การเปลี่ยนขนาด Chunk และ Embedding model ในภายหลังมีค่าใช้จ่ายในการทำ Re-indexing สูง ดังนั้นการกำหนดนโยบายให้ชัดเจนตั้งแต่ต้นจึงเป็นเรื่องสำคัญ
แนวทางการออกแบบขนาด Chunk
สำหรับคู่มือทางเทคนิคหรือเอกสารข้อกำหนด มักนิยมใช้ขนาดประมาณ 256–512 tokens อย่างไรก็ตาม เนื่องจากค่าที่เหมาะสมที่สุดจะแตกต่างกันไปตามลักษณะของเอกสารและกรณีการใช้งาน (Use case) การเตรียมตัวเลือกไว้ 2–3 รูปแบบแล้วนำมาเปรียบเทียบตรวจสอบด้วย Recall@K จึงเป็นวิธีที่ใช้งานได้จริงมากกว่า
ประเด็นการเลือก Embedding 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
การขยายไปสู่ 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 เข้าไปในขั้นตอนหลังจึงเป็นโครงสร้างที่นิยมใช้กันอย่างแพร่หลาย
โครงสร้างไปป์ไลน์ทั่วไป
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 แทบจะเป็นศูนย์
รูปแบบที่มักพบเป็นอาการ:
| วิธีการ | สรุป | ข้อควรระวัง |
|---|---|---|
| Min-Max Normalization | แปลงคะแนนแต่ละค่าให้อยู่ในช่วง 0-1 | ได้รับผลกระทบจากค่า Outlier ได้ง่าย |
| Z-score Normalization | แปลงให้มีค่าเฉลี่ยเป็น 0 และส่วนเบี่ยงเบนมาตรฐานเป็น 1 | มีประสิทธิภาพเมื่อข้อมูลมีการกระจายตัวใกล้เคียงกับการแจกแจงปกติ |
| RRF | อิงตามลำดับ (Rank) ไม่จำเป็นต้องทำ Normalization | ข้อมูลความต่างของคะแนนจะสูญหายไป |
หากเลือกใช้ RRF จะช่วยลดขั้นตอนการทำ Normalization ได้ แต่หากต้องการใช้ประโยชน์จากความมากน้อยของคะแนน การทำ Linear Combination พร้อมกับการทำ Normalization อย่างชัดเจนจะเป็นทางเลือกที่ใช้งานได้จริงมากกว่า การสร้างนิสัยในการบันทึก Log และทำ Visualization ของการกระจายตัวของคะแนนทั้งสองฝั่งในช่วงพัฒนา จะช่วยให้ค้นพบความคลาดเคลื่อนได้ตั้งแต่เนิ่นๆ
キーワード検索側のanalyzer/tokenizerが原因で、検索精度が大きく低下するケースがある。英語を前提としたBM25実装は空白区切りでトークン分割を行うため、日本語やタイ語のように単語間にスペースがない言語では正しく分割されない。
よく起きる問題
プラットフォーム別の対処
多言語ドキュメントが混在する場合は言語検出ステップを挟み、言語ごとに異なる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 รายการ
จุดสำคัญในการสร้าง
การรวมเข้ากับ 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)
สรุปประเด็นสำคัญจากบทความนี้:
สำหรับการพัฒนาในขั้นต่อไป การขยายไปสู่ GraphRAG หรือ Agentic RAG เป็นสิ่งที่น่าสนใจ แต่ในทางปฏิบัติควรเริ่มจากการยกระดับความแม่นยำด้วย Hybrid Search แบบเรียบง่ายก่อนแล้วจึงค่อยๆ พัฒนาต่อยอดไป การลดอาการหลอน (Hallucination) และการปรับปรุงคุณภาพคำตอบนั้นทำได้ยากหากไม่มีการปรับปรุงในส่วนของชั้นการค้นหา (Search layer) ดังนั้น ขอให้มองว่าการนำ Hybrid Search มาใช้เป็นจุดเริ่มต้นของวงจรการปรับปรุงคุณภาพของ RAG โดยรวม

Yusuke Ishihara
เริ่มเขียนโปรแกรมตั้งแต่อายุ 13 ปี ด้วย MSX หลังจบการศึกษาจากมหาวิทยาลัย Musashi ได้ทำงานพัฒนาระบบขนาดใหญ่ รวมถึงระบบหลักของสายการบิน และโครงสร้าง Windows Server Hosting/VPS แห่งแรกของญี่ปุ่น ร่วมก่อตั้ง Site Engine Inc. ในปี 2008 ก่อตั้ง Unimon Inc. ในปี 2010 และ Enison Inc. ในปี 2025 นำทีมพัฒนาระบบธุรกิจ การประมวลผลภาษาธรรมชาติ และแพลตฟอร์ม ปัจจุบันมุ่งเน้นการพัฒนาผลิตภัณฑ์และการส่งเสริม AI/DX โดยใช้ generative AI และ Large Language Models (LLM)