查询理解：从关键词到用户意图的跨越
查询理解，说白了就是让搜索引擎真正听懂用户在说什么。我做了这么多年搜索，最深的感触就是——用户输入的那几个词，背后往往藏着千言万语。
你想想看，当一个人输入「苹果手机掉水里了」，他到底想找什么？是维修方法？是防水测试？还是想买新手机？嗯，这就是查询理解要解决的问题。
查询分类：先搞清楚用户问的是什么
我个人习惯把查询分成这么几类：
- 导航类查询：用户已经知道要去哪，比如「淘宝网」「微信登录」
- 信息类查询：用户想了解某个知识，比如「怎么煮鸡蛋」「北京天气」
- 交易类查询：用户想买东西，比如「iPhone 15 价格」「附近火锅店」
- 事务类查询：用户想完成某个操作，比如「订机票」「查快递」
我在项目中遇到过最头疼的情况——用户输入「苹果」，到底是水果还是手机？这时候就得靠上下文和用户画像来猜了。如果用户之前搜过「iPhone 维修」，那大概率是手机。
核心要点：查询分类不是目的，目的是为后续的意图识别和结果排序提供依据。分类越细，后续处理越精准。
查询意图识别：读懂用户的潜台词
意图识别比分类更深入一层。它要回答的是——用户到底想达成什么目的？
举个例子，「北京到上海」这个查询，意图可能是：
- 查航班信息
- 查高铁时刻
- 查自驾路线
- 查两地距离
怎么判断？我一般会看这几个信号：
- 查询词本身：有没有「机票」「高铁」这样的关键词
- 用户历史行为：之前点过什么类型的页面
- 时间因素：节假日前后，旅行类意图明显增多
- 设备信息：手机端更倾向于本地服务查询
实战技巧：我曾经用过一个简单但有效的方法——对每个查询生成多个候选意图，然后让排序模型去选。这样即使意图识别错了，还有兜底方案。
查询改写与纠错：别让错别字毁了用户体验
用户输入错别字太常见了。我见过最离谱的是「周杰轮演唱会」——用户把「伦」打成了「轮」。搜索引擎要是直接返回「没有结果」，那用户就跑了。
查询改写一般分两步：
- 纠错：修正拼写错误、拼音错误、同音字错误
- 改写：同义词替换、语序调整、补充省略信息
常用的技术手段：
- 基于编辑距离的纠错（Levenshtein Distance）
- 基于语言模型的纠错（BERT、GPT等）
- 基于用户点击反馈的改写（用户搜A点了B，说明A和B相关）
# 一个简单的编辑距离纠错示例
def correct_query(query, vocab):
candidates = []
for word in vocab:
dist = levenshtein_distance(query, word)
if dist <= 2: # 允许最多两次编辑
candidates.append((word, dist))
return sorted(candidates, key=lambda x: x[1])[0][0]注意：改写不能太激进。我曾经遇到过把「苹果手机」改成「苹果水果」的乌龙事件。改写的原则是——宁可少改，不要乱改。
查询补全：帮用户把话说完
查询补全，就是用户刚输入「北京天」，我们就猜到他想搜「北京天气」「北京天安门」「北京天坛」。这个功能看似简单，但做好不容易。
我常用的补全策略：
- 基于前缀匹配：从历史查询日志中找高频前缀
- 基于用户画像：不同用户看到不同的补全建议
- 基于实时热点：突发新闻会迅速影响补全结果
举个例子，用户输入「新冠」，2020年初补全的是「新冠症状」，2023年补全的是「新冠疫苗第四针」。你看，同一个前缀，不同时间点补全结果完全不同。
关键指标：查询补全的评估标准有两个——命中率（用户是否选择了补全建议）和满意度（用户点击补全后的搜索结果是否满意）。
说实话，查询理解这块没有银弹。每个环节都需要根据实际业务场景做取舍。我个人的建议是——先从日志分析入手，看看用户到底在搜什么，然后再决定在哪个环节投入资源。
嗯，今天就聊到这儿。下一章我们会深入讲查询理解的评估方法，到时候再细聊。