AI助手引用来源的技术原理

两条路径，只有一条留下痕迹

当一个 AI 助手回答关于你公司的提问时，发生了两件事之一，而这两件事彼此并不相同。

在参数化路径（parametric path）上，模型依靠自身权重作答。没有发起任何请求、没有进行任何搜索，你的服务器也未收到任何请求。它所说的关于你的一切都来自训练语料中的文本，这些文本可能已是数年前的旧料，可能是关于你的第三方摘要，甚至可能是另一家名字相似的公司。如果它在这条路径上生成了一个 URL，那这个 URL 是逐 token 生成的，和其他字符串一样——这就是为什么生成指向不存在页面的可信链接是一种公认的失败模式，而非 bug。

在接地路径（grounded path）上，检索步骤先于一切运行。系统会发起搜索查询、获取文档、将文本放入上下文窗口，然后让模型基于这些内容作答。这条路径会触及你的服务器，页面上所有你可以验证的内容之所以可以验证，正是因为这次触及。

因此，关于任何 AI 助手声称内容的第一诊断问题是：它来自哪条路径，而且通常你可以辨别：接地生成的回答会展示来源，并伴随一个可见的延迟；参数化回答则立即出现且不带任何链接。这很重要，因为两种失败模式需要完全不同的补救措施——这正是纠正 AI 助手关于你的言论这一话题的核心。

逐步解析接地管道（The Grounded Pipeline）

不同实现有所差异，但阶段都是相同的——任何检索增强系统都具备这些阶段，因为这些 AI 助手本质上就是检索增强系统。按顺序如下：

每个阶段都是一个过滤器。一页能存活到引用列表，意味着它通过了全部七个阶段，而任何阶段的失败从外部都不可见——没有错误消息，没有报告。这个领域大多数有价值的工作都在于弄清楚你卡在了哪个阶段。

搜索后端处于一切的上游

检索阶段本质上是网络搜索。AI 助手的搜索来源有三种方式：授权商业搜索 API、自建爬虫和索引，或者两者兼有并合并结果。每种情况的后果相同，而这是该领域最未被充分陈述的事实：如果后端索引对于重写后的查询没有返回你的 URL，那么下游任何优化都无法引用你。再多的页面级优化也无法触及一份从未进入候选列表的文档。

这就使得传统的索引卫生状况成为地板而非人们常说的遗留问题。可被抓取、在 sitemap 中、被解析为每个主题一个规范 URL，以及针对重写问题所产生的长尾表述有排名——这些都是前置条件，详见检索友好的站点架构。重写器产生的查询往往呈现长尾特征：比人类输入更长、明确限定范围、常常带有用户只是暗示了的限定词。

任何特定 AI 助手使用哪个后端是商业合作，会在无公告的情况下变更，多个运营商已变更过不止一次。不要把任何关于谁为谁建立索引的具体说法当作准数——读到的那天就已过时，也不要在此基础上制定策略。

上下文预算决定有多少来源存活

组装阶段有一个硬性限制，即使不知道确切数字，你也可以通过算术推算。假设系统为检索到的材料分配了 8000 个 token 的上下文。对于英文 prose 每个 token 约四个字符来算，这大约是 32000 个字符。如果分块器（chunker）发出 600 token 的块，那么预算总共能容纳约 13 个块——这些块来自所有获取的文档，而非每个文档独占。

budget            8,000 tokens of retrieved context
chunk size          600 tokens
chunks that fit    8,000 / 600  ≈ 13
documents fetched  10
chunks per doc     13 / 10  ≈ 1.3

因此，引用真实的单位是一段话（passage），而非一页（page）。你的页面不是以页面为单位参与竞争；它的 200 词片段是在与另外 9 个页面的 200 词片段竞争。这一事实解释了在写作中让一个段落能够独立成立的大部分有用原则，也解释了为什么一个组织良好的长页面每个 section 有一个答案，其表现优于同样的内容分散在五个单薄 URL 上。

上面的数字是形状的说明，而非任何产品的实测。没有任何运营商公布其预算或分块大小，而且同一助手的高速和低速模式的配置也不同。不会改变的是：预算存在，而且相对于整个 web 而言很小。

引用是附加的，不是派生出来的

这是大多数解释都弄错的阶段。模型不会记录哪个文档生成了哪个词。它生成文本，而引用标记是生成文本的一部分——与所有其他内容一样，由下一个 token 过程产生。因此，一个标记是对哪篇来源相关的预测，而非来源的记录。

随之产生两个后果，而且两者在现实中都可以观察到。一句话可以携带一个来源的引用，但该来源并不包含这个声明——因为该来源曾在上下文中且看起来主题相关。一句被获取文档支持的话也可能没有被引用，因为标记根本没有被发出。系统通过事后验证环节来缓解这个问题——用第二次模型调用对照引用的块重新检查每个句子——这能减少第一种失败，但对第二种毫无帮助。

如果你是在构建这个系统而非受其影响，你自己的技术栈中同样问题的讨论参见让检索增强回答正确引用来源和将模型接地到来源。

你能从自己的服务器观察到什么

四件事，均为二级可观测（tier-2 observable），无需任何来自供应商的东西：

是否发生了获取。向 AI 助手提出一个你的网站是最显而易见答案的问题，然后在接下来 60 秒内查看你的访问日志。用户发起的获取携带一个独特的 User-Agent 标记——ChatGPT-User、Claude-User、Perplexity-User 及其同类，与同一运营商的批量爬虫是分开的——正因为如此它们可以区分。

它选择了哪个 URL。日志行中的路径告诉你后端提升了你的哪个页面，这是检索阶段的直接读数。

它收到了什么。状态码、字节数和内容类型。如果 fetcher 收到一个 200 状态但只有 900 字节，说明它拿到的是个空壳，而非文章。

访问者是否跟进了。来自 AI 助手主机的 Referer 出现在同一日志中，这是该领域中真正属于你的唯一点击数据。

将那些日志行从普通流量中分离出来，以及确认一个 Agent 身份的工作，在找出哪些 AI 爬虫访问过你中有完整介绍。

如果你是在构建接地路径而非测量他人的，决定质量的关键阶段是基于检索块生成内容，在确定之前用同一提示在多个模型上测试是值得的。Multigrid 在一个 API 背后暴露了这些模型，使你检索的一半管道保持固定而只改变模型——这是将变化归因于其中一个部分的唯一方法。

没有任何外部实验室能观察到的

直说，因为这个领域销售的所有东西都卖得好像这些是已知的一样：

后端的排序函数。你的页面是候选第三还是候选第三十，不对外暴露。

分块器。块大小、重叠方式，以及是否尊重标题结构。

选择分数。为什么你的某段被保留而另一段被丢弃。

预算。有多少块最终入选，来自多少文档。

因果关系。句子旁边的引用是否是该句子真正的来源。

任何声称优化了其中一项的人，都在声称访问了没有任何公开文档描述的东西。诚实的姿态是优化你能看见的阶段，而将其余的描述为它本来的样子。

对于站点所有者意味着什么

按重要性排序三件事。第一，要存在于后端索引中，因为检索在所有策略的上游，下游没有任何东西可以弥补缺失。第二，在第一次 HTTP 响应中为 fetcher 提供实际文本，因为大多数站点在获取阶段无声地失败——关于爬虫在页面需要 JavaScript 时看到什么的内容，用一条命令测试。第三，写出能够独立被提取出来的段落，因为被选中的是段落的单位。

除此之外的一切，在写这篇文章的时候，都是关于不可观测阶段的声称。这不意味着它是假的。这意味着你不应该把它当作已确立的东西来付费。