我们抓取了ChatGPT、Gemini和DeepSeek的网络流量，观察各自如何定义"来源"——三种完全不同的机制

开诚布公：我是一家AI可见性公司的创始人，因此这项研究正好解决了我们自己的需求。分析前已将我们的域名从所有计数中排除。文章中不会添加任何链接。我们想回答一个简单的问题：当AI助手展示"来源"时，从技术角度那究竟是什么？于是我们在ChatGPT、Gemini和DeepSeek的web客户端打开了开发者工具，对每个系统运行同样的4个查询各10次。我们发现：**ChatGPT**通过SSE流式传输回答，并使用`url_citation`对象附加引用，其中包含`start_ix`/`end_ix`——生成文本中的字符偏移量（UTF-16代码单元，所以如果你按字节计数，emoji和CJK字符会破坏解析）。引用绑定到回答中的特定*片段*，而非整个回答。**Gemini**运行在Google的batchexecute/JSPB传输协议上——protobuf以JSON数组形式呈现，字段使用位置而非名称。在每个引用的URL旁边有一组简短的混淆字段。我们的工作假设（未经Google文档确认）：`rs` ≈ 域名的可靠性评分，`ls` ≈ 最后可见日期，`GK` ≈ 字符范围（功能类似于ChatGPT的偏移量）。有趣之处不在于精确解码——而在于Gemini随每个来源附带了内部按域的信任信号。**DeepSeek**最为透明：一个简单的`search_results[]`数组附加在它将你的问题分解成的子查询后面。没有偏移量，没有隐藏字段。而它们实际引用的内容也截然不同：ChatGPT偏爱arXiv + 维基百科（有一篇arXiv论文在10/10次运行中被引用），Gemini偏爱大型SaaS/营销域名——有趣的是——在我们的运行中从未引用过任何Google资产，DeepSeek则依赖新闻稿分发线和新闻聚合器，包括其他两者从未触及的中文来源。额外发现：我们将所有这些与相同查询的Google/Bing前十结果进行了比较。URL级别重叠：3.3%（120个SERP位置中有4个匹配）。所有4个匹配均来自Bing。Google：零。注意事项：4个查询来自同一个B2B类别，每个系统N=10（±15–20 pp），单日快照，字段解码来自流量分析的假设。很乐意回答有关方法的任何问题。如果有人在他们的会话中捕获了不同的字段名，我很愿意进行比较。