企业官网建设流程全解析

RuView 复现审计 WiFlow-STD：WiFi 姿态模型的 0.08% 翻车、重训回血与 30 倍瘦身实测

【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView

WiFlow-STD 是 2026 年一篇宣称仅凭 WiFi 信号即可达到97.25% PCK@20 姿态估计精度、参数量仅 2.23M 的 SOTA 预印本工作，且罕见地完整开放了代码、权重与 36 万样本数据集。本文基于 RuView 仓库 docs/research/wiflow-std-audit-gist.md 的完整审计记录，以及 benchmarks/wiflow-std/RESULTS.md 的实测数据与配套脚本，逐层还原"声称被复现"的全过程：发布产物为什么第一步就跑不起来、重训后真实精度是多少、作者架构是否存在 2.6 倍冗余、以及如何把它压成 295 KB / 0.66 ms 的端侧模型。读完你会掌握一套可复用的"先跑 artifact、再信 README"的复现方法论，以及一条从损坏数据集修复到 ONNX 量化部署的完整实证链路。

审计背景：一个"什么都公开"的 SOTA 模型

WiFlow 预印本（arXiv 2602.08661）的核心主张如下：

数据集细节：12.8 GB 压缩包解压后 15.5 GB，共360,000 个 540×20 的 CSI 窗口，每个窗口带 15 个关键点的 2D 标注。仓库按 commit06899d29（2026-04-05，Apache-2.0）固定上游版本进行审计。

RuView 团队对此执行一条铁律：一个数字在复现之前只能叫 "CLAIMED"，只有复现之后才叫 "MEASURED"。审计在 2026 年 6 月进行，全部数字为实测。

Day 1：发布产物"三连坏"，但没有一个是科学造假

缺陷 1：代码无法 import

上游models/__init__.py导入了TemporalConvNet，但models/tcn.py里根本没有这个类——包作为发布状态根本无法导入运行。修复是一行 sed 替换（把TemporalConvNet换成实际存在的TemporalBlock），这一行就记录在 benchmarks/wiflow-std/remote/setup_and_train.sh 中。

缺陷 2：发布的 checkpoint 只跑出 0.08%，而非 97.25%

用发布权重best_pose_model.pth、发布代码、发布数据、发布的分割流程（seed-42 文件级 70/15/15，测试集 54,000 样本）跑出来的实测结果（原始输出见 benchmarks/wiflow-std/results/repro_a.json，评测入口是 benchmarks/wiflow-std/eval_repro.py）：

诊断结论（在 2,000 个来自数据集前部文件的 NaN-free 窗口上验证，排除了分割错配的可能）：

• 预测与目标的相关性 Pearson r ≈ 0.76——这是一个真实训练过的模型，只是其关键点归一化/顺序与发布数据不一致；
• 全局逐轴仿射校正（后验拟合）最多把 PCK@20 拉到 ≈20%；
• 逐关键点仿射校正（15×2 个拟合变换，属于"作弊级"宽容）也只到 ≈72%，仍远低于 97.25%；
• 预测↔目标关键点对应矩阵退化——多个预测关键点最佳匹配到同一个目标关节，属于关键点约定不匹配。

此外，发布根 checkpoint 用的是改名前的模块名（att.*、final_conv.*），而发布代码用的是改名后的（attention.*、decoder.*）——形状与参数量一致，但证明该权重早于发布代码。第二个发布的 checkpoint（cross_dataset_test/WiFlow/best_pose_model.pth）甚至是另一种架构（342 通道输入 = MM-Fi 布局，3 层 TCN，3 通道 3D decoder），根本不能用于自家数据集。仓库在 _bench_common.py 里内置了LEGACY_RENAMES = {"att.": "attention.", "final_conv.": "decoder."}用于加载这类旧 checkpoint。

缺陷 3：数据集损坏，且训练时"静默中毒"

发布数据集的最后 13 个文件（索引 487–499，共 9,072 个窗口，占 2.52%）是损坏的：包含 NaN 以及高达 3.4×10³⁸（float32 最大值）的垃圾幅值，而其余数据都是 [0,1] 归一化的。

更隐蔽的是后果：上游训练循环使用fp16 混合精度且没有任何 NaN/inf 防护，第一个损坏 batch 就会溢出 autocast，进而永久污染模型的 BatchNorm 运行统计（GradScaler 的 step-skipping 保护不了 BN）。因此用公开下载直接训练，从 epoch 1 起必然产出 NaN——作者自己的训练曲线正常收敛，说明他们本地数据与 Kaggle 上传的数据并不一致。

缺陷 4~6：训练脚本自身的坑

• run.py忽略--data_dir参数，硬编码../preprocessed_csi_data；
• train.py调用未定义的plot_training_history，训练完成后内置测试阶段必然以 NameError 崩溃；
• 审计期间还发现，训练到中途遇到非有限 loss 时直接 break 而非报错退出（这属于审计方重训脚本的防御性设计，见下）。

判定：artifact rot，不是坏科学

如果审计止步于此，很容易得出"造假"的结论——那就错了。这六个缺陷全部是打包层面的腐烂（artifact rot），而不是方法层面的伪科学。要区分这两者，唯一途径就是真的把代码跑起来。审计方向上游提交了全部六个缺陷及修复（issue #3）；同时必须承认：作者公开的内容超过了 90% 的论文，这是本次审计得以成立的前提。

Day 1 稍后：修复产物，科学成立——重训复现 96.1~96.6%

修复路径：修好 import → 将 9,072 个损坏窗口清零 → 用作者自己的代码和超参数在单卡（RTX 5080）上从零重训约 50 分钟（约 75 s/epoch，early-stop 于第 41 epoch，最佳 epoch 36）。

结论：论文声称可复现。与发布数字的差距在 0.6–1.2 个 PCK 点内（单次运行、损坏窗口已清零、torch/GPU 不同），且参数量精确吻合。同时要记录三项被迫偏差：修复缺陷 1 的一行改动；torch 2.x+cu128 替代固定的 2.3.1（RTX 5080 的 Blackwell sm_120 需要 ≥2.7）；9,072 个损坏窗口整体清零（否则发布流水线从 epoch 1 就是 NaN）。

复现所需的全部工程底座在仓库中：评测循环 benchmarks/wiflow-std/_bench_common.py、复现入口 benchmarks/wiflow-std/eval_repro.py、一键环境搭建 benchmarks/wiflow-std/remote/setup_and_train.sh、数据集修复脚本 benchmarks/wiflow-std/remote/clean_v2.py。

损坏掩码：不可再生的证据

两个掩码文件 results/nan_windows_mask.npy（9,070 个 NaN/Inf 窗口）与 results/big_windows_mask.npy（9,072 个 |幅值|>1.5 的窗口，两者并集 9,072，全部位于文件 487–499）是已提交的 ground truth。它们只能在未清洗的原始下载上再生：一旦clean_v2.py原地清零损坏窗口，证据就永久消失，重新扫描只会得到全 False 掩码。因此 generate_corruption_masks.py 内置了防呆检查——扫描结果全 False 就拒绝覆写，并提示重新下载。判定准则：每窗口存在任一非有限值（NaN 掩码），或有限值最大绝对值 > 1.5（大值掩码，正常数据为 [0,1]）。2026-06-11 已验证：从本地原始下载再生成的掩码与提交版本逐位一致。

Day 2：架构存在 2.6 倍冗余——效率扫描实测

能训练之后，下一个问题很自然：这个架构真的需要 2.23M 参数吗？RuView 用纯通道/分组/步长的缩放，把上游架构参数化复制成CompactWiFlowPoseModel（见 benchmarks/wiflow-std/remote/sweep/model_compact.py），在完全相同的清洗数据、seed-42 文件级分割、损失与协议下从零训练三个变体（fp32、batch 64、≤50 epoch、patience 5，RTX 5080 上每变体约 22–29 分钟）。变体配置定义在 benchmarks/wiflow-std/remote/sweep/run_sweep.py，原始数据在 benchmarks/wiflow-std/results/efficiency_sweep.jsonl。

关键发现一：half 变体严格支配原版

843,834 参数的 half 模型在 PCK@20 上与原版持平（96.62% vs 96.61%），PCK@50 与 MPJPE 全面更好，且收敛更快（epoch 23 vs 36）。也就是说，作者发布的 2.23M 架构在自己的 benchmark 上是**过参数化（over-parameterized）**的。没有任何 SOTA 表格会主动公布"砍一半还更好"的消融，但自己跑一遍只需要一小时 GPU 时间——这本身就是一条明确的科研行动建议。

关键发现二：tiny 变体是端侧甜点

56,290 参数（原版的 1/39.5）的 tiny 变体仍有94.11% PCK@20（比 full 少 2.5 个点），对应约 220 KB fp32 权重，是"严重受限边缘目标"可达的规模。这直接引出了下一节的边缘部署实测。

变体设计的工程细节（压缩时踩过的坑）

model_compact.py 的参数化过程暴露了原架构里几个被硬编码的假设，压缩时必须处理：

1. TCN 分组卷积的 groups 硬编码为 20，不整除紧凑通道数（如 270、135、85）。half/quarter 用groups_mode='gcd20'（取通道数与 20 的最大公约数，通道为 540 时仍等于 20，与原版一致）；tiny 用depthwise（groups = channels）。
2. Conv2d 下采样步长：原版用 4 个 stride-(1,2) 块把 240 宽降到 15（恰好等于关键点数）。通道变窄后继续二分会 <15 行，导致AdaptiveAvgPool2d((15,1))跨关键点复制行。规则改为"宽度仍 ≥15 就减半"，tiny 因此得到 stride 序列[2,1,1,1]、最终宽度 16。
3. tiny 的逐点卷积分组：TCN 第 1 块里 540→c 的稠密逐点卷积加残差下采样要 2×540×c 个参数（约 117k 的底部开销，超过 tiny 的 <100k 预算），tiny 将这两个卷积分组（groups=4）。

run_sweep.py --dry-run可以先只打印各变体的参数数与输出形状，验证配置后再挂后台跑：nohup venv/bin/python sweep/run_sweep.py > sweep/sweep.log 2>&1 &（已完成的变体写入 results.jsonl，幂等跳过）。

边缘部署实测：ONNX、fp16 与 int8 的真相

对重训出的 full checkpoint（2,225,042 fp32 参数）在 Windows 11 机器（torch 2.12.0+cpu、onnxruntime 1.26.0、16 torch 线程）上做了完整边缘基准。精度口径统一为：seed-42 文件级 70/15/15 测试分割中剔除损坏窗口后的10,000 窗口随机子集（fp32 子集 PCK@20 96.68% 与全量 96.61% 一致，证明子集有代表性）；延迟为 3 次交错重复的中位数（该机器 batch 1 的 run-to-run 波动约 ±20–40%）。脚本：quantize_bench.py、onnx_bench.py、eval_ort_accuracy.py、static_ptq_bench.py，原始数据在 results/edge_optimization.json。

full 模型：torch vs ONNX vs int8

陷阱一：PyTorch 动态量化在这个模型上"什么都不转"

审计量化时撞上一个教科书级陷阱：该模型有 0 个nn.Linear层，全部是 Conv1d（21 个）+ Conv2d（22 个）+ BatchNorm。torch.ao.quantization.quantize_dynamic（请求覆盖{Linear, Conv1d, Conv2d}）实际转换了0 个模块 / 0.0% 参数——动态量化只有 Linear/RNN 族的 kernel，对卷积静默跳过。所谓"int8"模型与 fp32 逐位相同，9.07 MB 原封不动。这正是 quantize_bench.py 中quantize_int8_dynamic要生成详细报告的原因：不是凭感觉，而是逐模块统计params_quantized_fraction。

陷阱二：fp16 只省空间，在 CPU 上反而更慢

fp16 序列化后体积减半（4.58 MB）且精度几乎无损（PCK@20 −0.005 pt），但 CPU batch 1 延迟反而慢约 2.2×（24.3 vs 11.0 ms）——torch CPU 的 fp16 卷积 kernel 是模拟的。fp16 在这里是存储/传输格式，不是 CPU 运行时优化。

真正的胜利：ONNX Runtime

ONNX fp32 是 batch 1 延迟的真正赢家：3.2 vs 11.0 ms/window，约 3.4× 快于 torch，精度完全一致（与 torch 的 parity 最大绝对差 2.4e-7，远小于 1e-4 阈值）。导出用 TorchScript 导出器（dynamo=False）、opset 17、动态 batch 轴，产物 results/retrained_fp32_dynamic.onnx（8.97 MB），已验证在 batch 1/2/64 均可运行（轴向注意力的view(N*W, C, H)reshape 被正确追踪为图操作而非烘死的常量）。dynamo 导出器也能捕获图，但在 cp1252 控制台写 ✅ 时崩溃（纯 Windows 编码外观问题，非模型阻塞）。

论文 "~2.2 MB int8" 声称的判定

"2,225,042 参数 × 1 字节 ≈ 2.2 MB" 的前提是每个参数都能量化。实测：PyTorch 动态量化 = 9.07 MB（0% 量化，无 Linear 层）；ONNX Runtime 动态量化（有 int8 卷积权重支持）=2.44 MB，接近声称，代价是 PCK@20 96.68→96.52%（−0.16 pt）、MPJPE +18%，且推理比 ONNX fp32 慢约 2×（ConvInteger kernel）。结论："2.2 MB"是权重算术估计，实际只能靠支持卷积的量化工具体系达到，且有小幅精度损失。

静态 PTQ（带校准）：int8 的精度甜点

后续用 ONNX Runtime静态量化（quantize_static，QDQ 格式，逐通道 int8 权重 + int8 激活）做了跟进，校准只用无损坏的训练分割窗口（1,000 个 MinMax / 512 个直方图校准器，绝不碰测试窗口），作用域分 "conv-only"（op_types_to_quantize=["Conv"]）与 "all-ops"（额外量化 Mul/Sigmoid/Add/AveragePool 胶水）：

结论：

• conv-only 是正确作用域：三种校准都落在 PCK@20 96.60–96.63%（优于动态的 96.52%，追回约 2/3 差距），MPJPE 0.0103–0.0108；all-ops 严格更差——最多 −1.4 pt PCK@20、+60% MPJPE，却没有任何体积/延迟收益，int8 激活流经 attention 块的逐元素胶水就是损伤源头；
• 体积反而略增（2.53 vs 2.44 MB，+3.6%）：QDQ 节点与逐通道 scale 有开销，且 12 个 BatchNorm 都跟在 Slice/Einsum/Reshape 后面、从不跟 Conv，无法折叠，只能保持 fp32；
• 延迟与动态持平，仍是 ONNX fp32 的约 2 倍——int8 解决不了该模型的延迟问题；
• 记录一个负结果：Entropy 校准在此模型上是 no-op（在相同校准集上选出的阈值与 MinMax 逐位相同，247 个 scale 全等）；另 ORT 1.26 的CalibMaxIntermediateOutputs在 batch 数整除 chunk 大小时会误报 "No data is collected"，脚本已绕过。

部署建议（full 模型）：要速度 → ONNX fp32（3.2 ms b1）；要 int8 体积 → 静态 QDQ conv-only（Percentile 或 MinMax，产物 results/retrained_int8_static_percentile_conv.onnx），精度严格支配动态 int8，延迟近似、体积仅多 0.09 MB。

tiny 变体的边缘产物：30× 更小、3.4× 更快

把同一套边缘流水线套到 tiny checkpoint（56,290 参数）上（tiny 版脚本 tiny_edge_bench.py；静态 QDQ Percentile conv-only 用 512 个无损坏训练窗口校准；精度仍在同一 10k 窗口测试子集上；torch-vs-ORT parity 最大绝对差 1.5e-7）：

两个被迫偏差（都记录在 JSON 里）：

1. 自适应池导出改写：tiny 的 stride 序列[2,1,1,1]使特征宽度停在 16，TorchScript 导出器拒绝AdaptiveAvgPool2d((15,1))（15 不整除输入高；full 模型宽度恰为 15，从未触发）。由于定尺寸 map 上的池化是固定线性算子，导出包装把它替换为mean(-1)（W 轴）+ 一个常量平均 matmul（用 PyTorch 的精确 bin 规则），parity 校验证明了与真实池化逐位等价。
2. 校准数必须 512：ORT 1.26 的直方图收集器会对逐 batch 最大值做np.asarray()，校准数必须是 64 窗口校准 batch 的倍数，否则残差末 batch 会崩溃。

关键结论：

• 最小可部署的 WiFlow 级模型 = tiny ONNX fp32：约 295 KB、batch 1 单窗口 CPU 0.66 ms（约 1,500 窗口/秒）、94.1% PCK@20——比 full ONNX fp32 小 30×、快约 3.4×，代价仅 −2.6 pt PCK@20；
• int8 在这个规模上是坏交易：静态 QDQ conv-only 只省 47 KB（−16%），却要付 −1.43 pt PCK@20（94.11→92.68%）和 +19% MPJPE，且比 tiny fp32 更慢（QDQ kernel 开销在小卷积上占比过高）——56k 参数模型几乎没有冗余可吸收权重+激活取整误差；
• 部署建议（紧凑版）：tiny 直接发 ONNX fp32——295 KB 下 int8 省下的体积解决不了任何真实约束，反而损失精度与速度；若未来确实需要 250 KB vs 295 KB 的差异，下一步该试的是 weight-only 量化，而非 QDQ。

审计方法论的四条 takeaways

1. 跑 artifact，别读 README。论文里的每个数字都离"被证实或被打脸"只有一次git clone的距离——两种结局都有价值，但只有一种能被原作者发表。本次审计证明了"artifact rot（打包腐烂）≠ bad science（坏科学）"，而这个区分不真跑代码就永远无法建立。
2. fp16 + 未校验数据 = 静默模型死亡。混合精度训练没有 NaN/inf 防护时不会大声失败——它悄悄腐蚀 BatchNorm 缓冲区，然后带着绿色进度条交付一个坏模型。对策三选一：校验输入、纯 fp32 训练、或给 autocast 加防护。
3. 给自己的声称也上证据等级。审计中途，同一套取证工具抓到了 RuView 自己一个已发布精度数字的软肋：它建立在一个退化的评测上（一个恒定输出的模型配上残缺的指标打分）。当天即撤回。规则必须双向生效，否则就是营销而不是测量。这正是 benchmarks/wiflow-std/RESULTS.md 中 Measurement (b) 所做的：旧 "92.9% PCK@20" 声称经取证（trainer 用了绝对 0.2 图像单位阈值而非 torso 归一化、模型输出恒定姿态——pred std 0.0000、均值预测器在该协议下能得 100%）被正式撤回，torso 归一化后同 holdout 只有 19.1%。
4. 过参数化藏在 SOTA 表格里。没有人会发布"砍一半还更好"的消融。自己跑一遍：一小时 GPU 时间，而且有时候答案就是它。

延伸：跨域微调的诚实边界（Measurement b）

审计并未止步于复现——还尝试把 WiFlow-STD 微调到 RuView 自己的 ESP32 采集数据（2,046 个配对窗口、单受试者、单房间、单节点，17 个 COCO 关键点，时间分割 70/15/15），结果同样有方法论价值（详见 RESULTS.md 的 Measurement (b) 与 remote/measb/）：

关键解读：没有任何运行超过均值姿态基线（单受试者单画面在归一化坐标下几乎不动，恒定均值姿态就能拿 95.9%）；预训练收益是优化转移而非特征转移（冻结主干的线性子载波 adapter 几乎不工作，说明 WiFlow-STD 的特征不可迁移到 ESP32 域）；且 2k 窗口的域内数字与 36 万窗口的 ~96% 不可比，与发布声称的 97.25% 更不可比。这条"诚实底线"（mean-pose baseline）正是上一条 takeaway 的落地——在模型击败均值基线之前，这条线上的任何 PCK 数字都不得被引用为姿态估计能力。

如何在自己机器上复跑整套审计

仓库提供了从零到结论的完整链路（运行前提：约 15 GB 磁盘、一块 GPU 用于重训、Windows 或 Linux 均可跑边缘基准）：

1. 环境与上游：remote/setup_and_train.sh 完成 clone 上游（固定 commit）、一行修复 import 缺陷、建 venv（RTX 5080 需 torch cu128）、kagglehub拉数据集、软链preprocessed_csi_data、按上游默认参数重训。
2. 清洗数据：remote/clean_v2.py 原地清零 9,072 个损坏窗口（mmap 读写、分块 4,000 窗口）；注意此操作不可逆，掩码证据请先保留。
3. 再生损坏掩码：generate_corruption_masks.py 必须指向未清洗的原始下载，全 False 结果会被拒绝写入。
4. 复现评测：eval_repro.py --data-dir <含 csi_windows.npy 的目录>跑发布 checkpoint 与重训 checkpoint 的 PCK/MPJPE，结果写入 results/repro_a.json。
5. 效率扫描：venv/bin/python sweep/run_sweep.py --dry-run先看参数数，再nohup ... &后台跑，结果追加进results.jsonl。
6. 边缘基准：quantize_bench.py（torch fp32/fp16/int8 的大小+延迟+精度）、onnx_bench.py（导出+parity+延迟+ORT 动态 int8）、eval_ort_accuracy.py（ORT 精度）、static_ptq_bench.py（带校准的静态 PTQ）、tiny_edge_bench.py（tiny 变体同套流水线），全部合并写入 results/edge_optimization.json。

所有共享工具（上游 import 垫片、>1GB npy 的 mmap 补丁、旧 checkpoint 键重映射、规范评测循环）都收敛在 _bench_common.py 单文件中，remote/ 下的部署脚本内联了副本，编辑时以它为准保持同步。审计结论的证据等级已按 ADR-152 §2.2 规则固化：WiFlow-STD 的精度声称 = MEASURED-EQUIVALENT（重训复现 ~96% PCK@20；发布 checkpoint 被证伪；数据与代码需要修复）。

【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView