检索技术核心20讲
陈东
奇虎360商业产品事业部资深总监
立即订阅
2298 人已学习
课程目录
已完结 29 讲
0/4登录后,你可以任选4讲全文学习。
课前必学 (2讲)
开篇词 | 学会检索,快人一步!
免费
导读 | 三步走策略,轻松搞定检索!
基础技术篇 (8讲)
01 | 线性结构检索:从数组和链表的原理初窥检索本质
02 | 非线性结构检索:数据频繁变化的情况下,如何高效检索?
03 | 哈希检索:如何根据用户ID快速查询用户信息?
04 | 状态检索:如何快速判断一个用户是否存在?
05 | 倒排索引:如何从海量数据中查询同时带有“极”和“客”的唐诗?
测一测 | 检索算法基础,你掌握了多少?
特别加餐 | 倒排检索加速(一):工业界如何利用跳表、哈希表、位图进行加速?
特别加餐 | 倒排检索加速(二):如何对联合查询进行加速?
进阶实战篇 (13讲)
06 | 数据库检索:如何使用B+树对海量磁盘数据建立索引?
07 | NoSQL检索:为什么日志系统主要用LSM树而非B+树?
08 | 索引构建:搜索引擎如何为万亿级别网站生成索引?
09 | 索引更新:刚发布的文章就能被搜到,这是怎么做到的?
10 | 索引拆分:大规模检索系统如何使用分布式技术加速检索?
11|精准Top K检索:搜索结果是怎么进行打分排序的?
12 | 非精准Top K检索:如何给检索结果的排序过程装上“加速器”?
13 | 空间检索(上):如何用Geohash实现“查找附近的人”功能?
14 | 空间检索(下):“查找最近的加油站”和“查找附近的人”有何不同?
15 | 最近邻检索(上):如何用局部敏感哈希快速过滤相似文章?
16 | 最近邻检索(下):如何用乘积量化实现“拍照识花”功能?
特别加餐 | 高性能检索系统中的设计漫谈
测一测 | 高性能检索系统的实战知识,你掌握了多少?
系统案例篇 (4讲)
17 | 存储系统:从检索技术角度剖析LevelDB的架构设计思想
18 | 搜索引擎:输入搜索词以后,搜索引擎是怎么工作的?
19 | 广告系统:广告引擎如何做到在0.1s内返回广告信息?
20 | 推荐引擎:没有搜索词,“头条”怎么找到你感兴趣的文章?
结束语 (2讲)
结束语 | 成长和进化,技术如此,我们亦如此
免费
结课测试 | 这些检索知识,你都掌握了吗?
检索技术核心20讲
15
15
1.0x
00:00/00:00
登录|注册

20 | 推荐引擎:没有搜索词,“头条”怎么找到你感兴趣的文章?

陈东 2020-05-15
你好,我是陈东。今天我来和你讲讲推荐引擎。
我们每天都会接触推荐引擎,最常见的,就是当我们用手机浏览资讯类 App 的时候,经常会用到的“下拉刷新”功能。你会发现,每次刷新之后,这些 App 都能给你推荐你最关心的“头条信息”。
那这些资讯类的 App,是怎么在没有搜索词的情况下,仅凭下拉刷新就可以在海量的文章中检索出你感兴趣的内容,并且推荐给你的呢?这就和推荐引擎中的检索技术有关了。那今天,我就以资讯类 App 推荐文章为例,来和你聊一聊推荐引擎中的检索技术。

推荐引擎的整体架构和工作过程

我们知道,检索引擎的灵活程度和系统的检索约束条件有关。那我们先来看一下针对不同的引擎,系统的检索约束条件分别是什么。
在搜索引擎中,系统的强约束条件是用户输入的搜索词。而在广告引擎中,系统的强约束条件是广告主设置的定向要求。但是在资讯类 App 推荐引擎中,因为所有的用户操作只有“下拉刷新”这一个动作,所以外界输入的检索约束条件其实非常少。
因此,相比于搜索引擎和广告引擎,推荐引擎具有更灵活的检索能力,也就是可以使用更灵活的检索技术,来进行文章的召回服务。这也是推荐引擎相比于搜索引擎和广告引擎最大的不同之处。
那一个推荐引擎是怎么工作的呢?我按照功能划分,梳理出了推荐引擎的核心模块。
推荐引擎架构示意图
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《检索技术核心20讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(3)

  • 一步
    将第一步“寻找每个物品的相似物品列表”放在离线环节。具体的操作是以 Item ID 为 Key,以相似物品列表为 posting list,来生成倒排索引,再把它存入线上的 Key-value 数据库中
    ---------------------------------
    利用这种方法的时候,每个item 都会生成一个 posting list, 这样的每个商品都会保存 n 分,这样会不会浪费空间?

    作者回复: 如果每个posting list都存了所有的商品,的确会比较浪费空间,而且其实也没必要,因为最后只会选取top k个。因此,我们可以对posting list进行截断,仅保留相似度超过一定阈值的item就好了。这样就能大幅减少空间。

    2020-05-17
    1
  • 一步
    我们就要先找出最接近的 k1 个 Item 向量,然后用 Item 1 对 User1 的权重乘上每个 Item 和 Item 1 的相似度,
    --------------------------
    这个应该是: 每个 Item 对 User1 的权重乘上每个 Item 和 Item 1 的相似度

    作者回复: 并不是哦。在基于物品的协同过滤中,对于要推荐的item,我们之前并不知道这个item和user1有什么关系,我们知道的是两个信息:
    一个是user1对item1的打分(记为w),另一个是item1和item的相似度(记为s),因此,user1和item的相关性,就是w*s

    2020-05-17
    1
  • 范闲
    1.关于第一个问题,其实有点疑问。每个item的向量实际上是不同用户偏好构成的。最终对不同item求出来实际上对于某个item,用户偏好相近的程度

    2.整体技术上的架构是类似的,但是在场景上区分很大。

    作者回复: 1.第一个问题,的确,最后针对某个用户推荐的时候,我们是需要具体计算和这个指定用户的相关性的。不过我在文中也说过,item based方案的实现会分为两部分,第一部分是离线构建起相似item的倒排表,第二部分才是在线上环节,根据具体用户,找出推荐item。我在这道题中,其实只要求做第一步,给出每个item对应的posting list即可。如果你想把第二步对具体用户推荐也完成的话,可以以用户1为例子,看看会推荐出什么item。

    2020-05-15
收起评论
3
返回
顶部