在美团搜索AI化的过程中，比较核心的两个组件是模型演习平台Poker和在线预估框架Augur。本文紧张与大家磋商Augur的设计思路、效果，以及它的上风与不敷，末了也大略先容了一下Poker平台的代价。希望这些内容对大家有所帮助或者启示。
搜索优化问题，是个范例的AI运用问题，而AI运用问题首先是个别系问题。经历近10年的技能积累和沉淀，美团搜索系统架构从传统检索引擎升级转变为AI搜索引擎。当前，美团搜索整体架构紧张由搜索数据平台、在线检索框架及云搜平台、在线AI做事及实验平台三大体系构成。
在AI做事及实验平台中，模型演习平台Poker和在线预估框架Augur是搜索AI化的核心组件，办理了模型从离线演习到在线做事的一系列系统问题，极大地提升了全体搜索策略迭代效率、在线模型预估的性能以及排序稳定性，并助力商户、外卖、内容等核心搜索场景业务指标的飞速提升。
首先，让我们看看在美团App内的一次完全的搜索行为紧张涉及哪些技能模块。如下图所示，从点击输入框到终极的结果展示，从热门推举，到动态补全、终极的商户列表展示、推举情由的展示等，每一个模块都要经由多少层的模型处理或者规则干预，才会将最适宜用户（指标）的结果展示在大家的面前。
为了担保良好的用户体验，技能团队对模型预估能力的哀求变得越来越高，同时模型与特色的类型、数量及繁芜度也在进步神速。算法团队如何只管即便少地开拓和支配上线，如何快速进行模型特色的迭代？如何确保良好的预估性能？在线预估框架Augur应运而生。
经由一段韶光的实践，Augur也有效地知足了算法侧的需求，并成为美团搜索与NLP部通用的办理方案。下面，我们将从解读观点开始，然后再分享一下在履行过程中我们团队的一些履历和思考。
2. 抽象过程：什么是模型预估？实在，模型预估的逻辑相对大略、清晰。但是如果要全体平台做得好用且高效，这就须要框架系统和工具培植（一样平常是管理平台）两个层面的合营，须要兼顾需求、效率与性能。
那么，什么是模型预估呢？如果忽略掉各种算法的细节，我们可以认为模型是一个函数，有一批输入和输出，我们供应将要预估文档的干系信息输入模型，并根据输出的值（即模型预估的值）对原有的文档进行排序或者其他处理。
纯粹从一个工程职员视角来看：模型可以简化为一个公式（ 举例：f(x1,x2)= ax1 + bx2 +c ），演习模型是找出最得当的参数abc。所谓特色，是个中的自变量x1与x2，而模型预估，便是将给定的自变量x1与x2代入公式，求得一个解而已。（当然实际模型输出的结果可能会更加繁芜，包括输出矩阵、向量等等，这里只是大略的举例解释。）
以是在实际业务场景中，一个模型预估的过程可以分为两个大略的步骤：第一步，特色抽取（找出x1与x2）；第二步，模型预估（实行公式 ƒ，得到终极的结果）。
模型预估很大略，从业务工程的视角来看，无论多繁芜，它只是一个打算分数的过程。对付全体运算的优化，无论是矩阵运算，还是底层的GPU卡的加速，业界和美团内部都有比较好的实践。美团也供应了高性能的TF-Serving做事（拜会《基于TensorFlow Serving的深度学习在线预估》一文）以及自研的MLX模型打分做事，都可以进行高性能的Batch打分。基于此，我们针对不同的模型，采纳不同的策略：
深度学习模型：特色多，打算繁芜，性能哀求高；我们将打算过程放到公司统一供应的TF-Serving/MLX预估做事上。线性模型、树模型：搜索场景下利用的特色相对较少，打算逻辑也相对大略，我们将在构建的预估框架内部再构建起高性能的本机求解逻辑，从而减少RPC。这一套逻辑很大略，构建起来也不繁芜，以是在培植初期，我们快速在主搜的核心业务逻辑中快速实现了这一架构，如下图所示。这样的一个架构使得我们可以在主搜的核心排序逻辑中，能够利用各种线性模型的预估，同时也可以借助公司的技能能力，进行深度模型的预估。关于特色抽取的部分，我们也大略实现了一套规则，方便算法同学可以自行实现一些大略的逻辑。
3. 预估框架思路的改变
3.1 老框架的局限
旧架构中模型预估与业务逻辑耦合的办法，在预估文档数和特色数量不大的时候可以供应较好的支持。
但是，从2018年开始，搜索业务瓶颈开始到来，点评奇迹部开始对全体搜索系统进行升级改造，并打造基于知识图谱的分层排序架构（详情可以拜会点评搜索智能中央在2019年初推出的实践文章《大众点评搜索基于知识图谱的深度学习排序实践》）。这也意味着：更多须要模型预估的文档，更多的特色，更深层次的模型，更多的模型处理层级，以及更多的业务。
在这样的需求背景下，老框架开始涌现了一些局限性，紧张包括以下三个层面：
性能瓶颈：核心层的模型预估的Size扩展到数千级别文档的时候，单机已经难以承载；近百万个特色值的传输开销已经难以承受。复用困难：模型预估能力已经成为一个通用的需求，单搜索就有几十个场景都须要该能力；而老逻辑的业务耦合性让复用变得更加困难。平台缺失落：快速的业务迭代下，须要有一个平台可以帮助业务快速地进行模型和特色的管理，包括但不限于配置、上线、灰度、验证等等。
3.2 新框架的边界
跟所有新系统的出身故事一样，老系统一定会涌现问题。原有架构在少特色以及小模型下虽有上风，但业务耦合，无法横向扩展，也难以复用。针对需求和老框架的各类问题，我们开始构建了新的高性能分布式模型预估框架Augur，该框架辅导思路是：
业务解耦，设定框架边界：只做特色抽取和模型预估，对预估结果的处理等业务逻辑交给上层处理。无状态，且可以做到分布式模型预估，无压力支持数千级别文档数的深度模型预估。架构上的改变，让Augur具备了复用的根本能力，同时也拥有了分布式预估的能力。可惜，系统架构设计中没有“银弹”：虽然系统具有了良好的弹性，但为此我们也付出了一些代价，我们会在文末进行阐明。
4. 预估平台的构建过程框架思路只能办理“能用”的问题，平台则是为了“通用”与“好用”。一个精良的预估平台须要担保高性能，具备较为通用且接口丰富的核心预估框架，以及产品级别的业务管理系统。为了能够真正地提升预估能力和业务迭代的效率，平台须要回答以下几个问题：
如何办理特色和模型的高效迭代？如何办理批量预估的性能和资源问题？如何实现能力的快速复用并能够保障业务的安全？下面，我们将逐一给出答案。
4.1 构建预估内核：高效的特色和模型迭代
4.1.1 Operator和Transformer
在搜索场景下，特色抽取较难堪做的缘故原由紧张包括以下几点：
来源多：商户、商品、交易、用户等数十个维度的数据，还有交叉维度。由于美团业务浩瀚，难以通过统一的特色存储去构建，交易干系数据只能通过做事来获取。业务逻辑多：大多数据在不同的业务层会有复用，但是它们对特色的处理逻辑又有所不同。模型差异：同一个特色，在不同的模型下，会有不同的处理逻辑。比如，一个连续型特色的分桶打算逻辑一样，但“桶”却因模型而各不相同；对付离散特色的低频过滤也是如此。迭代快：特色的快速迭代，哀求特色有快速在线上生效的能力，如果想要改动一个判断还须要写代码上线支配，无疑会拖慢了迭代的速率。模型如此，特色也是如此。针对特色的处理逻辑，我们抽象出两个观点：
Operator：通用特色处理逻辑，根据功能的不同又可以分为两类：
IO OP：用途理原始特色的获取，如从KV里获取数据，或者从对应的第三方做事中获取数据。内置批量接口，可以实现批量召回，减少RPC。Calc OP：用于处理对获取到的原始特色做与模型无关的逻辑处理，如拆分、判空、组合。业务可以结合需求实现特色处理逻辑。通过IO、打算分离，特色抽取实行阶段就可以进行IO异步、自动聚合RPC、并行打算的编排优化，从而达到提升性能的目的。
Transformer：用于处理与模型干系的特色逻辑，如分桶、低频过滤等等。一个特色可以配置一个或者多个Transformer。Transformer也供应接口，业务方可以根据自己的需求定制逻辑。
离在线统一逻辑：Transformer是特色处理的模型干系逻辑，因此我们将Transformer逻辑单独抽包，在我们样本生产的过程中利用，担保离线样本生产与线上特色处理逻辑的同等性。基于这两个观点，Augur中特色的处理流程如下所示：首先，我们会进行特色抽取 ，抽取完后，会对特色做一些通用的处理逻辑；而后，我们会根据模型的需求进行二次变换，并将终极值输入到模型预估做事中。如下图所示：
4.1.2 特色打算DSL
有了Operator的观点，为了方便业务方进行高效的特色迭代，Augur设计了一套弱类型、易读的特色表达式措辞，将特色算作一系列OP与其他特色的组合，并基于Bison&JFlex构建了高性能语法和词法解析引擎。我们在阐明实行阶段还做了一系列优化，包括并行打算、中间特色共享、异步IO，以及自动RPC聚合等等。
举个例子：
//IOFeature:binaryBusinessTime;ReadKV是一个IO类型的OPReadKV('mtptpoionlinefeatureexp','_id',_id,'ba_search.platform_poi_business_hour_new.binarybusinesstime','STRING')//FeatureA:CtxDateInfo;ParseJSON是一个Calc类型的OPParseJSON(_ctx['dateInfo']);//FeatureB:isTodayWeekend须要看Json这种的日期是否是周末,便可以复用CtxDateInfo这个特色;IsWeekend也是是一个Calc类型的OPIsWeekend(CtxDateInfo['date'])
在上面的例子中，ParseJSON与IsWeekend都是OP， CtxDateInfo与isTodayWeekend都是由其他特色以及OP组合而成的特色。通过这种办法，业务方根据自己的需求编写OP , 可以快速复用已有的OP和特色，创造自己须要的新特色。而在真实的场景中，IO OP的数量相对固定。以是经由一段韶光的累计，OP的数量会趋于稳定，新特色只需基于已有的OP和特色组合即可实现，非常的高效。
4.1.3 配置化的模型表达
特色可以用利用OP、利用表达式的办法去表现，但特色还可能须要经由Transformer的变换。为此，我们同样为模型构建一套可阐明的JSON表达模板，模型中每一个特色可以通过一个JSON工具进行配置，以一个输入到TF模型里的特色构造为例：
//一个的特色的JSON配置{"tf_input_config":{"otherconfig"},"tf_input_name":"modulestyle","name":"moduleStyle","transforms":[// Transfomers：模型干系的处理逻辑，可以有多个，Augur 会按照顺序实行{"name":"BUCKETIZE", // Transfomer 的名称：这里是分桶"params":{"bins":[0,1,2,3,4]//Transfomer的参数}}],"default_value":-1}
通过以上配置，一个模型可以通过特色名和Transformer的组合清晰地表达。因此，模型与特色都只是一段纯文本配置，可以保存在外部，Augur在须要的时候可以动态的加载，进而实现模型和特色的上线配置化，无需编写代码进行上线，安全且高效。
个中，我们将输入模型的特色名（tf_input_name）和原始特色名（name）做了区分。这样的话，就可以只在外部编写一次表达式，注册一个公用特色，却能通过在模型的构造体中配置不同Transfomer创造出多个不同的模型预估特色。这种做法相对节约资源，由于公用特色只需抽取打算一次即可。
此外，这一套配置文件也是离线样本生产时利用的特色配置文件，结合统一的OP&Transformer代码逻辑，进一步担保了离线/在线处理的同等性，也简化了上线的过程。由于只须要在离线状态下配置一次样本天生文件，即可在离线样本生产、在线模型预估两个场景通用。
4.2 完善预估系统：性能、接口与周边举动步伐
4.2.1 高效的模型预估过程
OP和Transformer构建了框架处理特色的基本能力。实际开拓中，为了实现高性能的预估能力，我们采取了分片纯异步的线程构造，层层Call Back，最大程度将线程资源留给实际打算。因此，预估做事对机器的哀求并不高。
为了描述清楚全体过程，这里须要明确特色的两种类型：
ContextLevel Feature：全局维度特色，一次模型预估要求中，此类特色是通用的。比如韶光、地理位置、间隔、用户信息等等。这些信息只需打算一次。DocLevel Feature：文档维度特色，一次模型预估要求中每个文档的特色不同，须要分别打算。一个范例的模型预估要求，如下图所示：
Augur启动时会加载所有特色的表达式和模型，一个模型预估要求ModelScoreRequest会带来对应的模型名、要打分的文档id（docid）以及一些必要的全局信息Context。Augur在要求命中模型之后，将模型所用特色构建成一颗树，并区分ContextLevel特色和DocLevel特色。由于DocLevel特色会依赖ContextLevel特色，故先将ContextLevel特色打算完毕。
对付Doc维度，由于对每一个Doc都要加载和打算对应的特色，以是在Doc加载阶段会对Doc列表进行分片，并发完成特色的加载，并且各分片在完成特色加载之后就进行打分阶段。也便是说，打分阶段本身也是分片并发进行的，各分片在末了打分完成后汇总数据，返回给调用方。期间还会通过异步接口将特色日志上报，方便算法同学进一步迭代。
在这个过程中，为了使全体流程异步非壅塞，我们哀求引用的做事供应异步接口。若部分做事未供应异步接口，可以将其包装成伪异步。这一套异步流程使得单机（16c16g）的做事容量提升超过100%，提高了资源的利用率。
4.2.2 预估的性能及表达式的开销
框架的上风：得益于分布式，纯异步流程，以及在特色OP内部做的各种优化（公用特色 、RPC聚合等），从老框架迁移到Augur后，上千份文档的深度模型预估性能提升了一倍。
至于大家关心的表达式解析对对付性能的影响实在可以忽略。由于这个模型预估的耗时瓶颈紧张在于原始特色的抽取性能（也便是特色存储的性能）以及预估做事的性能（也便是Serving的性能）。而 Augur 供应了表达式解析的Benchmark测试用例，可以进行解析性能的验证。
_I(_I('xxx'))BenchmarkModeCntScoreErrorUnitsAbsBenchmarkTest.testavgt251.644±0.009ms/op
一个两层嵌套的表达式解析10W次的性能是1.6ms旁边。比较于全体预估的韶光，以及措辞化表达式对付特色迭代效率的提升，这一耗时在当前业务场景下，基本可以忽略不计。
4.2.3 系统的其他组成部分
一个完善可靠的预估系统，除了“看得见”的高性能预估能力，还须要做好以下几个常被忽略的点：
特色日志处理流程：预估时产出的特色日志，须要通过框架上传到公司日志中央或者以用户希望的办法进行存储，方便模型的迭代。当然，必要的时候可以落入本地，方便问题的定位。监控，系统&特色：系统监控不用多说，美团内部的Cat&天网，可以构建出完善的监控体系。另一方面，特色的监控也很主要，由于特色获取的稳定性决定了模型预估的质量，以是我们构建了实时的特色分布监控系统，可以分钟级创造特色分布的非常，最大限度上担保模型预估的可靠性。丰富的接口：除了预估接口，还须要有特色抽取接口、模型打分Debug 接口、特色表达式测试接口、模型单独测试接口、特色模型刷新接口、特色依赖检等等一系列接口，这样才可以担保全体系统的可用性，并为后面管理平台的培植打下根本。Augur在完成了以上多种能力的培植之后，就可以当做一个功能相对完善且易扩展的在线预估系统。由于我们在构建 Augur的时候，设立了明确的边界，故以上能力是独立于业务的，可以方便地进行复用。当然，Augur的功能管理，更多的业务接入，都须要管理平台的承载。于是，我们就构建了Poker平台，个中的在线预估管理模块是做事于Augur，可以进行模型特色以及业务配置的高效管理。我们将不才一小节进行先容。
4.3 培植预估平台：快速复用与高效管理
4.3.1 能力的快速复用
Augur在设计之初，就将所有业务逻辑通过OP和Transformer承载，以是跟业务无关。考虑到美团搜索与NLP部模型预估场景需求的多样性，我们还为Augur授予多种业务调用的办法。
Java做事化调用：即基于Augur构建一个完全的Service，可以实现无状态分布式的弹性预估能力。Thrift调用：Java做事化版本中内置了对Thrift 的支持，使不同措辞的业务都可以方便地拥有模型预估能力。双框架：Augur支持同一个做事同时供应Pigeon（美团内部的RPC框架）以及Thrift 做事，从而知足不同业务的不同需求。Java SDK：Augur同样支持以SDK的办法将能力嵌入到已有的集群当中。但如此一来，分布式能力就无法发挥了。以是，我们一样平常运用在性能哀求高、模型比较小、特色基本可以存在本地的场景下。
个中做事化是被运用最多的办法，为了方便业务方的利用，除了完善的文档外，我们还构建了标准的做事模板，任何一个业务方基本上都可以在30分钟内构建出自己的Augur做事。做事模板内置了60多个常用逻辑和打算OP , 并供应了最佳实践文档与配置逻辑，使得业务方在没有辅导的情形下可以自行办理95%以上的问题。全体流程如下图所示：
当然，无论利用哪一种办法去构建预估做事，都可以在美团内部的Poker平台上进行做事、模型与特色的管理。
4.3.2 Augur管理平台Poker的构建
实现一个框架代价的最大化，须要一个完全的体系去支撑。而一个合格的在线预估平台，须要一个产品级别的管理平台赞助。于是我们构建了Poker（搜索实验平台），个中的在线预估做事管理模块，也是Augur的最佳拍档。Augur是一个可用性较高的在线预估框架，而Poker+Augur则构成了一个好用的在线预估平台。下图是在线预估做事管理平台的功能架构：
首先是预估核心特色的管理，上面说到我们构建了措辞化的特色表达式，这实在是个较为常见的思路。Poker利用Augur供应的丰富接口，结合算法的利用习气，构建了一套较为流畅的特色管理工具。可以在平台上完成新增、测试、上线、卸载、历史回滚等一系列操作。同时，还可以查询特色被做事中的哪些模型直接或者间接引用，在修正和操作时还有风险提示，兼顾了便捷性与安全性。
模型管理也是一样，我们在平台上实现了模型的配置化上线、卸载、上线前的验证、灰度、独立的打分测试、Debug信息的返回等等。同时支持在平台上直接修正模型配置文件，平台可以实现模型多版本掌握，一键回滚等。配置皆为实时生效，避免了手动上线碰着问题后因处理韶光过长而导致丢失的情形。
4.3.3 Poker + Augur的运用与效果
随着Augur和Poker的成熟，美团搜索与NLP部门内部已经有超过30个业务方已经全面接入了预估平台，整体的概况如下图所示：
预估框架利用迁移Augur后，性能和模型预估稳定性上均得到了较大幅度的提升。更加主要的是，Poker平台的在线预估做事管理和Augur预估框架，还将算法同学从繁复且危险的上线操作中解放出来，更加专注于算法迭代，从而取得更好的效果。以点评搜索为例，在Poker+Augur稳定上线之后，经由短短半年的韶光，点评搜索核心KPI在高位根本上仍旧实现了大幅提升，是过去一年半涨幅的六倍之多，提前半年完玉成年的目标。
4.4 进阶预估操作：模型也是特色
4.4.1 Model as a Feature，同构or异构？
在算法的迭代中，有时会将一个模型的预估的结果当做其余一个模型输入特色，进而取得更好的效果。如美团搜索与NLP中央的算法同学利用BERT来办理长尾要求商户的展示顺序问题，此时须要BERT as a Feature。一样平常的做法是离线进行BERT批量打算，注意灌输特色存储供线上利用。但这种办法存在时效性较低（T+1）、覆盖度差等缺陷。最好的办法自然是可以在线实时去做BERT模型预估，并将预估输出值作为特色，用于终极的模型打分。这就须要Augur供应Model as a Feature的能力。
得益于Augur抽象的流程框架，我们很快逾额完成了任务。Model as a feature，虽然要对一个Model做预估操作，但从更上层的模型角度看，它便是一个特色。既然是特色，模型预估也便是一个打算OP而已。以是我们只须要在内部实现一个分外的OP，ModelFeatureOpreator就可以干净地办理这些问题了。
我们在充分调研后，创造Model as a Feature有两个维度的需求：同构的特色和异构的特色。同构指的是这个模型特色与模型的其他特色一样，是与要预估的文档统一维度的特色，那这个模型就可以配置在同一个做事下，也便是本机可以加载这个Stacking模型；而异构指的是Model Feature与当前预估的文档不是统一维度的，比如商户下挂的商品，商户打分须要用到商品打分的结果，这两个模型非统一维度，属于两个业务。正常逻辑下须要串行处理，但是Augur可以做得更高效。为此我们设计了两个OP来办理问题：
LocalModelFeature：办理同构Model Feature的需求，用户只需像配置普通特色表达式一样即可实现在线的Model Stacking；当然，内部自然有优化逻辑，比如外部模型和特色模型所需的特色做统一整合，尽可能的减少资源花费，提升性能。该特色所配置的模型特色，将在本机实行，以减少RPC。RemoteModelFeature：办理异构Model Feature的需求，用户还是只需配置一个表达式，但是此表达式会去调用相应维度的Augur做事，获取相应的模型和特色数据供主维度的Augur做事处理。虽然多了一层 RPC，但是相对付纯线性的处理流程，分片异步后，还是有不少的性能提升。美团搜索内部，已经通过LocalModelFeature的办法，实现了BERT as a Feature。在险些没有新的利用学习本钱的条件下，同时在线上取得了明显的指标提升。
4.4.2 Online Model Ensemble
Augur支持有单独抽取特色的接口，结合Model as a Feature，若须要同时为一个文档进行两个或者多个模型的打分，再将分数做加权后利用，非常方便地实现离线Ensemble出来模型的实时在线预估。我们可以配置一个大略的LR、Empty 类型模型（仅用于特色抽取），或者其他任何Augur支持的模型，再通过LocalModelFeature配置多少的Model Feature，就可以通过特色抽取接口得到一个文档多个模型的线性加权分数了。而这统统都被包含在一个统一的抽象逻辑中，利用户的体验是连续统一的，险些没有增加学习本钱。
除了上面的操作外，Augur还供应了打分的同时带回部分特色的接口，供后续的业务规则处理利用。
5. 更多思考当然，肯定没有完美的框架和平台。Augur和Poker还有很大的进步空间，也有一些不可回避的问题。紧张包括以下几个方面。
被迫“消逝”的Listwise特色
前面说到，系统架构设计中没有“银弹”。在采取了无状态分布式的设计后，要求会分片。以是ListWise类型的特色就必须在打分前算好，再通过接口传递给Augur利用。在权衡性能和效果之后，算法同学放弃了这一类型的特色。
当然，不是说Augur不能实现，只是本钱有些高，以是暂时Hold 。我们也有设计过方案，在可量化的收益高于本钱的时候，我们会在Augur中开放协作的接口。
单机多层打分的缺失落
Augur一次可以进行多个模型的打分，模型相互依赖（下一层模型用到上一层模型的结果）也可以通过Stacking技能来办理。但如果模型相互依赖又逐层减少预估文档（比如，第一轮预估1000个，第二轮预估500），则只能通过多次RPC的办法去办理问题，这是一个现实问题的权衡。分片打分的性能提升，能否Cover多次RPC的开销？在实际开拓中，为了保持框架的清晰大略，我们选择了放弃多层打分的特性。
离线能力缺失落？
Poker是搜索实验平台的名字。我们设计它的初衷，是办理搜索模型实验中，从离线到在线所有繁复的手工操作，使搜索拥有一键演习、一键Fork、一键上线的能力。与公司其他的演习平台不同，我们通过完善的在线预估框架倒推离线演习的需求，进而构建了与在线无缝结合的搜索实验平台，极大地提升了算法同学的事情效。
未来，我们也会向大家先容产品级别的一站式搜索实验平台，敬请期待。
6. 未来展望在统一了搜索的在线预估框架后，我们会进一步对Augur的性能&能力进行扩展。未来，我们将会在检索粗排以及性能哀求更高的预估场景中去发挥它的能力与代价。同时 ，我们正在将在线预估框架进一步领悟到我们的搜索实验平台Poker中，与离线演习和AB实验平台做了深度的打通，为业务构建高效完全的模型实验根本举动步伐。
如果你想近间隔感想熏染一下Augur的魅力，欢迎关注文末的招聘信息，加入美团技能团队！
朱敏，紫顺，乐钦，洪晨，乔宇，武进，孝峰，俊浩等，均来自美团搜索与NLP部。
---------- END ----------
招聘信息
美团搜索工程团队，致力于打造通用高性能的全链路搜索智能系统，长期招聘搜索引擎工程师/技能专家，坐标上海及北京。欢迎感兴趣的同学发送简历至：tech@meituan.com（邮件标题注明：搜索与NLP部）
