Manticore Search 28.4.4 已发布。此次发布带来了更快的 KNN 重评分、更灵活的对话式搜索、更简单的安装和升级路径、更好的 faceting 控制、按表设置的相关性默认值,以及在认证、复制、SQL 兼容性、分布式查询和 columnar/KNN 内部实现方面的修复。
本文回顾了从 27.2.0 到 28.4.4 之间发布的所有内容。
升级说明
升级前请先查看这些内容:
- 28.0.0 将插件 ABI 版本
SPH_UDF_VERSION提升到了 12。 在将外部 UDF、ranker 和 token-filter 插件二进制文件加载到此版本之前,必须先重新编译。这个变更允许 token-filter 插件接收长的dict=keywords_32k令牌,而不会再静默跳过超过旧的 126 字节插件限制的值。现有表数据和配置仍然兼容,无需迁移索引。如果你同时恢复为针对旧 ABI 构建的插件二进制文件,并且不依赖新的长令牌插件行为,则可以降级。(Issue #4667 , PR #4668 ) - 如果启用了认证,请优先升级到 28.4.x。 28.4.2 修复了 MySQL 多语句执行中的认证/授权权限检查绕过问题。28.3.4 还改进了对 Connector/J 和 PyMySQL 的已认证 MySQL 启动兼容性,28.4.1 则通过将存储的复制用户持久化到集群元数据中,修复了已认证复制集群的重启恢复问题。(PR #4713 , Issue #4691 , Issue #4705 )
- 如果你将 MCL 独立于守护进程管理,请在升级 Manticore 时一并升级它。 这条发布线包含 MCL
13.7.0、新的
embeddings_threads设置,以及若干 columnar/KNN 的构建、打包和清理修复。不建议将旧版库与新版守护进程混用。(PR #169 , PR #186 , PR #4676 )
亮点
更快的 KNN 重评分
KNN 搜索
现在会在 rescore 阶段批量计算距离。HNSW 返回候选集后,Manticore 会重新计算最终的全精度距离并对结果重新排序。把这部分工作批量处理后,可以降低向量搜索最后阶段的每个候选项开销。
对于以向量为主的工作负载,这会把工作量从候选项筛选之后的查询部分中移走。结果不会改变;只是当需要重评分的候选项很多时,最终排名阶段的开销更小了。
通过 SQL 和 HTTP 的对话式搜索
对话式搜索
现在既可以通过 /search JSON API 使用,也可以通过 SQL CALL CHAT 使用。这让已经通过 HTTP API 与 Manticore 交互、又不想只为了聊天请求额外增加一条 SQL 路径的应用,更容易接入 Manticore 的聊天流程。
CREATE CHAT MODEL 现在也支持 custom_prompt,因此答案可以遵循应用特定的指令,例如引用规则、语气、回复长度或格式要求。该功能仍然建立在同一套 Manticore Search 流程之上:从已有的向量化表中检索相关文档,构建上下文,保留对话历史,并返回带有支持来源的答案。
一行安装与版本选择
现在快速开始的安装路径更简单了:
curl https://manticoresearch.com | sh
同一套安装器流程还可以升级现有安装、列出可用版本、在稳定版和开发版仓库之间切换,以及安装指定版本。包管理器仍然是已安装文件、仓库、服务和依赖项的最终来源;新的启动路径只是去掉了围绕这些内容的手工设置步骤。
如需查看所有选项,请运行:
curl https://manticoresearch.com | sh -s help
Facet 可以保留零计数分桶可见
分面搜索
现在通过 SQL ZEROES 和 JSON "zeroes": true 支持零计数 facet 分桶。
这是一个小而重要的 UI 功能。在电商式筛选中,你通常希望某个选项即使在当前筛选组合下计数为 0 也继续可见。结合 max 模式的 facet 行为,零计数分桶可以更容易地同时展示已选、可用以及当前不可用的选项,而不会把部分筛选词汇从用户面前隐藏起来。
更好的搜索相关性默认值
Manticore 现在支持 CREATE TABLE ... profile='relevance'
,并支持为 ranker
和 boolean_mode
保存按表的默认值。
根据我们的相关性测试,profile='relevance' 会为典型搜索工作负载应用更好的全文默认值,因此新表可以直接获得更强的排序行为,而不必让每个应用查询都重复设置相同选项。
这也让相关性设置成为表定义的一部分。如果一张表本来就应该表现得像一张针对相关性调优的全文搜索表,那么这个选择现在会写在 schema 里,而不是隐藏在应用代码中。
对 embedding CPU 使用的更多控制
embeddings_threads
限制用于自动 embedding 插入、ALTER TABLE ... REBUILD KNN 以及文本转向量 KNN 查询的 CPU 线程数。
这对共享主机和混合负载很重要。embedding 生成和 KNN 重建都可能非常吃 CPU;在服务器级别限制线程数,可以更容易地安排这些任务,而不会让它们占满整台机器。
Bug 修复
这条发布线包含 17 个 changelog 中列出的修复。最重要的有:
- 28.4.3 修复了围绕
COUNT(DISTINCT ...)的不兼容多语句处理问题,避免了多查询结果处理中错误的状态延续和行集损坏。 - 28.4.2 修复了 MySQL 多语句执行中的认证/授权权限检查绕过问题,因此多语句请求中的每条语句都会在认证下被正确验证。
- 28.4.1 和 28.3.1 修复了复制集群恢复的边界情况:已认证的集群重启恢复,以及节点在集群中只剩自己时的启动问题。
- 当分布式查询包含远程 stored fields 时,如果远程
GETFIELD读取出错或回复格式错误,现在会直接失败,而不是返回看似成功但 stored-field 值为空或不可信的结果行。 - 被中断的 columnar/KNN 合并清理现在会删除跟踪的临时前缀下的临时组件文件,防止残留的
.tmp.spc.*文件破坏后续的表重命名、附加或删除操作。 - 通过接受
SELECT查询中的简单单表别名,改进了与 DBeaver 的兼容性。 - Connector/J 和 PyMySQL 客户端现在可以完成已认证的 native-password 登录流程,而且在认证下,某些无害的会话
SET语句也不再失败。 - 内置的乌克兰语词形还原器现在能正确规范化带撇号的词形,因此像
здоров'ям这样的形式在lemmatize_uk_all下可以匹配здоров'я。 - AOT 混合关键词处理现在会遵循配置的
blend_mode,从而在索引和关键词提取时一致地恢复去分隔符后的变体。 - RT 自动优化现在不会把表压缩到少于两个磁盘 chunk,除非明确请求更低的下限。
- 修复了在多 chunk RT 表上,同一个
/search请求里同时包含percentiles聚合和 terms 聚合时可能触发的崩溃。 - 较长的 SQL 解析错误现在会保留 UTF-8 字符边界,因此包含西里尔字母和其他多字节文本的非法查询不再会生成被截断或损坏的错误信息。
完整列表请参见 changelog 。
需要帮助或想联系我们?
- 加入我们的 Slack
- 访问 Forum
- 在 GitHub 上报告问题或提出功能建议
- 给我们发邮件:
[email protected]

