Beyond similar names: How Elasticsearch semantic text exceeds OpenSearch semantic field in simplicity, efficiency, and integration

Try out vector search for yourself using this self-paced hands-on learning for Search AI. You can start a free cloud trial or try Elastic on your local machine now.

In Elasticsearch 8.15 (August 2024), we introduced the semantic_text feature, which reduced the setup of semantic search to a single step: specifying a field type. Since then, we have continued to enhance this GA feature with the goal of further simplifying our users' experience.

Recently, OpenSearch 3.1 (June 2025) released a similar feature named the semantic field type. In this blog, we’ll compare these two features in terms of simplicity, configurability, and efficiency, and show that it attempts to mirror Elasticsearch’s innovations but, in practice, gives the user less powerful capabilities while introducing more complexity.

Elasticsearch semantic_text—Elegantly simple

Elasticsearch's semantic_text feature simplifies the semantic search workflow by automatically generating embeddings using a default semantic model, with customization to other models enabled by a simple switch of the defined inference endpoint. This accelerates the delivery of semantic search while eliminating the need for manual configuration, ingest pipeline setup, incorporation of external tools, and manual synchronization of the models used at ingest and query time.

This capability is easily extensible with the integration of a wide array of additional model providers and enables powerful hybrid search scenarios.

The semantic_text field delivers a streamlined representation in _source, reducing verbosity and improving disk efficiency over the previous version. Elasticsearch features integrate this capability seamlessly. One example is support for highlighting, which lets you surface the most relevant chunks in the field to be sent to the LLM. After evolving from a multi-step pipeline setup to a single purpose-built field type, semantic search is simpler and production-ready. These nuances add up to better answer quality when building agents and utilizing Elasticsearch as the grounding source and vector store.

The semantic_text field is tightly integrated into the query language—both query DSL and ES|QL. Query options were also expanded to include match, knn and sparse_vector queries. semantic_text remains simple to set up while allowing advanced options to be used through this integrated query support. As we continue to invest in ES|QL, the power of this underlying system will continue to be present in every command.

For fully managed Elasticsearch users and those on the latest versions, new chunking and index options are available and are configurable for use in semantic text.

These changes reflect a continued focus on providing great defaults for semantic search while enabling expansive access to the underlying AI capabilities of the platform.

How does the new semantic field type in OpenSearch 3.1 compare? Let’s take a look…

Reviewing OpenSearch 3.1 semantic field feature

OpenSearch’s semantic field type, introduced in version 3.1, aims to simplify neural search by automatically enabling embedding generation during ingestion and query. However, on inspection, we see that its implementation introduces friction due to how it has been integrated with the rest of OpenSearch's features.

Key differences in functionality

Elasticsearch’s thoughtful choices on defaults and configurability enable users to get up and running quickly. Because of the seamless nature of Elastic’s implementation, there is a clear pathway to more advanced capabilities without compromising simplicity.

For example, after getting started with default quantization, a user may wish to adjust the quantization level based on the desired accuracy and latency trade-offs. The rigidity of OpenSearch’s implementation prevents an easy path to a more optimized experience.

Elasticsearch: Tighter integration/works seamlessly

Example of how Elasticsearch semantic_text Integrates with ES|QL:

Elasticsearch: Faster and more efficient

Additional resources:

• Defaults to BBQ in Elasticsearch's semantic_text.
• Filter non-essential information or always “exclude” in OpenSearch's semantic field.

Elasticsearch: Configurable

Additional resources:

• Improving text expansion performance using token pruning in Elasticsearch.
• Limitations of the semantic field in OpenSearch's semantic field.
• Fixed-length chunking in OpenSearch's semantic field.

While the tables above provide a concise overview, the nuances of semantic highlighting are particularly important for applications like RAG. Let's compare how Elasticsearch and OpenSearch handle this feature in more detail.

RAG best practices in semantic highlighting

Best practice:

Semantic highlighting should ideally reuse existing indexed embeddings to avoid expensive processing at query time. This design choice significantly reduces query latency and compute costs by eliminating the need for secondary inference. Furthermore, to improve relevance for Large Language Models (LLMs), the highlighting mechanism should return sufficient contextual information, often meaning whole chunks of text rather than just isolated sentences. The ability to configure the size of these chunks is also beneficial to optimize for the RAG use case.

Elasticsearch approach:

Elasticsearch's highlighting implementation aligns with this best practice, improving:

• Efficiency and cost: By reusing the embeddings already indexed for each document. This means no secondary inference is required, which can lead to more efficient processing when compared to OpenSearch.
• Contextual flexibility: Moreover, Elasticsearch's semantic highlighter returns whole chunks, which are almost always longer than one sentence. This provides more context to the LLM, often improving relevance in many cases. If the chunk size isn’t optimal for a specific use case, users can change it using chunking settings on the semantic_text field.

OpenSearch approach:

In contrast, OpenSearch’s semantic highlighting implementation results in limitations:

• Increased cost and latency: OpenSearch requires both documents and the query to be processed by a specific semantic highlighting model at query time. This incurs additional costs in query latency and compute due to this secondary inference.
• Limited context and lower relevancy: OpenSearch's semantic highlighting model operates solely on individual sentences, with no way to configure larger context windows. This limitation means the highlighter will only return single sentences, which could negatively impact relevance due to incomplete context being provided to the LLM.

Beyond the functional and efficiency distinctions in highlighting, the fundamental differences in simplicity and integration become evident right from the initial setup phase. Next, we’ll see that Elasticsearch’s approach requires fewer steps from the very beginning.

Simple comparison example: hybrid search with RRF

Here we see an example (without configuring chunking, pruning, or highlighting) that shows the additional steps needed to set up a rudimentary semantic field and execute a simple hybrid search based on RRF. Elasticsearch 9.1 and OpenSearch 3.1 were used.

We create a simple index with a multi-field in Elasticsearch:

• product_description
• product_description.prod_embedding

In OpenSearch OOTB, we have 2 fields at the top level because the text does not flow through to the subfield if it is of the “semantic” type.

We then run a hybrid search with RRF on both Elasticsearch and OpenSearch.

The seamless integration in Elasticsearch between semantic_text and retrievers can be seen.

Elasticsearch semantic_text:

OpenSearch semantic field:

Elasticsearch requires fewer steps in this simple case, highlighting its ease of use.

As the complexity of search scenarios grows, Elasticsearch’s scalable architecture ensures it can handle the demands with ease.

Conclusion

The comparison between Elasticsearch’s semantic_text and OpenSearch’s semantic field shows that, while both features share similar objectives, their capabilities diverge in significant ways. Architectural choices and a commitment to continuous improvement can lead to dramatically different outcomes in both capability and resource requirements.

• Elasticsearch’s semantic_text field stands out for its focus on simplicity, efficiency, and seamless integrations with the rest of the suite—offering configurable chunking, default quantization (BBQ), and compact storage. OpenSearch’s semantic field currently exhibits more rigidity and lacks some of the streamlined integrations and storage optimizations present in Elasticsearch.

Elasticsearch’s implementation of semantic_text provides a clear path to more advanced semantic search capabilities without compromising simplicity.

Try out semantic_text today

You can check out semantic_text in fully managed Elasticsearch Serverless projects with a free trial. It’s also available in versions spanning from 8.15, but is best experienced in 8.19 and 9.1.

Get started in minutes on your local environment with a single command:

curl -fsSL https://elastic.co/start-local | sh