事故日志里的最后一条错误往往是最响亮的症状。连接池耗尽之后RPC超时、重试、队列积压会接连出现模型如果抓住了“Timeout”就开始讲网络故事回答可能很像复盘却没有找到始发原因。把十万行日志塞进窗口只解决输入容量不解决评分。先构造一份小而明确的因果真值再扩大数据量才能知道评测器奖励的是原因还是故事。时间顺序只是必要线索下面的教学事故包含三个事件连接泄漏、连接池满、上游超时。因果边由场景构造者给定并非程序从日志自动发现。模型可以生成根因与证据ID校验器则检查ID是否存在、根因是否匹配、必要边是否缺失。这样至少不会因为回答里出现几个术语就给高分。truth {root: leak, edges: {(leak, pool_full), (pool_full, timeout)}} events {leak: 1, pool_full: 2, timeout: 3} def grade(answer): quoted set(answer.get(evidence, [])) supplied_edges {tuple(e) for e in answer.get(edges, [])} unknown quoted - events.keys() root_ok answer.get(root) truth[root] missing truth[edges] - supplied_edges unsupported supplied_edges - truth[edges] return {root_ok: root_ok, unknown_evidence: sorted(unknown), missing_edges: sorted(missing), unsupported_edges: sorted(unsupported), pass: root_ok and not unknown and not missing and not unsupported} supported {root: leak, evidence: list(events), edges: [(leak, pool_full), (pool_full, timeout)]} symptom {root: timeout, evidence: [timeout], edges: []} fabricated dict(supported, evidence[leak, missing_event]) assert grade(supported)[pass] assert not grade(symptom)[root_ok] assert not grade(fabricated)[pass] print(cause, required edges, fabricated evidence: PASS)这只是离线校验器已经验证三个手写答案没有调用Kimi也没有读取企业生产日志。若扩大到十万行必须保存原始事件与插入的干扰行并用目标分词器实数输入规模。字符数、行数和Token数应各报各的。把新模型放进同一套协议Kimi API现在同时列出K3与K3.1 Pro等型号。比较时不仅要固定题集还要记录工具是否可用、思考强度、输入是否分块以及完整输出是否被截断。官方型号列表Anthropic 的Agent评测文章把任务、运行轨迹和评分器区分开来。这里沿用这种分层思路不引用其分数。事故评测还应加入反例同样出现超时但始发原因换成限流同样有连接池满却只是下游变慢的结果。只有这些变体也能区分才说明模型没有记住固定故事。不要用这一张教学因果图宣布“RAG全面失效”。检索策略、索引粒度和问题设置都可能改变结果应该把失败归到具体条件而不是归到整个方法名下。
