资料检索日期：2026 年 9 月 6 日
上一篇文章已经通过 ChatGPT 的官方文档、网页 Network 响应和 API 返回，确认 query fanout 是真实存在的搜索机制。这篇转向中国 AI 助手，观察它们如何拆分和改写用户问题。
本文选取豆包、Kimi、元宝、DeepSeek 和通义千问五个平台，比较它们如何拆分和改写同一类用户问题。
一、验证方法
这次只验证产品返回层，不根据最终答案猜测隐藏过程。观察三个信号：
- Network 响应中是否出现
queries、query等查询字段； - 是否出现
web_search等搜索工具调用； - 查询、搜索结果和最终引用之间能否建立关系。
不同平台的问题不完全相同，以下数量均为单次请求的观察结果。
二、豆包：直接返回 queries 数组
针对“AI roll-up 模式公司”这个问题，豆包网页端 Network 响应的 search_query_result_block 中出现了 queries 数组，共 4 条：
- AI roll-up 模式代表公司；
- roll-up 模式是什么，科技行业；
- AI roll-up 国内企业案例；
- AI roll-up business model 收购整合 AI 公司。
响应同时显示“搜索 4 个关键词，参考 20 篇资料”。四条查询分别覆盖概念解释、代表公司、国内案例和英文商业模式。
三、DeepSeek：响应中直接出现多条 query
DeepSeek 的 completion 响应中直接出现了 queries 数组。针对“AI roll-up 模式有哪些公司？”，实际返回 5 条查询：
- AI roll up 模式 公司 列表；
- AI roll-up 模式 公司；
- AI rollup 模式 企业 有哪些；
- AI roll up strategy companies list；
- 人工智能 roll up 整合 模式 公司。
这些查询覆盖中文、英文、同义表达，以及“企业有哪些”“整合模式公司”等更具体的方向。
四、Kimi：web_search 参数中出现两条查询
Kimi 使用相同问题，Network 响应中的 web_search.args.queries 包含两条查询：
- AI roll-up 模式公司收购整合 2026；
- AI roll-up companies acquisitions 2025 2026。
它们分别指向中文收购整合案例和英文近期并购案例，把原问题改写成了带时间和业务动作的搜索方向。
五、通义千问：把问题拆成定义和案例
通义千问针对“AI roll-up 模式有哪些公司？”返回两条 query：
- AI roll up模式 定义；
- AI roll up模式 案例。
响应同时显示 recall_num: 82。它把公司名单问题拆成了“定义”和“案例”两个方向。
六、元宝：能看到搜索工具调用，但查询词不完整
元宝的 Network 响应出现 toolCallType: "web_search" 和 search_with_text 事件，页面显示“引用 15 篇资料作为参考”，但没有展示完整查询词。因此只能确认搜索调用，不能判断具体 fanout 类型。
七、用八类 query variant 重新解读
上一篇《查询扇出详解》提到，Google 专利把 query variant 分成同义、追问、泛化、具体化、规范化、翻译、蕴含和澄清八类。
这一节是在做单条查询的类型学解读：把每个平台返回的具体查询，放进八类 query variant 中观察。它不是对平台整体策略的判断，更不是对内部实现的确认。
| 平台 | 观察到的查询 | 对应的扩展类型 |
|---|---|---|
| 豆包 | 代表公司、行业解释、国内案例、商业模式 | 规范化、澄清、具体化、蕴含 |
| DeepSeek | 中文同义表达、英文表达、企业范围、整合模式 | 同义、翻译、泛化、具体化 |
| Kimi | 收购整合、英文并购案例、补充年份 | 具体化、翻译、蕴含 |
| 通义千问 | 模式定义、模式案例 | 澄清、蕴含 |
| 元宝 | 只看到搜索工具调用 | 暂无法判断 |
具体来看：
AI roll up 模式公司、AI rollup 模式企业有哪些，属于 Equivalent Query，同一意图的不同表达；AI roll up strategy companies list，属于 Translation Query，使用英文表达扩大检索范围；AI roll-up 模式公司列表，接近 Canonicalization Query，试图寻找代表性公司或标准答案；AI roll up模式 定义，属于 Clarification Query，先消除概念歧义；AI roll up模式 案例、AI roll-up 国内企业案例，属于 Entailment Query，从概念继续追问实际案例；AI roll-up 模式公司收购整合 2026，属于 Specification Query，在主题上增加业务动作和时间条件。
不过，分类不能过度精确。比如“AI roll-up 国内企业案例”既可以看作具体化查询，也可以看作从概念推导出来的蕴含查询。这里重要的不是给每条查询贴上唯一标签，而是观察模型到底从原问题扩展了哪些维度。
八、五个平台的模式对比
第七节回答的是“每条查询属于哪一类”，这一节回答的是“平台整体采用了什么搜索策略”。平台对比不再逐条贴标签，而是看同一平台的多条查询如何共同工作。
| 平台 | 可观察字段 | 可见搜索项 | 主要模式 | 可见性 |
|---|---|---|---|---|
| 豆包 | queries 数组 |
4 | 关键词抽取 + 方向扩展 | 查询和结果较清楚 |
| DeepSeek | queries[].query |
5 | 中英文改写 + 查询扩展 | 查询数组直接返回 |
| Kimi | web_search.args.queries |
2 | 语义限定 + 时效扩展 | 工具参数中可见 |
| 通义千问 | query 列表 |
2 | 子主题拆解 | 查询列表直接可见 |
| 元宝 | web_search、search_with_text |
未完整显示 | 搜索调用可见，策略暂不能判断 | 搜索调用可见 |
五个平台的差异因此可以分成两层：一层是查询本身的改写类型，另一层是平台如何组织这些查询。DeepSeek 扩大中英文表达，豆包提取关键词并展开方向，通义千问拆分定义与案例，Kimi 补充业务动作和时间条件；元宝目前只能确认搜索调用。
九、下一步：搜索 API 才是更底层的机制
fanout 只是搜索链路的上游。查询生成之后，真正决定结果质量的，是搜索 API 如何解析这些关键词和查询输入，如何召回候选内容，再如何排序、去重和组织结果。
尤其是面向 AI 搜索的 AI-friendly Search API：它和传统网页搜索 API 到底有什么不同？能否理解查询之间的关系？是否会根据查询意图返回结构化内容、摘要和证据？这些问题比“平台生成了几条查询”更接近搜索系统的底层机制。
模拟与反推是另一条研究路线，下一篇单独讨论。本文到这里，先把五个平台暴露出的查询形态和平台策略区分清楚。