CN115859158B - 场景识别方法、***及终端设备 - Google Patents

Abstract

本申请实施例公开了一种场景识别方法、***及终端设备，适用于定位技术领域，该方法包括：终端设备获取自身所处的当前地区和当前天气类型。确定出与当前地区和当前天气类型均匹配的目标识别模型。采集多次基础数据，其中相邻两次采集操作的间隔时长大于零。利用目标识别模型对采集到的基础数据进行处理，确定出自身进入的实际场景，实际场景为室内场景或室外场景。本申请实施例可以提升对实际场景识别的准确性。

Description

场景识别方法、***及终端设备

技术领域

本申请涉及定位技术领域，尤其涉及一种场景识别方法、***及终端设备。

背景技术

日常生活中，用户在室内场景和室外场景之间走动一种常见的情况。例如，用户从室外进入地铁站乘坐地铁，属于从室外场景进入室内场景的情况。又例如，用户在商场购物完，离开商场走到室外，则属于从室内场景进入室外场景的情况。

用户在室内场景和室外场景之间切换时，终端设备可以对用户进入的实际场景（以下简称为实际场景）进行识别，并根据识别结果对用户进行一些相关的反馈，从而为用户提供一些生活上的便利。但实际应用中发现，用户在室内场景和室外场景之间切换时，终端设备对实际场景识别难度往往较大，识别的准确度较低。

因此，实际应用中需要一种对实际场景识别准确度较高的方法。

发明内容

有鉴于此，本申请实施例提供了场景识别方法、***及终端设备，可以解决对用户进入的实际场景识别准确度低的问题。

本申请实施例的第一方面提供了一种场景识别方法，应用于终端设备，包括：

一方面，终端设备获取自身所处的当前地区和当前天气类型，并确定出与当前地区和当前天气类型均匹配的目标识别模型。另一方面终端设备采集多次基础数据，其中相邻两次采集操作的间隔时长大于零。最后利用目标识别模型对采集到的基础数据进行处理，确定出自身进入的实际场景，实际场景为室内场景或室外场景。

在本申请实施例中，一方面终端设备可以根据实际所处的地区以及实时的天气类型，来选取最适宜的识别模型使用。因此本申请实施例可以高度化的适配终端设备的实时情况，不会受到用户地理位置和天气的限制，实现对用户实时情况的针对性实际场景识别，极大地提高的对实际场景识别的准确性。另一方面以一定时间间隔进行多次数据采集，为搜星器提供更多的缓冲时间。使得搜星器用充足的时间完成冷启动，进入正常的工作状态搜索到完整的或者相对较为完整的卫星信号。因此本申请实施例可以获取到质量更好且更完整的基础数据。最后基于高适配性的识别模型来对获取到的基础数据进行处理，从而得到准确度更高的识别结果。

在第一方面的第一种可能的实现方式中，在采集多次基础数据之前，还包括：

进行光强检测，并当检测到的光强值满足预设条件时，执行采集多次基础数据的操作。

本申请实施例先进行光强检测，以粗识别用户的实时状态。在确定出实时状态为用户可能或已经进入目标识别的场景时，再正式开始基础数据采集，从而避免直接进行基础数据采集导致基础数据内存在大量脏数据的情况。因此本申请实施例可以提高对基础数据采集时机的准确性与合理性，提高所采集的基础数据的有效性，同时减少或避免对非实际场景内进行无效数据采集的工作量。

在第一方面的第二种可能的实现方式中，在进行光强检测之前，还包括：

获取自身所处的当前场景，当前场景为室内场景或者室外场景。

进行光强检测，当检测到的光强值满足预设条件时，执行采集多次基础数据的操作，具体包括：

当前场景为室外场景时，进行光强检测，并在检测到的光强值小于或等于预设的第一强度阈值时，执行采集多次基础数据的操作。

当前场景为室内场景时，进行光强检测，并在检测到的光强值大于预设的第二强度阈值时，执行采集多次基础数据的操作。

本申请实施例针对用户处于室内场景和室外场景两种情况下各自的特点，设置了对应的预设条件，以实现对用户实时状态更为精确的识别。同时也为后续区分两种情况进行数据采集提供基础。

作为本申请的一个实施例，获取自身所处的当前场景，包括：

检测在目标业务场景下历史对实际场景的识别结果。

当检测到有历史识别结果时，将该结果作为当前场景。

当未检测到有历史识别结果时，则进行环境数据检测或获取预设时长内的运动轨迹，并利用检测到的环境数据或运动轨迹来确定出当前场景。

本申请实施例提供了两种对当前场景的确定方法，以应对实际应用中终端设备可能面对的各种情况，实现对当前场景的准确有效识别。

在第一方面的第三种可能的实现方式中，在采集多次基础数据之前，还包括：

当检测到满足前置条件时，执行采集多次基础数据的操作。前置条件中包含有若干种用户行为。

本申请实施例通过设置前置条件，来确定用户是否有进行室内室外切换的意图，并在确定出用户有进行室内室外切换意图（即满足前置条件）时，开始进入基础数据采集流程。此时可以减少甚至避免在用户没有室内室外切换意图时的基础数据采集工作。因此本申请实施例可以有效提高对基础数据采集时机的准确性与合理性，减少对终端设备的功耗，同时提高对实际场景识别的准确性。

在第一方面的第四种可能的实现方式中，在采集多次基础数据之前，还包括：

当检测到满足预设的触发条件时，确定自身当前所处的目标业务场景。

确定出目标业务场景对应的前置条件，并检测是否满足前置条件。

本申请实施例通过设置触发条件，并在满足触发条件时使能对实际场景识别的整体方案，可以避免实际应用中持续识别实际场景所带来的高功耗问题，从而降低本申请实施例对终端设备带来的功耗。

在第一方面的第五种可能的实现方式中，当检测到满足预设的触发条件时，确定自身当前所处的目标业务场景，包括：

当检测到满足预设的触发条件时，确定出触发条件对应的业务场景，并将该业务场景确定为当前所处的目标业务场景。

在本申请实施例中，终端设备中可以设置一个或多个触发条件，每个触发条件可以对应着一个或多个业务场景。从而使得终端设备可以在满足触发条件时，将该被满足的触发条件对应的业务场景作为自身当前所处的业务场景，从而第一时间确定出即目标业务场景。

在第一方面的第六种可能的实现方式中，确定出与当前地区和当前天气类型均匹配的目标识别模型，包括：

确定出与目标业务场景、当前地区和当前天气类型均匹配的目标识别模型。

在针对不同业务场景区分设置识别模型时，本申请实施例可以有效识别出当前业务场景，以为后续识别模型的选取提供依据。由于不同识别模型所适配的业务场景可能会有所区别，因此本申请实施例可以有效提高对业务场景的适配性，从而提高对具体业务场景下的实际场景识别准确性。

在第一方面的第七种可能的实现方式中，利用目标识别模型对采集到的基础数据进行处理，确定出自身进入的实际场景，包括：

利用目标识别模型对采集多次基础数据操作中最后一次采集到的基础数据进行处理，确定出自身进入的实际场景。

本申请实施例以最新采集的基础数据为准进行实际场景分类和识别，此时搜星器启动的时间最久，因此数据的完整性最好，从而提高识别结果的准确性。

在第一方面的第八种可能的实现方式中，识别模型为分类模型。利用目标识别模型对采集多次基础数据操作中最后一次采集到的基础数据进行处理，确定出自身进入的实际场景，包括：

利用目标识别模型对采集多次基础数据操作中最后一次采集到的基础数据进行处理，得到目标识别模型输出的当次分类结果。再根据当次分类结果，确定出自身进入的实际场景。

由于单次分类结果的可靠性会受到模型识别精度影响，同时还受到基础数据质量的影响，从而使得单次分类结果可能存在一定的误识别情况。因此通过基于当次分类结果进行综合分析确定识别结果，使得本申请实施例可以有效提升最终识别结果的可信度，从而提高对识别结果的准确性。

在第一方面的第九种可能的实现方式中，根据当次分类结果，确定出自身进入的实际场景，包括：

获取最近得到的多次分类结果，并根据多次分类结果确定出自身进入的实际场景。其中，多次分类结果中包含当次分类结果。

本申请实施例通过对多次分类结果进行综合分析确定识别结果，可以有效降低单次分类结果误识别对最终实际场景识别结果的影响比重，提高最终实际场景识别结果的准确性。

在第一方面的第十种可能的实现方式中，根据多次分类结果确定出自身进入的实际场景，包括：

将多次分类结果中出现次数最多的分类结果作为终端设备进入的实际场景。或者当多次分类结果均相同时，将多次分类结果中任一分类结果作为终端设备进入的实际场景。

本申请实施例基于投票法提供了两种具体的综合分析方法，以降低单次分类结果误识别对最终实际场景识别结果的影响比重，提高最终实际场景识别结果的准确性。

在第一方面的第十一种可能的实现方式中，终端设备当前所处的目标业务场景为进出地铁站。

在获取自身所处的当前场景之前，还包括：

当检测到满足前置条件时，执行获取自身所处的当前场景的操作。前置条件中包含有若干种用户行为。

相应的，当前场景为室内场景时，进行光强检测，包括：当前场景为室内场景时，延迟预设时长后进行光强检测。

用户在出地铁站时，由于闸机一般设置在地铁站内部，因此导致用户往往会提前触发前置条件。为了应对这种情况，本申请实施例在前置条件被触发后没有直接进行光强检测，而是先选择延时一段时间再进行光强检测，以为用户提供一定的时间走出室内场景，从而加大光强检测时用户处于实际场景内的概率。因此，本申请实施例可以提高所采集的基础数据的有效性，从而提高识别结果准确性。

在第一方面的第十二种可能的实现方式中，当前场景为室外场景，且检测到的光强值大于第一强度阈值时，间隔预设的时长后返回执行进行光强检测的操作，直至满足预设的终止条件，停止光强检测。

当终端设备检测到的光强值大于强度阈值时，说明当前环境的光强较强，有较大可能用户仍处于室外场景中。此时本申请实施例，通过间隔一段时间再重新进行光强检测，从而实现对用户实时状态的持续监测。

在第一方面的第十三种可能的实现方式中，当前场景为室内场景，且检测到的光强值小于或等于第二强度阈值时，以预设的时长为间隔，周期性执行进行光强检测的操作，直至满足预设的终止条件，停止光强检测。

当终端设备检测到的光强值小于强度阈值时，说明当前环境的光强较若，有较大可能用户仍处于室内场景中。此时本申请实施例会以一定时长为间隔，周期性地进行循环光强检测，从而实现对用户实时状态的持续监测。

在第一方面的第十四种可能的实现方式中，所述基础数据中包含卫星信号的统计学特征参数；统计学特征参数包含以下至少一项参数：卫星信号的强度比例、最大信噪比、最小信噪比、信噪比标准差、信噪比中位数、信噪比极差、去零平均信噪比以及含零平均信噪比。

其中，考虑到地区内可搜索到的卫星数量往往是浮动的，为了去除浮动对求均值时的影响，在本申请实施例中，技术人员可以预先设定一个卫星总数量Q1。例如可以将Q1设置为地球表面所有导航卫星的总数。假设当前可搜索到的导航卫星数量n1，在计算去零平均信噪比，可以将当前搜索到的n1个导航卫星的卫星信号信噪比数据求和并除以n1，而在计算含零平均信噪比时，则可以将当前搜索到的n1个导航卫星的卫星信号信噪比数据求和并除以Q1。其中，n1和Q1均为任意正整数，且n1≤Q1。对使用去零平均信噪比以及含零平均信噪比说明如下：

实际应用中，由于室内遮挡的缘故，室内场景可搜索到的导航卫星数量一般会比室外场景少较多，因此实际室内场景可获取到的卫星信号信噪比数据往往也会少于室外场景。含零平均信噪比在计算时，可以避免可搜索到的导航卫星数量对计算结果造成较大影响，因此使用该项特征参数可以较好的适配室内场景的实际情况，从而可以提升识别模型对室内场景的识别效果。而去零平均信噪比可以较好的体现所搜索到的导航卫星的信号数据，相对整体导航卫星数据分布情况，因此该项特征参数可以较好的适配室外场景的实际情况，从而可以提升识别模型对室外场景的识别效果。

本申请实施例的第二方面提供了一种场景识别装置，

获取模块，用于获取自身所处的当前地区和当前天气类型。

模型确定模块，用于确定出与当前地区和当前天气类型均匹配的目标识别模型。

采集模块，用于采集多次基础数据，其中相邻两次采集操作的间隔时长大于零。

识别模块，用于利用目标识别模型对采集到的基础数据进行处理，确定出自身进入的实际场景，实际场景为室内场景或室外场景。

作为本申请的一个实施例，场景识别装置可以实现如上述第一方面任一项的方法。

本申请实施例的第三方面提供了一种场景识别***，包括：服务器以及上述第一方面任一项的方法中的终端设备。

服务器先获取样本参数，样本参数标记有对应的地区标签和天气类型标签。再基于样本参数对初始模型进行训练，得到训练完成的识别模型，该识别模型关联有样本参数对应的地区标签和天气类型标签。

终端设备确定出与当前地区和当前天气类型均匹配的目标识别模型，包括：

终端设备基于当前地区和当前天气类型，对服务器中的识别模型进行标签匹配，确定出地区标签与当前地区匹配且天气类型标签与当前天气类型相匹配的识别模型。

本申请实施例可以针对不同地区和不同天气类型区分构建的识别型，从而为终端设备提供更多可适配的识别模型。

在第三方面的第一种可能的实现方式中，服务器基于样本参数对初始模型进行训练，得到训练完成的识别模型，包括：

先基于预设的过滤条件对样本参数进行数据过滤，得到过滤后的样本参数。再基于过滤后的样本参数对初始模型进行迭代训练。其中在对初始模型迭代训练的过程中，对每次训练的损失函数值进行检测，并在检测到损失函数值稳定性满足预设条件时停止训练，得到训练完成的识别模型。

本申请实施例中服务器可以对样本参数进行数据过滤，以剔除其中的一些质量较差或可信度较低的数据，以尽量保留具有室内场景和室外场景典型特性的参数。因此可以提供最终对识别模型的训练效果，得到准确度更高的识别模型。同时通过设置对损失函数值稳定性相关的收敛条件，可以有效控制收敛速度，防止出现过早停止收敛或过度拟合收敛时间过久的情况。从而提升对识别模型的训练效果，提高最终识别模型的准确性。

作为本申请的一个可选实施例，预设条件可以包括：当连续h1次差值均小于差异阈值，判定为损失函数值稳定性较高，停止训练。

作为本申请的一个可选实施例，预设条件亦可以包括：当连续h2次判断结果均为当前损失函数值大于或等于前一次损失函数值，判定为损失函数值稳定性较高，停止训练。

其中，h1和h2均为任意正整数。

在第三方面的第二种可能的实现方式中，终端设备在采集多次基础数据之后，还包括：

终端设备基于当前地区和当前天气类型，对采集多次基础数据操作中最后一次采集到的基础数据添加对应的特征标签，并将添加好的特征标签后的基础数据发送至服务器。特征标签中包括地区标签和天气类型标签。

服务器基于接收到的基础数据的特征标签，对本地的识别模型进行标签匹配，确定出待更新的识别模型。再基于接收到的基础数据，对待更新的识别模型进行更新训练，得到更新后的识别模型。

在本申请实施例中，通过基础数据的特征标签与已有的识别模型的特征标签进行匹配，可以精确定位出每一个真实基础数据对应的特定识别模型（即目标模型）。再基于真实的基础数据来对目标模型进行更新，从而使得本申请实施例可以持续保持识别模型对用户真实生活场景的适应能力，使得本申请实施例中的识别模型对实际场景的分类准确性可以持续保持较高的水平。因此本申请实施例可以有效保持对实际场景识别的准确性。

第四方面，本申请实施例提供一种终端设备，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述第一方面任一项的方法。

第五方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现如上述第一方面任一项的方法。

第六方面，本申请实施例提供一种芯片***，该芯片***包括处理器，处理器与存储器耦合，处理器执行存储器中存储的计算机程序，以实现如上述第一方面任一项所述的方法。该芯片***可以为单个芯片，或者多个芯片组成的芯片模组。

第七方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面任一项所述的方法。

可以理解的是，上述第二方面至第七方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1A为本申请实施例提供的用户进入的实际场景为地铁站的场景示意图；

图1B为本申请实施例提供的基于地铁站进行地铁乘车码推荐的场景示意图；

图1C为本申请实施例提供的基于实际场景进行吃住行推荐的场景示意图；

图2A为本申请实施例提供的基础模型建模方法的实现流程图；

图2B为本申请实施例提供的基础模型的训练方法的实现流程图；

图2C为本申请实施例提供的基分类器构建及融合的架构示意图；

图2D为本申请实施例提供的基础模型跨地区应用的各项指标情况示意图；

图3A为本申请实施例提供的进出地铁站的业务场景中触发条件的场景示意图；

图3B为本申请实施例提供的场景识别方法的实现流程图；

图4A为本申请实施例提供的终端设备进行卫星信号搜索的场景示意图；

图4B为本申请实施例提供的针对用户当前处于室外场景时，对基础数据采集的流程示意图；

图4C为本申请实施例提供的针对用户当前处于室内场景时，对基础数据采集的流程示意图；

图4D为本申请实施例提供的针对用户当前处于地铁站内时，对基础数据采集的流程示意图；

图5为本申请实施例提供的进行场景分类的整体架构示意图；

图6A为本申请实施例提供的识别模型更新方法的流程示意图；

图6B为本申请实施例提供的基于众包数据进行模型更新的场景识别法整体架构图；

图7为本申请实施例提供的场景识别装置的结构示意图；

图8为本申请实施例提供的终端设备的结构示意图；

图9A为本申请实施例提供的手机100的结构示意图；

图9B为本申请实施例提供的终端设备的软件结构框图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定***结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的***、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

以下对本申请实施例可能涉及到的一些概念进行说明如下：

多个：若无特别说明，在本申请实施例中，多个均是指两个或两个以上。

实际场景：在本申请实施例中，实际场景是对用户实际所进入的室内场景或室外场景的代称。即在本申请实施例中，实际场景为终端设备所需识别的场景。具体而言，当用户从室内场景进入室外场景时，实际场景为室外场景。而当用户从室外场景进入室内场景时，实际场景则为室内场景。

其中，当本申请实施例应用在具体的业务场景时，亦可以对室内场景和室外场景进行业务场景的细化。例如在一些实施例中，室内场景可以是指特定的一种或多种具体场景，如可以是地铁站、商场和小区楼宇等中的任一种。同理在一些实施例中，室外场景也可以是指特定的一种或多种具体场景，如可以是广场、公园、球场和公交站台等中的任一种。当对室内场景和室外场景进行业务场景的细化时，本申请实施例中的实际场景，则是指具体细化后的室内场景或室外场景。例如，假设在一个可选实施例中，室内场景是指地铁站，而室外场景是任意室外场所。则此时，实际场景可以指是地铁站或者任意室外场所。

搜星器：在本申请实施例中，将终端设备中用于进行导航卫星信号搜索的硬件统称为搜星器。根据终端设备软硬件情况不同，搜星器所包含的具体内容可以存在一定差异。例如，在一些终端设备中，搜星器可以包含卫星导航芯片及卫星导航芯片的***电路。实际应用中，终端设备可以利用搜星器来进行导航卫星信号搜索，并可以根据搜索到的卫星信号数据确定出当前可搜索到的卫星数量、卫星信号强度等数据。其中，本申请实施例不对导航卫星具体所属的全球导航卫星***（Global Navigation Satellite System，GNSS）做过多限定，例如，可以是：北斗卫星导航***（BeiDouNavigation Satellite System，BDS）、全球定位***（Global Positioning System，GPS）、格洛纳斯卫星导航***（GlobalNavigation Satellite System）和欧盟的伽利略卫星导航***（GalileoSatelliteNavigation System，GALILEO）中的任意一种或多种。本申请实施例中的卫星信号，亦可描述为GNSS信号。

日常生活中，用户经常会在室内场景和室外场景之间走动。例如，常见的从室外进入地铁、商场以及小区内的楼宇等，均属于从室外场景进入室内场景，而从地铁、商场等建筑物内走出去，则属于从室内场景进入室外场景。用户在室内场景和室外场景切换时，终端设备可以对用户进入的实际场景进行识别。在此基础上，终端设备可以根据识别结果来对用户进行一些相关的反馈或者进行一些其他操作，从而为用户提供一些生活上的便利。

以一实例进行说明，用户在室内场景和室外场景切换时，对所进入的实际场景的需求可能会产生一定的变化。例如，用户从室外场景进入至室内场景时，可能会需要使用室内场景内的一些事物。而用户从室内场景进入室外场景时，则可能是需要打车出行或者需要运动等。在面对用户室内场景和室外场景切换时的需求变化，终端设备首先需要识别出用户进入的实际场景，在此基础上再针对用户实际需求进行内容推荐、智能操控等操作，从而为用户提供一些生活上的便利，同时提高用户对终端设备的操作效率。

例如可以参考图1A和图1B。其中，图1A是本申请实施例提供的一种用户进入的实际场景为地铁站的场景示意图。图1B，是本申请实施例提供的一种基于地铁站进行地铁乘车码推荐的场景示意图。在本申请实施例中，当识别出用户从室外进入地铁站时，终端设备可以弹出相关的地铁乘车码卡片，从而使得用户可以通过地铁乘车码卡片快速打开乘车码，并进站乘坐地铁。可以参考图1C，是本申请实施例提供的一种基于实际场景进行吃住行推荐的场景示意图。在本申请实施例中，当识别出用户从火车站出来时，终端设备可以弹出一些附近美食、酒店住宿和景点游玩的推荐卡片，从而使得用户可以通过推荐卡片快速熟悉附近吃住行的情况。在另一些实施例中，终端设备在识别出用户进入了小区楼宇时，可以按照用户预先设置的一些参数，远程控制用户屋内的物联网设备运行状态，如开启空调并设置温度等。

由上述分析可知，对用户进入的实际场景的识别，是实际应用中真实存在的需求，也是终端设备厂商为用户提供更好的个性化服务的一个技术基础。为了实现对实际场景的识别，可以采用以下几种识别方案：

识别方案1：终端设备采用自身的搜星器进行卫星信号搜索，从而确定出可搜索到的卫星数量，再根据卫星数量来判断所处环境属于室内场景还是室外场景。

识别方案2：终端设备采用自带的一些传感器，直接对所处环境的光强、基站信号强度、磁场强度以及卫星信号强度等参数进行采集。在获取到这些参数之后，再利用这些参数的强度大小来判断所处环境属于室内场景还是室外场景。

实际应用中，室内场景对卫星和基站等的信号遮蔽较为严重，使得终端设备在室内场景内可检测到的卫星数量、卫星信号强度以及基站信号强度等均会较差。因此识别方案1通过卫星数量，可以一定程度上实现对室内场景和室外场景的区分识别。同时，对于室内场景对阳光的遮蔽也较为严重，但往往会有相应的灯光照射，使得室内场景和室外场景的光强往往会存在一定的差别，因此光强也可以作为区别识别的参考参数。此外，由于建筑物对地球磁场的干扰，使得室内和室外磁场强度也会有一定差异。因此，识别方案2通过光强、基站信号强度、磁场强度和卫星信号强度等参数的大小，亦可以一定程度上实现对室内场景和室外场景的区分识别。但无论是识别方案1还是识别方案2，均是在识别时直接进行光强、基站信号强度、磁场强度、卫星数量以及卫星信号强度的参数的采集，均至少存在以下几个缺陷：

缺陷1：采用参数大小的方式区分室内场景和室外场景，识别方式较为粗糙，且受到地理位置以及天气等因素限制过大，使得识别结果可靠性较低，准确性低。

实际应用中，不同地区以及不同天气对参数的影响很大。例如晴天和阴天两种天气下，室外的光强差异可达几倍至几十倍。又例如，不同地区和不同天气情况下，即使都是在室内采集或室外采集，终端设备所能采集到的导航卫星的数量和卫星信号强度也会存在极大地差异。因此，直接根据这些参数难的大小来区分室内场景和室外场景，识别结果较为粗糙，可靠性和准确性较低。

同时，由上述分析可知，识别方案1和识别方案2所采集的参数情况，受到地理位置（即地区）以及天气影响较大。同理，同一天的不同时间段，识别方案1和2所采集的参数情况也可能会有较大差异。例如白天和晚上，室外的光强差异也会巨大。因此识别方案1和识别方案2收到参数采样的时间、地理位置以及天气限制极大。无法适应不同地区不同天气下的实际场景识别需求。

此外，对于识别方案2，基站信号强度和磁场强度作为部分主要参考维度，其可信度也较低。例如，基站的定位范围为百米数量级，即在100米范围内，基站信号强度的大小难以直接用于分辨定位。而且由于基站信号强度会随与基站中心距离增加而减弱，使得较弱的基站信号强度可能为某一较强室外基站边缘，也可能为某一室内基站的覆盖范围。同理对于磁场强度而言，磁场强度弱的情况，可能是室外干扰物过多导致，也可能是室内建筑物屏蔽导致。

缺陷2：参数采集的时机未考虑实际终端设备的情况，导致采集的参数质量较差，使得识别结果的准确性较低。

实际应用中，终端设备在刚启动搜星器时，搜星器往往处于冷启动的状态。而冷启动过程中，终端设备进行导航卫星信号时所采集的卫星信号数据是不完整的。因此实际应用中，识别方案1和识别方案2在需要进行实际场景识别时，直接启动搜星器采集的卫星信号数据往往也是不完整的，参数质量较差。在此基础上，利用不完整的卫星信号数据来识别实际场景，其识别结果的准确性也往往较低。

缺陷3：与实际的业务场景结合紧密度低，对业务场景下的实际场景的识别准确度较低。

实际应用中，不同业务场景下具体所需识别的具体室内场景或室外场景是有一定差异的。例如对于地铁场景，所需识别的具体室内场景为地铁站。对于商场场景，所需识别的室内场景为商场。对于公园场景，所需识别的室外场景为公园。而不同的室内场景或室外场景又具有一定的场景特性，因此仅通过对一些参数的直接采集并进行大小判断识别，往往难以贴合实际业务场景的情况。

综合上述三点缺陷分析可知，无论是识别方案1还是识别方案2，其对实际场景的识别准确率均较低。

为了提高对实际场景的识别准确率，本申请实施例一方面可以获取自身当前所处的地区以及天气类型，并确定出与当前地区和当前天气类型相匹配的识别模型。另一方面，本申请实施例会进行多次基础数据的采集，且每次采集均会间隔一定的时长。在此基础上，利用识别模型对采集到的基础数据进行处理，确定出当前的实际场景时室内场景还是室外场景。

本申请实施例至少具有以下有益效果：

1、对参数采集的时机更为合理有效，因此采集的参数有效性及质量均更佳，从而可以提高实际场景识别结果的准确性。

考虑到搜星器在长期不启动的情况下会进入关闭状态，再启动时则属于冷启动，此时搜索得到的卫星信号往往不完整。而搜星器在已启动后的一段时间内均为温启动或热启动，此时可以较为完整的获取到卫星信号。基于这一实际情况，本申请实施例在进行参数采集时，会在启动搜星器后多次采集参数，从而尽可能地基于热启动状态下的搜星器进行卫星信号的采集。使得本申请实施例实际使用的卫星信号可以尽可能的完整有效。因此本申请实施例可以有效提升实际使用的卫星信号的参数质量。

2、本申请实施例中的识别模型是针对不同地区和不同天气类型区分构建的模型。在实际使用时，终端设备可以根据实际所处的地区以及实时的天气类型，来选取最适宜的识别模型使用。因此本申请实施例可以高度化的适配终端设备的实时情况，不会受到用户地理位置和天气的限制，实现对用户实时情况的针对性实际场景识别，极大地提高的对实际场景识别的准确性。且基于识别模型的识别，可以避免直接基于参数大小进行场景识别导致识别结果过于粗糙的情况出现，从而提升识别准确性。

本申请实施例提供的场景识别方法可以应用于手机、平板电脑和可穿戴设备等终端设备上，此时终端设备即为本申请实施例提供的场景识别方法的执行主体，本申请实施例对终端设备的具体类型不作任何限制。

以下对本申请实施例适用的业务场景进行说明如下：

实际应用中，本申请实施例可适用于任意需要进行实际场景识别的业务场景，包括但不限于如：进出地铁站、进出火车站、进出商场、进出小区、进出公园、进出球场以及进出广场等。具体可根据实际应用的业务场景确定。

同时，本申请实施例不对识别出实际场景后，对识别结果的应用方式做过多限定，具体可根据实际的业务场景需求设定。以下通过一些实施例进行举例说明：

例如在图1A和图1B所示实施例中，针对进出地铁站的业务场景，终端设备可以在识别出实际场景为地铁站时，进行地铁乘车码卡片的自动弹出。又例如在图1C所示实施例中，对于进出火车站的业务场景，终端设备可以在识别出实际场景为室外场景时，进行吃住行相关的推荐卡片的自动弹出。而在识别出实际场景为火车站时，终端设备则可以弹出火车电子票的推荐卡片等。对于进出商场的业务场景，终端设备可以在识别出实际场景为商场时，弹出对商铺或商品的推荐卡片。对于进出小区的业务场景，终端设备可以在识别出用户进入小区楼宇时，提醒用户是否要启动屋内的物联网设备，并弹出对物联网设备运行设置的推荐卡片。

本申请实施例根据时序可分为三个阶段：基础模型训练、实际场景识别以及识别模型更新。其中，基础模型训练阶段主要是进行建模，即进行识别模型训练，以得到可进行室内场景和室外场景分类识别的模型。实际场景识别阶段是具体的应用阶段，主要是终端设备对参数进行采集并进行实际场景的识别，以确定出终端设备所进入的实际场景。识别模型更新阶段，主要是利用终端设备在实际场景识别阶段采集的真实参数，对已有的识别模型进行更新训练，以提高识别模型的有效性。以下依次进行说明：

阶段一：基础模型训练。

首先应当说明地，用户在使用终端设备的过程中可能会处于各种业务场景。考虑到不同业务场景的实际情况不同，因此本申请实施例可以选择对所有业务场景进行统一建模，亦可以选择对不同业务场景进行区分建模，具体可由技术人员自行选定。当选择针对所有业务场景进行统一建模时，所得到的基础模型可适用于所有业务场景，即此时基础模型的训练和使用可以不区分业务场景。而选择针对不同业务场景进行区分建模时，则根据实际设定的业务场景与基础模型对应关系，每个基础模型可以适用于一种或多种业务场景。以下均以单种业务场景为例，进行基础模型训练阶段的说明：

考虑到导航卫星的分布具有一定的地域性差异，不同地理位置空中的导航卫星分布密度与分布状态有一定差异。同时在不同天气下，云层对卫星信号的影响也存在一定差异。例如在多云、阴天、雨天、暴雪以及晴天中，终端设备所能采集到的卫星信号均可能会存在差异。因此实际应用中，地理位置和天气对终端设备所能采集的卫星信号均会有较大的差异。

为了可以适应不同地理位置和不同天气下对实际场景的识别需求，在本申请实施例中，以地区为具体的地理位置区分单位，并针对不同地区和不同天气进行区分建模。其中，本申请实施例不对地区的划分规则做过多限定，可由技术人员根据需求自行设定。例如可以以城市作为地区划分规则，此时每个地区对应着一个城市。又例如，亦可以以省份作为地区划分规则，此时每个地区对应着一个省份。同时，本申请实施例亦不对具体天气划分规则做过多限定，可由技术人员自行设定。例如在一些可选实施例中，可以将天气划分为晴天和非晴天，而在另一些可选实施例中，亦可以将天气划分为晴天、多云和极端天气等。

具体而言，技术人员在选定所需建模的一个或多个地区后，可以针对不同地区分别进行建模，且针对单个地区而言，也会区分不同天气类型进行区分建模。因此对于单个地区而言，也有着多个不同天气类型分别对应的识别模型。其中，本申请实施例针对每个地区中每类天气对应的建模操作均相同。

例如，假设天气划分规则中将天气类型划分为：晴天和非晴天两类。此时对于每个选定的地区，本申请实施例均可以针对晴天和非晴天分别进行建模，从而得到该地区对应的两个识别模型，即晴天和非晴天各自对应的识别模型。

又例如，假设共有城市A和城市B两个选定的地区，同时天气类型共分为天气a和天气b两类，此时本申请实施例共需构建4个识别模型：城市A在天气a对应的识别模型、城市A在天气b对应的识别模型、城市B在天气a对应的识别模型以及城市B在天气b对应的识别模型。在本申请实施例中，对这4个识别模型的建模方法均相同。

为了便于说明，本申请实施例以单个地区下单种天气类型对应的建模方法为例进行说明，其他地区以及其他天气类型下的建模方法，均可参考本申请实施例实现，本申请实施例不予赘述。下面通过具体实施例来进行说明。

可以参考图2A，示出了本申请实施例提供的基础模型训练阶段，基础模型的建模方法的实现流程图，详述如下：

S201，技术人员对目标地区在目标天气下的参数进行采集，得到样本参数。

在正式开始进行模型训练前，本申请实施例中由技术人员在目标地区内，进行目标天气下的参数采集。由于实际场景可能为室内场景或室外场景，因此在进行参数采集时，需要对室内场景和室外场景均进行参数采集，从而得到模型训练所需的样本参数。同时还需要为采集到的样本参数标记对应的场景标签，以记录是在室内场景下采集还是在室外场景下采集的。另外为了提升模型训练效果，技术人员可以采集较多的样本参数以备使用。其中，在本申请实施例中，每个具体室内场景或室外场景下采集的参数，均作为一组独立的参数进行后续的操作。因此设共采集了m个场景（包括室内场景和室外场景）的样本参数，则本申请实施例的样本参数中包含m组独立的参数，其中m为大等于2的任意整数。

在本申请实施例中，目标地区可以是任意地区，目标天气可以是任意天气类型，具体可由技术人员预先选定具体的目标地区和目标天气。例如，在一些可选实施例中，目标地区可以为对城市A，目标天气类可以为天晴。此时由技术人员在城市A天晴时，对室内场景和室外场景均进行参数采集。

应当说明的几点：

1、在本申请实施例中，终端设备所需采集的参数至少包括：通过搜星器采集到的卫星信号的特征参数。在此基础上，所需采集的参数亦可以包含一些卫星信号特征参数以外的其他数据，例如WiFi信号强度以及磁场信号强度等。在本申请实施例中，将卫星信号的特征参数以外的其他参数，称为辅助特征参数（亦可简称为辅助特征）。同时，本申请实施例不对是否采用辅助特征参数，以及具体采用什么辅助特征参数做过多限定，可由技术人员自行设定。

由于统计学特征可以较好的表征卫星信号的一些特征，同时实验证明，统计学特征参数室内场景下和室外场景下均会存在一定的差异。因此，作为本申请的一个可选实施例，可以采用卫星信号的统计学特征参数，作为本申请实施例中进行模型训练的样本参数，以及后续终端设备实际应用时所需获取的参数。

作为本申请实施例，可使用但不限于以下统计学特征参数中的任意一项或多项作为样本参数：卫星信号强度比例、最大信噪比、最小信噪比、信噪比标准差、信噪比中位数、信噪比极差、去零平均信噪比以及含零平均信噪比。

其中，考虑到地区内可搜索到的卫星数量往往是浮动的，为了去除浮动对求均值时的影响，在本申请实施例中，技术人员可以预先设定一个卫星总数量Q1。例如可以将Q1设置为地球表面所有导航卫星的总数。假设当前可搜索到的导航卫星数量n1，在计算去零平均信噪比，可以将当前搜索到的n1个导航卫星的卫星信号信噪比数据求和并除以n1，而在计算含零平均信噪比时，则可以将当前搜索到的n1个导航卫星的卫星信号信噪比数据求和并除以Q1。其中，n1和Q1均为任意正整数，且n1≤Q1。对使用去零平均信噪比以及含零平均信噪比说明如下：

实际应用中，由于室内遮挡的缘故，室内场景可搜索到的导航卫星数量一般会比室外场景少较多，因此实际室内场景可获取到的卫星信号信噪比数据往往也会少于室外场景。含零平均信噪比在计算时，可以避免可搜索到的导航卫星数量对计算结果造成较大影响，因此使用该项特征参数可以较好的适配室内场景的实际情况，从而可以提升识别模型对室内场景的识别效果。而去零平均信噪比可以较好的体现所搜索到的导航卫星的信号数据，相对整体导航卫星数据分布情况，因此该项特征参数可以较好的适配室外场景的实际情况，从而可以提升识别模型对室外场景的识别效果。

2、实际操作中，技术人员可根据业务场景确定具体所需采集参数的室内场景和室外场景。例如对于进出地铁站的业务场景，可以是对地铁站内和地铁站外进行参数采集。

3、实际操作中，对于同一地区不同天气类型下的参数采集工作可以同时或穿插进行。

S202，服务器基于样本参数，对预先构建的初始模型进行深度学习训练，得到基础模型。

在本申请实施例中，初始模型是一个具有初始参数配置的分类神经网络模型，具体的初始参数可由技术人员自行设定，此处不做限定。技术人员在得到样本参数后，可以将样本参数、对应的地区标签、天气类型标签以及样本参数内各个参数具体对应的实际场景（室内场景或室外场景）上传至云端的服务器。

云端的服务器在获取到样本参数以及对应的地区标签和天气类型标签之后，基于样本参数和具体对应的实际场景进行机器学习，以对初始模型进行迭代训练，得到可用于进行室内场景和室外场景分类的基础模型。同时，本申请实施例还为训练好的基础模型标记对应的地区标签和天气类型标签。

此外，若在对多种业务场景均进行了建模操作时，则可以选择为训练好的基础模型标记对应的业务场景标签。其中，若不区分业务场景进行建模，则可以选择不进行业务场景标签的标记。

作为本申请的一个可选实施例，可以参考图2B，示出了本申请实施例提供的基础模型训练阶段，基础模型的训练方法的实现流程图。在本申请实施例中，服务器内包含数据过滤模块、机器学习模块以及防早停过拟合模块，在本申请实施例中S202可以被替换为：S2021至S2023，详述如下：

S2021，数据过滤模块基于预设的过滤条件对样本参数进行数据过滤，得到过滤后的样本参数。

考虑到实际采集的样本参数中有可能会存在一些质量较差或可信度较低的数据，这些数据可能会影响对初始模型的训练效果。例如在一些室内室外交接处所测得的参数，难以体现出室内场景或室外场景的典型特性。因此在正式开始迭代训练之前，服务器首先可以对样本参数进行数据过滤，以剔除其中的一些质量较差或可信度较低的数据，以尽量保留具有室内场景和室外场景典型特性的参数。其中，本申请实施例不对具体使用的数据过滤条件做过多限定，可由技术人员自行设定。

作为本申请的一个可选实施例，考虑到样本参数均是针对具体的室内场景和室外场景采集的参数，因此其本质是与采集时的实际场景相关联的。即室内场景和室外场景的一些特性也会同时影响着样本参数的实际取值情况。基于此，本申请实施例可以选择一些与室内场景和室外场景特性关联度较高的条件作为过滤条件。

例如，对于室外场景，在天气类型已知的情况下，其光强大小也是有一定下限阈值的。而对于室内场景，其光强大小受天气类型影响往往较小，因此其光强大小往往是有一定上限阈值的。因此当样本参数中包含光强时，可以将光强大小作为过滤条件之一（亦可称为第一过滤条件）。具体而言，在进行数据过滤时，针对样本参数中每个具体场景下采集的参数分别进行光强大小的判断。对于样本参数中在室内场景下采集的参数，将其中光强大于上限阈值的参数组剔除。而对于样本参数中在室外场景下采集的参数，则将其中光强小于限阈值的参数组剔除，从而完成光强维度的数据过滤。

又例如，考虑到真实生活中用户在室内场景和室外场景活动的时间均是有一定规律性的，因此剔除一些用户在各个实际场景内非活动时间段采集的参数，从而提升剩余参数与真实生活的贴合度，使得最终得到的基础模型可以更加准确地识别用户真实生活中的实际场景。因此，样本参数中各个参数组的采集时间是否处于对应的活动时间段，亦可以作为过滤条件之一（亦可称为第二过滤条件）。具体而言，本申请实施例可以预先针对室内场景设置一个用户活动的时间段（以下称为第一时间段），并针对室外场景设置用户活动的另一时间段（以下称为第二时间段）。在进行数据过滤时，对于样本参数中在室内场景下采集的参数，将其中时间戳（对应着采集时间）在第一时间段以外的参数组剔除。而对于样本参数中在室外场景下采集的参数，则将其中时间戳（对应着采集时间）在第二时间段以外的参数组剔除，从而完成光强维度的数据过滤。

S2022，机器学习模块基于过滤后的样本参数对预先构建的初始模型进行迭代训练。

在完成数据过滤后，服务器开始利用过滤后的样本参数对初始模型进行神经网络迭代训练，其中本申请实施例不对具体迭代训练的方法做过多限定，可由技术人员自行设定。

作为本申请的一个可选实施例，为了提升基础模型对室内场景和室外场景分类的准确度，本申请实施例中样本参数在包含卫星信号的特征参数的基础上，还同时参考了卫星信号特征参数以外的辅助特征参数。其中，辅助特征参数具体包含的参数内容可由技术人员设定。例如在一些可选实施例中，可以包含：基站信号、WiFi信号以及磁场信号中，任意一种或多种信号的特征参数，如可以包含基站信号强度、WiFi信号强度以及磁场信号强度中的任意参数。作为本申请的一个可选实施例，辅助特征参数内可以包含一些不具备地域特性的数据，例如WiFi信号强度和磁场信号强度等。

作为本申请的一个可选实施例，可以使用决策级融合的方式，采用集成学习（Ensemble learning）方法来进行初始模型的迭代训练，将卫星信号的特征参数以及各个辅助特征参数进行加权融合学习，以得到所需的基础模型。其中，具体的集成学习方法此处不做过多限定，可由技术人员选定，例如可以使用的集成学习方法包括但不限于如：Stacking、boosting、bagging、blending以及随机森林等类型的集成学习融合方案。

作为本申请的一个可选实施例，考虑到相对卫星信号的特征参数而言，辅助特征参数精度往往较差，对于室内场景和室外场景分辨能力相对较弱。因此在利用集成学习方法来进行迭代训练的过程前，初始模型中本申请实施例可以针对卫星信号的特征参数和辅助特征参数分别构建基分类器。在此基础上，可以为各个基分类器分别设置对应的融合系数，且卫星信号特征参数对应的基分类器的融合系数（亦可称为第一融合系数），大于辅助特征参数对应的基分类器的融合系数（亦可称为第二融合系数）。其中辅助特征参数可以作为一个整体构建一个基分类器，亦可以为辅助特征参数差分为多组参数，并为每组参数分别构建对应的基分类器，此时每组参数中可以包含一项或多项参数。以一实例进行举例说明，可以参考图2C，是本申请实施例提供的一种模型训练过程中，基分类器构建及融合的架构示意图。在本申请实施例中，针对卫星信号特征参数构建了一个基分类器（即强模态分类器）。同时将辅助特征参数划分为Q2组，并为每组参数设置了对应的基分类器（即弱模态分类器1至弱模态分类器Q2），且采用Stacking集成学习融合方案。在本申请实施例中，Q2为大于或等于1的正整数。

基于图2C，本申请实施例中基础模型最终的元（Meta）分类器的分类结果P_final可以表示为：

P_final=Meta（k₀×P_GNSS，k₁×P₁，... k_n2×P_n2...，k_Q2×P_Q2）（1）

其中，P_GNSS为强模态分类器的分类结果，P₁至P_Q2分别为弱模态分类器1至弱模态分类器Q2的分类结果，k₀为强模态分类器的融合系数，k₁至k_Q2分别为弱模态分类器1至弱模态分类器Q2的融合系数，k₁至k_Q2均小于k₀，其中n2为大于或等于1且小于或等于Q2的正整数。其中，强模态分类器和各个弱模态分类器的分类结果，均是输出对室内场景和室外场景的判定概率。

由图2C及上述表达式（1）可知，在申请实施例中，先由强模态分类器和各个弱模态分类器对卫星信号特征参数和辅助特征参数进行分类，得到对应的多个判定概率。再以强模态分类器以及所有弱模态分类器的分类结果组成的评定概率矩阵输入值最终的元分类器，由元分类器进行最终的分类处理。由于任意k_n2均小于k₀，因此元分类器在进行室内场景和室外场景的分类处理时，强模态分类器分类结果的影响最大，从而实现参数多模态融合。即在主要参考卫星信号特征参数的基础上，同时参考辅助特征参数的效果，提升最终分类结果的准确性。其中，本申请实施例不对元分类器的类型做过多限定，可以技术人员设定，例如可以使用逻辑（logistic）回归分类器等分类器作为本申请实施例中元分类器。

S2023，在对初始模型迭代训练的过程中，防早停过拟合模块对损失函数值进行检测，并在检测到损失函数值稳定性较高时停止训练，从而得到训练完成的基础模型。

考虑到实际应用中，对初始模型进行训练时所使用到的样本参数的数据量往往较大。因此进行迭代训练时可能会出现收敛速度异常的情况，例如可能会出现过早停止收敛（EarlyStopping）或过度拟合收敛时间过久（即早停和过拟合）的情况。而无论是早停还是过拟合，都会导致训练效果下降，使得得到的基础模型准确率下降。为了解决这一问题，在本申请实施例中，设计了一个防早停过拟合的步骤。具体而言，本申请实施例将损失函数值稳定性较高作为一个收敛条件。在S2022进行迭代训练的过程中，本申请实施例会持续监测每次迭代过程对应的损失函数值（loss）情况，在损失函数值较为稳定性（即满足预设条件时），说明继续进行迭代训练的效果较为有限。因此，此时判定为满足收敛条件停止训练，从而得到训练完成的基础模型。

作为本申请的一个可选实施例，对损失函数值稳定性较高的判定方法可以包括：

1、连续多次损失函数值差异值较小，此时说明损失函数值变化程度很小，稳定性较高。具体而言，可以设定一个差异阈值，并在每次得到损失函数值时计算当前损失函数值与前一次损失函数值的差值。此时预设条件为：若连续h1次差值均小于差异阈值，可以判定为损失函数值稳定性较高，停止训练。

2、连续多次损失函数值均没有下降，此时说明继续迭代训练对基础模型的准确性提升效果较为有限。具体而言，可以在每次得到损失函数值时，判断当前损失函数值是否小于前一次损失函数值的差值。此时预设条件为：若连续h2次判断结果均为当前损失函数值大于或等于前一次损失函数值，则可以判定为损失函数值稳定性较高，停止训练。

其中，h1为任意正整数，h2为任意正整数，具体可由技术人员设定大小。

本申请实施例通过设置对损失函数值稳定性相关的收敛条件，可以有效控制收敛速度，防止出现过早停止收敛或过度拟合收敛时间过久的情况。从而提升对识别模型的训练效果，提高最终识别模型的准确性。

在经由上述图2A至图2C所示实施例的操作后，本申请实施例可以得到针对单个地区内单种天气类型的基础模型。实际应用中，技术人员可以根据实际选定的地区数量以及天气类型数的需求，来实施图2A至图2C所示实施例。基于此，本申请实施例可以得到多个基础模型，每个基础模型均标记有对应的地区标签和天气类型标签。以下将对基础模型标记的标签统称为特征标签。

作为本申请的一个可选实施例，在将损失函数值稳定性较高作为收敛条件的同时，本申请实施例中还可以包含其他收敛条件。例如，可以设置一个针对损失函数值的损失阈值，并将损失函数值达到损失阈值作为收敛条件之一。本申请实施例在初始模型进行迭代训练的过程中，满足任意收敛条件，均可以停止训练，从而得到训练完成的基础模型。

作为本申请的一个可选实施例，初始模型亦可以选择逻辑回归（LogisticRegression）分类模型，在此基础上进行模型训练，得到的基础模型为可用于分类的逻辑回归模型。

作为本申请的另一个可选实施例，在得到基础模型的基础上，本申请实施例还可以对这些基础模型进行一次或多次更新，以持续维持基础模型的准确性。

在本申请实施例中，模型包含初始模型、基础模型以及更新后的基础模型，其中基础模型是指对初始模型进行迭代训练后得到的，可用于进行室内场景和室外场景的分类模型。更新后的基础模型是指基于新的参数对基础模型进行更新训练后得到的模型。在本申请实施例中，又将基础模型和更新后的基础模型统称为识别模型。

应当理解地，在进行初始模型的训练过程，以及对基础模型的更新训练过程中，亦可以不进行S2021数据过滤的操作。此时S202可以被替换为：S2022至S2023。此时S2022亦可以适应性的修改为：机器学习模块基于样本参数对预先构建的初始模型进行迭代训练。

作为本申请的一个实施例，为了验证不同地区之间基础模型的适用度情况，本申请实施例先针对某一目标地区构建对应的基础模型，再利用该基础模型来处理另一地区（可称为待验证地区）的样本数据。可以参考图2D，是本申请实施例提供的基础模型跨地区应用的各项指标情况示意图。其中，以城市为单位进行地理位置划分，因此每个地区对应一个城市。

对图2D中的几个指标进行说明如下：

准确率：是指样本数据识别正确的次数占所有样本份数的比例。

召回率（recall）：是指针对单类样本数据，该类样本数据识别正确的次数占实际该类样本数据份数的比例。

精确率（precision）：是指针对单类样本数据，该类样本数据识别正确的次数，占预测结果为该类样本数据的总次数的比例。

以一实例进行示例说明，假设某城市待验证的样本数据份数共为100，其中正样本份数和负样本均为50，正样本是指实际场景为室外场景的样本数据，负样本是指实际场景为室内场景的样本数据。假设基础模型在对100份样本数据进行实际场景识别后结果情况如下：

50份正样本中，识别结果为室外场景（即识别正确）的共20份，识别结果为室内场景（即识别错误）的共30份。

50份负样本中，识别结果为室内场景的共49份，识别结果为室外场景的共1份。

基于上述结果情况可以得到如下数据：

准确率=（20+49）÷100=0.69；

室外场景的召回率=20÷50=0.4；

室外场景的精确率=20÷（20+1）=0.95；

室内场景的召回率=49÷50=0.98；

室内场景的精确率=49÷（49+30）=0.62。

由图2D的指标情况可知，针对某一地区构建的基础模型直接移用到其他地区时，由于地理位置的差异性，很有可能会导致基础模型在新地区的准确性下降，即基础模型跨地区的适用度较弱。基于此，针对不同地理位置进行对应的基础模型构建，可以极大地提升实际应用中基础模型对所属地理位置处实际场景识别的准确性，从而提高对实际场景的识别准确性。

在完成基础模型构建，或者完成对基础模型更新的基础上，本申请实施例可以进入阶段二：实际场景识别阶段。

同时，若技术人员选择针对不同业务场景进行区分建模，则理论上可以得到不同业务场景对应的多个识别模型。其中每个业务场景，均对应有不同地区不同天气类型下的多个识别模型，以应对该业务场景下，对不同地区不同天气下的实际场景识别。且当多个业务场景选择统一建模时，则这些统一建模的业务场景所对应的识别模型可以完全相同。

以一实例进行示例说明，假设技术人员选择针对业务场景A、业务场景B和业务场景C统一建模。此时技术人员可以将业务场景A、业务场景B和业务场景C视为一个对象，采用上述基础模型训练阶段的方法进行不同地区不同天气类型下的建模，从而得到多个可用的识别模型。此时所得到的所有识别模型，可通用于业务场景A、业务场景B和业务场景C。

阶段二：实际场景识别。

在本申请实施例中，实际场景识别阶段亦可以细分为：触发阶段和识别阶段。其中，触发阶段主要用于检测终端设备是否处于特定的业务场景，并触发终端设备进入识别阶段。识别阶段则主要用于针对业务场景进行实际场景识别。详述如下：

触发阶段：

考虑到实际应用中终端设备有着严格的功耗控制需求，且室内场景和室外场景切换，也仅是用户日常的一种生活场景。因此为了降低本申请实施例对终端设备带来的功耗，同时也为了可以在针对不同业务场景进行了区分建模的情况下，及时区分不同业务场景的实际场景识别需求，提高对业务场景的适配性以及对实际场景识别的准确性。作为本申请的一个实施例，针对业务场景可以设计对应的场景识别方法的触发条件。即终端设备在运行过程中，当检测到满足触发条件时，则进入识别阶段，开启实际场景识别阶段中的场景识别方法。

作为本申请的一个实施例，考虑到业务场景往往都具有一定的地域特性。因此对于触发条件而言，可以选取一些与业务场景相关的具有一定地域特性的数据（以下称为目标数据），例如业务场景一定范围内拥有的一些信号数据等，并设置目标数据对应的识别方案。在此基础上，终端设备可以在检测到目标数据时，使用对应预设的识别方案进行处理，以识别当前是否为对应的业务场景（以下称为目标业务场景）。当识别出是对应的业务场景时，则可以判定为满足触发条件，并开始进行实际场景识别。其中，本申请实施例不对目标数据内包含的具体内容做过多限定，可由技术人员设定。例如在一些可选实施例中，可以将业务场景周围的基站信号和/或WiFi信号作为目标数据。

以一实例进行示例说明，例如对于进出地铁站的业务场景而言，可以设置目标数据包括：地铁基站信号和地铁WiFi信号。相应的识别方案可以设置为：检测到特定的地铁站周围的地铁基站信号以及特定的地铁WiFi信号（以下称为目标地铁基站信号和目标地铁WiFi信号）时，判定为当前为进出地铁站的业务场景。也可以设定为检测到目标基站信号和目标地铁WiFi信号，且目标地铁基站信号和目标地铁WiFi信号强度达到各自对应的强度阈值时，判定为当前为进出地铁站的业务场景。或者亦可以设置为其他识别方案，此处不做限定。在此基础上，终端设备在检测到目标地铁基站信号和目标地铁WiFi信号时，利用对应的识别方案识别当前是否为进出地铁站的业务场景。若是进出地铁站的业务场景，则满足触发条件，开始针对进出地铁站的实际场景识别。

作为本申请的一个实施例，可以参考图3A，是本申请实施例提供的一种进出地铁站的业务场景中触发条件的场景示意图。在本申请实施例中，终端设备在检测到特定的地铁基站信号和地铁WiFi信号时，则可以判定为满足触发条件，开始针对进出地铁站的实际场景识别。

以另一实例进行示例说明，又例如对于进出商场的业务场景而言，可以设置目标数据包括：商场WiFi信号。相应的识别方案可以设置为：检测到特定的商场WiFi信号（以下称为目标商场WiFi信号），判定为当前为进出商场的业务场景。也可以设定为检测到目标商场WiFi信号，且目标商场WiFi信号强度达到对应的强度阈值时，判定为当前为进出商场的业务场景。或者亦可以设置为其他识别方案，此处不做限定。在此基础上，终端设备在检测到目标商场WiFi信号时，利用对应的识别方案识别当前是否为进出商场的业务场景。若是进出商场的业务场景，则满足触发条件，开始针对进出商场的实际场景识别。

以上实施例在进行WiFi信号识别时，可以预先设置好包含多种WiFi信号的WiFi指纹库，以用于识别当前搜索到的WiFi信号具体属于何种类型的WiFi信号，如是属于地铁WiFi信号还是属于商场WiFi信号等。

由上述说明可知，终端设备中可以设置一个或多个触发条件，每个触发条件可以对应着一个或多个业务场景。从而使得终端设备可以在满足触发条件时，将该被满足的触发条件对应的业务场景作为自身当前所处的业务场景，从而第一时间确定出即目标业务场景。

在本申请实施例中，通过设置触发条件来开启（亦可称为使能或触发）实际场景识别阶段中的场景识别方法，一方面，可以避免实际应用中持续识别实际场景所带来的高功耗问题，从而降低本申请实施例对终端设备带来的功耗。另一方面，当针对不同业务场景区分设置识别模型时，本申请实施例可以有效识别出当前业务场景，以为后续识别模型的选取提供依据。由于不同识别模型所适配的业务场景可能会有所区别，因此本申请实施例可以有效提高对业务场景的适配性，从而提高对具体业务场景下的实际场景识别准确性。

作为本申请的一个实施例，触发阶段可以描述为：终端设备监测是否满足预设的触发条件，并在满足触发条件时，确定终端设备当前所处的目标业务场景。或者亦可以描述为：终端设备在满足预设的触发条件时，确定当前自身所处的目标业务场景。

识别阶段：

可以参考图3B，示出了本申请实施例提供的识别阶段中场景识别方法的实现流程图，详述如下：

S300，终端设备确定当前业务场景对应的前置条件，并监测是否满足前置条件。

其中，在通过触发条件触发S300的操作时，当前业务场景即为目标业务场景。

实际应用中，用户处于业务场景中也不一定会在室内室外之间进行切换，例如用户可能只是路过业务场景而已。因此若在识别出当前业务场景的基础上直接进行基础数据（基础数据是用于识别实际场景所需的数据）的采集，并进行实际场景的识别。一方面，若用户只是路过业务场景而不需要进行室内室外的切换，则会导致此时的数据采集和实际场景识别失去意义，因此导致对终端设备功耗的浪费。另一方面，即使用户需要进行室内室外的切换，用户在刚处于业务场景内时，终端设备采集的基础数据大概率还是用户进入实际场景前的数据。因此基于过早采集得到的基础数据进行识别，会导致识别结果大概率仍是用户进入实际场景前所处的场景。例如在进出地铁站的业务场景中，假设用户需要从地铁站外走进地铁站内。若在通过触发条件识别出业务场景时就进行基础数据的采集，此时采集到的基础数据大概率是用户处于地铁站外时的数据。因此基于这些数据识别的结果大概率为室外场景，这与用户实际所需进入的地铁站内（室内场景）不符。

基于上述实际情况，为了提高对基础数据采集时机的准确性与合理性，以减少本申请实施例对终端设备的功耗，同时提高对实际场景识别的准确性。在本申请实施例中，首先由技术人员针对不同业务场景下用户对终端设备的使用情况（即用户的行为）进行分析，确定出不同业务场景下，用户若需要进行室内室外切换，对应可能会出现的一些用户行为。在此基础上，可以为针对这些用户行为导致的终端设备可能出现的一些变化，设置对应的检测条件，并将这些检测条件称为前置条件。当满足这些前置条件时，说明用户有一定概率需要进入或者已经进入了实际场景内。其中，由于不同业务场景下用户行为情况的不同，本申请实施例不对各个业务场景对应的具体前置条件内容做过多限定，可由技术人员设定。例如，以进出地铁站的业务场景为例，用户利用终端设备乘坐地铁的话，进出地铁站闸机需要打开终端设备的乘车码，此时用户需要进行翻腕动作。因此作为本申请的一个可选实施例，可以将终端设备翻腕动作和/或打开乘车码作为前置条件。

在确定出当前业务场景后，终端设备可以先匹配出当前业务场景对应的前置条件内容，并开始对前置条件的监测，以确定是否需要开始数据采集工作。其中应当说明地，若终端设备内仅设置了单种前置条件，即所有业务场景共用一种前置条件时，则可不进行前置条件的匹配操作。

S301，当满足前置条件时，终端设备获取所处的当前场景。其中当前场景为室内场景或室外场景。

实际应用中发现，在用户从室外场景进入室内场景的情况（以下称为第一类情况）和从室内场景进入室外场景的情况（以下称为第二类情况）中，存在一定的用户行为差别。对于从室外场景进入室内场景的第一类情况而言，用户一般会在差不多进入到室内场景或者已经进入室内场景后触发前置条件。而在从室内场景进入室外场景的第二类情况中，用户则一般会在到达室外场景之前提前一些做准备，因此导致前置条件较早被触发。仍以进出地铁站的业务场景为例进行举例说明，实际应用中，用户往往在差不多进入到地铁站或者已经进入到地铁站后打开终端设备的乘车码，从而触发前置条件。而在出地铁站时，由于地铁站闸机一般会安装在地铁站内，因此用户需要在地铁站内时打开终端设备的乘车码，从而触发前置条件。同理，对于与进出地铁站类似的，需要利用特定设备进行用户身份验证或者出入控制的业务场景中，一般这些特定设备都是安装在室内场景中。因此在将终端设备对这些设备的资料准备操作来作为前置条件内容时，对于第一类情况，用户往往会在进入到室内场景中时触发前置条件。而对于第二类情况，用户则经常先在室内场景中触发前置条件，再出到室外场景中。

为了适应第一类情况和第二类情况中的用户行为差异，本申请实施例针对第一类情况和第二类情况各自的特点设置了对应的基础数据采集方案。在此基础上，在检测到满足前置条件后，终端设备先确认自身当前所处的是室内场景还是室外场景，以确定出当前是可能是第一类情况还是第二类情况，再针对两类情况进行区分处理。其中，本申请实施例不对当前场景的获取方式做过多限定，可由技术人员自行设定。

作为本申请中确定当前场景的一个可选实施例，对当前场景的确定可分为两种情况：

1、用户在当前业务场景内已经进行过至少一次室内室外的切换。此时在当前业务场景中，终端设备已有历史对实际场景的识别结果，在这种情况下，本申请实施例可以将最近一次识别出的实际场景作为当前场景。例如假设在进出地铁站的业务场景中，用户已经从室外场景走进了地铁站内，此时终端设备已经有了一个实际场景为室内场景的识别结果。在此基础上，当前置条件再次被触发时，终端设备可以将室内场景作为终端设备所处的当前场景。

2、用户刚进入当前业务场景内，终端设备尚未进行过室内室外的切换。此时在当前业务场景中，终端设备尚未有对实际场景的识别结果。此时终端设备可以使用自身已有的一些传感器来进行环境数据检测并进行当前场景的粗识别，亦可以根据终端设备的运动轨迹来进行粗识别。例如，在满足前置条件时，终端设备可以获取自身最近一段时间（亦可称为预设时长）内的运动轨迹。若运动轨迹均在室外场景，且向业务场景方向移动，则可以判定为当前场景为室外场景。若最近一段时间的运动轨迹在室内场景，则可以判定为当前场景为室内场景。其中，预设时长具体的值此处不做限定，可由技术人员自行设定，例如可以设定为30秒至3分钟内的任意值。

应当理解地，实际应用中前置条件不是必须的，即在识别出当前业务场景后，终端设备可以不进行前置条件的监测并确定所处的当前场景。此时S300和S301可以被替换为：终端设备获取所处的当前场景。

S302，若当前场景为室外场景，终端设备进行光强检测。

当前置条件被触发且当前场景为室外场景时，说明用户当前有极大概率是从室外场景进入室内场景的第一类情况，此时需要开始针对用户是否进入室内场景的识别。理论上此时可以进行基础数据的采集，但实际应用中发现，若此时直接进行基础数据采集，可能会由于以下一些因素导致直接采集到基础数据内存在大量的脏数据（即可信度较低的数据）：

因素1、对前置条件误检测。

实际应用中，在前置条件内容已知的情况下，终端设备在检测是否满足前置条件时，仍有一定可能会将不满足前置条件的情况误检测为满足前置条件。例如，假设前置条件为：翻腕动作。实际应用中，终端设备有一定概率会将用户的一些非翻腕动作误识别为翻腕动作，从而判定为满足前置条件。

在对前置条件误检测的情况下开始后续的当前场景确定、光强检测直至基础数据采集，会导致直接采集到的基础数据可信度较低，即采集到的为脏数据。

因素2、用户在使用终端设备过程中误触发前置条件。

实际应用中，用户在进行室内室外切换的过程之外，也有可能会触发前置条件。例如，假设前置条件为：翻腕动作。实际应用中，用户在进入实际场景之前也有可能会习惯性的翻腕。例如用户进入实际场景之前，在手持终端设备一段时间之后为了缓解手腕疲劳，可能会手持着终端设备做出翻腕动作。因此实际应用中，即使检测到了前置条件，也有一定可能用户当时并未准备进入或者已经进入实际场景。导致终端设备有一定可能会因此采集到可信度较低基础数据，即采集到脏数据。

因素3、前置条件触发时，用户可能并未进入实际场景。

实际应用中，在前置条件被触发时，终端设备仍无法确定用户在第一类情况中所处的实时状态，例如无法确定用户实时状态是在室外场景，还是即将进入或者已经进入室内场景。且终端设备对前置条件的识别以及对当前场景的确认操作耗时极短，例如耗时可能处于毫秒级，在这个耗时情况下用户移动的位移量往往可以忽略不计。因此前置条件被触发并确定出当前场景后，若直接进行基础数据的采集，有较大概率采集到的是用户进入实际场景前的数据。例如用户可能只是走到室内场景中一些对信号遮蔽度较低的灰度区域，此时若进行基础数据采集，所采集到的基础数据不具有典型性，因此数据的有效性较低。

为了提高所采集的基础数据的有效性，减少采集到脏数据的情况，本申请实施例在确定出当前场景为室外场景时，首先会进行光强检测，并利用检测到的光强值来对用户实时状态进行粗识别。考虑到实际生活中，室内场景和室外场景的光强往往具有较大差别。例如室外场景中光源一般是自然光，其光强值往往较高。例如实测中室外光强值一般可以达到数千至上万勒克斯（lux），即使是阴雨天气，一般也可以达到800~1000lux左右水平。而对于室内场景其光源往往是灯光，其强度值往往较弱，例如常见的一些室内场景的光强值往往只有数百勒克斯。因此在实际应用中，光强值大小可以作为对用户实时状态的一种粗识别依据。

基于这一实际情况，本申请实施例在确定出用户处于第一类情况时，不是直接进行基础数据采集，而是进行光强检测以确定用户的实时状态。同时，本申请实施例还针对光强值设置了对应的强度阈值，以用于区分用户不同的实时状态。

S303，当检测到光强值大于预设的强度阈值时，终端设备间隔预设时长后重新进行光强检测。

在本申请实施例中，当终端设备检测到的光强值大于强度阈值时，说明当前环境的光强较强，有较大可能用户仍处于室外场景中。此时本申请实施例会间隔一段时间，再重新进行光强检测，从而实现对用户实时状态的持续监测。其中，本申请实施例不对间隔的预设时长具体值做过多限定，可由技术人员根据实际业务场景中情况设定。例如在一些实施例中，预设时长可以设置为N1分钟，其中N1为任意正数，例如N1可以是0.1至3中的任意值。

例如作为本申请的一个实施例，在进出地铁站的业务场景中，假设前置条件为：翻腕动作和/或打开乘车码。由于用户进行翻腕动作或打开乘车码时离地铁站闸机一般都不会太远，前置条件触发后用户可以较短时间内走进地铁站。因此此时的N1可以设置的较小，例如可以设置为1，此时终端设备会在1分钟后重新进行光强检测。

作为本申请的一个可选实施例，考虑到不同时间段和不同天气时，室外光强变化较大。因此为了提高强度阈值的有效性，以提高对实时状态检测的准确性，在本申请实施例可以针对不同时间段和不同天气设置不同的光强阈值。在得到当前环境的光强值后，再将其与当前时间段和当前天气对应的光强阈值进行比较。相应的，在S303之前还可以包括：终端设备获取当前时间段和当前天气下对应的光强阈值。

作为本申请的一个可选实施例，可以设置对用户实时状态的持续监测终止条件，即重复光强检测的终止条件，以控制本申请实施例对终端设备带来的功耗。在重复光强检测的过程中，若满足终止条件则停止进行光强检测。其中，本申请实施例不对终止条件内容做过多限定，可由技术人设定。例如在一些可选实施例中，可以设定重复光强检测的总次数上限值和总时长上限值，在S303重复光强检测的过程中，若重复的次数达到总次数上限值，或者光强检测的总时长达到总时长上限值，则停止光强检测。

S304，当检测到光强值小于或等于预设的强度阈值时，终端设备进行多次基础数据采集。

当终端设备检测到的光强值小于或等于强度阈值时，说明当前环境的光强较弱，有较大可能用户即将进入或者已经进入了室内场景中。此时本申请实施例开始进行基础数据采集。在本申请实施例中，基础数据中包含卫星信号的特征参数。在此基础上，所需采集的基础数据亦可以包含一些卫星信号特征参数以外的其他数据（即辅助特征参数），具体包含的负载特征数据参数，可由技术人员自行设定选取。

作为本申请的一个实施例，卫星信号的特征参数可以为卫星信号的统计学特征参数。其中统计学特征参数包括但不限于如：卫星信号强度比例、最大信噪比、最小信噪比、信噪比标准差、信噪比中位数、信噪比极差、去零平均信噪比以及含零平均信噪比中的任意一种或多种。

作为本申请的一个实施例，辅助特征参数包括但不限于如：WiFi信号强度以及磁场信号强度中的任意一种或多种。

在进行基础数据采集时，可能会由于以下一些因素导致基础数据存在脏数据或者存在数据不完整的情况：

因素1、对用户的实时状态误识别。

由上述对光强检测的说明可知，本申请实施例中光强检测是为了可以对用户实时状态进行粗识别。实际应用中发现，一些业务场景的室内场景和室外场景之间可能会存在光线灰度区域。在光线灰度区域内对室外光线的遮蔽度较差，即遮光性较差，因此光线灰度区域内的光强值可能会高于、等于或者低于强度阈值，从而导致终端设备在光线灰度区域内难以准确识别用户实时状态，使得终端设备可能会错误识别实时状态。以进出地铁站的业务场景为例，在地铁站的入口区域对室外光线的遮蔽效果一般较差，在入口区域内的光强值往往会受到室外光线的影响，因此可能会高于、等于或者低于强度阈值。因此当用户处于地铁站入口区域内时，终端设备有可能会误识别为即将进入或者已经进入室内场景（当前场景为室内场景时，则有可能误识别为即将进入或者已经进入室外场景）。

当终端设备在光线灰度区域误识别用户实时状态并开始采集基础数据时，终端设备采集的基础数据会同时受到室内场景和室外场景的影响，因此基础数据的可信度会有所下降。即采集到的基础数据中包含一定的脏数据。

因素2、搜星器处于冷启动状态，搜索到的卫星信号的数据不完整。

在进行基础数据采集时，终端设备需要启动并使用搜星器进行卫星信号的搜索，其中搜星器启动可分为：冷启动、温启动和热启动。实际应用中发现，搜星器经常会处于冷启动的状态。在冷启动的状态下，由于搜星器清理了历史消息或者存储历史消息与当前实际的导航卫星情况差异较大，导致搜星器难以正常进行卫星信号的搜索，此时搜索到的卫星信号往往是不完整的。因此难以获取到当前时刻卫星信号特征数据，例如卫星信号的信噪比数据等，如信噪比强度。以一实例进行说明，可以参考图4A，是本申请实施例提供的终端设备进行卫星信号搜索的一种场景示意图。假设终端设备内搜星器理论上当前可搜索的到的导航卫星数量为H，其中H为大于1的正整数。当搜星器处于冷启动时，可能仅能搜索到H个导航卫星中少部分导航卫星的卫星信号，例如可能今年搜索到一两个导航卫星的卫星信号。而在温启动或者热启动的状态下，搜星器则能搜索到完整的或者相对较为完整的卫星信号。

由于卫星信号的特征参数是基础数据的核心数据，因此若卫星信号本身数据不完整甚至非常少的情况下，会导致基础数据的有效性大大降低。

实际应用中，亦有可能存在上述因素以外的其他因素，导致刚开始采集到的基础数据内存在脏数据或者存在数据缺失等情况。终端设备若基于这些基础数据来进行实际场景的识别，所得到的识别结果准确性会受到较大影响。为了应对这些因素的影响，本申请实施例在需要采集基础数据时，会进行多次基础数据采集。其中每次采集均会间隔一定的时长（即相邻两次采集操作的间隔时长大于0），从而将采集的过程延长，为用户和搜星器提供更多的缓冲时间。使得用户有较多时间可以走入实际场景，同时也使得搜星器用充足的时间完成冷启动，进入正常的工作状态（搜星器在冷启动完成后，一段时间内再次启动均为热启动状态），搜索到完整的或者相对较为完整的卫星信号。

其中，本申请实施例不对每次采集的间隔时长，以及每次采集基础数据的重复次数做过多限定，可由技术人员自行设定。例如在一些实施例中，多次基础数据采集中每次采集的间隔时长可以设置为与S303中光强检测的间隔时长相同，即为N1分钟。而在另一些实施例中，每次采集的间隔时长亦可以设置为N2分钟，其中N2任意正数。考虑到实际应用中搜星器完成冷启动状态所需的时间一般在40秒至1分钟左右，因此可以将N2设置为大于或等于1的任意正数。作为本申请的一个可选实施例，将每次采集基础数据的重复次数设为K1。考虑到实际应用中，K1值越大，理论上所采集到的基础数据可信度以及完整度越高，但同时本申请实施例对终端设备造成的功耗越大。因此为了在提高基础数据可信度和完整性的基础上，平衡本申请实施例基础数据采集对终端设备造成的功耗，在本申请实施例中，可以设置为K1与N2分钟的乘积大于或等于M分钟。其中，M分钟为搜星器冷启动所需的时长，即在本申请实施例中每次重复采集基础数据的过程持续时长大于或等于搜星器冷启动所需的时长。作为本申请的另一个实施例，K1可以设置为2至5中任意整数，如可以设置为2或者3。

作为本申请的一个具体实施例，可以参考图4B，是本申请实施例提供的一种针对用户当前处于室外场景时，对基础数据采集的流程示意图。在本申请实施例中，S300至S304可以被替换为：

终端设备监测是否满足前置条件，若满足前置条件则执行光强检测的步骤。

终端设备进行光强检测。

当检测到的光强值大于强度阈值时，终端设备间隔N1分钟后，返回执行光强检测的操作，即再次进行光强检测。

当检测到的光强值小于或等于强度阈值时，开始采集K1次基础数据，其中每次采集操作的间隔时长为N2分钟。即每次采集基础数据后判断已采集的次数是否小于K2，若小于则在间隔N2分钟后，再进行下一次的基础数据采集。

其中，N1和N2均为任意正数，K1为大于1的任意正整数。

本申请实施例相关的实现细节、实现原理以及有益效果等，均可以参考S300至S304中的相关说明，此处不予赘述。

S305，终端设备利用识别模型对最后一次采集到的基础数据进行处理，得到当次的分类结果。

理论上采集的时间越靠后，用户进入实际场景的概率越大，且搜星器冷启动完成的概率越大，因此相应采集到的基础数据的可信度和完整性也越高。基于此，本申请实施例在对基础数据进行多次采集后，将最后一次采集到的基础数据作为实际场景识别所使用的数据。其中应当理解地，假设预设每次采集基础数据的重复次数为K1，实际应用中，可能会由于一些已知或未知的原因导致终端设备可能无法正常采集到K1次，此时本申请实施例仍使用最新采集到的基础数据。例如假设K1=3，但实际应用中由于一些原因，如搜星器出现故障，导致在第2次采集后就停止了采集，此时本申请实施例可以使用第2次采集到的基础数据。即在本申请实施例中，使用最后一次采集到的基础数据，而非限定必须使用第K1次采集的基础数据。

在确定出最后一次采集到的基础数据的情况下，终端设备可以开始对实际场景的识别。由阶段一：基础模型训练的说明可知，本申请实施例预先训练好的识别模型理论上可以直接用于识别实际场景。但实际应用中，无论如何训练基础模型或更新基础模型，所得到的识别模型仍会有一定的误识别可能。为了提高最终识别结果的准确性，本申请实施例在确定出最后一次采集到的基础数据后，首先将该基础数据输入对应的识别模型。在经由识别模型处理后得到一个对应的分类结果，该分类结果为室内场景和室外场景中的一种。在得到分类结果后，本申请实施例并不进行识别结果的直接判定，而是将该分类结果作为参考对象，进行下一步的处理。

作为本申请的一个可选实施例，在使用最后一次采集到的基础数据进行分类的基础上，亦可以同时使用更多的基础数据进行分类。例如在一些实施例中，也可以选用最新采集的多次基础数据来进行分类，此时可以将这些选用的基础数据作为一个整体输入识别模型。相应的，此时S305可以被替换为：终端设备利用识别模型对采集到的基础数据进行处理，得到当次的分类结果。

其中应当特别说明地，在对基础数据进行处理前需要先获取所需使用的识别模型。其中，对识别模型的获取操作包括：

S000、终端设备获取当前所处的地区以及天气类型，并获取当前业务场景下，与当前地区和当前天气类型对应的识别模型。

首先对S000的执行时机进行说明，理论上在S305等需要使用识别模型的操作之前的任意时机，均可执行S000获取识别模型，以使得本申请实施例可以正常使用识别模型。例如，对于S305而言，本申请实施例可以在S300之前，或者在S300至S305之间的任意位置处执行S000。

对S000的实现细节进行说明：

由阶段一：基础模型训练的说明可知，本申请实施例可以针对不同有业务场景、不同地区以及不同天气类型预先构建好不同的识别模型。因此，本申请实施例在确定好当前业务场景后，终端设备首先要获取自身所处的地区以及该地区当前的天气情况。再基于自身当前业务场景、所处地区以及该地区当前天气所属的天气类型，来匹配出适宜的识别模型。其中不对终端设备获取自身所在地区以及该地区当前天气类型的方式做过多限定，可由技术人员自行设定。例如，终端设备可以通过地域定位信息接口来获取自身的位置信息，从而确定出所在地区，同时可以通过实时天气信息接口来联网获取所在地区的天气情况，从而确定出当前天气类型。

作为本申请的一个可选实施例，终端设备亦可以选择利用内置的一些环境传感器，来获取终端设备当前所处环境的一些环境参数，并根据这些环境参数来辅助识别当前地区的天气类型。例如可以使用终端设备内置的光强传感器、温度传感器和湿度传感器等环境传感器中的任意传感器来获取对应的环境参数（如光强值、温度值和湿度值等），并根据获取到的环境参数来识别天气类型。

作为本申请的另一个可选实施例，可以综合上述联网获取天气类型和环境传感器获取天气类型两种方案，以应对更多的实际情况需求。具体而言，终端设备在需要获取天气类型时，首先识别自身网络情况。若网络质量较好（如网络质量低于对应的质量阈值等），则通过联网获取天气类型。若网络质量较差，则环境传感器获取天气类型。

在确定出终端设备所处的当前业务场景、地区以及天气类型后，可以开始进行模型匹配。即从已有的识别模型中，查找出业务场景标签与当前业务场景匹配，地区标签与当前所处地区匹配，且天气类型标签与当前天气类型匹配的识别模型。从而得到在特定业务场景内，特定地区在特定天气类型下对应的识别模型。其中，S000中匹配出来的识别模型亦可称为目标识别模型。

作为本申请的一个可选实施例，若构建基础模型时未区分业务场景建模，S000对识别模型的获取操作亦可以修改为：终端设备确定当前所处的地区以及天气类型，并获取与当前地区和当前天气类型对应的识别模型。

相应的，若构建基础模型时未区分业务场景建模，终端设备在模型匹配时，可以不对识别模型的业务场景标签进行匹配。即在确定出终端设备当前所处的地区以及天气类型后，从已有的识别模型中，查找出地区标签与当前所处地区匹配，且天气类型标签与当前天气类型匹配的识别模型。从而得到在特定地区的特定天气类型下对应的识别模型。

同时，对本申请实施例中终端设备对识别模型的获取方式进行说明。在本申请实施例中，识别模型由服务器端进行基础模型建模或更新训练得到，在此基础上，终端设备若想使用识别模型，可以采用如下两种可选方式实现：

方式1：终端设备将识别模型提前下载至本地，在需要的时候，从本地存储的识别模型中进行模型匹配和使用。

在本地存储识别模型时，终端设备可以主动或被动的对存储的识别模型进行模型数据更新，以获取最新的识别模型。例如终端设备可以预设的频率主动从服务器下载最新的识别模型，并覆盖本地存储的识别模型，以更新识别模型。又例如，服务器可以主动将最新的识别模型推送至终端设备，终端设备在接收到新的识别模型后，覆盖本地存储的识别模型，以更新识别模型。

方式2：终端设备在需要匹配识别模型时，将当前地区和当前天气类型等数据发送至服务器，由服务器根据这些数据进行匹配，并将对应的识别模型下发至终端设备使用。

S306，根据当次分类结果，确定终端设备所进入的实际场景。其中，实际场景为室内场景或者室外场景。

作为本申请的一个可选实施例，考虑到实际应用中单次分类结果的可靠性会受到模型识别精度影响，同时还受到基础数据质量的影响，例如冷启动时采集的数据质量较差（可信度较低）等，从而使得单次分类结果可能存在一定的误识别情况。为了减少单次分类结果误识别对最终识别结果的影响，本申请实施例在得到当次分类结果后，终端设备获取最近得到的多次分类结果，并根据这些最近的分类结果（包含当次分类结果）来综合判定终端设备所进入的实际场景。从而降低单次分类结果误识别对最终实际场景识别结果的影响比重，提高最终实际场景识别结果的准确性。其中，本申请实施例不对具体使用的分类结果数量W（W可以为大于或等于2的任意整数，例如可以取W为2或3），以及对这些分类结果综合判定的方法做过多限定，可由技术人员自行设定。

作为本申请中进行综合判定的一个可选实施例，在本申请实施例中，可以使用投票法的方式来实现综合判定。具体而言，例如终端设备在得到当次分类结果后，获取最近得到的W-1次分类结果。在此基础上，可以将其中出现次数占总次数W的比值大于或等于预设比例阈值的分类结果作为识别结果。其中，比值阈值取值范围为：大于50%且小于或等于100%，在此基础上本申请实施例不对比例阈值具体大小做过多限定。

作为本申请的一个实施例，当比例阈值实际取值处于（50%，100%）之间时，综合判定方法亦可描述为：将最近得到的W次分类结果中，出现次数较多的分类结果确定为终端设备所进入的实际场景。

作为本申请的另一个可选实施例，当比例阈值实际取值为100%时，综合判定方法亦可描述为：若最近得到的W次分类结果均相同，则将W次分类结果中任一结果确定为终端设备所进入的实际场景。作为本申请另一可选实施例，若最近得到的W次分类结果不完全相同，则判定为此次对实际场景的识别失败，即没有识别出实际场景。

作为本申请的另一个可选实施例，亦可选择将当次分类结果作为对实际场景的识别结果。或者设置一些对分类结果进行验证或修正的方法，并将验证或修正后的分类结果作为对实际场景的识别结果。即在本申请实施例中，亦可以取W=1。此时S306可以替换为：将当次分类结果作为终端设备所进入的实际场景。

综合上述说明，实际应用中，可以使用最近得到的W次分类结果（包括当次分类结果）来判定实际场景的识别结果时所使用到的分类结果，其中W为任意正整数。

S307，若当前场景为室内场景，终端设备在延迟预设时长后进行光强检测。

当前置条件被触发且当前场景为室内场景时，说明用户当前有极大概率是室内场景进入室外场景的第二类情况，此时需要开始针对用户是否进入室外场景的识别。

S307的实现细节、原理以及有益效果等与S302基本相同，因此可以参考S302的相关说明，此处不予赘述。以下仅对S307与S302的差异之处进行说明如下：

由S301中的相关说明可知，对于第二类情况而言，实际应用中用户经常会先在室内场景中触发前置条件，再出到室外场景中。因此对于第二类情况，本申请实施例在前置条件被触发后没有直接进行光强检测，而是先选择延时一段时间再进行光强检测，以为用户提供一定的时间走出室内场景，从而加大光强检测时用户处于实际场景内的概率。其中，设延时的时长为N3分钟，N3为任意大于0的正数。N3的具体值可由技术人员根据业务场景的实际情况，此处不做限定。例如，对于进出地铁站的业务场景而言，考虑到用户冲闸机走出地铁站的实际情况，N3可以设置为1至10中的任意值。

作为本申请的一个可选实施例，在本申请实施例中，S302中终端设备亦可以延时一段时间再进行光强检测，以应对实际生活用户可能在进入室内场景之前的一段时间就触发了前置条件。此时S302可以被替换为：若当前场景为室外场景，终端设备在预设时长后进行光强检测。作为本申请的一个实施例，设此时延时的时长为N4，则可以设置N3大于或等于N4，以对第一类情况和第二类情况的差异化处理，尽可能地适应实际用户情况。

作为本申请的另一个可选实施例，对于第二类情况亦可以选择不进行延时触发光强检测，而是在满足前置条件后开始光强检测。此时S307可以被替换为：若当前场景为室内场景，终端设备进行光强检测。

S308，当检测到光强值小于或等于预设的强度阈值，则以预设时长为周期，进行循环光强检测，直至满足预设的终止条件。

当终端设备检测到的光强值小于强度阈值时，说明当前环境的光强较弱，有较大可能用户仍处于室内场景中。此时本申请实施例会以一定时长为间隔，周期性地进行循环光强检测，从而实现对用户实时状态的持续监测。其中，设单次间隔时长为N5分钟，N5为任意正数。

作为本申请的一个可选实施例，用户在从室内场景走出室外场景的过程中，终端设备周围的光线可能随时会发送变化。因此为了提高光强检测的时效性，以提高对用户实时状态检测的有效性，在本申请实施例中，N5可以设置的相对较小，例如可以设置为0到1中任意值，如可以设置为0.1至0.5中的任意值。

作为本申请的一个可选实施例，可以设置对用户实时状态的持续监测终止条件，即重复光强检测的终止条件，以控制本申请实施例对终端设备带来的功耗。在重复光强检测的过程中，若满足终止条件则停止进行光强检测。其中，本申请实施例不对终止条件内容做过多限定，可由技术人设定。例如在一些可选实施例中，可以设定重复光强检测的总次数上限值和总时长上限值，在S308周期性重复光强检测的过程中，若重复的次数达到总次数上限值，或者光强检测的总时长达到总时长上限值，则停止光强检测。

作为本申请的一个实施例，在周期性循环光强检测的过程中，若检测到光强值大于强度阈值，则执行S309的操作。此时终止条件包括：检测到光强值大于强度阈值。

作为本申请的一个可选实施例，考虑到不同时间段和不同天气时，室外光强变化较大。因此为了提高强度阈值的有效性，以提高对实时状态检测的准确性，在本申请实施例可以针对不同时间段和不同天气设置不同的光强阈值。在得到当前环境的光强值后，再将其与当前时间段和当前天气对应的光强阈值进行比较。相应的，在S308之前还可以包括：终端设备获取当前时间段和当前天气下对应的光强阈值。

此外，在本申请实施例中，第一类情况和第二类情况下所使用的强度阈值，可以相同或不同。本申请实施例亦可将第一类情况下使用的强度阈值称为第一强度阈值，将第二类情况下使用的强度阈值称为第二强度阈值。

S309，当检测到光强值大于强度阈值，终端设备进行多次基础数据采集。

当终端设备检测到的光强值大于强度阈值时，说明当前环境的光强较强，有较大可能用户即将进入或者已经进入了室外场景中。此时本申请实施例开始进行基础数据采集。

S309的实现细节、原理以及有益效果等与S304基本相同，因此可以参考S304的相关说明，此处不予赘述。以下仅对S309与S304的差异之处进行说明如下：

设S309多次基础数据采集中每次采集的间隔时长为N6分钟，每次采集基础数据的重复次数设为K2。一方面，N6的说明可以参考S304中对N2的相关说明，两者可以通用，此处不予赘述。K2的说明则可以参考S304中对K1的相关说明，两者可以通用，此处不予赘述。作为本申请的一个可选实施例，考虑到室内场景对卫星信号的遮蔽效果较强，用户在从室内走下室外的过程中，终端设备所能搜索到的卫星信号的变化情况较大。因此为了能够在用户从室内走出室外的过程中及时采集到有效的基础数据，在本申请实施例中可以将N6的值设置的相对较小。例如可以设置为0到1之间的任意值（设N7秒为N6分钟以秒为单位换算后的数据，此时可以设置间隔时长达到秒级）。作为本申请的一个可选实施例，N6可以设置为与S308循环光强检测的周期N5相同。

作为本申请的一个可选实施例，为了适配第一类情况和第二类情况下可搜索到卫星信号的变化情况，可以设置为N6小于或等于N2。

作为本申请的一个具体实施例，可以参考图4C，是本申请实施例提供的一种针对用户当前处于室内场景时，对基础数据采集的流程示意图。在本申请实施例中，S300、S301和S307至S309可以被替换为：

终端设备监测是否满足前置条件，若满足前置条件则在延时N3分钟后执行光强检测的步骤。

终端设备进行光强检测。

当检测到的光强值小于或等于强度阈值时，以N5分钟为周期进行循环光强检测，即每隔N5分钟进行一次光强检测的步骤。若在循环总时长达到预设的总时长上限值Tmax分钟时，终端设备仍没有检测到光强值达到强度阈值条件（即检测到的光强值大于强度阈值），则停止光强检测。

当检测到的光强值大于强度阈值时，开始采集K2次基础数据，其中每次采集操作的间隔时长为N7秒。即每次采集基础数据后判断已采集的次数是否小于K2，若小于则在间隔N7秒后，再进行下一次的基础数据采集。

其中，N5和N7均为任意正数，K2为大于1的任意正整数。

本申请实施例相关的实现细节、实现原理以及有益效果等，均可以参考S300至S309中的相关说明，此处不予赘述。

作为本申请的一个具体实施例，在图4C的基础上可以参考图4D，是本申请实施例提供的在进出地铁站的业务场景下，一种针对用户当前处于地铁站内时，对基础数据采集的细化流程示意图。

在本申请实施例中，S300、S301和S307至S309可以被替换为：

终端设备监测是否满足前置条件：翻腕动作，若检测到翻腕动作则在延时2分钟后执行光强检测的步骤。这延时的2分钟用于用户从地铁站内走出地铁站外耗时。

终端设备进行光强检测。

当检测到的光强值小于或等于强度阈值时，以20秒为周期进行循环光强检测，即每隔20秒进行一次光强检测的步骤。若在循环总时长达到预设的总时长上限值10分钟时，终端设备仍没有检测到光强值达到强度阈值条件（即检测到的光强值大于强度阈值），则停止光强检测。

当检测到的光强值大于强度阈值时，开始采集2次基础数据，其中每次采集操作的间隔时长为20秒。

本申请实施例相关的实现细节、实现原理以及有益效果等，均可以参考S300至S309中的相关说明，此处不予赘述。

S305，终端设备利用识别模型对多次采集的基础数据中最后一次采集的基础数据进行处理，得到分类结果。

S306，根据分类结果，确定终端设备所进入的实际场景。其中，实际场景为室内场景或者室外场景。

可参考上述对S305和S306的说明，此处不予赘述。

作为本申请的一个可选实施例，参考图5，是本申请实施例提供的一种场景识别方法中，进行场景分类的整体架构示意图，详述如下：

终端设备在满足触发条件时，开始进行实际场景识别。其中，触发条件可以为：检测到业务场景一定范围内特定的基站信号和WiFi信号，即检测到终端设备进入业务场景的基站和WiFi路由器覆盖范围。

终端设备通过地域定位信息接口获取自身所处的位置信息，并根据位置信息确定当前所处地区。

终端设备通过天气信息接口确定当前天气类型，或者通过温度传感器、湿度传感器和光线传感器确定识别天气类型。

终端设备根据当前地区和当前天气类型，从本地的多个集成学习模块中匹配出一个集成学习模块。其中，每个集成学习模块即为一个识别模型，识别模型内的分类器结构可使用图2C所示实施例的分类器架构。

终端设备采集基础数据，并将基础数据输入匹配出的集成学习模块，得到对应的分类结果。

本申请实施例相关的实现细节、实现原理以及有益效果等，均可以参考S300至S309中的相关说明，此处不予赘述。

相对前述的识别方案1和识别方案2，本申请实施例至少具有以下有益效果：

1、本申请实施例中的识别模型是针对不同地区和不同天气类型区分构建的神经网络模型。在实际使用时，终端设备可以根据实际所处的地区以及实时的天气类型，来选取最适宜的识别模型使用。因此本申请实施例可以高度化的适配终端设备的实时情况，不会受到用户地理位置和天气的限制，实现对用户实时情况的针对性实际场景识别，极大地提高的对实际场景识别的准确性。且基于神经网络模型的识别，可以避免直接基于参数大小进行场景识别导致识别结果过于粗糙的情况出现，从而提升识别准确性。

其中，若针对不同业务场景进行了区分建模，则在进行模型选取时可以同时结合用户实时业务场景来进行模型匹配。此时本申请实施例适配用户所处实际业务场景情况特点，因此可以提升对终端设备实时情况适配性，从而使得本申请实施例对实际场景识别的准确性更高。

2、本申请实施例通过设置触发条件，并在满足触发条件时使能对实际场景识别的整体方案，一方面，可以避免实际应用中持续识别实际场景所带来的高功耗问题，从而降低本申请实施例对终端设备带来的功耗。另一方面，当针对不同业务场景区分设置识别模型时，本申请实施例可以有效识别出当前业务场景，以为后续识别模型的选取提供依据。由于不同识别模型所适配的业务场景可能会有所区别，因此本申请实施例可以有效提高对业务场景的适配性，从而提高对具体业务场景下的实际场景识别准确性。

3、本申请实施例通过设置前置条件，来确定用户是否有进行室内室外切换的意图，并在确定出用户有进行室内室外切换意图（即满足前置条件）时，开始进入基础数据采集流程。此时可以减少甚至避免在用户没有室内室外切换意图时的基础数据采集工作。因此本申请实施例可以有效提高对基础数据采集时机的准确性与合理性，减少对终端设备的功耗，同时提高对实际场景识别的准确性。

4、针对从室外场景进入室内场景的情况（即第一类情况）和从室内场景进入室外场景的情况（即第二类情况），本申请实施例根据两类情况各自的特点设置了对应的基础数据采集方案。例如针对第二类情况，在正式采集基础数据前可以先进行一定的时延，以为用户走出室内场景提供时间。因此本申请实施例可以更好地适应用户真实的为规律来，并确定对基础数据的采集时机，从而提高对基础数据采集时机的准确性与合理性，提高对实际场景识别的准确性。

5、无论是第一类情况还是第二类情况，在满足前置条件后本申请实施例都会先进行光强检测，以粗识别用户的实时状态。在确定出实时状态为用户可能或已经进入目标识别的场景时（例如，当用户当前场景为室外场景时，目标识别的场景即为室内场景，当用户当前场景为室内场景时，目标识别的场景为室外场景），再正式开始基础数据采集，从而避免直接进行基础数据采集导致基础数据内存在大量脏数据的情况。因此本申请实施例可以提高对基础数据采集时机的准确性与合理性，提高所采集的基础数据的有效性，同时减少或避免对非实际场景内进行无效数据采集的工作量。

6、本申请实施例在正式采集基础数据的时候，会以一定时间间隔进行多次数据采集，并以最后一次采集的基础数据为准进行实际场景分类和识别。从而将采集的过程延长，为用户和搜星器提供更多的缓冲时间。使得用户有较多时间可以走入实际场景，同时也使得搜星器用充足的时间完成冷启动，进入正常的工作状态搜索到完整的或者相对较为完整的卫星信号。因此本申请实施例可以获取到质量更好且更完整的基础数据，从而提高最终对实际场景的识别准确性。

7、本申请实施例在得到当次的分类结果时，可以基于当次分类结果进行综合分析，从而确定出终端设备实际所处的场景是室内场景还是室外场景。

由于单次分类结果的可靠性会受到模型识别精度影响，同时还受到基础数据质量的影响，从而使得单次分类结果可能存在一定的误识别情况。因此通过基于当次分类结果进行综合分析确定识别结果，使得本申请实施例可以有效提升最终识别结果的可信度，从而提高对识别结果的准确性。例如，可以选择对对当次分类结果进行验证或修正，从而减少单次误识别的概率，提高识别准确性。亦可以选择同时综合最近得到的多次分类结果来进行投票，从而降低单次分类结果误识别对最终实际场景识别结果的影响比重，提高最终实际场景识别结果的准确性。

阶段三：识别模型更新。

为了保持识别模型（包括初始训练好的基础模型，以及进行更新训练后的识别模型）的准确性，本申请实施例可以对识别模型进行及时更新，从而使得终端设备可以及时获得准确可靠的识别模型，保持对实际场景识别的准确性。具体而言，本申请实施例在阶段二：实际场景识别的过程中，当终端设备完成基础数据的采集后，可以由终端设备将采集到的真实的基础数据上传到云端的服务器。再由服务器根据这些真实的基础数据来对已有的识别模型进行更新训练。参考图3B，此时在S304和S309之后，本申请实施例还可以包括：

3010，终端设备基于所处的当前业务场景、当前地区和当前天气类型，对多次采集的基础数据中最后一次采集的基础数据，添加对应的业务场景标签、地区标签、天气类型标签和实际场景标签，并将添加好特征标签后的基础数据发送至服务器。

通过添加特征标签的方式，本申请实施例可以准确标记好每次上传的基础数据所对应的真实的业务场景、地区、天气类型以及实际场景。其中，考虑到通过阶段二：实际场景识别中对基础数据采集方案的多方面优化，使得本申请实施例最后一次采集基础数据时，用户极大概率处于实际场景中。因此在本申请实施例中，实际场景标签标记的可以是与当前场景不同的场景，如当前场景为室内场景时，实际场景标签标记的可以是室外场景，当前场景为室外场景时，实际场景标签标记的可以是室内场景。从而使得本申请实施例可以尽可能地为服务器提供真实可靠的数据。

相应的，若构建基础模型时未区分业务场景建模，终端设备在对基础数据添加特征标签中，可以不包含对应的业务场景标签，此时S3010可以被替换为：基于终端设备所处的当前地区和当前天气类型，对多次采集的基础数据中最后一次采集的基础数据，添加对应的地区标签、天气类型标签和实际场景标签，并将添加好特征标签后的基础数据发送至服务器。

由于实际应用中终端设备的数量往往较多，因此对于服务器角度而言，其可以收到较多不同终端设备上传的携带有特征标签的基础数据，因此以下将携带有特征标签的基础数据称为众包数据。

对于服务器而言，在接收到众包数据的基础上，可以基于众包数据对已有的识别模型进行更新。其中识别模型可以是初始构建好的基础模型，亦可以是对初始构建好的基础模型进行更新后的基础模型。参考图6A，是本申请实施例提供的一种识别模型更新方法的流程示意图，详述如下：

S401，服务器基于接收到的基础数据的业务场景标签、地区标签和天气类型标签，对识别模型进行特征标签的匹配，确定出对应待更新的目标模型。

由阶段一：基础模型训练的说明可知，当区分业务场景建模时，基础模型在建模已经标记有业务场景标签、地区标签和天气类型标签等特征标签。因此云端服务器在接收到基础数据时，可以根据接收到的几个特征标签来对已有的识别模型进行匹配，从而确定出特定该业务场景内，特定地区的特定天气类型所对应的识别模型。从而实现对待更新模型的精确定位。

其中，若构建基础模型时未区分业务场景建模，S401可以被替换为：服务器基于接收到的基础数据的地区标签和天气类型标签，对识别模型进行特征标签的匹配，确定出对应待更新的目标模型。

S402，服务器基于基础数据及基础数据的实际场景标签，对目标模型进行更新训练，得到更新后的目标模型。

本申请实施例中对目标模型的更新训练方法，与基础模型构建中对基础模型的训练方法基本相同，具体可参考阶段一：基础模型训练中的相关说明此处不予赘述。对目标模型更新训练后，原本的目标模型内的模型参数会发生对应的更新，因此服务器可以得到一个新的，更适用于当前用户真实生活场景情况的识别模型。其中，本申请实施例不对进行识别模型更新的时机做过多限定，可由技术人员设定。例如，在一些可选实施例中，可以设定对识别模型的更新周期，每次达到更新周期时，基于服务器在前一次更新操作到当前时刻期间接收到基础数据来更新对应的目标模型。在另一些可选实施例中，亦可以设置一个数据量阈值，在累计接收到的基础数据的数据量达到该数据量阈值时，开始基于累计的基础数据对目标模型进行更新训练。再又一些可选实施例中，亦可以由技术人员手动触发对识别模型的更新，例如可以在接收到较多用户反馈实际场景识别准确性问题时，进行识别模型更新。

在本申请实施例中，通过基础数据的特征标签与已有的识别模型的特征标签进行匹配，可以精确定位出每一个真实基础数据对应的特定识别模型（即目标模型）。再基于真实的基础数据来对目标模型进行更新，从而使得本申请实施例可以持续保持识别模型对用户真实生活场景的适应能力，使得本申请实施例中的识别模型对实际场景的分类准确性可以持续保持较高的水平。因此本申请实施例可以有效保持对实际场景识别的准确性。

作为本申请的一个实施例，可以参考图6B，是本申请实施例提供的一种基于众包数据进行模型更新的场景识别法整体架构图。在本申请实施例中服务器内包含云端预训练模型模块，用于对识别模型进行构建，还包含云端模型模块用于对识别模型进行更新训练。同时针对业务场景A，服务器内针对A1个城市（即地区的级别为城市）和A2种天气类型分别进行了建模，因此针对业务场景A共有A1×A2个识别模型。终端设备内包含推理模块，用于利用识别模型来进行实际场景的识别。详述如下：

终端设备作为众包采集模块，在进行场景识别的过程中，将采集到的众包数据上传至云端服务器。

服务器在接收到众包数据的基础上，云端预训练模型模块基于众包数据对已有的识别模型进行更新训练，得到更新后的识别模型。

其中，在云端模型模块在进行识别模型更新训练，首先对基础数据进行特征工程，即把原始的基础数据数据转变为识别模型的更新训练数据。再可以基于CNN模型中的栈式自动编码（StackedAutoEncoder）模型来实现识别模型的集成学习。另外，在A1×A2个识别模型中，若有一个或多个识别模型通过特征标签没有匹配到对应的基础数据时，服务器可以选择不对这些识别模型进行更新训练。因此实际应用中，每次进行识别模型更新训练时，可能是对所有识别模型都进行更新训练，也可能是对其中一部分识别模型进行更新训练，具体需根据实际情况确定。

服务器在完成对识别模型的更新训练后，可以主动向终端设备推送更新后的识别模型。

终端设备的推理模块在需要进行实际场景识别时，通过终端设备所在城市和天气类型等匹配出对应的识别模型，再利用该识别模型来实现对实际场景的识别，确定出所需进入的是室内场景或室外场景。其中，推理模块可以是基于TensorFlow-lite的轻量级模块。

本申请实施例的具体细节、原理及有益效果等说明，可参考上述阶段一至阶段三的相关说明，此处不予赘述。

作为本申请的一个具体实施例，为了验证识别模型为逻辑回归模型或神经网络模型的差异，以及是否使用众包数据对识别模型进行更新对识别模型的影响。本申请实施例针对以下四种情况进行了多个地区的实际场景识别情况测试：

情况1：识别模型是逻辑回归模型，在构建好对应的基础模型后，基于初始构建好的识别模型进行测试。此时没有使用众包数据对基础模型进行更新。

情况2：在情况1的基础上，基于收集到的众包数据来对识别模型进行更新，并利用更新后的识别模型进行测试。

情况3：识别模型是神经网络模型，在构建好对应的基础模型后，基于初始构建好的识别模型进行测试。此时没有使用众包数据对基础模型进行更新。

情况4：在情况3的基础上，基于收集到的众包数据来对识别模型进行更新，并利用更新后的识别模型进行测试。

对4种情况进行测试的数据如下表1：

表1

其中，室外召回率是指对室外场景的召回率，室外准确率是指对室外场景的准确率，室内召回率是指对室内场景的召回率，室内准确率是指对室内场景的准确率。

由表1内的数据可以看出，由于众包数据内可能存在一定的脏数据，因此导致在利用众包数据对基础模型进行更新后所得到的识别模型，对实际场景的识别能力可能会有一定程度的下降，但仍保持在一个较高的水平。但实际应用中，由于各个地区内的真实情况会不断变化，初始构建好的基础模型难以自行适应真实情况变化。因此若不采用众包数据对基础数据进行更新，则可能会导致基础模型对实际场景的识别能力持续下降，直至难以适用对应地区的真实需求。

对应于上文实施例所述的场景识别方法，图7示出了本申请实施例提供的场景识别装置的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图7，该场景识别装置包括：

获取模块71，用于获取自身所处的当前地区和当前天气类型。

模型确定模块72，用于确定出与当前地区和当前天气类型均匹配的目标识别模型。

采集模块73，用于采集多次基础数据，其中相邻两次采集操作的间隔时长大于零。

识别模块74，用于利用目标识别模型对采集到的基础数据进行处理，确定出自身进入的实际场景，实际场景为室内场景或室外场景。

作为本申请的一个实施例，场景识别装置可以实现如图1A至图6B所示实施例以及其他相关方法实施例。

本申请实施例提供的场景识别装置中各模块实现各自功能的过程，具体可参考前述图1A至图6B所示实施例以及其他相关方法实施例的描述，此处不再赘述。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。还应理解的是，虽然术语“第一”、“第二”等在文本中在一些本申请实施例中用来描述各种元素，但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如，第一表格可以被命名为第二表格，并且类似地，第二表格可以被命名为第一表格，而不背离各种所描述的实施例的范围。第一表格和第二表格都是表格，但是它们不是同一表格。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

本申请实施例提供的场景识别方法可以应用于手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobilepersonal computer，UMPC)、上网本、个人数字助理(personaldigital assistant，PDA)等终端设备上，本申请实施例对终端设备的具体类型不作任何限制。

例如，所述终端设备可以是WLAN中的站点(STATION，ST)，可以是蜂窝电话、无绳电话、会话启动协议(SessionInitiationProtocol，SIP)电话、无线本地环路(WirelessLocalLoop，WLL)站、个人数字处理(PersonalDigital Assistant，PDA)设备、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、车联网终端、电脑、膝上型计算机、手持式通信设备、手持式计算设备、卫星无线设备、无线调制解调器卡、电视机顶盒(set top box，STB)、用户驻地设备(customer premise equipment，CPE)和/或用于在无线***上进行通信的其它设备以及下一代通信***，例如，5G网络中的终端设备或者未来演进的公共陆地移动网络(Public Land Mobile Network，PLMN)网络中的终端设备等。

作为示例而非限定，当所述终端设备为可穿戴设备时，该可穿戴设备还可以是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上，或是整合到用户的衣服或配件的一种便携式设备。可穿戴设备不仅仅是一种硬件设备，更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能，如智能手表或智能眼镜等，以及只专注于某一类应用功能，需要和其它设备如智能手机配合使用，如各类进行体征监测的智能手环、智能首饰等。

图8是本申请一实施例提供的终端设备的结构示意图。如图8所示，该实施例的终端设备8包括：至少一个处理器80（图8中仅示出一个）、存储器81，所述存储器81中存储有可在所述处理器80上运行的计算机程序82。所述处理器80执行所述计算机程序82时实现上述各个场景识别方法实施例中的步骤，例如图3B所示的步骤S300至S310。或者，所述处理器80执行所述计算机程序82时实现上述各装置实施例中各模块/单元的功能，例如图7所示模块71至74的功能。

所述终端设备8可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括，但不仅限于，处理器80、存储器81。本领域技术人员可以理解，图8仅仅是终端设备8的示例，并不构成对终端设备8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述终端设备还可以包括输入发送设备、网络接入设备、总线等。

所称处理器80可以是中央处理单元（CentralProcessing Unit，CPU），还可以是其他通用处理器、数字信号处理器（Digital Signal Processor，DSP）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现成可编程门阵列（Field-Programmable Gate Array，FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器81在一些实施例中可以是所述终端设备8的内部存储单元，例如终端设备8的硬盘或内存。所述存储器81也可以是所述终端设备8的外部存储设备，例如所述终端设备8上配备的插接式硬盘，智能存储卡（Smart Media Card，SMC），安全数字（SecureDigital，SD）卡，闪存卡（Flash Card）等。进一步地，所述存储器81还可以既包括所述终端设备8的内部存储单元也包括外部存储设备。所述存储器81用于存储操作***、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器81还可以用于暂时地存储已经发送或者将要发送的数据。

下文以终端设备是手机为例，图9A示出了手机100的结构示意图。

手机100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及SIM卡接口195等。其中传感器模块180可以包括陀螺仪传感器180A，加速度传感器180B，气压传感器180C，磁传感器180D，环境光传感器180E，距离传感器180F，接近光传感器180G、指纹传感器180H，温度传感器180J，触摸传感器180K（当然，手机100还可以包括其它传感器，比如温度传感器，压力传感器、气压传感器、骨传导传感器等，图中未示出）。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP)，调制解调处理器，图形处理器（graphics processingunit， GPU)，图像信号处理器（image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器( Neural-network Processing Unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。其中，控制器可以是手机100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了***的效率。

处理器110可以运行本申请实施例提供的场景识别方法，以便于准确识别实际场景，提升用户的体验。处理器110可以包括不同的器件，比如集成CPU和GPU时，CPU和GPU可以配合执行本申请实施例提供的场景识别方法，比如场景识别方法中部分算法由CPU执行，另一部分算法由GPU执行，以得到较快的处理效率。

应理解，在实际应用中，手机100可以包括比图9A所示的更多或更少的部件，本申请实施例不作限定。图示手机100仅是一个范例，并且手机100可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

终端设备的软件***可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android***为例，示例性说明终端设备的软件结构。图9B是本申请实施例的终端设备的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android***分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时（Android runtime）和***库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图9B所示，应用程序包可以包括电话、相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口（applicationprogramming interface，API）和编程框架。应用程序框架层包括一些预先定义的函数。

如图9B所示，应用程序框架层可以包括窗口管理器，内容提供器，视图***，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图***包括可视控件，例如显示文字的控件，显示图片的控件等。视图***可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供终端设备的通信功能。例如通话状态的管理（包括接通，挂断等）。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在***顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，终端设备振动，指示灯闪烁等。

Android Runtime包括核心库和虚拟机。Android Runtime负责安卓***的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

***库可以包括多个功能模块。例如：表面管理器（surface manager），媒体库（Media Libraries），三维图形处理库（例如：OpenGLES），2D图形引擎（例如：SGL）等。

表面管理器用于对显示子***进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4， H.164， MP3， AAC， AMR， JPG， PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

另外，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

本申请实施例还提供了一种终端设备，所述终端设备包括至少一个存储器、至少一个处理器以及存储在所述至少一个存储器中并可在所述至少一个处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使所述终端设备实现上述任意各个方法实施例中的步骤。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时可实现上述各个方法实施例中的步骤。

本申请实施例还提供了一种芯片***，所述芯片***包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述各个方法实施例中的步骤。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读存储介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（Read-Only Memory，ROM）、随机存取存储器（Random Access Memory，RAM）、电载波信号、电信信号以及软件分发介质等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使对应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (18)

1.一种场景识别方法，其特征在于，应用于终端设备，包括：

获取自身所处的当前地区和当前天气类型；

确定出与所述当前地区和所述当前天气类型均匹配的目标识别模型；

采集多次基础数据，其中相邻两次采集操作的间隔时长大于零；所述基础数据中包含卫星信号的特征参数；

利用所述目标识别模型对采集到的基础数据进行处理，确定出自身进入的实际场景，所述实际场景为室内场景或室外场景；

在所述采集多次基础数据之前，还包括：

获取自身所处的当前场景，所述当前场景为室内场景或者室外场景；

当所述当前场景为室外场景时，进行光强检测，并在检测到的光强值小于或等于预设的第一强度阈值时，执行所述采集多次基础数据的操作；

当所述当前场景为室内场景时，进行光强检测，并在检测到的光强值大于预设的第二强度阈值时，执行所述采集多次基础数据的操作。

2.根据权利要求1所述的场景识别方法，其特征在于，在所述采集多次基础数据之前，还包括：

当检测到满足前置条件时，执行所述采集多次基础数据的操作；所述前置条件中包含有若干种用户行为。

3.根据权利要求2所述的场景识别方法，其特征在于，在所述采集多次基础数据之前，还包括：

当检测到满足预设的触发条件时，确定自身当前所处的目标业务场景；

确定出所述目标业务场景对应的所述前置条件，并检测是否满足所述前置条件。

4.根据权利要求3所述的场景识别方法，其特征在于，所述当检测到满足预设的触发条件时，确定自身当前所处的目标业务场景，包括：

当检测到满足预设的触发条件时，确定出所述触发条件对应的业务场景，并将该业务场景确定为当前所处的所述目标业务场景。

5.根据权利要求3所述的场景识别方法，其特征在于，所述确定出与所述当前地区和所述当前天气类型均匹配的目标识别模型，包括：

确定出与所述目标业务场景、所述当前地区和所述当前天气类型均匹配的所述目标识别模型。

6.根据权利要求1至5中任一所述的场景识别方法，其特征在于，所述利用所述目标识别模型对采集到的所述基础数据进行处理，确定出自身进入的实际场景，包括：

利用所述目标识别模型对所述采集多次基础数据操作中最后一次采集到的基础数据进行处理，确定出自身进入的实际场景。

7.根据权利要求6所述的场景识别方法，其特征在于，所述识别模型为分类模型；

所述利用所述目标识别模型对所述采集多次基础数据操作中最后一次采集到的基础数据进行处理，确定出自身进入的实际场景，包括：

利用所述目标识别模型对所述采集多次基础数据操作中最后一次采集到的基础数据进行处理，得到所述目标识别模型输出的当次分类结果；

根据所述当次分类结果，确定出自身进入的实际场景。

8.根据权利要求7所述的场景识别方法，其特征在于，根据所述当次分类结果，确定出自身进入的实际场景，包括：

获取最近得到的多次分类结果，并根据所述多次分类结果确定出自身进入的实际场景；其中，所述多次分类结果中包含所述当次分类结果。

9.根据权利要求8所述的场景识别方法，其特征在于，所述根据所述多次分类结果确定出自身进入的实际场景，包括：

将所述多次分类结果中出现次数最多的分类结果作为所述终端设备进入的实际场景；或者

当所述多次分类结果均相同时，将所述多次分类结果中任一分类结果作为所述终端设备进入的实际场景。

10.根据权利要求1所述的场景识别方法，其特征在于，所述终端设备当前所处的目标业务场景为进出地铁站；

在所述获取自身所处的当前场景之前，还包括：

当检测到满足前置条件时，执行所述获取自身所处的当前场景的操作；所述前置条件中包含有若干种用户行为；

相应的，当所述当前场景为室内场景时，进行光强检测，包括：

当所述当前场景为室内场景时，延迟预设时长后进行光强检测。

11.根据权利要求1所述的场景识别方法，其特征在于，还包括：

当所述当前场景为室外场景，且检测到的光强值大于所述第一强度阈值时，间隔预设的时长后返回执行所述进行光强检测的操作，直至满足预设的终止条件，停止光强检测。

12.根据权利要求1所述的场景识别方法，其特征在于，还包括：

当所述当前场景为室内场景，且检测到的光强值小于或等于所述第二强度阈值时，以预设的时长为间隔，周期性执行所述进行光强检测的操作，直至满足预设的终止条件，停止光强检测。

13.根据权利要求1至5中任一所述的场景识别方法，其特征在于，所述基础数据中包含卫星信号的统计学特征参数；

所述统计学特征参数包含以下至少一项参数：卫星信号的强度比例、最大信噪比、最小信噪比、信噪比标准差、信噪比中位数、信噪比极差、去零平均信噪比以及含零平均信噪比。

14.一种场景识别***，其特征在于，包括：服务器以及如权利要求1至13任一项中所述的终端设备；

所述服务器获取样本参数；所述样本参数标记有对应的地区标签和天气类型标签；

所述服务器基于所述样本参数对初始模型进行训练，得到训练完成的识别模型，该识别模型关联有所述样本参数对应的地区标签和天气类型标签；

所述终端设备确定出与所述当前地区和所述当前天气类型均匹配的目标识别模型，包括：

所述终端设备基于所述当前地区和所述当前天气类型，对所述服务器中的识别模型进行标签匹配，确定出地区标签与所述当前地区匹配且天气类型标签与所述当前天气类型相匹配的所述识别模型。

15.根据权利要求14所述的场景识别***，其特征在于，所述服务器基于所述样本参数对初始模型进行训练，得到训练完成的识别模型，包括：

基于预设的过滤条件对样本参数进行数据过滤，得到过滤后的样本参数；

基于过滤后的样本参数对所述初始模型进行迭代训练；

在对所述初始模型迭代训练的过程中，对每次训练的损失函数值进行检测，并在检测到所述损失函数值稳定性满足预设条件时停止训练，得到训练完成的识别模型。

16.根据权利要求14或15所述的场景识别***，其特征在于，所述终端设备在所述采集多次基础数据之后，还包括：

所述终端设备基于所述当前地区和所述当前天气类型，对所述采集多次基础数据操作中最后一次采集到的基础数据添加对应的特征标签，并将添加好的所述特征标签后的基础数据发送至所述服务器；所述特征标签中包括地区标签和天气类型标签；

所述服务器基于接收到的基础数据的所述特征标签，对本地的识别模型进行标签匹配，确定出待更新的识别模型；

所述服务器基于接收到的基础数据，对所述待更新的识别模型进行更新训练，得到更新后的识别模型。

17.一种终端设备，其特征在于，所述终端设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至13任一项所述的场景识别方法。

18.一种芯片***，其特征在于，所述芯片***包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现如权利要求1至13任一项所述的场景识别方法。

Images