简介：基于深度学习的数据级多源融合定位增强算法，是电子信息技术领域的一篇专业参考文献（PDF格式），面向从事信号处理、电子对抗、无源定位技术研究的工程师、科研人员及高校研究生。该文献针对不同定位体制的多系统协同定位能力不足问题，提出一种基于深度学习的数据级多源融合定位增强方法，通过设计的5L-CNN多源融合定位增强网络，一体化完成数据特征自主提取和融合预测，实现对两种以上不同定位体制的多源定位数据进行融合增强，提升目标定位精度。文档共1个PDF文件，压缩包大小882KB，为期刊论文原文格式，除摘要与关键词外，还包含引言中对现有定位体制局限性的分析、基于卷积神经网络的融合定位模型构建过程、以及仿真实验验证等内容。已有417人在CSDN学习下载，适合需要了解深度学习在多源融合定位方向应用现状、借鉴网络结构设计与实验思路的读者阅读参考。

1. 数据级多源融合定位增强：先把原始观测拼起来，再谈精度

做多源融合定位的人经常会纠结一个问题：是先把每个传感器各自算成位置再融合，还是把原始观测丢进同一个模型里一起学。我的建议是，先认真看数据级方案。所谓基于深度学习的数据级多源融合定位增强算法，核心就是在数据层把不同传感器的原始测量——IMU 的加速度和角速度、GNSS 的伪距和载噪比、WiFi 或 BLE 的 RSSI——先做时间和坐标对齐，再交给深度学习模型端到端地学习跨源特征，最终输出对现有定位结果的修正量。它比特征级融合省掉了大量手工特征设计，又比决策级融合保留了更多底层信息，特别适合 GNSS 信号不稳定、WiFi 指纹漂移、IMU 积分发散的室内外过渡场景。正在做定位项目、准备复现论文算法、或者被多传感器融合精度卡住的工程师，都值得把这个方向作为优先选项。

2. 数据级融合定位增强的核心逻辑：为什么深度学习比经典滤波更适合做修正

2.1 融合层级对比：数据级、特征级、决策级差在哪里

多源融合定位按照融合发生的层次，通常可以分成数据级、特征级和决策级三档。这个分层不只是一个学术术语，它直接决定你要花多少精力做前置处理，也决定最终的精度上限和工程复杂度。我把它整理成一张对比表，方便直接对照选型。

数据级的优势来自“少丢信息”。决策级融合到手的是每个源已经解算出的位置坐标，前端一个坐标解算错了，后续再融合也拉不回来。特征级融合稍微好一点，但设计什么特征、怎么把不同源的抽象特征对齐，又回到了手工活。数据级融合直接把传感器原始观测喂进去，让模型自己决定哪些信号分量可用、哪些分量是噪声，这正好契合深度学习的强项。

不过数据级也有代价：它对时间同步和坐标对齐的敏感度是最高的。GNSS 1 Hz 更新、IMU 100 Hz 更新、WiFi 可能几秒才扫描一次，如果不做对齐就把这些序列拼成一个矩阵，模型看到的是一堆错位的“假模式”。所以选数据级融合，先要有心理准备：前置工程占整个项目一半以上的工作量。

2.2 深度学习在这个位置上的不可替代性：时序特征与误差模型

传统多源融合定位的基石是卡尔曼滤波一族，包括扩展卡尔曼滤波、无迹卡尔曼滤波。卡尔曼的思路是：先写出状态转移方程和观测方程，然后在线性高斯假设下递推最优估计。这个思路在开阔道路、无人机飞行等场景很成熟，因为运动模型和卫星观测模型都写得很准。可一旦进到室内外过渡区域，模型就绷不住了。

实际问题在于，WiFi RSSI 会被人体遮挡，BLE 信号在金属货架旁剧烈震荡，GNSS 在多径环境下出现几十米的伪距跳变，IMU 的零漂又和环境温度、运动状态耦合。四个源各自的误差模型都在变，而且变化的方式很难用一个固定公式描述。这时候硬编观测方程，最后的融合结果可比单一源好不了多少。

深度学习在这里解决的不是“滤掉噪声”，而是“从多源信号中学会误差模式”。把一段窗口内的多通道观测看成一个时序序列，它内部既包含运动信息，也包含环境对信号造成的失真信息。比如你走进一个 WiFi 信号被货架遮挡的区域，RSSI 会同步下降，同时 IMU 检测到转弯，这两个事件在时间上强相关。深度学习模型可以学到这种跨模态的联合模式，而不是把每个源当成独立观测来加权。

我一般会把这个问题和常见的深度学习时序预测任务放在一起理解：本质上都是用历史窗口预测未来一个量。只不过这里预测的不是股票或天气，而是“当前位置相对于参考定位解的偏差”。这也是为什么 LSTM、Transformer、时序卷积这类结构在这个任务里远比普通全连接网络好用。全连接网络只能看到当前时刻的拼接向量，看不到转弯前 2 秒的加速度变化，而这些历史信息恰恰是修正定位的关键。

2.3 为什么输出修正量而不是直接输出坐标

数据级融合增强算法里，网络输出层设计有一个容易被新手忽略的决策：到底让模型直接输出最终坐标，还是输出一个修正量。我的答案很明确：大多数场景选修正量，不要直接回归坐标。

直接回归坐标意味着模型要同时学会两件事：第一，学会从多源信号中逆推绝对位置；第二，学会处理不同环境下的坐标尺度和参考系差异。这两个目标混在一起，模型容量被白白浪费在坐标系的绝对值上。而且定位坐标的范围很大，一栋楼可能有上万平米的区域，目标空间过大时，回归任务收敛速度明显变慢，梯度也更不稳定。

修正量方案把问题拆成了两个步骤。先用传统方式得到一个基础定位解，比如 GNSS 单点定位结果、惯导递推结果，或者一个简单的加权融合解；然后让深度学习模型只学习“基础解和真值之间的偏差”。这个偏差的空间范围小，量级相对稳定，适合回归任务。输出层只需要 2 到 3 个维度，分别是水平方向和垂直方向的修正值。这个思路和深度学习计算位姿并微调的做法有相似之处：先给一个合理的先验，再用网络去学习残差，而不是从头预测绝对数值。

实际使用中，修正量方案还有一个额外好处：更容易做增量集成。你已经在跑的定位系统不需要大改，只需要把原始定位解作为输入之一，再把模型输出叠加到结果上。如果模型效果不好，可以直接关掉增强功能，原系统不受影响。这一点在工程落地上的价值，很多时候比精度本身更重要。

3. 做数据级融合定位的前置工程：时间同步、坐标系对齐与训练数据构造

3.1 时间同步：用对齐窗口解决传感器时间戳不一致

数据级融合的第一个硬门槛，是让所有传感器的观测对齐到同一时间轴上。听起来简单，做起来非常容易出现系统性偏差。一个典型的翻车场景：WiFi 扫描结果的时间戳，在 Android 系统里往往是“开始扫描的时间”，而不是“收到结果的时间”，一次 WiFi 扫描要几百毫秒；IMU 数据是硬件中断带出来的高精度时间戳；GNSS 的伪距观测则是按秒脉冲对齐的 GPS 时间。三类时间戳各说各话，直接把原始数据按“时间戳相同”拼接，等于把不同时刻的观测当成同一时刻来用。

我常用的做法是做一个同步缓冲区：以基准源的时间戳为起点，开一个固定长度的窗口，每个源在窗口内做线性插值，把各自不规则的采样点重新映射到统一的采样网格上。这个统一网格的采样频率按最快源来决定，比如 IMU 100 Hz，那就把 WiFi 和 GNSS 都插值到 100 Hz 网格。这样做会丢失一部分高频信息吗？不会，因为 WiFi 和 GNSS 本身的带宽就低，插值不会制造出真实的高频变化，只是补了一个合理的中间值。

import numpy as np def build_sync_batch(sources: dict, window_s: float, start_t: float, max_gap_s: dict): """把多源观测根据时间戳对齐到统一网格。 sources: {"imu": {"ts": ndarray, "values": ndarray}, "wifi": {...}} window_s: 对齐窗口长度，秒 start_t: 窗口起始时间，秒 max_gap_s: 每个源允许的最大时间容忍度，单位秒 """ window_end = start_t + window_s target_ts = np.arange(start_t, window_end, 0.01) # 100 Hz 网格 aligned = {} for src_name, data in sources.items(): ts = data["ts"] values = data["values"] tol = max_gap_s.get(src_name, 0.05) # 只保留窗口附近且与基准时间偏差在容忍度内的样本 mask = (ts >= start_t - tol) & (ts < window_end + tol) pts = values[mask] pts_ts = ts[mask] # 线性插值到统一网格 interp_values = np.interp(target_ts, pts_ts, pts, left=np.nan, right=np.nan) aligned[src_name] = interp_values return target_ts, aligned

这段代码的逻辑说明：先定一个 100 Hz 的目标时间网格，然后对每个源都做一次线性插值。max_gap_s用来控制每个源的时间容忍度，不能对所有源用一个值。IMU 的容忍度可以给 0.01 秒，GNSS 给 0.05 秒，WiFi 这种慢源反而要给到 2 到 3 秒，否则窗口稍微偏移一点，WiFi 就整段没有数据。插值后如果出现NaN，说明这个源在窗口内根本没有有效样本，一般有两种处理：直接丢弃该窗口，或者用上一条有效值前向填充。我的经验是前向填充对训练稳定性更好，能保留更多样本，但要避免在源长时间失效时硬填。

3.2 坐标系对齐：把IMU载体坐标统一到导航坐标系

时间对齐只是第一步，坐标对齐才是真正容易被忽略的坑。GNSS 给出的经纬高是地理坐标系，WiFi 和 BLE 定位结果通常是局部的平面坐标，而 IMU 输出的加速度和角速度是载体坐标系。载体坐标系的定义是：x 轴朝前，y 轴朝右，z 轴朝下。如果你把手机朝侧面放着走路，载体坐标系的 x 轴其实是水平方向的，直接拿来当导航坐标系的 x 轴，模型学到的“前进”含义就会混乱。

我一般会把所有非地理坐标的源统一转换到一个导航坐标系，比如东北天坐标系。对 IMU 来说，需要先把加速度从载体坐标系旋转到导航坐标系，再减去重力分量。这一步用四元数或者旋转矩阵都能做，关键是方向余弦矩阵要从姿态解算结果里来，不能自己拍脑袋写死。

import numpy as np def rotate_to_navigation_and_remove_gravity(acc_body, quat): """把 IMU 加速度从载体系转到导航系，并去掉重力分量。 quat: 四元数 [w, x, y, z]，表示载体系到导航系的旋转 acc_body: 载体坐标系下的三维加速度，单位 m/s^2 """ w, x, y, z = quat # 四元数转旋转矩阵，R 表示载体系到导航系 R = np.array([ [1 - 2*(y*y + z*z), 2*(x*y - z*w), 2*(x*z + y*w)], [2*(x*y + z*w), 1 - 2*(x*x + z*z), 2*(y*z - x*w)], [2*(x*z - y*w), 2*(y*z + x*w), 1 - 2*(x*x + y*y)] ]) acc_nav = R @ acc_body acc_nav = acc_nav - np.array([0.0, 0.0, 9.81]) # 去掉重力 return acc_nav

这段代码的逻辑不复杂：旋转矩阵负责把“前右下”的坐标系翻到“东北天”，然后减去 z 方向的重力。需要特别强调的是，旋转这步不能省。如果只减重力不旋转，会导致一个问题：手机倾斜的时候，载体系 z 轴上的测量值里既有重力分量又有真实运动分量，减掉 9.81 之后剩下的量既不是垂直运动也没有水平方向意义。模型拿到这样的输入，等于被喂了一种随姿态变化的混合信号，结果就是模型对姿态敏感、对真实运动不敏感。

需要提醒的是，姿态四元数本身的精度直接影响对齐效果。如果只是在桌面静止采集，姿态基本没有参考价值；但如果是手持行走采集，我一般建议先用互补滤波或者视觉惯性方法先解算一次姿态，把每一帧的旋转结果保存下来，作为训练数据的原始记录，而不是在训练时再实时解算。

3.3 训练数据怎么造：真值标注、半仿真拼接与数据增强

数据级融合定位增强算法需要的数据量，看起来很大，但实际训练一个可用的修正模型，往往不需要百万级样本。关键是数据里的真实性和多样性。我见过不少项目，模型的参数量很小，训练集也才几万条，但精度表现很好，因为每一条数据的同步和标注都做得非常干净。数据的干净程度，比数据的规模更重要。

数据来源一般有三条路。第一条是真实采集加真值标注：人带着设备走，用激光 SLAM 或者高精度地图给出每一时刻的真值坐标。优点是最接近上线环境，缺点是采集成本高，一个楼层要来回走好几趟。第二条是纯仿真：用 GNSS 仿真器生成伪距和载噪比，用信道模型生成 WiFi 和 BLE 的 RSSI 序列。优点是可以批量生成各种场景，缺点是仿真和现实的差距有时会让模型上线后性能打折。第三条是半仿真拼接，也是我在这类项目里最推荐的做法：WiFi 和 BLE 用真实采集的信号源，GNSS 用仿真器或者离线回放数据，IMU 用真实录制的加速度序列，然后按时间轴拼接起来。

拼接时要注意，所有源的数据在进入模型前，都必须完成前面说的时间同步和坐标对齐。在这个阶段，可以顺手做一些数据增强。我用得比较多的是三种：时间偏移增强、旋转扰动增强、通道随机丢失增强。时间偏移增强是把窗口起点随机前移或后移 0.2 到 0.5 秒，让模型对时间同步误差更稳健；旋转扰动增强是把 IMU 输入随机旋转一个小角度，模拟不同的手持姿态；通道随机丢失增强是让模型适应某个信号源暂时失效的情况，避免过度依赖某一个源。

训练集构造最后一步是确定标签。标签是“真值坐标减去基准定位解”，也就是修正量。基准定位解必须和实际部署时使用的基础定位算法一致。如果训练时用的基准解来自高精度组合导航，上线时却用单点 GNSS 做基准，标签分布会完全不一样，模型输出自然不可用。这条一致性要求，建议直接写进项目文档，避免后来接手的人踩坑。

4. 用深度学习时序模型落地数据级融合增强：网络设计、输入组织与训练参数

4.1 网络骨架选型：一维卷积加双向LSTM的时序建模

数据级融合定位增强的输入是多通道时序数据，输出是位置修正量。解决这类问题的网络骨架有很多选择，但我的默认选择是“一维卷积加双向 LSTM”。这个组合不是最时髦的，却是这类任务里稳定性和性价比最好的方案之一。Transformer 能学长距离依赖，但训练需要更多数据；纯 LSTM 能建模时序，但对高频局部特征不够敏感；一维卷积用来提取局部信号模式，双向 LSTM 用来捕捉时间上下文，正好互补。

import torch import torch.nn as nn class DataLevelFusionNet(nn.Module): def __init__(self, in_channels=8, hidden_size=64, out_dim=3): super().__init__() # 局部特征提取：两路一维卷积 self.conv = nn.Sequential( nn.Conv1d(in_channels, 32, kernel_size=5, padding=2), nn.ReLU(), nn.Conv1d(32, 64, kernel_size=3, padding=1), nn.ReLU(), ) # 时序建模：双向 LSTM self.lstm = nn.LSTM( input_size=64, hidden_size=hidden_size, batch_first=True, bidirectional=True, ) # 回归头：输出位置修正量 self.head = nn.Sequential( nn.Linear(hidden_size * 2, 32), nn.ReLU(), nn.Linear(32, out_dim), ) def forward(self, x): # x: (B, C, L) B 批次，C 通道，L 窗口长度 x = self.conv(x) # (B, 64, L) x = x.transpose(1, 2) # (B, L, 64) out, _ = self.lstm(x) # (B, L, 128) out = out[:, -1, :] # 取最后时间步 return self.head(out)

这段网络定义里的关键参数：in_channels=8表示输入通道数，可以按实际传感器源数量调整，比如 IMU 6 轴加 GNSS 载噪比加 WiFi RSSI，就是 8 通道；hidden_size=64控制 LSTM 的隐层维度，太小学不到时序模式，太大容易过拟合；out_dim=3对应位置修正量的三个分量，如果只做水平面修正，可以改成 2。双向 LSTM 会输出两倍于隐藏层大小的特征，所以全连接头第一层输入维度是hidden_size * 2。

只取最后时间步的输出，适合“用整段窗口信息回归一个修正量”这种设定。如果你希望每一帧都有修正输出，可以改成对每个时间步都做回归，但那样训练难度会高不少，一般不需要在一开始就做。

4.2 输入张量组织与归一化：批次、窗口与通道怎么排

网络定义好了，接下来要解决数据怎么进网络的问题。我见过不少人在这一步把通道维和时间维搞反，导致模型训练一直不收敛。这个任务的输入张量形状一般定义为(B, C, L)，B是批次大小，C是信号通道数，L是窗口长度。一维卷积默认在最后一维上滑动，所以时间和通道的位置不能随便换。

import numpy as np import torch def prepare_input(buffer: dict, feature_conf: dict, window_len: int): """把同步对齐后的多源数据组装成模型输入。 buffer: 已经插值到统一时间网格的各源数据 feature_conf: 特征顺序配置，决定通道排列 window_len: 窗口长度，对应序列长度 L """ cols = [] for name in feature_conf: series = buffer[name] cols.append(series[-window_len:]) # 只取最近一个窗口 x = np.stack(cols, axis=0) # (C, L) x = normalize_per_channel(x) return torch.from_numpy(x).float().unsqueeze(0) # (1, C, L)

feature_conf的作用是固定通道顺序。比如规定["acc_x", "acc_y", "acc_z", "gyro_x", "gyro_y", "gyro_z", "carrier_noise", "rssi"]，训练和推理时必须用同一份配置，否则换一台手机或者改一个固件版本，通道顺序变了，模型表现会完全崩掉。这种做法看似愚钝，但能避免太多因为配置漂移导致的诡异问题。

normalize_per_channel这一步也很关键。不同通道的物理单位差别很大：加速度是每秒平方米，RSSI 是负的 dBm 值，载噪比是 20 到 50 dB。如果不归一化，数值范围大的通道会在梯度中占据绝对主导，数值小的通道几乎学不到东西。我一般用滑动窗口内的均值方差归一化，而不是全局归一化。全局统计在跨楼层、跨环境中会失效，滑动统计更贴近在线部署时的行为。

4.3 损失函数与训练配置：SmoothL1、分段加权与早停

损失函数的选取在这类任务里直接决定训练能否收敛。位置回归任务最常用的损失是均方误差，也就是 MSE。刚跑这个方向时我也用 MSE，后来发现它有几个问题：一是对异常标签过度敏感，一个几十米的 GNSS 跳点样本，会让整批梯度被拉偏；二是 MSE 对标签分布内部的微小偏差也有很高的惩罚，导致模型为了迎合极端样本而牺牲大部分正常样本的精度。

criterion = nn.SmoothL1Loss(beta=1.0) # forward 过程中计算 loss pred = model(batch_x) loss = criterion(pred, batch_y.delta)

SmoothL1Loss在误差绝对值小于beta时按二次函数惩罚，大于beta时按一次函数惩罚。这个特性让它对异常点不那么敏感，同时在正常样本范围内保持精确收敛。beta一般取 0.5 到 1.0，单位是米。如果标签里混合了不同噪声等级的样本，建议再加一个分段加权：把修正量较小的样本权重调低，修正量较大的样本权重调高，避免模型对室内慢速行走这种“几乎不动”的样本过拟合。

训练参数方面，我常用的配置可以作为一个起点：优化器用 Adam 或 AdamW，学习率 1e-3，batch size 64，窗口长度 128，训练 50 到 80 个 epoch，配合 early stopping。early stopping 的 patience 设 7 到 10 个 epoch，监控验证集的 CEP50 指标，而不是只盯着 loss。定位任务里经常出现 loss 还在下降、但定位误差已经不再改善的情况，只看 loss 容易多训练很多轮还学不到收益。

4.4 训练环境：从miniconda到PyTorch的实用配置

落地说到底要先把环境跑通。这类定位网络参数量不大，一个几百万参数的模型在 CPU 上也能训练，但速度会让人失去耐心。我的习惯是用 miniconda 建一个独立环境，先把 CPU 版本跑通，再切换 GPU 版本。这样做的好处是环境隔离，避免多个项目之间互相污染依赖。

conda create -n fusion python=3.10 conda activate fusion conda install pytorch torchvision cpuonly -c pytorch

上面这条命令适合先验证代码逻辑，不需要 CUDA。等数据准备到位、网络确认能跑通，再根据本机显卡驱动版本重装 GPU 版 PyTorch。最后安装 numpy、pandas、scikit-learn 这些常用依赖就够了。有个小提醒：不要在训练环境里直接安装定位 SDK 的全量依赖，有些 SDK 依赖的旧版本库会覆盖 PyTorch 的 numpy 环境，导致张量操作变慢甚至报错，这类问题排查起来非常消耗精力。

5. 数据级多源融合定位增强的避坑笔记：五个最容易翻车的工程细节

5.1 时间戳来源不一致，模型“好像在学但精度不降”

现象：训练 loss 一直在下降，但验证集上的定位误差没有明显改善，曲线像一条钝化的直线。我做第一版时遇到这种情况，第一反应是换网络结构，后来发现是时间同步的问题。

原因：WiFi 扫描结果和 IMU 数据用的不是同一套时间源。WiFi 的扫描时间戳来自应用层，IMU 来自硬件，GNSS 来自卫星时钟，三个时间源之间没有绝对对齐。模型内部其实是在学习一个“错位模式”，它确实学到了某些规律，但这个规律和真实位置修正无关。

解决：回到数据预处理阶段，重新核对每个源的时间戳定义。把 WiFi 数据的时间戳修正为扫描完成时间，把 GNSS 按 utc 时间统一成纳秒级整数，再把所有源的数据通过同步缓冲区插值到统一网格。改完时间同步后，同样的网络结构，验证集误差立刻开始下降。此后我把“时间戳来源检查”写进每次数据处理的 checklist，第一行就写它。

5.2 IMU坐标系没做姿态补偿，高动态场景越跑越偏

现象：模型在平缓直道上表现很好，但一碰到转弯或者手机从口袋拿出来的动作，输出误差突然变大，而且大得没有规律，有的位置偏左，有的位置偏右。

原因：输入到模型的加速度一直是载体坐标系的数据。手机横握时，载体坐标系的 x 轴其实朝左，和导航坐标系完全对不上。模型看到转弯动作时，会同时看到一组和真实运动方向不一致的加速度分量，自然学不出稳定的映射关系。

解决：在数据预处理阶段加入姿态补偿，把加速度从载体坐标系旋转到导航坐标系再输入模型。旋转矩阵来自姿态解算结果，通常用互补滤波或者卡尔曼滤波解算姿态。这个问题解决后，高动态场景下的误差明显回落，模型对握持方式的敏感性也降下来了。

5.3 修正量输出全零：标签噪声淹没了真实信号

现象：模型训练完成后，把预测的修正量打印出来，发现几乎全部接近 0。位置输出退化成“完全信任基准定位解”，增强算法形同虚设。

原因：标签是“真值坐标减去基准定位解”。如果基准解本身已经从某种滤波里得到，它的误差分布本身就比较小，而真值坐标的标注误差可能有 1 到 2 米，两者叠加后，标签的信噪比极低。回归任务在这种情况下会学到一个粗暴的规律：输出 0，损失就是标签的均值方差，比强行预测一个噪声更低。这是回归模型在低信噪比下最典型的行为。

解决：对训练样本做标签置信度筛选。具体做法是：只保留基准定位解与真值距离在一定阈值范围内的样本，或者按标签的绝对值给样本权重。另一个有效手段是换一个更强的基准解做标签，比如用激光 SLAM 的轨迹结果作为标签来源。把标签噪声压下来之后，模型才真正开始学到有意义的修正规律。

5.4 MSE损失被爆点主导，定位精度越想越差

现象：训练过程中偶尔出现 loss 突然升高一大截，然后又降回去，最终训练出来的模型在平稳场景下精度尚可，但一旦有 GNSS 跳点或者信号干扰，输出变得很不稳定。

原因：GNSS 在多径环境中可能出现几十米的伪距跳变，对应的标签修正量也会变成几十米。MSE 对这样的大偏差起二次方惩罚，几个爆点样本的梯度占比超过几百个正常样本，模型为了迎合这些爆点，把正常区域的拟合质量牺牲掉了。

解决：把损失函数从 MSE 换成 SmoothL1，并且对 GNSS 伪距残差做异常截断。还可以在数据加载时过滤梯度异常大的样本，用一个经验阈值把单样本损失超过某倍数的样本直接抛弃。这个操作让训练过程稳定很多，验证集上的最大误差也明显下降。

5.5 验证集随机拆分，泛化指标虚高

现象：离线验证时精度很高，CEP50 都到了 1 米以内，但把模型部署到新环境、新楼层，精度立刻回到 3 米以上，前后相差巨大。

原因：验证集是用随机拆分的方式从所有样本里选的，同一条连续轨迹的一部分在训练集、一部分在验证集。模型在训练时已经见过这条轨迹前后相邻的采样点，验证时等于在“背题”，泛化指标自然虚高。

解决：按轨迹和楼层做分组划分，保证同一条轨迹、同一个楼层的数据全部进入同一个折，再训练和验证。用 scikit-learn 的GroupKFold可以方便地实现，只需要把每条数据的轨迹 id 传进去。改成分组划分后，验证精度下滑了一些，但上线后更贴近真实表现，这反而让人踏实。

6. 从指标到消融实验：数据级融合定位增强算法的验证习惯与上线技巧

6.1 评估指标怎么选：RMSE、CEP50/95与最大误差

定位增强算法最终要回答的问题是：精度到底提升了多少，值不值得上线。单一指标很难说清楚，我通常同时看四个指标，并记录它们的原始值和相对提升比例。

6.2 消融实验设计：把数据级融合的收益单独拆出来

要让人信服数据级融合的收益，不能只贴一个“增强前 vs 增强后”的对比。我一般会设计一组消融实验：第一组只用 IMU 数据，第二组只用 WiFi 数据，第三组用数据级融合，第四组用特征级融合，第五组用决策级加权融合。所有模型使用相同的训练数据和验证划分，这样每一种融合层级的收益都能被单独量化。跑完之后你会发现，数据级融合在 CEP50 上通常比决策级好 20% 到 40%，但优势主要体现在环境切换时，稳定环境下的差距反而小。这个结论可以直接用来和团队沟通投入产出比。

6.3 上线前的一条硬规则：保留原定位解做并联冗余

最后一条习惯来自一次血的教训：把增强模型直接替代原定位模块，结果某个出入口信号剧烈变化时，模型输出连续跳变，连后悔药都没得吃。从那以后我立了一条硬规则——增强模型永远做并联，不做串联。

具体做法是保留原有定位解的输出通路，当原定位解的置信度指标正常时，继续使用原定位解；只有当置信度低于阈值或者信号源个数不足时，才切入增强模型的输出。同时在系统里加一个简单的输入监控，统计每个通道的均值和方差，发现分布偏离训练范围就自动降低增强模型权重。这个机制不一定让精度最大化，但能保证系统在异常情况下有底牌。

这些年我养成的习惯是：不管项目多赶，先把数据级融合的同步通道搭好，再做任何花哨网络。数据没对齐之前，模型再复杂都是给噪声拟合锦上添花。在很多看似玄学的精度问题上，最后查出来的都是时间尺度和坐标尺度的低级错误。希望帮到你。

本文还有配套的精品资源，点击获取