细说深度学习训练集、验证集、测试集(为什么有的论文的数据集只有训练集和验证集而无测试集)

验证集的作用:验证集是用来让我们验证一下网络的当前训练结果,以便于我们观察模型的泛化能力,看模型是否有过拟合,以调整网络的超参数如网络架构,学习率等。注意网络的训练并没有真的用到验证集,因为验证期间没有计算梯度,没有更新参数!

我们知道,传统机器学习的根本假设是:用于训练模型的数据和用来测试模型的数据来自同一个概率分布

对于规模很大的数据集,我们可以理想一点,认为他们服从这个根本假设。既然数据集很大,那我们就可以奢侈一点,把数据集划分为术业有专攻的三块:训练集,验证集,测试集。

但是其实很多时候只分为两块,即训练集和测试集,一是因为数据量有限,二是因为测试集可以身兼两职,既可以用作验证集来验证模型的训练结果,又可以用来得到最终测试结果

分为两块的这种划分还有个专门的名字,叫做“留出法”。

训练集用来训练NN,即根据反向传播的误差对每个参数的梯度进行参数更新;

验证集专门用来看看每经过1个epoch的训练之后,NN的性能如何,即验证一下当前模型的能力,那当然要用模型从来没见过的数据,即验证集绝对不能来自训练集

(如果把训练集的一部分作为验证集,那模型当然会表现很好,因为已经见过了,并且根据这些数据还做了自我校正。就像考试出原题无法验证考生的真实学习能力一样。)

最重要的一点:验证NN性能的过程不会更新网络的参数,因为验证时停止了梯度的反向传播!这一点一看代码就知道了。

所以!验证就是测试,测试就是验证,使用的是同样的代码,只是由于目的不同而有了不同的名字

所以!如果你的任务中数据集比较小的话,完全可以拿测试数据作为验证数据,而不必非要分为三部分,害的每一部分的size都很捉襟见肘,搞得训练集太小不够训练,测试集太小使得测试精度不那么可信,很尴尬。

这也是为什么很多论文中给出的训练过程图中给的是训练精度(train_accuracy)和测试精度(test_accuracy)的变化,而非训练精度和验证精度(validation_accuracy)。比如:

如果验证集就是测试数据的话,那么test_accuracy曲线的最后一个值就是最终的测试精度啦。

测试集就是最终要测试的数据了,是要得到一个结果,比如精度或者误差。

既然测试集可以用作验证集,那为啥还要分成三个集呢?
这太简单了,因为测试数据会变化啊。训练好一个模型后,之后可能会把他用到新的测试数据上,但是之前训练过程中用了当时任务的测试数据做验证集。

有必要说一说交叉验证,因为我之前把交叉验证和验证集搞混。

上面的留出法多做几次,把结果取平均就是交叉验证了。

交叉验证是针对数据集太小的情况,想要充分榨干这个小数据集的光和热,数据集够大就不需要折腾这个了。直接举个例子说明:

如果一个数据集有100条数据,按照8:2分为训练集和测试集(直接用测试集作为验证集),则应该用训练集的80条数据训练模型,用测试集的20条数据来测试训练的效果如何。

显然,这个模型只见到了80条数据,而有20条没见过,如果这俩数字是80000和20000,那我们觉得这个模型是可信的,毕竟8万条数据含有的多样性大概率已经包含了这2万条所含的多样性,所以无需钻研交叉验证。

但是80和20这两个数字,样本量太吝啬,我们会觉得这80条数据很可能没有包含着20条所能展示的多样性(信息),所以用这80条数据训练的模型的效果也就不那么可信了,因为这个模型没见过这20条数据的模式,所以识别效果也许也不好,即过拟合。

如果不考虑扩充数据集,那就只能充分利用这个小数据集。于是就有了交叉验证:我们再重新划分4次训练集和测试集,每次拿不同的80条作为训练集,另外20条作为测试集;最后把五次实验结果一平均,就是5折交叉验证。

注意在实现中,5次实验的5个测试集,不是说必须完全不同(第一次以编号为0-19的作为测试集,第二次20-39,第三次40-59,第四次60-79...),当然,这样做才严格符合交叉验证的定义,这样最好。

但是为了实现方便,一般是用随机法来近似。即:随机选择20条作为测试集,剩下的就是训练集了,5折就选5次,10折就选10次。


总之,训练集是用来通过梯度反向传播更新参数的,而验证集和测试集不会通过梯度反向传播更新参数,所以测试集和验证集完全可以是同一个数据集,而他俩都不可以和训练集有交叠,即必须互斥。

<think>好的,用户遇到了旁路由设置的问题,导致丢包严重无法上网。我需要仔细分析可能的原因解决方法。首先,用户的主机IP是192.168.47.13,旁路由的地址是192.168.47.9,设置旁路由作为网关后出现丢包。常见的可能原因包括防火墙设置、路由配置错误、网关或DNS问题,以及硬件问题。 首先,我应该考虑旁路由的防火墙是否阻止了流量。用户可能需要检查OpenWrt的防火墙区域设置,确保LAN区域的入站、出站转发都允许。另外,NAT规则是否正确,比如是否需要启用Fullcone NAT或者关闭某些过滤选项。 接下来是路由配置的问题。主路由旁路由之间的通信是否正常?需要确认主路由是否正确地转发流量到旁路由,同时旁路由的路由表是否正确指向主路由作为默认网关。此外,用户的主机是否正确设置了网关DNS,可能还需要检查是否有IP冲突。 然后是DNS配置,如果DNS解析有问题,即使路由正确,也可能导致无法上网。建议用户将DNS设置为旁路由的IP或者公共DNS如114.114.114.114。 硬件或网络性能问题也不能忽视。网线、接口松动或者旁路由设备性能不足可能导致丢包。可以建议用户通过ping测试检查延迟丢包情况,比如在旁路由上ping主路由外网地址,以及在主机上ping旁路由主路由,查看哪出现丢包。 另外,用户是否开启了某些可能导致问题的功能,如Turbo ACC中的流量分载或者SFE快速路径,这些有时会导致冲突,需要暂时关闭测试。 还有可能主路由的DHCP设置没有正确分配旁路由作为网关,用户可能手动设置了主机的网关,但其他设备如果有问题可能需要检查DHCP配置。另外,检查主路由的防火墙规则是否阻止了旁路由的流量。 最后,如果以上方法都不行,可能需要更详细的日志分析,比如在旁路由上使用tcpdump抓包,或者查看系统日志中的错误信息。如果用户对网络配置不熟悉,可能需要简化设置,比如先确保旁路由作为纯网关,关闭不必要的插件,逐步排查问题。根据</think>你的描述,设置旁路由后出现丢包无法上网的问题,可能是由于路由规则、防火墙设置或网络流向配置不当导致的。以下是逐步排查修改建议: --- ### **一、基础检查** 1. **确认网关指向正确** - 检查设备(192.168.47.13)的网关是否已设置为旁路由 IP `192.168.47.9` - 查看命令(Windows):`ipconfig /all` - Linux/OpenWrt:`ip route show default` 2. **旁路由与主路由连通性** - 在旁路由上执行 `ping 192.168.47.1`(假设主路由 IP 是 192.168.47.1,需确认) - 如果无法 ping 通,检查旁路由的网线、VLAN 配置或主路由的 ARP 表。 --- ### **二、旁路由配置修改** #### 1. **关闭 OpenWrt 防火墙(临时测试)** - 在「常规设置」中 **关闭「SYN-flood 防御」** - 在「区域设置」中确保 **LAN → 入站/出站/转发均设为「接受」** - 重启防火墙:`/etc/init.d/firewall restart` - **注意**:测试后若生效,需重新配置防火墙规则而非长期关闭。 #### 2. **配置 NAT 规则(关键步骤)** - 如果旁路由需要处理 NAT(例如主路由未做 NAT): 在 OpenWrt 的 **网络 → 防火墙 → 自定义规则** 添加: ```bash iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE ``` (`eth0` 需替换为旁路由连接主路由的实际接口名,如 `br-lan`) #### 3. **修改网关 DNS** - 进入 OpenWrt 管理界面:**网络 → 接口 → LAN → 编辑** - **IPv4 网关**:填写主路由 IP(如 `192.168.47.1`) - **DNS 服务器**:填写主路由 IP 或公共 DNS(如 `114.114.114.114`) - 保存并应用后,重启网络:`/etc/init.d/network restart` --- ### **三、主路由配置** 1. **关闭主路由的 DHCP 冲突** - 如果主路由旁路由均开启 DHCP,需关闭其中一个(建议保留主路由 DHCP,旁路由关闭)。 2. **主路由静态路由(可选)** - 如果网络有跨网段需求,在主路由添加静态路由: 目标网络:`0.0.0.0/0`,网关:旁路由 IP `192.168.47.9`。 --- ### **四、诊断工具** 1. **检查丢包路径** - 在主机上执行: ```bash ping 192.168.47.9 # 测试到旁路由的连通性 ping 192.168.47.1 # 测试到主路由的连通性 ping 8.8.8.8 # 测试外网连通性 traceroute 8.8.8.8 # 查看路径卡在哪一跳 ``` 2. **OpenWrt 系统日志** - 通过 `logread` 命令或管理界面查看是否有防火墙丢包记录: ```bash logread | grep DROP ``` --- ### **五、其他可能性** 1. **MTU 不匹配** - 尝试在 OpenWrt 的 LAN 接口设置中修改 MTU 为 `1472` 或 `1480`(需与主路由一致)。 2. **IPv6 冲突** - 在 OpenWrt 的 LAN 接口中禁用 IPv6(除非明确需要)。 3. **硬件性能问题** - 旁路由设备(如 R2S、树莓派)性能不足可能导致丢包,可尝试关闭流量监控类插件(如 SQM、AdGuard)。 --- ### **六、最终建议** 1. 按以下流程简化配置: - 旁路由仅作为网关(关闭 DHCP、DNS 等服务)。 - 主路由负责 DHCP,并强制分配网关为旁路由 IP。 - 旁路由防火墙保留默认规则,仅添加 NAT 伪装规则。 2. 若问题依旧,尝试重置 OpenWrt 至初始配置,逐步添加规则排查。 请根据实际网络结构调整配置,若仍有问题可提供更多细节(如主路由型号、OpenWrt 版本、网络拓扑)。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值