Elastic Search 8.13: Simplifying embedding and ranking for developers

We are continuing our commitment to making Lucene the best vector database. In this release, we see significant performance improvements. For example, in benchmarking the Cohere data set (1m vectors of 768 float dimensions), we saw a 2x performance improvement in the nightly benchmarks. You can read more about this innovation that contributed to Lucene in the Elasticsearch Platform highlights blog.

LTR is now available natively in Elasticsearch as a rescorer. It creates better search results by reranking result sets using a machine learning model trained with your input. Reranking is an important task for semantic search with or without vector search. It can account for signals beyond the query to surface the most relevant results at the top. This is particularly useful for RAG use cases, which rely on feeding only the top few results to an LLM as context.

8.13 brings LTR as part of the core Elastic Search product. We are pleased to have this in technical preview for you to try out. Try native LTR now with this example notebook. We look forward to your feedback!

Application code is complex enough for developers to build and maintain. The added complexity of generating embeddings and orchestrating more systems is an additional and unnecessary burden. In Elastic Search 8.13, we have simplified the integration of Cohere for embeddings, so the developer gets the advantage of great embedding models without the complexity of orchestrating many components and systems. We have refined the query performance of ELSER, allowing performance targets to be reached with fewer compute resources.

Developers often face the challenge of not controlling the source data. When it comes to large documents, they often need to be broken up (or chunked) into multiple embeddings. The same is true when you have multiple images or other artifacts associated with a single document. Multiple results are now possible with multiple inner_hits on nested kNN queries where these embeddings are stored as nested documents.

Many use cases require active management of synonyms to ensure the relevance of results. The use of product names, SKUs, and other linguistic pitfalls in data encouraged us to create an API to programmatically manage synonyms. This API is now promoted to general availability and complements the ability to manage synonyms through the UI. 

Elasticsearch Python client now supports orjson. orjson is a fast, correct JSON library for Python. In benchmarks, it exceeds the performance of standard built-in json modules. Speed improvements in the serialization/deserialization improve vector use cases where there is bulk indexing of vectors.

Since the lifeblood of search is the corpus of data you operate upon, we continue to enhance the existing catalog of connectors. In this release, we have added Redis (Preview) and Notion (Beta) to the catalog. Google Drive, Gmail, OneDrive, Outlook, and Salesforce have now been promoted to general availability.

It's not just a question of what you connect to, it's also about how and what data is retrieved. We have simplified the connector flow and improved the synchronization capabilities to bring the data into Elasticsearch and have added document-level security for ServiceNow and Salesforce connectors.

More significantly, you can bring that data into an existing index. It is no longer a requirement that the connector has to use one predefined index. This gives the developer greater flexibility on how and where the data should reside in Elasticsearch, allowing them to use a pre-existing index or an index they create for a specific project or use-case, or switch to a new index at any time. 

Read about these capabilities and more in the release notes. You can also find code references, notebooks, and the latest research in Search Labs.  

Existing Elastic Cloud customers can access many of these features directly from the Elastic Cloud console. Not taking advantage of Elastic on cloud? Start a free trial.