在过来十年，机器学习在学术界获得了泛滥的冲破，在工业界也有很多利用落地。美团很早就开始摸索不同的机器学习模型在搜寻场景下的利用，从最开始的线性模型、树模型，再到近两年的深度神经网络、BERT、DQN 等，并在实践中也获得了良好的成果与产出。
在美团搜寻 AI 化的过程中，比拟外围的两个组件是模型训练平台 Poker 和在线预估框架 Augur。本文次要与大家探讨 Augur 的设计思路、成果，以及它的劣势与有余，最初也简略介绍了一下 Poker 平台的价值。心愿这些内容对大家有所帮忙或者启发。
1. 背景
搜寻优化问题，是个典型的 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 聚合等等。
举个例子：
// IO Feature: binaryBusinessTime; ReadKV 是一个 IO 类型的 OP
ReadKV('mtptpoionlinefeatureexp','_id',_id,'ba_search.platform_poi_business_hour_new.binarybusinesstime','STRING')
// FeatureA : CtxDateInfo; ParseJSON 是一个 Calc 类型的 OP
ParseJSON(_ctx['dateInfo']);
// FeatureB : isTodayWeekend 须要看 Json 这种的日期是否是周末, 便能够复用 CtxDateInfo 这个特色; IsWeekend 也是是一个 Calc 类型的 OP
IsWeekend(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'))
Benchmark Mode Cnt Score Error Units
AbsBenchmarkTest.test avgt 25 1.644 ± 0.009 ms/op一个两层嵌套的表达式解析 10W 次的性能是 1.6ms 左右。相比于整个预估的工夫，以及语言化表达式对于特色迭代效率的晋升，这一耗时在以后业务场景下，根本能够忽略不计。
4.2.3 零碎的其余组成部分
一个欠缺牢靠的预估零碎，除了“看得见”的高性能预估能力，还须要做好以下几个常被疏忽的点：
- 几个常被疏忽的点 ：预估时产出的特色日志，须要通过框架上传到公司日志核心或者以用户心愿的形式进行存储，不便模型的迭代。当然，必要的时候能够落入本地，不便问题的定位。
- ，不便问题的定位 ：系统监控不必多说，美团外部的 Cat& 天网，能够构建出欠缺的监控体系。另一方面，特色的监控也很重要，因为特色获取的稳定性决定了模型预估的品质，所以咱们构建了实时的特色散布监控零碎，能够分钟级发现特色散布的异样，最大限度上保障模型预估的可靠性。
- 丰盛的接口 ：除了预估接口，还须要有特色抽取接口、模型打分 Debug 接口、特色表达式测试接口、模型独自测试接口、特色模型刷新接口、特色依赖检等等一系列接口，这样才能够保障整个零碎的可用性，并为前面治理平台的建设打下基础。
Augur 在实现了以上多种能力的建设之后，就能够当做一个性能绝对欠缺且易扩大的在线预估零碎。因为咱们在构建 Augur 的时候，设立了明确的边界，故以上能力是独立于业务的，能够不便地进行复用。当然，Augur 的性能治理，更多的业务接入，都须要治理平台的承载。于是，咱们就构建了 Poker 平台，其中的在线预估治理模块是服务于 Augur，能够进行模型特色以及业务配置的高效治理。咱们将在下一大节进行介绍。
4.3 建设预估平台：疾速复用与高效治理
4.3.1 能力的疾速复用
Augur 在设计之初，就将所有业务逻辑通过 OP 和 Transformer 承载，所以跟业务无关。思考到美团搜寻与 NLP 部模型预估场景需要的多样性，咱们还为 Augur 赋予多种业务调用的形式。
- 种业务调用的形式。：即基于 Augur 构建一个残缺的 Service，能够实现无状态分布式的弹性预估能力。
- 布式的弹性预估能 ：Java 服务化版本中内置了对 Thrift 的反对，使不同语言的业务都能够不便地领有模型预估能力。
- 地领有 ：Augur 反对同一个服务同时提供 Pigeon（美团外部的 RPC 框架）以及 Thrift 服务，从而满足不同业务的不同需要。
- 不同业务的不同需 ：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 的魅力，欢送退出美团技术团队！
7. 作者简介
朱敏，紫顺，乐钦，洪晨，乔宇，武进，孝峰，俊浩等，均来自美团搜寻与 NLP 部。
浏览更多技术文章，请扫码关注微信公众号 - 美团技术团队！