实时直播数据处理方法及计算机存储介质与流程

1.本技术实施例涉及计算机技术领域，尤其涉及一种实时直播数据处理方法及计算机存储介质。


背景技术：

2.随着用户交互需求的增长，越来越多的应用尤其是多媒体应用采用了实时交互的方式。在这种方式下，多媒体受众用户（如视频直播的观众用户或音频直播的听众用户等）可以通过评论消息的方式与多媒体主播进行实时交互。
3.以视频直播为例，在一般的视频直播过程中，很多主播所在直播间的在线人数非常多（可能达到成千上万人），每秒钟产生几十上百条甚至更多的观众用户的评论消息。对于主播来说，评论消息是可以了解观众用户对其播放内容、播放行为等的想法和需求的有效途径。但是，对于大量的评论消息，一方面，需要花费大量的人力和时间成本才能从中找出观众用户的核心诉求和想法；另一方面，很多诉求和想法是有时效性的，经过一段时间后梳理出来再进行回复或响应，会导致观众用户的诉求不能得到及时且有效的满足、大大降低了观众用户的体验，进而降低了用户粘性。


技术实现要素：

4.有鉴于此，本技术实施例提供一种实时直播数据处理方案，以至少部分解决上述问题。
5.根据本技术实施例的第一方面，提供了一种实时直播数据处理方法，包括：实时获取用户在观看直播内容过程中发送的评论消息；对预设时间范围内的评论消息进行语义分析，根据所述语义分析的结果获取所述评论消息对应的用户意图；根据所述用户意图对所述评论消息进行聚类，获取至少一个意图聚类结果；通过所述直播内容的直播信息界面展示所述意图聚类结果。
6.根据本技术实施例的第二方面，提供了另一种实时直播数据处理方法，包括：在直播界面展示直播内容及用户在观看所述直播内容的过程中输入的评论消息；以及，在确定评论意图提示条件满足时，在所述直播界面展示根据所述评论消息生成的用户意图提示消息。
7.根据本技术实施例的第三方面，提供了一种电子设备，包括：接收器、发送器和处理器；其中：所述接收器，用于接收用户在观看直播内容过程中输入的评论消息，并发送至所述处理器；所述处理器，用于实时获取所述评论消息；对预设时间范围内的评论消息进行语义分析，根据所述语义分析的结果获取所述评论消息对应的用户意图；根据所述用户意图对所述评论消息进行聚类，获取至少一个意图聚类结果；所述发送器，用于将所述意图聚类结果发送至用户设备，以通过所述用户设备在直播内容的直播界面展示所述意图聚类结果。
8.根据本技术实施例的第四方面，提供了另一种电子设备，包括：输入装置、显示器
和处理器；其中：所述输入装置，用于接收用户在观看直播内容过程中输入的评论消息，并发送至所述处理器；所述处理器，用于在直播界面展示直播内容及所述评论消息；以及，在确定评论意图提示条件满足时，获取根据所述评论消息生成的用户意图提示消息；所述显示器，用于在所述直播界面展示所述用户意图提示消息。
9.根据本技术实施例的第五方面，提供了一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面或第二方面所述的实时直播数据处理方法。
10.根据本技术实施例的第六方面，提供了一种计算机程序产品，包括计算机指令，所述计算机指令指示计算设备执行如第一方面或第二方面所述的实时直播数据处理方法对应的操作。
11.根据本技术实施例提供的实时直播数据处理方案，会对用户在观看直播内容过程中发表的评论消息进行实时获取，进而进行语义分析，从而获得用户基于评论消息所想要表达的用户意图。因同时观看直播内容的用户可能有很多，因此多个用户发表的评论消息所想要表达的意图可能相同或相近，基于此，可以基于获得的用户意图进行聚类，以获得一个或多个意图聚类结果，进而通过直播信息界面展示意图聚类结果。由此，一方面 ，通过对评论消息进行语义分析以及后续的意图聚类，即可了解用户的核心诉求和想法，无需人工处理，节省了人力和时间成本；另一方面，因实时获取评论消息并及时进行相应的分析和聚类，可以有效保证用户诉求和想法传达的时效性，及时且有效的满足用户需求，同时提升用户和主播的体验，增加用户和主播粘性。
12.而在用户意图显示层面，当评论意图提示条件满足时，即可在直播界面展示根据用户的评论消息生成的用户意图提示消息。由此，可以使得消息获取端如直播的主播等及时了解可表达用户核心诉求和想法的用户意图，并进行及时处理，以及时且有效的满足用户需求，提升用户的主播的体验，增加用户和主播粘性。
附图说明
13.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
14.图1为适用本技术实施例的实时直播数据处理方法的示例性系统的示意图；图2a为根据本技术实施例一的一种实时直播数据处理方法的步骤流程图；图2b为图2a所示实施例中的一种场景示例的示意图；图3a为根据本技术实施例二的一种实时直播数据处理方法的步骤流程图；图3b为图3a所示实施例中的一种直播信息界面的示意图；图3c为图3a所示实施例中的另一种直播信息界面的示意图；图4a为根据本技术实施例三的一种实时直播数据处理方法的步骤流程图；图4b为图4a所示实施例中的一种过程示意图；图5为根据本技术实施例四的一种实时直播数据处理方法的步骤流程图；图6a为根据本技术实施例五的一种实时直播数据处理方法的步骤流程图；图6b为图6a所示实施例中的一种场景示例的示意图；
图7为根据本技术实施例六的一种电子设备的结构示意图；图8为根据本技术实施例七的另一种电子设备的结构示意图。
具体实施方式
15.为了使本领域的人员更好地理解本技术实施例中的技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术实施例一部分实施例，而不是全部的实施例。基于本技术实施例中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本技术实施例保护的范围。
16.下面结合本技术实施例附图进一步说明本技术实施例具体实现。
17.图1示出了一种适用本技术实施例的实时直播数据处理方法的示例性系统。如图1所示，该系统100可以包括服务器102、通信网络104和/或一个或多个用户设备106，图1中示例为多个用户设备。在直播类应用系统中，多个用户设备106可以既包括主播端的用户设备1062，也可以包括受众用户端的用户设备1064。图1中同时示出了该两种用户设备，但本领域技术人员应当明了的是，图1中虽然仅示出了两个主播端的用户设备1062和两个受众用户端的用户设备1064，但该数量仅为示意性说明，在实际应用中，主播端的用户设备1062和受众用户端的用户设备1064的具体数量均可灵活设置，本技术实施例对此不作限制。本技术的多个实施例中，主要以主播端的用户设备1062的角度进行方案说明。
18.服务器102可以是用于存储信息、数据、程序和/或任何其他合适类型的内容的任何适当的服务器。在一些实施例中，服务器102可以执行任何适当的功能。例如，在一些实施例中，服务器102可以用于对受众用户的评论消息进行处理，以获得可反映一个或多个受众用户的用户意图的意图聚类结果，该意图聚类结果将会被发送给主播端的用户设备1062，以通过直播的主播端的用户设备1062进行展示。作为可选的示例，在一些实施例中，服务器102可以用于对受众用户的评论消息进行语义分析以获取用户意图，再基于用户意图进行聚类以获得意图聚类结果，进而发送给主播端的用户设备1062，通过直播的主播端的用户设备1062进行展示。作为可选的示例，在一些实施例中，服务器102可以被用于提供相应的接口以供主播端的用户设备1062或者受众用户端的用户设备1064调用，返回主播端的用户设备1062或者受众用户端的用户设备1064需要的数据。
19.在一些实施例中，通信网络104可以是一个或多个有线和/或无线网络的任何适当的组合。例如，通信网络104能够包括以下各项中的任何一种或多种：互联网、内联网、广域网(wan)、局域网(lan)、无线网络、数字订户线路(dsl)网络、帧中继网络、异步转移模式(atm)网络、虚拟专用网(vpn)和/或任何其它合适的通信网络。主播端的用户设备1062和受众用户端的用户设备1064能够通过一个或多个通信链路(例如，通信链路112)连接到通信网络104，该通信网络104能够经由一个或多个通信链路(例如，通信链路114)被链接到服务器102。通信链路可以是适合于在主播端的用户设备1062/受众用户端的用户设备1064和服务器102之间传送数据的任何通信链路，诸如网络链路、拨号链路、无线链路、硬连线链路、任何其它合适的通信链路或此类链路的任何合适的组合。
20.在直播场景下，受众用户端的用户设备1064主要用于展示直播内容，并接收受众用户在观看直播内容过程中发表的评论消息，该评论消息将会被发送至服务器102。
21.主播端的用户设备1062可以包括适合于与受众用户进行交互，呈现相应的信息和
界面的任何一个或多个用户设备。在一些实施例中，主播端的用户设备1062可以用于将主播录制的直播内容发送至服务器102，进而由服务器102发送给受众用户端的用户设备1064。在此基础上，作为可选的示例，在一些实施例中，主播端的用户设备1062还可以用于接收服务器102发送的意图聚类结果（其中，该意图聚类结果由服务器102根据受众用户端的用户设备1064发送的评论消息确定用户意图，基于该用户意图进行聚类获得），以通过主播端的用户设备1062向主播展示。
22.在一些实施例中，主播端的用户设备1062和受众用户端的用户设备1064均可以包括任何合适类型的设备。例如，在一些实施例中，主播端的用户设备1062和受众用户端的用户设备1064均可以包括移动设备、平板计算机、膝上型计算机、台式计算机、可穿戴计算机、游戏控制台、媒体播放器、车辆娱乐系统和/或任何其他合适类型的用户设备。
23.尽管将服务器102图示为一个设备，但是在一些实施例中，可以使用任何适当数量的设备来执行由服务器102执行的功能。例如，在一些实施例中，可以使用多个设备来实现由服务器102执行的功能。或者，可使用云服务实现服务器102的功能。需要说明的是，若主播端的用户设备1062具有较高的软硬件性能，则可替代服务器102执行部分或全部的上述与评论消息处理有关的功能。
24.基于上述系统，本技术实施例提供了一种实时直播数据处理方法，以下通过多个实施例进行说明。
25.实施例一参照图2a，示出了根据本技术实施例一的一种实时直播数据处理方法的步骤流程图。
26.本实施例的实时直播数据处理方法包括以下步骤：步骤s202：实时获取用户在观看直播内容过程中发送的评论消息。
27.大部分的直播类应用都提供有供受众用户在观看直播内容时，与主播或其他受众用户进行交互的设置，这些设置至少包括供受众用户发表评论消息的设置。大部分受众用户都会通过评论消息的形式就直播内容、直播针对的对象、以及主播的直播行为等与主播进行交互。这些评论消息会上传至服务器，再由服务器发送给主播端。相对应地，主播端能够实时获取受众用户发表的这些评论消息。需要说明的是，本技术实施例中，为简便起见，下文中“用户”意指受众用户。
28.本技术实施例中，评论消息的形式包括但不限于：文本评论消息、语音评论消息、图像评论消息、表情评论消息等中的至少一种。对于除文本评论消息之外的其它类型的评论消息，可以先将其转换为文本消息再进行处理。其中，对于表情评论消息可转换为默认文本消息或者转换为可表达表情含义的文本消息；对于图像评论消息可将其转换为可反映图像主要内容的文本消息。基于此，在一种可行方式中，本步骤可以实现为：实时获取用户在观看直播内容过程中输入的原始文本评论消息；和/或，实时获取对用户在观看直播内容过程中输入的表情评论消息或者语音评论消息或者图像评论消息进行转换后生成的文本评论消息。由此，可以使得本技术实施例的数据处理更为灵活，也使得直播应用可为用户提供更丰富的评论形式。
29.此外，为了保障评论消息获取的实时性，在一种可行方式中，可通过消息队列，实时获取用户在观看直播内容过程中发送的评论消息。其中，消息队列可采用诸如kafka消息
队列、tt日志队列等队列形式。但不限于此，其它队列形式以及其它可实时获取评论消息的形式均可适用于本技术实施例的方案。
30.通过上述过程，可实现对用户发表的评论消息的实时获取。
31.步骤s204：对预设时间范围内的评论消息进行语义分析，根据语义分析的结果获取评论消息对应的用户意图。
32.其中，对评论消息进行语义分析的具体实现可由本领域技术人员根据实际需求采用适当方式实现，包括但不限于神经网络模型如cnn模型等、或者通过语义分析算法等实现，本技术实施例对此不作限制。
33.通过语义分析，可以获取每条评论消息对应的用户意图。例如，主播在直播销售一件休闲裤的时候、多个用户分别发表了咨询裤子的材质、着装效果、单价的评论消息，对这些评论消息进行语义分析，可确定每个评论消息对应的用户意图分别为针对裤子的材质、着装效果、单价的咨询意图。
34.步骤s206：根据用户意图对评论消息进行聚类，获取至少一个意图聚类结果。
35.因有可能多个评论消息表达相同或相近的用户意图，例如，用户a发表评论消息“这个裤子多少钱”，用户b发表评论消息“请问单价怎样”，则这两条评论消息经过语义分析，可确定其对应的用户意图均为单价的咨询意图。则，通过聚类，可将这两个评论消息聚为一类。
36.可见，在获得了评论消息对应的用户意图后，可以基于此对评论消息进行聚类，以将具有相同或相近意图的评论消息聚为一类，以提高后续的数据处理及展示的效率，也使得主播更易于获得用户意图。
37.步骤s208：通过直播内容的直播信息界面展示意图聚类结果。
38.在确定了意图聚类结果后，一种可行方案中，可以将该意图聚类结果发送至主播端，由主播端对其进行加工或处理后，在直播内容的直播信息界面展示；另一种可行方案中，可以根据预存的模板将意图聚类结果处理为提示消息的形式，发送至主播端以通过主播端的直播信息界面展示。
39.其中，直播信息界面可以为一个独立的可基于直播内容进行展示的界面，如可以为一个弹窗界面或蒙版界面或者浮层等。但直播信息界面也可以是隶属于直播界面中的一个区域，通过该区域进行意图聚类结果的展示。
40.以下，以一个场景示例对上述过程进行示例性说明，如图2b所示。
41.图2b中，简单示意为有10个用户（分别为用户1-10）在观看主播x直播销售的休闲裤，其中，用户1发表评论消息1：“这条裤子是什么材质的呀”；用户2发表评论消息2：“都有什么型号”；用户3发表评论消息3：“多少钱，有优惠吗”；用户4发表评论消息4：“有模特吗，看下效果”；用户5发表评论消息5：“什么价钱”；用户6发表评论消息6：“瘦人穿上好看吗”；用户7发表评论消息7：“多少钱，现在打折吗”；用户8发表评论消息8：“是灯心绒的吗”；用户9发表评论消息9：“现在下单，几天能到货”；用户10发表评论消息10：“我天津的，已下单，什么时候能送到”。这些评论消息会经由数据传输通道实时发送给服务器，并经由服务器发送给主播x的直播客户端。一方面，主播x的直播客户端在接收到这些评论消息后会实时进行显示，并根据服务器不断发送来的消息更新界面显示。另一方面，服务器在接收到这些评论消息后，会按照一定的时间范围周期性地对实时接收到的评论消息进行处理，假设每分钟
处理一次，并且假设该10条评论消息均处于一个处理的时间范围周期内。则，对该10条评论消息进行语义分析，确定每条评论消息对应的用户意图，例如，评论消息1
‑‑‑
材质，评论消息2
‑‑‑
型号，评论消息3
‑‑‑
单价及优惠，评论消息4
‑‑‑
着装效果，评论消息5
‑‑‑
单价，评论消息6
‑‑‑
着装效果，评论消息7
‑‑‑
单价及优惠，评论消息8
‑‑‑
材质，评论消息9
‑‑‑
送货时间，评论消息10
‑‑‑
送货时间。
42.进而，在确定了各个评论消息对应的用户意图后，可以对这些用户意图进行聚类，获得意图聚类结果，例如，关心材质类（评论消息1和8）、关心型号类（评论消息2）、关心单价及优惠类（评论消息3、5和7）、关心着装效果类（评论消息4和6）、关心送货时间类（评论消息9和10）。基于此，则可生成相应的提示信息，如，“用户关心材质/型号/单价及优惠/着装效果/送货时间，请进行介绍”，该提示信息可发送至主播端。在主播端，通过弹窗将上述提示信息显示给主播，以通过该提示信息提示主播对用户意图也即用户关心的内容及时进行回应，或者，调整直播内容或主播的直播行为，等等。
43.当然，以上仅为示例性说明，在实际应用中，意图聚类结果的展示方式可由本领域技术人员根据实际需求设定，不限于上述示例中所述方式。
44.通过本实施例，会对用户在观看直播内容过程中发表的评论消息进行实时获取，进而进行语义分析，从而获得用户基于评论消息所想要表达的用户意图。因同时观看直播内容的用户可能有很多，因此多个用户发表的评论消息所想要表达的意图可能相同或相近，基于此，可以基于获得的用户意图进行聚类，以获得一个或多个意图聚类结果，进而通过直播信息界面展示意图聚类结果。由此，一方面 ，通过对评论消息进行语义分析以及后续的意图聚类，即可了解用户的核心诉求和想法，无需人工处理，节省了人力和时间成本；另一方面，因实时获取评论消息并及时进行相应的分析和聚类，可以有效保证用户诉求和想法传达的时效性，及时且有效的满足用户需求，同时提升用户和主播的体验，增加用户和主播粘性。
45.实施例二参照图3a，示出了根据本技术实施例二的一种实时直播数据处理方法的步骤流程图。
46.本实施例以意图聚类结果的展示方式为侧重点，对本技术实施例的实时直播数据处理方法进行说明。
47.本实施例的实时直播数据处理方法包括以下步骤：步骤s302：根据交互设置，确定预设时间范围和直播信息界面的展示方式。
48.其中，交互设置至少包括多种用于指示信息展示方式的选项设置。
49.本实施例中，直播应用中还提供有可对交互进行设置的选项或输入，即交互设置。通过该交互设置，主播可根据自身需要进行与评论消息的语义分析的时间周期即预设时间范围的设置，以及，进行与直播信息界面的展示方式有关的设置。这些交互设置可实现为诸如：时间范围输入框或单选项、直播信息界面展示方式选项框或单选项等的方式，以方便主播选择和设置。这些交互设置将会被上传服务器，在服务器进行存储并根据该交互设置进行实时直播数据处理。
50.在一种可行方式中，针对预设时间范围的交互设置可以包括但不限于：将预设时间范围设置为预设的时间间隔周期、或者，将预设时间范围设置为预设的时间窗口长度。
51.在另一种可行方式中，针对直播信息界面的展示方式的交互设置可以包括但不限于：以滚动窗口方式展示直播信息界面，或者，以滑动窗口方式展示直播信息界面。
52.通过上述交互设置，既为主播提供了方便灵活的设置手段，又能最大程度地满足主播的实际需求。
53.需要说明的是，通过本步骤可实现一次交互设置后续长期使用的效果，无需每次进行实时直播数据处理均执行交互设置。此外，所述交互设置也不限于上述预设时间范围设置和直播信息界面的展示方式的设置，本领域技术人员可根据实际需要增加其它设置项目。
54.步骤s304：实时获取用户在观看直播内容过程中发送的评论消息。
55.本步骤的具体实现可参照前述实施例一中的相关描述，在此不再赘述。
56.步骤s306：对预设时间范围内的评论消息进行语义分析，根据语义分析的结果获取评论消息对应的用户意图。
57.本步骤的执行与前述交互设置中有关预设时间范围的设置有关。基于此，在一种可行方式中，响应于预设时间范围为预设的时间间隔周期，本步骤可以实现为：按照预设的时间间隔周期，对评论消息进行语义分析。其中，时间间隔周期可由本领域技术人员根据实际需求适当设定，以时间间隔周期为2分钟为例，则每隔2分钟对获取到的评论消息进行语义分析，获取对应的用户意图。通过这种方式，既可实时及时的用户意图获取，又算法实现简单，实现成本低。
58.在另一种可行方式中，响应于预设时间范围为预设的时间窗口长度，本步骤可以实现为：按照预设的时间窗口长度获取时间窗口对应的时段内的评论消息，对获取的评论消息进行语义分析。与时间间隔周期不同，时间窗口与步长有关，例如，时间窗口为2分钟，步长为1分钟，则在第一个时间窗口内，会对第1-2分钟的评论消息进行语义分析；在第二个时间窗口内，会对第2-3分钟的评论消息进行语义分析；在第三个时间窗口内，会对第3-4分钟的评论消息进行语义分析，依此类推。也即，不同时间窗口对应的评论消息可能有部分重叠。通过这种方式，可以有效避免评论消息的遗漏，且可使得后续的意图聚类结果的展示更具连续性。
59.步骤s308：根据用户意图对评论消息进行聚类，获取至少一个意图聚类结果。
60.基于评论消息对应的用户意图对评论消息的聚类可采用常规聚类算法实现，包括但不限于：k均值聚类、高斯混合模型聚类等，本技术实施例对此不作限制。
61.步骤s310：根据设置的直播信息界面的展示方式，通过直播内容的直播信息界面展示意图聚类结果。
62.如前所述，针对直播信息界面的展示方式的交互设置包括但不限于：以滚动窗口方式展示直播信息界面，或者，以滑动窗口方式展示直播信息界面。
63.基于此，在一种可行方式中，在按照预设的时间间隔周期，对评论消息进行语义分析的情况下，本步骤可以实现为：基于直播内容的直播界面和确定的直播信息界面的展示方式，通过滚动窗口滚动展示意图聚类结果，其中，滚动窗口每次显示时间间隔周期内预设数量的评论消息对应的意图聚类结果。进一步可选地，在基于直播内容的直播界面，通过滚动窗口滚动展示意图聚类结果时，可以基于直播内容的直播界面展示新的窗口，每隔时间间隔周期通过新的窗口更新并展示意图聚类结果，其中，相邻两次展示的意图聚类结果为
不同的意图聚类结果。此种方式下，每隔预设的时间间隔周期对评论消息进行语义分析获得用户意图，进行聚类并获得意图聚类结果，通过窗口滚动展示，每次展示预设数量（如5条）的意图聚类结果且本次展示的意图聚类结果与前次不同。由此，实现了意图聚类结果的周期性自动更新展示。
64.一种上述方式的直播信息界面如图3b所示，其示出了一种按照预设的时间间隔周期自动更新显示的滚动窗口示例。此种方式下，将时间间隔周期内的评论消息基于其对应的用户意图进行聚类，然后根据意图聚类结果对应的评论消息的数量、权重等指标做top n处理，将数量高、权重高的n条意图聚类结果基于预设的规则或模板进行规范化、整合化处理后，主动推送主播端，通过直播信息界面中的滚动窗口，图3b中示意图为滚动窗口条（如图3b中虚线框部分所示）进行展示。其中，n可由本领域技术人员根据实际需求设置，如设置为10等。例如，可以在直播间界面的左下角评论区的上方通过滚动窗口做用于显示意图聚类结果的重点消息弹出。图3b中，示例为用户评论的上层展示，并且，该重点消息本身也可以做视觉强化处理，提升主播体验。
65.在另一种可行方式中，在按照预设的时间窗口长度获取时间窗口对应的时段内的评论消息，对获取的评论消息进行语义分析的情况下，本步骤可以实现为：基于直播内容的直播界面和确定的直播信息界面的展示方式，通过滑动窗口滑动展示预设时间步长内意图聚类结果，其中，滑动窗口每次显示时间窗口长度内预设数量的评论消息对应的意图聚类结果。进一步可选地，在基于直播内容的直播界面，通过滑动窗口滑动展示预设时间步长内所述意图聚类结果时，可以接收输入的触发操作，根据触发操作在直播内容的直播界面展示新的窗口，每隔预设时间步长通过新的窗口更新并展示意图聚类结果，其中，相邻两次展示的意图聚类结果为存在部分重合的意图聚类结果。其中，所述触发操作可以是诸如手势触发操作、语音触发操作、针对界面中展示的选项或按钮等的触发操作等等。可见，此种方式下，可以允许主播进行手动触发操作，为主播自行对意图聚类结果的展示控制提供了方便。其中，时间窗口长度和预设时间步长均可由本领域技术人员根据实际需求适当设置地，一般情况下时间步长小于时间窗口长度。相邻两次展示的意图聚类结果中存在部分重合的数据，使得展示更具连续性，且可有效避免主播的漏看。
66.一种上述方式的直播信息界面如图3c所示，其示出了一种按照时间步长更新显示意图聚类结果的滑动窗口示例。滑动窗口的size（时间窗口长度） 和 slide（时间步长）都是可以调整的，以size为5分钟，slide为15秒为例。即，每过15秒会获取一次最近5分钟的评论消息对应的用户意图，再基于用户意图进行聚类得到意图聚类结果，然后根据意图聚类结果对应的评论消息的数量、权重等指标做top n处理，将数量高、权重高的n条意图聚类结果进行规范化、整合化处理，若确定主播主动发起了触发操作，才将处理后的意图聚类结果发送给主播端，通过滑动窗口进行展示。其中，n可由本领域技术人员根据实际需求设置，如设置为10等。示例性地，主播可以在直播间界面左滑，触发直播间界面上出现一个浮层，其中展示有包含重点评论、商品热度、活跃用户三个标签tab，再点击重点评论就会展示最近一个时间窗口长度的意图聚类结果，图中示意为重点消息。并且，可对该重点消息进行视觉强化处理，提升主播体验。
67.基于以上两种展现方式，对于具有大量评论消息的主播，即使其评论消息qps上千，本方案也可从这些评论消息里面将核心、重点、有必须要回复的top问题都抽取出来通
过以上两种方式展现，让主播及时、轻松地掌控直播间用户的用户意图，及时作出回复、响应等，提升直播体验和直播效果。
68.此外，若主播为新手主播，其开播时如果直播间没有评论消息、或者没有有效评论消息的情况下，还可以预先设置默认文案作为重点消息，比如“亲，直播间暂无重点消息，请多播一会，敬请期待！”等。
69.通过本实施例，会对用户在观看直播内容过程中发表的评论消息进行实时获取，进而进行语义分析，从而获得用户基于评论消息所想要表达的用户意图。因同时观看直播内容的用户可能有很多，因此多个用户发表的评论消息所想要表达的意图可能相同或相近，基于此，可以基于获得的用户意图进行聚类，以获得一个或多个意图聚类结果，进而通过直播信息界面展示意图聚类结果。由此，一方面 ，通过对评论消息进行语义分析以及后续的意图聚类，即可了解用户的核心诉求和想法，无需人工处理，节省了人力和时间成本；另一方面，因实时获取评论消息并及时进行相应的分析和聚类，可以有效保证用户诉求和想法传达的时效性，及时且有效的满足用户需求，同时提升用户和主播的体验，增加用户和主播粘性。
70.实施例三参照图4a，示出了根据本技术实施例三的一种实时直播数据处理方法的步骤流程图。
71.本实施例中，以对数据的处理为侧重点，对本技术实施例的实时直播数据处理方法进行说明。
72.本实施例的实时直播数据处理方法包括以下步骤：步骤s402：实时获取用户在观看直播内容过程中发送的评论消息。
73.例如，可以通过消息队列或tt日志等，实时获取评论消息。
74.步骤s404：对预设时间范围内的评论消息进行语义分析，根据语义分析的结果获取评论消息对应的用户意图。
75.对于评论消息来说，因其由用户发表，因此，部分评论消息中可能携带有无意义的信息，甚至是违反相关规定的信息，如不良言论等。为了提升对评论消息进行语义分析的效率，避免无效信息对语义分析的干扰，在一种可行方式中，可以对预设时间范围内的评论消息进行脏数据过滤；对进行了脏数据过滤后的评论消息进行语义分析，获得语义分析结果，其中，语义分析结果至少包括用户意图和意图类别；根据意图类别对评论消息进行再次过滤，获得再次过滤后的评论消息及再次过滤后的评论消息对应的用户意图。
76.本技术实施例中，脏数据意指不在给定的范围内或对于实际服务无意义，或是数据格式非法的数据。例如，可以通过脏数据过滤，过滤掉评论消息中的空字符、特殊字符、测试数据、恶意攻击数据、闲聊数据等。本实施例中，对进行了脏数据过滤后的评论消息进行语义分析后，获得的语义分析结果除包括用户意图外，还包括意图类别，如与直播内容有关的用户意图（如针对电子商务这类意图还可以细分为商品推荐、商品属性、商品尺码、热门问题、通用问题、优惠券、直播间折扣等）、与直播针对的目标对象有关的用户意图、与直播的主播有关的用户意图、违规用户意图等，其中，所述违规用户意图有可能为涉黄赌毒、不良言论、迷信丑恶暴力、歧视、涉政、意思欺骗用语等意图类别。通过意图类别，可以对评论消息进行有效的区分，以为后续数据处理提供准确的依据。
77.基于此，进一步地，可以根据意图类别对评论消息进行再次过滤，获得再次过滤后的评论消息及再次过滤后的评论消息对应的用户意图。例如，通过再次过滤，过滤掉涉黄赌毒、不良言论、迷信丑恶暴力、歧视、涉政、意思欺骗用语等意图类别对应的评论消息，则剩下的评论消息及其对应的用户意图将是对后续数据处理有效的评论消息和用户意图。
78.步骤s406：根据用户意图对评论消息进行聚类，获取至少一个意图聚类结果。
79.本实施例中，获得的意图聚类结果可以包括以下至少之一：大于预设数量的评论消息对应的意图聚类结果、针对直播内容中的重点内容的评论消息对应的意图聚类结果、针对直播内容中的重点直播对象的评论消息对应的意图聚类结果、针对直播内容中的直播对象的重点属性的评论消息对应的意图聚类结果。
80.其中，预设数量的具体数值可由本领域技术人员根据实际情况适当设置，本技术实施例对此不作限制。例如，在100条评论消息中存在30条均是询问单价及优惠的评论消息，则聚类结果中将包含此类评论消息对应的意图聚类结果。
81.而在直播中，主播会针对需要宣传或推广的内容进行重点播放，例如，被反复播放的内容或者播放占用时间较长的内容等，相对应地，这部分重点内容也会有更多用户关注并发表评论消息，这部分评论消息对应的意图聚类结果也会成为获得的意图聚类结果以进行后续展示的一部分。
82.类似地，直播内容中还可能存在重点直播对象，如多个商品中的某个或某些商品，针对这些重点直播对象也将会有更多的评论消息，这部分评论消息对应的意图聚类结果可能为获得的意图聚类结果以进行后续展示的一部分。
83.而直播对象通常会有多种属性，例如，内容类型、人物、场景、材质、型号、单价、优惠等等，在诸如商品推广的直播中，单价及优惠通常可被认为是重点属性，对应的评论消息也会较多，相应的意图聚类结果也会成为获得的意图聚类结果以进行后续展示的一部分。再例如内容推广的直播中，如视频内容推广的直播中，内容类型、演员人物等会成为用户的重要关注点，对应的评论消息也会更多一些，相应的意图聚类结果也会成为获得的意图聚类结果以进行后续展示的一部分。
84.但本领域技术人员应当明了的是，上述多种意图聚类结果以及各种意图聚类结果中可能涉及的信息均为示例性说明，在实际应用中，还可以有其它意图聚类结果类型及涉及的其他适用信息。
85.由上可见，在实际应用中，获得的意图聚类结果可能包括多个，则在一种可行方式中，还可以根据每个意图聚类结果对应的评论消息的数量和预设的权重，对多个意图聚类结果进行排序；根据排序结果从多个意图聚类结果中筛选出待展示的意图聚类结果。后续，在需要在直播内容的直播界面展示意图聚类结果时，只需在直播内容的直播界面展示待展示的意图聚类结果即可。其中，不同的意图聚类结果对应的权重可由本领域技术人员根据意图相对于直播内容的重要程度进行设定，例如，针对电子商品类的直播，其单价、优惠、效果等通常被关注得较多，可以基于此结合其它的可能意图聚类结果分别进行权重设置，进而，在直播过程中，基于各意图聚类结果对应的评论消息的数量和预设的权重进行排序，将排序为top n的意图聚类结果作为待展示的意图聚类结果。其中，n可由本领域技术人员适当设置，如为10等，本技术实施例对此不作限制。
86.进一步可选地，可以先根据排序结果从多个意图聚类结果中筛选出候选意图聚类
结果；对候选意图聚类结果按照预设的模式进行规范化处理；再基于规范化处理的结果，确定待展示的意图聚类结果。其中，预设的模式可以为预设的模板，也可以为预设的数据处理规则。例如，预设的模板可以为基于意图聚类结果生成的便于主播理解和阅读的模板，如，“亲，观众现在更多关注
……
，请介绍一下”，其中的省略号部分为由意图聚类结果替换的部分，可以为每个意图聚类结果根据该模板生成一条重点消息，也可以采用部分意图聚类结果结合的形式，根据该模板生成重点消息。而预设的数据处理规则，则可以基于获得的意图聚类结果，为其添加或修改文案，并且，还可以设置文本的显示方式，如字体、大小、颜色等，以起到醒目显示的效果。
87.此外，在实际应用中，对于每个直播应用或直播平台，通常会存在超级主播，如直播会吸引成千甚至上万的观众用户的主播，为避免类似情况下造成的数据处理时延甚至崩溃，一种可行方式中，在根据用户意图对评论消息进行聚类，获取至少一个意图聚类结果时，可以按照预设的聚类参数对评论消息进行聚类；根据聚类结果中评论消息的数量大于预设数量的聚类结果，获得多个评论聚类热点；根据评论聚类热点和预设的计算任务节点的数量对评论消息进行分组，根据分组结果及分组内的评论消息对应的用户意图，获得对应的至少一个意图聚类结果。其中，不同的处理方式下聚类参数不同，本技术实施例对聚类参数的具体数据形式及数值不作限定，只需能够去除数据热点，将数据平均分散至不同任务节点即可。这样，多个任务节点可以进行均衡处理，避免单节点任务过重而导致的异常或崩溃。示例性地，以使用blink技术进行处理为例，可以通过minibatch和aggregate这两个聚类参数对评论消息的聚类过程进行优化，均衡算力。
88.步骤s408：根据确定的展示方式，通过直播内容的直播信息界面展示意图聚类结果。
89.通过展示意图聚类结果既可以使主播及时了解用户意图，若存在针对主播的直播内容或直播行为的用户意图，主播也可根据这些用户意图，及时调整自己的直播内容或直播行为，以满足观众用户需求，取得较好的直播效果。
90.直播信息界面的展示方式的具体确定及展示实现，可参照前述实施例一或二中相关部分的描述，在此不再赘述。
91.以下，以一个示例对上述过程进行示例性说明，如图4b所示。
92.本示例的场景中，主播点击开播并进行推流后，观众用户即可进入到直播间，然后，主播便可以和观众用户通过评论消息进行交互，如闲聊、介绍商品、回答观众用户的问题、和观众用户做互动等等，从而产生实时的评论消息。
93.基于实时产生的评论消息，本示例中的数据处理过程包括：数据埋点、数据计算、算法模型处理、数据存储、重点消息展示五个部分。以下，分别进行说明。
94.过程1、数据埋点即将每个直播间的观众用户发表的评论消息进行埋点、然后采集到消息队列或tt日志中供后续的实时数据计算任务订阅。图4b中示意为采集到tt日志中。
95.过程2、数据计算在订阅到直播间的实时评论消息后，首先做第一层数据清洗工作，将里面的脏数据过滤掉，如通过关键词匹配的方式等，针对空字符、特殊字符、测试数据、恶意攻击数据、前置算法识别为闲聊的数据等进行过滤。
96.过程3、算法模型处理本过程中，将经过脏数据过滤后的评论消息作为入参，通过udf的方式调用语义分析的算法模型进行语义识别，获得评论消息对应的用户意图及意图类别。可选地，还可获得用户意图对应的权重，和/或，对评论消息进行规范化处理后的结果。然后，根据意图类别，再次进行一层清洗，即第二层清洗，以过滤掉算法识别的涉黄赌毒、不良言论、迷信丑恶暴力、歧视、涉政、意思欺骗用语等数据。最后，将原评论消息、规范化处理后的评论消息、用户意图、意图类别、权重等相关信息输出。
97.因本示例中存在直播信息界面的两种展示方式，因此，算法模型的处理也存在着不同。
98.其中，针对第一种主动推送的方式，即通过滚动窗口周期性自动更新展示意图聚类结果的方式，基于滚动窗口（其中，窗口时间即预设的时间间隔周期可以自由调整，比如1分钟、5分钟等）的设置进行计算处理，如将窗口时间内的评论消息进行语义分析，基于语义分析获得的用户意图进行聚类，然后根据聚类获得的意图聚类结果对应的评论消息的数量、权重等参数做top n处理，将数量高、权重高的n条意图聚类结果进行规范化、整合化后返回，然后写入到下游日志（比如tt、metaq等）中，供下游工程端订阅。
99.针对第二种触发发送的方式，即通过滑动窗口基于主播的输入触发发送意图聚类结果进行展示的方式，基于滑动窗口（滑动窗口的size 和 slide都是可调整的，比如size为5分钟，slide为15秒，即每过15秒会进行一次最近5分钟的评论消息的处理）；将窗口时间内的评论消息进行语义分析获得用户意图，基于用户意图进行聚类，然后根据聚类获得的意思聚类结果对应的评论消息的数量、权重等指标做top n处理，将数量高、权重高的n条意图聚类结果规范化、整合化处理并返回，然后写入到下游olap/nosql等数据库（比如adb、holo、hbase、lindorm等，包含不局限于以上两种数据库）中。在一个示例中，当主播在直播间通过终端屏幕进行左滑操作时，会调用相关工程端的接口，然后查询该直播间最新的重点消息（即意图聚类结果），返回后展示到左滑窗口中。
100.其中，对于头部主播（流量较大的主播）的直播间，在对实时评论消息进行数据处理时，由于单个直播间的流量相比总流量占比较大，可能会有计算任务节点热点问题。为此，可以：（1）首先对聚类参数进行设置以进行数据处理优化。以blink为例，可以增加window窗口的minibatch、aggregate等优化策略。但不同的数据处理方式中，进行优化处理的聚类参数可能不同，例如，spark streaming可以为微批处理。因影响数据处理性能的因素主要包括代码的质量和batch duration优化值的设置，因此，不管是通过配置参数、还是调整代码，能够去除数据热点、将数据均匀分配，以及分多层聚合去重即可。（2）然后再做数据热点打散。例如，可以使用hash_code离散函数来分离数据热点，再使用mod函数对hash_code获得的哈希值进行分组操作（示例：mod(hash_code(x)，n)，其中，x表示数据指标中分布比较均匀的一个字段，n是平均分多少个任务节点如线程节点等），这样做可以有效的将数据均衡地打散到每一个任务节点上，避免个别的任务节点的数据量堆积导致数据倾斜，然后再按照维度进行group agg。由上，即可有效避免数据热点导致的数据处理异常或崩溃问题。
101.过程4、数据存储如前所述，本示例中，因存在直播信息界面的两种展示方式，因此，针对不同的展
示方式设置了不同的数据存储方式。其中，第一种主动推送的方式，即通过滚动窗口周期性自动更新展示意图聚类结果的方式，设定存储介质为日志、消息队列类型，支持下游用户订阅，并且上游有数据写入时直接推送到下游场景中；而第二种触发发送的方式，即通过滑动窗口基于主播的输入触发发送意图聚类结果进行展示的方式，设定存储介质为关系型或非关系型数据库如olap/nosql等数据库，以支持主播根据查询条件查询获得需要的数据。
102.过程5、重点消息展示仍如前所述，本示例中的直播信息界面存在两种展示方式。
103.针对第一种主动推送的方式，即通过滚动窗口周期性自动更新展示意图聚类结果的方式，由工程端主动订阅tt日志，获得重点消息后，主动封装推送到主播端，通过滚动窗口进行展示，展示效果如图3a所示，在直播间的左下角评论区的上方做重点消息弹出，图3a中示意为在用户评论区的上层展示，重点消息本身也会做视觉强化处理，提升主播体验。
104.针对第二种触发发送的方式，即通过滑动窗口基于主播的输入触发发送意图聚类结果进行展示的方式，需要主播主动发起触发操作才会展示（即被动）。示例性地，主播在直播间界面的屏幕上进行左滑操作，会出现一个浮层，包含重点消息、商品热度、活跃用户三个tab，再点击重点消息就会展示最近n分钟的重点消息，此处同样会做视觉强化处理，提升主播体验。
105.当新手主播开播如果直播间没有评论消息、或者没有有效评论消息的情况下，可以设置默认文案，比如“亲、直播间暂无重点消息，请多播一会，敬请期待”。
106.由此，即使对于一次直播的评论消息达到qps千万以上的主播，也可快速获得用户意图，及时做出回复、响应等，提升直播体验。
107.通过本实施例，基于实时评论消息、消息队列或tt日志、数据过滤等，可以使得整个实时直播数据处理的延迟控制在秒级，以便主播可以做出及时响应和回复，提升主播和观众用户的体验。基于两种展示方式，可以使主播对用户意图的获取具有更大的灵活性和自主性，进一步提升了用户和主播体验。
108.实施例四参照图5，示出了根据本技术实施例四的一种实时直播数据处理方法的步骤流程图。
109.本实施例从主播端的直播界面角度对本技术实施例提供的实时直播数据处理方法进行说明，该实时直播数据处理方法包括以下步骤：步骤s502：在直播界面展示直播内容及用户在观看直播内容的过程中输入的评论消息。
110.不管是直播应用还是直播平台，均提供有直播间，通过该直播间，主播进行直播操作，生成直播内容并通过直播界面展示；观众用户观看直播内容，并且，在观看过程中可以输入评论消息，以与主播进行交互。
111.步骤s504：在确定评论意图提示条件满足时，在直播界面展示根据评论消息生成的用户意图提示消息。
112.直播应用或直播平台预先设置有评论意图提示条件，以在该条件满足时，通过主播端的直播界面向主播展示基于评论消息生成的用户意图提示消息。
113.其中，评论意图提示条件可由本领域技术人员根据实际需求适当设置，例如，可以
是默认条件满足，则可实时或者根据展示方式设置来展示用户意图提示消息；当然，也可以是预先设定条件，在该条件满足时，展示用户意图提示消息。在一种可行方式中，用户意图提示消息可以根据如前述实施例一至三中任一实施例所述的方法获得的意图聚类结果生成。
114.通过本实施例，在用户意图显示层面，当评论意图提示条件满足时，即可在直播界面展示根据用户的评论消息生成的用户意图提示消息。由此，可以使得消息获取端如直播的主播等及时了解可表达用户核心诉求和想法的用户意图，并进行及时处理，以及时且有效的满足用户需求，同时提升用户和主播的体验，增加用户和主播粘性。
115.实施例五参照图6a，示出了根据本技术实施例五的一种实时直播数据处理方法的步骤流程图。
116.本实施例仍从主播端的直播界面角度对本技术实施例提供的实时直播数据处理方法进行说明，该实时直播数据处理方法包括以下步骤：步骤s602：展示直播界面。
117.步骤s604：在直播界面展示直播内容及用户在观看所述直播内容的过程中输入的评论消息。
118.其中，该评论消息的形式包括但不限于：文本消息、语音消息、图像消息、表情消息等。其中的语音消息、图像消息、表情消息均可转换为文本消息后进行后续的处理。
119.步骤s606:在确定评论意图提示条件满足时，在直播界面展示根据评论消息生成的用户意图提示消息。
120.在一种可行方式中，可以根据评论意图提示条件的类型，在确定评论意图提示条件满足时，按照与所述类型相匹配的展示方式，在直播界面展示根据评论消息生成的用户意图提示消息。通过为评论意图提示条件设置不同的类型，可以实现更为灵活的展示方式设置。
121.例如，当评论意图提示条件为默认条件满足状态时，则确定评论意图提示条件满足并接收通过主动推送方式发送来的根据评论消息生成的用户意图提示消息，并通过直播界面展示用户意图提示消息。此种方式中，可以由后端如工程端主动向直播应用主动推送用户意图提示消息，主播端接收到用户意图提示消息后默认条件满足，无需再进行进一步的判断，即可展示用户意图提示消息，由此，简化了主播端的操作，减轻了主播操作负担，且实现较为简单，实现成本低。
122.在具体展示时，可以实时展示，但较优地，可以采用前述多个实施例中描述的基于主动推送的展示方式，即采用滚动窗口的方式，每隔预设的时间间隔周期，自动更新展示。其具体实现可参照前述多个实施例中相关部分的描述，在此不再赘述。
123.针对用户意图提示消息的呈现，也即，在通过直播界面展示用户意图提示消息，可选地，可以实现为：在直播界面展示的评论消息的上层，按照预设格式对用户意图提示消息进行视觉强化处理并展示，其中，所述预设格式包括以下至少之一：字体类型格式、字体颜色格式、字体大小格式。由此，实现用户意图提示消息的重点显示和提醒。
124.在另一种可行方式中，根据评论意图提示条件的类型，在确定评论意图提示条件满足时，按照与所述类型相匹配的展示方式，在直播界面展示根据评论消息生成的用户意
图提示消息可以实现为：接收主播输入的用于指示进行评论意图提示的触发操作；根据触发操作确定评论意图提示条件满足，并响应于触发操作获取根据评论消息生成的用户意图提示消息；通过浮层在直播界面上展示用户意图提示消息。
125.其中，所述触发操作包括但不限于以下之一：手势触发操作、语音触发操作、界面选项触发操作。手势触发操作为基于主播端显示屏幕的手势操作，如左滑、右滑、双击、多击等与手势有关的操作；语音触发操作为通过语音发送触发指令的操作形式，如通过语音关键字“用户意图”等；界面选项触发操作为基于直播界面中相应的选项，如按钮、勾选项等进行的触发操作。通过触发操作，为主播控制用户意图提示消息的展示提供了便利。
126.基于此，只要接收到主播进行了触发操作后，才会认为评论意图提示条件满足，进而进行后续展示操作。
127.在通过浮层在直播界面上展示用户意图提示消息时，同样可以按照预设格式对用户意图提示消息进行视觉强化处理，并通过浮层在直播界面上展示用户意图提示消息，其中，所述预设格式包括以下至少之一：字体类型格式、字体颜色格式、字体大小格式。
128.此外，为了提高展示效率，丰富数据展示的维度，在一种可行方式中，可以在直播界面上渲染绘制浮层，浮层中包含多个标签页，多个标签页包括用于显示用户意图提示消息的标签页、用于显示直播内容热度的标签页、用于显示用户活跃度的标签页；进而，根据对用于显示用户意图提示消息的标签页的选择操作，在直播界面上展示用户意图提示消息。一种具体示例界面如图3b中所示。需要说明的是，在实际应用中，标签页的数量及展示的除用户意图提示消息之外的内容，均可由本领域技术人员根据实际需求设置。而相对来说，直播内容热度和用户活跃度对于主播播放行为的效果评价更具参考意义。
129.对于某些主播新手来说，其可能无法收到充分的有效评论消息，此种情况下，若未接收到用户输入的有效评论消息，则在确定评论意图提示条件满足时，在直播界面展示预先设置的默认用户意图提示消息，比如“亲、直播间暂无重点消息，请多播一会，敬请期待”，以提升其直播信心，提高其直播体验。
130.以下，以一个电商直播场景为示例，对上述过程进行示例性说明，如图6b所示。
131.图6b中，假设，主播x通过直播间售卖某一品牌的手机，因观众用户较多，为避免遗漏或者不能及时回复观众用户的评论消息，主播x在直播开始时，通过主播端的显示屏幕在直播界面上进行了左滑操作。直播应用基于该左滑操作确定评论意图提示条件被满足了，将会进行相应的响应提示，如弹出提示信息“用户意图将会及时提醒您”，或者，该提示消息也可通过语音形式播放，以告知主播其触发操作已被响应。
132.接着，直播界面上层将会显示一个浮层，在该浮层中每隔一分钟更新一次用户意图提示消息，每次显示五条用户意图提示消息，且相邻两次显示的用户意图提示消息中存在重叠部分。如图6b中所示，在第一个一分钟，通过浮层向主播x显示用户意图提示消息1-5，在第二个一分钟，通过浮层向主播x显示用户意图提示消息4-8，在第三个一分钟，通过浮层向主播x显示用户意图提示消息7-11，依次类推，直至直播结束或者主播x在直播过程中又进行了右滑操作。本示例中，设定右滑操作用于指示停止用户意图提示消息的显示。主播x通过浮层中显示的不断更新的用户意图提示消息，可以观众用户关心的问题，并及时做出回复。
133.而如果主播x未进行上述左滑操作，则直播应用可采用另一方式进行用户意图提
示消息的显示，如图6b中下半部分的多个虚线框所示。也即，主播x进入直播间后未进行任何操作，此种情况下，若直播应用中使用评论意图提示条件默认满足的方式，则当开播后，在直播界面中的评论消息的上层，会显示一个小弹窗，每隔一定的时间间隔如一分钟更新一次显示的用户意图提示消息，且相邻两次显示的用户意图提示消息完全不同。由此，即使主播不进行任何操作，也可及时了解观众用户的意图，并及时做回复。但不限于此，若主播x不希望显示用户意图提示消息，也可通过相应的操作关闭该功能，如点击弹窗中的关闭按钮，或者上滑操作或下滑操作，等等。
134.通过本实施例，在用户意图显示层面，当评论意图提示条件满足时，即可在直播界面展示根据用户的评论消息生成的用户意图提示消息。由此，可以使得消息获取端如直播的主播等及时了解可表达用户核心诉求和想法的用户意图，并进行及时处理，以及时且有效的满足用户需求，同时提升用户和主播的体验，增加用户和主播粘性。
135.实施例六参照图7，示出了根据本技术实施例六的一种电子设备的结构示意图，本技术具体实施例并不对电子设备的具体实现做限定。
136.如图7所示，该电子设备可以包括：处理器(processor)702、接收器704、发送器706。除此之外，在实际应用中，该电子设备还可以包括通信接口(communications interface)708、存储器(memory)710、以及通信总线712。
137.其中：处理器702、接收器704、发送器706、通信接口708、以及存储器710通过通信总线712完成相互间的通信。
138.接收器704，用于接收用户在观看直播内容过程中输入的评论消息，并发送至处理器702。
139.处理器702，用于执行程序714，具体可以执行上述方法实施例一至三中任意一个所述的实时直播数据处理方法的相关步骤。例如，用于实时获取评论消息；对预设时间范围内的评论消息进行语义分析，根据语义分析的结果获取评论消息对应的用户意图；根据用户意图对评论消息进行聚类，获取至少一个意图聚类结果。
140.发送器706，用于将意图聚类结果发送至主播端的用户设备，以通过主播端的用户设备在直播内容的直播界面展示意图聚类结果。
141.通信接口708，用于与其它电子设备或服务器进行通信。
142.具体地，程序714可以包括程序代码，该程序代码包括计算机操作指令。
143.处理器702可能是cpu，或者是特定集成电路asic（application specific integrated circuit），或者是被配置成实施本技术实施例的一个或多个集成电路。智能设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个cpu；也可以是不同类型的处理器，如一个或多个cpu以及一个或多个asic。
144.存储器710，用于存放程序714。存储器710可能包含高速ram存储器，也可能还包括非易失性存储器（non-volatile memory），例如至少一个磁盘存储器。
145.程序714具体可以用于使得处理器702执行上述方法实施例一至三中任意一个所述的实时直播数据处理方法对应的操作。
146.程序714中各步骤的具体实现可以参见上述实时直播数据处理方法实施例一至三
中的相应步骤和单元中对应的描述，并具有相应的有益效果，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。
147.实施例七参照图8，示出了根据本技术实施例七的一种电子设备的结构示意图，本技术具体实施例并不对电子设备的具体实现做限定。
148.如图8所示，该电子设备可以包括：处理器(processor)802、输入装置804、显示器806。除此之外，在实际应用中，该电子设备还可以包括通信接口(communications interface)808、存储器(memory)810、以及通信总线812。
149.其中：处理器802、输入装置804、显示器806、通信接口808、以及存储器810通过通信总线812完成相互间的通信。
150.输入装置804，用于接收用户在观看直播内容过程中输入的评论消息，并发送至处理器802。
151.处理器802，用于执行程序814，具体可以执行上述方法实施例四至五中任意一个所述的实时直播数据处理方法的相关步骤。例如，用于将直播内容及评论消息发送至显示器806，以使显示器806在直播界面展示直播内容及所述评论消息；以及，在确定评论意图提示条件满足时，获取根据评论消息生成的用户意图提示消息。
152.显示器806，还用于在直播界面展示用户意图提示消息。
153.通信接口808，用于与其它电子设备或服务器进行通信。
154.具体地，程序814可以包括程序代码，该程序代码包括计算机操作指令。
155.处理器802可能是cpu，或者是特定集成电路asic（application specific integrated circuit），或者是被配置成实施本技术实施例的一个或多个集成电路。智能设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个cpu；也可以是不同类型的处理器，如一个或多个cpu以及一个或多个asic。
156.存储器810，用于存放程序814。存储器810可能包含高速ram存储器，也可能还包括非易失性存储器（non-volatile memory），例如至少一个磁盘存储器。
157.程序814具体可以用于使得处理器802执行上述方法实施例四至五中任意一个所述的实时直播数据处理方法对应的操作。
158.程序814中各步骤的具体实现可以参见上述实时直播数据处理方法实施例四至五中的相应步骤和单元中对应的描述，并具有相应的有益效果，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。
159.本技术实施例还提供了一种计算机程序产品，包括计算机指令，该计算机指令指示计算设备执行上述多个方法实施例中的任一实时直播数据处理方法对应的操作。
160.需要指出，根据实施的需要，可将本技术实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本技术实施例的目的。
161.上述根据本技术实施例的方法可在硬件、固件中实现，或者被实现为可存储在记
录介质（诸如cd rom、ram、软盘、硬盘或磁光盘）中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件（诸如asic或fpga）的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件（例如，ram、rom、闪存等），当所述软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的实时直播数据处理方法。此外，当通用计算机访问用于实现在此示出的实时直播数据处理方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的实时直播数据处理方法的专用计算机。
162.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术实施例的范围。
163.以上实施方式仅用于说明本技术实施例，而并非对本技术实施例的限制，有关技术领域的普通技术人员，在不脱离本技术实施例的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本技术实施例的范畴，本技术实施例的专利保护范围应由权利要求限定。