Forráskód Böngészése

基线口径试完: A3 决定性结果 —— 公式确认无疑(fleet_med 在该行集上 100%), 唯一未知是样件行集少 276 行

四个候选全试完, 结论一句话: **差的是行集, 不是公式**。
| 基线算在哪个行集 | fleet_med 不一致 | z 不一致 |
| A1 本器行集(9163) | 528 | 707 |
| A2 全量组(不卡 n>=3) | 3095 | 3823 |
| A3 只用样件那批键(8887) | **0** | **68** |
| A4 跨窗合并(w0127+w0316) | 8337 | 8884 |

⇒ 基线公式确认: median(val) + 1.4826*MAD, 在正确行集上 fleet_med 逐值 100% 一致、z 99.2%(剩 68 处,
疑似 MAD≈0/小样本键的兜底)。剩下唯一未知 = 样件行集比本器少 276 行(3.1%, 全是 n>=3 低样本组, 缺 0 行),
正是这 276 行把 fleet 中位数拉偏了 5~8%(A1 与 A3 的差距全部来自这里)。
行集假设 H1(全覆盖 7 bin)/H2(>=2 bin)/H3(每键前 K 台)/bin 覆盖度阈值 全部过砍 —— 都不成立;
最可能是样件计算时点的记录到达差异, 而非某条筛选规则。

docs §6.4 改成这张决定性对照表 + 过砍假设表, 并保留上轮的自我更正(对拍列名写漏导致的假 0)。
zhouyang.xie 3 hete
szülő
commit
0e0e696ea5
1 módosított fájl, 32 hozzáadás és 10 törlés
  1. 32 10
      docs/振动六层链_接口规格与缺口_v0.1.md

+ 32 - 10
docs/振动六层链_接口规格与缺口_v0.1.md

@@ -117,16 +117,38 @@ MAD=0.80209 → z=−0.3116 · IQR/1.349=1.46899 → z=−0.1701 ·
    Usage)与 `RPM`(`rms_rawRPM_DC`)以及全部波形/谱名。**注意:原先按 `meas_type` /
    `meas_source` 找都不成立,`y_unit` 才是那把钥匙。**
 
-### 6.4 仍未闭合的一件事:`fleet_med` / `z` 的基线口径
-
-`val` 100% 一致、而 `fleet_med` 94%、`z` 92% ⇒ **差在基线怎么算**,不在取值。已排除:
-按我当前这套行集算 `median(val)` + `1.4826×MAD`(单点验中、整体 94%)。
-待试的候选(按可能性排序):① 基线用**未过 `n≥3`** 的全量组;② 基线**跨窗合并**(w0127+w0316);
-③ 尺度用**样件那批机组**的 MAD(即基线集合 = 样件行集,而非本器行集);④ 截尾/加权(如去掉 n 最小的一档)。
-
-★ **一条自我更正**:本轮中途我曾用"值不一致 = 0"的说法,那是探测脚本里对拍列名写漏(`fleet_med`/`z`
-在样件侧没有配对的 `_本` 列,被 `continue` 跳过了)造成的假象;以上表格是 `rudong_fusion_run.py --verify`
-(本器自带、三列都查)给出的**真数**。留在这里以免下次又被同一类"对拍自己骗自己"骗到。
+### 6.4 仍未闭合的一件事:样件的**行集**(不是公式)
+
+本轮把 §6.4 的候选试完了,得到一个**决定性的结论**:
+
+| 基线算在哪个行集上 | `fleet_med` 不一致 | `z` 不一致 |
+|---|---:|---:|
+| A1 本器行集(9,163 行,= 量纲闸 + n≥3) | 528 | 707 |
+| A2 全量组(不卡 n≥3) | 3095 | 3823 |
+| **A3 只用样件那批键(8,887 行)** | **0** | **68** |
+| A4 跨窗合并(w0127+w0316) | 8337 | 8884 |
+
+⇒ **基线公式已经确认无疑**:在**正确的行集**上算 `median(val)` + `1.4826×MAD`,`fleet_med` 逐值 **100% 一致**,
+`z` 99.2% 一致(剩 68 处,疑似 `MAD≈0`/小样本键的兜底规则)。
+
+⇒ 剩下的唯一未知是**样件的行集比本器少 276 行**(3.1%,全是 `n≥3` 的低样本组,缺 0 行)。
+那 276 行会**抬高/压低同一键的 fleet 中位数**,于是基线整体偏 5–8% —— A1 与 A3 的差距就来自这里。
+试过的行集假设全部**过砍**(都不成立):
+
+| 假设 | 结果 |
+|---|---|
+| H1 该机组在该 sensor/meas 下覆盖全部 7 个 bin | 9,163 → 966 行(砍掉太多) |
+| H2 覆盖 ≥ 2 个 bin | → 6,847 行(砍掉太多) |
+| H3 每键取 n 最大的前 K 台(K=20/24/28/34) | → 6,250 / 7,106 / 7,878 / 8,762 行(K=34 仍多 125 行) |
+| bin 覆盖度阈值(已试 3…20) | 9,163 → 8,981(th=5)→ 8,933(th=10)→ 7,463(th=16,开始缺行) |
+
+★ **一条自我更正**:上一轮我曾用"值不一致 = 0"的说法,那是探测脚本里对拍列名写漏(`fleet_med`/`z`
+在样件侧没有配对的 `_本` 列,被 `continue` 跳过了)造成的假象;以上表格是真数。
+留在这里,以免下次又被同一类"对拍自己骗自己"骗到。
+
+**下一步只剩一件事**:把那 276 行"样件为什么没收"钉死(最可能是样件计算时点的记录到达差异,
+而不是一条筛选规则 —— 若是规则,H1/H2/H3 或覆盖度阈值里总该有一个正好命中)。钉死之后
+`fleet_scalar_z` 即可正式转 raw-derived。
 
 ### 6.5 结论