CN110233745A - 管理群消息的方法及装置 - Google Patents
管理群消息的方法及装置 Download PDFInfo
- Publication number
- CN110233745A CN110233745A CN201910507182.4A CN201910507182A CN110233745A CN 110233745 A CN110233745 A CN 110233745A CN 201910507182 A CN201910507182 A CN 201910507182A CN 110233745 A CN110233745 A CN 110233745A
- Authority
- CN
- China
- Prior art keywords
- topic
- group
- user
- message
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1818—Conference organisation arrangements, e.g. handling schedules, setting up parameters needed by nodes to attend a conference, booking network resources, notifying involved parties
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
- H04L51/046—Interoperability with other network applications or services
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本说明书实施例提供一种管理社交应用中的群消息的方法和装置。根据该方法,服务端预先通过增量归类的方式,将各条群消息归类为群话题。当用户请求获取群话题时,客户端向服务端发出获取群话题的请求。服务端获取用户群中已形成的各个群话题的摘要,并根据用户特征对各个话题进行排序,将摘要信息和排序信息返回给客户端。客户端按照排序信息中的顺序,以摘要的形式展示各个话题,从而便于用户高效处理群消息。
Description
技术领域
本说明书一个或多个实施例涉及社交应用工具,尤其涉及对社交应用中的群消息进行管理的方法和装置。
背景技术
通讯类社交应用或软件,例如钉钉,微信,QQ,Line等等,已经成为人们生活聊天,兴趣讨论以及工作交流的重要工具。许多社交应用支持用户群的功能,例如钉钉群,微信群,QQ群等。一个用户群中包含多个用户,群中的用户又称为群成员。群成员在群中发布的消息称为群消息,群消息会发布给群中的所有用户。
随着用户加入的群越来越多,用户常常在社交应用中收到大量群聊天消息。相比于单人聊天的消息,群消息数量众多,参与人员广泛,而且往往与用户自身的相关程度较低。这些特点导致用户往往难以高效地浏览和处理这些群消息。逐条浏览群消息将会导致大量的时间浪费,完全忽视又容易错过一些重要的或者感兴趣的讨论内容。
因此,希望能有改进的方案,可以帮助用户更好地浏览和处理群消息。
发明内容
本说明书一个或多个实施例描述了对社交应用中的群消息进行话题化管理的方法和装置,从而帮助用户有效地浏览和处理群消息。
根据第一方面,提供了一种管理群消息的方法,通过服务端执行,所述方法包括:
从客户端接收第一用户进行群操作的第一请求;
根据所述第一请求确定第一用户群;
获取所述第一用户群中已形成的N个话题,所述N个话题是基于所述第一用户群中各条群消息的内容和回复关系,对所述各条群消息进行归类而形成;
获取所述N个话题中各个话题的摘要信息;
根据所述第一用户的用户特征,确定所述N个话题的排序信息;
向客户端提供所述N个话题的摘要信息以及排序信息。
在一个实施例中,第一请求用于请求进入第一用户群,相应的,第一请求中包括所述第一用户的用户标识和第一用户群的群标识;在这样的情况下,确定第一用户群包括,根据所述群标识,确定所述第一用户群。
在一个实施例中,所述第一请求用于请求获取第一用户群的群话题,相应的,第一请求中包括所述第一用户的用户标识和所请求的第一用户群的群标识;在这样的情况下,确定第一用户群包括,根据所述群标识,确定所述第一用户群。
在另一实施例中,所述第一请求用于请求启动话题获取功能,其中包括所述第一用户的用户标识;在这样的情况下,确定第一用户群包括,根据所述用户标识,确定所述第一用户对应的至少一个用户群,所述至少一个用户群为:
所述第一用户所加入的全部用户群;或者,
所述第一用户标注为关注的用户群;或者,
所述第一用户所加入的用户群中有未读新消息的用户群;
所述第一用户群为所述至少一个用户群中任意的一个用户群。
根据一种实施方式,获取所述第一用户群中已形成的N个话题包括:
获取针对所述第一用户群形成的已有话题;
对于各个已有话题,确定其最后更新时间距离当前时刻的时长;
将所述时长小于预设时长阈值的话题,作为所述N个话题。
在一种实施方式中,方法还包括,获取所述N个话题中各个话题的统计信息,以及向客户端提供所述N个话题的统计信息;其中,所述统计信息包括以下中的一项或多项:归类到对应话题的消息集合中群消息的总数量,归类到对应话题的消息集合中特定类型的群消息的数量,参与该话题的用户数目,该话题的最后更新时间。
根据一种实施方式,对于所述N个话题中任意的第一话题,获取摘要信息包括:
确定归类到第一话题的第一消息集合中各条群消息的各个消息部分对应的特征向量;
根据所述特征向量,从所述各个消息部分中选择具有语义代表性的第一消息部分;
将所述第一消息部分的信息作为所述第一话题对应的第一摘要信息。
进一步地,在各种实施例中,所述各个消息部分可以为各条消息;或者为各条消息中的各个句子;所述第一摘要信息可以包括,所述第一消息部分在群消息中的编号。
在一个具体实施例中,通过以下方式从各个消息部分中选择具有语义代表性的第一消息部分:
根据所述各个消息部分对应的各个特征向量,确定两两消息部分之间的语义相关度;
根据两两消息部分之间的语义相关度,确定每个消息部分与其他消息部分整体的综合相关度得分;
选择综合相关度得分最高的消息部分作为所述第一消息部分。
在另一具体实施例中,通过以下方式从各个消息部分中选择具有语义代表性的第一消息部分:
根据所述各个消息部分对应的各个特征向量,确定各个特征向量的中心向量作为语义中心;
从各个消息部分中,确定出其特征向量与所述中心向量相似度最高的消息部分作为所述第一消息部分。
在一种实施方式中,对于所述N个话题中任意的第一话题,获取摘要信息包括:读取预先确定的所述第一话题对应的第一摘要信息。
进一步地,上述第一摘要信息可以基于形成所述第一话题时的群消息而确定;或者,可以基于归类到所述第一话题的消息集合中预定数目的群消息而确定。
在一个实施例中,第一用户的用户特征包括所述第一用户在所述第一用户群中的群角色;相应地,根据所述第一用户的用户特征,确定所述N个话题的排序信息,包括:根据所述群角色,确定所述第一用户与各个话题中包含的群消息的发送者之间的角色关系,根据所述角色关系确定各个话题的相对排序。
在另一实施例中,第一用户的用户特征包括,对话题排序的设置特征;相应的,根据所述第一用户的用户特征,确定所述N个话题的排序信息包括,根据所述设置特征,确定所述N个话题的排序信息。
根据第二方面,提供一种管理群消息的方法,通过客户端执行,所述方法包括:
接收第一用户进行群操作的第一操作指令;
向服务端发送与所述第一操作指令对应的第一请求;
从服务端接收该第一用户所加入的第一用户群中已形成的N个话题的话题信息,所述话题信息包括摘要信息以及排序信息;
按照所述排序信息中指示的顺序,根据所述摘要信息显示所述N个话题的话题摘要。
在一个实施例中,第一操作指令为进入第一用户群的操作指令,所述第一请求中包括所述第一用户的用户标识和第一用户群的群标识。
在一个实施例中,上述第一操作指令为获取所述第一用户群的群话题的操作指令,所述第一请求包括所述第一用户的用户标识和第一用户群的群标识。
在另一实施例中,上述第一操作指令为启动话题获取功能的操作指令,用于获取所述第一用户对应的至少一个用户群中的群话题,所述至少一个用户群为:
所述第一用户所加入的全部用户群;或者
所述第一用户标注为关注的用户群;或者
所述第一用户所加入的用户群中有未读新消息的用户群;
所述至少一个群包括所述第一用户群。
根据一种实施方式,所述N个话题包括第一话题,所述摘要信息包括,被确定为第一话题的话题摘要的第一消息部分在群消息中的编号;相应地,根据所述摘要信息显示所述N个话题的话题摘要包括:
根据所述编号获取所述第一消息部分对应的第一文本;
显示所述第一文本作为所述第一话题的话题摘要。
在一种实施方式中,所述话题信息还包括话题统计信息,所述方法还包括,显示所述N个话题中各个话题的话题统计信息;其中,所述话题统计信息包括以下中的一项或多项:归类到对应话题的消息集合中群消息的总数量,归类到对应话题的消息集合中特定类型的群消息的数量,参与该话题的用户数目,该话题的最后更新时间。
根据一种实施方式,在显示所述N个话题的话题摘要之后,还包括:
接收所述第一用户的第二操作指令,所述第二操作指令用于展开所述N个话题中的第一话题;
显示归类到所述第一话题中的各条群消息。
根据另一种实施方式,在显示所述N个话题的话题摘要之后,还包括:
接收所述第一用户的第三操作指令,所述第三操作指令用于针对所述N个话题中的第一话题进行回复;
接收用户针对所述第一话题输入的第一回复消息;
将所述第一回复消息标记为针对所述第一话题。
根据第三方面,提供一种管理群消息的装置,部署在服务端中,所述装置包括:
请求接收单元,配置为从客户端接收第一用户进行群操作的第一请求;
用户群确定单元,配置为根据所述第一请求确定第一用户群;
话题获取单元,配置为获取所述第一用户群中已形成的N个话题,所述N个话题是基于所述第一用户群中各条群消息的内容和回复关系,对所述各条群消息进行归类而形成;
摘要获取单元,配置为获取所述N个话题中各个话题的摘要信息;
排序单元,配置为根据所述第一用户的用户特征,确定所述N个话题的排序信息;
信息提供单元,配置为向客户端提供所述N个话题的摘要信息以及排序信息。
根据第四方面,提供一种管理群消息的装置,部署在客户端中,所述装置包括:
指令接收单元,配置为接收第一用户进行群操作的第一操作指令;
请求发送单元,配置为向服务端发送与所述第一操作指令对应的第一请求;
信息接收单元,配置为从服务端接收该第一用户所加入的第一用户群中已形成的N个话题的话题信息,所述话题信息包括摘要信息以及排序信息;
显示单元,配置为按照所述排序信息中指示的顺序,根据所述摘要信息显示所述N个话题的话题摘要。
根据第五方面,提供了一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行第一方面和第二方面的方法。
根据第六方面,提供了一种计算设备,包括存储器和处理器,其特征在于,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现第一方面和第二方面的方法。
根据本说明书实施例提供的方法和装置,服务端通过增量归类的方式,将各条群消息归类为群话题。当用户请求获取群话题时,获取各个群话题的摘要,并根据用户特征对各个话题进行排序,将摘要信息和排序信息返回给客户端。客户端按照排序信息中的顺序,以摘要的形式展示各个话题,从而使得用户可以快速、高效地浏览群消息的讨论内容,便于用户及时有效地进行响应和处理,极大地提升用户体验。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1示出根据一个实施例的社交应用中群消息的场景示意图;
图2示出根据一个实施例管理群消息的方法的执行流程;
图3示出用户发出获取群话题的操作指令的一个例子;
图4示出用户发出获取群话题的操作指令的另一个例子;
图5示出根据一个实施例获取群话题的步骤流程;
图6示出根据一个实施例客户端显示的话题信息的界面示意图;
图7示出根据一个实施例部署在服务端中的群消息管理装置的示意性框图;
图8示出根据一个实施例部署在客户端中的群消息管理装置的示意性框图。
具体实施方式
下面结合附图,对本说明书提供的方案进行描述。
在群聊场景下,群消息数量众多,信息庞杂,参与人员广泛,使得用户难以快速获得群中讨论内容的有效信息,难以进行高效地浏览和响应。为了帮助用户有效浏览和响应用户群中的消息,根据本说明书实施例的构思,提出根据群消息的内容和回复关系,将各条群消息归类到群话题。当用户进入某个已加入的用户群时,可以通过呈现当前群中讨论的群话题,帮助用户快速获知群中讨论的内容,进而帮助用户进行高效地浏览和响应。
图1示出根据一个实施例的社交应用中群消息的场景示意图。图1示出在一个用户群中的一段群聊消息的示例。在这个示例中,共有15条消息。可以看到,一个用户群中参与用户众多,群消息数量众多,消息更新很快,使得用户难以有效进行管理。根据本说明书的实施例,可以对这15条消息进行归类,得到2个正在讨论的话题。并且,对这2个话题提炼摘要,通过摘要的形式分别表示各个话题。例如可以如下表示各个话题:
话题1:“国际6楼,空调又坏啦”,
话题2:“ant gitlab是哪个团队在维护?”
通过以上的方式,将群消息归类为话题并将话题摘要显示给用户,使得用户可以一目了然地知晓,目前群中正在讨论的内容,帮助用户高效地对群消息进行浏览和响应。
下面描述以上效果的具体实现方式。
图2示出根据一个实施例管理群消息的方法的执行流程。该执行流程涉及客户端和服务端,其中客户端安装于用户终端中,与用户直接进行交互,用于接收用户输入,向用户呈现结果;服务端用于对群消息进行后台处理和管理,包括话题归类,摘要提取,话题拉取等,并将群消息管理结果返回给客户端。
在一个实施例中,群消息的管理功能可以由相应社交应用本身提供,例如,钉钉,微信,Line,等等。在这样的情况下,上述客户端即社交应用的应用客户端,服务端为社交应用的服务器。
在另一实施例中,群消息的管理功能可以由第三方服务方提供,例如,第三方可以基于钉钉开放的接口,开发出钉钉“群聊小助手”之类的管理工具,由用户选择性地进行安装,从而嵌入到钉钉中。又例如,第三方可以开发微信小程序,实现群聊管理功能,嵌入到微信中。这样的第三方管理工具也可以分为客户端和服务端,其中客户端嵌入在社交应用客户端中,服务端体现为群管理服务器,社交应用的服务端可以调用该群管理服务器中的服务功能,实现群消息的归类和话题化管理。在这样的情况下,图2中的客户端可以是上述管理工具的客户端,服务端为该管理工具的服务端。或者,也可以认为,图2中的客户端为嵌入有上述管理工具的社交应用客户端,服务端为可调用群管理服务的社交应用服务端。
为了实现群消息的话题化管理,图2的执行流程包括消息归类阶段,用于将各条群消息进行归类,形成话题;以及话题拉取阶段,用于在用户发起请求时,以话题摘要的形式向用户提供已经形成的话题。
消息归类阶段可以包含以下过程。
在步骤S101,用户向客户端输入群消息m。
在步骤S103,客户端将群消息m上传到服务端;
在步骤S104,服务端通过增量归类的方式,将群消息m归类到某个话题。
可选的,在步骤S103之前,客户端可以执行步骤S102,对群消息m进行缓存。当缓存一定数量的群消息,统一上传到服务端;或者,每隔预定时间间隔,将缓存的群消息统一上传到服务端。
可选的,在步骤S102,客户端可以对群消息m进行特征提取。该特征提取可以是将群消息m转换为特征向量的形式,从而避免将消息明文发送至服务端,实现一定程度的消息加密。该特征提取还可以包括提取更多的消息特征,例如消息回复关系特征,时间特征等。
当然,在不包含步骤S102的实施例中,客户端也可以直接将群消息m明文上传服务端,由服务端进行特征提取。
在获取到群消息m后,在步骤S104,服务端采用增量归类的方式对群消息m进行归类。具体的,可以认为服务端中包括归类引擎,归类引擎一方面获取群消息m的消息特征,包括内容方面的特征(例如,词向量,句向量,句子数,字数等)和回复关系的特征(例如,引用了哪个用户,引用了哪条消息等),另一方面获取已经形成的话题的话题特征,将消息特征和话题特征输入到训练的机器学习模型中,该模型将会输出将群消息m归类到各个已有话题的概率,以及为其创建一个新话题的概率。根据这些概率,可以将群消息m归类到某个话题,该某个话题可能是已有的话题,也可能是新话题。
在确定群消息m所归类的话题后,更新该话题的话题特征。更新后的各个话题作为已有话题,用于下一条群消息的归类。如此,对于每一条群消息,将其作为增量消息,归类到已有话题或为其开启新话题,从而实现增量归类。
通过增量归类的方式,避免常规聚类时每次针对全部群消息的全量数据重新进行聚类,大大提升计算效率。并且在以上归类过程中,综合考虑群消息的内容方面特征和回复关系的特征进行归类,使得归类过程针对群消息的特点而进行,归类结果更准确。
以上消息归类过程是后续话题拉取过程的基础,因此在图2中为了示例的目的将其示出为首先执行的阶段。但是应理解,消息归类过程是持续不断进行的;每当客户端将一条或一批群消息上传到服务端时,服务端中的归类引擎就针对各条群消息进行增量归类。
下面描述话题拉取的过程。
如图2所示,在步骤S201,用户向客户端发出一个群操作的操作指令;于是,在步骤S202,客户端向服务端发出相应的请求。为了描述的简单,将步骤S201中的操作指令称为第一操作指令,将步骤S202中的请求称为第一请求。然而应理解,本文中的“第一”,“第二”等描述,仅仅是为了描述的清楚而对相似概念进行区分,并不意在对相关概念的顺序等其他方面进行限定。
在一个实施例中,用户可以首先进入某个群中,针对这个群发出获取群话题的操作指令作为上述第一操作指令。
图3示出用户发出获取群话题的操作指令的一个例子。在图3的例子中,用户进入“AI研发组”这个群中。默认地,会话界面中会显示这个群中最近的若干条群消息。可以在该界面上提供一个选项图标301,该图标可以显示为“话题模式”等样式,作为调用群消息管理功能的接口。用户点击该图标301,即发出获取这个用户群中的群话题的操作指令。相应的,在这样的情况下,步骤S202中客户端发出的第一请求用于请求获取已进入的用户群的群话题,且该第一请求中会包括该用户的用户标识,以及该用户请求处理的用户群的群标识。
在另一实施例中,用户可以通过触发群消息管理功能,针对多个群统一发出获取群话题的操作指令。
图4示出用户发出获取群话题的操作指令的另一个例子。在图4的例子中,在社交应用主界面中提供有群消息管理工具的接口图标401,例如显示为“群聊小助手”。用户点击该图标401,即发出获取群话题的操作指令。在不同实施例中,操作指令可以是针对不同的群范围。例如,在一个例子中,点击该图标,即请求将用户所加入的所有群都切换到话题模式,也即请求获取该用户加入的全部用户群的群话题。在另一例子中,用户可以预先对所加入的一部分用户群进行标注或授权,例如,将其标为关注的群。当用户触发群消息管理工具,即请求获取这部分标注为关注的用户群中的群话题。在又一例子中,群消息管理工具也可以被设置为,当用户点击接口图标触发该工具时,请求获取用户所加入的用户群中有未读新消息的用户群中的群话题。
在又一实施例中,用户可以预先在嵌入有群消息管理工具的社交应用中进行偏好设置,例如将各个群的默认显示模式设置为话题模式。在这之后,在用户请求进入某个群的同时,即意味着请求获取该群的话题。在这样的情况下,步骤S202中客户端发出的第一请求为进入某个用户群的请求,该请求同时也是获取该用户群的群话题的请求,该请求中会包括该用户的用户标识,以及请求进入的用户群的群标识。
通过以上的各种方式,客户端向服务端发出获取群话题的第一请求。
相应的,服务端接收到该第一请求后,在步骤S203,根据该请求进行话题拉取,从而将获取的话题相关信息返回给客户端。可以将服务端中执行步骤S203的话题拉取过程的部分称为话题拉取引擎。
图5示出根据一个实施例获取群话题的步骤流程,即图2中步骤S203的子步骤。可以理解,图5的步骤流程通过服务端,特别是服务端中的话题拉取引擎来执行。
如图5所示,在接收到客户端的第一请求后,在步骤51,根据该第一请求确定待处理的用户群,称为第一用户群。
如前所述,根据一种实施方式,例如在图3所示的例子中,第一请求中会包括用户标识,以及该用户请求进入或请求处理的用户群的群标识。在这样的情况下,服务端可以直接根据第一请求中包含的群标识,确定出第一用户群。
根据另一实施方式,例如在图4所示的例子中,第一请求是针对用户对应的特定范围的用户群统一获取群话题的请求,其中包括用户标识。在这样的情况下,服务端根据该用户标识,确定该用户对应的至少一个用户群。根据对应的群消息管理工具的配置,上述至少一个用户群可以是,该用户所加入的全部用户群;或者,该用户标注为关注的用户群;或者,该用户所加入的用户群中有未读新消息的用户群。在确定出上述至少一个用户群的基础上,可以将该至少一个用户群中每个用户群作为第一用户群,进行后续步骤的处理。
接着,在步骤52,获取上述第一用户群中已形成的N个话题。可以理解,如消息归类阶段所述,服务端中的归类引擎持续不断地针对各个用户群进行群消息的增量归类。相应的,话题拉取引擎可以直接获取归类引擎的归类结果。对于特定的第一用户群,话题拉取引擎可以读取第一用户群中已经形成的N个话题,这N个话题是归类引擎基于第一用户群中各条群消息的内容和回复关系,对各条群消息进行增量归类而形成。可以理解,每个话题对应于归类到该话题的消息集合。
可以理解,用户群中的话题数量会随着时间而累积增多,但是用户对太久之前的话题一般是不感兴趣的。为了避免用户群中的话题无限制累积,也避免向用户推送过多不感兴趣的话题,在一个实施例中,可以设置一个时长阈值作为过期时长,例如该时长阈值可以设置为1天。对于已经形成的话题,可以将该话题对应的消息集合中最新消息的发布时间作为该话题的最后更新时间。当该最后更新时间距离当前时刻的时长超过所设置的过期时长时,则认为该话题为过期话题,将其从备选话题中删除。相应的,在一个实施例中,在步骤52中,对于第一用户群中已形成的各个已有话题,确定其最后更新时间距离当前时刻的时长;将时长小于上述预设时长阈值的话题,作为上述N个话题。换而言之,步骤52获取的N个话题均为最近更新的话题,其最后更新时间距离当前时刻均不超过上述时长阈值。例如,当时长阈值为1天时,获取的N个话题均是在最近1天内有更新的话题。
对于以上的N个话题,在步骤53,获取各个话题的摘要信息。
可以理解,在本说明书的实施例中,各个话题是对群消息进行增量归类而得到的,并不要求用户使用特定标识符来标识出话题题目(例如如一些社交应用中要求的使用标识符“#”标识出话题题目,比如用“#人工智能#”来标识出话题为“人工智能”),因此,这就需要从归类到一个话题的各个群消息的内容中提炼出话题摘要。而另一方面,群消息的增量归类是持续进行的,因此,一个话题对应的消息集合也在持续变化,可能持续有新的群消息被归类到该话题中。换而言之,提炼话题摘要所基于的群消息集合也在持续变化中。考虑到以上特点,在不同实施例中,可以采用实时形成或预先固定两种方案,获得各个话题的实时摘要或固定摘要。下面分别描述获取实时摘要和固定摘要的过程。
首先描述获取实时摘要的实施方式。在该实施方式下,服务端在接收到客户端的获取话题的请求时,基于当前时刻下各个话题对应的消息集合中的消息内容,进行内容提炼和选择,确定出话题摘要。
下面以N个话题中任意的一个话题,称为第一话题,为例进行描述。具体的,对于任意的第一话题而言,可以确定出该第一话题当前对应的第一消息集合,其中包括当前已归类到该第一话题的各条群消息。为了进行摘要提炼,可以将各条群消息划分为多个消息部分,获取各个消息部分的特征向量;然后,根据特征向量确定各个消息部分之间的语义相关度或确定各个消息部分的语义中心,据此,从各个消息部分中选择出具有语义代表性的消息部分作为第一话题的话题摘要。在不同实施例中,上述消息部分可以是整条消息,也可以是消息中的句子。下面结合具体例子描述以上过程。
在一个实施例中,服务端可以获取各个群消息的明文。在这样的情况下,可以以句子为单位进行分析,从消息集合中选择出具有代表性的句子作为话题摘要。
具体的,对于上述第一话题对应的第一消息集合,可以将其中的各条群消息划分为各个句子,并获取各个句子对应的特征向量。在一个实施例中,可以对各个句子进行特征提取,从而得到句子对应的特征向量。可以理解,在进行消息的增量归类时,需要分析消息的内容,一般地也需要获取消息中各个句子的特征,因此,归类引擎往往已经对各个句子进行了特征提取。在这样的情况下,在一个实施例中,也可以直接从归类引擎中获取已经生成的句子特征向量。
然后,基于各个句子的特征向量,选择具有语义代表性的句子。
在一个具体实施例中,可以根据各个句子的特征向量,确定两两句子之间的语义相关度。该语义相关度可以基于句子特征向量之间的距离而确定,距离越小,语义相关度越高,该距离例如可以是欧式距离,余弦距离等等。上述语义相关度也可以基于向量之间的点乘结果而确定。然后,基于两两句子之间的语义相关度,可以得到每个句子与其他句子整体的综合相关度得分。例如,句子i与其他句子的综合相关度得分Si可以表示为:
其中,Aij表示句子i和句子j之间的语义相关度,M为消息集合中句子的数目。
在得到各个句子的综合相关度得分后,可以从中选择综合相关度得分最高的句子作为代表句子。
在另一具体实施例中,对于第一话题对应的第一消息集合中的M个句子,可以确定这M个句子对应的M个特征向量的中心向量,作为该消息集合的语义中心。然后,确定各个句子的特征向量与该中心向量的相似度。该相似度可以基于特征向量与中心向量的距离或点乘结果而确定。基于此,可以从各个句子中,选择其特征向量与中心向量相似度最高的句子,作为消息集合的代表句子。
在一个例子中,可以直接将该代表句子的文本内容作为摘要信息。在另一例子中,可以将该代表句子在群消息中的编号作为摘要信息,该编号例如包括,消息id和句子序号,用以表示,被选择作为摘要的句子是哪条消息中的第几个句子。
在另一个实施例中,客户端对各条消息进行特征提取后,将消息对应的特征向量提供给服务端。在这样的情况下,服务端可以以整条消息为单位进行分析,基于消息特征向量,选择出具有代表性的消息作为话题摘要。
具体的,对于上述第一话题对应的第一消息集合,可以获取各条消息对应的特征向量。然后,基于各个消息的特征向量,选择具有语义代表性的消息。更具体的,可以根据各个消息的特征向量,确定消息之间的语义相关度,进而得到每条消息与其他消息整体的综合相关度得分,将得分最高的消息选择作为代表消息。或者,可以根据各条消息的特征向量确定出中心向量,并将特征向量与中心向量相似度最高的消息作为代表消息。以上过程与选择代表句子过程类似,只是特征向量不同。
在确定出代表消息的基础上,可以将该代表消息的编号,例如消息id,或消息序号,作为摘要信息。
在更多实施例中,还可以采用其他具体算法,选择具有代表性的消息部分作为话题摘要。例如,可以基于消息之间的引用关系,得到各个消息被引用的次数,基于该引用次数对各个消息进行排序,将排序最靠前的作为代表消息。又例如,还可以基于各个消息部分(整条消息或句子)的特征向量和预设判定条件,确定两两消息部分之间是否相关,据此确定与每个消息部分相关的其他消息部分的数目,然后依据此数目进行排序,将排序靠前的消息部分作为话题摘要。
如此,通过以上多种方式,基于当前时刻下各个话题对应的消息集合中的消息内容,确定出实时话题摘要。如此得到的话题摘要可以更准确、更及时地反映归类到该话题的各个消息中的内容。
根据另一种实施方式,各个话题的话题摘要可以预先确定并固定下来,如此,当用户请求获取话题时,在步骤53,只需要读取预先确定的各个话题对应的摘要信息。下面仍以N个话题中任意的第一话题为例,描述其话题摘要的确定方式。
在一个实施例中,在形成第一话题的同时,即确定出其话题摘要。如前所述,归类引擎将各条群消息视为增量数据,将其归类到已有话题中,或为其创建一个新话题。因此,每个话题最初都是基于一条群消息而形成的。假定上述第一话题是基于某条特定消息,称为第一群消息,而形成,也就是说,在对第一群消息进行归类时,因为无法将其归类到之前的已有话题,于是为其创建了该第一话题。此时,可以基于该第一群消息确定该第一话题的话题摘要。更具体的,可以将该第一群消息作为第一话题的话题摘要;或者,如果该第一群消息包含多个句子,可以从中选择一个句子作为话题摘要。
例如,在一个例子中,服务端针对一条群消息“空调是不是坏了”创建了一个新话题,同时,可以将该条消息本身确定为该新话题的摘要。
在以上情况下,话题摘要可以由归类引擎在归类形成话题的同时而确定。在一个实施例中,将形成话题时确定的话题摘要固定下来,不再变更。
在另一实施例中,将形成第一话题时确定的话题摘要作为临时摘要,当归类到该第一话题的消息数目达到预定数目时,基于该预定数目的群消息再次确定话题摘要。基于多条群消息确定话题摘要的具体方式可以参照前述的获取实时摘要的过程。在如此确定话题摘要之后,就将话题摘要固定下来,不再变更。
例如,延续以上例子,假定形成第一话题的群消息为“空调是不是坏了”,可以将该消息作为该第一话题的临时摘要。当后续有例如10条群消息归类到该第一话题时,基于该10条群消息再次确定话题摘要。假定在再次确定摘要的过程中,从回复消息中选择了更有代表性的句子“东区空调已修好,西区还在维修”作为摘要,之后就将话题摘要固定下来,不再变更。
在固定摘要的实施方式中,话题拉取引擎在步骤53只需要读取预先确定的话题摘要信息,而不需重新进行摘要提炼的计算,执行速度更快。并且,由于在界面呈现时是通过摘要来代表一个话题,因此固定摘要的方式对于用户确定话题来说更加友好而直观,特别是在用户反复请求话题拉取的情况下。例如,如果用户相隔一个小时两次请求获取话题,在实时摘要的情况下,看到的话题摘要可能略有不同,用户需进一步判断是否是产生了新的话题;而固定摘要的方式则不会产生这样的误解。
以上,通过多种方式,获取了各个话题的摘要信息。此外,在步骤54,还根据用户的用户特征,确定上述N个话题的排序信息。
根据一种实施方式,用户特征可以包括请求话题的用户在用户群中的群角色。根据这样的用户特征,可以确定请求用户与各个话题中包含的群消息的发送者之间的角色关系,据此确定各个话题的相对排序。
具体的,在一些用户群中,不同用户具有不同的角色和权限,例如群主,管理员,普通群成员。在用于工作管理沟通的社交应用中,还支持针对工作群中的用户设置部门、级别等角色属性。基于这样的群角色信息,可以确定请求用户与各个话题中包含的消息发送者之间的角色关系,例如,上下级关系,均为普通成员的同级关系等等。
在具体实施例中,如果一个话题中的消息发送者中包括特定角色的发送者,该特定角色与用户具有一定角色关系,例如是群主,管理员,或请求用户的上级角色,那么将该话题的排序信息设置为高优先级。
在另一具体实施例中,如果一个话题中第一条消息的发送者,或称为该话题的发起者,与用户具有上述特定角色关系,那么将该话题的排序信息设置为高优先级。
如前所述,一个话题的摘要一般选自归类到该话题的某条消息。在一个具体实施例中,如果一个话题中被选为摘要的消息的发送者与用户具有上述特定角色关系,那么将该话题的排序信息设置为高优先级。
在又一具体实施例中,如果一个话题的发起者,或者被选为摘要的消息的发送者为请求用户本人,那么将该话题的排序信息设置为高优先级。
还可以对以上的实施例进行组合,根据用户与各个话题中消息发送者的综合关系,得到各个话题的总优先级得分作为其排序信息。
根据另一种实施方式,用户的用户特征包括,对话题排序的设置特征,例如热度优先,更新时间优先,等等。相应的,在步骤54,可以根据用户的设置特征,确定各个话题的排序信息。
例如,在用户对话题排序的设置为热度优先的情况下,可以按照话题的热度确定其排序优先级。其中话题热度可以基于该话题中包括的消息数目,或者参与该话题的用户数目(即不同的消息发送者数目)来确定。
又例如,在用户对话题排序的设置为更新时间优先的情况下,可以将各个话题中最新消息的发布时间作为话题更新时间,根据话题更新时间的倒序,确定各个话题的排序优先级。
根据需要,还可以将以上各个实施方式中的各个实施例进行全面组合,综合考虑用户与话题中消息发送者的关系,以及用户的排序设置,确定最终的排序信息。
例如,在一个例子中,可以首先考虑用户的群角色以及与消息发送者的关系特征,确定各个话题的排序优先级等级;当多个话题的优先级等级相同时,例如均被设置为高优先级,考虑用户的排序设置,例如按照更新时间,进一步进行排序。又例如,在另一例子中,可以为以上各项因素,包括用户与话题发起者的关系,用户与消息发送者的关系,用户的排序设置等,赋予一定的权重因子,根据权重因子将各项因素下对话题的排序优先级进行综合,得到最终的排序信息。
通过以上方式,根据用户特征确定出N个话题的排序信息,如此使得,话题排序针对用户而定制,使得用户更容易获得重要的话题讨论内容。
此外,根据一种实施方式,拉取话题信息还包括步骤55,在其中获取各个话题的统计信息。
如前所述,每个话题对应于一个消息集合;可以获取消息集合中消息的各方面的统计信息作为话题统计信息。例如,话题的统计信息可以包括以下中的一项或多项:消息集合中群消息的总数量;消息集合中特定类型的群消息的数量,该特定类型的群消息例如是,点赞消息,非回复类的消息,等等。还可以获取消息集合中发送者数目,该话题的最后更新时间,等等,作为话题的统计信息。
如此,服务端中的话题拉取引擎分别获取了第一用户群中N个话题的摘要信息,排序信息,以及可选的话题统计信息。当用户获取话题的请求是针对多个用户群时,对于每个群,均执行图5所示的获取该用户群中话题信息的方法流程。
回到图2,服务端在步骤S203获取各个话题的话题信息后,在步骤S204将这些话题信息发送给客户端,其中包括话题摘要信息,排序信息和可选的统计信息。于是,在步骤S205,客户端根据接收到的话题信息,对各个话题进行展示。具体的,客户端按照排序信息指示的顺序,通过话题摘要的形式显示上述N个话题。
在一个实施例中,各个话题的摘要信息中包括摘要文本。在这样的情况下,客户端直接显示各个摘要文本来代表各个话题。
在另一实施例中,各个话题的摘要信息包括,被确定为话题摘要的消息部分在群消息中的编号,该编号例如包括消息id和句子编号,用以表示被选择作为摘要的句子是哪条消息中的第几个句子。在这样的情况下,客户端首先根据上述编号获取该消息部分对应的文本作为摘要文本,例如根据上述消息id和句子编号确定出对应的句子,读取该句子的文本作为摘要文本;从而可以显示该摘要文本来代表对应的话题。
在一个实施例中,在步骤S204客户端还获取到各个话题的统计信息。在这样的情况下,在步骤S205,客户端还相应地显示各个话题的统计信息,这些统计信息例如包括,归类到对应话题的消息集合中群消息的总数量,归类到对应话题的消息集合中特定类型的群消息的数量,上述消息集合中发送者数目,该话题的最后更新时间,等等。
图6示出根据一个实施例客户端显示的话题信息的界面示意图。图6的界面示意图可以是用户在图3所示的界面的基础上,通过点击图3中的选项图标301发出拉取群话题的请求后得到的;或者,也可以是在社交应用被设置为默认话题模式的情况下,用户进入“AI研发组”这个用户群后即呈现的。
如图6所示,“AI研发组”目前正在讨论的话题有3个,分别用其话题摘要来表示,包括摘要1“明天的培训谁主讲”表示的话题1,摘要2“空调是不是坏了”表示的话题2,和摘要3“调试了一下,loss用交叉熵更好一些”表示的话题3。3个话题的排列顺序根据接收到的排序信息而确定。
在图6的例子中,在每个话题的摘要下方,还显示该话题的统计信息。例如,话题1的统计信息包括:“20条消息,11人讨论,3个赞”,话题2的统计信息包括:“30条消息,25人讨论,6个赞”,等等。通过图6示意的界面所显示的话题信息,用户可以一目了然地获知该用户群中正在讨论的话题内容,从而实现大量群消息内容的高效浏览。
进一步的,在一个实施例中,在话题显示界面中还提供交互接口,从而便于用户快速地处理和响应群消息。相应地,图2所示的方法流程还包括,在步骤S206,用户发出针对群话题的操作指令,在步骤S207,客户端根据用户的操作指令,显示对群话题的操作结果。
在一个具体实施例中,如图6所示,在每个话题信息下方还提供交互接口“展开”,“回复”,“点赞”等。用户可以通过点击这些交互接口,发出针对群话题的操作指令。
在一个例子中,在步骤S206,用户点击某个话题下的“展开”选项,发出展开该话题的操作指令。客户端接收到该操作指令后,在步骤S207,显示归类到该话题中的各条群消息。
在另一例子中,在步骤S206,用户点击某个话题下的“回复”选项,发出针对该话题进行回复的操作指令。针对这样的操作指令,在不同实施例中可以有不同处理方式。
在一个实施例中,响应于针对某个话题的回复指令,首先展开用户回复所针对的话题(例如展开话题2“空调是不是坏了”中的各条群消息),在呈现该话题中各条消息的话题展开界面中显示消息输入框。用户可以在该消息输入框中输入回复消息。客户端接收到用户输入的回复消息后,在该话题展开界面中显示用户输入的回复消息。同时,将该回复消息标记为针对该话题的消息,便于服务端中的归类引擎直接将该条回复消息归类到该展开的话题中。
在另一实施例中,响应于针对某个话题的回复指令,将界面切换回常规群消息展示界面,在该界面中显示消息输入框。在一种实现方式中,在该消息输入框中默认引用所针对的话题的发起者,或者引用该话题摘要的消息(例如,默认引用消息“空调是不是坏了”),如此,将用户输入的回复消息标记为针对该话题的消息,从而便于归类引擎直接将该条回复消息归类到所针对的话题中。
当然,根据实现的需要,还可以设计更多的交互接口和交互方式,在此不做限定。
回顾以上过程,服务端通过增量归类的方式,将各条群消息归类为群话题。当用户请求获取群话题时,获取各个群话题的摘要,并根据用户特征对各个话题进行排序,将摘要信息和排序信息返回给客户端。客户端按照排序信息中的顺序,以摘要的形式展示各个话题,从而使得用户可以快速、高效地浏览群消息的讨论内容,便于用户及时有效地进行响应和处理,极大地提升用户体验。
根据另一方面的实施例,提供了一种管理群消息的装置,该装置部署在社交应用服务端中,该服务端可以通过任何具有计算、处理能力的设备、平台或设备集群实现。图7示出根据一个实施例部署在服务端中的群消息管理装置的示意性框图。如图7所示,该消息管理装置70包括:
请求接收单元71,配置为从客户端接收第一用户进行群操作的第一请求;
用户群确定单元72,配置为根据所述第一请求确定第一用户群;
话题获取单元73,配置为获取所述第一用户群中已形成的N个话题,所述N个话题是基于所述第一用户群中各条群消息的内容和回复关系,对所述各条群消息进行归类而形成;
摘要获取单元74,配置为获取所述N个话题中各个话题的摘要信息;
排序单元75,配置为根据所述第一用户的用户特征,确定所述N个话题的排序信息;
信息提供单元76,配置为向客户端提供所述N个话题的摘要信息以及排序信息。
在一个实施例中,第一请求用于请求进入第一用户群,相应的,第一请求中包括所述第一用户的用户标识和第一用户群的群标识;在这样的情况下,用户群确定单元72配置为,根据所述群标识,确定所述第一用户群
在一个实施例中,所述第一请求用于请求获取第一用户群的群话题,相应的,第一请求中包括所述第一用户的用户标识和所请求的用户群的群标识;在这样的情况下,用户群确定单元72配置为,根据所述群标识,确定所述第一用户群。
在另一实施例中,所述第一请求用于请求启动话题获取功能,其中包括所述第一用户的用户标识;在这样的情况下,用户群确定单元72配置为,根据所述用户标识,确定所述第一用户对应的至少一个用户群,所述至少一个用户群为:
所述第一用户所加入的全部用户群;或者,
所述第一用户标注为关注的用户群;或者,
所述第一用户所加入的用户群中有未读新消息的用户群;
所述第一用户群为所述至少一个用户群中任意的一个用户群。
根据一种实施方式,话题获取单元73配置为:
获取针对所述第一用户群形成的已有话题;
对于各个已有话题,确定其最后更新时间距离当前时刻的时长;
将所述时长小于预设时长阈值的话题,作为所述N个话题。
在一种实施方式中,所述装置还包括统计信息获取单元(未示出),用于获取所述N个话题中各个话题的统计信息;在这样的情况下,信息提供单元76还配置为向客户端提供所述N个话题的统计信息;其中,所述统计信息包括以下中的一项或多项:归类到对应话题的消息集合中群消息的总数量,归类到对应话题的消息集合中特定类型的群消息的数量,参与该话题的用户数目,该话题的最后更新时间。
根据一种实施方式,对于所述N个话题中任意的第一话题,摘要获取单元74配置为:
确定归类到第一话题的第一消息集合中各条群消息的各个消息部分对应的特征向量;
根据所述特征向量,从所述各个消息部分中选择具有语义代表性的第一消息部分;
将所述第一消息部分的信息作为所述第一话题对应的第一摘要信息。
进一步地,在各种实施例中,所述各个消息部分可以为各条消息;或者为各条消息中的各个句子;所述第一摘要信息可以包括,所述第一消息部分在群消息中的编号。
在一个具体实施例中,摘要获取单元74通过以下方式从各个消息部分中选择具有语义代表性的第一消息部分:
根据所述各个消息部分对应的各个特征向量,确定两两消息部分之间的语义相关度;
根据两两消息部分之间的语义相关度,确定每个消息部分与其他消息部分整体的综合相关度得分;
选择综合相关度得分最高的消息部分作为所述第一消息部分。
在另一具体实施例中,摘要获取单元74通过以下方式从各个消息部分中选择具有语义代表性的第一消息部分:
根据所述各个消息部分对应的各个特征向量,确定各个特征向量的中心向量作为语义中心;
从各个消息部分中,确定出其特征向量与所述中心向量相似度最高的消息部分作为所述第一消息部分。
在一种实施方式中,对于所述N个话题中任意的第一话题,摘要获取单元74配置为:读取预先确定的所述第一话题对应的第一摘要信息。
进一步地,上述第一摘要信息可以基于形成所述第一话题时的群消息而确定;或者,可以基于归类到所述第一话题的消息集合中预定数目的群消息而确定。
在一个实施例中,第一用户的用户特征包括所述第一用户在所述第一用户群中的群角色;相应地,排序单元75配置为:根据所述群角色,确定所述第一用户与各个话题中包含的群消息的发送者之间的角色关系,根据所述角色关系确定各个话题的相对排序。
在另一实施例中,第一用户的用户特征包括,对话题排序的设置特征;相应的,排序单元75配置为,根据所述设置特征,确定所述N个话题的排序信息。
根据又一方面的实施例,提供了一种管理群消息的装置,该装置部署在社交应用客户端中。图8示出根据一个实施例部署在客户端中的群消息管理装置的示意性框图。如图8所示,该消息管理装置80包括:
指令接收单元81,配置为接收第一用户进行群操作的第一操作指令;
请求发送单元82,配置为向服务端发送与所述第一操作指令对应的第一请求;
信息接收单元83,配置为从服务端接收该第一用户所加入的第一用户群中已形成的N个话题的话题信息,所述话题信息包括摘要信息以及排序信息;
显示单元84,配置为按照所述排序信息中指示的顺序,根据所述摘要信息显示所述N个话题的话题摘要。
在一个实施例中,指令接收单元81接收的第一操作指令为进入第一用户群的操作指令,相应的,请求发送单元82发送的第一请求中包括所述第一用户的用户标识和第一用户群的群标识。
在一个实施例中,指令接收单元81接收的第一操作指令为获取所述第一用户群的群话题的操作指令,相应的,请求发送单元82发送的第一请求包括所述第一用户的用户标识和第一用户群的群标识。
在另一实施例中,指令接收单元81接收的第一操作指令为启动话题获取功能的操作指令,用于获取所述第一用户对应的至少一个用户群中的群话题,所述至少一个用户群为:
所述第一用户所加入的全部用户群;或者
所述第一用户标注为关注的用户群;或者
所述第一用户所加入的用户群中有未读新消息的用户群;
所述至少一个群包括所述第一用户群。
根据一种实施方式,所述N个话题包括第一话题,所述摘要信息包括,被确定为第一话题的话题摘要的第一消息部分在群消息中的编号;相应地,显示单元84配置为:
根据所述编号获取所述第一消息部分对应的第一文本;
显示所述第一文本作为所述第一话题的话题摘要。
在一种实施方式中,所述话题信息还包括话题统计信息,所述显示单元84还配置为,显示所述N个话题中各个话题的话题统计信息;其中,所述话题统计信息包括以下中的一项或多项:归类到对应话题的消息集合中群消息的总数量,归类到对应话题的消息集合中特定类型的群消息的数量,参与该话题的用户数目,该话题的最后更新时间。
根据一种实施方式,在显示所述N个话题的话题摘要之后,指令接收单元81还接收所述第一用户的第二操作指令,所述第二操作指令用于展开所述N个话题中的第一话题;所述显示单元84还配置为,显示归类到所述第一话题中的各条群消息。
根据另一种实施方式,在显示所述N个话题的话题摘要之后,指令接收单元81还接收所述第一用户的第三操作指令,所述第三操作指令用于针对所述N个话题中的第一话题进行回复。所述装置还包括回复单元(未示出),配置为接收用户针对所述第一话题输入的第一回复消息;并将所述第一回复消息标记为针对所述第一话题。
通过以上装置,获取对用户群中的群消息进行归类形成的各个话题的话题信息,从而便于用户高效地浏览和处理各个群消息。
根据另一方面的实施例,还提供一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行结合图2所描述的方法。
根据再一方面的实施例,还提供一种计算设备,包括存储器和处理器,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现结合图2所述的方法。
本领域技术人员应该可以意识到,在上述一个或多个示例中,本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时,可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。
以上所述的具体实施方式,对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本发明的具体实施方式而已,并不用于限定本发明的保护范围,凡在本发明的技术方案的基础之上,所做的任何修改、等同替换、改进等,均应包括在本发明的保护范围之内。
Claims (26)
1.一种管理群消息的方法,通过服务端执行,所述方法包括:
从客户端接收第一用户进行群操作的第一请求;
根据所述第一请求确定第一用户群;
获取所述第一用户群中已形成的N个话题,所述N个话题是基于所述第一用户群中各条群消息的内容和回复关系,对所述各条群消息进行归类而形成;
获取所述N个话题中各个话题的摘要信息;
根据所述第一用户的用户特征,确定所述N个话题的排序信息;
向客户端提供所述N个话题的摘要信息以及排序信息。
2.根据权利要求1所述的方法,其中,所述第一请求用于请求进入第一用户群,所述第一请求中至少包括所述第一用户群的群标识;
根据所述第一请求确定第一用户群包括,根据所述群标识,确定所述第一用户群。
3.根据权利要求1所述的方法,其中,所述第一请求用于请求获取第一用户群的群话题,所述第一请求中至少包括所请求的第一用户群的群标识;
根据所述第一请求确定第一用户群包括,根据所述群标识,确定所述第一用户群。
4.根据权利要求1所述的方法,其中,所述第一请求用于请求启动话题获取功能,所述第一请求包括所述第一用户的用户标识;
根据所述第一请求确定第一用户群包括,根据所述用户标识,确定所述第一用户对应的至少一个用户群,所述至少一个用户群为:所述第一用户所加入的全部用户群;或者,所述第一用户标注为关注的用户群;或者,所述第一用户所加入的用户群中有未读新消息的用户群;
所述第一用户群为所述至少一个用户群中任意的一个用户群。
5.根据权利要求1所述的方法,其中获取所述第一用户群中已形成的N个话题包括:
获取针对所述第一用户群形成的已有话题;
对于各个已有话题,确定其最后更新时间距离当前时刻的时长;
将所述时长小于预设时长阈值的话题,作为所述N个话题。
6.根据权利要求1所述的方法,还包括,获取所述N个话题中各个话题的统计信息,以及向客户端提供所述N个话题的统计信息;
所述统计信息包括以下中的一项或多项:归类到对应话题的消息集合中群消息的总数量,归类到对应话题的消息集合中特定类型的群消息的数量,参与该话题的用户数目,该话题的最后更新时间。
7.根据权利要求1所述的方法,其中,所述N个话题包括第一话题,所述获取所述N个话题中各个话题的摘要信息包括:
确定归类到第一话题的第一消息集合中各条群消息的各个消息部分对应的特征向量;
根据所述特征向量,从所述各个消息部分中选择具有语义代表性的第一消息部分;
将所述第一消息部分的信息作为所述第一话题对应的第一摘要信息。
8.根据权利要求7所述的方法,其中,
所述各个消息部分为,各条消息;或者为,各条消息中的各个句子;
所述第一摘要信息包括,所述第一消息部分在群消息中的编号。
9.根据权利要求7或8所述的方法,其中,根据所述特征向量,从所述各个消息部分中选择具有语义代表性的第一消息部分,包括:
根据所述各个消息部分对应的各个特征向量,确定两两消息部分之间的语义相关度;
根据两两消息部分之间的语义相关度,确定每个消息部分与其他消息部分整体的综合相关度得分;
选择综合相关度得分最高的消息部分作为所述第一消息部分。
10.根据权利要求7或8所述的方法,其中,根据所述特征向量,从所述各个消息部分中选择具有语义代表性的第一消息部分,包括:
根据所述各个消息部分对应的各个特征向量,确定各个特征向量的中心向量作为语义中心;
从各个消息部分中,确定出其特征向量与所述中心向量相似度最高的消息部分作为所述第一消息部分。
11.根据权利要求1所述的方法,其中,所述N个话题包括第一话题,获取所述N个话题中各个话题的摘要信息包括:
读取预先确定的所述第一话题对应的第一摘要信息。
12.根据权利要求11所述的方法,其中,
所述第一摘要信息基于形成所述第一话题时的群消息而确定;或者,
所述第一摘要信息基于归类到所述第一话题的消息集合中预定数目的群消息而确定。
13.根据权利要求1所述的方法,其中,所述用户特征包括所述第一用户在所述第一用户群中的群角色;
根据所述第一用户的用户特征,确定所述N个话题的排序信息,包括:
根据所述群角色,确定所述第一用户与各个话题中包含的群消息的发送者之间的角色关系,根据所述角色关系确定各个话题的相对排序。
14.根据权利要求1所述的方法,其中,所述用户特征包括,对话题排序的设置特征;
根据所述第一用户的用户特征,确定所述N个话题的排序信息包括,根据所述设置特征,确定所述N个话题的排序信息。
15.一种管理群消息的方法,通过客户端执行,所述方法包括:
接收第一用户进行群操作的第一操作指令;
向服务端发送与所述第一操作指令对应的第一请求;
从服务端接收该第一用户所加入的第一用户群中已形成的N个话题的话题信息,所述话题信息包括摘要信息以及排序信息;
按照所述排序信息中指示的顺序,根据所述摘要信息显示所述N个话题的话题摘要。
16.根据权利要求15所述的方法,其中,所述第一操作指令为进入所述第一用户群的操作指令,所述第一请求中包括所述第一用户的用户标识和第一用户群的群标识。
17.根据权利要求15所述的方法,其中,所述第一操作指令为获取所述第一用户群的群话题的操作指令,所述第一请求中包括所述第一用户的用户标识和第一用户群的群标识。
18.根据权利要求15所述的方法,其中,所述第一操作指令为启动话题获取功能的操作指令,用于获取所述第一用户对应的至少一个用户群中的群话题,所述至少一个用户群为:所述第一用户所加入的全部用户群;或者,所述第一用户标注为关注的用户群;或者,所述第一用户所加入的用户群中有未读新消息的用户群;
所述至少一个群包括所述第一用户群。
19.根据权利要求15所述的方法,其中,所述N个话题包括第一话题,所述摘要信息包括,被确定为第一话题的话题摘要的第一消息部分在群消息中的编号;
根据所述摘要信息显示所述N个话题的话题摘要包括:
根据所述编号获取所述第一消息部分对应的第一文本;
显示所述第一文本作为所述第一话题的话题摘要。
20.根据权利要求15所述的方法,其中,所述话题信息还包括话题统计信息,所述方法还包括,显示所述N个话题中各个话题的话题统计信息;
其中,所述话题统计信息包括以下中的一项或多项:归类到对应话题的消息集合中群消息的总数量,归类到对应话题的消息集合中特定类型的群消息的数量,参与该话题的用户数目,该话题的最后更新时间。
21.根据权利要求15所述的方法,其中,在根据所述摘要信息显示所述N个话题的话题摘要之后,还包括:
接收所述第一用户的第二操作指令,所述第二操作指令用于展开所述N个话题中的第一话题;
显示归类到所述第一话题中的各条群消息。
22.根据权利要求15所述的方法,其中,在根据所述摘要信息显示所述N个话题的话题摘要之后,还包括:
接收所述第一用户的第三操作指令,所述第三操作指令用于针对所述N个话题中的第一话题进行回复;
接收用户针对所述第一话题输入的第一回复消息;
将所述第一回复消息标记为针对所述第一话题。
23.一种管理群消息的装置,部署在服务端中,所述装置包括:
请求接收单元,配置为从客户端接收第一用户进行群操作的第一请求;
用户群确定单元,配置为根据所述第一请求确定第一用户群;
话题获取单元,配置为获取所述第一用户群中已形成的N个话题,所述N个话题是基于所述第一用户群中各条群消息的内容和回复关系,对所述各条群消息进行归类而形成;
摘要获取单元,配置为获取所述N个话题中各个话题的摘要信息;
排序单元,配置为根据所述第一用户的用户特征,确定所述N个话题的排序信息;
信息提供单元,配置为向客户端提供所述N个话题的摘要信息以及排序信息。
24.一种管理群消息的装置,部署在客户端中,所述装置包括:
指令接收单元,配置为接收第一用户进行群操作的第一操作指令;
请求发送单元,配置为向服务端发送与所述第一操作指令对应的第一请求;
信息接收单元,配置为从服务端接收该第一用户所加入的第一用户群中已形成的N个话题的话题信息,所述话题信息包括摘要信息以及排序信息;
显示单元,配置为按照所述排序信息中指示的顺序,根据所述摘要信息显示所述N个话题的话题摘要。
25.一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行权利要求1-22中任一项的所述的方法。
26.一种计算设备,包括存储器和处理器,其特征在于,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现权利要求1-22中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910507182.4A CN110233745A (zh) | 2019-06-12 | 2019-06-12 | 管理群消息的方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910507182.4A CN110233745A (zh) | 2019-06-12 | 2019-06-12 | 管理群消息的方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN110233745A true CN110233745A (zh) | 2019-09-13 |
Family
ID=67858983
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910507182.4A Pending CN110233745A (zh) | 2019-06-12 | 2019-06-12 | 管理群消息的方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110233745A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111193599A (zh) * | 2019-12-06 | 2020-05-22 | 腾讯科技(深圳)有限公司 | 消息处理方法和装置 |
CN112350924A (zh) * | 2020-11-06 | 2021-02-09 | 北京字跳网络技术有限公司 | 通信方法、装置、终端和存储介质 |
CN112423011A (zh) * | 2020-11-17 | 2021-02-26 | 北京达佳互联信息技术有限公司 | 消息回复方法、装置、设备及存储介质 |
CN112929255A (zh) * | 2021-01-22 | 2021-06-08 | 维沃移动通信有限公司 | 消息发送方法及装置 |
CN114363282A (zh) * | 2020-09-27 | 2022-04-15 | 维沃移动通信有限公司 | 消息处理方法和电子设备 |
-
2019
- 2019-06-12 CN CN201910507182.4A patent/CN110233745A/zh active Pending
Non-Patent Citations (1)
Title |
---|
周亦鹏: "《软件人主题分析和信息检索技术》", 31 August 2012 * |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111193599A (zh) * | 2019-12-06 | 2020-05-22 | 腾讯科技(深圳)有限公司 | 消息处理方法和装置 |
CN111193599B (zh) * | 2019-12-06 | 2021-07-06 | 腾讯科技(深圳)有限公司 | 消息处理方法和装置 |
CN114363282A (zh) * | 2020-09-27 | 2022-04-15 | 维沃移动通信有限公司 | 消息处理方法和电子设备 |
CN112350924A (zh) * | 2020-11-06 | 2021-02-09 | 北京字跳网络技术有限公司 | 通信方法、装置、终端和存储介质 |
CN112350924B (zh) * | 2020-11-06 | 2022-09-27 | 北京字跳网络技术有限公司 | 通信方法、装置、终端和存储介质 |
CN112423011A (zh) * | 2020-11-17 | 2021-02-26 | 北京达佳互联信息技术有限公司 | 消息回复方法、装置、设备及存储介质 |
CN112929255A (zh) * | 2021-01-22 | 2021-06-08 | 维沃移动通信有限公司 | 消息发送方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110233745A (zh) | 管理群消息的方法及装置 | |
Medvedev et al. | The anatomy of Reddit: An overview of academic research | |
Yin et al. | LCARS: A spatial item recommender system | |
US10154002B2 (en) | Systems and methods for permission-based message dissemination in a communications system | |
US9391789B2 (en) | Method and system for multi-level distribution information cache management in a mobile environment | |
WO2015055067A1 (en) | Method and apparatus for pushing messages | |
US20080133501A1 (en) | Collaborative workspace context information filtering | |
US20080215581A1 (en) | Content/metadata selection and propagation service to propagate content/metadata to client devices | |
KR20160058896A (ko) | 소셜 커뮤니케이션 데이터를 분석하고 송신하는 시스템 및 방법 | |
WO2009006228A1 (en) | Processing data obtained from a presence-based system | |
CN104254852A (zh) | 用于混合信息查询的方法和系统 | |
TW200816008A (en) | Adaptive dissemination of personalized and contextually relevant information | |
EP2344998A2 (en) | System and method for context enhanced ad creation | |
US8126973B2 (en) | System and method for incorporating social networking maps in collaboration tooling and devices | |
CN100413249C (zh) | 一种联系人管理方法 | |
CN111522978B (zh) | 一种数据推送方法和装置 | |
CN111885399A (zh) | 内容分发方法、装置、电子设备以及存储介质 | |
CN111369209A (zh) | 事务提醒方法、装置、设备及存储介质 | |
KR101559719B1 (ko) | 효과적인 마케팅을 도출하는 자동학습 시스템 및 방법 | |
CN105279159B (zh) | 联系人的提示方法和装置 | |
CN112765514A (zh) | 一种监测网络舆情方法、装置及存储介质 | |
TW202016769A (zh) | 收集未回覆消息的方法、系統及非暫態電腦可讀取記錄媒體 | |
US9369536B1 (en) | Event-based user behavior timeline, predictions, and recommendations | |
CN111552835B (zh) | 文件推荐方法、装置及服务器 | |
CN110018823A (zh) | 交互式应用程序的处理方法及系统、生成方法及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190913 |
|
RJ01 | Rejection of invention patent application after publication |