Easysearch 2.4.0 的核心变化，不只是增加一种向量字段或查询接口，而是把基于 Lucene 的原生 HNSW 向量搜索纳入内核，让关键词召回与语义召回可以在同一套搜索基础设施中组合使用。与此同时，Mapping、集群配置、生命周期策略、快照、密钥库和插件等管理能力也得到更新，重点解决搜索系统从“能跑”走向“可长期维护”的问题。
原生 HNSW 改变了哪些事情
传统关键词检索擅长处理产品型号、专有名词、错误码和精确短语，但很难识别不同表述背后的相同意图。例如，“硬盘空间不足”和“节点磁盘快满了”在词面上差异较大，语义上却高度相关。
Easysearch 2.4.0 将基于 Lucene 的原生 HNSW 引入内核后，可以使用近似最近邻搜索召回语义相近的文档。HNSW 通过构建多层邻接图，避免查询时对全部向量进行逐一比较，更适合大规模、低延迟的向量检索。
它带来的工程价值主要有三点：
- 统一存储和检索链路：结构化字段、文本倒排索引和向量索引可以放在同一搜索系统中管理。
- 降低系统拼接成本：不必仅为了语义搜索额外维护一套独立向量数据库及同步链路。
- 支持混合召回：关键词搜索负责精确命中，向量搜索负责语义扩展，两者可以互相补足。
不过，原生向量能力并不意味着所有查询都应改成向量查询。SKU、订单号、日志错误码等字段仍应优先使用 term、match_phrase 或过滤条件；向量检索更适合知识库、商品描述、工单和自然语言问答。
混合检索的重点是融合，而不是简单相加
混合检索通常包含两条召回通道：
- BM25 等关键词检索返回文本相关结果；
- HNSW 返回与查询向量距离较近的结果；
- 系统对两组候选结果进行融合、过滤和重新排序。
直接把两种分数相加往往不稳定，因为 BM25 分数与向量相似度不在同一数值空间。实践中可以使用归一化加权，也可以采用 RRF（Reciprocal Rank Fusion，倒数排名融合）。RRF 只依赖排名，对分数量纲不敏感，适合作为第一版混合检索方案。
下面给出一个可以改造的最小示例。假设当前部署提供 Elasticsearch 风格的索引与 _search 接口；向量字段类型、HNSW 参数名和 knn 请求结构应以实际 Easysearch 2.4.0 部署支持的接口为准。 运行前需要把 ES_URL、认证信息、向量维度和示例向量替换为实际值。
#!/usr/bin/env bash
set -euo pipefail
ES_URL="${ES_URL:-http://localhost:9200}"
INDEX="${INDEX:-hybrid-demo}"
AUTH_USER="${AUTH_USER:-admin}"
AUTH_PASS="${AUTH_PASS:-admin}"
curl -sS -u "$AUTH_USER:$AUTH_PASS" \
-X PUT "$ES_URL/$INDEX" \
-H 'Content-Type: application/json' \
-d '{
"mappings": {
"properties": {
"title": {"type": "text"},
"content": {"type": "text"},
"category": {"type": "keyword"},
"embedding": {
"type": "dense_vector",
"dims": 4,
"index": true,
"similarity": "cosine"
}
}
}
}'
curl -sS -u "$AUTH_USER:$AUTH_PASS" \
-X POST "$ES_URL/$INDEX/_doc/1?refresh=true" \
-H 'Content-Type: application/json' \
-d '{
"title": "节点磁盘告警处理",
"content": "检查磁盘水位、分片分布以及生命周期清理任务。",
"category": "operations",
"embedding": [0.12, 0.78, 0.31, 0.45]
}'
curl -sS -u "$AUTH_USER:$AUTH_PASS" \
-X POST "$ES_URL/$INDEX/_search" \
-H 'Content-Type: application/json' \
-d '{
"size": 5,
"query": {
"multi_match": {
"query": "磁盘空间不足",
"fields": ["title^2", "content"]
}
}
}'
curl -sS -u "$AUTH_USER:$AUTH_PASS" \
-X POST "$ES_URL/$INDEX/_search" \
-H 'Content-Type: application/json' \
-d '{
"size": 5,
"knn": {
"field": "embedding",
"query_vector": [0.10, 0.80, 0.28, 0.47],
"k": 5,
"num_candidates": 50
}
}'
生产环境中，查询向量应由同一个 embedding 模型生成，索引和查询两侧必须保持模型版本、维度及归一化方式一致。更换模型时不要直接混写新旧向量，较安全的做法是创建新字段或新索引，完成回填和评估后再切换别名。
如果服务端暂未采用统一的混合查询语法，也可以在应用层使用 RRF 融合两组结果：
from collections import defaultdict
def rrf(keyword_hits, vector_hits, rank_constant=60):
scores = defaultdict(float)
documents = {}
for hits in (keyword_hits, vector_hits):
for rank, hit in enumerate(hits, start=1):
doc_id = hit["_id"]
scores[doc_id] += 1.0 / (rank_constant + rank)
documents[doc_id] = hit
return [
{
"_id": doc_id,
"rrf_score": score,
"source": documents[doc_id].get("_source", {}),
}
for doc_id, score in sorted(
scores.items(), key=lambda item: item[1], reverse=True
)
]
if __name__ == "__main__":
keyword_hits = [
{"_id": "1", "_source": {"title": "磁盘空间不足处理"}},
{"_id": "2", "_source": {"title": "节点巡检手册"}},
]
vector_hits = [
{"_id": "2", "_source": {"title": "节点巡检手册"}},
{"_id": "3", "_source": {"title": "分片容量规划"}},
]
for item in rrf(keyword_hits, vector_hits):
print(item)
真实业务还应在融合前加入租户、权限、时间范围和文档状态过滤，避免语义召回绕过业务边界。
管理升级不只是界面变化
Easysearch 2.4.0 的控制台新增可视化 Mapping 编辑器。它对字段较多、索引模板复杂的团队尤其有用：开发者可以更直观地检查字段类型、嵌套关系和索引选项，减少手写 JSON 时出现层级或拼写错误的概率。
Mapping 仍然属于需要严格评审的基础设施配置。可视化编辑器不能替代版本控制，推荐把控制台用于设计和检查，再将最终配置导出或同步到代码仓库，通过测试环境验证后发布。需要重点检查：
- 向量维度是否与 embedding 模型输出一致；
- 字符串字段应该使用
text、keyword，还是同时使用多字段； - 不需要检索的字段是否可以关闭索引以节省空间；
- 动态 Mapping 是否可能因为异常数据造成字段膨胀；
- Mapping 变更是否需要新建索引并执行 reindex。
集群设置页面现在能够同时查看临时、持久和默认三层配置，这有助于排查“重启后参数失效”或“配置值与预期不一致”等问题。诊断时应明确最终生效值来自哪一层，而不是只看某一次 API 修改的结果。
生命周期、快照和资源分析共同决定可维护性
版本还同步更新了生命周期策略、可搜索快照、密钥库和插件管理。这些功能看似分散，实际上覆盖了搜索平台的完整运维链路：
- 生命周期策略控制索引如何滚动、迁移和删除；
- 可搜索快照在数据保留成本与查询能力之间提供新的选择；
- 密钥库用于管理不适合明文写入配置文件的敏感信息；
- 插件管理影响节点能力、版本兼容性和升级流程。
此外，高并发下字段使用统计和磁盘用量分析更稳定，能够帮助团队识别低价值字段、索引膨胀和容量热点。但这类统计也不应被当作瞬时真相：应在典型业务周期内观察趋势，并结合查询日志、分片分布和生命周期策略一起判断。
升级前后的检查清单
建议不要在升级完成后立即把全部流量切换到向量检索。更稳妥的推进方式是：
- 先选择一个有明确相关性评估集的知识库或站内搜索场景；
- 对关键词、纯向量和混合检索分别测试 Recall@K、MRR 或 NDCG；
- 压测索引写入、HNSW 构建、查询延迟和内存占用；
- 确认向量字段增加后的磁盘容量与快照耗时；
- 记录 embedding 模型版本，并设计重新生成向量的迁移方案；
- 检查临时、持久和默认集群配置，避免升级后参数漂移；
- 审核插件兼容性、密钥库内容和生命周期策略；
- 使用灰度索引或别名切换，保留快速回滚路径。
Easysearch 2.4.0 最值得关注的，是搜索能力与管理能力同时向前推进。原生 HNSW 让语义检索进入核心链路，而 Mapping、配置分层、生命周期和资源分析的改进，则让这条链路更有机会稳定运行在生产环境中。真正的收益取决于相关性评估、容量规划和运维治理，而不是单纯把向量字段加入索引。