11 月 19 - 20 日 Apache Pulsar 社区年度盛会来啦,立即报名! 了解详情
写点什么

信息流推荐在凤凰新闻的业务实践

  • 2020-03-17
  • 本文字数:8639 字

    阅读完需:约 28 分钟

信息流推荐在凤凰新闻的业务实践

导读:作为资讯阅读的用户产品,凤凰新闻一直在探索将 AI 赋能到内容生产和消费的全链路上。不断尝试调和 AI 算法与人的智慧相互约束和补位,将"人"的价值发挥到最大,让推荐引擎不是迎合用户,而是尝试引领用户,从而做到真正的"价值阅读"。本次分享主要从业务特点、推荐整体架构、特征和召回以及一些延展应用等方面,介绍凤凰新闻在资讯信息流推荐上的一些更贴近业务的经验。




对于推荐,可以理解为信息的分发与匹配,让内容与用户有一个很好的 match,将两者连接起来。这自然就会产生两个维度:用户和内容,从这两个维度出发,来定义问题:


  • 用户视角:在每一刷获得感兴趣的内容,从而让使用 App 的周期内的满意度最大化

  • 内容视角:内容生产后迅速的触达匹配分类的人群或用户,产生足够的影响力


相对应的,就会存在如下难点:


  • Item 量级:决定了我们要不要做推荐这个事情,如果仅仅是几十几百,一个榜单 List 就能解决问题;当 item 量级达到几十几百万的时候,信息流的分发或者推荐才会更加有作用、有意义。

  • User 量级:决定了系统的负载能力,到底能够承担多大的流量、负载与计算力,决定了整个业务的复杂度,用户的量级越大,系统扩展性的要求就会越高。

  • 产品形态:是否支持用户产生反馈,并与用户进行很好的交互。

  • 以上这些会产生许多信号,并促使你完成推荐,也是非常重要的点。

  • 内容的时效性:任何一个内容,包括视频或者图文,是有生命周期在里面的,内容有长有短,其中预测一个内容的生命周期是一个挺难的事情,不论通过算法也好或者其它技术也好;假设我们已经知道内容的生命周期,如何在有效的周期内给予内容有效的曝光量,也是个很难的问题。如何 Balance 这两个问题,时效性是非常重要的,因为过了内容的生命周期,再给用户推荐,是没有意义的,用户体验会非常差。

  • 用户满意度的评价指标:做过推荐的同学可能会熟悉一些指标,比如惊喜度、覆盖度、新颖度之类的,这些可以归类于非业务场景的指标。此外还有一些业务场景的指标,有点击率、CTR、时长、完成比、交互的频次、访问深度、多样性、甚至是留存率等等,这些指标和用户的满意度是否真的是正相关的,以及用户的满意度真的就能用这几个指标完整的刻画?这些都是我们需要思考的。

  • 内容质量的判定:怎样判定一个内容质量到底是好还是坏,好的标准到底是什么,以及我们如何去建模,如果可以建模,特征是什么,以及我们的模型如何有效的利用特征去判别,也是一个难题。

  • 冷启动问题:分为内容冷启动与用户冷启动。内容冷启动就是一个新内容进入平台,没有被分发出来;而用户冷启动就是一个新的用户,交互数据和行为非常的稀疏,如何做比较好的推荐、能够引导进行后续更加稠密的交互,增加粘性,以此来提升用户体验,更好的满足用户的需求。

  • 人工运营规则 VS 机器算法:在资讯信息流推荐系统承担的可能不止是一个长尾兴趣的分发,还会有一些运营行为和人为规则的引入。所以两者的效果如何调和、平衡甚至是互补,也是一个难题。其中,我们要明确算法的边界是什么,哪些能做,哪些达不到,比如让机器去做文本分类,业界已经有很成熟的解决方案了,但是让机器去判别文风或者文采,就会很难。首先如何定义这些就是主观的标准,对人来说,尚且不容易,让机器去评判一个非常主观的标准,本身就是很难的。

  • 所以如何确定机器算法的边界是什么,以及边界之外人是否可以有效的进行互补,是最后这个问题的难点所在,可能就需要大量的经验,以及实验才能知道。




整体架构跟业内是相似的,也是基于召回和排序的框架。左边的内容池是百万的量级,经过召回部分的初筛,规则过滤,粗排序后,可以得到 size 在几千量级的召回候选集;在精排阶段,经过多目标排序的优化,可以将集合降到几百的量级;最后经过重排和人工规则的过滤,将数据集合可以降到几十的数量集,推送给用户。



目前线上的模型都切换到 Deep,以前也尝试过传统的机器学习模型,但是随着模型的迭代演进,发现 Deep 模型相对于传统模型在业务指标上有较大的提升,当在做模型结构、特征工程的时候,对业务的收益是更大的,并且可以更好的贴近业务。


从底往上介绍模型,模型的右下角是用户的信息、交互信息与内容的信息,左下的部分是用户历史的行为集合;再往上一层是数据的 Embedding 层,稠密的向量;第三层的左面是 FM 模型的 Pooling,FM 以前在 CTR 中也用过,相比 GBDT 和 LR 传统的模型在排序结果中表现是非常好的,适合资讯信息流的 Ranking,在这里主要捕捉的是低阶的交叉特征;中间的 DNN 模型捕捉的是更高阶的变化;右面是 Attention 的部分,NLP 中的一个概念,在这里用来捕捉 Session 序列,包括用户的行为序列,所以自然想到用 Attention 去建模。大致看起来,模型的左半边部分像 DeepFM,而右边像阿里的 DIN。再往上一层,将子网络的各个部分做一个 concat,然后几层 Dense,做一个多目标的学习,目标不止有 CTR、Duration 时长,还有会有 Like/Comment 点赞、评论的目标等。最后可以根据业务需求去调整指标的权重,有针对性的去优化,当然这部分我们也计划尝试用强化学习来学习这些超参数。



在模型更新中,这里主要还是以增量更新为主,在模型设计之初,有两条路向前推进:一个是模型的实时性,一个是特征的实时性。我们面临过这个问题的选择,其实两者代表系统实时性不同的维度,每个方向去提升实时性的话,都意味着会付出大量的代价,有工程的代价,也有系统设计难度的代价。基于自身业务去考虑,我们最终选择了重特征的实时性,轻模型的实时性。在示意图中,左面是小时级的特征,通过训练,增量的对模型进行更新;右面是通过全量样本对模型进行全量的 full-batch 更新,因为如果一直使用增量模型,时间长了会产生一定的偏差,偏差累积效应会影响线上效果,因此,定期的全量更新是必须的。


相比离线特征,现在的实时这块已经做到了秒级的更新。而如果增加模型的实时性意味着能更快的捕捉新的特征,或者让模型学习到特征与特征之间的泛化关系。在资讯信息流的推荐中,能捕捉到的比如当前的热点、人群的、兴趣的全局变化,通过结合自身的业务,发现,比如说热点、兴趣、人群的变化在一段时间内是稳定的,特征之间的泛化并不会那么大,比如看美食类的用户多半也看看养生、娱乐等等。所以这里模型的更新选择小时级是一个比较好的对资源的权衡。



样本的 Reweight 对于实际业务有一个挺大的提升,对于解释模型也是一个很好的例子。


比如在定义任务目标时,我们除了想优化用户的点击率,还想让用户有更高的刷新次数。所以,rewight 定义了一个用户的跳出率,即文章的跳出率=用户最后一刷的曝光除以文章的总曝光。将文章跳出率乘在原始样本标签上,对用户的一个 Session 最后一刷的样本进行调权,惩罚跳出率高的,奖励跳出率低的。这个非常容易理解,即如果一个内容造成非常高的跳出率,就是说内容本身可能有问题,那么对它进行降权。结合 Reweight,可以更好的指导模型的权重优化,提高模型对具体目标的优化能力。


在跳出率分段-权重模型图中可以看出,横坐标是跳出率的分段,纵坐标是模型的权重,对于内容来说,模型的权重越高,就证明内容质量越好,对于点击刷新率是一个正的贡献,左面模型权重很低,就证明内容质量比较差,对于点击刷新率是一个负的贡献。模型上线后,线上 ABTest 的绝对值提升有将近 1%,还是不错的。



推荐本身就是各种 Metric 的权衡,对于推荐来说,是非常重要的。因为系统需要科学的衡量指标,但是衡量指标之间往往存在一定的关联、因果和矛盾,为了更好的撬动核心指标,我们需要理清这些指标的关系。


按照事件发生的逻辑顺序,先有曝光,列表曝光时间,点击,阅读时长,阅读完成比,最后用户会产生分享、收藏、点赞、评论等一些动作;与这些对应的是推荐品质的衡量级别:曝光与列表曝光时间产生的是曝光质量以及曝光的负反馈;而曝光与点击的数据对应着 CTR 的转化率;阅读时长和阅读完成比则是对于内容的自身质量的评价指标;最后,一个用户的交互行为,如分享、收藏、点赞、评论等信息,则是在用户看完内容之后产生了共鸣,才会去完成这些动作,才会有冲突点和传播价值。


PPT 下面是在实际业务中,不同指标的组合,对应优化目标变化的结果,最后优化 CTR、阅读时长与交互,即优化目标是让 CTR 稳定,阅读时长提升,互动率提升,则系统就会倾向于推荐品质相对较好的视频和文章,并且能够激发用户互动,助推留存的提升。留存率的指标是比较难去直接优化的,因为是长期的指标,所以难以建立模型去优化,假设定义留存率是 7 日留存,那么可能需要通过 7 天之后的样本数据建立因果联系,但是这个因果联系未必是正相关,因为中间会有很多变量来决定这个用户留存或者流失,所以说这个指标是很难优化的,我们需要找到顺序相关的指标进行间接优化。而我们这里使用的 CTR+阅读时长+交互信息,三个指标都是正向的,从实际的效果来看对业务的提升是比较好的。




因为以前有许多同学在特征工程这块做过分享,所以这里会说的简单一些。先来说说特征框架。自底向上,主要是三条 pipeline 的流向,左面的离线日志,中间的实时日志,已经做到了秒级的采集,以及最右边的线上请求数据。中间层特征框架是我们共同抽象出来的共有特征组件,包括线上的请求、实时的处理以及离线的数据,保证了特征的一致性,就是说离线的模型训练与线上的模型预估用的是同样的特征数据,这是非常重要的,如果你在这个部分有偏差的话,就会出现一些特征穿越现象,这也是在早期的推荐系统中非常容易被忽视的一个点。最后是数据的存储,离线日志会存到 Hive 中,而实时的数据则会存到 Redis 集群。当线上请求过来的时候,通过特征框架的规范化,去请求模型,最后通过模型得到排序的结果,这就是整个特征框架的一个大致流程。



如果说刚才是从系统的角度去讲特征,这里则主要是从内容或者说从特征分类的角度进行划分:


  • 用户画像:主要是用户的人口属性、兴趣属性、层次以及用户的行为偏好

  • 内容画像:对于内容的一些分类,NLP 的处理,统计类的一些指标,文本质量的分数,以及向量稠密表示

  • 请求上下文:客观环境的描述,比如说时间、天气、地域、手机型号、品牌等


这些特征会进行一定的交叉,赋予这个特征更多的含义。比如说使用用户画像和内容画像做交叉,可以得到用户的长短期的兴趣匹配、Session 兴趣泛化匹配、用户年龄对于某些内容类别的偏好、用户性别对于某些内容类别的偏好等。


如果拿用户画像与请求的上下文进行特征的交叉,则会得到用户常驻地在什么地方、用户的兴趣随时间的变化,比如有的用户会在早上看新闻,而在晚上看一些娱乐类的资讯;还有一些场景的刻画,如用户喜欢在地铁上看视频,而在办公的时候喜欢看图文。大概能够得到当前时下最热的一些 topic 是什么,或者手机品牌对于用户的影响,如华为手机的男性用户比偏多,而小米手机年轻人用的比较多等。这些特征的构建对于推荐系统的解释性有很好的支撑,如果没有很强的可解释性,优化的天花板会很低,所以你不知道该往哪个方向进行优化,而这些特征的组合就是为了增加模型的可解释性。



因为之前大家对于用户画像的比较关心,所以这里单独增加了一个 slide。简单介绍下,用户画像的特征工程其实是比较简单的,主要是数据的处理环节,在画像的设计上可能会有些考量。资讯类的用户画像主要分为三类:统计类、推断类、固有类。右面的思维导图是大概的用户画像的归类,主要是:


  • 用户的兴趣分类:用户对内容资讯不同层面的偏好度

  • 用户行为画像:主要是时间的偏好,体验的偏好

  • 用户的等级:根据用户的使用频次以及粘度进行划分

  • 社交画像:地理位置,以及附近的人等

  • 人口属性:刚才说到的性别年龄等

  • 数据采集:显性的包括点击、曝光等;还有隐形的如评论、阅读时长等

  • 地理位置信息:用户当前的位置 POI,常驻的地理位置等


用户画像的难点是如何平衡各类的偏差 Bias。


在左下角的图中,蓝色的用户 A,如果出现点击行为,我们内部一般称为 Signal 信号,怎样衡量信号的一个强弱,除了要跟这个用户自身的历史去比较,还要跟同期产生这个行为的用户进行比较,然后来判定 A 用户的信号的强弱,其实有点像对用户的输入信号做一个 normalize 的过程。



召回部分是一个挺大的话题,我们同样使用了多路召回的方法,这里只介绍利用 FFM 模型进行召回的方法,我们是使用 FM 做排序的,而排序是有中间产物的,图中公式的红框中是一些稠密的向量表示,把它们抽出来,就会组合成我们想要的一些稠密表示,比如用户的稠密表示、内容的稠密表示,这也对应着用户的 Embedding 和 Item 的 Embedding,将 User Embedding 拆分成三个分量,Item 也拆分为三个 Feature、ID 和 Context 的特征向量,将他们一一对应并做内积,最后 User 向量利用 Faiss 计算对应的 Item 向量的 NN 结果作为召回集合,最后可能会做一些后处理,如过滤或者打散等。


FFM 模型召回其实理解起来很简单,它有很多优点:


  • 它是有优化目标的召回,可以很好的结合业务定制优化目标,来引导向量学习。

  • 可以在一定程度上解决 Item 冷启动的问题,比如一个新的 Item 进来后,可以生成向量,进行向量的相似度计算。

  • 在保证召回结果足够的个性化的同时,可以带来足够多的惊喜度,这也是非常重要的,因为 FFM 模型召回的覆盖度是很好的,可以将一些新的内容进行召回,增大了惊喜度的可能。

  • 避免传统协同过滤带来的"马太效应",传统的协同过滤是基于 currence 的方式产生的,更容易推荐一些偏热的内容,而 FFM 模型可以有效的抑制这种现象,更偏向于个性化。



下面来介绍一些延展性的问题,具体的问题以及对应的一些思路:



标题党的内容是挺讨厌的,随着媒体生态的建设,内容创作者为了某些利益会写一些与内容不符的标题,吸引用户注意。标题党会严重影响用户的时长,降低内容的品质,还会使得跳出率升高,影响留存。怎么鉴别标题党呢,可以从三个角度出发:


  • 从内容特征入手,主要是用 NLP 建立模型,最初始的训练数据可能需要人为的去标记

  • 再有就是通过用户举报去积累数据

  • 从数据特征入手,使用用户的评论等数据可以进行甄别



其实主要还是使用内容的动态特征,也就是内容的消费数据,我们将内容消费按照时长划分了 6 个维度,转化率划分了 5 个百分维度,阅读完成比划分了 5 个百分维度,相互组合共有 150 维的特征,文章的归属为其中的一类组合作为文章的动态特征,比如"时长 0-30s,阅读比 10-30%,转化 15%-20%"。


我们做了大量统计和对比发现"标题党"类的内容会存在:高转化率、低时长、低完成比的性质;而相反中等转化率、高时长、高完成比,我们一般定义为优质深度类的内容。那我们这样去构造特征是否真的具有实际意义呢?来看一个线上用户的真实例子:



tp 开头的编号,就是我们对应的动态特征的区间,数据都脱敏了,可以看到第二列深度阅读,用户在时政、娱乐,或者说旅游,在深度阅读上是有非常明显的倾向的,并且用户在这些类型的内容下对标题党有非常强的敏感度,也就是说用户对这些标题党内容有低完成比与高跳出率,根据我们实际对这个用户的了解、根据浏览历史去匹配发现,这样的特征构建是符合用户的特征。所以我们将这个特征体系加入到精排模型以及重排模型,是有效的抑制用户对分类下的标题党的情况,从而优化用户整个阅读的体验。在实际的 ABTest 上,我们加入这些特征,对于用户的留存和体验是有一个比较明显的提升的。



再来看下缩略图的优化,在 Feed 流产品里,标题和缩略图其实是非常核心的信息传达元素,因为除了标题和缩略图,其它的视觉元素相对的都比较小,所以如何优化缩略图,对信息流的提升效果也是重要的关键。针对缩略图的优化我们也做了很多工作,比如有缩略图的裁剪,传统的裁剪是偏规则的裁剪,会出现一些比较诡异的结果,特别是针对于人脸的裁剪,经常会把头或者脸的一半裁剪掉。我们添加了一个美学的图像裁剪模型做监督并捕捉图像焦点特别是人脸等易错的焦点部分。在图中下半部分,中间的部分就是我们新的模型上线后的效果,会比原来的方法好很多。


智能缩略图的选择也是很重要的,我们利用 Fine-tune 的一个美学判分模型 RankingModel 来进行缩略图的选择,变成一个排序的任务,将文章里所有的图进行排序,然后选出最好的那个图作为封面图。


最终,通过 Topic Model 进行标签的配图,根据文章语义 Topic 关联预定的图片,让没有图片的文章也配上图。这里就不在赘述了。



最后,感谢 AI 技术中心同学们的整理,如有问题,或者愿意加入我们,欢迎联系:


madi@ifeng.com


PS:欢迎加入 DataFunTalk 推荐算法 技术交流群,跟同行零距离交流。如想进群,请加逃课儿同学的微信(微信号:DataFunTalker),回复:推荐算法,逃课儿会自动拉你进群。



Q:图片、视频文本内容自动打标签那怎么做?


A:文本这部分主要是 NLP 模型产生的结果,如关键词、命名实体的抽取,包括否是一个标题党、是否是一个软文,以及知识图谱,实体之间的关系的标签。视频则主要是对于帧的抽取,对帧的 label,以及帧与帧之间的相似度的建模产生一些 label,这些 label 最后会转换成一些 topic,最后作为视频的标签。现在我们的模型很多是基于 Embedding 的输入,所以视频我们会跳过标签的环节,直接打上语义的 Embedding,以及用户行为的 Embedding,将两个做融合,行为的 Embedding 主要是 item2vector 得到的。


Q:实现信息流推荐技术的核心是什么?


A:其实每个环节都非常重要。实际上推荐的难度是在于量级不同而带来差别。当量级很大的时候,基于召回、排序的框架的效率就很高,所以部分的技术就是核心;而更偏重业务侧指标的信息流推荐,他的线上规则,重排序以及更复杂的业务逻辑是核心。


Q:线上模型演进,目前用了哪些,效果怎样?


A:以排序模型为例,最开始是基于人工特征,使用 LR+GBDT 的方式去做,后来使用了 FM,发现 FM 在一些稀疏特征上非常好,它的特征交叉也非常的有用,然后上了 FFM,效果进一步的提升,目前线上已经使用 Deep 模型是单模型中效果最好的。


Q:新闻资讯有图文和视频,如何做特征?


A:图文的特征我在内容特征部分已经介绍过了,这里就不赘述了。关于视频部分的特征,一部分是从关键帧抽取的离散特征,并通过帧序列抽取的 Topic 类特征,还有一些清晰度、码流等固有特征,还有利用比对能够获得的视频源以及视频内的一些实体、任务、场景、地点以及通过知识图谱扩展的概念等,以及少部分标题特征。还有一部分是利用视频语义映射到稠密向量,一部分类似 item2vec 基于用户行为学习的向量,一部分是基于关键帧语义模型构建的向量,两者做求和平均。


Q:如果要转行做推荐算法,有什么建议,如何实践推荐?


A:主要看你从哪个方向进行转型,如果是从图像或者 AI 的相关行业的话,难度不大,需要了解一些业务实际相关的经验;如果之前没有这方面的经验,则需要数学的背景和一些机器学习的理论,还需要一些数据实践的能力。如果是在校学生,你可以参加一些比赛,如 Kaggle 等,或者下载一些数据集练练模型;而从业者则可以在相应的应用场景拿一些数据,跑跑 Demo 的模型,实践这种东西需要看你有没有很好的机会去做。


Q:特征处理方面有哪些经验或者踩过的坑可以分享一下吗?


A:坑有很多,特征的添加和组合是通过业务不断的尝试出来的,特征这个地方可能会有一些方法论,但都是一些框架性的东西,怎样验证一个特征有效,也需要做很多的工作,甚至要实际上线做 ABTest,因为这块没有太多现成的经验和大家分享,需要在业务中做一个细致的整理。


Q:怎样解决推荐中的信息茧房问题?推荐系统常见的问题是回声室效应,从用户角度,有没有一些其它的技术?


A:工业界其实很少会去提这个概念,学术界更偏向于去研究这个问题。工业界其实更倾向于多样性、探索与利用的问题。也就是我们要去识别当前用户的状态是,用户愿意继续消费他感兴趣的信息流,做一些广泛的探索,还是说他目前有一些疲劳。这个类似于有限状态机,我们需要去建模用户不同的状态以及他调到下一个状态的概率是多少,以及用户疲劳后的试探,这里其实还是一个模型建模与特征匹配的问题,这是一个多层次状态机 + 多层次试探的问题。所以工业界对于信息茧房这个问题不是特别关注,而更愿意用一些简化的模型去解决这个问题,当然我们不排除这个问题对用户是有影响的,如果你一直给一个用户看他以前看过的内容,或者他不关心的内容,他的兴趣会越来越窄,所以我们会增加结果的多样性,包括它的用户画像等,并不只是用户的长尾兴趣,还会有些试探的东西在里面。以及基于他现在的一些推荐,使用知识图谱推理出用户应该去看的东西,相当于增加一些人工的因素在里面,其实推荐出了长尾的推荐这一部分,还有人工运营的部分,会有一些额外的信息进来,修正纯靠算法带来的一些缺点,在一定程度上也能缓解信息茧房和回声室效应这种问题。


Q:互联网公司的新闻推荐和传统传媒行业的新闻推荐在业务上有何不同的侧重点?


A:互联网推荐可能更偏兴趣推荐,会带来了更多的曝光、信息流、营收、广告收入等,传统的媒体行业可能更多的是自家的品牌的提升。这两个行业的资源也是不一样的,互联网的资源更多一些,包括自媒体的建设、激励制度,数据用户量资源更大;传统媒体行业资源和用户可能相对更加垂直一些,人群也不一样,营销自己的品牌价值,产生溢价,产生媒体影响力等。


作者介绍


马迪,凤凰网 技术总监


本文来自 DataFunTalk


原文链接


https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247498125&idx=1&sn=52efbe5876151b48a917640f5f56c589&chksm=fbd74be1cca0c2f7b2f378a1b15339ef8697544c2b43bb9b51c7c9eaa79b6aea119d943786a9&scene=27#wechat_redirect


2020-03-17 14:004174

评论

发布
暂无评论
发现更多内容

在字节,大规模埋点数据治理这么做!

字节跳动数据平台

大数据 字节跳动 埋点 流量 埋点治理

模块三作业

cqyanbo

模块八

侠客行

「架构实战营」

你只会用 split?试试 StringTokenizer,性能可以快 4 倍!!

CRMEB

百度智能云开物秀出全年成绩,发布和升级五大新产品

百度大脑

人工智能 百度

1.6(下周四)直播 | 观测云实践学堂03期:K8S太复杂,可观测实践一筹莫展?全新K8S实践干货直播间等你!

观测云

直播

网络编程懒人入门(十三):一泡尿的时间,快速搞懂TCP和UDP的区别

JackJiang

TCP 网络编程 udp 即时通讯 IM

直播整理 | TDengine 技术内幕分享:兼容 OpenTSDB

TDengine

数据库 tdengine OpenTSDB

面试被问spring ioc,这样说让面试官眼前一亮(1)

公众号:程序猿成神之路

spring 5

59 K8S之Elasticsearch节点

穿过生命散发芬芳

k8s 28天写作 12月日更

Presto 在字节跳动的内部实践与优化(优化篇)

字节跳动数据平台

大数据 字节跳动 presto

Dubbo的预热与停机实践

快看工程技术中心

dubbo 优雅停机 服务预热

如何把 MySQL 备份验证性能提升 10 倍

Juicedata

MySQL 数据库 云存储 数据备份

恒源云(GPUSHARE)_[SimCSE]:对比学习,只需要 Dropout?

恒源云

深度学习

数字中国建设再提速,智慧金融发展如何跑出“加速度”?

百度大脑

人工智能 数字化 智能化

检索、问答、情感分析场景前沿技术方案分享!

百度开发者中心

自然语言处理

Apache APISIX Dashboard 未授权访问漏洞公告(CVE-2021-45232)

Apache APISIX 中文社区

漏洞修复 CVE Apache APISIX

大凉山的新衣,产业AI的未来

脑极体

28天写作总结

wood

28天写作

[架构实战营] 模块八作业

张祥

架构实战营

Spring框架基础知识(02)

海拥(haiyong.site)

28天写作 12月日更

2021年末28天写作营总结

mtfelix

28天写作

怎么借助Camtasia制作回忆录

淋雨

Camtasia 录屏 luping

httprouter源码刨析

王博

Presto 在字节跳动的内部实践与优化(实践篇)

字节跳动数据平台

大数据 字节跳动 presto

QCon-小布助手对话系统工程实践

OPPO数智技术

网络安全审计之CMS代码审计

网络安全学海

黑客 网络安全 信息安全 渗透测试 代码审计

2021,用「创新」重新定义ToB

ToB行业头条

信息流推荐在凤凰新闻的业务实践_AI_DataFunTalk_InfoQ精选文章