Elasticsearch:默认更轻量 - 从 source 中排除向量
作者:来自 Elastic Jim Ferenczi
Elasticsearch 现在默认从 source 中排除向量,在需要时仍可访问向量,同时节省空间并提升性能。
使用这种针对 Search AI 的自定进度动手学习,亲自尝试矢量搜索。您可以立即开始免费的云试用或在本地计算机上试用 Elastic。
为什么要更改默认设置?
到目前为止,Elasticsearch 会同时把向量存储在 doc_values(用于相似度搜索)和 _source(用于检索)中。然而,大多数向量工作负载在搜索响应里并不需要原始向量,只需要 top-k 结果和少量元数据字段。
把大型向量存两份是浪费的。这会增加索引大小、减慢索引速度,并让搜索响应变大。在大多数情况下,用户甚至没意识到自己在每个文档中检索了多 KB 的向量。
这一变化避免了重复,同时保留了 Elasticsearch 的优势:对存储在 _source 中的结构化元数据(比如标题和 URL)的快速访问。
一次罕见但必要的更改
我们通常不会在小版本或 Serverless 环境中引入破坏性更改。但在这种情况下,我们确信好处远远大于影响。
我们看到许多用户因为向量默认被存储和返回而遇到性能问题或响应过大的情况。与其要求额外配置,我们选择把高效的路径设为默认:
"index.mapping.exclude_source_vectors": true
无论你是在 Serverless、ESS,还是自管部署中使用 Elasticsearch,这个设置现在都会对所有新建索引默认启用。
现有索引不受影响。对于在此更改之前创建的索引,该设置依然为 false,向量字段会像之前一样继续存储并在 _source 中返回。
回填:它就是能用
回填(Rehydration)意味着 Elasticsearch 可以在需要时把已索引的向量重新加入 _source,即使它并没有存储在那里。这会在以下情况自动发生:
-
部分更新
-
重建索引
-
恢复
即使向量不再物理存储在 _source 中,这些工作流依然能无缝运行。
你也可以在搜索请求中使用 _source 选项手动触发回填(见下文)。
精度取舍
Elasticsearch 在内部将向量存储为 32 位浮点数,这也是索引和相似度搜索时使用的格式。然而,在 JSON 中提供的向量可能是更高精度的类型,比如 double 甚至 long。
当 _source 不再存储原始输入时,任何回填的向量都会反映用于索引的 float 表示。在几乎所有用例中,这就是搜索和评分所需要的。
但如果你需要保留精确的输入精度 —— 例如必须检索原始的 double 值而不是索引时的 32 位浮点数 ——
你就必须在创建索引时禁用这个设置:
"index.mapping.exclude_source_vectors": false
这可以确保原始向量值保存在磁盘上的原始 _source 中。
在需要时访问向量字段
如果你的应用需要在搜索响应中获取向量值,你可以显式地检索它们。
- 使用 fields 选项:
POST my-index/_search
{
"fields": ["my_vector"]
}
在 hits 旁返回已索引的向量字段,而不在 _source 中。
- 重新启用 _source 中的向量包含:
POST my-index/_search
{
"_source": {
"exclude_vectors": false
}
}
此选项会将已索引的向量字段回填到该响应的 _source 中。
影响是什么?
我们使用 OpenAI Vector Rally 赛道对这一变化进行了基准测试。
突出结果:
从_source中排除载体的影响。
这带来了:
-
更快的索引
-
更少的磁盘 I/O
-
降低资源使用
尤其是在高量向量工作负载中。
最终想法
Elasticsearch 是一个功能齐全的向量搜索引擎,我们致力于确保它默认情况下运行良好。这一变化消除了大多数用户甚至未察觉的低效,同时保留了所有功能。
你仍然可以通过 _source 快速访问元数据,更新和恢复行为无缝,并且在需要时选择返回向量值。如果精确保留原始向量很重要,这种灵活性依然支持,你只需选择启用。
对大多数用户来说,开箱即用的效果会更好。
原文:Lighter by default: Excluding vectors from source - Elasticsearch Labs

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
.NET GcPDF V8.2 新版本:人工智能 PDF 处理
一、GcPDF 产品简介 GcPDF(GrapeCity Documents for PDF)是葡萄城(GrapeCity)推出的一款功能强大的 .NET PDF 开发组件,旨在为开发人员提供高效、灵活的 PDF 文档处理解决方案。无论是创建全新 PDF 文档、编辑现有 PDF 内容,还是进行 PDF 转换、批注、签名、表单处理等操作,GcPDF 均能通过简洁易用的 API 实现,广泛适用于企业级报表生成、文档管理系统、电子合同签署、金融票据处理等各类业务场景。 作为 .NET 生态下的成熟 PDF 组件,GcPDF 具备跨平台特性,支持 .NET Framework、.NET Core、.NET 5+ 及以上版本,可在 Windows、Linux、macOS 等操作系统中稳定运行,同时兼顾高性能与低内存占用,能轻松应对大规模 PDF 文档的批量处理需求,帮助开发团队快速构建专业的 PDF 相关应用。 二、GcPDF V8.2 新特性:AI 驱动的 PDF 处理 V8.2 版本新增了功能强大的软件包 GcPDF AI ,该软件包旨在展示 GcPDF 如何与 AI 服务集成,进而优化 P...
-
下一篇
TDS数据治理深度实践:从标准化到智能化的演进之路
TDS数据治理深度实践:从标准化到智能化的演进之路 TDS(Turing Data Studio)是专注于数据开发和治理的平台。其架构涵盖了从基础设施到用户功能的各个层次,包括数据开发、数仓管理、监控运维和资源管理等模块,支持高效的任务调度、资源管理和数据血缘分析。 上一代大数据产品在实际运行中仍存在以下关键问题: 1. 开发阶段风险控制不足: 数据开发任务经过修改调试后,会直接用于处理线上数据,存在误操作直接影响线上数据的隐患。 2. 产出阶段质量保障滞后: 数据产出质量。需要等数据完全产出后,通过人工校验或下游反馈发现,无法在数据产出过程中实时拦截空值、异常值等问题。 数据产出时效性。任务执行达到重试失败上限或触发延迟产出报警后,数据RD才能收到通知,难以有效维持数据时效性。 3. 运维阶段处理低效: 日志分析有时需要值班同学帮助查看定位原因排查问题,依赖人工经验,处理问题效率较低。 数据产出异常时,由于涉及的类型和层级较多,难以快速准确识别下游受损范围,并导致未及时回溯数据。 为了解决上述问题,TDS建设了体系化的数据治理方案。 流程标准化(规范开发)→ 质量可控化(主动防控)→...
相关文章
文章评论
共有0条评论来说两句吧...