意义：培养自己的阅读能力，学习更多的知识
一个网站搜索引擎其面临的数据量是PB级别的，其背后的技术架构也很是值得学习的。核心的目标在于如何给用户呈现最符合用户预期的内容，关键要克服的问题个人认为包含以下几项：
这篇文章让我学习到一个搜索引擎内部到底是怎么运作的？索引如何建立？检索策略？收益颇深！
一个用户请求过来之后，整个搜索引擎的工作流程大致如下：
首先用切词组件做分词，把 query 分成多个 word，然后多个 word 会从我们的倒排索引里面获取倒排拉链，在倒排拉链的基础上，会做求交计算来拿到所有命中的 doc list。拿到 doc list 之后，我们希望能够把优质的网页反馈给用户，这时候我们还需要做 rank 计算。rank 计算就是拿倒排里面的一些位置索引信息，包括在正排里面拿一些 rank 的属性特征信息做打分，最终会把分数比较高的 Top N 结果反馈用户。当然在前端 web 页面展示的时候，需要从正排中提取摘要信息，展示给用户。这就是整个的检索过程。
网站内容：
【query分析】
【查询策略】
搜索架构中最重要的两个核心模块为：
【正排索引】
独立更新的问题：更新频率高
设计思路：
【倒排索引】
两个问题：
设计思路：
【基础赋权】
基础赋权是来解决 query 中的每一个 term 和它对应的文章的权重计算。
【紧密度计算】
紧密度计算就是用户的 query 过来之后，针对 query 的分词，一是相邻 word 之间的紧密程度在文章中是怎样的分布；二是跨 term 的信息，那也就是方向的信息。
通过计算文章中query中相邻word之间的距离来确定方向性。例如上图中取B为中心点，第二个A是在B后面，则A和B的距离就会拉长
想设计亿万级高并发架构，你要先知道高并发是什么？
面对流量高峰，不同的企业是如何通过技术手段解决高并发难题的呢?
0、引言
软件系统有三个追求：高性能、高并发、高可用，俗称三高。三者既有区别也有联系，门门道道很多，全面讨论需要三天三夜，本篇讨论高并发。
高并发（High Concurrency）。并发是 *** 作系统领域的一个概念，指的是一段时间内多任务流交替执行的现象，后来这个概念被泛化，高并发用来指大流量、高请求的业务情景，比如春运抢票，电商双十一，秒杀大促等场景。
很多程序员每天忙着搬砖，平时接触不到高并发，哪天受不了跑去面试，还常常会被面试官犀利的高并发问题直接KO，其实吧，高并发系统也不高深，我保证任何一个智商在线的看过这篇文章后，都能战胜恐惧，重拾生活的信心。
本文先介绍高并发系统的度量指标，然后讲述高并发系统的设计思路，再梳理高并发的关键技术，最后结合作者的经验做一些延伸探讨。
1、高并发的度量指标
既然是高并发系统，那并发一定要高，不然就名不副实。并发的指标一般有QPS、TPS、IOPS，这几个指标都是可归为系统吞吐率，QPS越高系统能hold住的请求数越多，但光关注这几个指标不够，我们还需要关注RT，即响应时间，也就是从发出request到收到response的时延，这个指标跟吞吐往往是此消彼长的，我们追求的是一定时延下的高吞吐。
比如有100万次请求，99万次请求都在10毫秒内响应，其他次数10秒才响应，平均时延不高，但时延高的用户受不了，所以，就有了TP90/TP99指标，这个指标不是求平均，而是把时延从小到大排序，取排名90%/99%的时延，这个指标越大，对慢请求越敏感。
除此之外，有时候，我们也会关注可用性指标，这可归到稳定性。
一般而言，用户感知友好的高并发系统，时延应该控制在250毫秒以内。
什么样的系统才能称为高并发？这个不好回答，因为它取决于系统或者业务的类型。不过我可以告诉你一些众所周知的指标，这样能帮助你下次在跟人扯淡的时候稍微靠点儿谱，不至于贻笑大方。
通常，数据库单机每秒也就能抗住几千这个量级，而做逻辑处理的服务单台每秒抗几万、甚至几十万都有可能，而消息队列等中间件单机每秒处理个几万没问题，所以我们经常听到每秒处理数百万、数千万的消息中间件集群，而像阿某的API网关，每日百亿请求也有可能。
2、高并发的设计思路
高并发的设计思路有两个方向：
垂直方向扩展，也叫竖向扩展
水平方向扩展，也叫横向扩展
垂直方向：提升单机能力
提升单机处理能力又可分为硬件和软件两个方面：
硬件方向，很好理解，花钱升级机器，更多核更高主频更大存储空间更多带宽
软件方向，包括用各快的数据结构，改进架构，应用多线程、协程，以及上性能优化各种手段，但这玩意儿天花板低，就像提升个人产出一样，996、007、最多24 X 7。
水平方向：分布式集群
为了解决分布式系统的复杂性问题，一般会用到架构分层和服务拆分，通过分层做隔离，通过微服务解耦。
这个理论上没有上限，只要做好层次和服务划分，加机器扩容就能满足需求，但实际上并非如此，一方面分布式会增加系统复杂性，另一方面集群规模上去之后，也会引入一堆AIOps、服务发现、服务治理的新问题。
因为垂直向的限制，所以，我们通常更关注水平扩展，高并发系统的实施也主要围绕水平方向展开。
3、高并发的关键技术
玩具式的网络服务程序，用户可以直连服务器，甚至不需要数据库，直接写磁盘文件。但春运购票系统显然不能这么做，它肯定扛不住这个压力，那一般的高并发系统是怎么做呢？比如某宝这样的正经系统是怎么处理高并发的呢？
其实大的思路都差不多，层次划分 + 功能划分。可以把层次划分理解为水平方向的划分，而功能划分理解为垂直方向的划分。
首先，用户不能直连服务器，要做分布式就要解决“分”的问题，有多个服务实例就需要做负载均衡，有不同服务类型就需要服务发现。
集群化：负载均衡
负载均衡就是把负载（request）均衡分配到不同的服务实例，利用集群的能力去对抗高并发，负载均衡是服务集群化的实施要素，它分3种：
DNS负载均衡，客户端通过URL发起网络服务请求的时候，会去DNS服务器做域名解释，DNS会按一定的策略（比如就近策略）把URL转换成IP地址，同一个URL会被解释成不同的IP地址，这便是DNS负载均衡，它是一种粗粒度的负载均衡，它只用URL前半部分，因为DNS负载均衡一般采用就近原则，所以通常能降低时延，但DNS有cache，所以也会更新不及时的问题。
硬件负载均衡，通过布置特殊的负载均衡设备到机房做负载均衡，比如F5，这种设备贵，性能高，可以支撑每秒百万并发，还能做一些安全防护，比如防火墙。
软件负载均衡，根据工作在ISO 7层网络模型的层次，可分为四层负载均衡（比如章文嵩博士的LVS）和七层负载均衡（NGINX），软件负载均衡配置灵活，扩展性强，阿某云的SLB作为服务对外售卖，Nginx可以对URL的后半部做解释承担API网关的职责。
所以，完整的负载均衡链路是 client <->DNS负载均衡 ->F5 ->LVS/SLB ->NGINX
不管选择哪种LB策略，或者组合LB策略，逻辑上，我们都可以视为负载均衡层，通过添加负载均衡层，我们将负载均匀分散到了后面的服务集群，具备基础的高并发能力，但这只是万里长征第一步。
数据库层面：分库分表+读写分离
前面通过负载均衡解决了无状态服务的水平扩展问题，但我们的系统不全是无状态的，后面通常还有有状态的数据库，所以解决了前面的问题，存储有可能成为系统的瓶颈，我们需要对有状态存储做分片路由。
数据库的单机QPS一般不高，也就几千，显然满足不了高并发的要求。
所以，我们需要做分库分表 + 读写分离。
就是把一个库分成多个库，部署在多个数据库服务上，主库承载写请求，从库承载读请求。从库可以挂载多个，因为很多场景写的请求远少于读的请求，这样就把对单个库的压力降下来了。
如果写的请求上升就继续分库分表，如果读的请求上升就挂更多的从库，但数据库天生不是很适合高并发，而且数据库对机器配置的要求一般很高，导致单位服务成本高，所以，这样加机器抗压力成本太高，还得另外想招。
读多写少：缓存
缓存的理论依据是局部性原理。
一般系统的写入请求远少于读请求，针对写少读多的场景，很适合引入缓存集群。
在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求，因为缓存集群很容易做到高性能，所以，这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。
缓存的命中率一般能做到很高，而且速度很快，处理能力也强（单机很容易做到几万并发），是理想的解决方案。
CDN本质上就是缓存，被用户大量访问的静态资源缓存在CDN中是目前的通用做法。
缓存也有很多需要谨慎处理的问题：
一致性问题：(a)更新db成功+更新cache失败 ->不一致 (b)更新db失败+更新cache成功 ->不一致 ©更新db成功+淘汰缓存失败 ->不一致
缓存穿透：查询一定不存在的数据，会穿透缓存直接压到数据库，从而导致缓存失去作用，如果有人利用这个漏洞，大量查询一定不存在的数据，会对数据库造成压力，甚至打挂数据库。解决方案：布隆过滤器 或者 简单的方案，查询不存在的key，也把空结果写入缓存（设置较短的过期淘汰时间），从而降低命失
缓存雪崩：如果大量缓存在一个时刻同时失效，则请求会转到DB，则对DB形成压迫，导致雪崩。简单的解决方案是为缓存失效时间添加随机值，降低同一时间点失效淘汰缓存数，避免集体失效事件发生
但缓存是针对读，如果写的压力很大，怎么办？
高写入：消息中间件
同理，通过跟主库加机器，耗费的机器资源是很大的，这个就是数据库系统的特点所决定的。
相同的资源下，数据库系统太重太复杂，所以并发承载能力就在几千/s的量级，所以此时你需要引入别的一些技术。
比如说消息中间件技术，也就是MQ集群，它是非常好的做写请求异步化处理，实现削峰填谷的效果。
消息队列能做解耦，在只需要最终一致性的场景下，很适合用来配合做流控。
假如说，每秒是1万次写请求，其中比如5千次请求是必须请求过来立马写入数据库中的，但是另外5千次写请求是可以允许异步化等待个几十秒，甚至几分钟后才落入数据库内的。
那么此时完全可以引入消息中间件集群，把允许异步化的每秒5千次请求写入MQ，然后基于MQ做一个削峰填谷。比如就以平稳的1000/s的速度消费出来然后落入数据库中即可，此时就会大幅度降低数据库的写入压力。
业界有很多著名的消息中间件，比如ZeroMQ，rabbitMQ，kafka等。
消息队列本身也跟缓存系统一样，可以用很少的资源支撑很高的并发请求，用它来支撑部分允许异步化的高并发写入是很合适的，比使用数据库直接支撑那部分高并发请求要减少很多的机器使用量。
避免挤兑：流控
再强大的系统，也怕流量短事件内集中爆发，就像银行怕挤兑一样，所以，高并发另一个必不可少的模块就是流控。
流控的关键是流控算法，有4种常见的流控算法。
计数器算法（固定窗口）：计数器算法是使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略，下一个周期开始时，进行清零，重新计数，实现简单。计数器算法方式限流对于周期比较长的限流，存在很大的弊端，有严重的临界问题。
滑动窗口算法：将时间周期分为N个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。此算法可以很好的解决固定窗口算法的临界问题。
漏桶算法：访问请求到达时直接放入漏桶，如当前容量已达到上限（限流值），则进行丢弃（触发限流策略）。漏桶以固定的速率进行释放访问请求（即请求通过），直到漏桶为空。分布式环境下实施难度高。
令牌桶算法：程序以r（r=时间周期/限流值）的速度向令牌桶中增加令牌，直到令牌桶满，请求到达时向令牌桶请求令牌，如获取到令牌则通过请求，否则触发限流策略。分布式环境下实施难度高。
4、高并发的实践经验
接入-逻辑-存储是经典的互联网后端分层，但随着业务规模的提高，逻辑层的复杂度也上升了，所以，针对逻辑层的架构设计也出现很多新的技术和思路，常见的做法包括系统拆分，微服务。
除此之外，也有很多业界的优秀实践，包括某信服务器通过协程（无侵入，已开源libco）改造，极大的提高了系统的并发度和稳定性，另外，缓存预热，预计算，批量读写（减少IO），池技术等也广泛应用在实践中，有效的提升了系统并发能力。
为了提升并发能力，逻辑后端对请求的处理，一般会用到生产者-消费者多线程模型，即I/O线程负责网络IO，协议编解码，网络字节流被解码后产生的协议对象，会被包装成task投入到task queue，然后worker线程会从该队列取出task执行，有些系统会用多进程而非多线程，通过共享存储，维护2个方向的shm queue，一个input q，一个output q，为了提高并发度，有时候会引入协程，协程是用户线程态的多执行流，它的切换成本更低，通常有更好的调度效率。
另外，构建漏斗型业务或者系统，从客户端请求到接入层，到逻辑层，到DB层，层层递减，过滤掉请求，Fail Fast（尽早发现尽早过滤），嘴大屁眼小，哈哈。
漏斗型系统不仅仅是一个技术模型，它也可以是一个产品思维，配合产品的用户分流，逻辑分离，可以构建全方位的立体模型。
5、小结
莫让浮云遮望眼，除去繁华识真颜。我们不能掌握了大方案，吹完了牛皮，而忽视了编程最本质的东西，掌握最基本最核心的编程能力，比如数据架构和算法，设计，惯用法，培养技术的审美，也是很重要的，既要致高远，又要尽精微。
分享嘉宾：张鸿志博士 美团 算法专家
编辑整理：廖媛媛 美的集团
出品平台：DataFunTalk
导读： 美团作为中国最大的在线本地生活服务平台，连接着数亿用户和数千万商户，其背后蕴含着丰富的与日常生活相关的知识。美团知识图谱团队从2018年开始着力于图谱构建和利用知识图谱赋能业务，改善用户体验。具体来说，“美团大脑”是通过对美团业务中千万数量级的商家、十亿级别的商品和菜品、数十亿的用户评论和百万级别的场景进行深入的理解来构建用户、商户、商品和场景之间的知识关联，进而形成的生活服务领域的知识大脑。目前，“美团大脑”已经覆盖了数十亿实体、数百亿的三元组，在餐饮、外卖、酒店、到综等领域验证了知识图谱的有效性。今天我们介绍美团大脑中生活服务知识图谱的构建及应用，主要围绕以下3个方面展开：
--
“美团大脑”是什么？
以下是“美团大脑”构建的整体RoadMap，最先是2018年开始餐饮知识图谱构建，对美团丰富的结构化数据和用户行为数据进行初步挖掘，并在一些重要的数据维度上进行深入挖掘，比如说对到餐的用户评论进行情感分析。2019年，以标签图谱为代表，重点对非结构化的用户评论进行深入挖掘。2020年以后，开始结合各领域特点，逐个领域展开深度数据挖掘和建设，包括商品、美食、酒旅和到综和cross图谱等。
--
在搜索中，通常用户需要将其意图抽象为搜索引擎能够支持的一系列精搜关键词。标签知识图谱则是通过“标签”来承载用户需求，从而提升用户搜索体验。例如，通过标签知识图谱，用户可直接搜索“带孩子”或者“情侣约会”，就可返回合适的商户/内容供给。从信息增益角度来说，用户评论这种非结构化文本蕴含了大量的知识（比如某个商户适合的场景、人群、环境等），通过对非结构化数据的挖掘实现信息增益。该团队以生活服务领域的海量评论数据作为主要知识来源，通过标签挖掘、标签间关系挖掘以及标签-商户关联等关键技术，自下而上梳理用户需求，场景及主要关注点完成图谱构建。
标签知识图谱构建分为以下四个部分：知识抽取、关系挖掘、图谱打标和图谱应用。
① 知识抽取
标签挖掘采用简单的序列标注架构，包括Single span标签挖掘和跳字标签挖掘，此外还会结合语义判别或者上下文判别，采用远监督学习+结果投票方式获取更精准的标签。
② 关系挖掘
同义词挖掘：同义词挖掘被定义为给定包含N个词的池子，M个业务标签词，查找M中每个词在N中的同义词。现有的同义词挖掘方法包括搜索日志挖掘、百科数据抽取、基于规则的相似度计算等，缺乏一定的通用性。当前我们的目标是寻找通用性强，可广泛应用到大规模数据集的标签同义词挖掘方法。
以下是作者给出的同义词挖掘的具体方案，首先将离线标签池或者线上查询标签进行向量表示获取向量索引，再进行向量哈希召回，进一步生成该标签的TopN的同义词对候选，最后使用同义词判别模型。该方案的优势在于降低了计算复杂度，提升了运算效率；对比倒排索引候选生成，可召回字面无overlap的同义词，准确率高，参数控制简单。
对于有标注数据，主流的标签词嵌入表示方法有word2vec、BERT等。word2vec方法实现较为简单，词向量取均值，忽略了词的顺序；BERT通过预训练过程中能捕捉到更为丰富的语义表示，但是直接取[CLS]标志位向量，其效果与word2vec相当。Sentence-Bert对于Bert模型做了相应的改进，通过双塔的预训练模型分别获取标签tagA和tagB表征向量，然后通过余弦相似性度量这两个向量的相似性，由此获取两个标签的语义相似性。
对于无标注数据来说，可以通过对比学习的方法获取句子的表示。如图所示，Bert原始模型对于不同相似度的句子的向量相似度都很高，经过对比学习的调整之后，向量的相似度能够较好地体现出文本相似度。
对比学习模型设计：首先给定一个sentence，对这个样本做扰动产生样本pair，常规来说，在embedding层加上Adversarial Attack、在词汇级别做Shuffling或者丢掉一些词等构成pair；在训练的过程中，最大化batch内同一样本的相似度，最小化batch内其他样本的相似度。最终结果显示，无监督学习在一定程度上能达到监督学习的效果，同时无监督学习+监督学习相对于监督学习效果有显著提升。
同义词判别模型设计：将两个标签词拼接到Bert模型中，通过多层语义交互获取标签。
标签上下位挖掘：词汇包含关系是最重要的上下位关系挖掘来源，此外也可通过结合语义或统计的挖掘方法。但当前的难点是上下位的标准较难统一，通常需要结合领域需求，对算法挖掘结果进行修正。
③ 图谱打标：如何构建标签和商户供给的关联关系？
给定一个标签集合，通过标签及其同义词在商户UGC/团单里出现的频率，卡一个阈值从而获取候选tag-POI。这样会出现一个问题是，即使是频率很高但不一定有关联，因此需要通过一个商户打标判别模块去过滤bad case。
商户打标考虑标签与商户、用户评论、商户Taxonomy等三个层次的信息。具体来讲，标签-商户粒度，将标签与商户信息（商户名、商户三级类目、商户top标签）做拼接输入到Bert模型中做判别。
微观的用户评论粒度，判断每一个标签与提到该标签的评论（称为evidence）之间是正面、负面、不相关还是不确定的关系，因此可当作四分类的判别模型。我们有两种方案可选择，第一种是基于多任务学习的方法， 该方法的缺点在于新增标签成本较高，比如新增一个标签，必须为该标签新增一些训练数据。笔者最终采用的是基于语义交互的判别模型，将标签作为参数输入，使该模型能够基于语义判别，从而支持动态新增标签。
基于语义交互的判别模型，首先做向量表示，然后是交互，最终聚合比较结果，该方法的计算速度较快，而基于BERT的方法，计算量大但准确率较高。我们在准确率和速度上取balance，例如当POI有30多条的evidence，倾向于使用轻量级的方式；如果POI只有几条evidence，可以采用准确率较高的方式进行判别。
从宏观角度，主要看标签和类目是否匹配，主要有三种关系：一定不会，可能会，一定会。一般通过商户层关联结果进行投票结果，同时会增加一些规则，对于准确率要求较高时，可进行人工review。
④ 图谱应用：所挖掘数据的直接应用或者知识向量表示应用
在商户知识问答相关的场景，我们基于商户打标结果以及标签对应的evidence回答用户问题。
首先识别用户query中的标签并映射为id，然后通过搜索召回或者排序层透传给索引层，从而召回出有打标结果的商户，并展示给C端用户。A/B实验表明，用户的长尾需求搜索体验得到显著提升。此外，也在酒店搜索领域做了一些上线实验，通过同义词映射等补充召回手段，搜索结果有明显改善。
主要采用GNN模型实现，在构图中构建了两种边，Query-POI点击行为和Tag-POI关联信息；采用Graph Sage进行图学习，学习的目标是判断Tag和POI是否有关联关系或者Query和POI是否点击关系，进一步依据关联强度进行采样。上线后结果显示，在仅利用Query-POI信息构图时，线上无收益，在引入Tag-POI关联信息后线上效果得到显著提升。这可能是因为排序模型依赖于Query-POI点击行为信息去学习，引入Graph Sage学习相当于换了一种学习的方式，信息增益相对较少；引入Tag-POI信息相当于引入了新的知识信息，所以会带来显著提升。
此外，仅接入Query-POI向量相似度线上效果提升不佳，将Query和POI向量接入后效果得到显著提升。这可能是因为搜索的特征维度较高，容易忽略掉向量相似度特征，因此将Query和POI向量拼接进去后提升了特征维度。
该任务通过当前已知的Item去预测用户点击的Masked Item。比如说获取Item的上下文表征的时候，将相关的Attribute信息也进行向量表征，从而去判断Item是否有Attribute信息。
此外，还可以做Masked Item Attribute 预测，从而将标签的知识图谱信息融入到序列推荐任务中去。实验结果表明，引入知识信息后的准确率在不同的数据集上均有数量级的提升。同时，我们也做了线上转化的工作，将Item表征做向量召回；具体来说，基于用户历史上点击过的Item去召回topN相似的Item，从而补充线上推荐结果，在美食列表推荐页有显著提升。
--
菜品知识图谱的构建目标，一方面是构建对菜品的系统理解能力，另一方面是构建较为完备的菜品知识图谱，这里从不同的层次来说明菜品知识图谱的构建策略。
** * 菜名理解**
菜名中蕴含着最精准、获取成本最低的菜品信息，同时对菜名的理解也是后续显式知识推理泛化能力的前提。首先是抽取菜名的本质词/主体菜，然后序列标注去识别菜名中的每个成分。针对两种场景设计了不同的模型，对于有分词情况，将分词符号作为特殊符号添加到模型中，第一个模型是识别每个token对应的类型；对于无分词情况，需要先做Span-Trans的任务，然后再复用有分词情况的模块。
菜名理解是一个较为重要的信息来源，但是所蕴含的知识相对有限，从而提出了基于深度学习模型进行初步字符推断，可实现对不同字面表述的泛化处理。但是对需要专业知识的case表现欠佳，偶尔在字面极其匹配时出现case。
从知识内容丰富的文本中挖掘某些菜谱的基础知识，来构建源知识库；然后通过泛化推理去映射到具体SKU中。在食材推理中，比如菜品种有多道红烧肉，统计10道五花肉中有4道是指五花肉，6道是指带皮五花肉，因此肉就转化为带皮五花肉。对应地，佛跳墙有多道菜谱，先通过统计每种食材出现的概率，可以卡一个阈值，然后表明该菜谱的食谱是什么。
多源数据挖掘，基于菜名理解结果构建solid knowledge triple，同时也依赖菜名理解结果泛化规则。该策略主要适用于处理食材、功效、人群等标签。该方法准确率OK，有一定泛化能力，但覆盖率偏低。
业务内有一些比较好用的训练数据，例如1000万商户编辑自洽的店内分类树。基于该数据可产生5亿的 positive pairs 和 30G corpus。在模型训练中，会随机替换掉菜谱分类的 tab/shop，模型判断 tab/shop 是否被替换；50%的概率drop shop name，使得模型仅输入菜名时表现鲁棒。同时，对模型做了实体化改进，将分类标签作为bert的词进行训练，将该方法应用到下游模型中，在10w标注数据下，菜谱上下位/同义词模型准确率提升了1.8%。
首先使用ReseNet对菜谱图片进行编，使用Bert模型对菜谱文本信息做编码，通过对比学习loss去学习文本和店菜的匹配信息。这里采用双塔模型，一方面是下游应用较为方便，单塔模型可独立使用，也可inference出菜品图片的表示并缓存下来；另一方面是图片内容单纯，暂无交互式建模的必要。训练目标分别是图片与店菜匹配、图片与菜名对齐，图片与Tab对齐。
可基于多模态信息做菜品品类预测或者菜谱信息补全。比如，预测“猪肉白菜”加上了图片信息将更加直观和准确。基于文本和视图模态信息进行多视图半监督的菜谱属性抽取，以烹饪方式抽取为例，首先通过产生烹饪方法训练样本（红烧肉-红烧）；然后采用CNN模型去训练预测菜谱烹饪方法，指导Bert模型Finetune文本模型或者多模态模型，基于商户/tab/菜品及评论信息预测菜品烹饪方法；最终对两个模型进行投票或者将两个特征拼接做预测。
综上，我们对菜品知识图谱构建进行相应的总结。菜品理解比较适合SKU的初始化；深度学习推理模型和显式推理模型比较适合做同义词、上下位、菜系等；最终是想通过多模态+结构化预训练和推理来解决单模态信息不完整、属性维度多、需要大量标注数据等问题，因此该方法被应用到几乎所有的场景中。
今天的分享就到这里，谢谢大家。
分享嘉宾：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）