AiSOC 基准评测方法论详解：200 条合成事件、substrate 与 wet eval 的可复现实验体系

人工智能AI Agent网络安全后端前端【免费下载链接】AiSOCOpen-source AI Security Operations Center: alert fusion, LLM-agent triage, MITRE ATTCK investigation, and a replayable decision ledger for every agent step. Self-hostable, runs with no API keys, MIT licensed. Ships an MCP server for Claude, Cursor and Continue.项目地址https://gitcode.com/GitHub_Trending/ai/AiSOC点击查看免费下载本文以 AiSOC 开源仓库的基准评测文档为骨架逐层拆解其公开评测体系数据集如何确定性生成、substrate 自检与 wet eval真实 LLM为何必须分开、每个 suite 的门槛值从哪来、rate card 如何计价以及一条命令复现全部数字的完整路径。读完后你将能够独立复现 AiSOC 的评测结果、把同一套协议套用到自己的 SIEM/SOAR 上并准确判断哪些数字可以对外引用、哪些只是回归信号。1. 这套评测为什么存在商业 AI SOC 厂商公布的基准通常不可复现数据集私有、评分规则私有、运行器私有买方只能看到结论。AiSOC 采取相反的策略——把数据集、评测执行器和 CI 门禁一起开源并明确标注哪些数字是真实测量、哪些只是 substrate确定性底座自检。整个文档贯穿一条工作区级规则对哪些是合成的、哪些是真实的保持透明绝不把 substrate 自检当作实时 Agent 的性能。这条规则的落地方式非常具体每个 suite 在报告里都带有 class 标签eval_telemetry.py产出的每个对象都带有mode: deterministic_substrate字段wet eval 报告带有mode: live或mode: dry_run连 CI 的报告写入器都会拒绝把 substrate 数字排版成 live 数字见 scripts/render_eval_charts.py 中的_render_wet_eval三分支逻辑。2. 数据集200 条合成事件与 55 个模板族2.1 事件语料的构成评测对全部 suite 使用同一份确定性语料services/agents/tests/eval_data/synthetic_incidents.json由 scripts/generate_eval_incidents.py 以固定种子重新生成因此两个贡献者在不同机器上可以产出逐字节一致的文件。属性文档记载值仓库实测当前数据总用例数200200不同模板宏族5555每模板用例数3–4通过{user}/{host}/{ip}/{campaign}循环35 个模板 × 4 例 20 个模板 × 3 例严重度分布low / medium / high / critical偏向 mediumhigh 93 / critical 88 / medium 19MITRE ATTCK 战术覆盖v15 的 14 个战术中的 11 个expected_tactics中出现 12 个不同 tactic ID真实 vs 合成100% 合成不含客户遥测、不含抓取日志、不含专有 IOC一致说明上表仓库实测列由对synthetic_incidents.json的计数得到。严重度与战术数量与文档描述存在轻微差异生成器参数调整所致复现时请以你所检出 commit 的数据文件为准不要交叉引用不同版本的分布。每条事件记录的字段结构可直接用于编写检测与连接器契约{ id: INC-EVAL-001, template_id: phishing-macro-email, template_index: 0, title: Spear-phishing email with macro-laden attachment delivered to daveexample.com, description: Inbound email from 203.0.113.111 delivered an Office document ..., expected_tactics: [TA0001, TA0002], expected_techniques: [T1566.001, T1059.005], severity: high, response_class: block_indicator, evidence_keywords: [phishing email, macro, 203.0.113.111, WIN-DC-PRIMARY, ...], telemetry: [ { source: m365_audit, Operation: Send, ...: ... } ] }response_class如block_indicator与evidence_keywords是后续 playbook 覆盖门禁与离线判分的关键输入而不是装饰字段。2.2 为什么是 55 个模板、200 条用例、确定性生成这三项设计决策都是权衡结果文档给出了明确理由为什么不是 200 个独立叙事若每个用例一个模板就等于一例一模板单个模板损坏在 1/200 0.5% 的稀释下几乎不可见。每模板循环 3–4 次后按模板宏平均的回归信号约为 1.8%/模板灵敏度显著提高同时不会让生成器膨胀。为什么是 200足够小——substrate 套件可在毫秒级跑完每 PR 的全语料门禁约 35 ms又足够大——在公布的 p95 下限上wet eval 的每模板时间方差可控制在 10% 以内。为什么必须确定性不稳定的语料等于不稳定的 CI 门禁。确定性生成让不同日期落地的两个 PR 面对逐字节相同的输入。生成器通过hashlib.sha256派生的索引在池中取样见 scripts/generate_eval_incidents.py 中的_seed_index避免依赖 Python 全局随机状态。2.3 合成遥测语料每条事件至少附带一条支撑遥测写入 services/agents/tests/eval_data/synthetic_telemetry.jsonl。当前语料共361 条事件、14 个来源来源事件数来源事件数sysmon113web_access26windows_security51azure_signin21edr38github_audit13linux_auditd33cloudtrail13m365_audit28dns7k8s_audit7linux_journald4db_audit4vpn3每条事件的形状就是真实连接器会 pivot 的字段集——{user, host, ip, query, action, …}——因此连接器与 Sigma 规则的 PR 有一个明确契约可以开发无需先准备真实租户。这份语料的关键限定词是结构上忠实于真实连接器但不是从活租户抓取的。它是确定性地手工塑形出连接器会发出的字段集而不是真实环境的噪声分布。这一点在 §7 的局限性中会再次展开。2.4 合成与真实的边界组件类别说明200 条事件语料合成确定性、可再生361 条遥测事件合成手工塑形为真实连接器字段集被测 substrate 代码真实services/fusion、services/agents中的生产模块实时 AgentLangGraph 编排器真实仅由 wet eval 驱动§3.2LLM 响应wet eval真实真实 OpenAI / Anthropic / Ollama 调用真实计费Rate card§5真实公开挂牌价每行标注生效日期3. Substrate 自检 vs. wet eval全文最重要的区分3.1 Substrate 自检每 PR、毫秒级、无 LLMsubstrate 套件只驱动确定性代码关键词抽取器——来自services/agents/app/extractors/融合分组——一套在测试内部实现的四层方案按(rule_id, host, user)建键。它不是services/fusion实际运行的分组逻辑后者按{tenant}:{entity}:{tactic}建键保留它只是为了回归门禁其数字不描述本产品报告与计划模板——LLM 调用失败时的确定性降级合成器离线判分器——关键词覆盖率与 rubric 评分检查。这些套件毫秒级跑完并对每个 PR 设门禁。它们不测量 LLM Agent 质量只测量 substrate 一致性。四个评分套件中有三个mitre_accuracy、investigation_completeness、response_quality在构造上是同义反复的只要 substrate 保持内部一致就通过不一致就大声失败。这使它们成为优秀的回归信号却是糟糕的能力分数。把mitre_accuracy 0.97读成Agent 的 MITRE 分类准确率是 97%是对该套件的误读——它门禁的是 substrate不是 Agent。3.2 Wet eval每周、真实 LLM、真实费用wet eval 端到端驱动线上services/agentsLangGraph 编排器跑同一份 200 条语料。每次 LLM 调用都是真实的每个 token 都花真钱每个延迟数字都反映真实网络往返。Wet eval 属性值节奏每周一次另加触及 Agent 图或提示词的 PR 按需触发驱动scripts/run_evals.py 的--wet数据集同一份synthetic_incidents.json确定性LLM通过环境配置文档记为AISOC_BENCH_PROVIDERopenai\|anthropic\|ollama采集遥测墙钟延迟 p50/p95/p99、prompt completion token、USD 成本CI 门禁.github/workflows/wet-eval.yml输出eval_report.json的wet_eval块 渲染到apps/docs/static/eval/每周任务把结果推送到与 substrate 运行相同的eval-results分支使历史趋势线集中在一处。3.3 两条承重的实时调度语义文档特别指出两个语义细节它们直接决定报告该怎么读。以下实现细节均可在 scripts/wet_eval.py 中找到对应代码。1整轮运行共用一个事件循环。每条事件都在同一个 asyncio 循环上调度。历史实现按事件逐个asyncio.run导致langchain-openai缓存的异步 HTTP 客户端被绑定到已关闭的循环——于是第一条之后的所有事件模型调用失败Agent 静默退回确定性启发式而运行仍自称live。检查办法是报告里的llm_calls_placed它被发布在每个均值旁边而一次完全没有发出调用的运行会被拒绝。async def _dispatch_all() - None: # One event loop for the whole run, matching production, where the # triage workers loop lives as long as the process. ...2失败按 0 分计入并记录原因。调查彻底失败的事件抛异常或返回statusfailed以0 分进入均值原因写入报告的groundedness.zero_scored块——这样样本量始终等于已调度的前缀。丢弃失败者是幸存者偏差它会抬高均值并把样本缩减到低于门禁自身的最小样本要求这正是修复前那套 harness 自我夸大的方式。def _zero_scored(inc, *, reason, latency_s, llm_calls) - WetEvalRecord: return WetEvalRecord(..., groundedness0.0, zero_scored_reasonreason, ...)3.4 0.40 的 groundedness 下限从哪里来.github/workflows/live-agent-eval.yml 断言的下限是0.40作用在确定性的 10 条事件切片上由 scripts/check_live_agent_floor.py 对照记录在 services/agents/tests/eval_data/live_agent_floor.json 中的历史运行来校验——推导历史被保留修复前的运行也保留并打上标记。该下限低于观察到的最低修复后运行值0.44余量刻意做得很薄在零填充语义下一次失败的调查大约让均值下降 0.05因此一个在 10 条事件中失败 3 条及以上的模型会把任务判红——这正是该结果应当产生的信号。加载器会拒绝高于自身已记录证据的下限。live_agent_floor.json中的记录包含模型名、调度的事件数、每次观测的均值以及运行位置。例如qwen2.5:0.5b在开发者机器上重复 7 次得到 0.5561四位小数完全一致在 GitHub 托管的 ubuntu-latest 上观测到 0.5821、0.5329、0.5933 等值。文件同时明确写着该下限描述的是 Ollama 本地服务托管模型需要各自的运行与下限。check_live_agent_floor.py还显式拒绝四类输入substrate报告未标注mode: live、unmeasuredgroundedness.measured为假或评分事件数少于下限推导样本、wrong model模型与下限推导模型不符除非显式传--allow-model、以及低于下限。这是同一扇门上的第二把锁。4. Suite 与它真正测量的东西完整逐套件说明在评测页上这里给出带 class 标签的摘要门槛值取自 scripts/run_evals.py 中的_TARGETS与测试文件中的断言保持一致。Suite类别头条指标门槛mitre_accuracySubstrate 自检关键词抽取器的按模板宏准确率≥ 0.80宏 ≥ 0.80alert_reduction遗留不描述本产品1000 条告警噪声流 → 测试内四层分组≥ 0.70alert reduction产品逻辑真实测量同一告警流用RawAlert.correlation_key()分组文档记 33.3%参考区间 20–95%investigation_completenessSubstrate 自检报告模板的平均关键词覆盖率≥ 0.85宏 ≥ 0.80response_qualitySubstrate 自检合成计划的平均 rubric 分≥ 0.80宏 ≥ 0.75hunt_corpus覆盖度门禁正向场景命中率≥ 1.0adversary_eval退化行为门禁三档强度下的整体命中率整体 ≥ 0.40light ≥ 0.85heavy ≤ 0.50confidence_calibration校准门禁Brier 分数越低越好≤ 阈值判定条件取反memory_recall记忆保真召回准确率≥ 0.95override_accuracy覆写准确率准确率≥ 0.95playbook_completion_rate运营覆盖门禁范围内事件有匹配 playbook 的比例≥ 0.50detection_fp_rate交叉误报门禁每条规则的上限 FPR≤ 0.05latency_*wet真实测量墙钟 p50/p95/p99无硬门槛tokens_*wet真实测量每次调查的 LLM token 总量无硬门槛usd_*wet真实测量按 rate card 折算的单次调查成本无硬门槛_SUITE_NAMES是与--suite参数对齐的规范名称元组共 11 项--suite all是默认值传入单个名称可隔离运行某一套件——这既是 CI 按轴矩阵的用法也是运维把回归 bisect 到单个门禁的用法。4.1 为什么有两个告警降噪数字这是评测页上最容易被误引的一处。两个数字的分母都是 1000 条合成噪声告警流由generate_noisy_alert_stream生成包含近似重复、主机/用户变体、时间窗突发和良性噪声但分组逻辑完全不同遗留套件services/agents/tests/test_alert_reduction.py在测试文件内部实现四层分组1. 同一 (rule_id, host, user) 且 10 分钟内 → 1 个 incident 2. 同一 (rule_id, host) 且 30 分钟内 → 1 个 incident 3. 同一 (rule_id) 且 5 分钟内告警风暴 → 1 个 incident 4. 其余 → 各自独立 incident然后丢弃低于噪声阈值的 incident。它保留下来只为连续性不描述本产品。产品逻辑services/fusion/tests/test_alert_reduction_real.py用生产代码真正调用的键来分组。键的定义在 services/fusion/app/models/alert.pydef correlation_key(self) - str: Generate a key for alert correlation (grouping related alerts). # Correlate by primary entity and tactic entity self.src_ip or self.hostname or self.username or self.domain or unknown tactic self.mitre_tactics[0] if self.mitre_tactics else unknown return f{self.tenant_id}:{entity}:{tactic}而 services/fusion/app/services/correlator.py 正是以这个键作为 Redis 索引前缀命中已有 incident 就合并否则新建并写入带 TTL 的键映射async def _correlate(self, alert: RawAlert) - tuple[bool, IncidentSummary]: corr_key alert.correlation_key() index_key f{_CORRELATION_PREFIX}{corr_key} incident_id_bytes await self._redis.get(index_key) if incident_id_bytes: incident await self._load_incident(incident_id) if incident and incident.alert_count self._max_alerts: incident await self._merge_alert(incident, alert) await self._save_incident(incident) return True, incident incident self._create_incident(alert) await self._save_incident(incident) await self._redis.set(index_key, str(incident.id), exself._window) return False, incident四层测试方案给出的降噪率更高但它是按(rule_id, host, user)这类更细的维度分桶生产逻辑按{tenant}:{entity}:{tactic}分桶维度更粗、语义更贴近同实体同战术的攻击链。因此产品逻辑的数字明显更低——而且降噪率不是越高越好过度合并会把互不相关的事件塞进同一个 incident得到一个看起来很降噪但无用的 SOC。4.2 Playbook 覆盖门禁的四条子条件playbook_completion_rate的判定不是单一比例而是由 services/agents/tests/test_playbook_completion_rate.py 组合四个条件整体覆盖率≥ 0.50事件被判定为已覆盖需同时满足——被打上事件映射类别的标签、trigger.severity包含该事件严重度、且至少有一个步骤的动作类型与该事件的expected_response_class对齐。严重度子门禁high critical 事件在已映射子集上达到 ≥ 0.95避免用不匹配的 playbook 虚增覆盖率来凑过原始比率仅作透明披露不做门禁。每类别存在性子门禁playbooks/packs/v1/下每个已发布类别当前 21 个目录如account-takeover、bec、cloud-misconfig、container-escape、data-exfil都必须至少覆盖 1 条事件否则视为死重与数据集↔pack 对齐回归。动作对齐子门禁≥ 0.85匹配事件中必须有对应动作类型的步骤isolate_host→isolate_host、block_indicator→block_ip等这是阻止只靠标签匹配的 playbook 被算作真实响应的关键。由此形成三条可预测的 CI 行为删掉一个 playbook → 覆盖率下降 → CI 失败加入坏 playbook触发条件错误/无对齐步骤→ 孤儿门禁失败加入覆盖此前孤儿模板的新 playbook → 覆盖率上升且不会产生假阴性因为按模板宏也被同时报告。5. Rate cardUSD 数字的唯一来源评测页上的美元数字按每次 wet eval 运行时的公开挂牌价计算。运行时的费率被记录进 JSON 报告wet_eval.usd.rate_card_at_run因此历史美元数字不会因价格变动而被悄悄重估。5.1 代码中的费率表实际费率常量位于 scripts/eval_telemetry.py单位为 USD / 1M tokensProvider模型输入 ($/1M tok)输出 ($/1M tok)OpenAIgpt-4o2.5010.00OpenAIgpt-4o-mini0.150.60OpenAIgpt-4-turbo10.0030.00OpenAIgpt-5占位5.0015.00Anthropicclaude-3.5-sonnet3.0015.00Anthropicclaude-3-haiku0.251.25Googlegemini-1.5-pro1.255.00Googlegemini-1.5-flash0.0750.30本地ollama/llama3.1:8b0.000.00代码注释明确标注这些是illustrative public 2025-era list prices替代为你租户实际支付的费率即可它们与services/agents/app/core/cost_telemetry.py按 1K token 计价即上表除以 1000保持一致使 substrate 门禁与运行时成本账本共用同一套成本模型。注意两处需要以代码为准的细节1文档的 rate card 表列出的是claude-3.5-haiku0.80 / 4.00而代码中的键是claude-3-haiku0.25 / 1.252文档提到的--rate-card覆盖参数在当前run_evals.py的 argparse 参数集合中并不存在可用的覆盖路径是替换RATE_CARD_2025_USD_PER_M或向cost_usd()传入自定义rate_card。复现历史数字前请核对这两点。5.2 未知模型的定价语义cost_usd()在未知模型上会回退到gpt-4o条目这对 substrate 预算是可接受的但在 wet eval 中是危险的一个本地 Ollama 运行会被贴上头条费率模型的标签报告就会命名一个从未被调用的模型并按该模型的价目给 token 定价。因此 wet eval 路径做了两层防护--wet-model参数把实际服务的模型名写入报告model字段当模型在 rate card 中没有条目时USD 记为None并给出说明——未测量该模型没有 rate card 条目自托管模型没有可套用的每 token 挂牌价见 scripts/wet_eval.py。5.3 更新费率的正确流程维护者更新价格的路径在文档中写明修改 scripts/run_evals.py 中的费率字典、设置effective_from、提 PR。下一次 wet eval 运行会自动采用。当前实现中费率常量实际位于scripts/eval_telemetry.pywet_eval.py通过from eval_telemetry import RATE_CARD_2025_USD_PER_M复用因此修改点应为该文件——这是源码与文档的另一处轻微偏差但语义一致。历史美元数字不会被回溯改写只有显式请求时才重算。如果供应商在周中涨价下一次每周 wet eval 会反映新费率差异可在eval-results/eval/results/sha.json - wet_eval.usd.rate_card_at_run中看到。5.4 Token 与延迟预算的确定性估算在 substrate 路径上eval_telemetry.py用一套完全确定性的启发式给出每次调查的预算prompt_tokens 800系统提示 工具 schema 预算 ceil(len(description) / 4) ceil(Σ len(json.dumps(event)) / 4) # 仅前 5 条遥测事件 completion_tokens 800 × severity_factor severity_factor: info 0.5 / low 0.7 / medium 1.0 / high 1.4 / critical 1.8其中 4 字符/token 是 OpenAI 公开的英文文本经验值_TELEMETRY_EVENTS_PER_PROMPT 5模拟首轮上下文包的形状800 的系统预算刻意设置得比真实 Agent 更宽裕——宁愿误报一次成本回归也不要漏掉真实回归。这些数字在报告中被标记为mode: deterministic_substrate是上界投影而非实测wet eval 会用真实 token 计数替代它们。6. 如何复现文档承诺每个数字都能从全新 clone 在 30 秒内substrate或 10–30 分钟内wet eval取决于供应商与并发复现。6.1 Substrate 运行每 PR无需 LLM 密钥git clone https://github.com/beenuar/AiSOC.git cd AiSOC pnpm install python scripts/run_evals.py --json --out my-eval.json python scripts/render_eval_charts.py my-eval.json或者一条命令pnpm eval:public该脚本定义在根 package.json 中等价于先run_evals.py --out eval_report.json再render_eval_charts.py eval_report.json。它会运行统一评测器、写出eval_report.json并把按套件的 markdown 图表包渲染到eval/results/charts/便于贴进仪表盘或 PR 评论。substrate 部分不需要任何 API key。render_eval_charts.py还会把四张 SVG 落到文档站latency-p50-p95-p99.svg、tokens-distribution.svg、usd-distribution.svg、latency-by-template.svg位于 apps/docs/docs/benchmark-charts。若报告中没有wet_eval或per_investigation块它会输出明确占位说明绝不插补数字。6.2 常用参数速查scripts/run_evals.py 的 CLI 参数如下表默认值与帮助文本取自源码参数默认值作用--suiteall运行全部套件或按名称隔离运行单个套件--json关把 JSON 报告打印到 stdout--outrepo/eval_report.json报告写入路径--ci关任一套件低于其目标下限时以非零码退出--baseline无与保存的基线 JSON 对比Wave 2 / w2-dac--max-regression-pp1.0允许的 MITRE 准确率回退百分点--telemetry-only关跳过 substrate 门禁只输出 token/USD/延迟遥测块--telemetry-modelgpt-4o计价时套用的模型名--no-telemetry-records关从报告中删掉逐事件遥测数组聚合与按模板统计始终保留--wet关运行实时 LLM wet eval需要WET_EVAL_OPENAI_KEY--dry-run关仅配合--wet用确定性预算合成 wet eval 报告形状不发起真实调用--wet-out无额外把 wet eval 块写到此路径供wet_eval_update_benchmark.py消费--wet-limit无仅配合--wet最多调度 N 条事件确定性前缀报告记录实际用量--wet-model无仅配合--wet实际服务的模型名写入报告model字段--wet-require-live关仅配合--wet实时路径降级为 substrate 时报错而不是静默降级退出码语义如下便于接入 CI退出码含义0所有门禁通过或未设置--ci1至少一个套件低于目标下限仅--ci时2MITRE 准确率相对基线回退 ≥--max-regression-pp3Eval substrate 导入失败services/agents依赖未安装6.3 Wet eval每周需要 LLM 凭证export AISOC_BENCH_PROVIDERopenai export OPENAI_API_KEYsk-... python scripts/run_evals.py --wet --concurrency 8 --out my-wet-eval.json python scripts/render_eval_charts.py my-wet-eval.json几个必须知道的实现细节实时路径的密钥读取自WET_EVAL_OPENAI_KEY而不是OPENAI_API_KEY见 scripts/wet_eval.py。这样 CI 机器的密钥卫生是显式的wet eval 盒子只会看到 wet eval 的键看不到任何租户凭证。随后它用os.environ.setdefault(OPENAI_API_KEY, api_key)做尽力而为的桥接且不会覆盖本地已有的个人键。文档中的--concurrency参数在当前 argparse 中未定义直接传入会报参数错误请以源码参数表为准。凭证不落配置文件只在运行期间从环境读取退出即丢弃。这与 BYOK 流程一致可参考 apps/docs/docs/operations/credentials.md。本地模型路径Ollama 提供 OpenAI 兼容端点services/agents/app/llm/factory.py已支持OPENAI_BASE_URL因此可以在没有任何 secret 的 runner 上驱动真实 Agent——这正是 .github/workflows/live-agent-eval.yml 的做法。该工作流对qwen2.5:0.5b与llama3.2:3b-instruct-q4_K_Mdocker-compose.yml实际拉取的模型做矩阵运行用--wet-limit 10控制 CPU 预算并用--wet-require-live防止未调用模型却通过。6.4 与已发布数字对比每个已发布的 wet eval 运行都会把快照推到eval-results分支。与latest.json对比python scripts/run_evals.py --baseline eval/results/latest.json \ --max-regression-pp 1.0 --out my-eval.json如果mitre_accuracy相对基线回退超过 1.0 个百分点该次运行失败。另有 scripts/check_scoreboard.py 对公开记分板做陈旧度门禁最新一行的日期超过 45 天即失败MAX_SCOREBOARD_AGE_DAYS 45。之所以是 45 天而不是 7 天是因为每周任务需要已配置经费的供应商密钥该门禁捕捉的是记分板长期停滞而页面仍宣称每周更新这一类实际发生过的失效。7. 如何与自己的 SOC 对比这套评测被设计为可对任何能摄入 JSON 语料、输出分组事件与调查报告的 SIEM/SOAR 复现。协议刻意保持最小化使厂商或内部团队一个下午就能跑完并公开结果。使用同一数据集。检出你要对比的 commit原样使用services/agents/tests/eval_data/synthetic_incidents.json。不要重新生成——文件 SHA-256 应与评测页上的 provenance 行一致。使用同一指标。同时报告逐事件均值与按模板宏平均而不只是逐事件均值。语料是 55 个模板循环 3–4 次仅看逐事件是更弱的信号。运行你能够复现的五个套件。mitre_accuracy、alert_reduction、investigation_completeness、response_quality、playbook_completion_rate都位于 services/agents/tests 下且不依赖 AiSOC 专有运行时。把被测 substrate 代码换成你的等价实现即可。wet eval 必须声明模型与 rate card。没有这两个标签延迟、token 与美元数字跨供应商不可比——请在提交结果时与数字一并记录。提交报告。文档规划的reproductions-and-comparisonsissue 模板位于.github/ISSUE_TEMPLATE/benchmark_reproduction.yml随 v8.0 计划的 T5.4 一起落地在模板落地前请开一个带benchmark:reproduction标签的普通 issue附上 commit SHA、数据集 SHA、评测模式、模型与eval_report.json。文档明确欢迎任何复现——包括显示 AiSOC 在某个模板族上落败的复现。发现回归请提 issue 或 PR这套 harness 存在的意义正是把这些暴露出来。8. 局限性这套评测不能告诉你什么开源诚实性要求把边界写清楚。以下五类限制在文档中逐条列出并能在源码中找到对应证据。8.1 合成数据不是生产数据200 条语料是手工塑形以覆盖结构多样的模板但真实 SOC 告警流在三点上不同分布真实环境由 5–10 条噪声规则主导评测均匀分布模板使每个模板都被练到。对抗漂移真实攻击者会变异语料是静态的。adversary_eval套件heavy / medium / light 三档部分缓解但不能替代红队数据。其三档门禁为 light ≥ 0.85轻度 leetspeak 等价于控制组、整体 ≥ 0.40重变异下预期从 0.95 基线掉约 50 个百分点、heavy ≤ 0.50若重变异档也抓太多说明控制组本身失真。上下文形状真实事件携带组织特有上下文资产重要性、营业时间、责任人评测把这些归一化掉了。评测能告诉你的AiSOC 的 substrate 在固定语料上是否随时间变差、wet eval 稳态成本大致是多少、哪些模板族出现回归。8.2 Substrate 自检在设计上就是同义反复mitre_accuracy、investigation_completeness、response_quality是用来门禁 substrate 一致性的不是 LLM 能力。这是整套评测中最容易被误读的部分。若你想主张AiSOC 的 Agent 在 MITRE 分类上 97% 准确substrate 分数不支持这个主张wet eval 的 LLM-as-judge 变体才是该主张对应的指标。8.3 Wet eval 的方差即使温度设为 0LLM 输出仍非确定供应商会以不同方式批处理请求。延迟取决于供应商负载token 计数取决于模型的 tokenizer 版本。公布的 p50/p95/p99 来自单次每周运行不报告置信区间因为 n200 小到头条数字会逐周可见地移动。做跨周比较时应看趋势而不是某一次周快照。8.4 成本是 rate card 成本不是基础设施成本每次调查的美元数字只包含 LLM API 开销不包含基础设施计算、存储、可观测性、工程时间也不包含人工复核 Agent 建议的成本。真实的 SOC TCO 模型必须把那些加进去。8.5 Playbook 完成率是覆盖率不是质量50.5% 的整体完成率是合成事件的类别、严重度与响应动作被playbooks/packs/v1/中至少一个 playbook 匹配的比例。它不执行playbook、不计步骤耗时、也不衡量其在实时遥测下的可靠性。步骤执行由 playbook 引擎自身的单元测试覆盖——具体文件为 services/agents/tests/test_playbook_engine_correctness.py、services/agents/tests/test_playbook_steps_act.py、services/agents/tests/test_playbook_control_flow.py 等文档中引用的test_playbook_engine.py在当前仓库中不存在请以上述文件名检索。8.6 连接器 / SIEM 覆盖缺口合成遥测语料目前覆盖 14 个日志来源。一个尚未被手工建模进语料的连接器例如某个小众身份提供商不会出现在任何套件中。提交新模板 支撑遥测是正确的补齐路径。9. 一张图看懂该引用哪个数字你想说的话应该引用的指标不能引用的指标回归没发生substrate 逐事件均值 按模板宏—实时 Agent 的分类准确率wet eval LLM-as-judgesubstratemitre_accuracy每次调查花多少钱wet evalusd_*含 rate card 标签substrateper_investigation.usd上界投影单次调查多快wet evallatency_*substratelatency_ms微秒级路径告警能降多少产品逻辑correlation_key()测得的比率遗留四层套件的 75.3%响应覆盖够不够playbook_completion_rate覆盖率语义任何响应有效的主张10. 延伸阅读与后续演进实际数字与逐套件解释见评测页 apps/docs/docs/benchmark.md公开记分板与社区提交见 apps/docs/docs/benchmark-scoreboard.mdx历史快照在eval-results分支计划中的扩展token USD 遥测 T2.4、公开记分板 T5.4、每周 wet eval CI T5.5、公开数据集保真基准 T5.3见 plans/future-release-implementation-plan.md开源 Agent 代码位于 services/agents——每次 wet eval 运行的都是同一份代码。复现入口最终收敛为两条命令pnpm eval:public用于 substrate 回归python scripts/run_evals.py --wet --out my-wet-eval.json用于真实 LLM 测量。前者是每个 PR 的门禁后者是需要凭证与预算的周期性测量。把这两者混为一谈是阅读任何 AI SOC 基准时最容易犯、也最昂贵的错误。赞分享人工智能AI Agent网络安全后端前端【免费下载链接】AiSOCOpen-source AI Security Operations Center: alert fusion, LLM-agent triage, MITRE ATTCK investigation, and a replayable decision ledger for every agent step. Self-hostable, runs with no API keys, MIT licensed. Ships an MCP server for Claude, Cursor and Continue.项目地址https://gitcode.com/GitHub_Trending/ai/AiSOC点击查看免费下载相关推荐Amis-LocalAI基准测试方法论5步构建可复现的本地大模型性能评测体系Amis LocalAI基准测试方法论5步构建可复现的本地大模型性能评测体系 本指南面向刚接触 AmisAmis LocalAI 本地推理运行时 桌面工Cosmos Policy 之 LIBERO 评测实战一条命令复现论文基准成绩Cosmos Policy 之 LIBERO 评测实战一条命令复现论文基准成绩 Cosmos Policy 是 NVIDIA 推出的「用视频世界模型做机器人策Headroom 基准测试指南压缩性能、准确率验证与可复现的评测方法Headroom 基准测试指南压缩性能、准确率验证与可复现的评测方法 Headroom 的核心承诺是压缩上下文但不损失准确率。本篇技术文章以仓库中 wik人工智能大模型LLM网关AI Agent上一篇67K star 杀回 GitHub 日榜前八IBM Docling 的这轮回热比上次上榜更值得盯下一篇手把手LangChain 有状态 Agent 迁到 Agent Substrate30 倍超分复用怎么配创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考