如何为你的 AI 构建应用添加搜索功能(让用户真正能找到东西)

想为 AI 构建的应用加上搜索功能,可以先做一个随输入即时缩小结果的过滤框,明确告诉它该搜索哪些字段,再加上便于浏览的分类筛选;至于容错拼写或按语义查找这类需求,留给 AI 驱动的智能搜索来解决。

每一个足够好用的 AI 构建应用,迟早都会遇到这个时刻:它被填满了。原本只有十几道菜谱时用起来赏心悦目的菜谱应用,到了三百道菜谱时就变成了一件苦差事。原本只有八位客户时整整齐齐的客户跟踪表,到了两百位客户时就变成了没完没了的滚动翻找。没有任何东西坏掉——这个应用被用起来了,这本来就是它存在的意义——但现在,用户来这里最想做的那件事,找到某一个具体条目,却变得太耗时了。

这就是该给应用加上搜索功能的信号了:一个输入框,敲几个字母就能把一长串列表缩小到你要找的那一条。这么做不是因为搜索听起来很厉害,而是因为滚动翻找不等于找得到。下面我们来讲讲怎么做到这一点,同时不过度设计——因为往往最花哨的那个版本,恰恰是错误的第一步。

什么时候该给应用加搜索功能?

你会知道的,因为滚动翻找开始变得比它该有的耗时更长——你的列表已经从一小撮整整齐齐的条目,涨到了几百条,想找某一个具体的东西,就得先划过所有其他内容。走到这一步,不是因为出了什么问题;是应用被用起来了,这本来就是它存在的意义。

这里有个很典型的例子。一位宠物美容师做了一个应用来跟踪自己的客户——姓名、狗狗的名字、品种,以及哪些狗讨厌吹风机之类的备注。头几个月,这就是一份她扫一眼就能看清的整洁列表。等她攒到两百位客户时,常常是顾客就站在面前,她却得在应用里划过上百个名字,才能找到”Bella 的主人”。

这个应用完全在按她要求的方式工作。只是这份列表不再是在其中找到某一条信息的好办法了。这正是搜索要解决的问题:它把”划到看见为止”变成了”打几个字母,它就在那儿”。

如果你的应用会展示某种列表——订单、菜谱、客户、商品、笔记,而且这份列表还在不断变长,你迟早会遇到这个问题。好消息是,最简单的第一版搜索,就能解决几乎所有人的这个问题。

怎么给一个 AI 构建的应用加上搜索功能?

先做一个过滤框——列表顶部的一个文本输入框,你一边打字,它一边把不匹配的内容隐藏起来——而不是一上来就要最智能的”AI 搜索”。这就是第一步的全部内容,对大多数应用来说,这也是唯一需要的一步。

向 AI 构建工具提要求时,你很容易忍不住想要最智能的那个版本:能理解你的意思、能处理同义词、能按相关性排序。请克制住这个冲动。智能版本运行得更慢,运行成本更高,也更难做对,而且你几乎可以肯定现在还用不上它。

输入”bella”,列表就缩小到只剩 Bella 们。就这么简单。它是即时的,运行起来几乎零成本,而且这正是人们说”我想要能搜索”时,真正想要的东西。

直接向你的构建工具这样提要求就行:“在这个列表上方加一个搜索框,把它过滤成与我输入内容匹配的条目。“你会惊讶地发现,很多时候这就是整个项目的全部内容了。

搜索到底应该看哪些字段?

只看真正能识别出你要找的那个东西的两三个字段——而不是每个条目的每一个字段。把这一点告诉你的构建工具,是让搜索变得好用而不是让人抓狂的关键一步,而大多数人都会跳过它。

默认情况下,构建工具可能会搜索所有内容——每个条目的每一个字段。听起来很全面,但结果往往更糟。想象一下,在那份客户列表里搜索,却因为某条备注里提到狗狗体型”小”而匹配出结果。现在你得在一堆技术上匹配、但根本不是你想要的结果里大海捞针。

所以要明确指出哪些字段才重要。对那位美容师来说,是客户姓名和狗狗的名字——不是备注,不是品种,也不是预约记录。对一个菜谱应用来说,是菜名,也许再加上主要食材,而不是整段做法说明。告诉你的构建工具:“搜索只应该看标题和名称字段。“搜对两个字段,永远胜过搜遍全部十二个字段。

应该先做搜索,还是先做筛选?

答案往往是筛选——因为很多人口中的”搜索”,其实是”给我看这一类子集”,而搜索框根本不是解决这个问题的对的工具。这一点常常让非技术背景的创建者感到意外。

一个有三百件库存商品的二手商家,通常不想打字——她想点一下”已售出”、“有库存”或”本周新上架”。这就是筛选:几个按钮或一个下拉菜单,按你早已在记录的某个分类来缩小列表。筛选往往比搜索更容易做,日常也更好用,因为人们按状态浏览的频率,远高于按名字去找某一件具体的东西。

一个不错的判断标准是:当”我大致知道它叫什么”时,加搜索框;当”给我看这一类”时,加筛选。前面那位宠物美容师最后两个都想要——一个搜索框,让她在客户站在面前时能按姓名迅速找到人;一个”该洗澡了”的筛选器,让她在闲下来的下午一眼看出该给谁发短信。同样的数据,却是两种完全不同的取用方式。

如果只能先做一个,那就观察人们实际是怎么用这个应用的。如果他们总在问”所有 X 都在哪儿”,他们想要的是筛选,不是搜索框。

搜索找不到结果时,应该显示什么?

一句明确具体的提示——比如”没有客户匹配’zelda’——请检查拼写或清空搜索”——而不是一片空白,那看起来像是”这个应用坏了”。它并没有坏;只是没有匹配结果而已,而大多数人都会忘了为这种情况做规划。

默认情况下,常常就是一片空白。所以要告诉你的构建工具,空状态该显示什么文案。就这一句话的区别,决定了用户会觉得你的应用坏了,还是会觉得自己打错了字。

顺便也确保有一个显眼的方式可以清空搜索、恢复完整列表——输入框里的一个小”x”,或者一个”清空”链接。困在一个逃不出来的搜索里的人,比你想象的要多得多。

什么时候需要 AI 驱动的智能搜索,而不是普通过滤框?

有两个具体信号,不是凭感觉:拼写错误,以及语义。如果有人搜索”stephanie”却漏掉了”Stefanie”,你需要一种能容忍细微出入的容错匹配——向你的构建工具提要求:“即使拼写稍有偏差,搜索也要能找到结果。“而如果你真的需要”帮我找出关于账单问题的笔记”,而不是”找出包含’账单’这个词的内容”,那就属于智能的、AI 驱动的搜索了——一旦它要解决的是简单过滤框解决不了的问题,多花的成本和复杂度就是值得的。

但千万别一上来就做这个。先从过滤框开始,等拼写错误真的造成困扰时,再加上容错匹配,只有当”匹配文字”不再够用时,才去用智能版本。大多数应用其实永远用不到这一步之后。

所以,在你动手做任何东西之前,先观察自己用自己的应用用上一周。那个你总要划来划去去找的东西——一个客户、一份订单、一道菜谱——那就是你的搜索框存在的意义。先为这一件事把它做好,你就已经为几乎所有使用它的人解决了这个问题。