Elasticsearch 9 và Hybrid Search 2026 — BBQ, ELSER, Retrievers API và Kiến trúc Search System cho Production

Posted on: 4/17/2026 11:15:07 AM

Năm 2026, search không còn chỉ là "gõ keyword rồi trả kết quả" — người dùng kỳ vọng hệ thống hiểu ý nghĩa câu truy vấn, tìm được nội dung liên quan ngay cả khi không trùng từ khóa, đồng thời vẫn chính xác tuyệt đối với các truy vấn cụ thể như mã sản phẩm hay tên riêng. Elasticsearch 9 chính thức đáp ứng nhu cầu này với kiến trúc Hybrid Search — kết hợp sức mạnh của Inverted Index truyền thống (BM25) với Vector Search (HNSW + BBQ) trong cùng một engine, loại bỏ nhu cầu vận hành hai hệ thống riêng biệt.

1. Tại sao Hybrid Search là tương lai của Search

Trước khi đi sâu vào Elasticsearch 9, hãy hiểu rõ tại sao chúng ta cần Hybrid Search thay vì chỉ dùng một trong hai paradigm truyền thống.

1.1 Giới hạn của Keyword Search (BM25)

BM25 — thuật toán xếp hạng dựa trên tần suất thuật ngữ (TF-IDF cải tiến) — vẫn là nền tảng của mọi search engine. Nó sử dụng Inverted Index để map từng term tới danh sách document chứa term đó, cho phép truy vấn cực nhanh (microseconds) với dữ liệu hàng tỷ document.

Tuy nhiên, BM25 có điểm yếu cốt lõi: vocabulary mismatch. Khi người dùng tìm "cách giảm cân hiệu quả" nhưng document viết "phương pháp kiểm soát cân nặng", BM25 không match được vì không có từ chung. Đây là giới hạn bản chất của lexical matching.

1.2 Giới hạn của Vector Search (Semantic)

Vector Search giải quyết vocabulary mismatch bằng cách chuyển text thành embedding vectors (mảng số thực đa chiều), rồi tìm kiếm theo khoảng cách cosine/dot-product trong không gian vector. Hai câu có nghĩa tương tự sẽ nằm gần nhau trong không gian này, bất kể dùng từ khác nhau.

Nhưng Vector Search cũng có điểm yếu: nó kém chính xác với exact match. Tìm mã đơn hàng "ORD-2026-78543" bằng vector search cho kết quả rất tệ — embedding model không được train để phân biệt các chuỗi ký tự ngẫu nhiên.

2. Kiến trúc Elasticsearch 9 — Những thay đổi cốt lõi

Elasticsearch 9.0 (GA đầu 2025, cập nhật liên tục tới 9.3 năm 2026) mang đến loạt cải tiến biến nó từ search engine thuần keyword thành unified search platform.

graph TD
    A[Client Query] --> B[Query DSL / Retrievers API]
    B --> C{Query Router}
    C --> D[BM25 Inverted Index]
    C --> E[ELSER Sparse Vector]
    C --> F[Dense Vector HNSW + BBQ]
    D --> G[Score Normalization]
    E --> G
    F --> G
    G --> H{Fusion Method}
    H --> I[RRF - Reciprocal Rank Fusion]
    H --> J[Linear Combination]
    I --> K[Final Ranked Results]
    J --> K
    K --> L[Re-ranking ColBERT/ColPali]
    L --> M[Response]

2.1 BBQ — Better Binary Quantization

Đây là cải tiến lớn nhất của Elasticsearch 9 cho vector search. BBQ nén vector từ float32 xuống binary representation (1 bit per dimension), giảm bộ nhớ tới 95% so với float32 gốc.

Với dataset 1 tỷ vectors 768 chiều:

Từ Elasticsearch 9.1, BBQ trở thành default cho mọi dense_vector index mới. Thuật toán hoạt động theo 2 bước: (1) quantize vector thành binary, dùng SIMD instructions để so sánh nhanh (POPCNT + XOR), (2) re-score top candidates bằng vector gốc để đảm bảo recall.

{
  "mappings": {
    "properties": {
      "content_embedding": {
        "type": "dense_vector",
        "dims": 768,
        "index": true,
        "similarity": "cosine",
        "index_options": {
          "type": "bbq_hnsw"
        }
      },
      "content": {
        "type": "text",
        "analyzer": "vietnamese_custom"
      },
      "semantic_content": {
        "type": "semantic_text"
      }
    }
  }
}

2.2 ELSER v2 — Elastic Learned Sparse Encoder

ELSER là model sparse vector được Elastic train riêng, tạo ra sparse embedding có thể index bằng inverted index quen thuộc nhưng mang lại semantic understanding. Khác với dense vector (mọi chiều đều có giá trị), sparse vector chỉ có một số ít chiều khác 0, mỗi chiều đại diện cho một "expanded term" mà model học được.

Điều đặc biệt: ELSER có sẵn trong Elasticsearch 9 — không cần external model server, không cần GPU, chạy trực tiếp trên node với CPU inference. Khi tạo semantic_text field mà không chỉ định inference endpoint, Elasticsearch tự động dùng ELSER.

2.3 Retrievers API — Composable Search Pipeline

Retrievers là abstraction mới trong Query DSL, cho phép xây dựng search pipeline nhiều tầng một cách declarative. Thay vì viết logic phức tạp ở application layer, bạn compose trực tiếp trong query.

{
  "retriever": {
    "rrf": {
      "retrievers": [
        {
          "standard": {
            "query": {
              "match": {
                "content": {
                  "query": "cách tối ưu hiệu năng database",
                  "analyzer": "vietnamese_custom"
                }
              }
            }
          }
        },
        {
          "standard": {
            "query": {
              "semantic": {
                "field": "semantic_content",
                "query": "cách tối ưu hiệu năng database"
              }
            }
          }
        },
        {
          "knn": {
            "field": "content_embedding",
            "query_vector_builder": {
              "text_embedding": {
                "model_id": "jina-embeddings-v3",
                "model_text": "cách tối ưu hiệu năng database"
              }
            },
            "k": 50,
            "num_candidates": 200
          }
        }
      ],
      "rank_window_size": 100
    }
  },
  "_source": ["title", "content", "url"],
  "size": 10
}

Query trên kết hợp 3 retriever: BM25 match, ELSER semantic, và dense kNN — fusion bằng RRF. Tất cả chạy trong một roundtrip tới Elasticsearch, không cần orchestration ở application.

3. HNSW Deep Dive — Thuật toán đằng sau Vector Search

HNSW (Hierarchical Navigable Small World) là thuật toán ANN (Approximate Nearest Neighbor) được Elasticsearch sử dụng cho dense vector search. Hiểu cách nó hoạt động giúp bạn tune performance cho production.

graph TD
    subgraph "Layer 2 - Coarsest"
        A2[Node A] --- B2[Node B]
    end
    subgraph "Layer 1 - Medium"
        A1[Node A] --- B1[Node B]
        B1 --- C1[Node C]
        A1 --- D1[Node D]
    end
    subgraph "Layer 0 - Finest"
        A0[Node A] --- B0[Node B]
        B0 --- C0[Node C]
        A0 --- D0[Node D]
        C0 --- E0[Node E]
        D0 --- F0[Node F]
        E0 --- F0
        B0 --- E0
    end

3.1 Cách HNSW hoạt động

HNSW xây dựng một graph đa tầng (multi-layer), trong đó:

• Layer 0 chứa tất cả nodes (vectors), mỗi node kết nối với M neighbors gần nhất
• Layer 1, 2, ... chứa một subset ngẫu nhiên của nodes (xác suất giảm theo tầng), tạo "express highways" cho navigation nhanh
• Tìm kiếm bắt đầu từ layer cao nhất (ít nodes, bước nhảy xa), greedy navigate tới neighbor gần query nhất, rồi drop xuống layer thấp hơn để refine

Hai hyperparameter quan trọng nhất:

4. Thiết kế Search System cho Production

Phần này đi vào kiến trúc end-to-end cho một hệ thống search production — từ data ingestion tới serving.

graph LR
    subgraph Data Sources
        DB[(Database)]
        CMS[CMS/API]
        S3[Object Storage]
    end
    subgraph Ingestion Pipeline
        CDC[CDC / Change Stream]
        ENR[Enrichment Service]
        EMB[Embedding Service]
        ING[Ingest Pipeline]
    end
    subgraph Elasticsearch Cluster
        COORD[Coordinating Nodes]
        DATA1[Data Node - Hot]
        DATA2[Data Node - Warm]
        ML[ML Node - ELSER]
    end
    subgraph Serving
        API[Search API .NET]
        CACHE[Redis Cache]
        CLIENT[Vue Frontend]
    end
    DB --> CDC
    CMS --> CDC
    S3 --> CDC
    CDC --> ENR
    ENR --> EMB
    EMB --> ING
    ING --> COORD
    COORD --> DATA1
    COORD --> DATA2
    COORD --> ML
    CLIENT --> API
    API --> CACHE
    API --> COORD

4.1 Data Ingestion — CDC và Embedding Pipeline

Thay vì batch reindex, hệ thống production nên dùng CDC (Change Data Capture) — bắt mọi thay đổi từ database gốc (INSERT/UPDATE/DELETE) và đẩy sang Elasticsearch gần real-time. Với SQL Server dùng Debezium hoặc Change Tracking, với PostgreSQL dùng logical replication.

Pipeline xử lý mỗi document qua 3 bước:

1. Enrichment: thêm metadata, normalize text, detect language
2. Embedding: gọi embedding model (Jina v3, OpenAI text-embedding-3-large, hoặc self-hosted) để tạo dense vector
3. Ingest: Elasticsearch Ingest Pipeline xử lý ELSER sparse encoding + index document

public class SearchDocumentIndexer
{
    private readonly ElasticsearchClient _client;
    private readonly IEmbeddingService _embeddingService;

    public async Task IndexDocumentAsync(ProductDocument doc)
    {
        var embedding = await _embeddingService
            .GenerateEmbeddingAsync(doc.Title + " " + doc.Description);

        var indexDoc = new SearchableProduct
        {
            Id = doc.Id,
            Title = doc.Title,
            Description = doc.Description,
            ContentEmbedding = embedding,
            SemanticContent = doc.Title + " " + doc.Description,
            Category = doc.Category,
            Price = doc.Price,
            UpdatedAt = DateTime.UtcNow
        };

        await _client.IndexAsync(indexDoc, idx => idx
            .Index("products-v2")
            .Id(doc.Id.ToString())
            .Pipeline("product-enrichment")
        );
    }
}

4.2 Index Design — Multi-field Strategy

Một document trong Elasticsearch cần nhiều "góc nhìn" khác nhau để phục vụ hybrid search:

{
  "index_patterns": ["products-*"],
  "template": {
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1,
      "index.knn": true,
      "analysis": {
        "analyzer": {
          "vi_analyzer": {
            "type": "custom",
            "tokenizer": "icu_tokenizer",
            "filter": ["icu_folding", "lowercase", "vi_stop"]
          }
        }
      }
    },
    "mappings": {
      "properties": {
        "title": {
          "type": "text",
          "analyzer": "vi_analyzer",
          "fields": {
            "keyword": { "type": "keyword" },
            "suggest": {
              "type": "completion",
              "analyzer": "vi_analyzer"
            }
          }
        },
        "description": {
          "type": "text",
          "analyzer": "vi_analyzer"
        },
        "semantic_content": {
          "type": "semantic_text"
        },
        "content_embedding": {
          "type": "dense_vector",
          "dims": 768,
          "index": true,
          "similarity": "cosine",
          "index_options": {
            "type": "bbq_hnsw",
            "m": 24,
            "ef_construction": 150
          }
        },
        "sku": { "type": "keyword" },
        "category": { "type": "keyword" },
        "price": { "type": "float" },
        "updated_at": { "type": "date" }
      }
    }
  }
}

4.3 Search API — .NET Integration

Elastic cung cấp Elastic.Clients.Elasticsearch (.NET client chính thức) hỗ trợ đầy đủ Retrievers API và hybrid search.

public class HybridSearchService
{
    private readonly ElasticsearchClient _client;

    public async Task<SearchResult> HybridSearchAsync(
        string query, string? category = null, int page = 1, int size = 10)
    {
        var response = await _client.SearchAsync<ProductDoc>(s => s
            .Index("products-v2")
            .From((page - 1) * size)
            .Size(size)
            .Retriever(r => r
                .Rrf(rrf => rrf
                    .RankWindowSize(100)
                    .Retrievers(
                        ret => ret.Standard(std => std
                            .Query(q => q
                                .Bool(b => b
                                    .Must(m => m
                                        .MultiMatch(mm => mm
                                            .Query(query)
                                            .Fields(new[] { "title^3", "description" })
                                            .Type(TextQueryType.BestFields)
                                            .Fuzziness(new Fuzziness("AUTO"))
                                        )
                                    )
                                    .Filter(BuildCategoryFilter(category))
                                )
                            )
                        ),
                        ret => ret.Standard(std => std
                            .Query(q => q
                                .Semantic(sem => sem
                                    .Field("semantic_content")
                                    .Query(query)
                                )
                            )
                        ),
                        ret => ret.Knn(knn => knn
                            .Field("content_embedding")
                            .QueryVectorBuilder(qvb => qvb
                                .TextEmbedding(te => te
                                    .ModelId("jina-v3")
                                    .ModelText(query)
                                )
                            )
                            .K(50)
                            .NumCandidates(200)
                        )
                    )
                )
            )
            .Highlight(h => h
                .Fields(f => f
                    .Add("title", new HighlightField
                    {
                        PreTags = new[] { "<mark>" },
                        PostTags = new[] { "</mark>" }
                    })
                    .Add("description", new HighlightField
                    {
                        PreTags = new[] { "<mark>" },
                        PostTags = new[] { "</mark>" }
                    })
                )
            )
        );

        return MapToSearchResult(response);
    }
}

5. Score Fusion — RRF vs Linear Combination

Khi kết hợp kết quả từ nhiều retriever, cần một chiến lược fusion để merge và re-rank. Elasticsearch 9 hỗ trợ hai phương pháp chính.

5.1 Reciprocal Rank Fusion (RRF)

RRF là phương pháp rank-based — chỉ quan tâm vị trí (rank) của document trong mỗi retriever, không quan tâm score tuyệt đối. Công thức:

RRF_score(d) = Sum( 1 / (k + rank_i(d)) )
// k = constant (default 60), rank_i = vị trí trong retriever thứ i

Ưu điểm lớn nhất: không cần normalize scores giữa các retriever. BM25 score có thể là 15.7, cosine similarity là 0.89 — RRF xử lý được vì nó chỉ nhìn rank.

5.2 Linear Combination (Weighted)

Với Linear Combination, bạn gán trọng số cho mỗi retriever và cộng score (sau normalization). Phù hợp khi bạn biết rõ retriever nào quan trọng hơn cho use case cụ thể.

{
  "retriever": {
    "linear": {
      "retrievers": [
        {
          "retriever": {
            "standard": {
              "query": { "match": { "content": "tối ưu database" } }
            }
          },
          "weight": 0.3
        },
        {
          "retriever": {
            "knn": {
              "field": "content_embedding",
              "query_vector_builder": {
                "text_embedding": {
                  "model_id": "jina-v3",
                  "model_text": "tối ưu database"
                }
              },
              "k": 50,
              "num_candidates": 200
            }
          },
          "weight": 0.7
        }
      ],
      "normalizer": "min_max"
    }
  }
}

6. ColBERT và Multi-stage Re-ranking

Elasticsearch 9 hỗ trợ multi-stage interaction models như ColBERT và ColPali thông qua MaxSim operator. Đây là bước tiến lớn cho search quality.

Pipeline 3 tầng trong production:

graph LR
    A[Query] --> B[Stage 1: Candidate Retrieval]
    B --> |Top 1000| C[Stage 2: Hybrid Fusion RRF]
    C --> |Top 100| D[Stage 3: ColBERT Re-ranking]
    D --> |Top 10| E[Final Results]

ColBERT (Contextualized Late Interaction over BERT) tạo embedding cho từng token của document và query, rồi dùng MaxSim để tính interaction score. Chi phí cao hơn bi-encoder nhưng cho relevance gần cross-encoder với tốc độ nhanh hơn nhiều.

7. Scaling Elasticsearch cho Billion-scale

7.1 Shard Strategy

Quy tắc cơ bản cho production:

• Shard size: target 20-40 GiB/shard cho search workload, 40-60 GiB cho logging
• Shard count: tránh quá nhiều small shards — mỗi shard có overhead (memory cho segment metadata, thread pools)
• Số shard = Total data size / Target shard size, rồi round up

7.2 Tiered Architecture

7.3 Filtered Vector Search — ACORN

Từ Elasticsearch 9.1, thuật toán ACORN cải thiện đáng kể hiệu năng filtered kNN search. Trước đây, khi kết hợp vector search với filter (ví dụ: tìm sản phẩm tương tự nhưng chỉ trong category "electronics"), Elasticsearch phải scan nhiều candidates hơn cần thiết. ACORN tích hợp filter trực tiếp vào HNSW graph traversal, giảm số nodes cần visit.

8. Search UX — Frontend Integration với Vue

Search tốt không chỉ là backend — UX phía frontend quyết định trải nghiệm người dùng.

8.1 Search-as-you-type với Debounce

import { ref, watch } from 'vue'
import { useDebounceFn } from '@vueuse/core'

export function useHybridSearch() {
  const query = ref('')
  const results = ref<SearchResult[]>([])
  const suggestions = ref<string[]>([])
  const isLoading = ref(false)

  const fetchSuggestions = useDebounceFn(async (q: string) => {
    if (q.length < 2) {
      suggestions.value = []
      return
    }
    const res = await fetch(
      `/api/search/suggest?q=${encodeURIComponent(q)}`
    )
    suggestions.value = await res.json()
  }, 150)

  const executeSearch = useDebounceFn(async (q: string) => {
    if (!q.trim()) {
      results.value = []
      return
    }
    isLoading.value = true
    try {
      const res = await fetch(
        `/api/search?q=${encodeURIComponent(q)}`
      )
      const data = await res.json()
      results.value = data.hits
    } finally {
      isLoading.value = false
    }
  }, 300)

  watch(query, (val) => {
    fetchSuggestions(val)
    executeSearch(val)
  })

  return { query, results, suggestions, isLoading }
}

8.2 Highlight và Snippet

Elasticsearch trả về highlight fragments — đoạn text chứa từ match được bọc trong tag <mark>. Frontend render HTML này với sanitize:

<template>
  <div class="search-result" v-for="hit in results" :key="hit.id">
    <h3 v-html="hit.highlight?.title?.[0] || hit.title" />
    <p
      class="snippet"
      v-html="hit.highlight?.description?.[0]
        || truncate(hit.description, 200)"
    />
    <div class="meta">
      <span class="category">{{ hit.category }}</span>
      <span class="score">Relevance: {{ hit.score.toFixed(2) }}</span>
    </div>
  </div>
</template>

9. Monitoring và Performance Tuning

9.1 Metrics cần theo dõi

9.2 Common Pitfalls

10. Elasticsearch vs Giải pháp thay thế 2026

Kết luận

Elasticsearch 9 đánh dấu bước chuyển từ "search engine" sang "unified search & vector platform". Với BBQ quantization giảm 95% bộ nhớ, ELSER cho semantic search không cần GPU, Retrievers API cho composable hybrid queries, và ColBERT/ColPali re-ranking — đây là stack hoàn chỉnh nhất cho search production năm 2026. Điều quan trọng nhất không phải là chọn keyword hay vector, mà là kết hợp đúng cách cả hai trong cùng một pipeline, với fusion strategy phù hợp use case của bạn.

Tài liệu tham khảo:

• Elasticsearch 9.0 Release — What's New (Elastic Blog)
• BBQ — Better Binary Quantization in Lucene & Elasticsearch (Elastic Labs)
• Elasticsearch 9.1: BBQ default & ACORN filtered vector search (Elastic Labs)
• Hybrid Search in Elasticsearch — Overview & Queries (Elastic Labs)
• From Vector Hype to Hybrid Reality: Is Elasticsearch Still the Right Bet? (Pureinsights 2026)
• Hybrid Search — OpenSearch Documentation