Weaviate Blog

Weaviate 1.39 Release

8.5内容质量
Weaviate 1.39 Release

TL;DR · AI 摘要

Weaviate 1.39发布Boost API和MMR多样性选择,4-bit量化预览提升搜索性能,开源社区功能持续优化。

核心要点

  • Boost API实现查询时动态重排序,支持过滤/数值衰减等条件组合
  • MMR多样性选择算法提升混合搜索结果的相关性与多样性
  • 4-bit旋转量化技术预览可减少30%存储占用

结构提纲

按章节快速跳转。

  1. 介绍1.39版本六大核心更新及性能优化方向

  2. 实现查询时动态重排序,支持过滤/数值衰减等条件组合

  3. ·MMR多样性算法

    通过相关性与多样性平衡提升搜索结果质量

  4. 新型压缩技术减少30%存储占用并保持精度

  5. 重构实现降低50%提交日志磁盘使用量

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • Weaviate 1.39新功能
    • 搜索优化
      • Boost API
        • 动态重排序机制
      • MMR多样性
        • 相关性-多样性平衡
    • 性能提升
      • 4-bit量化
        • 30%存储优化
      • HNSW快照
        • 50%日志压缩

金句 / Highlights

值得收藏与分享的关键句。

#Weaviate#搜索#AI#开源
打开原文

Weaviate 1.39 版本发布 | Weaviate

Weaviate 1.39 版本发布

2026年8月27日

·

1分钟阅读

Ivan Despot

开发者体验工程师

Weaviate v1.39 现已作为开源版本和 Weaviate Cloud 服务发布。

本次发布有两个搜索功能达到通用可用性:查询时重新排序的 Boost API,以及适用于混合搜索和向量搜索的最大边际相关性(MMR)多样性选择。另外新增两个功能:4位旋转量化(预览版)和实验性的 Search REST API。本文还涵盖了在 1.38 版本中悄然发布的 gRPC-Web,以及优化了提交日志磁盘使用并加速启动的 HNSW 快照重构。

以下是本次版本的主要亮点:

  • Boost API - 通用可用性
  • MMR 多样性选择 - 通用可用性
  • 4位旋转量化(预览版)
  • Search REST API(实验性)
  • gRPC-Web
  • 自动 HNSW 快照 - 通用可用性
  • 性能改进与修复
  • 社区贡献
  • 总结

Boost API - 通用可用性

在 v1.38 版本作为预览功能引入的 Boost API 现已正式发布。

Boost 是一个查询时重新排序的功能。主搜索获取候选结果后,Weaviate 会根据您的 Boost 条件对每个结果进行评分并重新排序。与过滤器不同,它不会移除任何内容:不匹配任何条件的对象会被降权,而不是被排除。这就是“只显示有库存的产品”和“优先显示有库存产品,但仍显示最佳匹配的缺货产品”之间的区别。

工作原理

Boost 可包含 1 到 20 个条件,共有四种类型:

  • filter:提升满足过滤条件的结果
  • property_value:按数值属性值排序
  • time_decay:优先考虑接近某个时间点的对象
  • numeric_decay:优先考虑接近目标数值的对象

两个权重控制结果。外层权重(默认 0.5)将 Boost 分数混合到原始相关性分数中:(1 - weight) * primary + weight * boost。每个条件有自己的权重(默认 1.0)。如果希望条件降权而非升权,可将权重设为负数。

第三个设置 depth(默认 100,受 QUERY_MAXIMUM_RESULTS 限制)表示主搜索在重新排序前获取的候选数量。通过 QUERY_BOOST_DEFAULT_DEPTH 可为整个集群调整此默认值。

以下是一个真实结果页面的示例。相同的查询在小型产品目录上运行两次:一次普通查询,一次使用优先显示有库存且近期发布的商品的 Boost:

code
from
datetime
import
timedelta
from
weaviate
.
classes
.
query
import
Boost
,
Filter
prefer_in_stock_and_recent
=
Boost
.
blend
(
[
Boost
.
filter
(
Filter
.
by_property
(
"in_stock"
)
.
equal
(
True
)
,
weight
=
2.0
)
,
Boost
.
time_decay
(
"released"
,
scale
=
timedelta
(
days
=
30
)
)
,
]
,
weight
=
0.3
,
# 30% boost, 70% original relevance
depth
=
200
,
# re-score the top 200 candidates
)
for
label
,
boost
in
(
(
"plain hybrid"
,
None
)
,
(
"with boost"
,
prefer_in_stock_and_recent
)
)
:
response
=
collection
.
query
.
hybrid
(
query
=
"wireless headphones"
,
limit
=
4
,
boost
=
boost
)
print
(
label
)
for
obj
in
response
.
objects
:
print
(
"  "
,
obj
.
properties
[
"title"
]
,
"| in stock:"
,
obj
.
properties
[
"in_stock"
]
)
code
plain hybrid
Kestrel 无线耳机 | 有货:True
Meridian 无线耳机 | 有货:False
Aurora 无线耳机 | 有货:False
Nimbus 无线耳机 | 有货:True
with boost
Kestrel 无线耳机 | 有货:True
Nimbus 无线耳机 | 有货:True
无线耳机 Pro | 有货:True
Meridian 无线耳机 | 有货:False

Nimbus 有货且已上架12天,因此从第四名升至第二名。耳机因相同原因位列第三,尽管文本匹配度较弱。两件缺货商品排名下降:Meridian 滑落至第四名,Aurora 被移出页面。两者均未从结果集中删除。Kestrel 作为最佳关键词和向量匹配,仍保持第一名。权重设为 0.3 时,70% 的评分由搜索本身决定。将权重提高至接近 1.0 时,库存和新鲜度将主导排序。将权重降低至接近 0.0 时,将恢复原始结果。

增强功能适用于 hybrid、bm25、near_text、near_vector、near_object、near_media 和 near_image,分别在 .query.* 和 .generate.* 命名空间中提供。该功能不适用于 fetch_objects,因为 fetch_objects 没有可融合的相关性评分。

增强功能在重排序器之前执行

如果同时使用 boost= 和 rerank=,重排序器将在增强后执行并重新排序结果,因此具有最终决定权。除非需要这种分层效果,否则建议只使用其中一种方式。

相关资源

  • 指南:搜索 - 增强结果
  • 指南:搜索 - 融合与权重

MMR 多样性选择 - 一般可用性 ​

MMR 多样性选择功能自 v1.37 版本预览以来,现已正式发布。该功能可与所有 near_* 搜索一起在混合搜索中使用。混合搜索支持并非 v1.39 新增功能,其在 v1.38.6 版本已引入,因此如果您使用的是近期 1.38 版本,已具备该功能。v1.39 的变化在于将该功能标记为成熟版本。

MMR 逐个选择结果。在每一步中,它会权衡两个因素:候选结果与查询的匹配程度,以及它与已选结果的差异性。最终会得到一个覆盖主题的第一页,而不是重复显示相同段落九次。这对混合搜索帮助最大。混合查询的关键词部分和向量部分往往倾向于选择相同聚类的近似相同段落,因此它们的合并前10名结果通常是系统中最重复的列表。

MMR 在查询管道的末期运行,位于两个部分合并之后、页面截断之前。如果使用重排序器,它会在 MMR 之后运行:

两个参数用于配置 MMR,但都容易设置错误。

balance 参数在相关性和多样性之间进行权衡。取值范围为 0.0 到 1.0,超出该范围的值会被拒绝。MMR balance 必须在 0 和 1 之间。当设置为 1.0 时,仅考虑相关性,结果顺序与不使用 MMR 时相同。当设置为 0.0 时,仅考虑多样性。因此,数值越低,结果越多样。默认值为 0.0,而非 0.5。如果省略 balance 参数,将使用最激进的设置,因此建议始终显式传递该参数。

MMR 选择结果的限制是页面大小,即返回结果的数量。MMR 从候选池中选择这些结果,而候选池的大小由查询本身的限制决定。MMR 的限制必须至少为 1,且不能超过查询限制。

以下是同一查询在三种不同设置下的结果。该集合包含文档片段,其中四个片段对碳定价的描述大致相同:

/think

code
from
weaviate
.
classes
.
query
import
Diversity
for
balance
in
(
1.0
,
0.3
,
0.0
)
:
response
=
collection
.
query
.
hybrid
(
query
=
"carbon pricing"
,
limit
=
8
,
# candidate pool
diversity_selection
=
Diversity
.
mmr
(
limit
=
4
,
balance
=
balance
)
,
# 4 returned
)
print
(
f"balance=
{
balance
}
"
)
for
obj
in
response
.
objects
:
print
(
"  "
,
obj
.
properties
[
"title"
]
)
code
balance=1.0
碳税与配额交易
碳定价基础
碳定价常见问题
什么是碳价格?
balance=0.3
碳税与配额交易
碳定价常见问题
碳定价基础
沿海城市适应资金
balance=0.0
碳税与配额交易
油气甲烷规则
沿海城市适应资金
可再生能源补贴与电网建设

当值为1.0时,结果是四种表述相同内容的页面,这与未使用MMR时的结果一致。当值为0.3时,重复结果中有一个被适应资金相关内容取代。当值为0.0时,相关性在首次选择后不再计算,碳定价查询返回了甲烷规则和电网建设相关内容。最后一个结果是未指定balance参数时的默认输出。

需要Python客户端4.23.0或更高版本。这是diversity_selection功能首次在collection.query.hybrid和collection.generate.hybrid中引入的版本。MMR在bm25搜索中不可用,因为bm25没有用于计算距离的向量,且在多向量集合中也无法使用。

  • 指南:搜索 - 多样性选择(MMR)
  • 指南:混合搜索 - 多样性选择(MMR)
  • 博客:混合搜索详解

4位旋转量化(预览) ​

旋转量化(RQ)通过两步缩小向量。首先将向量旋转,使值在各维度上均匀分布。然后将每个维度存储为小整数代码,而非32位浮点数。Weaviate已提供8位和1位RQ。v1.39版本新增4位量化作为预览功能。

4位相当于半个字节,两个维度可打包为一个字节。在1536个维度的情况下,这需要16字节的头部加上768字节的编码:每个向量占用784字节,而原始float32需要6144字节。因此体积缩小了7.84倍,而非整数的“8倍”,因为头部信息仍需保留。

通用格式为16 + ceil(outputDim / 2) 字节,其中outputDim = 64 * ceil(inputDim / 64)。旋转操作会将维度数向上取整到64的倍数。在1536维度时,由于1536正好是24×64,向上取整无需额外成本。但在1000维度时,需要支付1024维度的费用。

无需预览标志即可启用该功能。它是一个普通的模式值,设置向量索引的rq.bits = 4即可:

code
from
weaviate
.
classes
.
config
import
Configure
client
.
collections
.
create
(
"Doc"
,
vector_config
=
Configure
.
Vectors
.
text2vec_weaviate
(
name
=
"default"
,
source_properties
=
[
"title"
,
"body"
]
,
vector_index_config
=
Configure
.
VectorIndex
.
hnsw
(
quantizer
=
Configure
.
VectorIndex
.
Quantizer
.
rq
(
bits
=
4
,
rescore_limit
=
20
,
)
,
)
,
)
,
)

一旦在向量上首次启用RQ,bits值即被固定,之后无法更改。不存在从8位编码迁移到4位编码的机制,因此创建集合时需确定位宽。

如果不想按集合单独设置,管理员可通过设置集群范围默认值DEFAULT_QUANTIZATION=rq-4,使新向量索引默认使用4位量化。此时新建的HNSW索引将自动配置bits: 4和rescoreLimit: 20。Flat索引则保持原样。

4位量化仅适用于HNSW索引

code

平面索引仍然会拒绝该设置,要求RQ位必须为1或8,这一规则同样适用于动态索引的平面侧。在HNSW索引中使用4位。

与其他RQ宽度类似,4位宽度支持余弦、点积和L2平方距离度量方式。

预览功能

4位宽度是预览功能,其行为和默认值可能在未来版本中发生变化。

- 概念:向量量化 - 旋转量化
- 概念:向量量化 - 重评分
- 配置参考:向量索引参数

## 搜索REST API(实验性) ​

Weaviate目前提供两种搜索API。gRPC速度快,但需要生成的客户端和HTTP/2支持。GraphQL需要手动构建查询字符串,并从_additional字段中提取元数据。对于shell脚本、Lambda函数、边缘工作器、API网关或没有Weaviate客户端的语言来说,这两种方式都不够友好。

v1.39版本新增了实验性的Search REST API。您可以通过纯HTTP/1.1发送JSON请求并接收JSON响应,所有端点都通过OpenAPI规范进行描述,与REST API的其他部分保持一致。这种设计也更适合LLM工具调用,因为模型需要的是文档化的HTTP端点而非客户端库。

v1.39.0版本发布了第一个端点POST /v1/search/{collection}/near-text。v1.39.1补丁版本又新增了三个搜索端点和一个对应的聚合端点,因此在1.39.1或更新版本中您将获得全部五个端点:

- POST /v1/search/{collection}/near-text
- POST /v1/search/{collection}/bm25
- POST /v1/search/{collection}/hybrid
- POST /v1/search/{collection}/near-object
- POST /v1/aggregate/{collection}

以下示例使用near-text端点。

这些端点默认是关闭的。通过在每个节点上设置EXPERIMENTAL_REST_SEARCH_ENABLED来启用:

services : weaviate : image : cr.weaviate.io/semitechnologies/weaviate : 1.39.1 environment : EXPERIMENTAL_REST_SEARCH_ENABLED : 'true'

code

可接受的真值包括on、enabled、1和true。一个开关即可控制所有端点。当功能关闭时,路由仍然存在,但会返回422状态码并提示需要设置的变量名称,而非令人困惑的404错误。

请求体中的所有字段均使用驼峰命名法。对于near-text查询,query是必需的字符串数组,每个字符串代表一个待搜索的文本片段。发送单个字符串进行普通搜索,发送多个字符串时Weaviate会将它们平均为一个搜索向量。您还可以指定certainty或distance(不可同时指定)、targetVector、where、limit、offset、autoLimit、returnProperties、returnMetadata、tenant和consistencyLevel参数。

curl -s -X POST http://localhost:8080/v1/search/Movie/near-text \ -H 'Content-Type: application/json' \ -d '{"query":["spaceship galaxy"],"limit":3, "returnProperties":["title","hasAuthor.name"], "returnMetadata":["distance"]}'

code

响应格式为{results, tookMs}。每个搜索结果都以相同的平面结构返回{id, properties, references, metadata}:

{ "results" : [ { "id" : "2aeb3309-33e7-4a8d-a8e2-6413b53890d8" , "properties" : { "title" : "spaceship galaxy adventure" } , "references" : { "hasAuthor" : [ { "name" : "famous writer" } ] } , "metadata" : { "distance" : 0.07182336 } } ] , "tookMs" : 2 }

code

当查询不涉及引用字段时,references字段会被省略;当仅请求id时,metadata字段会被省略。向量数据永远不会返回。

发生错误时,会返回标准格式的{"error": [{"message": "..."}]}响应体。

实验性功能意味着其结构仍可能发生变化

此 API 默认处于关闭状态,其请求和响应结构尚未固定。参考选择功能最有可能发生变化。在 v1.39 版本中,您需要通过在 returnProperties 中使用点号表示法(如 "hasAuthor.name")来请求引用属性,且仅支持单层深度。这种格式即将被替换,因此请做好更新相关实现的准备。

目前尚无官方客户端封装此接口。所有 Weaviate 客户端均使用 gRPC 进行搜索,因此现阶段您需要通过 curl 或原始 HTTP 访问该接口。Boost、MMR、重排序、生成式搜索和 group-by 功能在 REST 接口上均不可用。

- 参考资料:RESTful API - 搜索端点
- 环境变量:EXPERIMENTAL_REST_SEARCH_ENABLED

## gRPC-Web

浏览器无法直接使用纯 gRPC 协议,因此前端代码一直无法直接调用 Weaviate 的 gRPC API。gRPC-Web 通过普通 HTTP 提供相同 API,填补了这一空白。该功能在 v1.38.3 版本中引入,此前的版本说明中未进行过介绍。

该接口位于与 REST API 相同端口(默认 8080)的 /v1/grpc-web/ 路径下。它不使用 gRPC 端口,也不使用独立端口,因此无需在防火墙或入口规则中额外开放端口。

该功能默认处于启用状态。如需关闭,将运行时配置键 grpc_web_enabled 设置为 false。该键使用 snake_case 命名格式,且没有对应的环境变量。配置变更无需重启即可生效。当接口关闭时,对 /v1/grpc-web/ 路径的请求将返回标准 404 错误,与 Weaviate 不提供服务的其他路径行为一致。REST API 的其余功能不受影响。

需要注意的是:目前所有 Weaviate 客户端库均通过纯 gRPC 连接,因此尚未使用此接口。

- 参考资料:gRPC API - gRPC-Web

## HNSW 快照,自动 - 一般可用性

HNSW 索引在启动时会通过重放其提交日志(记录图结构所有变更的仅追加写前日志)进行重建。快照是该图结构的压缩镜像,因此启动时只需加载一个文件,而无需重放数百万条记录。此前快照仅作为可选缓存:您需要通过少量环境变量进行调度,且日志文件会永久保留在磁盘上。这意味着您需要为相同图结构支付两次存储费用。

在 v1.39 版本中,快照功能已实现自动化并进入一般可用阶段。Weaviate 会在后台自动创建和刷新快照,当新快照安全写入磁盘后,会删除所有该快照覆盖的提交日志。您将获得以下优势:

- 更少磁盘占用:您只需保留快照文件和快照后的写入数据,而非快照文件和完整历史记录。在向量密集型集群中,这能带来显著的存储节省。
- 启动更快更稳定:加载快照在每次重启时耗时基本一致。而重放持续增长的日志文件耗时会不断变化。
- 无需调优:没有快照相关环境变量,也无需设置调度计划。Weaviate 会自主决定何时创建新快照。

关于磁盘节省的两个注意事项:清理操作仅针对已加载的分片执行,因此不活跃租户的旧文件会一直保留到下一次使用。快照期间磁盘使用量会暂时上升,因为 Weaviate 会在删除旧文件前先写入新文件。请保留当前的磁盘余量空间。

原先用于控制快照的五个配置项现已失效。Weaviate 仍会接受这些配置项,但将在未来版本中移除:

PERSISTENCE_HNSW_DISABLE_SNAPSHOTS PERSISTENCE_HNSW_SNAPSHOT_INTERVAL_SECONDS PERSISTENCE_HNSW_SNAPSHOT_ON_STARTUP PERSISTENCE_HNSW_SNAPSHOT_MIN_DELTA_COMMITLOGS_NUMBER PERSISTENCE_HNSW_SNAPSHOT_MIN_DELTA_COMMITLOGS_SIZE_PERCENTAGE

code

设置其中任何一个配置项会在启动时记录一条警告信息,而不是直接失败,因此升级时不会因过时的配置文件而中断。您可以在合适的时候删除这些配置项。唯一保留的HNSW持久化设置是:PERSISTENCE_HNSW_MAX_LOG_SIZE(默认值500MiB)。该配置项设置的是预写日志的轮转大小,与快照无关,且仍然有效。

- 概念:存储 - HNSW快照

- 环境变量:PERSISTENCE_HNSW_MAX_LOG_SIZE

## 性能改进与修复 ​

除主要特性外,v1.39版本还包含大量改进。其中几个值得关注:

- 更快的关键词搜索:经过评分路径优化后,bm25查询和混合搜索中的关键词部分响应速度显著提升。

- 跨属性关键词AND:新的AndCross搜索操作符要求每个查询词必须出现在对象的某个位置,而非全部出现在单个属性中。该功能在1.38版本中已发布,为可选功能,因此普通And操作仍保持当前行为。

- 更高效的异步复制:在多租户集群中,后台修复操作减少了冗余工作。修复功能现在可以防止首次扫描时删除对象重现、防止修复覆盖更新的本地写入、防止租户关闭时内存泄漏。

- 更轻量的HFresh:HFresh向量索引占用内存更少,磁盘写入频率更低。

- 更可靠的备份:在Azure上列出备份时不再扫描所有对象,恢复操作不再强制加载延迟加载的分片,现在可以设置增量备份去重的文件数量。

- 更安全的副本迁移:节点间迁移副本现在使用硬链接,不再暂停压缩操作。与正在进行的迁移冲突的模式变更会被拒绝,同一分片上的两个复制操作不再相互干扰。

- 毫秒级以下延迟指标:HTTP和gRPC请求持续时间直方图现在包含低至100µs的桶,快速查询不再全部落在单个桶中。

- 批量删除返回422:包含缺失匹配字段的批量删除现在返回422 Unprocessable Entity,而非500错误。

- Weaviate 1.39:GitHub发布说明

## 社区贡献 ​

Weaviate是开源项目,本次发布包含五位首次贡献者的成果。感谢以下贡献者:

- @hashkanna :为text2vec-google模块添加位置配置( #8418 )

- @vjsai :在分片配置中拒绝负数desiredCount( #11824 )

- @Joe-Weaviate :使用automaxprocs设置GOMAXPROCS,添加cgroup v2支持( #11918 )

- @VihaanAgarwal :修复命名向量集合的对象写入路径( #11919 )

- @apoorva-01 :为包含缺失匹配字段的批量删除返回422( #12049 )

如需贡献代码,请查看贡献者指南和GitHub上的good-first-issue标签。

## 总结 ​

Weaviate v1.39将两项搜索功能提升为通用可用,预览第三项功能,并实现HNSW快照自动化。

主要亮点:

- 提升API(GA):跨混合、关键词和向量搜索的查询时重新评分,可提升或降低结果排名而不丢失任何结果

- MMR多样性选择(GA):在混合和near_*搜索中实现多样性选择,使第一页结果覆盖主题而非重复内容
  • 4位旋转量化(预览):在HNSW索引中,每个1536维向量占用784字节,体积仅为原始float32的1/7.84
  • 搜索REST API(实验性):基于纯HTTP/1.1的JSON协议,默认关闭。v1.39.0版本新增near-text功能,v1.39.1版本新增bm25、混合搜索、near-object以及聚合接口
  • gRPC-Web:可通过普通HTTP在浏览器访问的gRPC接口,默认从REST端口启用(自v1.38.3版本起)
  • HNSW快照(通用版):减少提交日志磁盘占用,提升启动速度和稳定性,移除5个调优参数,无需任何调度任务

准备好开始了吗?

该版本已开源发布在GitHub,也可在Weaviate Cloud上使用,可直接创建免费层级的集群

注意

Weaviate Cloud可能不支持所有功能。预览版和实验性功能、需要特定环境配置的功能可能在托管集群中不可用,或采用不同发布时间表

如需升级自托管集群,请查阅迁移指南获取版本特定说明

感谢阅读,祝你向量搜索愉快!

准备开始构建了吗? ​

查看快速入门教程,或注册Weaviate Cloud免费账户

GitHub

论坛

X(推特)

不想错过任何博客文章?

订阅我们的双周刊通讯以获取最新动态!

通过提交,我同意

服务条款