整体架构首先看一下58同城推举系统整体架构，一共分数据层、策略层和运用层三层，基于58平台产生的各种业务数据和用户积累的丰富的行为数据，我们采取各种策略对数据进行挖掘剖析，终极将结果运用于各种推举场景。
数据层：
紧张包括业务数据和用户行为日志数据。业务数据紧张包含用户数据和帖子数据，用户数据即58平台上注册用户的根本数据，这里包括C端用户和企业用户的信息，帖子数据即用户在58平台上发布的帖子的根本属性数据。这里的帖子是指用户发布的房源、车源、职位、黄页等信息，为方便表达，后文将这些信息统称为帖子。用户行为日志数据来源于在前端和后台的埋点，例如用户在APP上的筛选、点击、收藏、打电话、微聊等各种操作日志。这些数据都存在两种存储办法，一种是批量存储在HDFS上以用作离线剖析，一种是实时流向Kafka以用作实时打算。
策略层：
基于离线和实时数据，首先会开展各种根本数据打算，例如用户画像、帖子画像和各种数据剖析，在这些根本数据之上便是推举系统中最主要的两个环节：召回和排序。召回环节包括多种召回源的打算，例如热门召回、用户兴趣召回、关联规则、协同过滤、矩阵分解和DNN等。我们采取机器学习模型来做推举排序，先后迭代了LR、FM、GBDT、领悟模型以及DNN，基于这些根本机器学习模型，我们开展了点击率、转化率和勾留时长多指标的排序。这一层的数据处理利用了多种打算工具，例如利用MapReduce和Hive做离线打算，利用Kylin做多维数据剖析，利用Spark、DMLC做大规模分布式机器学习模型演习，利用theano和tensorflow做深度模型演习。
运用层：
我们通过对外供应rpc和http接口来实现推举业务的接入。58同城的推举运用大多是向用户展示一个推举结果列表，属于topN推举模式，这里先容下58同城的几个主要的推举产品：
1、猜你喜好：58同城最主要的推举产品，推举场景包括APP首页和不同品类的大类页，目标是让用户打开APP或进入大类页时可以快速找到他们想要的帖子信息，这紧张根据用户的个人偏好进行推举。
2、详情页干系推举：用户进入帖子详情页，会向用户推举与当前帖子干系的帖子。该场景下用户意图较明显，会采取以当前帖子信息为主用户偏好信息为辅的办法进行推举。
3、搜索少无结果推举：用户会通过品类列表页上的筛选项或搜索框进入品类列表页获取信息，若当前筛选项或搜索条件搜索出的结果较少或者没有结果，便会触发推举逻辑进行信息推举。此时会结合当前搜索条件的扩展以及用户偏好信息进行推举。
4、个性化推送（Push）：在用户打开APP前，将用户感兴趣的信息推送给他们，匆匆利用户点击，提高用户生动度。这里包含推送关照的天生和推送落地页上帖子列表的天生两个推举逻辑。值得一提的是推送是逼迫性的推举，会对用户形成骚扰，因此如何降落用户骚扰并给用户推举真正感兴趣的信息尤为主要。
5、Feed流推举：我们的推举产品在某些推举场景下因此Feed流的形式展现的，例如APP中央的今日推举场景、推送落地页场景。用户可以在这些页面中不断下拉刷新消费信息，类似时下火热的各大资讯Feed流推举。
推举系统是一个繁芜的工程，涉及算法策略、工程架构和效果数据评估三方面的技能，后文将分别从这三方面先容58同城推举系统。
算法
推举涉及了前端页面到后台算法策略间的各个流程，我们将推举流程抽象成如下图所示的召回、排序、规则和展示四个紧张环节：
召回环节即利用各种算法逻辑从海量的帖子中筛选出用户感兴趣的帖子候选凑集，一样平常凑集大小是几十到上百。
排序即对候选凑集中的帖子进行打分排序，这里一样平常会利用机器学习排序模型，排序环节会天生一个排序列表。
规则环节即我们可能对排序列表采纳一定的规则策略，最终生成一个包含N条结果的列表。例如在规则环节我们可能会采纳不同的去重策略，如文本去重、图片去重、稠浊去重等，可能会采纳不同的列表打散策略，可能会迭代产品经理提出的各种规则逻辑。由于推举系统的终极评价是看统计效果，因此各种人为的规则都会影响终极结果，我们抽象出规则环节后便可以对任何逻辑做线上ABTest，终极评价干系逻辑是否合理。
天生N条推举结果列表后，不同的前端展示办法也会影响终极的推举效果，例如不同的UI设计，采取大图模式还是小图模式，页面上展示哪些字段都会影响用户在推举列表页上的点击，因此在推举产品迭代过程中不同的展示样式迭代也很主要。
在上述的四个环节中，召回和排序是推举系统最主要的两个环节。规则和展示样式一样平常变革周期较长，而召回和排序有很大的挖掘空间，会被不断的迭代，我们的推举算法事情也紧张是环绕召回和排序进行。下图是我们推举算法的整体框架，紧张包括根本数据的打算以及上层的召回策略和排序模型的迭代。
根本数据打算紧张包括用户标签和帖子标签的挖掘，这部分事情由用户画像、搜索和推举多个团队共同完成，终极各团队共享数据。基于用户注册时填写的根本属性信息和用户行为日志，可以挖掘出用户人口属性和兴趣偏好信息，如用户的年事、性别、学历、收入等根本属性，用户感兴趣的地域商圈、二手房均价、厅室、装修程度等偏好信息。帖子标签挖掘包括提取帖子的固定属性、挖掘衍生属性以及打算动态属性。固定属性直接从帖子数据库提取即可，如分类、地域、标题、正文、图片、房源价格、厅室、小区等。我们还会基于贴子信息是否完备、价格是否合理、图片质量好坏、发帖人质量等多个维度来打算帖子质量分。基于用户行为日志数据可以打算帖子的PV、UV、点击率、转化率、勾留时长等动态属性。这些数据终极会在召回环节和排序环节利用，例如基于用户标签和帖子标签可以进行兴趣召回，将用户标签和帖子标签作为特色迭代机器学习模型。
召回紧张卖力天生推举的候选集，我们采取多种召回源领悟的办法来完成该过程。我们先后迭代了如下各种召回策略：
热门召回。基于曝光和点击日志，我们司帐算不同粒度的热门数据。以二手车业务线为例，从粗粒度到细粒度的数据包括：城市下的热门商圈、商圈下的热门车系和品牌、特定车系和品牌下的热门车源等。每一个车源的热度我们通过最近一段韶光内帖子的PV、UV、CTR等指标来衡量，这里的CTR会通过贝叶斯和COEC做平滑处理。热门召回策略会在冷启动时被大量采取。
地域召回。58同城是向用户供应本地生活做事类信息，用户的每次访问都会带上地域信息，如选择的城市、定位的地点等。我们紧张结合地域信息和热门数据做召回，如附近最新或最热帖子召回、城市热门帖子召回等。
兴趣召回。基于帖子根本属性字段和帖子标签信息，我们构建了一套帖子检索系统，通过该系统能够以标签或属性字段检索出最新发布的帖子。在用户画像中，我们打算了每个用户的兴趣标签，因此基于用户兴趣标签便能在检索系统中检索出一批帖子，这可以作为一种召回源。此外，在帖子详情页干系推举场景中，我们也可以利用当前帖子的属性和标签信息去检索系统中检索出干系帖子作为召回数据源。这两种检索召回实在便是我们常说的基于内容的推举。
关联规则。这里并非直接采取传统Apriori、FP-growth关联规则算法，而是参考关联规则思想，将最近一段韶光中每个用户点击所有物品当做一次事务，由此打算两两物品之间的支持度，并在支持度中融入韶光衰减因子，终极可以得到每个物品的topK个关联性强的物品。这种召回办法实在类似协同过滤中的item相似度矩阵打算，我们紧张将其运用在详情页干系推举中。
协同过滤。我们利用Spark实现了基于User和基于Item的批量协同过滤打算，由于数据量大，批量打算会较花费韶光，我们又实现了基于Item的实时协同过滤算法。常日情形下我们会直接将用户的推举结果列表作为一种召回源，而在详情页干系推举场景，我们还会利用协同过滤打算出的Item相似度矩阵，将帖子最相似的topK个帖子也作为一种召回源。
矩阵分解。我们引入了SVD算法，将用户对帖子的点击、收藏、分享、微聊和电话等行为操作看浸染户对帖子进行不同档次的评分，从而构建评分矩阵数据集来做推举。
DNN召回。Google在YouTube视频推举上利用了DNN来做召回，我们也正在进行干系考试测验，通过DNN来学习用户向量和帖子向量，并打算用户最附近的topK个帖子做为召回源。
上述不同的召回算法都产生出了一部分推举候选数据，我们须要将不同的召回数据领悟起来以提高候选集的多样性和覆盖率，这里我们紧张利用两种召回领悟策略：
分级领悟。设置一个候选集目标数量值，然后按照效果好坏的次序选择候选物品，直至知足候选集大小。假设召回算法效果好坏的顺序是A、B、C、D，则优先从A中取数据，不敷候选集目标数量时则从B中取数据，依次类推。我们的系统支持分级领悟策略的配置化，不同召回算法的先后顺序可以灵巧配置。这里的效果好坏顺序是根据离线评价和线上评价来决定的，例如离线我们会比较不同召回算法的召回率和准确率，线上我们会比较终极点击或转化数据中不同召回算法的覆盖率。
调制领悟。按照不同的比例分别从不同召回算法中取数据，然后叠加产生终极总的候选集。我们的系统也支持调制领悟策略的配置化，选择哪些召回算法、每种召回算法的选择比例均可以灵巧配置。这里的比例紧张根据终极线上点击或转化数据中不同召回算法的覆盖率来设置。
召回环节新召回源的添加或者新领悟策略的上线，例如开拓了一种新召回算法、须要修正调制领悟策略中的配比等，我们都会做线上ABTest，终极通过比较不同策略的效果来辅导我们的迭代。值得一提的是，召回环节我们还会有一些过滤规则，例如过滤低质量帖子、在某些特定场景下对召回算法产生的结果加一些条件限定等。
排序环节我们紧张采取Pointwise方法，为每个帖子打分并进行排序，通过利用机器学习模型预估帖子的点击率、转化率和勾留时长等多指标来做排序。早期我们紧张优化点击率，目前我们不仅关注点击率外还会看重转化率的提高。在58同城的产品场景中，转化紧张指用户在帖子详情页上的微聊、打电话操作。
排序离线流程紧张包括样本天生和选择、特色抽取、模型演习和评价。首先对埋点日志中的曝光、点击、转化和勾留时长等数据做抽取解析，如基于曝光序列号关联各种操作、解析埋点参数（例如日志中记录的实时特色）、解析高下文特色等，并同时打上label，天生模型样本。然后对样本进行过滤，例如过滤恶意用户样本、过滤无效曝光样本等。然后对样本做特色抽取，天生带特色的样本，我们紧张从用户、帖子、发帖人和高下文四个维度做特色工程。之后，按照一定正负样本比例做采样，终极进行模型演习和评估，离线评估指标紧张参考AUC，离线效果有提升后会进行ABTest上线，逐步迭代。我们先后迭代上线了如下排序策略：
规则序。早期未上线机器学习模型时，对候选集中的帖子会直策应用刷新韶光、统计CTR或者一些产品规则来做排序。
单机器学习模型。我们最早实践的是LR模型，它是线性模型，大略高效、可阐明性好，但对特色工程哀求较高，须要我们自己做特色组合来增强模型的非线性表达能力，早期我们利用LibLinear来演习模型，后来迁移到了Spark上。之后我们引入了XGBoost树模型，它非线性表达能力强、高效稳定，是目前开源社区里最火热的模型之一，最初我们采取单机版本演习，后期将XGBoost支配在我们的yarn集群上，利用分布式版本进行演习。同时，我们运用了FM模型，比较于LR模型它引进了特色组合，能够办理大规模稀疏数据下的特色组合问题，我们紧张利用分布式FM （DiFacto，FM on Yarn）来进行模型演习。上述这些模型都是批量更新，常日是一天更新一次，为了快速捕捉用户行为的变革，我们还引入Online Learning模型，紧张考试测验运用FTRL办法去更新LR模型，在某些场景下得到了稳定的效果提升。
领悟模型。类似Facebook、Kaggle的做法，我们实践了GBDT+LR和GBDT+FM的模型领悟方案。首先利用XGBoost对原始特色做处理天生高阶特色，然后输入到LR和FM模型中，目前我们的点击率预估模型中效果最佳的是GBDT+LR领悟模型，转化率预估模型中效果最佳的是GBDT+FM领悟模型。此外，我们还会考试测验将某个单指标（如点击率）下多个模型的预测结果进行领悟（如相加或相乘等），也会将多个指标（点击率、转化率和勾留时长）的模型进行领悟（如相乘）以不雅观察效果。
深度模型。深度学习正逐渐被各大公司运用于推举系统中，我们也正在进行考试测验。目前，我们已将FNN（Factorisation machine supported neuralnetwork）模型运用在我们的推举排序中，比较单机器学习模型，FNN有较稳定的效果提升，但比领悟模型效果要稍差，目前我们正在进行深度模型的调优，并在考试测验引入Wide&Deep等其他深度模型。
基于上述根本机器学习工具，目前我们紧张会迭代点击率、转化率和勾留时长预估模型，线上会ABTest上线单指标模型、多指标领悟模型，以提高推举效果。
架构
对付推举系统来说，一套支撑算法策略高效迭代的推举后台系统至关主要，我们基于微做事架构设计了推举后台系统，它扩展性好、性能高，系统架构如下图所示，系统分为数据层、逻辑层和接入层，数据层供应各种根本数据的读取，逻辑层实现召回和排序策略并支持不同策略的ABTest，接入层对外供应了通用的访问接口。
数据层供应推举逻辑所须要的各种数据，这些数据存储在WRedis、文件、WTable等多种设备上，我们将所有数据的读取都封装成RPC做事，屏蔽了底层的存储细节。这里包括检索做事、召回源读取做事、帖子特色中央和用户特色中央：
检索做事。我们搭建了一套搜索引擎用做召回检索，支持基于各种搜索条件去检索数据，例如可以检索出价格在200万至300万之间的回龙不雅观两室的房源、检索出中关村落附近的最新居源。该做事紧张运用于这几类场景：在猜你喜好推举场景中基于用户标签去检索帖子、在干系推举场景中基于当前帖子属性去检索干系帖子、冷启动时基于地域信息召回附近的帖子等。
召回源读取做事。供应各种召回源数据的读取，这些召回源数据通过离线或实时打算得到，包括热门数据、协同过滤数据、关联规则数据、矩阵分解结果等。该做事设计得较灵巧，支持任意召回源的增加。
帖子特色中央。供应帖子所有属性字段的读取，在召回、排序和推举主体逻辑中会利用到这些帖子属性，一样平常情形我们会在召回环节读取出所有帖子属性，然后运用于排序和规则逻辑中。召回得到的候选集大小一样平常是几十到几百，为了支持高性能的批量读取，我们选择利用WRedis集群存储帖子属性，并通过多线程并发读取、缓存、JVM调头等多项技能担保做事性能。目前，该做事每天承接数亿级要求，均匀每次读取150条数据，耗时担保在2ms之内。
用户特色中央。UserProfile数据包括用户离线/实时兴趣标签、人口属性等，该数据会在召回环节利用，例如利用用户兴趣标签去检索帖子作为一种召回源，也会在排序环节利用，例如将用户标签作为机器学习排序模型的特色。
逻辑层实现了详细的推举策略，包括推举主体做事、召回做事、排序做事和ABTest实验中央。这些做事由不同的开拓职员掩护，担保了推举策略的高效迭代，例如召回和排序是我们常常迭代的环节，由不同的算法职员来完成，召回做事和排序做事的分离降落了耦合，提高了迭代效率。
推举主体做事。吸收推举要求，解析推举场景参数，调用用户特色中央获取用户信息，要求ABTest实验中央获取对应场景的ABTest实验参数，如召回策略号、排序算法号、规则号和展示号。然后将推举场景参数、ABTest实验参数等发送至召回做事得到候选集列表，之后再调用排序做事对候选集进行排序，终极对排序列表做干系规则处理，将结果列表封装返回。
召回做事。吸收场景参数和召回策略号参数，调用检索做事和召回源读取做事读取各种召回数据，并进行分级领悟或调制领悟。我们实现了召回策略的配置化，一个召回号对应一种召回策略，策略采取哪种领悟办法、每种领悟办法下包含哪些召回源、不同召回源的数量均通过配置来完成。我们将召回配置进行Web化，算法或产品职员只需在Web页面上配置即可生效策略。此外，召回层还包括一些过滤规则，例如过滤低质量信息、过滤用户历史浏览记录、过滤产品指定的符合某些特定条件的数据等。
排序做事。吸收场景参数、用户信息、候选集列表和排序算法号等参数，调用机器学习排序模块，对候选集列表做排序。我们设计了一套通用的特色提取框架，担保机器学习离线模型演习和线上排序共用相同的特色提取代码，并灵巧支持不同模型之间的特色共享。在排序做事中上线一种模型本钱很低，只须要供应模型文件和特色配置文件即可，后续我们将会对排序配置进行Web化，简化上线流程。目前，我们的排序做事中运行了基于LR、XGBoost、FM、XGBoost+LR、XGBoost+FM、DNN的几十个排序模型。
ABTest实验中央。我们设计了一套灵巧通用的ABTest实验平台（内部称作“日晷”）来支持推举系统的策略迭代，它包括流量掌握、实时效果数据统计和可视化等功能，支持用户在Web页面上配置实验和流量，并能展示实时效果数据。这套实验平台不仅可以运用于推举系统，还可以用于任何其它须要做ABTest实验的业务系统中，它支持多层ABTest实验，能充分利用每份流量去完成业务迭代。例如我们的推举系统ABTest实验就包含召回、排序、规则和展示四层，不同层之间实现了流量的重新打散，担保了不同层之间实验的正交性。当要求到达我们的推举系统时，推举主体做事便要求“日晷”以得到该要求对应的召回号、排序号、规则号和展示号等实验参数，之后该要求便会被这些实验参数打上标记，贯穿于后续的推举流程，决定每层中将走哪部分逻辑，终极这些实验参数会记录到后台和客户端埋点日志中，用于终极的实验效果统计。
接入层直接和客户端交互，从客户端吸收要求并调用推举主体做事得到推举帖子id列表，然后查询出帖子详细属性返回给客户端做展示。在大部分推举场景中，接入层由业务方掩护，可能是PHP或Java实现的http接口；也有少部分场景的接入层是我们自主掩护，我们采取58自研的MVC框架WF实现了干系http接口。
我们采取58自研的RPC框架SCF实现了上述微做事架构的推举系统，采取58自研的监控系统WMonitor实现了推举系统的立体监控，全体技能栈是Java。我们采取多线程、异步、缓存、JVM调优、降级、限流等方法担保了推举系统的稳定和高可用，目前我们的推举系统日均处理数亿的推举要求，均匀耗时约30毫秒。
数据
这里的数据紧张指推举埋点数据和推举效果数据：埋点数据是推举系统的基石，模型演习和效果数据统计都基于埋点数据，需担保埋点数据的精确无误；效果数据是对推举系统的评价，指引推举策略的迭代，构建完备的效果数据体系至关主要。
我们的推举埋点日志数据包括曝光日志、点击日志、转化日志和页面勾留时永日记等，这些日志数据都须要客户端通过埋点来产生。这里大略阐明一下这些操作的含义：客户端要求一次推举接口得到推举结果列表叫做一次曝光；用户点击推举结果列表上的某条帖子进入帖子详情页叫做一次点击；用户在帖子详情页上进行微聊、打电话、收藏等操作叫做转化；用户在帖子详情页上的阅读韶光叫做页面勾留时长。这里的曝光、点击和转化是一个漏斗，操作数量是逐渐递减的趋势。由于58同城上用户对帖子的访问可能来源于推举、搜索和运营活动页等场景，为了标识出推举产生的点击/转化/勾留时长，我们须要在埋点中加入推举干系的参数。我们将埋点参数设计成一个固定格式的字符串，它包含了曝光唯一序列号、推举位标识、召回号、排序号、规则号、展示号、帖子id列表、帖子id等字段，这些字段将会浸染于机器学习模型演习样本天生和推举效果统计中。埋点参数紧张分为列表参数和单贴参数两类：推举接口返回一个帖子列表，会对应返回一个列表参数，包含了曝光序列号、推举位标识、召回号、排序号、规则号、展示号、帖子id列表等字段；返回的帖子列表中，每个帖子会对应返回一个单贴参数，包含曝光序列号、推举位标识、召回号、排序号、规则号、展示号、帖子id等字段。客户端得到推举接口返回的埋点参数后，会将列表参数埋入到曝光日志中，将单贴参数埋入到点击日志、转化日志和勾留时永日记当中，把稳这里埋点时须要推举列表页向帖子详情页通报单贴参数，一样平常须要通过修正跳转协议来实现。终极埋点日志中有了这些参数后，我们便可基于曝光唯一序列号将曝光、点击、转化、时长数据join起来，产生模型演习样本以及漏斗效果数据。值得一提的是，我们采纳透传的办法在推举后台、接入层、客户端间通报埋点参数字符串，所有埋点参数由推举系统后台天生，接入层和客户端均不做任何处理。埋点参数仅由我们推举一方卖力，这样能够避免多方改动埋点参数，从而减少埋点缺点的可能性，由于是透传处理，也便于今后埋点参数的扩展。
埋点数据是推举系统的基石，不能有遗漏或者缺点，这就哀求我们严格把控开拓测试流程，尤其是APP上的埋点，若发版之后创造有缺点，便要等到下一次发版时办理。客户端开拓和测试同事不清楚埋点参数的含义但闇练节制测试环境支配及拥有Android和IOS测试机，而推举后台同事清楚埋点参数含义但对测试环境较生疏并缺少测试机，因此我们总结出了测试同事卖力环境支配、推举后台同事卖力考验埋点参数的测试流程，详细流程如下图所示。此外，58同城上的APP开拓比较繁芜，不同产品线各自开拓自己的APP业务模块，APP平台方开拓主模块，每次发版前都有一个集成阶段，合并所有业务方提交的代码，产生终极的APP包，集成阶段很可能会发生业务方埋点未生效的情形。因此，我们的埋点测试包括业务方内部测试和集成测试两个阶段，以担保埋点万无一失。
我们的推举效果数据是一个多维数据集，我们紧张关注推举位上的点击、转化、勾留时长等指标。日常事情中我们须要从不同业务线、不同客户端、不同推举位、不同推举算法等多个维度去剖析这些指标数据，例如我们会不雅观察房产和车在相同推举位上的数据比拟、猜你喜好场景上不同召回或排序算法的数据比拟、二手房详情页在Android和IPhone上数据比拟等。各种数据剖析比拟能帮助我们优化推举策略，乃至能创造某些业务线功能逻辑上的隐蔽BUG，例如在我们推举项目攻坚阶段，我们通过剖析比较二手房详情页在Android和IPhone两端的推举效果，创造了IPhone上详情页浏览回退的BUG，终极反馈给业务方并办理了该问题，该BUG的办理使得我们在二手房详情页推举位上的推举点击量提高了数十万。
我们从离线和实时两方面构建推举效果数据，数据统计流程如下图所示：
早期，离线效果数据统计是通过 MapReduce + Hive + MySQL 来实现的，我们首先会编写MapReduce程序对原始埋点日志进行抽取天生Hive表，然后会编写大量的Hive SQL来统计各种指标数据，并将结果数据写入MySQL数据表，终极做可视化展示和邮件报表。由于我们比较的维度和指标多，Hive SQL语句的编写花费了我们不少人力。在数据平台部门支配了Kylin多维剖析系统后，我们将效果数据统计事情迁移到了Kylin上，我们只须要设计好Hive源数据表，并设置好维度和度量，Kylin便能根据维度和度量来自动估量算结果数据，这省去了我们编写Hive SQL的事情，大大提高了效率。关于如何利用Kylin构建多维数据集可以参考此文《基于Kylin的推举系统效果评价系统》。
实时效果数据我们采取Storm + HBase 来打算，实时效果数据紧张用于非常埋点监控、新上线推举算法效果快速反馈、模型非常监控等，我们实现了一个包含较少维度的多维数据统计，今后我们将考试测验引入Druid等实时多维剖析系统来完善推举实时效果数据的培植。
总结
本文先容了58同城智能推举系统在算法、工程和数据三方面的技能演进。我们在最近一年加快了推举业务的迭代速率，接入了房产、车等业务线在APP、PC、M三端共计近百个推举位，我们的推举点击占比指标（推举位上产生的点击量在总体点击量中的占比）比较一年之前提高了2~3倍，达到了20%~30%，每天能够产生数千万的推举点击量，为业务线带来了流量提升。
任何推举系统的发展必会经历推举位扩充和推举算法深入优化两个阶段，流量指标可以通过扩充推举位来快速提高，当推举位稳定之后，就须要依赖更加深入的算法优化来连续提高指标，而此时的效果提升也会相对缓慢。目前，我们的流量指标已相对稳定，我们会更进一层去关注转化指标，提高用户进入帖子之后与发帖人进行微聊或电话沟通的可能性，帮助用户找到真正有用的信息。
