• 人工智能
• 搜索引擎
• 本地部署
• 后端
• MCP 服务

本文带你完整走通 XERJ 的_watcher语义检测能力：定时判定、告警触发的全链路实测，并附上一份诚实的门槛失败数据——"错误且自信"（wrong-and-confident）率达到 0.2449，远超 5% 的红线。机制是真的通的，质量是真实测出来的，两者分开讲。

什么是 XERJ _watcher：语义检测的定时判定机制

XERJ 是一个面向 AI 数据检索的开源搜索引擎，一条命令即可为代码、文档、日志和 PDF 建立可搜索、可 RAG 的索引，并且兼容 Elasticsearch 客户端协议。除了"搜"，它还能"盯"：

• watch（观察规则）：你通过PUT /_watcher/watch/{id}提交一个"检测观察"，它会按固定间隔（如每秒 1 次）自动扫描指定索引里的新文档；
• 语义判定：每批新文档会带着你预设的"问题"去问/_decide接口——这是一个基于带标签历史库的加权 k 近邻投票，全程本地执行，不向外发送任何数据；
• 告警触发：当某个正例标签的置信度越过阈值p_min，节点就把一条 fire 记录写入.xerj_alert_fires索引，这就是"告警落地"。

路由定义见 engine/crates/xerj-api/src/router.rs，判定与拒绝逻辑在 engine/crates/xerj-api/src/es_compat.rs。

唯一真正执行的 watch 形状：创建检测告警步骤

XERJ 对输入的态度是"要么照做，要么大声拒绝"。_watcher目前只评估一种 watch 形状，其余一律返回 501 并明确说出"不接受的原因"。支持的结构如下：

创建一个"发票检测"观察长这样（一个最小可用示例）：

curl -s -XPUT http://127.0.0.1:9200/_watcher/watch/detect-invoice \ -H 'content-type: application/json' \ -d '{"trigger":{"schedule":{"interval":"1s"}}, "input":{"search":{"request":{"indices":["mail-incoming"]}, "body":{"query":{"match_all":{}}}}}, "condition":{"xerj_decide":{"question":"{{text}}", "positive_label":"invoice","text_field":"text", "p_min":0.5,"index":"email-history","k":10}}, "actions":{"index_alert":{"level":"info"}}}'

两个容易踩的边界：

1. watch 在 PUT 时刻基线化：它记录当前索引的最大_seq_no，只判定此之后写入的文档——所以先建 watch、再灌数据，顺序不能反；
2. 不支持的形状被拒绝：cron 调度、transform、多索引输入、其他 action 类型都会拿到 501，而不是被静默接受后永远不执行。

全链路实测：从定时判定到告警触发

为了验证"部署中的检测观察到底做什么"，仓库里有一套完整 harness：benchmarks/systemone-watcher-gate/watcher_gate.py。关键点：它从不调用/_decide来下判定——所有 fire 记录全部由节点自己的 watcher 评估器写入.xerj_alert_fires，harness 只负责读回。

实验设置（配置文件：gate.toml）：

120 封候选由 gen_boundary.py 用模板确定性生成（seed 1108，重跑逐字节可复现），每条都带构造出来的真值标签gold。四种"跨界"模式故意借用其他类别的措辞：不含 "invoice" 一词的账单邮件、提到金额的私人便条、结尾问问题的 newsletter、埋在状态通报里的待回复确认。

运行结果（2026-10-11，本地构建的v1.0.0-rc.94release 版本）：

原始逐条输出在 results/run.json，完整控制台记录在 results/transcript.txt。

诚实的失败数据：门槛没有通过

结论先行：FAIL。门槛要求"置信度 ≥ 0.8 的 fire 中，错误占比 ≤ 5%"，实测是 24.49%，差了近 5 倍。这个失败是真实的、有价值的——它告诉我们默认投票在边界样本上的质量不足以支撑"自信即正确"的告警承诺。

混淆矩阵：错在哪里

24 条"错误且自信"的 fire，raw 置信度全部落在 0.871–1.000 之间，其中 18 条恰好是1.000。也就是说，系统不是"拿不准"，而是"错得斩钉截铁"。

为什么校准也救不了

配置里明明打开了calibration = "isotonic"，但 fire 记录里p_cal全为 null：历史索引里没有"投票 + 真值结果"的配对，节点如实上报了无法拟合（calibrated: false）。

更关键的是，就算拟合成功也救不了：isotonic 校准是一个单调映射，无法区分同处 rawp = 1.000的正确 fire 和错误 fire。把 1.000 压低能滤掉 18 条错误，但同样会把正确的那批压下去——拆掉检测器而不是修好它。单样本的过度自信是投票本身的性质，不是置信度刻度能修的问题（校准在"聚合频率是否贴合概率"这个不同量纲上确实有用，那是另一项已测过的指标）。

错误根因：词表之外的邮件投给"最像"的标签

默认判定是基于词法（lexical）嵌入的 BM25 加权 kNN 投票。边界邮件与自己标签的训练样本共享词汇为零时，就会被投给"它最像的别的标签"——而正因为和那个标签很像，投票份额（即置信度）反而很高。这正是 benchmarks/systemone-classify-email/README.md 里 8 封手工"hard"样本就发现的两个模式，如今以 120 封的规模复现。

实操建议：如何安全使用 XERJ 告警检测

机制是真的（定时触发、语义判定、fire 落地全部验证通过），但默认投票质量有边界。给运维的诚实建议：

1. 用与真实流量同构的留出集，调decisions.min_confidence和p_min，别用默认值直接上生产；
2. 不要把 raw 投票置信度当成可靠的"弃权信号"——它对分布外输入会过度自信；
3. 接受当前已知限制：服务重启不会恢复 watch（评估器只在put_watch时启动）、每轮判定预算 1000 条、暂无通知投递、watch 需通过 API 而非控制台编写（详见 content/answers/does-xerj-support-s3-alerting-plugins.md）。

要复现整套测量，只需：

xerj -d /tmp/gate-data --insecure --port 9471 -c gate.toml # 后台启动 python3 gen_boundary.py XERJ_URL=http://localhost:9471 python3 watcher_gate.py

结论

XERJ 的_watcher把"定时判定 → 语义投票 → 告警触发"这条链路完整走通了，而且用"输了就公布"的规则把失败数据原样写进了 benchmarks/systemone-watcher-gate/README.md。0.2449 的门槛失败不是瑕疵，它标出了语义检测告警当前能负责任地使用的位置：机制可信，质量要靠你自己的数据调出来。

• 人工智能
• 搜索引擎
• 本地部署
• 后端
• MCP 服务