SPQA：基于AI的架构

Posted 2023-04-30 BOTAI

人工智能将在未来几个月和几年内做很多有趣的事情，这要归功于GPT之后的爆炸。但最重要的变化之一是更换我们现有的软件。

我们曾经使我们的业务适应软件的局限性。在这个模型中，软件将适应我们开展业务的方式。

基于人工智能的应用程序将与我们今天拥有的应用程序完全不同。新架构将是一个更加优雅的基于GPT的四组件结构：状态，政策，问题和行动。

从根本上说，这是从基于电路的架构到基于理解的架构的过渡。

我们当前的软件是基于电路的，这意味着应用程序具有显式和刚性结构，例如电路板中的蚀刻。输入和输出必须显式创建、路由和维护。任何偏离该结构都会导致错误，添加新功能需要组织开发人员的线性努力。

电路不是完美的隐喻，但它具有足够的描述性。

新软件将基于理解。这些应用程序将具有几乎无限的输入，因为它们基于发送到真正理解您所问内容的系统的自然语言。添加新功能就像提出不同的问题和/或给出不同的命令一样简单。

SPQA 架构

（录制尖叫声）

“不！GPT没有真正的理解......”

⏱️ 从现在开始 60 秒...

有很多人不认为 GPT 正在做的事情是真正的“理解”，但我认为我可以在不到 60 秒的时间内说服大多数坚持者。准备？走。

首先，让我们定义术语。

情报就像是“收集、分析和共享敌人的信息，以实现卓越的决策。

• 数据：没有上下文的原始事实或数字
• 信息：已处理、组织或结构化的数据
• 知识：组合成有用的信息
• 理解：在新情况和背景下应用知识的能力

或以压缩形式：

• 数据是原始的
• 信息有条理
• 知识是有用的
• 应用理解

所以我们使用的定义是：

在新情况和背景下应用知识的能力。

那么，GPT 可以做到这一点吗？让我们用一个例子来回应。让我们看看他们是否足够理解星球大战和禁忌之爱和莎士比亚等概念，从而写出以下诗？

写一首从卢克到莱娅的情诗。

我要求它这样做，这是它写的......

哦，莱娅，所有少女中最公平的，
你的美丽使我的灵魂陷入困境。
你闪亮的眼睛，像点亮黑夜的星星，
用爱的甜蜜、闪亮的光芒填满我的心。

你温柔的触感，像羽毛一样贴在我的皮肤上，让我的心跳舞，
跳跃。
你的声音，就像我热切的耳朵里的音乐，多斯抚慰我的灵魂，
平息我最深的恐惧。

虽然我们的爱可能是被禁止的，但确实，
我情不自禁地把我的心交给你。

为了你，我所渴望的一切，我的莱娅，你点燃了我的心。

所以，让我们偷偷地进入黑夜，
让我们的爱展翅高飞。
因为在你怀里，我知道我会找到平安，
世界上所有的麻烦必定会停止。

渴望的GPT

自己尝试一下，并在组合中添加新的上下文/情况。

这是一首莎士比亚的诗，关于《星球大战》宇宙中两个兄弟姐妹之间的禁忌之爱。它适用于我刚刚编造的全新情况/背景。

尴尬

请注意，我什至没有在提示中提到星球大战或禁忌之爱！它理解“卢克和莱娅”和“爱”的含义，并推断这是被禁止的，因为它知道兄弟姐妹不应该对彼此有这种感觉。

关于 GPT 以及它们是否“理解”事物的许多困惑来自将理解与体验混淆。

理解出乎意料地从系统中消失了。

GPT 懂事吗？是的。这项技术的魔力在于，GPT基本上必须意外地深入学习概念，这样他们才能正确预测序列中的下一个字母。然后，它可以在新情况下应用这些概念。

但是 GPT 知道爱是什么感觉吗？还是去思考宇宙？还是人类的死亡？不。他们一点头绪都没有。他们没有感情。他们没有意识。他们没有一点点经历。

如果你认为你必须感觉才能理解，那么你就是在说理解需要意识，这比卢克和莱娅跳起来的鸿沟更大。

但请记住，我们并不是要求 GPT 体验事物。我们不是在问他们是否感觉到了。问题是他们是否可以使用新信息从概念中概括出来，即将知识应用于新的情况和背景。

这就是理解。是的，他们做得非常好。

⏱️ 计时器停止。希望我已经说服了你。

理解的软件

很难摸清我们的传统软件和理解软件之间的差异范围。

国家和政策都将是基于模型的

我说“类似”是因为确切的获胜实施将基于市场且不可预测。

与其试图摸索解释，不如让我们举个例子，想想今天和不久的将来如何使用 SPQA 架构来完成它。

今天的安全计划

假设我们有一家名为Splice的生物技术公司，总部位于加利福尼亚州圣布鲁诺。他们拥有 12，500 名员工，并且正在获得全新的 CISO。她要求团队立即开始构建以下内容：

• 从业务和风险的角度给我一个最关键应用程序的列表
• 创建我们对他们的主要威胁的优先级列表，并将其与我们的安全团队花费的时间和金钱相关联
• 就如何调整预算、员工人数、OKR 和项目列表提出建议，以正确适应我们的实际威胁
• 让我们使用这种新方法编写一个调整后的安全策略
• 定义我们将跟踪的前 5 个 KPI，以显示实现目标的进度
• 根据我们的组织结构，构建从该策略流出的嵌套 OKR 结构
• 为开发板创建描述新方法的更新演示文稿
• 根据我们所属的法规，从合规性的角度创建我们缺乏的方式列表
• 然后制定一个完整的实施计划，在未来四个季度之前分解
• 最后，编写我们的第一份季度安全报告，并保持文档更新

需要多少人才能将其放在一起？什么资历的人？需要多长时间？

如果你在安全部门工作了很长时间，你就会知道这很容易就是几个月的工作，只是为了第一个版本。会议、讨论和维护所有这些也需要数百小时。

见鬼，有许多安全组织花了数年时间研究这些东西，但仍然没有令人满意的版本。

因此，花费数月的时间来创建它，然后使用安全组织中数十名最优秀的人员来维护它，他们花费了大量时间。

使用 SPQA 的安全程序

让我们看看它在新模型中是什么样子的。

在实际实现中，POLICY可能会成为STATE的一部分，但需要更小的模型来允许更频繁的更改。

1. 选择基本模型 — 您从 OpenAI、Google、Meta、麦肯锡或其他公司的最新、最棒的整体 GPT 模型开始。很多公司都会有一个。让我们称之为OpenAI的GPT-6。它已经非常了解安全性、生物技术、项目管理、日程安排、会议、预算、事件响应和审计准备，因此您可以独自生存。但您需要更个性化的上下文。
2. 训练您的自定义模型 — 然后，您可以根据您自己的数据训练您的自定义模型，这些数据将堆叠在 GPT-6 之上。这是上一节中的所有内容。这是公司的遥测和上下文。原木。文档。财政。聊天。电子邮件。会议记录。万事。这是一家小公司，压缩算法作为我们使用的自定义模型生成 （CMG） 产品的一部分，因此总共有 312TB 的数据。您可以在此基础上训练自定义模型。STATE
3. 训练您的策略模型 — 现在，您训练另一个完全与公司愿望相关的模型。使命，目标，你的反目标，你的挑战，你的策略。这是来自人类的指导，我们用它来指导架构的一部分。当我们要求它为我们制作东西并制定我们的计划时，它会使用此处捕获的护栏来执行此操作。ACTIONPOLICY
4. 告诉系统执行以下操作 — 现在模型已合并。我们有 GPT-6，与我们的模型堆叠在一起，也与我们的模型堆叠在一起，他们一起比我们自己更了解我们。STATEPOLICY

所以现在我们给它我们从CISO那里得到的完全相同的工作清单。

• 从业务和风险的角度给我一个最关键应用程序的列表
• 创建我们对他们的主要威胁的优先级列表，并将其与我们的安全团队花费的时间和金钱相关联
• 就如何调整预算、员工人数、OKR 和项目列表提出建议，以正确适应我们的实际威胁
• 让我们使用这种新方法编写一个调整后的安全策略
• 定义我们将跟踪的前 5 个 KPI，以显示实现目标的进度
• 根据我们的组织结构，构建从该策略流出的嵌套 OKR 结构
• 为开发板创建描述新方法的更新演示文稿
• 根据我们所属的法规，从合规性的角度创建我们缺乏的方式列表
• 然后制定一个完整的实施计划，在未来四个季度之前分解
• 最后，编写我们的第一份季度安全报告，并保持文档更新

在可预见的未来，我们仍然需要仔细检查模型的输出，因为在游戏早期，幻觉是真实存在的。

假设我们新的组合SPQA系统称为Prima。问自己两个问题。

1. 考虑到它对公司的所有了解，创建所有这些的第一个版本需要多长时间？
2. 每周、每月、每季度或每年创建更新版本需要多少时间？

答案是分钟。不仅适用于初始创建，也适用于未来的所有更新。

它唯一需要的是1）使用最新数据的最新模型，以及2）来自组织中人类领导者的正确问题。在这种情况下，我们已经在上面的列表中提出了这些问题。

请记住，Prima不仅会提出方向，还会创建所有工件。每个文档。每个OKR。QSR本身。战略文件。董事会演示文稿的大纲。审核员编制文件。甚至是给利益相关者的电子邮件。这是额外的数百小时工作，而这些工作本来可以由整个组织中更多的初级团队成员完成。

所以——我们谈论的是每季度数千小时的工作——分散在几十个人身上——到其中的1%到5%。在新模型中，工作将转向确保是最新的，并且我们要求是正确的。POLICYQUESTIONS

软件垂直行业的转型

坚持安全性，因为这是我最了解的，想象一下SPQA将对整个产品空间做什么。静态分析怎么样？

SPQA 中的静态分析

在静态分析中，您实际上是在接受输入并询问两件事：

1. 怎么了？
2. 我们如何解决它？

SPQA将粉碎所有这样做的现有软件，因为它是基于理解的。因此，一旦它通过你的问题充分了解问题，并且它理解你试图通过你的，它将能够做的不仅仅是发现代码问题和修复。它将能够执行以下操作：STATEPOLICY

1. 查找问题
2. 展示如何用任何语言（编码或人类）修复它
3. 编写一个关于避免这些错误的即时教程
4. 在工具的技术中编写一个规则来检测它
5. 给你固定代码
6. 确认代码有效

另外，你还可以做一些更疯狂的事情，比如创建多个版本的代码，看看它们如何应对最常见的攻击，然后根据这些结果提出建议。

一般安全软件

现在，让我们缩小到一般的安全软件，并对一些最受欢迎的产品进行一些快速点击。

检测和响应

• 谁是这里真正的攻击者？
• 谁在等待激活？
• 查找我们组织中最新的 TTP
• 在我们的检测软件中编写规则以找到它们
• 与我们的同行分享这些规则
• 拉出他们的规则并检查这些规则
• 创建一个虚假的并行基础结构，该基础结构看起来与我们完全相同，但旨在使用以下条件捕获攻击者
• 自动禁用帐户、发送通知、重置令牌等。当您看到成功的攻击时
• 注意可疑的链接事件，例如未知电话呼叫，然后是远程会话，然后是文档审查。

基本上，当你站起来时，你们中的大多数人都必须手动构建D&R功能，因为你已经准备好了SPQA。

它天生就明白什么是可疑的。没有更明确的编码规则。现在，您只需向“策略”模型添加指导。

攻击面管理和赏金

• 提取有关公司的所有数据
• 查找其所有合并和隶属关系
• 查找与这些内容相关的所有文档
• 列出所有域
• 持续运行工具以查找所有子域
• 开放端口
• 端口上的应用程序
• 使用自动化不断浏览这些网站
• 将数据发送到 SPQA 模型以查找最脆弱的点
• 针对这些点运行自动化
• 自动向赏金计划提交包含 POC 代码的高质量报告
• （如果你是青蛙）向security@提交相同的报告，看看他们是否仍会向您付款
• 不断发现我们的新表面
• 持续监控/扫描并转储到数据湖（S3 存储桶或等效数据）
• 不断重新运行模型STATE
• 连接到警报系统和报告创建工具
• 让系统自我优化

企业安全

• 监控可疑操作和参与者的所有活动
• 自动检测、阻止并通知这些操作
• 确保 SaaS 安全性与企业安全策略完全同步（请参阅POLICY)

供应商和供应链安全

供应商和供应链安全将成为SPQA最激烈和最强大的中断之一，只是因为目前这个问题是多么不可能。

• 列出我们拥有的所有供应商
• 使用我们收到的每份问卷
• 查找供应商的软件在我们的基础架构中涉及的每个位置
• 在这些位置查找易受攻击的组件
• 列出我们公司各个方面的最高风险的优先清单
• 建议缓解措施以降低风险，盯着最严重的风险
• 创建具有类似功能但不具有这些风险的替代供应商列表
• 创建前 3 个选项的迁移计划

今天，在任何大型组织中，上述目标几乎是不可能的。基于 SQPA 的应用程序将在几分钟内将其吐出。整件事。每次模型更新时都一样。

我们谈论的是完全不可能...到分钟。

即将推出的内容

请记住，整个事情就像 4 个月前一样弹出，所以这仍然是第 0 天。

这些只是网络安全的几个例子。但这基本上从一个月前开始适用于所有软件。目前的主要限制是：

1. 创建大型自定义模型所需的大小限制和软件
2. 为拥有大量数据的大型组织运行更新的速度和成本限制

第一个已经使用诸如LangChain，但我们很快就会为此提供超级流畅的实现。您基本上可以在所有软件中提供导出选项，以发送导出或流式传输该工具的所有内容。那是Splunk，Slack，GApps，O365，Salesforce，你所有的安全软件，所有的人力资源软件。万事。

它们都将具有近乎实时的连接器，发送到您选择的 SPQA 产品的型号。STATE

我们可能会看到“状态”和“策略”分解为多个子模型，其中包含最基本和最及时的数据，以便它们可以尽可能快速和廉价地更新。

对于#2，这需要时间。OpenAI已经在降低这项技术的价格方面做了一些真正的魔术，但是在数百TB的数据上训练自定义模型仍然是昂贵和耗时的。下降多少和多快是未知的。

如何准备

以下是我向当今创建软件的人推荐的内容。

开始思考您企业的首要原则。非常认真地问问自己你提供什么，它与竞争对手的产品有什么不同，以及当你的公司成为一组客户不直接访问的 API 时会是什么样子。是你的界面让你与众不同吗？您的数据？您的见解？当您的所有竞争对手都拥有同样强大的人工智能时，这些情况会如何变化？

开始考虑您企业的护城河。当这一切完全实现时，在接下来的 1-5 年内，问问自己，使用自己的自定义模型堆叠在庞大的 LLM 之上，与像麦肯锡这样的人带着 The SolutionTM 走进来有什么区别。现在是 2026 年，他们告诉您的客户，他们可以通过使用您的州和政策在 3-12 个月内简单地实施您的业务。只有他们有一些秘密的麦肯锡酱可以添加，因为他们见过这么多顾客。每个人最终都会运行三个通用 SPA 框架之一吗？

注意创新者的困境。仅仅因为这是不可避免的并不意味着你可以放弃一切并转向。问题是，根据您当前的业务、垂直、成熟度、财务状况等，您将如何转型？你要慢慢地、原地做吗？或者您是否建立一个单独的部门，重新开始，但从您的传统运营中获取资源？或者也许是某种混合体。对于每个公司来说，这即将成为一个非常重要的决定。

专注于问题。当给出出色的答案变得容易时，最重要的是提出正确问题的能力。这种新架构将非常强大，但您仍然需要定义公司正在尝试做什么。我们为什么存在？我们的目标是什么？甚至比您的状态更重要的是，您的政策内容将成为您业务中最独特和最识别的部分。这是你的目的，你不会容忍的，以及你对成功的定义。

我目前的模式是分析乐观主义。我对即将发生的事情感到兴奋，但忍不住担心它的发展速度有多快。

再见。

本文来自博客园，作者微信：165501809，转载请注明原文链接：https://www.cnblogs.com/botai/p/SPQA-AI-architecture.html

美团基于AI的搜索引擎架构建设与实践

点击“技术领导力”关注∆  每天早上8:30推送

在过去十年，机器学习在学术界取得了众多的突破，在工业界也有很多应用落地。美团很早就开始探索不同的机器学习模型在搜索场景下的应用，从最开始的线性模型、树模型，再到近两年的深度神经网络、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服务（参见《》一文）以及自研的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，最大程度将线程资源留给实际计算。因此，预估服务对机器的要求并不高。

为了描述清楚整个过程，这里需要明确特征的两种类型：

1. ContextLevel Feature：全局维度特征，一次模型预估请求中，此类特征是通用的。比如时间、地理位置、距离、用户信息等等。这些信息只需计算一次。

2. 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赋予多种业务调用的方式。

• 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的魅力，欢迎关注文末的招聘信息，加入美团技术团队！

7. 作者简介

朱敏，紫顺，乐钦，洪晨，乔宇，武进，孝峰，俊浩等，均来自美团搜索与NLP部。

 -END- 

加入读者群，跟100位CTO学习交流？

---

席位珍贵，至于老K加不加你，随缘吧！

（如遇繁忙，请手动添加：laokei2020）

---

大家在看：

1.

2.

3.

4.

5

6.

7.

8.