事故日志里的最后一条错误，往往是最响亮的症状。连接池耗尽之后，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全面失效”。检索策略、索引粒度和问题设置都可能改变结果，应该把失败归到具体条件，而不是归到整个方法名下。