|
6 | 6 | <!-- TOC --> |
7 | 7 |
|
8 | 8 | - [Introduction](#introduction) |
| 9 | + - [不同时期的搜索](#不同时期的搜索) |
| 10 | + - [查询理解系统的特点](#查询理解系统的特点) |
| 11 | +- [深度查询理解](#深度查询理解) |
| 12 | + - [查询理解模块的作用与处理流程](#查询理解模块的作用与处理流程) |
9 | 13 | - [引用文献](#引用文献) |
10 | 14 |
|
11 | 15 | <!-- /TOC --> |
|
41 | 45 | - 他们必须了解哪些查询需要重定向到 Web 搜索引擎,哪些查询用于本地设备操作。 |
42 | 46 |
|
43 | 47 |
|
| 48 | +### 不同时期的搜索 |
| 49 | + |
| 50 | +- 文本匹配 |
| 51 | + - 使用 Lucene indexing 等方法构建从关键词到文档的反向索引; |
| 52 | + - 通过人工添加的标签过滤返回的结果; |
| 53 | + - 大多数购物网站依然在使用; |
| 54 | + |
| 55 | + <div align="center"><img src="./_assets/TIM截图20190213103134.png" height="" /></div> |
| 56 | + |
| 57 | +- Rank 排序 |
| 58 | + - 底层依然是基本的文本匹配,但是加入了根据相关性排序的概念(Rank) |
| 59 | + - 相关性的计算基于一系列指标,如 TF-IDF、关键词相关性(keyword relevance)、网站权重(website authority)、流行度(popularity)、链接强度(link strength)等; |
| 60 | + |
| 61 | +- 基于 NLP 技术的查询理解 |
| 62 | + - 通过一个查询理解模块,利用 NLP 技术,通过上下文信息了解用户以前的搜索和浏览活动,以及用户的兴趣、位置、查询时间、位置天气等,以准确预测用户的意图并获得最佳结果。 |
| 63 | + |
| 64 | +### 查询理解系统的特点 |
| 65 | + |
| 66 | +1. 理解查询的语义 |
| 67 | + |
| 68 | + 语义理解的层次 |
| 69 | + |
| 70 | + <div align="center"><img src="./_assets/TIM截图20190213105813.png" height="" /></div> |
| 71 | + |
| 72 | +1. 理解上下文和历史任务 |
| 73 | + |
| 74 | + 示例:搜索 “michael jordan” 可能会返回篮球运动员或者伯克利大学的机器学习教授,如果用户之前搜索了机器学习相关的关键字,那么用户的意图很可能是后者; |
| 75 | + |
| 76 | +1. 个性化 |
| 77 | + |
| 78 | + 不同的用户有不同的兴趣,用户很可能会在他的兴趣领域或工作领域进行搜索。 |
| 79 | + |
| 80 | + |
| 81 | +## 深度查询理解 |
| 82 | + |
| 83 | +### 查询理解模块的作用与处理流程 |
| 84 | + |
| 85 | +**作用**: |
| 86 | +1. 推断查询的意图; |
| 87 | +1. 通过建议,引导用户到达一个明确的意图; |
| 88 | +1. 改进查询结果。 |
| 89 | + |
| 90 | +**处理流程**:(标号不代表处理顺序) |
| 91 | + |
| 92 | +<div align="center"><img src="./_assets/TIM截图20190213144945.png" height="" /></div> |
| 93 | + |
| 94 | +- 首先由**查询细化子模块**中的**纠错组件**对原始查询进行处理,通常包括拼写更正、缩略语扩展、分词、合并、短语切分等; |
| 95 | +- 修正后的查询被传递给**查询建议子模块**,该子模块用于发现那些可能导致更好结果的查询(下拉列表),并作为新的查询重新输入; |
| 96 | +- 新的查询通过**查询拓展**组件找到同义查询,以避免术语不匹配带来的损失(因为搜索引擎的底层依然基于传统的文本匹配);以上过程可能会进行多轮; |
| 97 | +- 将扩展后的查询集合传入**查询意图检测子模块**,用于推断查询的确切意图,其中 |
| 98 | + - **查询分类**组件用于标记查询所属的类别(用于过滤不相关的查询),通常被定义为运动、天气、旅游或视频等不同类别之一,如 “brazil germany” 可能会被定义为运动(如果搜索了足球)或旅游(搜索了巴西到德国的航班); |
| 99 | + - 一个查询可能会被划分为多个片段(Segment),特别是对于句子类型的搜索,不同的片段被分为不同的类别; |
| 100 | + - **语义标记**组件对每个查询做语义标记,以进行精确的意图检测。 |
| 101 | +- 最后将扩展的意图标记查询集合传递到答案生成模块 |
| 102 | + |
| 103 | +<div align="center"><img src="./_assets/TIM截图20190213151159.png" height="" /></div> |
| 104 | + |
| 105 | +- **查询纠错**发现了原始查询的拼写错误,并进行了纠正; |
| 106 | +- **查询建议**给出了两个不同领域的可能推荐,这里假设用户选择了 “Michael Jordan berkley” 作为他真正的目标; |
| 107 | +- **查询拓展**找到更多的同义查询加入查询集; |
| 108 | +- **查询分类**将得到的查询集分类为目标类别(这里是 "academic"); |
| 109 | +- **语义标记**对查询中的不同片段进行标记,以获得准确的查询意图。 |
| 110 | + |
| 111 | + |
| 112 | + |
| 113 | + |
44 | 114 | ## 引用文献 |
45 | 115 | - [2] Learning to Personalize Query Auto-Completion |
46 | | - - 本文讨论了使用位置特征、年龄和性别等用户特征、区域特征、用户短历史特征和长历史特征进行查询自动完成的问题,并给出了使用该方法进行意图预测的思路。 |
| 116 | + - 本文讨论了使用位置特征、年龄和性别等用户特征、区域特征、用户短历史特征和长历史特征进行查询自动完成的问题,并给出了使用该方法进行意图预测的思路。 |
| 117 | +- [6] Context-Aware Query Classification |
| 118 | + - 本文讨论了上下文的使用和概念序列(概念后缀树)的遍历。 |
| 119 | +- [8] Evaluating the Effectiveness of Search Task Trails |
| 120 | + - 本文讨论了交错查询的情况:30% 的会话包含多个任务,5% 的会话包含交叉任务。 |
| 121 | + |
| 122 | + <div align="center"><img src="./_assets/TIM截图20190213120835.png" height="" /></div> |
| 123 | + |
| 124 | +- [9] Task-Aware Query Recommendation |
| 125 | + - 给出了一种新的方法,用于识别交错的任务,并根据所识别的交错任务推荐查询。 |
0 commit comments