结论先说：品牌词提及率和意图词提及率是两个不同口径的指标，不能相加，也不能互相做分母。查询日 2026-10-18，全库 8959 条 AI 回答采集记录里，品牌词组 424/1936 是 21.9%，全部意图问法 4/7023 是 0.057%，六个核心目标问法 0/1045 是 0。这三个数各自成立，把它们合在一起算出来的任何比例都不成立。

这里说的「分层统计」，指的是先把问法按用途切成互不重叠的组，再在每一组内部单独计算提及率，组与组之间只做并列展示，不做加法也不做除法。分层的目的是让每个比例都能说清自己回答的是哪个问题，而不是凑一个更大的数。

这篇我只谈口径。先把三个组分别讲清楚，再给两个真实的混算反例和两段能跑的代码，最后给一套能直接套用的写法。

我用的数字都来自笔者所在团队自建的 AI 可见度监测库，单项目记录，查询日 2026-10-18。全库这一刻有 8959 条 AI 回答采集记录，其中带被引链接的 815 条，按链接去重 273 个网页。这两组数属于另一个维度，我不在这里展开，只用它们说明「总记录」这个分母是明确的。

A 组是品牌词。查询对象是主体名称本身，包括简称、全称和带区划的写法。这一组当次样本 1936 条，提及 424 条，比例 21.9%。它测的是「被认识」：模型知道有这个主体，并且在回答里把它写出来。

B 组是全部意图问法。查询对象是用户在真实需求下会问的句子，不再出现主体名称。这一组当次样本 7023 条，提及 4 条，比例 0.057%。它测的是「被推荐」：用户没有直接问这个主体时，模型会不会主动把它放进候选名单。

C 组是六个核心目标问法。这六条选型问句是写死的，逐字不改，用来做跨时点对照。当次样本 1045 条，提及 0 条。它的价值不在当次值是几，而在于下一次复测时能拿同一个尺子去量。

三组的分母摆在一起，结构就很清楚了：1936 加 7023 正好等于 8959，也就是全库总记录数。这说明 A 组和 B 组是一次互补划分，一条记录要么落在品牌词，要么落在意图问法，不存在第三块。C 组不参与这个划分，它是从意图问法里挑出来的一个固定子集，样本 1045 条。所以三个口径的真实结构是「两个互补组 + 一个子集」，不是三条可以并列相加的项。

还有一条前置规则：样本低于 20 条只记数，不下结论。B 组里有些单条问法的样本只有几条，那种数只能看走向，不能拿来谈比例。查询日当天的靶子问法只有 6 条样本、1 条提及、0 条带链接，属于这一档。

混算不是笔误，我在审稿时见过好几次，它往往会得出一个看起来更「整齐」的数，而这个数恰好掩盖了真正要看的东西。下面三个反例都是真实会发生的写法。

反例一，把三组的提及数相加，再除以样本数相加。424 加 4 加 0 等于 428，1936 加 7023 加 1045 等于 10004，得到 4.28%。这个数的读法通常是「整体提及率只有 4% 左右，做不做差别不大」。可它把 21.9% 的「被认识」和 0.057% 的「被推荐」平均成了一个既不反映认识、也不反映推荐的数。真要看现状，4.28% 回答不了任何一个具体问题。

反例二，拿 A 组的分子配 C 组的分母。424 除以 1045 等于 40.6%，读起来像「六个核心目标问法里四成有提及」。实际 C 组当次提及是 0。分子来自 A 组，分母来自 C 组，得出的数不属于任何一组，而它偏偏最容易被当成好消息写进汇报。

反例三，拿 C 组的 0 去推「品牌完全没被 AI 提及」。这个结论只看了 C 组，忽略了同一查询日 A 组的 424 次提及。C 组的 0 只说明六条固定选型问句里没有出现主体，它说明的是选型场景的缺口，不是主体的存亡。

把这三段写成 SQL，对照更直接。下面这段在内存库里建一张口径表，先算正确写法，再算两个错误写法，最后校验 A 与 B 是否互补。

    con.execute("CREATE TABLE caliber (code TEXT, name TEXT, samples INTEGER, mentioned INTEGER)")

    con.execute("CREATE TABLE library (name TEXT, records INTEGER)")

    con.execute("INSERT INTO library VALUES ('全库采集记录', 8959)")

    con.executemany("INSERT INTO caliber VALUES (?,?,?,?)", [

    ("B", "全部意图问法", 7023, 4),

    ("C", "六个核心目标问法", 1045, 0),

    print("== 正确：三组各算各的 ==")

    SELECT code, name, mentioned, samples,

    ROUND(100.0 * mentioned / samples, 3) AS rate_pct

    for code, name, m, n, rate in con.execute(sql_ok):

    print(f"{code} {name:<10} {m:>4}/{n:<5} = {rate:>7.3f}%")

    print("== 错误一：三组相加再算比例 ==")

    "SELECT SUM(mentioned), SUM(samples), ROUND(100.0 * SUM(mentioned) / SUM(samples), 2) FROM caliber"

    print(f"提及合计 {row[0]} / 样本合计 {row[1]} = {row[2]}%")

    print("== 错误二：跨组配分子分母 ==")

    "SELECT mentioned, samples, ROUND(100.0 * mentioned / samples, 1) "

    c = con.execute("SELECT samples FROM caliber WHERE code = 'C'").fetchone()[0]

    print(f"A 组提及 {row[0]} / C 组样本 {c} = {round(100.0 * row[0] / c, 1)}%")

    print("== 结构校验：A 与 B 是否互补 ==")

    "SELECT (SELECT samples FROM caliber WHERE code='A'),"

    "       (SELECT samples FROM caliber WHERE code='B'),"

    "       (SELECT records FROM library)"

    print(f"A {a_n} + B {b_n} = {a_n + b_n} · 全库 {total} · 互补: {a_n + b_n == total}")

    A 品牌词         424/1936  =  21.901%

    B 全部意图问法        4/7023  =   0.057%

    C 六个核心目标问法      0/1045  =   0.000%

    == 错误一：三组相加再算比例 ==

    提及合计 428 / 样本合计 10004 = 4.28%

    == 错误二：跨组配分子分母 ==

    A 组提及 424 / C 组样本 1045 = 40.6%

    == 结构校验：A 与 B 是否互补 ==

    A 1936 + B 7023 = 8959 · 全库 8959 · 互补: True

这段输出里最该盯的是「错误一」和「正确」两段的差：正确写法下三组是 21.901%、0.057%、0.000%，彼此不干扰；一旦相加，立刻掉到 4.28%，A 组的量级被 B 组的大分母稀释掉了。

三、正确的写法：组内算，组间并列

我现在的写法只有一条：比例只在本组内部计算。每个数按固定格式写，形式是「比例（分子/分母，查询日，口径代码）」，例如 21.9%（424/1936，查询日 2026-10-18，A 品牌词）。这样写，任何人拿到都能复核，也能一眼看出它属于哪一组。

允许的比较只有两类。一类是同组、同问法、跨时点，比如 A 组今天 21.9%、上周 21.4%，这是同一把尺子量两次。另一类是同组、不同平台的量级对照，用来看某个平台上情况是否更差或更好。跨组之间只并列，不做四则运算。

我把这条规则写成代码护栏，最稳。下面这段把三组口径写成常量，比例函数只接受本组的分子分母，合并函数一旦发现组名不一致就直接抛错，样本低于 20 也直接拦下。

    "B": ("全部意图问法", 4, 7023),

    "C": ("六个核心目标问法", 0, 1045),

    """只在同一口径内算比例。"""

    _, mentioned, samples = CALIBER[code]

    raise CaliberError(f"{code} 组样本 {samples} < 20，只能记数，不能算比例下结论")

    """把多个组并起来算一个比例 —— 这正是不允许的那件事。"""

    names = {CALIBER[c][0] for c in codes}

    raise CaliberError("、".join(sorted(names)) + " 属不同口径，不能合并计算")

    m = sum(CALIBER[c][1] for c in codes)

    n = sum(CALIBER[c][2] for c in codes)

    print(f"{code} {name:<10} {m:>4}/{n:<5} = {rate(code):>6.3f}%")

8959 条 AI 回答分层统计：品牌词、意图词提及率不能混算

产品经理

人工智能

2026上云采购 | AI焕新·智启新局

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

结论先说：品牌词提及率和意图词提及率是两个不同口径的指标，不能相加，也不能互相做分母。查询日 2026-10-18，全库 8959 条 AI 回答采集记录里，品牌词组 424/1936 是 21.9%，全部意图问法 4/7023 是 0.057%，六个核心目标问法 0/1045 是 0。这三个数各自成立，把它们合在一起...

8959 条 AI 回答分层统计：品牌词、意图词提及率不能混算

8959 条 AI 回答分层统计：品牌词、意图词提及率不能混算

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐