用 MAI-Cyber-1-Flash 研判告警时，结论时对时错，通常先不要急着怀疑模型能力。更常见的情况是：喂进去的那条告警字段不全，模型只能在信息缺口上做保守推断。判断一条告警研判靠不靠谱，可以先做一个动作——挑一条典型告警，把模型实际能看到的字段逐个列出来，标出哪些是空的、哪些只有设备厂商的摘要文本、哪些是原始日志里本来就没有的。字段清单列清楚之后，再看缺失项会把结论推向哪个方向，最后按接入成本排补字段的顺序，而不是一开始就大改模型或提示词。
对单条告警做研判质量评估，建议先核对输入字段完整度，再评价模型结论。列全时间、主机、账号、进程、命令行、父进程、外联地址七类字段，逐项标注缺失；命令行缺失时结论通常只能停在进程名层面，账号缺失时无法区分是服务账号还是人；外联地址缺失时难以判断是正常更新还是可疑回连。补字段建议按进程树记录、登录日志、DNS 与外联记录的顺序推进，成本由低到高。同时在输出上约定结论栏与证据栏，缺关键证据统一落到待人工。是否有效，需要用同一批告警做补字段前后的对照来确认，而不是只看单条结论对不对。
挑一条典型告警拆成字段清单
选一条你认为模型判错的告警，找到它进入研判链路前的原始结构，而不是告警列表页上那句摘要。很多告警平台只把标题和描述传给模型，原始字段被丢在上游。可以先在日志采集侧或告警转发配置里确认：MAI-Cyber-1-Flash 收到的请求体里到底带了哪些键。下面是一份字段核对清单，可以直接照着逐项打勾。
- 时间：事件发生时间、日志采集时间、告警生成时间是否都有。若只有告警生成时间，模型无法判断进程启动与网络外联的先后关系。
- 主机：主机名、IP、资产归属、业务角色。只有 IP 时，模型不知道这是办公终端还是对外服务器。
- 账号：执行账号、账号类型（服务账号或交互登录）、是否特权账号。缺失时无法判断行为是否符合该账号的日常画像。
- 进程：进程名、进程路径、PID。仅有进程名时，容易把同名程序混为一谈。
- 命令行：完整命令行参数。这是判断意图最直接的字段，缺失时结论会明显变弱。
- 父进程：父进程名、父进程命令行、进程树层级。缺失时无法区分是交互式启动还是被脚本、计划任务拉起。
- 外联地址：目标 IP、域名、端口、协议、解析记录。缺失时只能在进程行为层面推断。
标注方式建议用一张简表，缺失直接写“缺”，有值但被截断写“截断”，只有厂商摘要文本的写“仅摘要”。这三种状态对模型的意义完全不同，混在一起会让后续排查失去方向。
分别确认缺字段时结论会落到哪个方向
字段缺失不是让结论“稍微不准”，而是让结论类型发生变化。可以先按下面三类分别核对，看你的告警落在哪一类。
命令行缺失
模型只能看到进程名和路径，通常只能给出“某个进程在某个主机上运行”这类描述性结论，对是否为恶意行为的判断会非常保守，多半会写成“需结合命令行与进程树进一步确认”。这时模型不是判错，而是没有足够输入去判断。
账号缺失
模型无法区分这次操作是服务账号例行任务，还是有人用交互账号手工执行。结论通常会退回到“无法确认执行者身份，建议核实登录来源”，对横向移动、权限提升类告警的研判基本停在表层。
外联地址缺失
模型看不到目标 IP、域名和端口，只能依据进程行为判断。对于下载、更新类行为，模型无法区分是正常软件更新还是可疑回连，通常会给出“存在外联行为但目的不明”的保守结论，难以支撑阻断类动作。
把这三类情况对照自己的告警样本，能较快看出“模型判错”里有多少其实是输入不足。需要结合环境确认的是：某些字段在你的采集链路上是否本来就拿不到，例如终端未开启命令行审计，这类缺口补起来成本较高，应单独标记。
按接入成本排出补字段顺序
补字段不要一次性全上，先按成本从低到高推进，每补一类就回头验证结论是否变化。下面是一个可参考的顺序，数据来源系统需要按你实际使用的组件替换。
| 顺序 | 补充字段 | 数据来源系统 | 说明 |
|---|---|---|---|
| 1 | 进程树记录（父进程、命令行、进程路径） | 终端侧进程审计、EDR 事件表、主机审计日志 | 通常已有采集，只是没透传到研判请求里，改转发字段的成本最低 |
| 2 | 登录日志（账号、登录类型、来源地址） | 系统认证日志、域控登录审计、堡垒机会话记录 | 需要按主机和时间关联，注意时区与时钟同步 |
| 3 | DNS 与外联记录（域名、解析结果、连接五元组） | DNS 日志、防火墙会话表、网络流量记录 | 数据量大、关联窗口要控制，建议先按告警时间前后取一个短窗口 |
接入时可以先在告警转发层做字段映射，把上游原始字段名对齐到研判请求的固定键，避免模型侧反复改提示词。下面的骨架仅示意字段组装方式，键名按你的实际接口替换，不要直接照搬。
{
"alert_time": "原始事件时间",
"host": {"name": "主机名", "ip": "主机IP", "role": "资产角色"},
"account": {"name": "账号", "type": "service|interactive", "privileged": true},
"process": {"name": "进程名", "path": "进程路径", "pid": 0},
"cmdline": "完整命令行",
"parent_process": {"name": "父进程名", "cmdline": "父进程命令行"},
"network": {"dst_ip": "目标IP", "dst_domain": "目标域名", "dst_port": 0, "proto": "tcp"}
}验证方式很直接：补完一类字段后，取同一批历史告警重跑研判，比较结论栏和证据栏是否发生变化。如果字段补上后结论没有变化，说明该类字段对这批告警的判别贡献有限，可以不再优先投入。
把证据不足写成一种正式输出
信息不全时，模型最容易出现的问题是硬给一个确定结论。可以在输出格式上做约束：要求研判结果固定分两栏，结论栏和证据栏，证据栏必须逐条对应输入字段。缺关键证据时，结论栏统一落到“待人工”，而不是让模型自行推测。下面是一段输出约定示例，可放在系统提示或输出校验逻辑里。
输出要求：
1. 结论栏只能取以下值之一：确认可疑 / 疑似 / 待人工。
2. 证据栏逐条列出判断依据，每条必须引用输入中的具体字段值。
3. 若命令行、账号、外联地址中任一字段缺失，结论栏必须为“待人工”。
4. 证据栏中不得出现输入里不存在的字段值或推断出的地址、账号。
5. 字段被截断时，在证据栏注明“字段截断”，不得补全。这套约定同时便于做输入输出校验：在调用模型之后加一层检查，如果结论是“确认可疑”但证据栏引用了不存在的字段，就按格式错误退回重判。这样可以把“模型硬给结论”的问题变成可观测的格式问题，而不是靠人工逐条怀疑。
用同一批告警比对补字段前后的差异
验证补字段是否真的改变研判结果，方法是用同一批告警做前后对照，而不是换一批样本看感觉。建议从近期的告警里挑十几条，覆盖不同告警类型，保留补字段前的结论记录，再补字段重跑。对照表至少包含四项：补字段前结论、补字段后结论、证据栏变化、人工最终判定。
| 告警 | 补字段前结论 | 补字段后结论 | 证据栏变化 | 人工判定 |
|---|---|---|---|---|
| 示例A：异常进程启动 | 待人工（无命令行） | 疑似（命令行含下载参数） | 由“仅进程名”变为引用完整命令行与父进程 | 按实际核实结果填写 |
| 示例B：异常登录 | 待人工（无账号类型） | 待人工（账号为服务账号但仍需确认） | 新增账号类型与登录来源地址 | 按实际核实结果填写 |
| 示例C：可疑外联 | 疑似（仅进程行为） | 确认可疑或降级，视解析记录而定 | 新增目标域名与解析结果 | 按实际核实结果填写 |
表格里的结论和人工判定必须由你自己的样本填出，不能照抄。比对时注意两点：一是同一告警的输入时间窗口要一致，否则字段变化和时间变化混在一起，无法归因；二是如果补字段后结论从“疑似”变成“待人工”，不一定是退步，可能是模型不再在缺证据时硬判，这类变化同样值得记录。完成一轮对照后，再决定是继续补字段，还是调整输出约定，判断依据就落在可复查的记录上。