xerj v0.6.2 发布解读：向量持久化、kNN 删除一致性、按需段校验与 PIT 生命周期治理

人工智能搜索引擎本地部署后端MCP 服务【免费下载链接】xerjXERJ is the new way for AI to search data. Its autoindex capability activates agents to know your data without the token waste of grep and sed. One command indexes code, docs, logs and PDFs for search, RAG, security audits and agent memory, using 40x fewer tokens than grep. Elasticsearch compatible, so existing clients just work.项目地址https://gitcode.com/GitHub_Trending/xe/xerj点击查看免费下载xerj v0.6.22026-04-25是一次面向生产环境的正确性 有界资源版本围绕向量存储落地了四项关键能力HNSW 图跨重启持久化、删除操作真正传播进 kNN 图、可随时触发的段完整性 fsck以及为 Point-in-TimePIT上下文引入 TTL 与后台回收。本文基于仓库中的版本说明展开并结合xerj-vector、xerj-engine、xerj-api、xerj-storage、xerj-common的源码实现逐项讲解这四项变更的原理、配置与升级影响帮助运维与开发者理解为何 v0.6.2 是向量索引正确性的一个关键里程碑。版本概况四项生产优先项全部落地v0.6.2 完成了PATH_TO_100_PCT_v0.6.0_to_v1.0.md规划中的全部四项交付项直接消除 v0.6.0 公平性评审中暴露的三类正确性问题P1HNSW 图持久化重启不再从 WAL 逐条重建P2删除操作在 kNN 图中打墓碑tombstone搜索结果与邻居候选同时跳过已删节点P3按需段 fsck 端点POST /{index}/_admin/segments/fsckP4PIT 上下文 TTL 与后台回收器杜绝上下文无限累积。同期ES YAML 兼容性测试通过数为1305 / 132998.2%处于历史 1302–1306 的波动区间内无回归。P1HNSW 图跨重启存活变更动机v0.6.2 之前HNSW 图只存在于内存中每次重启都要扫描 WAL 并重新插入全部向量来重建图。对百万级向量索引而言启动耗时为分钟到小时级别更糟的是若在 flush 之后、重启之前发生崩溃WAL 已被检查点越过插入记录图可能彻底丢失。新行为现在图与doc-id ↔ node-id映射会在每次_flush时随段一起持久化到index_dir/hnsw/目录下index_dir/hnsw/graph.bin # HNSW 图xerj-vector 格式CRC32C 校验 index_dir/hnsw/ids.json # { next_id, map: { doc_id: node_id, ... } }布局与写入逻辑见 engine/crates/xerj-engine/src/index.rssave_hnsw_to_disk在 flush 完成与优雅停机时调用通过临时文件 fsync rename 父目录 fsync 的原子持久化方式写入xerj_common::fsio::write_file_durable保证崩溃或断电时要么保留旧文件、要么保留完整新文件。重启后直接加载字节一致的图耗时从分钟到小时降为秒级。文件格式 v2XHNS0001图文件格式在 engine/crates/xerj-vector/src/hnsw.rs 中定义const HNSW_MAGIC: [u8; 8] bXHNS0001; const HNSW_FORMAT_VERSION: u32 2;v2 新增尾部墓碑块u32 num u64 × num即删除标记列表直接随图持久化hnsw.rs加载器兼容 v1v1 文件没有墓碑块按空墓碑集处理hnsw.rsCRC32C 校验load_from在读取前对整个载荷做 CRC 校验任何不一致magic 错误、版本越界、CRC 不匹配都返回Err由调用方回退到 WAL 重放重建绝不静默加载损坏图hnsw.rs。加载失败采用非致命策略打一条warn!()日志并回退到 WAL 重放重建。单元测试save_load_roundtrip验证保存后重载的图对同一查询返回相同邻居集hnsw.rsload_rejects_corrupt_file验证损坏文件被拒绝hnsw.rs。P2删除传播进 kNN 图变更动机v0.6.2 之前存在一个隐蔽的一致性漏洞文档被删除后_get/_search已经查不到它但它的向量会永远出现在 kNN 结果中——因为节点与其邻居边仍留在图里。新行为删除路径现在会为对应的 HNSW 节点打墓碑搜索时该节点既不会作为结果返回也不会作为 kNN 邻居候选墓碑随图持久化格式 v2跨重启保留。实现位于 engine/crates/xerj-engine/src/index.rs删除文档时通过hnsw_id_map找到节点 ID调用HnswIndex::mark_deleted(node_id)打墓碑随后从 id 映射中移除条目使同一doc_id重新索引时获得全新节点 ID旧节点保持墓碑状态。mark_deleted本身是幂等的见 hnsw.rs。在 HNSW 图内部被墓碑标记的槽位仍参与遍历保持图结构连通但不会作为结果返回hnsw.rs。这里有一个明确的取舍需要运维知晓边不会被重连。持续的删除负载会让召回率以每遍历步约一次位向量查找的速度缓慢下降如果删除量很大建议重建索引。边重连与内存回收属于规划中的 v0.7 图压缩graph compaction工作。P3按需段 fsck 端点变更动机2026-04-25 的审计认为段完整性校验缺失。复查证明审计有误——逐节 CRC32C 在写入时已计算整个文件的 CRC 在打开时也会校验真正缺失的是面向运维的触发入口。新端点POST /{index}/_admin/segments/fsck → 200 OK 健康索引 → 500 Internal Server Error 任一节损坏便于外部监控以命中而非绿灯触发告警响应体示例来源版本说明{ total_segments_checked: 17, total_sections_checked: 51, corrupt_sections: 0, segments: [ { segment_id: seg-..., sections: [{kind:Stored,ok:true,error:null}, ...] }, ... ] }源码实现处理器admin_segments_fsck位于 engine/crates/xerj-api/src/es_compat.rs支持通配符/逗号索引表达式一次 fsck 多个索引corrupt_sections ! 0时返回 500底层逻辑fsck_segments位于 engine/crates/xerj-storage/src/index_store.rs遍历当前快照中每个段打开读取器后对每一节重新计算 CRC32C 并对比产出结构化报告CPU 密集工作在tokio::task::block_in_place中执行不会阻塞 tokio worker对数百 MB 的 CRC 计算而言这很重要。建议的运维节奏放进 cron 定期执行、硬件事件之后执行、或怀疑位腐烂bit rot时执行。顺带一提/v1/indices/:name/_flush与本端点是两条独立路径fsck 只读不写可安全用于健康检查脚本。P4PIT 上下文不再泄漏变更动机v0.6.2 之前每次POST /{idx}/_pit?keep_alive…都会插入一个永不过期的上下文。客户端开 10 000 个 PIT 而不关闭就会永久持有 10 000 个上下文——这是纯粹的进程内内存泄漏向量。新增Config.pit配置3 项[pit] default_keep_alive_secs 300 # 未带 ?keep_alive 时生效 max_keep_alive_secs 86400 # 硬上限24 小时 sweep_interval_secs 30 # 后台回收器的扫描节奏配置结构体PitConfig及默认值见 engine/crates/xerj-common/src/config.rsdefault_keep_alive_secs默认 300ES 要求必须传keep_alivexerj 允许缺省并应用此默认值而不是返回 400max_keep_alive_secs默认 86 400对客户端请求的硬上限防止恶意客户端申请 30 天的 PIT超出的请求会被静默截断为 24 小时sweep_interval_secs默认 30越小内存漂移越少、CPU 消耗越高。行为细节open_pit解析 ES 风格的1ms/5s/2m/1h/7d时长es_compat.rs子秒单位向上取整到 1 秒避免500ms产生零时长 PIT下限 1 秒上限max_keep_alive_secs后台回收器按sweep_interval_secs扫描engine.pitsDashMap丢弃所有expires_at now的条目engine.rsopen_pit还会机会式地先扫一次sweep_expired_pitses_compat.rs因此即使客户端以紧密开环方式反复开 PIT内存增长也能自我收敛无需等待下一个 tick。随版本一起交付的小项三项 painless-execute 加固从 v0.5.9 带入输入限制、no-eval详见 v0.6.0 说明HNSW 格式 v2向后兼容 v1 读取器v0.6.2 写出的图 v0.6.0 / v0.6.1 无法读取旧版本写出的图仍可加载HNSW 单元测试从 7 个增至 9 个往返保存/加载、损坏拒绝、墓碑排除、墓碑持久化。明确不在 v0.6.2 范围内滑入 v0.7项目说明周期性 HNSW 检查点目前仅在_flush触发保存长时间无 flush 的 ingest 期间向量仍靠 WAL 保证持久性但该区间内重启会走 WAL 重建图v0.7HNSW 图压缩移除墓碑边并回收内存v0.7混沌测试矩阵端到端证明重启重建成本消失v1.0-rc这些工作把 AI/向量域的交付评分从 v0.6.0 的 65% 推向 v0.7 目标约 80%剩余 20% 主要落在 AI 执行层hybrid/semantic执行器、reranker、agent 循环由 v0.7 交付。升级注意项磁盘格式兼容性段 / WAL / DV 无磁盘格式变化仍可读取 v0.5.9 / v0.6.0 / v0.6.1 生成的旧产物HNSW 图文件格式从 1 升到 2加载器两者皆支持。v0.6.2 → v0.6.0 降级时无法加载升级后写出的图——运维只需跑一次 ingest即可从 WAL 重建图之前被工具依赖的_admin/segments/fsck端点形态——它本来就不存在因此无迁移风险。配置迁移自定义了Config的运维应在 TOML 中添加或依赖默认值[pit] default_keep_alive_secs 300 max_keep_alive_secs 86400 sweep_interval_secs 30小结v0.6.2 的四个主题对应四类不同的生产风险启动可用性HNSW 持久化把重启时间从小时级降到秒级、查询正确性删除真正进入 kNN 图、数据完整性可观测性按需 fsck 让位腐烂可被监控到、资源有界性PIT 上下文带 TTL 与后台回收。对运行大规模向量索引的部署升级收益集中在重启更快、kNN 结果与主搜索一致、损坏可主动探测、长跑进程内存可预测四点同时务必留意 HNSW 格式版本变更带来的降级约束与持续删除负载下的召回率取舍。赞分享人工智能搜索引擎本地部署后端MCP 服务【免费下载链接】xerjXERJ is the new way for AI to search data. Its autoindex capability activates agents to know your data without the token waste of grep and sed. One command indexes code, docs, logs and PDFs for search, RAG, security audits and agent memory, using 40x fewer tokens than grep. Elasticsearch compatible, so existing clients just work.项目地址https://gitcode.com/GitHub_Trending/xe/xerj点击查看免费下载相关推荐Slate v2 占位符删除回退一致性扫描placeholder 生命周期与 delete-to-empty 回归治理实战Slate v2 占位符删除回退一致性扫描placeholder 生命周期与 delete to empty 回归治理实战 导读 本篇文章围绕 Slate v前端富文本UI组件插件系统Fission 发布生命周期与零停机升级治理RELEASES.md 政策全解读Fission 发布生命周期与零停机升级治理RELEASES.md 政策全解读 本文围绕 Fission 仓库根目录的 RELEASES.md https:/云原生后端Pulse v6.4.0-rc.4 发布解读关键化增量同步、Proxmox 视图恢复与治理生命周期改进Pulse v6.4.0 rc.4 发布解读关键化增量同步、Proxmox 视图恢复与治理生命周期改进 v6.4.0 rc.4 是 Pulse v6 系列下一可观测性运维后端上一篇Minimal Mistakes 标题中的 Markdown 标记文章内渲染与浏览器标签页剥离机制解析下一篇Socket.IO Java客户端项目推荐创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考