📣 极限科技诚招搜索运维工程师(Elasticsearch/Easysearch)- 全职/北京 👉 : 立即申请加入

引言 #

想象这样一个场景:你在公司内部的知识库里搜索:“接口偶尔超时,但日志没看到错误”,却一无所获。然而,系统中明明存在一篇名为《服务响应延迟排查指南》的文章。这并不是数据缺失,而是传统搜索引擎的局限——它“只认字,不认意”。它不知道“超时”≈“延迟”,“没报错”≈“无明显异常”。为了解决这个问题,现代搜索系统引入了 向量检索 技术,让搜索不再局限于关键词匹配,而是真正开始“理解语义”。本文将带你了解:

  • 向量检索的基本原理
  • 它解决了哪些传统搜索的痛点
  • Easysearch 是如何实现并向企业级场景赋能的

无需复杂数学,也能彻底搞懂这项关键技术。


一、什么是向量检索? #

1.1 关键词匹配的局限 #

传统关键词检索关注的是文本中是否出现了用户输入的词语。
例如,用户搜索:

“如何提高搜索准确性?”

系统会去索引中查找包含“提高”“搜索”“准确性”等词的文档,并按相关性返回结果。

这种方法在表达清晰、关键词明确的情况下效果很好;但当用户表达更自然、模糊或长句的时候,系统很难从字面上匹配对应的结果。

1.2 向量检索的核心思想 #

向量检索的基本想法是:

把自然语言转换成一个数字向量,然后在向量空间中比较这些向量之间的距离,从而衡量语义相似度。

换句话说:

  • 每个文本或句子可以映射成一个“数值向量”
  • 语义相似的文本在向量空间会更“接近”
  • 通过比较向量之间的距离(如余弦相似度),可以实现语义检索

这种方法让搜索系统不仅仅依赖字面匹配,还能理解更深层次的语义含义。


二、向量检索解决了什么问题? #

在传统搜索系统中,关键词检索一直是最核心、最可靠的能力。但随着用户输入方式越来越自然,关键词检索逐渐暴露出一些难以回避的问题。

1. 表达方式不一致的问题 #

用户可能会用不同的方式表达同一个意思,例如:

  • “搜索性能优化方法”
  • “如何提升搜索系统的速度”
  • “搜索慢了该怎么解决”

从人的角度看,这些问题非常相似;
但从关键词角度看,它们并不完全相同。

向量检索通过语义表示的方式,将这些不同表达映射到相近的向量空间,从而降低对字面一致性的依赖。


2. 同义词与近义表达问题 #

关键词检索对同义词非常敏感:

  • “延迟高” vs “响应慢”
  • “服务异常” vs “系统出问题”

如果没有额外配置,同义词往往无法自然匹配。
而向量检索在语义空间中可以天然捕捉这种相似性。


3. 长文本与自然语言问题 #

当用户输入的是一整句话甚至一段描述时:

“最近接口偶尔超时,日志没看到明显错误”

关键词检索很难判断哪些词是重点。
向量检索则可以将整段文本作为一个整体进行语义理解。


三、Easysearch 中的向量检索实现 #

Easysearch 在设计上既保留了传统的关键词检索能力,又支持向量检索,使得两者可以在一个系统中协同工作,从而兼顾精确性和语义理解能力。下面是 Easysearch 对向量检索的实现逻辑分解。


3.1 向量字段的定义 #

在 Easysearch 中,向量检索的前提是要必须安装 knn 插件,参考 插件安装然后在索引中定义一个可以存储向量的字段。这个字段通常是一个固定长度的浮点向量,用于存放文本或句子的 embedding 表示。

示例:

PUT /my-vector-index
{
  "mappings": {
    "properties": {
      "text_vector": {
        "type": "knn_dense_float_vector",
        "knn": {
          "dims": 128,
          "model": "lsh",
          "similarity": "cosine"
          "L": 99,
          "k": 1
        }
      }
    }
  }
}

上面的配置定义了一个向量字段 text_vector,用于存放 128 维的向量,并指定使用 LSH_COSINE 来衡量相似度。

关于向量字段:

  • dims:向量维度
  • model模型类型
  • similarity相似度类型(如余弦相似度)
  • L:哈希表的数量。一般来说,增加此值会增加召回率。
  • k:用于形成单个哈希值的哈希函数的数量。一般来说,增加此值会增加精度。

这一步是向量检索的基础,也是搜索系统能够理解语义的前提。

LSH(Locality-Sensitive Hashing)是一种近似最近邻搜索算法,适合大规模向量快速查找。


3.2 向量生成:将文本转成向量 #

在执行向量搜索前,需要将用户的查询文本转化为向量。这个过程不能由 Easysearch 自动完成(除非内置本地模型),因此通常借助 **搜索管道(Search Pipeline)**机制,在查询到达时动态调用外部 embedding 服务完成转换,实现向量生成:

PUT /_search/pipeline/semantic_pipeline
{
  "request_processors": [
    {
      "semantic_query_enricher": {
        "tag": "semantic-enricher",
        "description": "Generate vector from natural language input",
        "url": "https://api.openai.com/v1/embeddings",
        "vendor": "openai",
        "api_key": "<YOUR_API_KEY>",
        "default_model_id": "text-embedding-3-small",
        "vector_field_model_id": {
          "text_vector": "text-embedding-3-small"
        }
      }
    }
  ]
}

这个管道配置了:

  • 调用外部模型生成向量
  • 将生成的向量存储到目标字段 text_vector

这样,当用户发起查询时,Easysearch 会先将查询文本转换成向量,然后再进行向量检索。

embedding 是一种将文本转换为固定长度数值向量的技术,常见于 NLP 模型如 BERT、Sentence-BERT 或 OpenAI 的 text-embedding 模型。


3.3 向量检索 DSL 示例 #

当索引建立并且向量字段定义好之后,就可以执行向量检索了。

以下是一个常见的向量检索 DSL 示例:

GET /my-vector-index/_search
{
  "query": {
     "knn_nearest_neighbors": {
        "field": "text_vector",
        "vec": {
          "values": [
            -0.37436,
            -0.11959,
            -0.87609,
            -1.1217,
            1.2788,
            0.48323,
            -0.53903,
            0.053659,
            -0.23929,
            -0.12414,
            ......
          ]
        },
        "model": "lsh",
        "similarity": "cosine",
        "candidates": 50
      }
  }
}

这个 DSL 表示:

  • 在字段 text_vector 上使用向量检索
  • knn_nearest_neighbors: 表示执行 K 最近邻(K-Nearest Neighbors)搜索
  • vec.values: 字段填入的是由 embedding 模型生成的浮点数数组
  • model:模型类型。
  • similarity:相似度类型。

这种办法允许系统把用户的自然语言查询转换成向量,然后在内置向量索引中进行搜索,从而返回在语义空间中最接近的结果。


四、向量检索的工程实践:如何在 Easysearch 中高效使用 #

向量检索相较于传统关键词检索具有以下优势:

4.1 语义理解能力更强 #

向量检索基于 embedding,将文本转成向量表示,能够捕捉到文本背后的语义信息:

  • 同义词或近义表达可以被映射到相似向量
  • 不同的表达方式可以得到相似结果

例如:

“搜索引擎的工作原理” 和 “如何设计一个文本搜索系统”

此类查询结果在语义上具有相似性,向量检索可以更好地召回相关内容。


4.2 混合查询:语义 + 关键词 #

向量检索与关键词检索并不是对立的,而是互补的:

  • 关键词检索提供精确匹配
  • 向量检索提供语义相似匹配
  • 混合使用可以提高召回率和准确性

4.3 典型使用模式 #

Easysearch 在设计上支持混合查询能力,允许开发者根据业务需要灵活组合。在 Easysearch 中,向量检索并不是一个独立存在的“高级功能”,而是作为搜索体系中的一种能力,与全文检索、过滤、聚合等机制协同工作。从工程实践角度来看,Easysearch 更强调可控、可组合、可落地

1. 向量检索通常不是“唯一条件” #

在真实系统中,Easysearch 很少只使用纯向量检索,而是结合结构化条件,例如:

  • 时间范围
  • 数据类型
  • 状态字段

这样可以避免语义搜索范围过大,同时保证结果符合业务上下文。


2. 向量检索更多用于“召回阶段” #

在 Easysearch 的搜索链路中,向量检索通常承担的是:

扩大候选结果范围(Recall)

而不是直接决定最终排序。

之后,系统仍然可以结合:

  • 关键词命中情况
  • 业务权重
  • 时间衰减策略

对结果进行进一步筛选和排序。


3. 与搜索管道协同使用 #

Easysearch 通过搜索管道机制,可以在查询阶段自动完成:

  • 自然语言 → 向量转换
  • 查询增强与规则注入
  • 统一搜索策略管理

这使得向量检索的引入不会破坏原有搜索体系,而是作为能力叠加。


五、向量检索的应用场景 #

向量检索特别适合以下场景:

5.1 问答系统 #

用户使用自然语言提问时,向量检索可以将查询语义映射到内容向量空间,从而返回最相关的答案。

5.2 模糊语义搜索 #

用户用不同表达方式提问,但意图相同:

  • “怎么提升搜索速度?”
  • “搜索性能优化的方法有哪些?”

这类查询完全可以通过向量检索得到更理想的结果。

5.3 数据推荐与相似性计算 #

比如:推荐与当前文章语义相似的文章或日志。

5.4 客户工单智能匹配 #

当客服收到一条新工单:“页面加载慢,特别是在早上九点”,系统可通过向量检索自动匹配历史相似案例,辅助快速响应。

5.5 日志异常聚类与检索 #

运维人员输入“最近某个服务偶尔卡顿”,即可召回语义相近的日志条目,即使关键字不完全匹配。


六、总结 #

从“找得到”到“猜得准”,向量检索正在让搜索系统变得更像一个“懂你”的助手。Easysearch 将语义能力无缝融入现有搜索架构,既保留了关键词检索的精确性,又赋予系统理解自然语言的能力。这种平衡的设计理念,正是其在企业级场景中落地的关键所在。未来,随着大模型与向量技术的深度融合,我们有望看到更加智能、主动的搜索体验。