超越相似名称：Elasticsearch semantic text 如何在简洁、高效、集成方面超越 OpenSearch semantic 字段
作者：来自 Elastic Mike Pellegrini, Nick Chow 及 Libby Lin
比较 Elasticsearch 语义文本和 OpenSearch 语义字段在简洁性、可配置性和效率方面的表现。
自己动手体验向量搜索，使用这个自定进度的 Search AI 实操学习。你现在可以开始免费的云试用，或者在本地机器上尝试 Elastic。
在 Elasticsearch 8.15（2024 年 8 月）中，我们引入了 semantic_text 功能，将语义搜索的设置简化为一步：指定字段类型。从那时起，我们持续增强这一 正式发布版功能，目标是进一步简化用户体验。
最近，OpenSearch 3.1（2025 年 6 月）发布了一个类似功能，名为 semantic 字段类型。在这篇博客中，我们将从简洁性、可配置性和效率方面比较这两个功能，并展示它试图模仿 Elasticsearch 的创新，但实际上为用户提供的功能更弱，同时引入了更多复杂性。
Elasticsearch semantic_text —— 优雅简洁
Elasticsearch 的 semantic_text 功能通过默认语义模型自动生成向量嵌入，只需简单切换已定义的推理端点即可自定义为其他模型，从而简化了语义搜索工作流。这加快了语义搜索的交付速度，同时无需手动配置、设置 ingest pipeline、引入外部工具，也不需要在写入和查询时手动同步所用的模型。
这种能力可以通过集成大量其他模型提供商轻松扩展，并支持强大的混合搜索场景。
semantic_text 字段在 _source 中提供了简化的表示形式，相比之前的版本减少了冗余、提升了磁盘效率。Elasticsearch 的功能与这一能力无缝集成。例如，它支持高亮功能，可以将字段中最相关的片段提取并发送给 LLM。语义搜索从多步骤的 pipeline 设置演变为单一的专用字段类型后，更加简单且可直接投入生产。这些细节累积起来，在构建 Agent 和将 Elasticsearch 用作 grounding 来源及向量存储时，能带来更高质量的答案。
semantic_text 字段与查询语言（包括查询 DSL 和 ES|QL）紧密集成。查询选项也扩展为支持 match、knn 和 sparse_vector 查询。semantic_text 保持了简单的设置方式，同时通过这种集成查询支持，可以使用高级选项。随着我们持续投资于 ES|QL，这个底层系统的能力将继续体现在每个命令中。
对于完全托管的 Elasticsearch 用户和使用最新版本的用户，现在可以使用新的分块和索引选项，并可配置用于语义文本。
这些变化体现了我们持续关注为语义搜索提供优秀默认设置的同时，也让用户能够广泛使用平台的底层 AI 能力。
那么，OpenSearch 3.1 中的新 semantic 字段类型表现如何呢？让我们一探究竟……
评测 OpenSearch 3.1 的 semantic 字段功能
OpenSearch 在 3.1 版本中引入的 semantic 字段类型，旨在通过在写入和查询时自动启用向量嵌入生成来简化神经搜索。然而，经过检查，我们发现其实现方式由于与 OpenSearch 其他功能的集成方式，反而引入了一些阻碍。
功能上的主要差异
Elasticsearch 在默认值和可配置性上的深思熟虑，使用户能够快速上手。由于 Elastic 的实现方式无缝衔接，用户可以在不牺牲简洁性的情况下，顺利过渡到更高级的功能。
例如，在使用默认量化开始后，用户可能希望根据所需的准确性与延迟权衡来调整量化级别。而 OpenSearch 的实现僵化，阻碍了轻松获得更优体验的途径。
Elasticsearch：集成更紧密/运行更流畅
| Elasticsearch semantic_text | OpenSearch semantic field | |
|---|---|---|
| 开箱即用 embedding | 默认附带 ELSER，开箱即可生成向量嵌入。支持即时语义搜索，无需设置模型。 | 没有默认的开箱即用模型。需要额外步骤来选择、注册并部署向量嵌入模型。 |
| 支持的查询类型 | Semantic、Match、KNN、Sparse_vector。在保持语义查询简洁性的同时具备 DSL 的灵活性。 | Neural（Vector）。在开发过程中灵活性有限。 |
| 与查询语言的集成 | 与 ES|QL 集成，提供统一的数据探索体验，提升生产力。 | 目前不支持与 PPL 集成。开发者被迫在查询语言之间切换（例如切换到 DSL）。 |
| 语义高亮（参见高亮方法差异部分） | 无需设置模型。查询中不需要指定模型 ID。用户可即时获得高亮，无技术负担。 | 没有默认高亮模型。每次查询都需要指定模型 ID。开发者必须分别管理和跟踪高亮模型与嵌入模型。 |
Elasticsearch semantic_text 与 ES|QL 集成示例：
FROM product-catalog-index
| WHERE match(product_description.prod_embedding,
"carpenter thing for shaving wood ?")Elasticsearch：更快更高效
| Elasticsearch semantic_text | OpenSearch semantic field | |
|---|---|---|
| 量化 | 默认使用 BBQ，内存节省高达 95%。支持可配置量化，用户可调整。 | 量化继承自嵌入模型，不支持配置。用户被锁定在低效内存使用和较差性能中。 |
| 响应中包含的嵌入数据 | 输出简洁，客户端关注核心内容。 | 响应中附加嵌入数据，开发者需过滤非必要信息或总是“排除”。 |
附加资源：
- Elasticsearch 的 semantic_text 默认使用 BBQ。
- OpenSearch 的 semantic 字段需过滤非必要信息或总是 “排除”。
Elasticsearch：可配置
| Elasticsearch semantic_text | OpenSearch semantic field | |
|---|---|---|
| 稀疏模型的 Token 修剪 | 默认启用。稀疏向量延迟提升 3-4 倍。查询时可配置，用户可根据查询需求调整。 | 修剪比例固定为 0.1，且不可配置。导致处理不同数据集时缺乏灵活性。 |
| 分块 | 默认启用且可配置。可配置分块提升相关性。 | 默认禁用；启用时仅支持固定长度分块。固定长度分块会丧失上下文含义，因此相关性较低。 |
附加资源：
- 使用 Elasticsearch 的 Token 修剪提升文本扩展性能。
- OpenSearch 的 semantic 字段的限制。
- OpenSearch 的 semantic 字段中的固定长度分块。
上表提供了简明的概览，但语义高亮的细节对于像 RAG 这样的应用尤为重要。让我们更详细地比较 Elasticsearch 和 OpenSearch 如何处理这一功能。
RAG 语义高亮最佳实践
最佳实践：
语义高亮应尽量复用已索引的嵌入，避免查询时进行昂贵的二次推理。此设计大幅降低查询延迟和计算成本。此外，为了提升大型语言模型（LLM）的相关性，高亮机制应返回足够的上下文信息，通常是整块文本，而非孤立句子。能够配置这些文本块的大小，对优化 RAG 用例也很有帮助。
Elasticsearch 方法：
Elasticsearch 的高亮实现符合上述最佳实践，提升了：
-
效率与成本：复用每个文档已索引的嵌入，无需二次推理，处理效率优于 OpenSearch。
-
上下文灵活性：其语义高亮返回整块文本，通常比单句更长，为 LLM 提供更多上下文，提升相关性。如果块大小不适合特定用例，用户可以通过 semantic_text 字段的分块设置调整。
OpenSearch 方法：
相比之下，OpenSearch 的语义高亮实现存在以下限制：
-
成本与延迟增加：查询时需对文档和查询同时使用特定的语义高亮模型，导致额外的查询延迟和计算开销。
-
上下文受限且相关性较低：高亮模型仅对单句操作，且无法配置更大上下文窗口，只返回单句，因上下文不完整可能影响相关性。
除了功能和效率上的差异，简洁性和集成度的根本区别从最初的设置阶段就显而易见。接下来，我们将看到 Elasticsearch 的方案从一开始就更简便。
简单对比示例：使用 RRF 的混合搜索
这里展示一个示例（未配置分块、修剪或高亮），说明设置基础语义（semantic）字段并执行基于 RRF 的简单混合搜索所需的额外步骤。使用了 Elasticsearch 9.1 和 OpenSearch 3.1。
我们在 Elasticsearch 中创建了一个带多字段的简单索引：
-
product_description
-
product_description.prod_embedding
在 OpenSearch 开箱即用（OOTB）环境中，顶层有两个字段，因为如果字段是 “semantic” 类型，文本不会流向子字段。
然后，我们在 Elasticsearch 和 OpenSearch 上分别运行基于 RRF 的混合搜索。
可以看到 Elasticsearch 中 semantic_text 与检索器之间的无缝集成。
Elasticsearch semantic_text：
PUT /product-catalog-index{"mappings": {"properties": {"product_description": {"type": "text","fields": {"prod_embedding": {"type": "semantic_text"}}}}}
}
# Insert a document
POST /product-catalog-index/_doc{"product_description": "A hand plane is an essential tool in a woodworker's toolset. It's used to smooth and flatten wood surfaces as well as trim components."
}# Do Hybrid Search using Retrievers (RRF)
POST /product-catalog-index/_search{"retriever": {"rrf": {"retrievers": [{"standard": {"query": {"match": {"product_description": "Thing that Carpenters use to shave lumber."}}}},{"standard": {"query": {"semantic": {"field" : "product_description.prod_embedding","query": "Thing that Carpenters use to shave lumber."}}}}]}}
}OpenSearch semantic field:
# Register and Deploy an embedding model
POST /_plugins/_ml/models/_register?deploy=true{"name": "amazon/neural-sparse/opensearch-neural-sparse-encoding-doc-v3-distill","version": "1.0.0","model_format": "TORCH_SCRIPT"
}# WAIT for the TASK to be COMPLETED and then create your index
GET /_plugins/_ml/tasks/csMZdJgBeUoTAZq7_jT0# Create Index
PUT /product-catalog-index{"mappings": {"properties": {"product_description": {"type": "text","copy_to": "prod_embedding"},"prod_embedding": {"type": "semantic","model_id": "c8MadJgBeUoTAZq7ADQt"}}}
}# NOTE: The “copy_to” did not work on a “semantic” field.
POST /product-catalog-index/_doc{"product_description": "A hand plane is an essential tool in a woodworker's toolset. It's used to smooth and flatten wood surfaces as well as trim components.","prod_embedding": "A hand plane is an essential tool in a woodworker's toolset. It's used to smooth and flatten wood surfaces as well as trim components."
}# Create a RRF Pipeline processor
PUT /_search/pipeline/rrf-pipeline-product-catalog{"description": "Processor for hybrid RRF search","phase_results_processors": [{"score-ranker-processor": {"combination": {"technique": "rrf"}}}]
}
#
POST /product-catalog-index/_search?search_pipeline=rrf-pipeline-product-catalog{"_source": {"excludes": ["prod_embedding_semantic_info"]},"query": {"hybrid": {"queries": [{"match": {"product_description": "Thing that Carpenters use to shave lumber."}},{"neural": {"prod_embedding": {"query_text": "Thing that Carpenters use to shave lumber."}}}]}}
}在这个简单案例中，Elasticsearch 需要的步骤更少，突出其易用性。
随着搜索场景复杂度的增加，Elasticsearch 可扩展的架构确保它能够轻松应对需求。
总结
Elasticsearch 的 semantic_text 与 OpenSearch 的 semantic 字段虽然目标相似，但功能存在显著差异。架构选择和持续改进的承诺，带来了功能和资源需求上的巨大不同。
- Elasticsearch 的 semantic_text 字段以简洁、高效和与套件其他部分的无缝集成为特色，提供可配置分块、默认量化（BBQ）和紧凑存储。OpenSearch 的 semantic 字段目前更僵化，缺少 Elasticsearch 中一些简化的集成和存储优化。
Elasticsearch 对 semantic_text 的实现，为更高级的语义搜索能力提供了清晰路径，同时不牺牲简洁性。
立即试用 semantic_text
你可以通过免费试用，在完全托管的 Elasticsearch Serverless 项目中体验 semantic_text。它也可在 8.15 及以上版本使用，但在 8.19 和 9.1 中体验最佳。
只需一条命令，几分钟内即可在本地环境开始使用：
curl -fsSL https://elastic.co/start-local | sh
原文：Beyond similar names: How Elasticsearch semantic text exceeds OpenSearch semantic field in simplicity, efficiency, and integration - Elasticsearch Labs