01

60 秒回答模板

我会先把这类问题定义为本地生活搜索里的复杂场景需求。用户不是只搜品类，而是在表达位置、场景、人群、约束和偏好，例如附近、团建、宠物友好、安静、预算、营业时间等。AI 的第一步是意图解析，把自然语言拆成地点范围、服务品类、场景属性、硬约束和软偏好；第二步是候选召回，结合商家结构化信息、评论文本、标签和历史反馈找出可能匹配的商家；第三步是排序和解释，把强约束先过滤，软偏好用于排序，并给出匹配理由；第四步是交互补全，当需求不明确或结果不足时，主动澄清或给替代方案。指标上要看长尾 query 的满足率、搜索改写率、无结果率、结果点击和到店后满意反馈、用户是否继续追问。风险是过度猜测用户意图、把评论里的偶发描述当成稳定属性、以及距离和质量之间取舍不清。

考点 意图槽位
难度 真实面经题
回答目标 讲清产品设计与评估闭环
02

深入解析

01

这类搜索的难点是场景而不是关键词

“附近适合 X 的 Y”通常包含多层含义：地理范围、服务品类、使用场景、同行人、时间、预算、氛围和禁忌条件。传统关键词匹配容易只命中 Y，却忽略 X 的真实约束。AI 的价值在于把自然语言需求转成可执行的搜索意图。

02

意图解析要拆出硬约束和软偏好

硬约束包括位置、营业状态、服务品类、是否允许宠物、是否支持包间等；软偏好包括安静、适合团建、有氛围、性价比高、近期评价好。拆清楚后，硬约束用于过滤，软偏好用于排序和解释，避免把用户必须满足的条件当成普通加分项。

03

商家理解要利用评论和标签补足结构化信息

很多长尾属性不会完整写在商家基础资料里，可能散落在用户评论中。AI 可以从评论中识别场景证据，例如是否适合多人聚餐、是否吵、服务是否稳定、环境是否适合拍照。但这些属性要有证据和时间窗口，不能把一条偶发评论当成稳定事实。

04

匹配结果要给用户可理解理由

长尾搜索结果不能只给商家列表。用户需要知道为什么这个商家适合当前需求，例如距离近、近期多人聚餐反馈多、环境安静、宠物友好证据较多。解释可以帮助用户快速决策，也能暴露系统误解，方便用户继续改写。

05

交互上要允许澄清和降级

当需求太模糊、候选太少或约束冲突时，产品应主动澄清，例如询问预算、人数、时间，或者给出替代条件。没有足够结果时，可以放宽某个软偏好并说明原因，而不是直接返回空结果或强行推荐不相关商家。

06

评估要专门看长尾满足率

这类需求在总体搜索里占比可能不高，但体验影响大。应按长尾 query 构建评估集，看意图解析准确、候选相关、无结果率、改写率、点击或收藏、到店后反馈、负反馈和人工抽检。只看整体搜索 CTR 会掩盖长尾问题。

03

易错点

  • 把问题答成关键词搜索优化，没有拆复杂场景和约束。
  • 只讲语义召回，没有说明硬约束过滤、软偏好排序和结果解释。
  • 把评论中的偶发描述直接变成商家稳定标签，可信度不足。
  • 结果没有匹配理由，用户无法判断系统是否理解了需求。
  • 候选不足时直接返回空结果或乱推荐，没有澄清和放宽策略。
  • 只看整体 CTR，没有针对长尾 query 的满足率和改写率评估。
04

面试官追问

硬约束和软偏好为什么要区分？

硬约束不满足就不应该推荐，软偏好可以用于排序和解释。混在一起会导致看似相关但实际不可用的结果。

如果没有完全匹配的商家怎么办？

可以提示约束冲突，询问是否放宽条件，或给出部分匹配的替代方案，并明确哪些条件被放宽。

如何判断评论里的长尾属性可信？

看相似评论数量、时间分布、评论质量和是否与商家信息一致。单条评论只能作为弱证据，不能直接变成强标签。

为什么不能只用通用搜索指标评估？

长尾复杂 query 容易被总体指标掩盖。整体点击率高，不代表“附近适合团建的餐厅”这类需求被满足。