一、问题的起点：当同一个品牌在不同 AI 平台被“不同称呼”
在生成式 AI 评测实践中，有一个问题远比想象中复杂——同一个被测对象，在不同平台、不同问题的 AI 回答中，可能以完全不同的名称出现。
举个例子：某运动品牌在豆包的回答里被称作“安踏”，在 DeepSeek 的回答里却出现了“ANTA”“安踏体育”“安踏集团”等多种写法；某 SaaS 产品在通义千问中被写为完整公司名，到了 Kimi 那里只剩下简称。更麻烦的是，有些 AI 回答根本不提品牌名称，而是用一段解释性文字描述这个品牌，比如“那个主打性价比的国产运动鞋品牌”。
如果评测系统不能把这些不同称呼统一识别为同一个对象，后续的提及率、推荐率计算就失去了基础。这也是我们做多平台 AI 回答评测时，必须首先解决的工程问题：从杂乱的非结构化文本中，准确识别、归一化并关联同一个被测对象。
本文将从数据工程视角，系统梳理多平台 AI 回答样本的清洗、品牌别名合并、无效样本过滤、解释文本对齐、差异标签处理以及指标聚合的完整流程。
二、多平台采样的数据结构
一个标准的多平台 AI 评测采样任务，通常会产生如下数据结构：
字段 说明 示例
platform AI 平台名称 deepseek / doubao / tongyi
question_id 问题唯一标识 Q20260701_001
intent_category 用户意图分类 推荐决策 / 对比分析 / 品牌认知
raw_answer AI 原始回答全文 完整文本，可能含 Markdown、列表等
sample_time 采样时间戳 2026-07-01 14:30:00
round_num 同一问题的采样轮次 1 / 2 / 3
单个测评任务可能包含多个被测品牌、数十个问题、多个平台、多轮采样，最终形成数百甚至数千条独立样本。第一步工作就是把这些原始样本纳入统一的清洗管道。
三、品牌别名合并：从“多名称”到“唯一实体”
这是整个流程中工程复杂度最高的环节之一。我们需要建立一个 品牌实体字典，将同一对象的全称、简称、英文名、产品名、常见别称甚至历史曾用名全部映射到同一实体 ID。
3.1 字典构建规则
text
实体ID: BRAND_001
主名称: 安踏
别名列表:
- ANTA
- 安踏体育
- 安踏集团
- Anta Sports
- 安踏品牌
正则匹配: /安踏|ANTA|Anta/i
排除条件: 非运动鞋服语境下的“安踏”（如地名、人名）
这个字典需要持续维护，因为 AI 模型在不同时期、不同版本中可能演化出新的称呼方式。实践中我们发现，AI 有时会自己“发明”一些非正式但语义正确的称呼，比如把某品牌称为“那个福建的运动品牌”，这种情况就需要进阶的语义匹配来处理。
3.2 别名识别的三个层级
第一层：精确匹配。 直接对 AI 回答文本进行字符串匹配，识别字典中所有已知的精确名称。这一层速度快、准确率高，但漏检率也高。
第二层：模糊匹配与正则。 处理英文大小写变体、中英文混排、特殊字符间隔等问题。例如“A N T A”或“安踏（ANTA）”这类写法。
第三层：语义指代识别。 这是最难处理的一层。AI 可能说“这个品牌”“该公司”“前述企业”，需要结合上下文判断指代对象。目前的做法是将包含指代词的段落与前置文本拼接，再通过实体链接模型判断指向。
三层识别结果合并后，同一回答中对同一品牌的多次出现会去重——单次回答中每个品牌最多计一次提及。
四、无效样本过滤：不是什么回答都算数
采样过程中会不可避免地产生无效样本，需要在清洗阶段识别并隔离。常见无效样本类型包括：
4.1 AI 拒绝回答
text
“抱歉，我无法提供品牌推荐。”
“这个问题超出了我的知识范围。”
“建议您自行搜索相关信息。”
这类回答没有提供实质性信息，不计入有效样本。
4.2 回答明显偏离问题
问题问的是“有哪些值得推荐的国产运动鞋品牌”，AI 回答却在讨论运动鞋的材料科技发展史，完全没有品牌信息。这种偏离会被标记为“意图不匹配”，从品牌识别统计中排除。
4.3 回答内容过短或无信息量
“好的。”“可以。”“了解了。”这类不包含任何品牌信息的极短回答，同样归为无效。
4.4 乱码、截断、格式异常
API 返回异常、超长文本截断、编码错误导致乱码等情况，直接标记为异常样本，不计入有效统计。
4.5 过滤策略的边界控制
无效样本过滤需要把握一个平衡：过滤太严可能丢失真实但表达不规范的样本，过滤太松可能引入噪声。我们的做法是对过滤后的无效比例设置监控阈值——如果某个平台或某类问题的无效比例异常偏高（超过 20%），就需要人工抽查确认是否存在系统性偏差。
五、解释文本对齐：当 AI “解释”品牌而不是“提及”品牌
这是多平台评测中一个容易被忽视但影响很大的场景。
有些 AI 回答不会直接说出品牌名称，而是用一段解释性文字来描述一个品牌。例如：
“有一个国内品牌以高性价比著称，近年来在跑步和篮球鞋领域都有不错的口碑，签约了多位 NBA 球星。”
这是对安踏的描述，但“安踏”这两个字完全没有出现。从严格的字符串匹配角度看，这是“未提及”。但从用户信息获取的角度看，AI 实际上已经在向用户传达关于这个品牌的关键信息。
5.1 解释文本对齐的方法
我们引入了一个 解释文本对齐模块，核心逻辑是：
对 AI 回答中的非品牌名称描述段落进行实体属性抽取；
将抽取到的属性组合（行业、定位、特征、事件等）与已知品牌的知识图谱进行匹配；
匹配置信度超过阈值时，将该段落标记为对某品牌的“隐性解释”，并赋予特殊标签 mention_type: implicit；
在指标计算时，隐性解释不计入标准提及率，但单独作为“解释能力”维度的分析数据。
这样做的价值在于：我们既能保持提及率定义的严格性（只有明确名称才算提及），又能捕捉到 AI “知道这个品牌但没用名字说出来”的情况，这对品牌 AI 心智诊断有重要意义。
六、差异标签体系：不只是“提到没提到”
清洗和对齐完成后，每个品牌在每个有效样本上会被打上一组标签。这套标签比简单的“提及/未提及”要丰富得多：
标签维度 可能取值 说明
mention_status explicit / implicit / none 明确提及 / 隐性解释 / 未出现
recommend_status recommended / mentioned / negative / none 被推荐 / 仅被提到 / 负面提示 / 无
sentiment positive / neutral / negative / mixed 语义倾向
position_rank 1 / 2 / 3 / unranked 在推荐列表中的位置
citation_status with_source / without_source 是否有引用来源
risk_flag true / false 是否存在负面风险信号
is_anomaly true / false 是否为异常样本
这个标签体系的工程意义在于：将非结构化的 AI 回答转化为结构化的、可计算的特征向量，后续所有指标聚合都建立在这套标签之上。
七、指标聚合：从样本标签到可比较的分数
有了每一条样本上的标签数据，下一步就是按被测对象聚合指标。以品牌为单位进行聚合计算。
7.1 提及率计算
text
提及率 = 有效提及次数 / 有效样本总数 × 100%
有效提及：mention_status = explicit，且 is_anomaly = false
同一问题在同一平台的多轮采样中，每轮独立计算，不合并
分母排除无效样本和异常样本
7.2 推荐率计算
text
推荐率 = 有效推荐次数 / 有效样本总数 × 100%
有效推荐：recommend_status = recommended
单次回答中一个品牌最多计一次推荐
“推荐”的判定标准：AI 将品牌作为建议、首选、备选、值得考虑的对象输出，而不是简单罗列
7.3 综合得分的加权逻辑
综合得分不是简单把提及率和推荐率相加，而是引入场景权重：
推荐决策类问题（用户问“有什么推荐”）中的推荐，权重高于信息导航类问题（用户问“什么是 XX”）中的提及；
购买意图类问题（用户问“选哪个好”）中的正向推荐，权重更高；
多平台稳定出现比单个平台偶尔出现，获得额外稳定性加权；
负面风险标签会对综合得分产生下调影响；
解释能力（包括隐性解释的准确度）作为补充维度参与评分，但不主导总分。
具体的权重系数根据测评任务类型动态调整——品牌认知类测评更看重提及率和解释准确性，推荐决策类测评更看重推荐率和推荐排序。
八、跨平台一致性与差异分析
多平台评测的核心价值之一，就是观察同一品牌在不同 AI 平台上的表现差异。聚合完成后，我们会生成一个 平台差异矩阵：
text
豆包 DeepSeek 通义千问 Kimi
品牌A提及率 78% 82% 71% 85%
品牌A推荐率 45% 51% 38% 49%
品牌B提及率 62% 58% 65% 60%
...
这个矩阵帮助企业回答一个问题：我的品牌是在某个 AI 平台上表现不好，还是在所有 AI 平台上都有问题？
如果所有平台表现一致偏低，问题可能出在品牌的公开信息覆盖度和内容质量上；
如果仅某个平台表现偏差，可能与平台的模型特性、联网机制或数据源差异有关；
如果某平台的推荐率显著低于提及率，说明品牌虽然被 AI 知道，但 AI 不愿意主动推荐，可能需要关注品牌在 AI 认知中的竞争定位。
九、流程工程化：从手工到管道
上述流程如果在每个测评项目中手工执行，效率低且难以保证一致性。因此我们将整个流程工程化为一个可配置的数据处理管道：
text
原始样本采集 → 格式校验 → 无效过滤 → 别名合并 →
实体识别 → 语义标签 → 解释对齐 → 标签生成 →
指标聚合 → 差异分析 → 结果输出
每个环节的输出都有 Schema 约束，环节之间通过数据质量检查点连接。异常样本自动标记后进入人工复核队列，边界案例由人工判断后更新规则库。
这套管道的设计原则是：机器处理确定性规则，人工处理边界判断。对于明确的字符串匹配、格式校验、简单规则过滤，完全自动化；对于语义模糊、指代不明、置信度处于阈值边缘的样本，进入人工复核。
十、流程的边界与持续迭代
最后需要说明这套数据清洗与指标聚合流程的边界：
数据具有时效性。 AI 模型版本更新、平台策略调整、品牌公开信息变化，都会影响测评结果。单次测评反映的是特定采样时间窗口下的状态，连续监测的变化趋势比单点数据更有参考价值。
指标不等同于事实。 提及率、推荐率反映的是 AI 回答中的信息呈现状态，不等同于品牌的市场份额、产品质量或用户满意度。AI 回答中出现的负面信息也需要结合事实核查，不能直接等同于品牌存在问题。
流程持续迭代。 随着 AI 平台增多、模型能力增强、回答形式多样化（如图片、表格、结构化数据），数据清洗和指标聚合流程也需要持续升级。目前的管道主要处理文本回答，未来需要扩展多模态回答的识别能力。
在多平台 AI 评测中，数据清洗和指标聚合不只是技术细节，而是决定评测结果是否可信的基础工程。品牌别名能不能合对、无效样本能不能滤干净、解释文本能不能对齐、差异标签能不能打准——这些环节中的每一个判断，都会影响最终呈现给企业的数据图景。
对技术团队而言，把“感觉某个品牌在 AI 里表现不错”转化为“在多平台、多问题、多轮采样下，该品牌的提及率为 X%，推荐率为 Y%，在推荐决策场景中排名第 Z”，中间的差距就是这套数据工程管道要解决的问题。
