# 子设计 2：Case 正确性评判 **Date:** 2026-04-20 **Status:** Draft for discussion --- ## Summary 一个 case 的“正确性”不能只靠看最终回答像不像。对数据库故障诊断 agent 来说，至少要同时判断： - 有没有可靠完成执行 - 根因和关键事实是否正确 - 证据链和因果链是否成立 - 推荐动作是否对症 因此 v1 判分必须采用分层设计： 1. `Execution Checks` 2. `Deterministic Rubric Checks` 3. `LLM Semantic Judge` 其中 deterministic rubric 是主要 gate，LLM 只做语义补充。 这里的 `rubric` 可以理解成某个 case 的“判定清单”。 它不是一句笼统的“答案要正确”，而是一组可以逐项检查的要求，例如： - 必须识别某个 root cause - 必须触达某类 evidence - 必须提到某个关键实例或 digest - 不能把某个干扰因素误判为主因 因此，rubric 的作用是把“case 是否成功”从模糊判断，转换成结构化、可复查、可自动执行的判定规则。 --- ## Correctness Dimensions ### 1. Execution Correctness 判断 run 是否真正执行成功，而不是被环境或工具故障污染。 ### 2. Factual Correctness 判断 root cause、instance、digest、metric、版本、时间窗等关键事实是否正确。 ### 3. Reasoning Correctness 判断证据是否能支撑结论，是否存在主次颠倒、跳跃推理或证据不足。 ### 4. Recommendation Correctness 判断建议是否针对真实根因，而不是泛泛而谈或误导。 --- ## Judge Layer 1: Execution Checks 这一层只回答一个问题：`这个结果是否可评`。 ### Required checks - workspace 创建是否成功 - source prepare 是否成功 - diagnosis 是否完成 - 是否出现 tool failure / timeout / malformed output - 是否超出允许的 follow-up 次数 - final output 是否为空或明显不完整 ### Output 建议标准化为： - `success` - `infra_fail` - `tool_fail` - `timeout` - `malformed` - `incomplete` 默认规则： - 只要 execution status 不是 `success`，case 就直接 fail 或标记为 invalid，不进入后续语义判分 --- ## Judge Layer 2: Deterministic Rubric Checks 这是 v1 的主判层。 ### Core principle 先从最终回答和工具轨迹中抽取结构化 facts，再与 case spec 中的 rubric 匹配。不要直接用整段自然语言做弱字符串比对。 ### Extracted facts 建议抽取： - root cause candidates - involved components - involved instances - SQL digests - metric names and values - time window - known bug / issue IDs - recommendations - data sources touched ### Rubric categories 每个 case rubric 建议分三类： - `critical` 缺一项直接 fail - `major` 显著影响质量，按覆盖率判定 - `minor` 只影响 score，不直接 blocking ### Typical deterministic checks - 是否识别了正确 root cause - 是否识别了关键 hotspot instance - 是否检查了 Go GC 指标 - 是否使用规定的数据源组合 - 是否命中指定 slow query digest - 是否提到 known bug ID / PR / version gap - 是否给出特定 recommendation 类型 - 是否触发 negative assertion ### Negative assertions negative assertions 是非常重要的 guardrail，例如： - 不能把 ANALYZE 当主因 - 不能只说高 CPU 而不检查 GC - 不能只说慢 SQL 而不识别主 hotspot 一旦命中 negative assertion，应直接 fail。 --- ## Judge Layer 3: LLM Semantic Judge 规则无法稳定覆盖的部分，由 LLM semantic judge 补充。 ### Suitable tasks - 判断 primary / secondary root cause 的优先级是否正确 - 判断因果链是否完整 - 判断 recommendations 是否和根因一致 - 判断是否有幻觉或无证据断言 ### Input contract semantic judge 默认不直接读取全量 transcript，而应优先读取压缩后的 evaluation packet： - final diagnosis - extracted facts - rubric - negative assertions - baseline diff - 少量必要证据摘要 只有 fail case、边界 case 或人工要求 explain mode 时，才补充更多原文上下文。 ### Unsuitable tasks 不应让 LLM 负责： - 硬性实体识别 - critical rubric pass/fail - execution failure 判定 ### Output 建议输出： - `root_cause_score` - `causal_chain_score` - `recommendation_score` - `hallucination_risk` - `semantic_summary` - `explanations` 默认应输出短结构化结果，避免把 explanation token 成本摊到所有 case。详细 explanation 只在 fail / regression case 生成。 --- ## Final Verdict Logic 建议 v1 默认判定规则： 一个 case 通过，必须同时满足： - execution status = `success` - 所有 critical rubric 通过 - major rubric 覆盖率达到阈值 - 没有触发 negative assertion - overall score 不低于阈值 建议优先级顺序： 1. execution fail -> fail 2. negative assertion hit -> fail 3. critical rubric fail -> fail 4. major coverage below threshold -> fail 5. 其余使用 score 和 diff 反映质量变化 --- ## Suggested Scoring Model 建议把结果拆成多个子分数，而不是只有一个 overall： - `coverage_score` - `root_cause_score` - `causal_chain_score` - `recommendation_score` - `tool_reliability_score` - `overall_score` 其中： - `coverage_score` 主要来自 deterministic rubric - `root_cause_score` 可由 deterministic + semantic 组合 - `overall_score` 用于趋势分析，不直接替代 hard gate --- ## Regression Comparison daily run 的判分结果必须能与 baseline 做结构化 diff。 ### Required diff dimensions - pass -> fail / fail -> pass - critical rubric 减少 - major 覆盖率下降 - root cause 文义变化 - recommendation 退化 - 新出现 tool failure - 成本或 follow-up 轮次上升 ### Regression severity 建议分级： - `critical` pass -> fail，或命中核心 case critical item - `high` root cause / evidence chain 明显退化 - `medium` recommendation 或覆盖率下降 - `low` 文案或 minor rubric 退化 --- ## Failure Taxonomy Mapping 判分结果不应只有数字，还需要归因。 建议把 fail 映射到 taxonomy： - `wrong_root_cause` - `partial_root_cause` - `missed_incident_window` - `missed_gc_check` - `missed_hotspot_instance` - `insufficient_cross_reference` - `wrong_tool_or_param` - `tool_execution_failure` - `weak_recommendation` - `hallucinated_evidence` 一条失败记录建议包含： - primary failure code - secondary failure codes - judge explanation --- ## Anti-Flakiness Rules 为了降低 daily regression 抖动，判分规则需要遵循以下原则： - deterministic facts 优先于自然语言相似度 - critical items 只使用稳定、明确的实体或结论 - 不对措辞风格做评分 - LLM judge 只用于语义补充，不做主 gate - judge version 必须持久化，避免判分规则漂移不可解释 --- ## Defaults - 主 gate 是 deterministic rubric - critical rubric fail 直接 fail - negative assertion hit 直接 fail - LLM semantic judge 不能覆盖 deterministic hard fail - final verdict 必须可解释，并附带 failure codes