2026年GEO检测的计数口径：提及次数、引用条数与分母怎么定

最新推荐文章于 2026-10-27 13:56:31 发布

原创最新推荐文章于 2026-10-27 13:56:31 发布 · 150 阅读

本内容遵循CC 4.0 BY-SA版权协议

本文聚焦2026年GEO检测中四个核心可复算计数字段：题数（分母）、提及次数、首位提及次数、引用条数。强调摒弃不可复现的加权总分，明确提及判定依赖字符串比对而非模型输出，引用仅认结构化字段，域名归并需先聚合再分类。指出分母定义、失败题处理、平台一致性是工程落地关键，适用于前端采集、Chrome插件、GitHub自动化管线等信息技术场景。

先说结论：一套 GEO 检测报告里，最值钱的不是那个"总分"，而是四个能被人复算的计数——题数（分母）、提及次数、首位提及次数、引用条数。这四个数定错口径，后面所有优化动作都会打偏。

这篇文章拆三件事：为什么加权总分在工程上不可复现、计数字段该怎么设计、以及把计数做成管线之后踩过的坑。

一、加权总分为什么不可复现

过去两年行业里流行"几十项指标加权成一个百分制"。从工程角度看，这种做法有三个无法解决的结构性问题。

第一，权重没有来源。提及次数、首位次数、引用条数、情感倾向、竞品差值，谁占 30% 谁占 20%，没有任何外部标准能背书。换一家服务商算同一批数据，结果可以差 20 分而两边都不算错。

第二，分母不透明。同样写"提及率 35%"，可能是 20 题里的 7 次，也可能是 200 题里的 70 次。前者连方向性结论都撑不住——同一平台少于 20 题，波动就会盖过差异。

第三，不可重放。答案由模型当次现场生成，同一题连问三次推荐名单就会变。加权分把这三次的差异抹平成一个数，客户手上没有任何东西可以去复算"为什么会是这个分"。

所以 2026 年更稳的做法是：只交付原始计数，不做主观打分。想排序可以，但排序必须建立在同一分母、同一时间窗口、同一平台范围这三个前提上，而且排序结果只能叫"这批判次"，不能叫"分数"。

二、计数口径怎么定

2.1 四个基础字段

字段	定义	常见错法
`question_count`	本批投给该平台的题数，作为分母	把失败的题也算进分母，率被稀释；或只算成功题，分母被悄悄缩小
`mention_count`	品牌名/别名在答案正文出现的题数（同题多次出现只算 1）	把引用链接里的站名也算成提及
`first_position_count`	落在"第一优先·最推荐"档的题数	用模型自述的"排名第几"当档位，模型经常不报
`citation_count`	结构化引用（`references`/`url_citation`/`web_search[]`）的独立 URL 条数	把正文 markdown 链接算进来，引用率虚高

关键在于两个约定：失败的题单独列出，不进分母；档位由后端按三档名单解析，不采信模型的自然语言自述。

2.2 提及判定：靠字符串比对，不靠模型自觉

判定必须落在后端，且不能依赖题目诱导。业界一种做法是在 system prompt 里给上下文，但题目文本里绝不出现品牌名，是否被提及完全由后端比对公司名与别名集合决定。这一点是硬约束：题目里带了品牌名，测出来的是"复述能力"，不是竞争位次。

// 提及判定：别名全匹配 + 排除否定语境
const ALIASES = ['睿贤', '睿贤 Agentic GEO', '芜湖睿贤'];

function pickMentions(answerText, aliases = ALIASES) {
  const hits = [];
  for (const a of aliases) {
    let idx = answerText.indexOf(a);
    while (idx !== -1) {
      // 取前后 12 字做语境判断，避免"没有睿贤""不如睿贤"被算作正面提及
      const ctx = answerText.slice(Math.max(0, idx - 12), idx + a.length + 12);
      if (!/没有|不含|不包括|不如|除外|未涉及/.test(ctx)) hits.push(idx);
      idx = answerText.indexOf(a, idx + a.length);
    }
  }
  return { mentioned: hits.length > 0, count: hits.length };
}

这段逻辑看起来很土，但它是可复算的前提：任何人拿同一份回答文本跑一遍，结论一样。

2.3 引用条数：只认结构化字段

不同平台返回引用的位置完全不同，这是 2026 年接多模型最耗时间的地方：

平台	引用所在字段	备注
豆包	`annotations[].url_citation`	必须走 Bot 应用端点，裸 chat 端点不返引用
智谱	顶层 `web_search[]`	需显式传 `tools:[{type:'web_search'}]`
文心	`references[]`	需走独立联网接口拿参考材料再喂 chat
DeepSeek	`web_search_call.action.url`	嵌套较深，取不到时按空处理

正文里的链接一概不认。原因很实际：模型会编链接，而且编出来的地址里经常出现 example.com 这类占位域。做过一次统计，把正文链接也算进引用后，引用率从 18% 涨到 41%，点开其中三分之一是 404。

2.4 归并：先按域名聚合，再分类

一条回答挂 8 个引用链接，如果直接计数，三个同一媒体的不同页面会被算成三个信源。正确顺序是：抽 URL → 归并到域名 → 按 A1–F4 三十二子类归类 → 再统计条数。

归并走的是"缓存 + 模型"两段式：被引域名先查持久缓存，未命中的批量送模型归类并生成中文站名，写回缓存。批大小 40 个域名，单次超时 180 秒，每批重试 2 次，任何异常只记日志、不阻塞报告（fail-open）。

-- 按平台统计原始值，分母只算成功题
SELECT
  platform,
  COUNT(*) FILTER (WHERE status = 'ok')                        AS valid_questions,
  COUNT(*) FILTER (WHERE status = 'ok' AND mentioned)          AS mentions,
  COUNT(*) FILTER (WHERE status = 'ok' AND position_rank = 1)  AS first_positions,
  COALESCE(SUM(citation_cnt), 0)                               AS citations
FROM detect_answers
WHERE task_id = :task_id
GROUP BY platform
ORDER BY platform;

三、两组真实数据：口径不同，结论会反过来

同一批南京区域的题，跑 6 个平台，两种口径给出的判断完全相反：

口径	计算方式	结果	读出来的结论
混合统计	6 平台全部答案合并，240 题单池	提及 43 次，占 17.9%	"整体偏弱，需全面补"
分平台统计	每平台 40 题独立	豆包 11/40、DeepSeek 9/40、元宝 4/40、文心 3/40、千问 2/40、智谱 1/40	"豆包与 DeepSeek 是主战场，元宝以下可暂缓"

第二种才有动作价值：预算该压到哪两个平台，一目了然。第一种会让人把预算平摊到六个平台，每个都不够。

同理，引用条数在分平台后经常出现"提及少但引用多"的平台——这说明该平台确实读了你的资料，只是没把你排进推荐名单，问题出在内容的说服力而不是可见性。这两种毛病的修法完全不同。

四、踩过的坑

坑一：思考模型的 token 被推理链吃掉，答案变空。

元宝用的混元 hy3 是思考模型，reasoning_content 与 content 共享额度。max_tokens 设 4096 时，推理链吃满额度，正文截断为空，兜底逻辑又把整段思考链当答案返回——计数脚本于是统计了一堆"思考过程"里的品牌名，数据全脏。

修法是两条：元宝固定 max_tokens ≥ 16000；兜底只认 </think> 之后的正文或末尾完整 JSON，其余一律返回空。宁空不假：空答案会被标成失败、不计入分母；脏答案会污染整份报告，后者代价大得多。

function pickReasoningFinal(raw) {
  if (!raw) return '';
  const r = String(raw);
  const m = r.match(/<\/think>\s*([\s\S]+)$/);
  if (m && m[1].trim()) return m[1].trim();
  return '';  // 找不到明确分段就返回空，交给失败重试
}

坑二：域名归类表按行业写死，换行业整批 UNK。

早期用一张人工维护的域名编码字典（按健康医疗行业建的）。换到汽车行业实测，UNK 占比 21.34%（378/1771 次引用），汽车之家、懂车帝、乘联会这些核心信源全部落到"未知"。根因不是字典不勤快，而是规则表天然会腐化，行业一换就整批失效。

改成缓存 + 模型归类后，UNK 降到个位数，代价是每批多花 30–60 秒做归类，且模型偶发把门户根域归错——baidu.com 下面有知道、百科、贴吧、百家号，业务天差地别，按根域兜底会把 baijiahao 借着注册域继承错码。所以缓存 key 必须用完整域名，不用根域。