解读

面试官把“餐厅—特色菜—辣度”这一生活化场景抛给候选人，实质是在考察三点：

1. 对中文搜索会话式 Query 的理解深度；
2. 对百度等国产搜索引擎“上下文继承”“需求澄清”机制的技术认知；
3. 能否把技术原理映射到 SEO 实操（关键词布局、结构化数据、内容补给）。
   回答时不能只说“搜索引擎很智能”，而要拆解“谁在做、怎么做、做到什么程度”，并回扣 SEO 工作。

知识点

1. 会话搜索（Conversational Search）：多轮 Query 之间通过 Session-ID、设备指纹、Cookie、登录账号等绑定，形成同一搜索会话。
2. 指代消解（Coreference Resolution）：将“这些菜”映射到上一轮“特色菜”实体，依赖 NER 与依存句法。
3. 查询重写（Query Rewriting）：搜索引擎在服务端把“这些菜辣吗”自动补全为“【餐厅名】特色菜辣吗”，再送入排序系统。
4. 上下文缓存（Context Cache）：百度“百晓生”模型在 30 分钟会话窗口内缓存实体与意图，降低重复理解成本。
5. 动态摘要与答案拼接：如果站点提供了“辣度等级+口味描述”结构化字段，百度可直接抽取生成多轮对话式摘要。
6. E-E-A-T 与本地搜索：餐厅类页面需同时满足体验（辣度可视化）、权威（厨师背书）、信任（真实点评），才能在“特色菜+辣吗”组合 Query 下稳定展现。

答案

“百度处理这类连续追问，核心是分两步：先绑定会话，再完成指代消解。
第一步，用户发出第一条 Query‘这家餐厅有什么特色菜？’时，百度通过 Session-ID 把该 Query 与地理位置、设备号绑定，并在本地搜索触发器中激活‘餐厅实体卡片’。系统利用 POI 数据库锁定最匹配的一家，返回特色菜列表。
第二步，当用户紧接着问‘这些菜辣吗？’，百度在服务端做查询重写：先用 NER 把‘这些菜’回指到上一轮结果中的‘特色菜’实体，再把原 Query 扩展为‘【餐厅名】+特色菜+辣度’。扩展后的 Query 重新进入语义索引，优先检索‘辣度’字段有标注的页面。如果我们的官网在菜品介绍中使用了‘辣度星级’结构化数据（Schema.org 的‘spicyLevel’），百度就能直接抽取并在动态摘要里给出‘微辣、中辣、特辣’的分级答案，无需用户再次点击。
因此，从 SEO 角度，我们要：

1. 在菜品页用 JSON-LD 标注‘name、description、spicyLevel’；
2. 用口语化长尾词‘××菜辣不辣’覆盖可能的追问 Query；
3. 在标题与首段同时出现‘特色菜+辣度’组合，方便查询重写时命中。
   这样即可借助百度的上下文理解机制，把第二轮流量也锁定在自有结果里。”

拓展思考

1. 多轮会话的“意图漂移”：若用户第三轮问“附近有没有不辣的同款？”，系统需结合地理位置与口味标签做交叉检索，SEO 可提前生产“替代菜品/不辣版本”内容矩阵，抢占“不辣+菜名”长尾。
2. 小程序与闭环：百度智能小程序支持“一次搜索、多次交互”，可把“特色菜→辣度→下单”做进同一 Session，降低跳失；SEO 人需与产品联动，把结构化数据同步到小程序，实现 SERP 直连服务。
3. 语音搜索场景：中文口语常省略主语，“辣吗”单字 Query 占比高，优化时应增加“纯口语+语气词”词库，并在页面 FAQ 区用“问：这菜辣吗？答：微辣”成对出现，提升语音答案匹配度。