返回 登录
0

每个软件工程师都应该了解的搜索技能

原文:What every software engineer should know about search
作者:Max Grigorev
翻译:Diwei

译者注:想要构建或改进搜索体验?从这里开始。以下为译文。

如果你问一名软件工程师:“如何给产品添加搜索功能?”或者“如何构建一个搜索引擎?”你可能会得到这样一个回答:“我们刚刚推出了ElasticSearch集群,以后再也不用担心构建搜索功能了。”

但真的是这样吗?许多现有产品仍然 很不友好的 搜索 体验。很多工程师对搜索引擎的工作原理知之甚微,而这些知识往往是提高搜索质量的必要条件。

尽管有很多的开源软件包,也有了很多的研究成果,但很少有介绍关于如何构建稳定搜索体验的文章。更讽刺的是,如果在网上搜索关于搜索技能的专业,得到的结果其实并不是自己想要的。

为什么要读这篇文章?

如果你想构建搜索功能,那么这篇文章会对你提供很大的帮助。当然,并不是说这篇文章会包含所有的内容,但我们会根据读者的反馈进行修改。

由于我有谷歌、Airbnb和几家初创公司的工作经验,因此我将基于这些经验介绍一些最受欢迎的方法、算法、技术和工具。

如果你不了解搜索相关的问题有多复杂,那么产品的用户体验也肯定很糟糕,这样不仅让之前的努力付出东流,产品还很有可能会失败。

如果你缺乏耐心或者已经了解了很多知识,那么可以直接浏览工具和服务部分。

关于哲学

这篇文章很长,但我们所涵盖的大部分内容都基于下面四个基本原则:

实际上搜索是一个综合问题:

  • 查询是可高度变化的。根据产品需求的不同,搜索问题也是不尽相同的。
  • 想想Facebook的不同搜索方式(搜索某位用户的图表)。
  • YouTube搜索(搜索个人视频)。
  • 这些搜索与Kayak有哪些不同的地方(航空旅行计划真的是个很棘手的问题)。
  • 谷歌地图(理解地理空间数据)。
  • Pinterest。

质量、度量和流程非常重要:

  • 根本就不存在什么魔法般的算法。因为流程总是在不断地促进很多技术的进化,从而满足解决各个方面的问题,并提高用户经验,通常是渐进的和持续的。
  • 换句话说,搜索不仅仅只是为某个特定领域构建排名检索(我们将在下面讨论)的软件。通常情况下搜索系统就像是一种不断变化的组件管道,随着时间的推移,它们会调整和演变,从而形成有凝聚力的体验。
  • 搜索成功的关键重点是在于建立评估和调整产品和开发周期的过程。搜索系统架构师应该考虑过程和度量,而不仅仅是技术

使用现有的技术:

  • 和大多数工程问题一样,不要自己闭门造车。在可能的情况下,使用现有的服务或开源工具。如果现有的SaaS(如Algolia或托管弹性搜索)符合约束条件,而你又有足够的经济能力能够负担得起,那么也可以使用它。即使是在需要定制、增强或考虑是否需要替换的情况下,在产品初期阶段,这种解决方案也有可能是最佳选择。

即使你买了,也需要了解细节:

  • 即使使用的是现有的开源或商业解决方案,你也应该对搜索问题的复杂性有一定的认识,并且需要知道哪里可能会出现陷阱。

理论:搜索问题

每款产品的搜索都不相同,而选择则需要依赖于需求的许多技术细节。它有助于识别搜索问题的关键参数:

  1. 大小:语料库(需要搜索的完整文档集)有多大?有成千上万个文件吗?
  2. 影像:用户是在搜索文本、图像、图形关系,还是地理空间数据?
  3. 语料库控制和质量:是你在控制的文档的来源,还是来自于(潜在的敌对)第三方?是否所有文档都准备好被索引或者需要清理和选择?
  4. 索引速度:需要实时索引吗?或者批量构建索引有没有问题?
  5. 查询语言:查询是否是结构化的,是否需要支持非结构化查询?
  6. 查询结构:是否是查询文本、图像、声音?还是街道地址,记录的身份证,人脸?
  7. 情境依赖:结果是否取决于用户是谁,他们的历史与产品,他们的地理位置,时间等?
  8. 建议支持:是否需要支持不完整的查询?
  9. 延迟:服务延迟需求是什么?100毫秒还是100秒?
  10. 访问控制:它是完全公开的,还是应该只看到文档的一个受限制的子集?
  11. 遵从性:是否有遵从性或组织限制?
  12. 国际化:是否需要支持具有多语言字符集或Unicode的文档?(提示:总是使用utf - 8,除非你真的知道你在做什么。)你需要支持多语种语料库吗?多语种查询呢?

通过这些点来思考,可以帮助你在设计和构建单个搜索系统组件时做出重要的选择。


生产索引管道。

理论:搜索管道

现在让我们看一遍搜索子问题列表。这些通常由形成管道的独立子系统来解决。这意味着一个给定的子系统将消耗以前子系统的输出,并为下列子系统生成输入。

这导致了生态系统的一个重要特性:一旦你改变了上游子系统的工作方式,你就需要评估变化的影响,并可能改变下游的行为。

下面是你需要解决的最重要的问题:

索引选择:

给定一组文档(例如,整个Internet,所有的Twitter帖子,Instagram上的所有图片),选择一个可能更小的文档子集,作为搜索结果可能值得考虑,并且只包括索引中的那些,丢弃其余部分。这样做是为了使索引紧凑,而且几乎是正交的,以选择要显示给用户的文档。一些特殊类别的文件没有被削减可能包括:

垃圾处理:

哦,所有不同的形状和大小的搜索垃圾邮件!一个巨大的主题本身,值得单独的指导。一个好的网络垃圾分类概述

不受欢迎的文档:

域约束可能需要过滤:色情、非法内容等。这些技术类似于垃圾邮件过滤,可能需要额外的启发式。

重复的:

或接近重复的文件。可以通过本地敏感的散列相似度度量、聚类技术甚至是clickthrough数据完成。一个很好的技术概述

较低的文档:

效用的定义在很大程度上依赖于问题领域,因此很难推荐这里的方法。有些想法是:可能为您的文档构建一个实用程序函数;heuristics可能起作用,或者例如一个只包含黑色像素的图像不是一个有用的文档;实用程序可以从用户行为中学习。

索引结构:

对于大多数搜索系统,文档检索是使用反向索引执行的——通常称为索引。

所以我到底应该怎么做呢?

这篇文章并不是一篇教程,但是如果你想现在就构建一个搜索体验,这里倒是有一个简短的概述:

  1. 正如上面所说的,如果你有一定的经济基础,可以选择购买现成的SaaS(下面列举了一些评价不错的)。现有的服务适用于:

    • 你的经验是一个“连接”一个(你的服务或应用有互联网连接)。

    • 它是否支持您需要的所有功能?这篇文章很好地阐述了你想要什么样的功能。举几个例子,我至少要考虑一下:支持你正在搜索的媒体;实时索引支持;查询灵活性,包括上下文相关的查询。

    • 考虑到语料库的大小和预期的QpS,你能负担得起未来12个月的费用吗?

    • 服务是否能够支持预期的流量,在所需的延迟范围内?如果您正在从应用程序查询服务,请确保给定的服务能够快速访问您的用户所在的位置。

  2. 如果托管解决方案不适合您的需求或资源,您可能需要使用一个开源库或工具。如果有联网的应用程序或网站,我现在就选择弹性搜索。对于嵌入式体验,下面有多种工具。

  3. 在将文档上传到搜索索引之前,您可能需要做索引选择并清理文档(比如从HTML页面中提取相关文本)。这将降低索引的大小,并使得到好的结果更容易。如果您的语料库适合于一台机器,那么只需编写一个脚本(或者几个)来完成它。如果不是,我会用Spark

图片描述
2017年10月14日,SDCC 2017之大数据技术实战线上峰会即将召开,邀请圈内顶尖的布道师、技术专家和技术引领者,共话大数据平台构建、优化提升大数据平台的各项性能、Spark部署实践、企业流平台实践、以及实现应用大数据支持业务创新发展等核心话题,七位大牛与你相聚狂欢,详情查看所有嘉宾和议题,以及注册参会,分享还可优惠30元。

评论