kezekshi（каз. кезекші——值班员）是一个告警初级分诊回路，运行在本机，不向外发送数据。确定性规则先滤掉运维噪声，剩下不确定的部分由微调后的 Gemma 4 E2B（Apache 2.0）处理，并生成给二线的卡片：结论、带证据引用的论断、MITRE ATT&CK 技术、缺什么、要查什么。 在 assist 模式下，模型不做任何关闭动作。回路本身只关闭白名单里的确定性噪声，其余全部由人查看。 这里有什么：回路代码、响应 schema、ATT&CK 索引、训练和评估脚本、操作手册。权重：Hugging Face 上的 oleg-vdv/kezekshi-l1。 没有什么：训练数据（见下文）。 在封闭集上的测量，2026.11.06，温度 0，不启用思考，模型决策不带兜底规则。完整回路会额外用规则备忘为其兜底。 在实验台流量上（3000 条告警的测量），98.1% 的告警无需调用模型即可解决，进入模型的占 1.9%。模型在 8 GB 显存的笔记本上每条告警耗时 2–5 秒。 目前的结论是：这个回路适合用来卸载噪声和起草卡片。作为自主的升级决策器，模型尚未经过验证。 合成数据不能迁移到真实流量。在纯合成数据上是 0 次误升级，而在真实噪声上同一版本把 100 条中的 39 条做了升级。用 215 个真实 benign 案例做微调后，这个问题消失了。 困难负样本比新攻击类型更有效。来自 SCCM 的 PowerShell -enc、来自备份的 vssadmin create、按申请单发起的扫描：在这些例子上，模型学到的是按特征而非按表面来判断边界。 严格的 schema 比微调更便宜。Ollama 的 schema 针对每条告警单独构建：只允许它的 E-id 和 MITRE 候选。在不重新训练的情况下，训练外类型的错误率从 9/20 降到 0/20，MITRE 召回率从 13/36 升到 25/36。代价是：真实噪声上的结论从 97 降到 93（主要是 FP 和 BTP 混淆），出现了零星的额外升级，而且链接检查现在流于形式。 提示会影响结论。MITRE 候选列表会把模型推向升级。加入"候选并不意味着攻击"的说明后，这部分有所减少，但新类型的 recall 从 20/20 降到 18/20：OAuth 授权和 IDOR 被当作正常情况关闭了。我们否决了这条说明。 微调后的模型启用思考反而有害：工作模式是不启用。 架构 Wazuh（只读）→ normalize → 注入？白名单噪声？──是→ 无需模型即解决 │ 否 ▼ MITRE 候选 → 模型 → 校验器 → 策略 → L2 队列和审计 src/triage.py 系统提示词、按告警定制的响应 schema、Ollama 客户端、校验器 src/attack.py 本地 ATT&CK 索引和按告警文本匹配候选 src/rulebook.py Wazuh 规则备忘和噪声白名单 src/build.py 数据集构建，src/seed_example.py——标注样例 src/train_hf.py LoRA 微调（transformers + peft），merge_hf.py——合并 eval/run_eval.py 评估：结论、升级、MITRE、响应校验 eval/recall_eval.py 回路在受控攻击上的 recall pipeline/ 服务：守护进程、策略、L2 队列、Web 控制台、报告 docs/operations.md 操作手册，docs/dataset.md——数据以及如何构建自己的数据 启动 需要 Python 3 和 Ollama。服务基于标准库运行。权重占 4.9 GB，已在 Ollama 0.40.14 上验证。

从 Hugging Face 获取模型

hf download oleg-vdv/kezekshi-l1 --local-dir kezekshi-l1-v6 (cd kezekshi-l1-v6 && ollama create kezekshi-l1-v6 -f Modelfile)

不依赖模型的离线检查

python eval/test_schema.py

在仓库示例上运行回路，无需 Wazuh

cd pipeline MODEL=kezekshi-l1-v6 OLLAMA=http://localhost:11434/api/chat python run.py --dry-run samples/wazuh_alerts.sample.jsonl 连接 Wazuh、策略模式和服务运行见 docs/operations.md 和 pipeline/README.md。 cd src && python build.py python train_hf.py ../data/train.jsonl python merge_hf.py kezekshi-l1-lora kezekshi-l1-merged python llama.cpp/convert_hf_to_gguf.py kezekshi-l1-merged --outtype q8_0 --outfile kezekshi-l1-q8_0.gguf ollama create kezekshi-l1 -f ../Modelfile 关于 8 GB 上训练的说明：Unsloth 搭配 Gemma 4 E2B、Windows 以及把层卸载到 RAM 会破坏反向传播，所以这里用 transformers + peft。Windows 上的 Ollama 无法从 safetensors 导入 Gemma 4，需要通过 llama.cpp 转成 GGUF。 v6 权重（GGUF Q8_0）已发布在 Hugging Face 上。数据集未发布：它依赖课程材料和封闭实验台的告警。因此模型可以启动并在自己的告警上验证，但上面的指标无法从公开文件复现。更多细节以及如何构建自己的数据集——docs/dataset.md。 代码和权重——Apache 2.0，见 LICENSE。基础模型 Gemma 4——Apache 2.0。