专访豌豆荚搜索技术负责人：应用内搜索——移动时代的搜索技术

在传统互联网时代，以 Google 为代表的搜索引擎，通过对网页建立索引，并以搜索结果的形式将其展现到用户面前，实现了信息的关联。而在移动互联网时代，各个 App 成了信息的孤岛，很难将其关联起来。豌豆荚的应用内搜索技术在这方面做了很好的尝试。

什么是应用内搜索呢？官方的解释如下。

移动时代，用户所需的丰富内容存在于海量的应用之中。豌豆荚通过「应用内搜索」技术打通应用，索引其中的各类内容直接展现给用户，并且引导用户直接调起应用来消费这些内容。「应用内搜索」技术不仅让用户享受到无缝的内容消费体验，更让开发者通过内容直接获得持续的流量和用户。

InfoQ 就该技术及相关产品采访了豌豆荚搜索技术负责人李大海和豌豆荚技术经理杨涛。

李大海，豌豆荚搜索技术负责人。负责应用内搜索技术的商业化和产品化。像最近推出的豌豆荚一览，就是产品化的一个具体体现。

杨涛，豌豆荚技术经理。主要负责“豌豆荚一览”后端工程，应用内搜索工程，包括具体的数据接入和数据理解等。

本文即根据采访内容整理而成。

演进过程：从提出应用内搜索到产品化

豌豆荚的应用内搜索从去年提出，到现在推出“豌豆荚一览”这样的产品，我们可以从技术和产品两个方面看一下其演进过程。

首先从技术角度看。去年，豌豆荚的研发团队首先拟出了应用内搜索的技术协议，然后基于这个技术协议接入了一些合作伙伴的内容。在他们的配合之下，这些内容被应用到豌豆荚主产品里面，比如跟猫眼做的电影票，再比如可以直接搜到知乎的问答，还有具体场景底下的一些用例。

今年，研发团队调整了具体的执行策略，但觉得还是不够快，所以又探索了一些新的方式。仍然是原来的那一套协议，但是不用开发者进来，不用他们配合，而是自己做最快的数据接入的工作。这是今年的改变。这主要是从效率方面考虑的：需要开发者来配合的话，要考虑开发者的响应时间，来来回回去沟通协议具体是什么样的，可能一个来回就是一个星期，有两三个来回一个月就过去了。其他的方向都是一样的，接入的内容还是会跟开发者沟通，一定是他们愿意接入的东西。

进展确实很明显，改变了策略之后，目前已经接入了500 家左右的应用内容。

还有一个很重要的事情，豌豆荚有一个很重要的、叫做 Chana （刹那）的技术，集成到了一览里面。Chana 是豌豆荚的邓草原老师基于 Akka 开发的一个实时计算框架，是用 Scala 语言编写的。研发团队在底层做了应用内搜索的架构升级，包括把这样一个实时性和扩展性都很棒的实时计算平台引入进来，以及对于底层的 Storm 等平台的升级，这些可能是用户看不见的，但是能很大地扩展数据处理能力。

再从产品角度看。产品方面也很清楚，在去年一开始的时候，研发团队主要是在豌豆荚的主产品里做了很多创新的探索，看一下如何将提供给用户的价值最大化。今年又有了更进一步的全新的探索，基于应用内搜索技术，推出了“豌豆荚一览”和“ Snap 效率锁屏”这样的产品。研发团队也在产品中加了很多的应用场景，比如用户购买了电影票，可以很快地告诉用户，你的电影马上开始了，可以选择打车过去，或是附近有什么好的餐厅，这些都是通过应用内搜索的技术把服务和内容跟用户当前的产品结合在一起的具体例子。这两个产品也是豌豆荚在应用内搜索产品化上给出的阶段性答案。

协议：应用内搜索的基石

在刚开始的时候，研发团队会把每一个门类特别细节的东西都定义得很清楚，在接入的时候希望接入的内容在每个门类下，这些字段都应该很清楚再接入，这样效率会比较低，现在会倾向于尽可能结构化，一些不能结构化的东西先把它半结构化地拿进来。这样达到一个效率和最结构化的信息和将来结构化信息的利用有一个平衡。

另外，研发团队也在不断地做一些细节的优化。像前面提到的今年的变化，不再需要开发者主动的配合，所以内部要考虑怎么能够把各种各样不同的、千奇百怪的应用内容跟协议搭进来。说得通俗一点，是怎么样才能够更聪明地去做适配，怎么样才能更智能化地提高适配效率，在这方面做了很多工作。这个工作可能不是重新制定协议，而是对协议进行一些简单的升级，让它能够普适性做得更好。

这里还要提一下 Deep Link。之所以有这个概念，是因为移动互联网发展起来，原来那套基于 HTTP、超链接实现互联互通的互联网被割成了以应用为中心的信息孤岛。要解决这个痛点，所以很多厂商纷纷提出了自家的 Deep Link，但是目前还没有一个事实上的行业标准。比如说谷歌做了一个 App Indexing ，Facebook 做了一个 App Links ，大家的协议都会有或多或少的差异。目前看来，Facebook 的协议因为考虑得更全面一些，所以成为事实标准的可能性会更大。但不管怎么样，这个格局还是很纷乱的，大家更多是从自己的应用场景、自己的应用需求出发，制定这样的一套一套的规则。

豌豆荚去年做这件事的时候，更多是从自己和用户的角度去考虑这件事情，主要是从三个点来考虑，一是普适性，二是经济性，三是实时性。先看普适性，豌豆荚做这件事情的时候，市面上已经有谷歌和 Quixey 的两种协议，所以想兼容这两种协议。如果开发者支持这两种协议，可以直接接入进来。再看经济性，豌豆荚采用的方案都是 Microdata 这种很成熟的技术方案，开发者可以很快地、比较容易地通过这些技术提交内容。最后看实时性，对于豌豆荚接入的应用内容，如果在手机上看到一个内容，它能够更快地触达用户，还是很重要的。所以开发者可以通过实时 API，快速提交内容。当时整个协议的思路主要是从这三个点出发。

在应用调起方面，国内的开发者其实对调起支持都不是特别友好，有一个效率比较高的方法，先去看开发者到底对调起的支持怎么样，对于支持好的会在产品里直接调起应用去打开这个页面，如果不行的话，则会调起 H5 页面。如果所有的开发商和厂商都能够更重视调起这一块，能够把 Deep Link 这一块做得更好，将来有希望做到应用里面的每一个页面都能够被标准的调起，这样以后应用内搜索可以做成跟网页搜索一样。不过这是下一步要做的工作，当前还不是最重要的。最重要的是先让用户看到这里的价值，用户喜欢用，反过来开发者就会看到里面的价值。

应用内搜索与传统互联网搜索之比较

应用内搜索和传统的互联网搜索还是有一些关系的。

架构上来说，跟传统的搜索是差不多的，但是从现在的索引的量来说，比不上传统的搜索这么大。移动互联网这一块，可能还有一些不同，与传统互联网搜索相比，它需要一个结构化更好的数据。

整个搜索这件事情本身从逻辑来讲分成几段，数据的获取、数据的加工、数据的呈现。这对于传统的网页搜索和移动搜索都是大同小异的。再有移动互联网时代面临几个比较大的困难，因为它不互联互通，没有超链，没有超链就缺少了投票机制，所以 PageRank 就行不通，PageRank 在谷歌是非常重要的做排序的东西。没有这个东西，一旦要做非常通用的移动互联网的搜索，排序就需要找其他东西来代替，需要一个其他可靠的信息来做代替，现在还在寻找。在移动互联网方面，很多不同的门类都是结构化的，都是异构的。商品、图书和电影的结构都不一样，搜一个关键词的时候要把一些不同结构的东西混合排序，这个事情其实也是一个挺有挑战的事情。而以前都是网页，东西都是文字的。

像网页搜索，一般会根据 PageRank 排序，而应用内搜索考虑的因素有很多，举个具体的例子，比如做视频的收录时，考虑的因素有用户的情况，比如用户安装的哪一个应用，安装的是腾讯视频还是爱奇艺，如果某一个片子两个都有，用户只安装其中一个，排名肯定是选择用户安装的那个。再有就是，有一些视频可能其他人是盗播的，就不能选择它，再就是选择码率。各个方面的因素是综合考虑的，并没有说哪一个是最重要的。

从技术角度讲，豌豆荚的应用内搜索也有一个平台一样的东西，跟全网的搜索引擎的架构差不多，包括爬虫和解析、数据流水线、索引、检索一整套。

团队：小而美

应用内搜索方面，豌豆荚一直保持着一个小而精的工程团队，工程人员一直没有特别大的增长，但是工程师搭配比较合理，有搜索领域的专家，也有工程能力很强的软件工程师，还有很有创新精神、勇于探索的年轻人。另外，这个团队的工作也并不是完全自成一套，不是说完全从头开始做的，也会用到很多外界成熟的第三方开源软件。像公司里的 Codis 和 Chana，觉得做得很好的东西，都会有机的结合到产品和工程里面来。团队也是挺开放的。

另外，像搜索团队，其实负责了豌豆荚的应用内搜索和应用搜索等工作。

给工程师的建议：基础、视野和好奇心

李大海和杨涛两位专家也给有志于从事搜索技术的技术人员提了一些建议。

杨涛提到，工程师首先要把基础打好，要做搜索这样的事情还是需要一些算法功底的，其次要有一个比较宽的视野，能够看到业界现在做的东西，比如说 DeepLink 和 Akka，并思考怎么把这个东西用到自己的工作当中。还有一点，有一些工程师可能特别喜欢做一些工程上的事，一些很底层的事，这样离产品比较远。而在豌豆荚，他们希望工程师可以跟产品有一种默契，比如工程师想到一个东西，能不能和产品把功能设计进去，用技术推进产品改进，这个很重要。特别是对于现在看还比较创新的产品，其实需要很多这样的 Idea，但是有一些 Idea 是从产品得不到的，就可以从工程师这儿得到一些帮助。像在豌豆荚，如果工程师认为技术上能够做到的某些事情，对产品有所帮助，则应该着力去推。

李大海认为工程师最重要的是要保持好奇心，因为很多时候，工程师工作久了就有一点疲了，好奇心是使其持续保持个人成长很重要的方面。发现一个地方出了问题，要多问为什么，如何避免，如何做得更好，要研究根本原因。这样的动力能够让大家走得更远。所以在带领团队的时候，他也会多问“为什么”。问多了之后，希望大家养成主动思考的习惯。作为团队的领导，也应该给每一位工程师更多责任，不希望大家是纯粹执行命令的人。在做一览的时候，他会直接对工程师说，这一块你是专家，这个事情到底要怎么做，请你给出答案，让工程师快速成长。像一览里面一些排序的改进，一些和内容策略相关的事情，都是工程师主动推动做出来的。