在产品中一般会分布着大大小小的搜索，以便提升用户的信息获取效率和信息消费的能力。本文作者全流程角度，对搜索功能进行了讲解，并从搜索流程中寻找提升体验的触点，一起来看一下吧。
在产品中因多功能诉求和业务复杂性等因素，界面大多有高信息密度和高交互密度的特征，为了让用户能快速获取信息和完成任务，在产品中会分布着大大小小的搜索，以便提升用户的信息获取效率和信息消费的能力。
同时因为用户输入内容不可控、解析-匹配-排序规则的复杂度、用户搜索场景的不同等因素，让搜索功能有一定空间去提升体验，所以本文将尝试从全流程角度讲解搜索功能，从搜索流程中寻找提升体验的触点。
若对内容有疑问或想要探讨，希望各位不吝赐教～
本文将通过「激活搜索」、「输入关键词」、「解析内容」、「召回」、「排序」、「结果呈现」6个步骤对搜索内容进行拆解说明。其中前三部分和交互强相关，所以本文将重点讲解。
一、激活搜索
激活搜索阶段最重要的是提供反馈明确当前状态，目前大抵会有两种呈现方式。
1. 出现搜索下拉面板，展示搜索历史or热门搜索or内容引流
如：在飞书文档中激活搜索时会在面板中展示“搜索历史”和“最近浏览”，增加相关内容曝光，去给用户提供更多选择以触达目标内容，该交互形式通常出现在全局性搜索或多维度搜索功能中。
再如：在饿了么中激活搜索进入搜索页，不仅会提供历史搜索，还有一系列的推荐内容和营销榜单的引导，达到商业运营的目的。
2. 仅光标聚焦到搜索框中
如：Coding的事项列表中点击搜索，仅光标聚焦搜索框。
作为任务管理工具在使用搜索时其目标是非常明确的，其对于搜索体验目标是要求快速匹配内容。仅聚焦搜索框中可以减少视觉干扰专注于完成搜索操作。该交互形式常运用于B端产品的表格、列表搜索中。
所以在激活搜索阶段需要结合当前产品性质和搜索场景综合考虑采用何种反馈形式。
二、输入关键字
在此之前我们先看几个例子：
- 石墨文档中，输入关键字后即开始进行搜索行为，并在下拉面板中直接呈现出了搜索结果
- 知乎中输入关键字后即时出现了关键词联想列表，用户可选择回车or点按钮查看搜索结果，也可根据列表切换关键词后查看结果。
可以看出不同产品的交互差异，那造成这种差异的原因是什么呢？之前在思考这个问题的时候认为是B端产品和C端产品的区别，但仔细一想这样划分过于粗暴。后续尝试用搜索场景来解释发现会更合理。
1. 定义搜索场景
在《Web信息架构》中对搜索场景划分为4类，在结合具体产品后我将其收缩为2类。
1）已知条目搜索
用户有非常明确的搜索目标，是在已知内容库中快速定位信息。输入的关键词就是想要获取信息主题。
如：想在Jira上看挂在我头上关于“组件”的任务，会直接在列表中搜索“组件”，此时的搜索结果即我想要的内容。如：查找微信联系人，是有非常明确的搜索目标。
2）探索式搜索
用户有模糊的搜索目标，是在未知内容库中搜寻信息。是对于该类信息主题是未知的想要去探索，且大概率是不能精准描述关键词和结构化表达问题。
如：最近在做组件，想看一下相关文章参考，则会在一些知识平台上输入“组件”查找参考。若没有查找到目标内容，则不停的切换关键词“组件规范”、“组件设计”、“基础组件”进行搜索，直到查找到相关目标内容。
2. 对应的交互方式
这两种搜索场景用户诉求不同导致用户体验目标的不同，则在输入关键词阶段会提供不同的交互方式。
1）已知条目搜索
体验目标：用户目标明确，需要更快更精准的提供结果。
交互方式：输入关键字过程中进行搜索行为，实时展示搜索结果。
2）探索式搜索
体验目标：用户目标模糊，提供关键词辅助能提供更标准化的关键词便于更精准的查找到内容。
交互方式：输入关键字后即时提供关键词联想，回车进行结果查询。
从搜索场景角度出发处于探索式搜索时可提供「关键词联想」功能提升搜索体验，但「关键词联想」在其他产品中也有广泛的运用。
3. 关键词联想的运用
1）在内容平台中以降低用户输入成本，提升搜索效率
如：准备在小红书上查一下冷冻水饺是冷水还是热水下锅，在输入冷冻水饺后就出现大量关联问题，可直接切换选择则完成搜索。
在谷歌中搜索“今日天气”会在面板中直接显示天气数据，直接将结果显示在关键词联想面板中，减少了跳转成本。
2）商业化运营的目的
如：在饿了么搜索“奶茶”，则不仅出现带“奶茶”的商品，还穿插了奶茶果汁排行榜及奈雪、兵立王的商家关联。其中奈雪多次下单过，所以可能是根据最近购买记录进行优先展示，然而兵立王我从未下单过也从未浏览过出现在这儿大概率是商业曝光。
总而言之，关键词联想是适用于探索式搜索场景以提升搜索准确度和有效性；同时适用于内容平台性产品以降低用户输入成本；及有营销诉求的产品以满足商业化运营。
所以在设计时应当考虑产品目标和用户场景去设计输入关键词阶段的交互流程，以提供更好的搜索体验。
三、解析关键词（Query）
在搜索输入关键字过程中会存在拼写错误、语义表达差异等原因导致搜索结果不准确或搜索无内容。所以为了更准确的理解用户意图，加强系统的理解能力通常都会设置多种解析规则，对关键词进行预处理、改写、分词等，以提供更准确的搜索结果。同时对关键词的解析越精准细致，搜索显得越智能高效，也能较大提升搜索体验。
举个例子：飞书文档中输入“wendang”，能搜索出“文档”的内容；石墨文档中输入小写的“meri”，能搜索出大写“MERI”的文档；百度中输入拼写错误的“appla”，能搜索出Apple相关内容。
以上产品所展示的解析能力为「预处理」、「改写」、「分词」三大块，也是现有产品中最常用的解析能力。当然对于搜索引擎和ChatGPT这类产品会有更专业化更复杂的的解析流程本文暂不涉及，主要是超过我知识范围了…下文将根据常用的这三块内容详细讲解。
1. 预处理
预处理指将关键词进行字符转化、删除、截断处理方便后续进行分析。其目的是转化和简化关键词，更好的理解用户意图，以提供更合适的搜索结果。
预处理具体分为以下几种能力：
1）拼音转文字
输入拼音时可转化为文字进行结果查询，如：输入“chanpinsheji”，将转化为“产品设计”进行搜索。就从个人日常使用搜索功能而言，常会忘记切换输入法直接输入了拼音，此时提供该能力也能进行有效搜索时是能带来体验上的惊喜感。
功能虽好，但也不一定产品内所有搜索功能都需要加上拼音转文字能力，这个也是需要结合当前搜索场景和用户行为具体分析是否为一个高ROI功能。
如：在一些B端 CRM系统中客服人员会通过搜索客户名称进行资料录入，此时的搜索场景大多是在IM聊天窗口中复制客户名称再粘贴到搜索框中从而完成搜索行为。此时的搜索大多不会牵扯到手动输入，此时拼音转文字能力作用也不大。
2）大小写转换
大写字母转换为小写字母进行结果查询，即不论用户输入大写或小写字母都能查询到对应结果。
如：输入“f6”，能搜索出大写“F6”的内容。
该能力适用于带有字母的结果数据。举个例子，在ERP系统中有大量的企业物资信息，其中对于一些固定资产通常会以“楼层+设备名+设备编号”来进行命名，如：“F6-iMac-7842”，字段为大小写字母混排，存在较高的输入成本。若提供大小写转换，则直接输入“f6-imac-7842”也能出现对应结果。
3）繁简体转换
将繁体字转化为简体字进行搜索，该能力则适用于涉及到繁体字使用习惯地区用户，本次就不再赘述。
4）无意义字符移除
无意义字符包括特殊符号（emjio、表情符号、连续的空格符等）和无意义字符（“的”、“了”、“么”、“哈”等语气组词）。无意义字符会打包成一个《停用词库》作为搜索配置库存在，且目前有大量的开源《停用词库》可直接调用，所以具体停用哪些字符可基于开源词库的内容再结合业务诉求进行增删。
举个例子，在飞书文档中输入“会议”且中间插入多个空格，依旧能搜索出带“会议”的文档。
注意看输入框下方第一行文字“在高级搜索中查看 ‘会 议’ ”，将“会 议+6空格”缩短成“会 议+1空格”，仅保留了一个空格作为分词符，去掉了多余的空格符。
而在石墨文档中输入“设计”能查询到内容，若中间插入多个空格则搜索无结果。石墨则是将所有输入内容作为有效字符进行搜索，进而搜索结果为空。
从体验上来看，飞书文档通过增加系统搜索规则来减少错误输入导致的无结果，增加了系统容错性，来提供更多的可能性，减少空数据带来的失落感。
插入一个关于空格的小细节：
当初写搜索功能的交互说明时，被测试问道如果输入连续的空格如何响应？当时想的是谁没事干输那么多空格，但作为一个专业的和蔼可亲的设计师怎么能将心里话说出来呢。所以赶紧看了各大产品的处理方式以便于合理借鉴，发现主要分为以下几种类型：
- 输入多个空格后，搜索结果面板显示无结果，点击回车无响应
- 不允许输入空格，输入非空格字符后才能输入空格
总的来说，分为两类一种是前置防错，直接不允许输入，在数据结构中大多数情况中不存在多空格数据的存在；另一种是后置反馈，允许输入任何字符无匹配内容则显示无结果，这种处理方式更简单直接，不做任何特殊处理有结果就显示没有结果就为空，给予用户最大的操作自由同时逻辑也统一。
个人角度更偏向第二种，即保证用户输入的自由度，通过搜索规则合理去除无意义字符，此时还未有对应匹配内容则应当告知用户无结果，告知用户尝试用其他关键词进行搜索。同时也减少规则的复杂度。
5）长度截断
即将超过设定长度的关键词进行截断，减少查询压力。如百度的查询限制为38个汉字，谷歌的查询限制为32个词。
总的来说，预处理中的「拼音转文字」、「大小写转换」、「繁简体转换」是通过增加系统判断规则的复杂度来减少用户输入的复杂度，降低用户的输入门槛和成本，提升用户操作的自由度。「无意义字符移除」和「长度截断」则是合理筛查关键词，精简表达提升搜索结果的准确度。
2. 分词
分词是当输入关键词无法与数据库完全匹配时，则会将关键词拆分为多个Term（Term可以是词组也可是汉字）再与数据库匹配。如：“九转大肠”无匹配内容时可拆分为“九转”、“大肠”两个词组或拆分为“九”、“转”、“大”、“肠”四个汉字进行匹配。
分词的关键在于怎么分？在英文语句中“You are awesome.”用空格隔开了三个单词，若用这句话进行分词搜索则自然会拆分成“you”、“are”、“awesome”三个单词。
在中文表达中没有空格，且中文分词不合适就会形成不同的语义表达。如“上海市长江大桥”可分词为“上海市”、“长江大桥”，也可以是“上海市长”、“江大桥”。
目前大多数产品都是采用的基于词典的分词方法，即维护一个分词库，若输入的关键词命中分词库中的词语时，则能召回词语对应的内容。
举个例子，在飞书文档中输入“头脑”，会出现包含“头脑”词语的文档；若输入“头脑暴”，则无结果。这是将“头脑暴”作为一个词组参与搜索，没有命中分词库数据库也无匹配内容。
在石墨文档的结果匹配中则是将分词逻辑直接用分隔符显示出来了。如：输入“小李的工作内容”首先停用了“的”，然后拆分为“小李”、“工作”、“内容”三个词组进行结果匹配。
但基于分词库进行分词会存在一定的维护成本，如：出现新词则需要手动添加等。
随着分词技术的成熟，已经形成一套更为智能化的分词方法和工具服务，会加入深度学习模型分析让其更智能的分词。因为这块过于后端技术化所以不多赘述，有兴趣的同学可查看《中文分词的原理、方法与工具》这篇文章有详细介绍。
分词能力广泛运用于探索式搜索场景的产品中，通过分词技术将关键词合理拆分重组，以召回更多相关内容，其注重的是查全率。所以在内容资讯产品（如：知乎、语雀、微信搜一搜）中通常都会运用分词技术召回大量内容以满足用户查询需求。
3. 改写
改写指的是将输入关键词改写为另一个能与数据内容匹配的关键词，具体可分为三个方向。
- 将拼写错误的关键词纠错改为拼写正确的字词；
- 将不同文字表达但是同义的字词统一归为更为标准的字词；
- 将输入关键词扩展出与其内容或行为语义相关的字词列表，推荐给用户便于对潜在需求挖掘发现。
1）纠错
将拼写错误的关键词纠错改为拼写正确的字词。如：在知乎输入拼写错误单词“appla”，系统自动将关键词修改为“apple”，并展示了对应结果。
相比英文单词拼写纠错，中文字词的纠错则更为复杂。如：中文字若通过拼音输入时就存在模糊音（平翘舌、前后鼻音等）、同音字错误；若通过五笔输入时就存在形近字错误等。
在腾讯搜索技术文档中将错误类型分为「Non-word Error」指不存在于词典中的错误字词；「Real-word Error」指由多个汉字组成的词语错误。且这两个大类还可以继续拆分更小粒度的错误类型。
当然图上的错误类型是全集，搜索引擎基于产品特性是大面积覆盖了这些错误类型。除搜索引擎的产品则可根据产品定位和场景进行选择性实现。
如：在钉钉的全局搜索中搜索联系人就采用了「简拼」、「汉字+拼音组合」、「混淆音」、「颠倒」等纠错方式。但这些纠错能力也仅限于联系人，针对聊天记录和文档里的内容则不涉及。
仔细一想，很合理且必要。
联系人数量有限，且名字是会存在生僻字，容易拼写错误，且在使用钉钉中搜索联系人是一个高频行为，提供关键词纠错能力，是允许用户出错的同时加强系统的判断能力并提供合适的解决方案呈现给用户，从而减少不必要的错误提示和空页面。
而聊天记录和文档则会因为使用时间不断累加数据量，若提供过于强大的纠错能力会召回大量低匹配度内容导致搜索结果不够简练准确。
2）归一
将不同字词但是同义的字词统一归为更为标准的字词再做数据匹配。其目的是为了解决在表达中存在的语义差异，如：“iPhone手机价格”、“iPhone手机售价”、“iPhone手机多少钱”三种不同的语义都是表达统一含义，则可以将这三种表达都归一到“iPhone手机价格”的标准字词。
同停用词库，同义词也会打包成为一个《同义词库》，且目前已有开源的词库，可在现有业务基础上进行增删同义词。
如：之前设计产品中有针对整栋建筑内所有设备和空间的搜索，其中针对“卫生间”同义的词语包括“厕所”、“洗手间”、“盥洗室”，所以就设置了将这三类词语归一为“卫生间”。这样在输入“厕所”时也能查询“卫生间”的数据内容。
3）扩展
将输入关键词扩展出与其内容或行为语义相关的字词列表，推荐给用户便于对潜在搜索需求挖掘，该功能也称为关键词联想。在本文的2.3「关键词联想的运用」阶段对其有描述，在此就不赘述了。
随着搜索内容越来越复杂和多语义化，解析关键词会越来越重要。只有不断细化和更新解析规则才能更准确理解用户意图，以尽可能获得更准确的结果，增强搜索结果有效性。
话锋强硬一转，插入一个小话题。在网上看了多篇关于搜索的文章，发现大家对于“模糊搜索”和“精确搜索”的定义都有所不同，借此来说说自己的理解。
①精确搜索（=）：即关键字和内容完全匹配
例如：输入“九转大肠”，只会出现“九转大肠”，关键词与结果需完全一一对应。
②模糊搜索（like）：即关键字和内容不完全匹配也能出现结果，关键字与结果部分匹配即可
例如：输入“九转大肠”，会出现“九转大肠俞涛”、“顶级厨师九转大肠”、“九转小肠”、“九转猪肚”、“红烧大肠”。
举个例子，来看看知网当中可对搜索结果进行精确和模糊搜索，其搜索结果区别。
同时在解析关键词这一环节中预处理、分词、改写这些能力也是对模糊匹配能力的进一步细化，如：输入拼音、输入首字母简写、同音字等也可进行匹配。
所以在做设计需求时应该明确模糊匹配是需要模糊到何种程度，而不是用该搜索支持模糊匹配一句话带过。
四、召回
召回指的是关键词经过解析后与数据库内容进行匹配，寻找到与之匹配内容的过程，也就是系统在筛选符合用户搜索需求的内容。
在这个阶段后端同学会通过倒排索引技术来建立关键词与数据库的关系，提升搜索查询效率。简单来说就是建立类别清晰的目录便于快速查找目标内容。
所以查询速度则与该环节强相关，该环节倒排索引建设的越合理查询速度越快。这块内容因纯为后端技术方向，所以也不多赘述。
五、排序
当在数据库中查询到多个结果时，则需要通过排序规则以优先级展示给用户。合理的排序规则是将结果有效呈现的关键因素。
排序可大致分为两个方向，一种是根据匹配度+数据参数进行优先级排序，如：搜索订单、任务、事项这类数据时，可优先根据匹配度（如：匹配度越高越靠前），若匹配度一致则再根据订单、任务、事项的数据参数排（如：创建时间倒序，可根据业务需要选择具体参数）排序。
如在Coding上搜索“组件”事项，出现了4条包含组件条目的事项内容，其中状态和优先级一致时，其ID是呈倒序，所以猜测Coding有一条排序的规则是根据ID序号倒序排序。
二种是根据加入多维度算法综合打分排序，将评分结果越高的搜索结果越靠前。可根据数据类型列举参数进行计算。用内容资讯类产品举例，其通常会设置阅读量、评论率、时效性等数据指标+权重计算得分进行排序。
如：在微信搜一搜中搜索文章、知乎搜索回答都有其一套默认的数据指标排序规则。
随着搜索能力的成熟，目前也形成了一套专业化的排序方案，详细内容可参考《一文带你了解搜索功能设计》，在此也不多赘述。
六、结果呈现
作为搜索功能最后一环，清晰有效的展示搜索结果是其关键要素。
目前在各大搜索引擎中都逐步优化成基于关键字类型展示不同的结果形式，根据关键字类型尽可能多的曝露信息，便于用户快速触达和获取信息，减少跳转步骤。
如：在谷歌中搜索“日出”则首要出现图片；搜索“杉木”首要匹配维基百科链接；搜索“iPhone 13”则首要匹配且定位到Apple官网中购买iPhone13的链接。
但在其他产品中是如何有效曝露结果信息，让用户能更快速有效的选择内容呢？
来看一下文档类产品，石墨和飞书，其下拉面板中展示搜索结果，同时也可hover结果条目时出现popover去预览文档内容。
再来看看语雀，搜索结果中则是展示了标题和部分内容。整体看起来信息密度过于大，没有重点，很难识别到重要信息。特别是在查找公开知识库内容时，从标题和描述文字很难感知具体内容质量，所以需要打开多个文档查看内容，有较大的查找成本。
总之，在搜索结果呈现界面中应该根据结果形式特点去设计搜索结果页，或是通过有序分类导航或是以灵活化的结果展示形式等，为用户提供更可视化的结果，减少用户查找和跳转成本。
七、打个总结
本文拆解了搜索这么多能力，那产品内的搜索都需要实现这些能力吗？
个人认为不是的。
首先不同产品搜索场景不同，重要度不同，其对搜索功能完备度要求也不一样。
其次在做产品设计过程中因产品商业目标、功能规划、技术限制等是不可能一次性将功能做完美到极致，这时候就需要设计师从用户体验出发结合客观条件因素限制提出性价比更高的解决方案。或是优先实现核心场景的高频使用痛点，或是优先实现核心用户的使用痛点，实现设计价值最大化。
同时当设计师对功能底层逻辑了解的越透彻，在产品和开发面前也更有“议价”的权利，从而提升设计师话语权，更好的让设计产生价值。
所以打工人追求Work Life Balance，体验设计师应该追求Business Experience Balance。
参考文章：
- Google 自动完成功能在搜索中的工作原理
- 搜索联想词产品实践系列（一）:定位-评估和召回篇
- 腾讯搜索：搜索中的 Query 理解及应用
- 中文分词的原理、方法与工具
- 阿里云：智能开放搜索OpenSearch
本文由 @0479 原创发布于人人都是产品经理，未经许可，禁止转载
以上就是本篇文章【搜索功能全流程解析】的全部内容了，欢迎阅览 ！ 文章地址：http://houdi.cs-ej.cn/news/216.html 资讯 企业新闻 行情 企业黄页 同类资讯 首页 网站地图 返回首页 成事e家移动站 http://houdi.cs-ej.cn/mobile/ , 查看更多