AI 引用追踪

1. AI 引用追踪是什么

一套可重复执行的测量流程：先把提问集冻结下来，按固定节奏在事先声明的一组引擎上跑一遍，每条答案都采样、核验，并按同一套日志 schema 写下来。最终产出的是一条时间序列，告诉你被引用的频率有多高、出现的位置有多显眼，以及到底来自哪些引擎。

采集与定义分两条线：这里讲怎么采，GEO 指标 讲每一项指标具体是什么。文中每出现一个指标名，都会链回那一页的公式，定义只放一处，避免在两个地方各说一套。

引用追踪与提及追踪也不是同一件事。无链接的提及该怎么作为日常监控来做（在答案文本里识别、去重、按引擎归一），是更难、也更独立的一个问题，见 品牌提及追踪。这里只把提及当作日志的一个 appearance 取值（见 §4）顺带记录。

这套测量流程的整体形态是：

冻结的提问集（prompt set）→ 选定的引擎 → 采样得到的答案 → 经核验、归一的日志 → 变化量报告

交付方式有两种，且顺序固定：先手工（拿到基准事实），再自动化（做规模化）。这个先后不能颠倒，原因见 §4。

为什么这件事重要：「我们有没有被引用」是被问得最多的 GEO KPI 问题，而答错它（提问集有偏、指标定义混用）比不答更糟，因为一个看上去笃定、实际却错的数字，会被直接拿去做决策。正确的做法来自 GEO 最早的学术研究：与其只回答「是否被引用」这种非此即彼的问题，不如按出现位置的显眼程度给出一个连续的度量。这种位置加权的「呈现强度」（impression）思路，正是这一整套方法要落地的方向，见 Aggarwal et al. 2024；至于为什么排序链接时代那套指标在这里已经不再适用，见 生成式引擎优化。

2. 度量之前先定下的四个决策

下面四个决策，决定了你之后每一个数字到底是什么意思。任何一个定错，后面的数据都没法解读。

四个核心指标分别是：引用率（Citation Rate）、引用份额（Citation Share）、平均位置（Average Position，定义 A，即引用次序）、来源多样性（Source Diversity）；它们的定义依次在 GEO 指标 的 §3.2、§3.3、§3.5、§3.10。其他出现的指标，公式同样回到那一页查阅。

3. 第一步：构建提问集（你的测量工具）

提问集是 AI 引用追踪里最大的偏差来源（对应 GEO 指标 §7 列出的第 3 号陷阱）。提问集本身就是这个实验，要像设计一份调研问卷那样严谨地对待它。

规则：

• 从真实的用户意图去提炼提问，不要直接照搬你自己的关键词表。一个买家真正会在 ChatGPT 里敲下来的句子，会是什么样子？
• 规模：先做 30 到 50 条。少于 30 条左右，采样噪声会盖过信号；之后可以再扩。
• 各类别要均衡（商业类、信息类、对比类），不要让其中某一类意图主导整体均值。
• 冻结并打上版本号。 悄悄改提问，时间序列就失去了意义。要加提问，请开一个新版本号，不要在原地修改一个仍在使用的版本。
• 纳入版本控制：提问集是数据，不是配置。

有一种反面做法必须点名：专挑那些你本来就占优的提问。这样算出来的数字只会越来越好看，最终得到的策略也只是在服务一个被粉饰过的样本。

交付物是一个带版本号的 prompts.csv：

id,query,intent,category,locale,prompt_set_v,added_date,retired_date
q001,"best crm for startups",commercial,software,en,v3,2026-05-19,
q002,"how does retrieval augmented generation work",informational,technical,en,v3,2026-05-19,

4. 第二步：手工方法（一律从这里开始）

走到自动化之前，请先亲手把流程跑一遍。手工采样提供的是基准事实：它让你建立起对「在各个引擎里，被引用到底长什么样」的判断，不依赖任何厂商，也是日后核对你所购工具的唯一办法。

步骤：

1. 固定排期：同一批提问，固定在同一星期几、同一时间窗内采集。采集频率本身也是数据的一部分。
2. 每条提问、每个引擎都开一个全新会话：不要带登录状态，也不要带个性化历史。被个性化过的答案没法复现。
3. 原样记录答案以及它所引用的来源。 原始记录不可改动：指标只能事后从原始记录里推算出来，不能拿推算结果回头改原始记录。
4. 标注你的域名以何种形式出现：cited、mentioned 或 absent（依据 引用 vs 提及 的判定）。
5. 记下引用次序：你在该引擎的来源列表里排第几（这是平均位置定义 A 的输入）。

交付物是一行标准化的引用日志；§5 的自动化做法最终会沿用同一套 schema：

run_date           采样日期（UTC）
prompt_id          外键 -> prompts.csv
prompt_set_v       冻结提问集的版本号
engine             perplexity | chatgpt | google-aio | ...
appearance         cited | mentioned | absent
citation_rank      在来源列表里的整数位次（非 cited 时为 null）
source_url         引擎归属的网址（非 cited 时为 null）
citation_verified  true | false   （见 §4.1）
snippet            引擎实际取用的那句话或那一段

4.1 逐条核验引用（最常被跳过的一步）

AI 标注的来源网址只是它给出的一个说法，并不等于事实：这个网址可能打不开（404），也可能打开后根本支撑不了它所对应的那句话。这一步是 AI 追踪特有的，不能省略。

每个被引用的网址，只有在同时满足以下两点时，才记为 citation_verified = true：

• 该网址可以打开（没有失效，也没有跳转到一个不相干的页面），而且
• 该页面确实能支撑引擎拿它佐证的那句话。

已核验和未核验的引用要分开统计。一条臆造的、或站不住脚的引用，本身就是一个值得记录的发现。这类失效为什么常见到需要专门去测量，见 Liu et al. 2023《Evaluating Verifiability in Generative Search Engines》。

5. 第三步：自动化方法（手工跑通后再做）

请只把一个你已经验证过的手工流程拿去自动化。至于自建还是采购，要在确立这条规则之后再讨论。

各引擎的 API 现状（2026-05 核对）。 各家引擎之间，没有一个统一的、专门用来把引用结果返回给你的接口；每个引擎能做到什么，必须分别说清楚：

来源：Perplexity Chat Completions 参考 与 更新日志；OpenAI web search 工具；Google Search Central — AI features。

自动化的本质，就是在 §4 那套 schema 外面再加一层与具体引擎无关的薄外壳：

for engine in engines:
  for prompt in prompt_set_v:                  # 冻结、带版本号
    answer, sources = engine.ask(prompt)       # 全新会话，无历史
    appearance = classify(answer, sources, my_domain)   # cited|mentioned|absent
    rank       = citation_rank(sources, my_domain)      # 未引用则为 null
    verified   = url_resolves(src) and supports_claim(src, answer)   # §4.1
    log.append(run_date, engine, prompt.id, prompt_set_v,
               appearance, rank, source_url, verified, snippet)
# 此时 log 的 schema 与手工方法完全一致

采购路线。 如果你选择采购而不是自建，那么选哪个工具，其实更像是一个指标定义的问题：先去看 GEO 指标 §4 给出的厂商对照矩阵（Profound、Otterly、Ahrefs、BrightEdge、Similarweb 各自如何定义该 KPI），先认可哪一套定义，再据此选工具，而不是反过来。

6. 第四步：归一、存储、算出变化量

手工和自动化两条路现在共用同一套 schema，因此结果可以直接对比。两条存储规则：

• 原始答案不可修改。 把采到的答案与来源列表原样保存下来。
• 指标是推算出来的，不能手工改动。 如果某个数字看着不对，要去修正计算它的查询，而不是直接去改表格里的单元格。

从日志里算出几个核心指标的公式见 GEO 指标；下面给出的是查询的大致写法：

-- 引用率  （定义见 GEO 指标 §3.2）
SELECT engine,
       COUNT(*) FILTER (WHERE appearance = 'cited') AS cited,
       COUNT(*)                                     AS answers
FROM citation_log WHERE prompt_set_v = 'v3' GROUP BY engine;

-- 平均位置，定义 A / 引用次序  （GEO 指标 §3.5）
SELECT engine, AVG(citation_rank)
FROM citation_log WHERE appearance = 'cited' GROUP BY engine;

-- 来源多样性  （GEO 指标 §3.10）
SELECT COUNT(DISTINCT engine)
FROM citation_log WHERE appearance = 'cited';

这个变化是真的吗？ 一次周环比的波动，并不会自动等于一个真实结果。在你对外宣布「指标动了」之前，请先过一遍这张清单：

• 两次采样使用的提问集版本完全一致吗？
• 底层的引用数够多吗？总共才 5 条引用时的一次跳动只能算噪声；这也是 GEO 指标 在 First-Cite Rate 一节专门提示过的小样本风险。
• 两次采样之间，某个引擎有没有改过行为（例如模型或检索更新）？
• citation_verified 的比例变了吗？靠未核验引用堆积出来的增长不能算增长。

7. 第五步：报数时不要自欺

每一个对外报出的数字，都必须带上它的口径，否则跟任何数字都没法比：

• 提问集版本（例如 v3）
• 引擎集（具体是哪几个引擎，而不是笼统的「AI」）
• 时间窗（例如 7 天，每周采样一次）
• 算的是提及还是引用
• 位置定义（A、B、C，见 GEO 指标 §3.5）

一个不交代上述任何一项的「引用率 18%」，只是道听途说，不是指标。

不要急着把指标的变动直接解读成业务结果，也不要把话说过头：追踪能证明的是可见度的变化，不是营收的变化。要把可见度推到业务收益，得另用一套模型，见 GEO ROI 模型。

放到更大的闭环里看：这套追踪流程产出的是一份周期性快照，交给 GEO 审计 接续使用。追踪是日常的脉搏读数，审计是定期的全面体检。

8. 效度威胁与陷阱

把下面每一项都过一遍，再把报告发出去。每一项的更详细说明都在对应的链接里：

• 提问集偏差：被粉饰过、或没有版本号的提问集（§3；GEO 指标 §7）
• 时间窗偏差：长度不同的窗口本质上就是不同的指标
• 多语言混切：中文和英文的答案池不能加在一起（GEO 指标 §7）
• 提及与引用混算：把两者混为一谈会让结果虚高（引用 vs 提及）
• 位置定义混用：A、B、C 三者之间互不可比（GEO 指标 §3.5）
• 个性化泄漏：带登录、开了历史的会话没法复现
• 臆造或失效引用：把未核验的引用当成战绩上报（§4.1）
• 过度外推单方面的提升：你一家单独测出来的提升，等到竞争对手也针对同一个引擎做了优化之后，未必还能保持下去；见 Aggarwal et al. 2024 §6 里的 C-SEO Bench 提醒

9. 延伸阅读

• 定义层：GEO 指标、引用 vs 提及、品牌提及
• 业务视角：GEO ROI 模型
• 相邻操作：GEO 审计
• 逐引擎细节：Perplexity AI、ChatGPT Search、Google AI Overviews
• 学术源头：Aggarwal et al. 2024 — GEO: Generative Engine Optimization

参考资料

学术：

1. Aggarwal, P. et al. (2024). GEO: Generative Engine Optimization. KDD ‘24. arXiv:2311.09735 · ACM DL
2. Puerto, H. et al. (2025). C-SEO Bench: Does Conversational SEO Work? NeurIPS ‘25 D&B. arXiv:2506.11097
3. Liu, N., Zhang, T., Liang, P. (2023). Evaluating Verifiability in Generative Search Engines. Findings of EMNLP ‘23. arXiv:2304.09848

API 与平台文档（2026-05 已核对）：

• Perplexity — Chat Completions API Reference · Changelog
• OpenAI — Web Search tool (Responses API)
• Google Search Central — AI features and your site

厂商 KPI 方法论（采购路线，经 GEO 指标）：

• Otterly.ai — Brand Report KPI Definitions
• Ahrefs — Brand Radar Methodology