超越相似名称：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 与 ES|QL 集成示例：

FROM product-catalog-index
| WHERE match(product_description.prod_embedding,
"carpenter thing for shaving wood ?")

Elasticsearch：更快更高效

附加资源：

• Elasticsearch 的 semantic_text 默认使用 BBQ。
• OpenSearch 的 semantic 字段需过滤非必要信息或总是 “排除”。

Elasticsearch：可配置

附加资源：

• 使用 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