作者： Andre Luiz
讨论如何以及何时使用 semantic_text、dense_vector 或 sparse_vector，以及它们与嵌入生成的关系。
通过这个自定进度的 Search AI 实践学习亲自体验向量搜索。你可以开始免费云试用，或者在本地机器上尝试 Elastic。
多年来，使用嵌入来提升信息检索的相关性和准确性已经显著增长。像 Elasticsearch 这样的工具已经发展出支持这种类型数据的专用字段类型，比如密集向量、稀疏向量和语义文本。然而，为了获得良好的效果，关键在于理解如何正确地将嵌入映射到 Elasticsearch 可用的字段类型：semantic_text、dense_vector 和 sparse_vector。
本文将讨论这些字段类型、各自的适用时机，以及它们在索引和查询过程中与嵌入生成和使用策略之间的关系。
密集向量类型
在 Elasticsearch 中，dense_vector 字段类型用于存储密集向量，这些向量是文本的数值表示，其中几乎所有维度都是相关的。这些向量由语言模型生成，如 OpenAI、Cohere 和 Hugging Face，旨在捕捉文本的整体语义含义，即使它与其他文档没有共享相同的词语。
在 Elasticsearch 中，密集向量的维度上限为 4096，具体取决于所使用的模型。例如，all-MiniLM-L6-v2 模型生成 384 维向量，而 OpenAI 的 text-embedding-ada-002 生成 1536 维向量。
当需要更大的控制权时，例如使用预生成的向量、应用自定义相似度函数或与外部模型集成，dense_vector 字段通常被作为存储这类嵌入的默认类型。
何时以及为何使用 dense_vector 类型？
密集向量非常适合用于捕捉句子、段落或完整文档之间的语义相似性。当目标是比较文本的整体含义，即使它们不共享相同词语时，它们也表现得非常好。
当你已经有一个外部嵌入生成流程，使用如 OpenAI、Cohere 或 Hugging Face 等模型，并且只想手动存储和查询这些向量时，dense_vector 字段是理想选择。这种字段类型高度兼容嵌入模型，并在生成和查询上提供完全的灵活性，让你可以控制向量的生成、索引以及搜索中的使用方式。
此外，它支持多种语义搜索形式，如 KNN 或 script_score 查询，适用于需要调整排序逻辑的场景。这些能力使 dense_vector 成为 RAG（检索增强生成）、推荐系统以及基于相似度的个性化搜索等应用的理想选择。
最后，该字段允许你自定义相关性逻辑，可使用如 cosineSimilarity、dotProduct 或 l2norm 等函数，根据你使用场景的需求来调整排序。
对于那些需要灵活性、自定义能力和与高级用例兼容性的用户来说，密集向量仍然是最佳选择。
如何对 dense_vector 类型使用查询？
对定义为 dense_vector 的字段进行搜索时，使用的是 k-nearest neighbor 查询（KNN 查询）。该查询用于查找与查询向量最接近的文档。以下是一个将 KNN 查询应用于 dense_vector 字段的示例：
{"knn": {"field": "my_dense_vector","k": 10,"num_candidates": 50,"query_vector": [/* vector generated by model */]}
}除了使用 Knn 查询外，如果需要自定义文档评分，也可以使用 script_score 查询，将其与如 cosineSimilarity、dotProduct 或 l2norm 等向量比较函数结合，以更可控的方式计算相关性。请看示例：
{
"script_score": {"query": { "match_all": {} },"script": {"source": "cosineSimilarity(params.query_vector,
'my_dense_vector') + 1.0","params": {"query_vector": [/* vector */]}}}
}如果你想深入了解，我推荐阅读文章《How to set up vector search in Elasticsearch》。
稀疏向量类型
sparse_vector 字段类型用于存储稀疏向量，这种向量的大多数值为零，只有少数词语具有显著权重。这种向量常见于基于词项的模型，如 SPLADE 或 ELSER（Elastic Learned Sparse EncodeR）。
何时以及为何使用稀疏向量类型？
稀疏向量非常适合在需要词汇层面更精确搜索，同时不牺牲语义智能的情况下使用。它们将文本表示为 token/value 对，仅突出最相关的词语及其权重，提供了清晰性、控制力和效率。
这种字段类型在基于词项生成向量时特别有用，比如 ELSER 或 SPLADE 模型，根据词元在文本中的相对重要性为每个词元分配不同权重。
当你想控制查询中特定词语的影响时，稀疏向量类型允许你手动调整词语的权重，以优化结果排序。
主要优势包括搜索的透明性，因为可以清楚理解为什么某个文档被认为相关；存储效率，因为只保存非零值的词元，而密集向量则保存所有维度。
此外，稀疏向量是混合搜索策略的理想补充，甚至可以与密集向量结合，将词汇精度与语义理解融合。
如何对稀疏向量类型使用查询？
sparse_vector 查询允许你基于词元/值格式的查询向量搜索文档。下面是查询示例：
{"query": {"sparse_vector": {"field": "field_sparse","query_vector": {"token1": 0.5,"token2": 0.3,"token3": 0.2}}}
}如果你更喜欢使用训练好的模型，可以使用推理端点，它会自动将查询文本转换为稀疏向量：
{"query": {"sparse_vector": {"field": "field_sparse","inference_id": "the inference ID to produce the token/weights","query": "search text"}}
}要进一步了解这个主题，我建议阅读《Understanding sparse vector embeddings with trained ML models》。
语义文本类型 - semantic_text
semantic_text 字段类型是 Elasticsearch 中使用语义搜索最简单、最直接的方式。它通过推理端点自动处理嵌入生成，既在索引时也在查询时完成。这意味着你不必担心手动生成或存储向量。
何时以及为何使用 semantic_text？
semantic_text 字段是采用 Elasticsearch 语义搜索最简单直接的方式。它适合那些想以最少技术投入开始，并且不想手动处理向量的用户。该字段自动化了嵌入生成和向量搜索映射等步骤，使设置更快、更方便。
当你重视简洁和抽象时，应考虑使用 semantic_text，它消除了手动配置映射、嵌入生成和数据接收流程的复杂性。只需选择推理模型，剩下的由 Elasticsearch 处理。
主要优势包括自动嵌入生成（在索引和查询时进行），以及预配置支持所选推理模型的现成映射。
此外，该字段原生支持长文本自动拆分（文本分块），允许将大段文本分成更小的片段，每个片段都有自己的嵌入，提升搜索精度。这极大提高了生产力，特别适合希望快速交付价值且不想处理语义搜索底层工程的团队。
不过，虽然 semantic_text 提供速度和简洁，但也有一定限制。它支持市场标准模型，只要它们作为 Elasticsearch 中的推理端点可用。但不支持像 dense_vector 字段那样使用外部生成的嵌入。
如果你需要更多控制嵌入生成方式、想使用自己的嵌入，或者需要结合多个字段进行高级策略，dense_vector 和 sparse_vector 字段则提供了适合更定制或领域专用场景的灵活性。
如何对 semantic_text 类型使用查询
在 semantic_text 出现之前，查询要根据嵌入类型（密集或稀疏）使用不同的查询。稀疏字段用 sparse_vector 查询，密集字段用 KNN 查询。
使用 semantic_text 类型时，搜索通过 semantic 查询进行，它自动生成查询向量，并与已索引文档的嵌入进行比较。semantic_text 类型允许你定义一个推理端点来嵌入查询，如果没有指定，则会使用索引时相同的端点来处理查询。
{"query": {"semantic": {"field": "semantic_text_field","query": "search text"}}
}要了解更多，我建议阅读文章《Elasticsearch：使用 semantic_text 简化语义搜索》。
总结
在选择如何在 Elasticsearch 中映射嵌入时，理解你想如何生成向量以及需要多少控制权是非常重要的。如果你追求简单，semantic_text 字段支持自动且可扩展的语义搜索，适合很多初始用例。当需要更多控制、微调性能或与自定义模型集成时，dense_vector 和 sparse_vector 字段提供所需的灵活性。
理想的字段类型取决于你的用例、可用基础设施以及机器学习堆栈的成熟度。最重要的是，Elastic 提供了构建现代且高度适应性搜索系统的工具。
原文：Elasticsearch new semantic_text mapping: Simplifying semantic search - Elasticsearch Labs
