BM25 keyword search, approximate vector search, hybrid search, and structured filters in one query.
|
BM25 keyword search, approximate vector search, hybrid search, and structured filters. Vector indexes are built per Lucene segment, so query latency rises as segments accumulate between merges.
|
Lexical, vector, and application signals combined in one ranking expression you define.
|
Keyword and vector results come from separate retrievers and are merged by rank fusion or a weighted combination, not ranked together with your business signals. Your team picks the normalization and retunes the weights as data changes.
|
Rank expressions compiled and evaluated natively over text, vector, tensor, and document features.
|
function_score covers a few built-in boosts. Anything beyond them needs Painless scripts embedded in each query, which make queries much more expensive across many documents.
|
First phase scores every retrieved candidate on each content node, second phase reranks the best per node, global phase reranks the merged results. Candidate counts are set per stage.
|
Rescorers and rerankers see only a fixed window of top documents on each shard, so relevant documents outside that window never reach your model. Each stage is configured and tuned separately.
|
Built in: feature logging, and XGBoost, LightGBM, and ONNX models in any ranking phase.
|
Models rescore only that per-shard window, and documents outside it keep their original scores. XGBoost and LightGBM models are uploaded through Eland, ONNX ranking models aren’t supported, and the feature requires a paid subscription tier.
|
Embedders and ONNX models run inside the platform, as part of indexing and ranking.
|
Models run on dedicated ML nodes, on Elastic’s hosted inference service, or in external services such as OpenAI or Cohere. Each is a separate workload to size, secure, and pay for.
|
Native tensor fields and tensor math in ranking. Late interaction such as ColBERT is defined in the rank profile.
|
No general tensor type, so personalization and multi-signal ranking must be flattened into separate fields and scripts. Late-interaction vectors (rank_vectors) have no ANN index, so scoring runs as a brute-force script over each candidate.
|
Attribute fields are updated in place and available to filtering and ranking immediately.
|
Every update rewrites the whole document, so frequently changing fields, such as prices or popularity, add continuous reindexing load. Changes become searchable after a refresh (1 second by default).
|
Data redistributes automatically as nodes are added or removed, with no shard count to plan.
|
The primary shard count is fixed when an index is created. Changing it requires a split (with the index read-only), a shrink, or a reindex, so an undersized shard plan becomes a migration project later. Shards rebalance across nodes automatically.
|
Versioned rank profiles in the application package, selected per query.
|
Ranking logic is spread across Query DSL in each request, retriever trees, rescorers, and stored learning-to-rank models, which makes changes harder to version, test, and roll back.
|
8.5× higher throughput per CPU core for hybrid queries, up to 12.9× for vector, and 6.5× for lexical, with an estimated 5× lower infrastructure cost, in our published benchmark.
|
Needed 6.5× to 12.9× more CPU per query than Vespa across the tested workloads (Elasticsearch 8.15.2, November 2024), with the widest gap on vector queries.
|
White papers
