拣阅一:缘由和系统设计「建议收藏」

2022-07-08 16:18:50 浏览数 (1)

大家好,又见面了,我是全栈君。

个人平时比較喜欢看些新闻资讯,比方科技类的huxiu, 36kr,体育新闻等,对相关的APP也实用到,今日头条做的非常不错。周围非常多人在用。可是在用了一段时间之后发现非常多APP都有下面特点:

1. 信息多并且杂,即使我仅仅订阅或者关注了某些类别。推送的消息首先是太多其次是不相关。 太多的信息我消费不了,不相关的信息我比較反感。

2. 如今的APP号称能够进行精准和个性化的推荐,头条做的还行。可是感觉不能及时的捕捉用户的兴趣变化。推荐的结果变化也小。 惊喜度不够。

3. 聚合类的新闻资讯有非常多反复性的内容。并且非常多仅仅是简单的抓取和展现,对阅读的方式和体验都没有太大改善。

以上大概是用过之后感觉有些不便的地方。之前做过一段时间的推荐和文本处理相关的事情,加上自己有些想法,就想实现一个简单的系统,拿自己做个试验试试,也好验证下自己的想法,针对以上问题,个人的想法是1. 每天给用户展现一定数量的有价值的新闻,即限制推送给用户新闻的数量。相关性方面须要针对用户的特征建模,预期效果不太明显,仅仅能通过一些策略来控制,比方最热和相关结合,某个事件或者某个类别展现一条新闻等策略实现。2. 针对用户的行为及时更新用户的特征权重。及让变化更实时一点。3. 非常多人看文章仅仅是看文章的大意,非常少通读全文的,假设能对文章进行摘要。对APP类的应该会比較好。可是如今对中文貌似没有好的摘要方法。仅仅能不断的进行尝试改进。我会用之前文章介绍的摘要算法进行实验,结合中文的词法和语义做些尝试。

以上纯粹是个人的观点和看法。肯定有不妥的地方,这方面有想法的能够在一起交流下。

眼下开发工作已经进行了一些。之前一直用java来做web相关的服务和设计。奈何一般的云server跑java的话费用较高。故採用了python来进行相关的开发工作。系统的简单设计例如以下:

系统主要分为OnLine Service, OffLine Service, 当中OnLine 部分主要进行下面操作:

a). Fetcher利用UA和PA来获取推荐展示的新闻数据,首先会向redis请求相关数据计算。然后到MySql获取数据,眼下假定MySql能够满足一定量的并发请求,以后能够考虑依照数据类型在MySql前面再加一层缓存。

b). Updater主要是依据用户行为来更新缓存中的UA权重,这样下次就能够依据用户的最新行为进行推荐展示。

OffLine部分主要负责的是线下逻辑的处理,主要包含对抓取数据的清洗、特征提取、摘要、入库等操作,为了解耦,利用MQ来存储抓取的数据。

眼下採用的方式是tornado 框架来提供web服务,redis作为缓存存储数据,mysql作为底层数据存储。 rabbitmq 来作为消息队列,jieba分词器来进行中文分词,redis mysql 眼下已经实现。web主要剩下页面的设计和实现,特征提取和摘要正在进行。因为事情比較多,可能最后实现的跟文章中说的会有非常大差别。接下来会讲部分想法的实现过程和效果, 详细取决于进度和工作了。假设有兴趣能够一起交流。

发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/116165.html原文链接:https://javaforall.cn

0 人点赞