谢邀!(潜水员终于有可以专业回答的问题了)
优采云 发布时间: 2021-06-22 06:04谢邀!(潜水员终于有可以专业回答的问题了)
感谢邀请! (潜水员终于有一个可以专业回答的问题了)
相关兴趣:搜狗搜索工程师,对搜索技术“有点了解”
搜索是一个复杂的系统,具有广泛的技术方向。它的技术门槛如此之高,几乎没有任何互联网产品能与搜索相媲美。要玩这个系统,必须要有一群了解搜索的最优秀的工程师和研究人员。看到@熊辰炎同学也提到,如果要解决,知乎可能需要5个熟练工工作半年以上。在我看来,这种作为站点搜索的团队配置几乎可以解决大部分的基本问题,即避免被“处处”投诉。但如果要求更高,能够“智能”处理用户查询,那么这种团队配置可能还是遥不可及。
当然,搜索不仅仅是人类的问题。支持搜索的人工智能技术正在“经验主义”(以统计学为代表)的道路上享受着大数据(尤其是用户行为数据)的红利。从一个特定的站点出发,即使是知名度高、广受欢迎的站点,它所能访问的数据也是非常有限的,无论是用户群体行为数据,还是整个网络的信息资源。用户对全网通用搜索的期望与站内搜索的唯一区别在于,搜索范围已经从全网向这个特定站点转变,但搜索用户对全网通用搜索的先天“懒惰”、模糊性和智能期望搜索结果从未改变。而且,由于用户对自己喜欢的站点的了解和熟悉程度远远超过了他对整个网络的了解,因此用户对搜索服务中的各种问题更加敏感,因此有更高的要求。正是这种数据限制导致的技术限制和用户需求之间的矛盾,使得原生网站搜索注定是一条不太可能的成功之路。
说远了,让我们回到技术员身上,解释一下为什么知乎site搜索不如一般搜索(如百度、搜狗)网站查询那么好用。
@张前川对搜索效果的评价和解释已经比较完整了。让我以这些案例为例,说明通用搜索是如何解决其背后的技术问题的。主要分为NLP/相关计算/排序方面。
1.NLP
1.1 分词(Word Segmentation)
搜索中的分词是指将文本切割成多个独立的语义单元作为检索的最小单位,然后对分词后的词串建立倒排索引,以加快检索服务。这是信息检索最基本也是最重要的结构,这里不再详细展开。
先看张千川提到的“避谷”案例。正如张千川所说,避谷应单独切割成一个词。为了说明下面的算法,我把案例改成了“避谷法”,这样更容易说明问题。正确的分词方法是【避谷法】。如果把避谷分为【避】和【谷】两个词,很容易在知乎站内搜索中出现【避】和【谷】这两个词分开出现的结果,这也是我们常说的语义漂移。那你怎么知道[辟谷]应该是一个独立的词?
最经典的分词方法包括基于词典的前向/后向最大匹配或基于语言模型的分词等。其中,如何构建准确完整的词典以及哪些语料统计适用于语言模型是所有算法成功。重点是。
问:Universal Search 如何解决这个问题?
答案:挖掘网络语料或用户行为数据!
一个。对于基于词典的方法,由于“辟谷”是道教术语,因此该词可能不收录在分词词典中。那么一般搜索通常可以通过挖掘网络语料库(如百科词条)来补充词典。
B.对于语言模型或其他统计方法,用户群体的历史行为数据是非常有价值的数据。这里只有一个想法。从历史上看,用户在点击结果的标题中搜索“顾”和“顾”的可能性很大,“方”和“方法”很可能是挨在一起的,而“顾”和“法”很小。概率是相邻的。由此可以推断,[Agu]和[Method]应该连起来构成一个词,将“Agu”和“Method”分开更合适。用户历史行为数据的使用方式有很多种,大家也可以打开思路。
1.2 查询更正(Query Correction)
再看“什么是浩亭”的案例,很直观。大家可以看到,用户将查询词的一部分输入拼音,系统需要自动纠正错误。当然,这是一个简单的纠错,只要找到浩亭对应的上下文语言模型中概率最高的汉字“好听”,就可以纠错。
有些需要纠错的情况没那么容易。比如“哦泡泡手机”,本意是找“oppo手机”。人脑可以非常快速准确地完成这个纠错过程,但对于没有智能的机器来说,这个转换过程就没有那么容易了。这个case算法的纠错过程大概是这样的:先把“oh bubble”转换成拼音“opao”,然后计算“opao”和“oppo”之间的编辑距离(衡量文本字符串相似度的一种方法) ),然后通过各种数据和模型计算出“哦泡泡”被修正为“oppo”的概率,尤其是上下文为“手机”时,“哦泡泡”被修正为“oppo”的概率。这些步骤中的每一步都需要同时有算法和数据的支持。一般搜索面对更多的数据和更多的用户,显然有着非常大的优势。
1.3 查询理解(Query Understanding)
查询理解的概念比较宽泛。从广义上讲,上述的分词和查询纠错也可以归入查询理解的范畴。这里我们主要使用query comprehension来总结一系列query rewriting、词之间的接近度、词权重等。 对query的理解有助于得到更好的搜索结果。 Maekawa给出的“101大楼”是一个更全面的例子,但我对此有不同的看法。
首先,“101楼”一起代表一个完整的语义实体,所以在相关结果中101和楼应该是相邻的。 Mae Chuan说应该分成一个词,但是为了搜索召回率,也就是尽可能多的找到相关结果,最好分开,因为“101楼”还有很多其他的名字”,如《台北101》《101大厦》等。为 101 大楼挖掘出这些等效(或同义)术语对于搜索结果至关重要。搜索中使用的这种等效或同义算法是查询重写的最常见形式。
但是“101”和“建筑”之间有着非常密切的关系。如果两者在文档中相距太远,则结果通常无关紧要。这里涉及到另一个概念——接近度,即需要将其切割成两个独立的词,但要求结果中两个词之间的距离足够近。在某些情况下,有必要靠近。
查询重写和接近度还依赖于网络资源的挖掘和历史用户行为的挖掘,比如用户在同一个会话中的主动重写、用户在查询后点击、多次查询具有相似的点击结果等......合理应用各类数据可以提高搜索效果。通用搜索正在利用其数千亿的网页索引库和每天数亿的用户查询和跟进行为,逐步积累对大数据的查询理解智慧。任何网站可能都无法访问这些内容。
2.RELEVANCE(相关性)
上面提到的内容都是和NLP相关的,我们再来看看search-correlation计算中的另一个核心技术。相关性计算通常是指在给定查询和文档的情况下计算两者在语义上是否相关。语义相关是一个非常大的挑战。从技术的发展来看,从早期的词频统计,比如tf.idf、BM25、到语言模型、接近度等,都试图从查询词中出现在文档中。使用次数、位置、词权重、文档长度等来估计查询与文档的相关性。近期,在深度学习的影响下,基于深度神经网络的词嵌入、语义表示、语义匹配等新技术的出现,正在将相关性计算从匹配统计引向“语义计算”的大门。搜狗和百度在这方面已经取得了阶段性的成功,这个方向还有很多问题需要解决,让我们拭目以待。
美川提到的“为什么来北京”的案例可以从多个角度来解决。例如,通过查询理解,我们可以知道“Beijing”在这个查询中是一个非常重要的词,标题中收录重要词的文档与查询词相关的概率比只收录该词的文档要高。正文中的重要词。 Maekawa 提到的第二个结果是无关紧要的。 “北京”只出现在正文中。解决这个问题的想法还有很多。如果要进行搜索,则需要从多个维度解释查询和文档之间的关系。这是一项需要大量积累的工作。
3.ranking(排名)
排序,网文胜义就是根据满足用户需求的程度,将搜索结果从高到低排序,让最符合用户需求的结果排在搜索结果列表的顶部,让用户可以先浏览。排序主要涉及两个主要问题:用于排序的多维特征和多维特征的融合以确定最终顺序。
相关性无疑是搜索排序中非常重要的一种纬度。前面我们提到,相关性本身也需要从多个更精细的纬度进行分析。正如许多用户所提到的,知乎 是一个问答社区。有些人提出问题,有些人回答,而另一些人喜欢并关注。为什么知乎 返回的许多结果为零答案和零关注者。事实上,问题的回答数、关注数、点赞数都是衡量一个文档质量的非常客观的指标。这些对于衡量问题是否能够满足用户的需求非常有价值,这意味着在排名时应该考虑这些。功能。
那么这么多特征是如何相互融合来确定最终顺序的呢?有许多基于规则或线性融合的方法。近年来,learning to rank方法在各种竞赛、学术论文、工业产品中被无数次使用,将多个特征融合的结果带到或逼近局部最大值。最优解或全局最优解。
无论是排序特征的准确性和丰富性,还是排序的整合,都是搜索工程师孜孜不倦优化的方向。经验和积累也很重要。
4.search 架构
张千川提到了搜索性能和稳定性问题,证明他确实是一个搜索专家。哈哈。大多数用户认为搜索性能与搜索性能无关,但实际上两者密切相关。由于服务负载的压力和用户响应时间的限制,分配给每个用户查询的计算资源和时间非常有限。底层检索的性能越好,可以搜索到的候选文档就越多,留给排序优化的时间就越多,可以使用更丰富的特征和更复杂的算法来达到更好的排序效果。简而言之,性能越高,改进的空间就越大。
除了最基本的倒排索引,架构上还有很多可以优化的地方。例如历史数据的批量反演和新数据或更新数据的实时反演的设计,然后是标题和正文等不同重要性的字段的处理,反演的压缩,快速合并算法,灵活的多机划分环形架构等等,这些都是一个好的搜索架构需要考虑的问题。一个好的架构的设计也源于对搜索任务的足够深入的理解。没有多年打磨搜索,优秀的架构师不可能设计出完美的搜索架构。
这很冗长。综上所述,知乎search 体验并不理想,问题很多,但这些问题绝不是知乎唯一的问题,也不仅仅是人力投资的问题。搜索一个极其复杂的系统,好的搜索体验需要技术的沉淀和积累,需要海量数据特别是海量用户行为数据的支持。现场搜索是基于它在搜索方向上的积累和它可以访问的数据。对于知乎这样高标准、严要求的用户来说,要达到用户满意并不容易。
当然可以解决所有问题~~