为什么知乎的搜索功能如此之烂？

看来需要修改提问了....最近感觉社区搜索正常多了.....感谢回答
每次要搜索东西都要找好久，明明刚刚看过的东西搜索就搜索不出来。技术和运作方面都有什么原因呢？

有关回应 · 2021-5-23 19:37:42

谢邀！（潜水员终于有可以专业回答的问题了）
利益相关：搜狗搜索工程师，对搜索技术「略懂」
搜索是技术方向辐射相当广的一个复杂系统，其技术门槛之高，在众多的互联网产品中能与搜索比肩的是少之又少。要想玩转这套系统，拥有一批最优秀且懂搜索的工程师和研究员是必不可少的。我看到之前 @熊辰炎  同学也提到说想解决的话，社区可能需要5个熟练工干大半年。在我看来，这种团队配置作为站内搜索差不多能解决大部分基础问题，即达到不被“到处”抱怨。但如果要求再高一点点，能稍”智能”地处理用户查询，那么这种团队配置恐怕还是望成莫及。
当然搜索也绝不仅仅是一个人力问题，支撑搜索的人工智能技术正在”经验主义”(以统计学为代表)的道路上享受着大数据（特别是用户行为数据）的红利。从一个特定站点出发，即使是一个格调高、深受用户喜爱的站点，其能够接触到的数据无论是用户群体行为数据还是全网的信息资源都是十分有限的。用户对于全网通用搜索和站内搜索的期望的差别仅在于搜索范围从全网变为这个特定站点，但搜索用户天生的”懒惰”、表达含糊以及对搜索结果智能的期待从未改变过。而且由于用户对他所喜爱的站点的了解、熟悉程度远远超出其对全网的了解，所以用户对搜索服务所存在的各种问题更为敏感，从而也有更高的要求。正是这种数据局限所带来的技术水平局限与用户需求之间的矛盾，使得原生站内搜索注定就是一件不太可能成功的路。
扯远了，回到作为一个技术人员解释为什么社区站内搜索没有通用搜索(例如百度、搜狗)的site查询好用吧。
@张前川关于搜索效果的评测解释得已经比较完善了，下面我就以这几个case为例解释一下通用搜索是如何解决背后的技术问题吧。主要分为NLP/相关性计算/排序这几个方面。
1.    NLP
1.1 分词(Word Segmentation)
搜索中的分词是指将文本切成多个独立的语义单元以作为检索的最小单元，然后分词后的词串建立倒排索引以加快检索服务的速度。这是信息检索最基本最重要的架构，这里不详细展开。
先看看张前川提到的“避谷”这个case，正如张前川所说，避谷应该切成一个独立的词。为了解释后面的算法，我把case改成“避谷方法”，更容易说明问题，它的正确切词方法是【避谷】【方法】。如果把避谷分成【避】【谷】两个单字，就容易出现社区站内搜索这种【避】【谷】两字分开出现的结果，也是我们常说的结果发生语义漂移。那么如何知道【避谷】应该是个独立的词呢？
最经典的分词方法有基于词典的前向/后向最大匹配或基于语言模型的分词等等，其中如何构建准确而全的词典，用什么语料统计适用的语言模型都是算法成功的关键所在。
问: 通用搜索如何解决这个问题呢？
答：挖掘网络语料或用户行为数据！
a.    对于基于词典的方法，由于“避谷”是个道家的一个术语，有可能分词词典里不包含这个词。那么通用搜索通常可以通过挖掘网络语料（例如百科词条）来补充词典。
b.    对于语言模型或其他统计方法，用户群体历史的行为数据就是一种非常有价值的数据。这里仅提一个思路。历史上搜索“避谷方法”的用户，所点击结果的标题中“避”与“谷”很大概率彼此紧邻，“方“法”很大概率紧邻，而“谷“与”方法”很小概率紧邻。由此可以推断【避谷】【方法】应该相互连接组成一个词，而“避谷”与”方法”之间切分开来更合适。利用用户历史行为数据的方法还有很多，大家也可以打开思路。
1.2 查询纠错(Query Correction)
      再看“什么名字haoting“这个case，非常直观，大家都能看出来是用户把查询词的一部分敲成拼音了，需要系统自动纠错。当然这是个简单的纠错，只要找到haoting对应的上下文语言模型概率最大的汉字“好听”即可纠正过来。
有些需要纠错的case就不那么容易了。例如“哦泡手机”，原意是找“oppo手机。”人脑能够非常快速准确的完成这一个纠错过程，但对于不具备智慧的机器，这个转换过程并不那么容易。针对这个case算法纠错的过程大致应该是这样：首先把”哦泡”转换成拼音“opao“，然后计算“opao”和“oppo”之间的编辑距离（一种度量文本串之间相似程度的方法），然后通过多种数据和模型计算出来“哦泡”纠错成“oppo”的概率，特别是在上下文为“手机”的条件下“哦泡”纠错成“oppo”的概率。这里面的每个步骤都同时需要算法与数据的支撑，通用搜索面对更多的数据和更更多的用户，显然有非常大的优势。
1.3 查询理解(Query Understanding)
查询理解这个概念比较广，广义上前面提到的分词、查询纠错也可以纳入查询理解的范畴，这里我们主要用查询理解来概括查询改写、词间紧密度、词赋权等一系列的对查询的理解以帮助获得更好的搜索结果。前川前面给出的“101大厦”就是一个比较综合的例子，但是这个case我有些不同看法。
首先“101大厦”合在一起表示一个完整语义的实体，所以相关的结果中101和大厦应该紧邻在一起。前川说应该分成一个词，但出于搜索查全率的考虑，即尽可能找到更多的相关结果，它们还是分开比较好，因为“101大厦”还有很多种其他的叫法，例如“台北101””101大楼”等等。挖掘出101大厦的这些等价(或同义)说法对于搜索效果至关重要。这种等价或同义的算法用在搜索中就是查询改写一种最常见的形式。
但是“101”和“大楼”之间又存在非常紧密的关系，两者如果在文档中相距太远，结果通常是不相关的。这里涉及的是另一个概念——紧密度，即既需要切成两个独立的词，但又要求结果中这两个词之间的距离足够近，某些情况要求一定紧邻。
查询改写、紧密度同样依赖于网络资源的挖掘以及历史用户行为的挖掘，例如用户在同一个session内的主动改写、用户查询后的点击、具有相似点击结果的多个query等等…每种数据的合理应用，都能让搜索效果有所提升。通用搜索正是利用其数千亿网页索引库以及每日数亿次的用户查询及后续行为，在大数据上逐渐积累对查询理解的智慧。这些恐怕任何一个站点都无法触及的。
2.    相关性(relevance)
前面提到的都是NLP相关内容，我们再来看看搜索里另一个核心技术—相关性计算。相关性计算通常指给定一个查询和一篇文档，计算两者是否语义相关。语义相关是个非常大的挑战，从技术的发展历程来看，从早期的统计词出现的频率，例如tf.idf、BM25、到language model、proximity等等都试图从查询词在文档中出现的次数、位置、词的权重、文档的长度等等多个角度去估计查询与文档之间的相关度。近来在深度学习的影响下，基于深层神经网络的词嵌入、语义表示、语义匹配等新兴技术的涌现，正在带领相关性计算由匹配统计迈入“语义计算”的大门。搜狗、百度已经在这这方面取得了阶段性的成功，同时这个方向还有很多问题待解决，让我们拭目以待吧。
就前川提到的“为什么要来北京”这个case，可以从多个角度解决。例如通过查询理解，我们可以知道“北京”在这个查询中是个非常重要的词，而标题包含重要的词的文档相比于仅正文包含重要词的文档中有更大概率与查询词先关。前川提到的第二条结果不相关，”北京”即仅仅出现正文里。解决这个问题的思路还有很多，要想做个搜索，需要从多个维度去阐述查询与文档之间的关系，这是一项需要相当深积累的工作。
3.    排序（ranking）
排序，望文生义即将搜索结果按照满足用户需求的程度从高到低排序，以便最满足用户需求的结果能够排在搜索结果列表的最前面，让用户能够最先浏览到。排序主要涉及两大问题：用于排序的多维特征以及多维特征的融合以决定最终的顺序。
相关性无疑是搜索排序的一类非常重要的纬度，我们前面也提到相关性自身也需要从多个更细纬度去剖析。正如很多用户提到的，社区是问答社区，有人提问、有人回答、还有人点赞、关注，为什么社区返回的结果很多都零回答、零关注。其实问题的回答数、关注数、点赞数都是衡量一个文档质量非常客观的指标，这些对于衡量问题是否能够满足用户需求都是非常有价值的，也就是说这些都应该成为排序所考虑的特征。
那么这么多特征相互如何融合来决定最终的顺序呢？有很多基于规则或线性融合的方法，近年来排序学习(Learning to Rank)的方法已经无数次在各种竞赛、学术论文、工业界产品中将排序多特征的融合的结果带入或逼近局部最优解或全局最优解。
无论是排序特征的准确与丰富还是排序融合，都是搜索工程师们孜孜不倦地不断优化的方向，经验与积累也是非常重要的。
4.    搜索架构
张前川提到了搜索性能与稳定性问题，足以证明他确实是搜索的专业人士。呵呵。大部分用户会认为搜索效果和搜索性能没有什么关系，但实际上两者是紧密联系在一起的。由于服务负载的压力、用户响应时间的限制，分给每次用户查询的计算资源和时间是非常有限的。底层的检索的性能越好，所能查找的候选文档越多，所留给排序优化的时间越多，越能使用更丰富的特征和更复杂的算法，达到更好的排序效果。简而言之，性能越高，效果提升空间越大。
除了最基本的倒排索引，架构上还有很多可以优化的点。例如对历史数据的批量倒排和针对新数据或更新数据的实时倒排的设计，其次针对标题、正文等重要度不同字段的处理、倒排的压缩，快速交并算法、灵活的多机分环架构等等这些都是一个好的搜索架构需要考虑的问题。而好的架构的设计也是来源于对于搜索这个任务足够深刻的理解，如果没有对搜索多年的打磨，一名再优秀的架构师也是不可能设计出一套完美的搜索架构的。
啰嗦很多，总结一下，社区搜索体验不理想，存在多种问题，但这些问题绝不是社区仅有的问题，也不仅仅是人力投入的问题。搜索一个异常复杂的系统，好的搜索体验需要技术的沉淀与积累，需要海量数据特别是海量用户行为数据的支撑。站内搜索就于其在搜索方向的积累、其能接触到的数据，像社区这样面对高标准严要求的用户，注定不易做到用户满意。
当然凡是问题，是都能够被解决的~~

有关回应 · 2021-5-23 19:37:43

来，一并说了吧

问：搜索哪里差
1.关键字占百分之九十都搜不出来
2.搜索一个内容，首页的问题大多都是零答零关注，这样的搜出来有什么用？
3.搜索出来的内容不能按相关度/热度/时间/质量排序，我也不知道社区是怎么排序的

问：搜索为什么这么差
答：不知道

问：社区不改进的话俺们怎么办呢
1.用百度/谷歌搜索“想要的内容+社区”
1.百度谷歌『关键词 SITE:http://zhihu.com』
2.搜索相关话题，在话题下看精品答案
3.给黄鸡心发私信骂一顿出气，再改用百度搜索

问：社区客户端收到新评论要跋山涉水才能看到，大家都是这样吗？
答：是的大家都这样，如果该回答热度高，可以考虑关掉评论，或者用电脑登录查看，可定位

问：为什么自己的匿名回答一旦发布就再也找不到了？
答：是的，社区没有给用户的匿名回答建立索引。

问：那怎么找到自己的匿名回答？
1.你可以开启新赞同/感谢提示，这样有人给你的匿名回答点赞，你就可以再见它一面。
2.回答了问题，就会自动关注该话题，匿名也关注，如果你没有取消关注，就可以去关注话题下寻找你的回答。
3.建立一个私密收藏夹，收藏自己的匿名回答。随时可看。

问：为什么有时候自己的动态里会显示自己关注了一些奇奇怪怪的问题？
答：可能你邀请过别人回答此问题，社区感觉你对这个问题感兴趣，因此关注了。但是现在好像没有了。

问：为什么时间线首页经常会重复出现几天前别人的答题？
答：这是新版首页的特点，以免你错过以前的精彩回答。可以在设置中关闭。

问：时间线首页全被话题新问题占领了啊！看不见关注的大v的新回答了怎么办？
答：这是新版首页的特点。你可以选择取消关注一部分话题，也可以在设置中关闭新版首页。

问：手机客户端编辑新回答时，手一滑就退出了，怎么办？
答：联网情况下，可以在草稿中找到未发表的内容。只是空格不见了。

问：用手机客户端编辑回答时，手一滑退出了，再进去发现新编辑的内容不见了！怎么回事？
答：是的，我碰见过很多次，建议在电脑上修改，或者养成在手机便签或者印象笔记上编写回答和修改回答的习惯。再直接复制粘贴发表。

想到别的再补充。

有关回应 · 2021-5-23 19:37:44

相关利益：社区基础产品负责人。目前社区搜索是我的主要工作。（承认这点需要勇气。）

第一部分，回答「是不是」

尽管指向「社区搜索结果很烂」的个案事实可以看到很多，但个案再多也难以得到整体结论。回答「是不是」的问题，我们仍需要想办法得到一个全面的、定量的结论。

目前，整体衡量搜索服务的效果好坏，或者说相对客观的比较任意两个搜索服务，搜索行业中有很多种量化衡量搜索结果的办法，其中使用最广泛的两种是「DCG 评测」和「SBS 感知评测」。参考：搜索引擎评价体系应该分几个方面？建立怎样的指标？ - 搜索引擎优化（SEO）前者重点考察单条结果的位置和需求满足度。即：最好的结果是否被搜索出，是否排前。后者作为「DCG 评测」的补充，把搜索结果页看成一个整体，除了同样考察单条相关性之外，额外考察结果综合体验、展现丰富度、多样性等结果展现及结果页配合等整体效果。作为对这个问题的回答，我们选取相对适合社区搜索现状的「DCG评测」。

让我们一起看一看，社区搜索在 DCG 评测中的表现。

样本：不去重随机抽取社区问答搜索词 200 个。

打分标准：
对每条结果逐个采用 0~3 分 4 档打分：

3 能基本满足用户需求或回答内容对该次搜索用户有非常高的信息价值。
2 能满足用户部分需求或回答内容对该次搜索用户有较高的信息价值。
1 只可能满足少数特定用户需求或回答内容对该次搜索用户可能有一定信息价值。
0 不相关，不满足需求，对该次搜索用户没有帮助。

计算方法：
简化版 DCG 算法，对前列结果得分位置加权，综合计算总分。1 分为绝对满分。

评测结论：
社区搜索得分： 0.39
主流搜索平均得分： 0.63
（主流搜索平均得分：对多个主流通用搜索，用SITE语法，不去重筛选出问答网页）

所以最后，「烂不烂」这个问题的结论是：——是的，真是很烂。

从这个结论来看，大家对于社区搜索功能「如此之烂」的评价都非常中肯。而且，确实如大家所说的，在通用搜索使用SITE语法的搜索效果更好。（群众的眼光雪亮雪亮的）

亲爱的社区用户们，对不起！

第二部分，回答「为什么烂」

通过评测看到的具体问题，我们归纳了导致搜索效果烂的几类原因：

问题 1，自然语言处理（NLP）类问题
CASE #1：避谷
「避谷」是一个独立词，居然在某些结果中被切分成「避」和「谷」。

CASE #2：101大厦
问题：前列无相关结果。切词、丢词、同义词问题。

「101 大厦」不可切分，
结果中需要含有 101，
「101 大厦」需要与「台北 101 大楼」作为同义词或自动纠错映射。

CASE #3：什么名字haoting
问题：结果未正确纠错

问题 1 原因分析：
自然语言处理技术是一个难点，主要的问题是：

各种大规模语料库的持续积累和建设。分词、同义词、纠错、丢词等等。
根据具体场景和效果，持续优化的处理算法和策略。

对比通用搜索引擎，相对年轻的社区在这方面的积累还是明显不够的，对全网语料数据的收集也不是强项。因此，不可避免时不时总会看到一些让人无语的烂结果。

问题 2，排序算法类问题
CASE #4：新股
问题：零回答结果排序过于靠前

CASE #5：机油多少里程换一次
问题：1、前列多条命中0赞同回答。2、轮船、摩托车并不是查询主需求。

CASE #6：为什么要来北京
问题：第二条结果标题不包含北京，而是法国

问题 2 原因分析：
搜索结果通过「权重」排序。权重一般由两部分组成。

一部分与「用户输入的搜索词」有关。

比如通常，完全匹配用户搜索词的结果，得分比部分匹配的要高。搜索词中每一个词语的权重也是不同的，重要词语的权重更高，例如「为什么要来北京」中「北京」比「为什么」重要。

另一部分与「用户输入的搜索词匹配」基础上，与社区特点相结合。

比如通常，一个 1000 字，482 赞同的结果，得分天然比一个 20 字 0 赞同的结果要高。
好的搜索可以很好的平衡二者，给出理想的整体排序权重。而社区搜索目前的排序算法本身仍然存在不足，在两种权重因子的计算上都有一些问题。
尤其是第二部分，尽管社区拥有丰富的用户内容评价数据，到目前为止的权重策略很不理想，繁复冗余，没有最终取得应有的理想效果。
而问题3中的一些原因实际让这个问题雪上加霜，大幅恶化，导致了大量无答案或者无赞问题排序过于靠前的严重问题。

问题 3，性能和稳定性问题
目前社区平台的优质回答已经达到了千万量级，包括搜索请求量在内的所有访问指标都取得了超预期增长。
这种迅猛增长的情况极大考验了按照之前数据规模和请求规模设计的整体搜索系统。众多的权重因子随着规模增加复杂度大幅提升，短期内性能和稳定性成为很大问题。所以最近一段时间为了保证对每次搜索请求都能正常返回结果，我们不得不对权重算法做了简化，这也就部分导致了问题2中结果权重出现的问题。
「社区的搜索功能如此之烂」的背后的技术原因分析大概就是这些。
综上，确实没有做好。所以「被骂也是应该的」。

第三部分，我们为什么没有接入 SITE（通用引擎的站内搜索）

尽管线上问题很多，解决起来也不容易，但考虑从社区搜索能到达的理想状态，我们仍然不甘心简单接入一个 SITE 语法搭建的站内搜索了事。
一个重要原因是，社区搜索是贯穿整个社区平台的重要基础功能。用户在提问时用到，在找人时用到，在邀请回答时用到，在引用答案和公共编辑时也都会用到。搜索对于整个产品的效率都有很大影响。
另外一个重要的原因是：社区的内容不仅仅是一个个网页。社区上用户与内容之间丰富的互动信息可以帮助搜索引擎识别哪些内容更为重要，数据富集度和准确度远远高于「PageRank」，同时，社区的内容天然有人的属性，而这应该被用来满足社区特有的搜索需求。比如：

个性化
与你相关的内容可以有更好的排序，你曾看过的、点过赞同反对的、关注过的话题里的内容等，搜起来应该更容易。

社会化
你关注的圈子中用户的赞同、反对、感谢和评论可以更好的帮助你定位你找的内容。

通用引擎的站内搜索确实能简单快速解决目前很多的搜索痛点问题。但对社区来说它是没有生命力，或者说提高空间非常有限的。我们希望社区上的内容能被更好的搜索，社区独有的用户需求能被更好的满足，所以我们并没有选择这个明显更为容易，也是一部分网友建议的方案。

第四部分，我们正在做什么

是的，我们正在酝酿一次搜索改进，针对上面提到的问题，期望能一次性解决大部分。它将是社区搜索一次比较大的变动，除了使用量最大的问答搜索之外，用户和话题搜索也在改进范围之内。

当然，新的搜索只是一个起点，它一开始只是解决了上面提到的搜索效果问题，界面和功能不会发生任何变化，只是搜索效果会变好一些。但我们希望它会在逐步发展中，对社区内容和社区用户的理解更充分，也更为灵活，逐渐明显不同与「SITE 语法搜索」的效果，让社区用户用起来会更爽。

一切顺利的话，新搜索很快会与大家见面。希望各位届时能再次试用。同时，也恳请知友们继续多多通过回答、评论或私信向我反馈你遇到的效果不好的搜索词，这对我们正在进行中的搜索效果整体改进帮助很大。

-----------------------------更新分隔线-------------------------
新搜索效果已上线，参考：这不是文本框，是搜索框 - 社区产品专栏 - 社区专栏
希望大家继续多多关注和吐槽社区搜索，谢谢！

有关回应 · 2021-5-23 19:37:45

因为贵: ) 要做到效果不被骂，几百万砸下去才能看见些成效吧。

会做搜索的工程师很贵的。能够带搜索团队的leader更贵。
要想做到过得去，不被到处抱怨，起码要5个熟练工干大半年。
按照4人年工时，每人年的人力成本往低了算按照50万（对应25万左右年薪），那也是两百万打底。

这还没算对应的PM和测试的成本。人力成本也算的非常低，在北京这个价格便宜的没有道理了，社区如果能够按照这个价格招到这个水平的开发估计老板们做梦都笑醒了... 且不要说这种人不好说，基本也就只能去百度和360搜索挖了，核心工程师在两家都是宝贝，我觉得如果最后整个团队一个人的一年成本能控制在70-80万就算是成功。

得，这么一算奔着500万去了，这样还只是搜索效果过得去不被骂，对社区的核心业务帮助短期来看大概可以忽略吧... 比起提搜索效果，社区在技术上优先级更高的项目多了去了...

所以还是洗洗睡，安心用Baidu/Google的站内搜索吧...

有关回应 · 2021-5-23 19:37:46

看到这个问题下的2.2K关注，社区社区老总小周不禁冷笑了一声:妈的，这个月的活跃度KPI考核压力又轻了。

两分钟后，社区搜索负责人接到了来自小周的电话:“小王，听说你们组来了个搜索技术大神？”

小王顿时喜上眉梢，刚挖来的新手没想到这么快就被领导知道了，这是要升职加薪的节奏啊。

然而还没等小王邀功，电话那头传来了怒吼声:“赶紧让他滚！你他妈还想不想干了？老子花钱请你不是让你来认真写代码的！”

小王仰头看了看窗外，两滴眼泪无力的流了下来，本来搜索组在社区已经是地位最低的组了，现在……

滴答滴答五分钟又过去了，小周想了想又拨通了社区hr的电话:“小陈，谁他妈让你给搜索组加薪的？！！！”

“可是产品组的员工最低工资都是搜索组工资最高员工2倍多了，我不过给搜索组每人加了10元钱每年而已……”小陈嗫嚅道。

“老子花钱不是让他们来好好写代码的！”

……

又是五年过去了，社区早已成为互联网最活跃的社区，没有之一。

同时，社区旗下社区商城，社区贴吧，社区飞车，社区CF等在同类中已成为数一数二的领先者。

纳斯达克庆功会上，面对各色记者的采访，社区老总小周一把搂住了搜索组负责人小王感慨道:“这都是小王的功劳啊！！！”

想起了昨天在社区搜索输入“周源”两字，却弹出了“李彦宏”的个人介绍，众人纷纷向小王竖起了大拇。

小王终于痛苦的大声哭出声来……

完。

为什么知乎的搜索功能如此之烂？

5 个回复