人工智能搜索引擎本地部署后端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点击查看免费下载本篇技术指南以仓库中的对比文档scripts/seo/testdata/factcheck/good_compare_manticore.md为核心骨架逐一解析 XERJ 与 Manticore Search 在单二进制、无 JVM、无外部嵌入服务这一共同定位下的真实异同并结合 XERJ 源码给出hybrid查询、--embed-mode嵌入后端、ES-YAML 兼容性、tree-sitter 符号索引与 Agent Memory API 的底层实现证据。读完你可以掌握两个引擎各自的优势边界并能在具体选型时做出有依据的判断。两个站在同一位置的引擎Manticore Search 与 XERJ 的正面比较之所以成立是因为两者在部署形态上高度重合都是单个二进制一条命令即可启动都支持单节点、无 JVM运行没有 Elasticsearch 那样对 Java 堆的依赖都支持无外部嵌入服务的本地向量能力。XERJ 在仓库中的实际形态与此一致xerj-server是独立的可执行程序engine/crates/xerj-server/src/main.rs 中--insecure --data-dir即可拉起本地开发实例README 也强调兼容 Elasticsearch API但并非 Elasticsearch 内部实现的复刻见 README.md 第 392–395 行。真正的分歧发生在能力深度与工程成熟度上下文逐项展开。混合检索Manticore 的 RRF 与 XERJ 的hybrid查询Manticore Search 的 KNN 文档与混合搜索文档对应原文档引用的两个外部证据条目说明了它的能力本地 ONNX 嵌入模型、无需 API Key并可在同一条查询中通过OPTION fusion_methodrrf将 BM25 与 KNN 结果融合。XERJ 提供了同构的能力只是换成了 Elasticsearch 风格的查询语法hybrid查询类型。从 engine/crates/xerj-query/src/parser.rs 可以看到它的完整解析逻辑hybrid.queries必须是非空数组每个子查询通过query字段指定并可选weight默认 1.0参与融合权重hybrid.fusion支持两种策略rrf默认策略常量 k60也支持对象写法{ type: rrf, k: 60 }自定义 klinear线性融合对每个子列表做 min-max 归一化到 [0,1] 后再按权重加权求和learned会被显式拒绝并返回 400hybrid fusion learned is not yet supported; use rrf or linear而不是悄悄回退到 RRF——这是宁可报错也不歪曲排序的明确设计。底层执行在 engine/crates/xerj-engine/src/index.rs 中实现源码注释给出了精确公式RRF每个文档的综合得分为Σ_i weight_i / (k_rrf rank_i_in_list_i)rank 从 1 开始某列表中缺失的文档在该列表贡献 0。注释明确说明这与 ES / OpenSearch 使用的公式相同且对 BM25 与向量相似度之间的分数尺度差异鲁棒Linear综合得分为Σ_i weight_i × normalised_score_i计算更廉价允许调用方偏置某个信号但对分数尺度的离群值敏感Learned尚未实现执行层在遇到该变体时回退 RRF 并给出警告。也就是说Manticore 的BM25 KNN 一次查询融合在 XERJ 中对应的是{ query: { hybrid: { queries: [ { query: { match: { title: database } }, weight: 1.0 }, { query: { knn: { field: embedding, query_vector: [...] } }, weight: 1.0 } ], fusion: { type: rrf, k: 60 } } } }此外执行层还专门处理了hybrid出现在bool等复合结构中的场景issue #943凡是无法真正执行的 Hybrid 节点都会返回 400 并点名支持的写法避免静默丢弃混合查询导致返回错误命中的陷阱。嵌入方式默认不神经神经是显式选择这是原文档强调的另一个核心差异点。Manticore 开箱即带本地 ONNX 嵌入模型而 XERJ 的默认嵌入器是词法特征哈希lexical feature hashing并不是神经网络——这一点在 engine/crates/xerj-autoindex/src/catalog.rs 的注释中说得非常直白默认内建的是 384 维的 hybrid lexicalvector 嵌入器不是神经的。神经语义需要显式开启。xerj-server的--embed-mode参数见 engine/crates/xerj-server/src/main.rs支持五种后端模式说明lexical默认内建 feature-hash离线、非神经neural内建 BERTall-MiniLM-L6-v2进程内推理首次使用自动下载模型约 90 MB并缓存之后离线运行proxy外部 OpenAI 兼容的/v1/embeddings端点auto若配置了embedding.default_endpoint则走 proxy否则退回 lexicalonnx-experimental本地 all-MiniLM-L6-v2 兼容 FP32 ONNX 原型宽 384需要匹配的tokenizer.json不自动下载对应的还有--onnx-model与--onnx-tokenizer两个参数来指定 ONNX 模型路径。engine/crates/xerj-rerank/src/lib.rs 还说明proxy 模式在写入时发送文档文本、搜索时发送查询文本neural 模式下 Raft 消息索引名、映射、分片分配不携带嵌入数据。需要强调的是XERJ 的神经嵌入路径目前是MiniLM 级别的模型而 Manticore 提供了 Qwen、Llama、Mistral、Gemma 等更广的本地模型选择——这是原文档明确承认的劣势之一。XERJ 的差异化能力机器可核查的兼容性原文档指出XERJ 相对 Manticore 多出的是一组可发布、可机器核查的工程能力全部可以在仓库中找到对应实现。1. ES-YAML 一致性套件。README 顶部徽章与正文README.md 第 20 行、第 392–395 行写明一致性套件每次提交都会运行当前通过1366 / 1369个用例原文档中 99.8% 即由此推算对应的 curated 子集在 engine/tests/es-compat-yaml 中剩余差距在该目录中列出而非隐藏。docs/ARCHITECTURE.md 进一步说明这套 ES-YAML 用例是线路级兼容性的判据行为与 Elasticsearch 不同即视为错误。这也是 XERJ 宣称现有 Elasticsearch 客户端直接可用的事实基础。2. 零配置文件夹索引与 tree-sitter 符号提取。xerj autoindex folder一键发现并索引文件夹engine/crates/xerj-autoindex/src/cli.rs。代码文件由 tree-sitter 解析并做 AST 感知索引——符号 全文让 Agent 检索到的是函数而非一行。支持的语法覆盖 Python、C、Rust、JavaScript、Go、TypeScript、Java、C、Ruby、PHP、C#、Bash、Kotlin 等见 engine/crates/xerj-autoindex/Cargo.toml。README 还给出了可复现的提取基准单线程进程内提取约1,500 文件/秒13 MB/stree-sitter 解析约占 72%README.md 第 411–427 行。3. Agent Memory API 与同进程 MCP 服务。XERJ 在同一个进程中提供_memory/{namespace}写入与_memory/{namespace}/_recall召回并按语义BM25 / semantic / vector检索MCP 服务器把这些操作暴露为xerj_memory_store、xerj_memory_recall等 stdio 工具见 engine/crates/xerj-mcp/src/lib.rs。对一个正在运行的 Agent 而言这意味着搜索 持久记忆共用同一个端点无需再拉起第二个数据服务。许可证Apache-2.0 与 GPL-3.0 的商用含义原文档点出XERJ 采用Apache-2.0见仓库根目录 LICENSEManticore 采用GPL-3.0。若你的场景是把引擎嵌入商业产品这一差异有实际分量Apache-2.0 允许闭源衍生与再分发而 GPL-3.0 的 copyleft 会约束衍生作品的许可方式。这是纯工程能力之外的、直接影响选型决策的条款差异。什么时候应该选 Manticore 而不是 XERJ原文档给出了明确的三条选型建议仓库侧的对比页面 landing/compare/xerj-vs-vector-database.html 也做出了同样的诚实表述——XERJ 不是唯一处于这个位置的引擎也从不宣称如此它在成熟度和嵌入器广度上输给 Manticore需要成熟度Manticore 有 21 年 Sphinx 血统而 XERJ 仍处于 pre-1.0 阶段需要神经嵌入的广度Manticore 自带 Qwen、Llama、Mistral、Gemma 级别的本地模型XERJ 的神经路径目前是 MiniLM 级别团队希望以 SQL 作为查询界面SQL 是 Manticore 的原生接口而 XERJ 走的是 Elasticsearch REST 风格。反过来如果优先考虑可发布的一致性数字1366/1369 ES-YAML、零配置的文件夹/多格式文档索引、为 Agent 设计的同进程记忆 API以及Apache-2.0 的商用友好许可XERJ 是更匹配的选项。结论XERJ 与 Manticore Search 的对比是同类位置、不同取舍的典型部署形态单二进制、无 JVM、本地嵌入高度一致混合检索RRF能力对等真正的分水岭在于成熟度与模型广度Manticore 胜、一致性可核查性与 Agent 生态集成XERJ 胜。选型时不必迷信任何一方的宣传而是对照上文的五个维度——混合检索语法、嵌入后端、兼容性证据、许可条款、SQL 需求——逐条打分。赞分享人工智能搜索引擎本地部署后端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 对比 Khoj只想要搜索与记忆时自托管助手与本地检索引擎的边界在哪里XERJ 对比 Khoj只想要搜索与记忆时自托管助手与本地检索引擎的边界在哪里 本文是 XERJ 项目官方对比文档的技术展开Khoj 是一个完整的自托管个人工智能搜索引擎本地部署后端MCP 服务边缘与混合云数据库部署的用户期望 2025–2026以 XERJ 单二进制搜索引擎逐项对照边缘与混合云数据库部署的用户期望 2025–2026以 XERJ 单二进制搜索引擎逐项对照 本篇技术指南以仓库内 user feedback/15 clust人工智能搜索引擎本地部署后端MCP 服务向量检索实战Manticore Search HNSW KNN 索引与自动嵌入完整教程向量检索实战Manticore Search HNSW KNN 索引与自动嵌入完整教程 Manticore Search 是一款开源搜索数据库原生支持全文、搜索引擎数据库全文检索后端上一篇从入门到进阶node-dateformat处理ISO 8601与UTC时间的完整方案下一篇64K上下文新标杆LongAlign-7B-64k重塑长文本智能处理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考