如何从0到1搭建站内搜索？

许珂诚 2023-07-24 06:30:22

一、为什么要做站内搜索

对于一个单独的内容站来说，搜索其实不算是用户的常用功能，因为在绝大部分情况下，用户会更加偏向于询问他人，也就是传说中的伸手党。当无法从他人获取自己想要的内容时，用户才会倾向于去找进行搜索这个动作，而这个动作的发生环境通常也不是在一个单独的内容站内，更多地会更偏向使用 Google、百度等搜索引擎。

站在用户的角度，这样做当然是更有意义的，能够用较低的成本增加找到自己想要内容的几率。但是与此同时，一个单独的内容站为什么还需要自己做搜索呢？

1. 让用户尽可能少地离开网站去获取信息

如果让用户都去通过搜索引擎获取本站信息，用户搜索关键词的结果排序里，你的网站不一定能够进入第一页内。我们其实也都知道让搜索引擎去获取本站信息得以被搜索的初衷，不是去维护现有用户，而是希望获得更多精准用户。

所以，站内搜索的主要目的是提高用户使用本站的深度，获取用户搜索关键词数据等。不过这部分需要时间去积累。

2. 部分网站不开放数据

有些网站由于业务上、战略上等等原因，不会开放数据给搜索引擎使用，那么为了降低用户找到内容的成本，提供站内搜索就是必然的选择。

这种现象多出现于电商、O2O 等平台，同时也由于移动互联网的发展，入口和用户习惯的改变，导致信息孤岛急速扩张，更多的平台选择了只有部分开放甚至不开放数据。（现在也有巨头在尝试打破这个现象，比如说曾经的小米传送门，和现在的微信搜一搜）

3. 用户使用习惯的改变

这一部分其实前面已经提到了，当前使用互联网的第一大入口已经从浏览器等传统 PC 环境转向移动设备上的 App。呈现给用户的形式再也不是一连串不知所谓的网址，而是手机桌面上可见的、鲜艳的 App 图标，至于传统 PC 上用户用得很多的网站聚合页，也更多被各种 App Store 所替代。

当用户进入 App，呈现给他的就只有当前 App 的内容，这种情况下用户本能地会去选择使用 App 内的搜索。

不过做站内搜索也有一些需要说明的问题：

（1）开发成本相对较高

如果一旦要求高一点，希望做一个体验还过得去的站内搜索，涉及的东西就很多了，大体上可以分为：

每一部分都直接影响到最终的用户体验。

当然如果随便一点，或者内容复杂度低，MVP 试行等等，都可以考虑先直接用 SQL 去模糊查询。

搜索词处理（纠错、改写、分词等）
关键词和数据的匹配（标题匹配、内容匹配、生产者匹配以及权重）
排序（时间、相关性、数据类型）

（2）投入产出比相对较低

前面说到了开发成本较高，那么在开发完成之后，这个功能的使用率会是多少呢？搜索是一个主动行为，在没有额外机制和奖励的情况下，用户是被动的。同样的，除非是知网、淘宝、知乎这种平台，在绝大部分平台上，这项功能的使用频次必定不会太高。

这也属于那种重要但不紧急的任务，站内搜索对于一个网站的必要性就有点像是，手机上发短信的功能，用户可以不用，但是你不能没有。

（3）内容量问题

搜索不到内容是一个搜索功能使用的时候最尴尬的时候，尽管可以通过一些手段，比如说相似内容推荐、热门搜索推荐等等；但是不可否认的是，在正常情况下（用户搜索正常词句，且与平台相关）如果搜索不到内容，尽管做了这些处理，但依旧是没有彻底解决根本的用户效率问题。

所以，在做这个功能的时候，平台的内容量一定是必须要考虑的问题。

二、搜索：词、匹配、排序

在讲具体内容之前，需要给大家先介绍一下搜索引擎搜索方式—— Site。

这应该也算是大家都会经常用到的搜索技巧了，这种搜索方式其实完全可以理解成各大搜索引擎给网站提供的免费站内搜索。

那就有个问题出现了，为什么不去使用搜索引擎的 Site 方式作为网站的站内搜索呢？这样的网站其实是有一些的，比如说 V2EX。

用搜索引擎的站内搜索好处有很多，比如说开发成本极低，用户使用成本低，搜索精准度相对较高等等

但是坏处其实也有一些：

首先是排序，搜索引擎的排序算法是你无法干预的，这就导致无法提供业务上所需要的排序；比如说商品网站，搜索电饭煲，搜索引擎可能更偏向相关度、时间等等，但是其实在业务层面，销量、好评率等等也是非常重要的考量因素，而这些数据不说搜索引擎能不能纳入权重，就算能，那这些数据是否能够提供给第三方也是个问题
然后是网站类型不同导致的数据类型问题，资讯、问答、社区、商品等等类型的平台，所提供可供搜索的内容是完全不一样的，而现在搜索引擎很大程度并不能完全满足绝大部分的内容类型。
最后就是更新，目前想要让搜索引擎快速收录网站链接的方式中最主流的是站点地图，但是站点地图的最大问题就是更新不及时，也很难预测到什么时候会编入索引，什么时候会收录。

1. 搜索词处理

搜索词解析方式目前比较普遍一点的就是分词和纠错。

前者目前来讲，稍微好做一点。GitHub 上也要大量开源的分词框架库可以使用，同时也支持自定义。这一部分建议之后要好好收集一下用户的搜索词，看看分词出来的词语是否切合用户当时希望表达的意思。同时也要根据业务调整，比如说在电商平台搜索 ”智能电视“，不能结果出来只有 ”智能“ 和 ”电视“，”智能电视“ 这个词本身就应该也作为一个关键词存在。

后者难度稍微高一点，因为现在的纠错不在于说没有方法去做，而是在于说假如不契合业务，可能会导致一些奇怪的结果。

尤其是错误纠正方面（纠错的流程大体为错误字(词)识别 → 错误字(词)纠正）。不过错字(词)有时候确实会影响到分词效果，进一步影响到搜索的结果，所以这个还是有必要去做的，不过可以考虑用户量再大一些，数据更加丰富的时候去做会更好。

以及后面可以涉及到更加深入的用户搜索词预测，这个就更加复杂了，笔者也不了解，就不多说了。

2. 匹配

互联网上的能看到的内容都可以叫做数据，而绝大部分数据都会存在于数据库的一张一张表之中。匹配的根本就是将搜索词拿来去这些表里查找，找到合适的数据。

但是这样做效率太低了，为了提高效率和精准度，自然要规定一下搜索的范围，所以通常我们会对搜索进行分类处理，比如说这个关键词是搜索商品的，这个关键词是搜索文章的。

当然，让用户去选要搜什么分类已经是古早互联网时期的做法了，现在更加常见的做法是展示出所有的内容，但是分块展现，比如说知乎，综合下就带有话题、专栏、问题三种形式。

上面说的是匹配的范围，匹配还有另外一个重点就是匹配的覆盖面：

同一个类型的数据，比如说一篇文章，可能包括标题、作者、时间、内容、评论等等数据。那么你的匹配是要覆盖到哪些数据？标题？作者？时间？或者内容？

如果上面很多都想做匹配的话，那就叫多字段匹配或者多字段搜索，最简单的方式就是把多个字段组合起来建索引。

另外，如果说你还希望搜索匹配这篇文章的内容，而文章的内容通过都是很长的富文本或者文本形式，那么可能你还需要使用全文匹配来帮助你。

以上两种其实只是目前比较常见的搜索匹配方式，技术领域中有很多方法来解决这些问题，但是还是建议产品有时间可以多了解一下，可以更加理解技术的局限、边界和成本。

3. 排序

排序一般会根据相关度、内容用户相关数据、时间等等情况排序，比较依赖于业务属性。比如说新闻网站，时间维度的权重可能就会比较重；电商网站可能就比较看重销量、知名度、利润、优惠（比如说特定打折时期，将品类中让利较多的商品展现出来吸引用户）；内容网站可能还会涉及到用户是否读过，解决用户想凭借几个词找到之前度过的文章这个场景。

所以这部分很难说有什么标准的解法，视业务和用户群体而定。