站内搜索功能怎么实现

去年帮一个做母婴电商的站内朋友看后台数据，发现站内搜索的搜索实现转化率只有1.2%，而首页推荐位的站内转化率是4.7%。问题出在哪？搜索实现用户搜“防胀气奶瓶”，结果页第一屏全是站内普通奶瓶，只是搜索实现标题里带了“奶瓶”两个字。搜索算法根本没理解“防胀气”这个核心需求。站内这件事让我意识到，搜索实现站内搜索不是站内装个Elasticsearch就完事了。

最基础的搜索实现实现方式是用数据库的LIKE查询。比如用户搜“奶瓶”，站内你就写SELECT * FROM products WHERE title LIKE '%奶瓶%'。搜索实现这法子在小数据量下能跑，站内商品过万就完蛋——全表扫描，搜索实现响应时间直接飙到两三秒。站内我见过一个日活五千的商城，用MySQL的LIKE硬扛，搜索接口平均耗时1.8秒，用户等不及就关页面了。更麻烦的是它没法处理拼写错误，用户打“奶并”就什么都搜不到。

正经做法是引入全文检索引擎，Elasticsearch或者Meilisearch这类。它们把商品标题、描述、标签拆成词条，建倒排索引。用户搜“防胀气奶瓶”，引擎先分词，再查哪些商品同时包含这些词。速度是毫秒级。但光有引擎不够，关键在分词和权重。中文分词得用IK或者jieba，把“防胀气”切成一个词，而不是“防”、“胀”、“气”三个字。权重设置更讲究：标题命中比描述命中重要，精确匹配比模糊匹配重要。我一般会把标题权重设为3，描述设为1，标签设为2。

光靠文本匹配还不够。用户搜“苹果手机”，你库里有个商品叫“iPhone 15”，标题里没“苹果”俩字，纯文本搜就漏了。得加同义词库，把“苹果”映射到“iPhone”、“Apple”。还有拼音搜索，用户打“naiping”也能出奶瓶。这些配置在Elasticsearch里就是synonym filter和pinyin analyzer的事，但得有人维护词库。我见过一个团队每周手动更新同义词表，运营把用户搜索词日志导出来，发现“平果”这种错别字高频出现，就加到映射里。

排序是另一个坑。文本相关性高不代表用户想买。搜“奶瓶”，一个销量10万+、评分4.9的普通奶瓶，和一个销量200、评分4.5的防胀气奶瓶，谁排前面？得把销量、评分、转化率这些业务指标揉进排序公式。Elasticsearch支持function_score，可以给每个文档算个综合分。我通常会把文本相关性占60%，销量占20%，评分占15%，新品加权5%。具体比例得看品类，快消品销量权重要高，小众品类评分权重高。

还有实时性。商品下架了，搜索里还能搜到，用户点进去404，体验极差。得做增量索引更新。商品一变更就发消息到Kafka，消费者进程去更新ES里的文档。别用定时全量重建，那玩意儿慢，还容易把新商品漏掉。我见过一个系统每小时全量重建一次索引，结果大促期间新上架的商品一小时内搜不到，白白丢了订单。

最后说个容易被忽略的点：搜索日志。用户搜了什么词、点了哪个结果、有没有下单，这些数据得存下来。分析日志能发现很多问题。比如“连衣裙”这个词搜出来点击率低，一看结果页全是过季款，那就得调整排序权重，给当季商品加个时间衰减因子。搜索不是配完就完，得持续调。我那个母婴电商朋友后来加了同义词和销量权重，搜索转化率从1.2%涨到3.1%，没改任何前端代码。