品牌别名、解释文本和场景标签：AI回答数据清洗实践

一、从非结构化文本到可量化指标

向AI平台批量提问获取品牌相关数据，听起来是一个直接的操作。但当你面对成百上千条AI回答时，真正的问题才开始浮现。

品牌名称以各种形态出现——全称、简称、英文名、产品名、错别字——同一个实体被拆分成多个不同的字符串；回答中既有对品牌的客观描述，也有带有明显推荐倾向的表达；不同问题类型下，品牌被描述的方式和质量也各不相同。要从这些非结构化文本中提取出有意义的指标，数据清洗是绕不开的一步。

本文从数据工程角度，分享一套从AI回答采集到品牌解释能力指标输出的实践流程，重点涉及无效样本过滤、品牌别名合并、解释文本抽取、场景标签分类和指标聚合五个环节，并结合阿里云DataWorks + MaxCompute给出可落地的实现方案。

二、整体数据流程

整个处理链路分为六个阶段：

每个环节都需要记录处理状态和关键决策，保证从最终指标可以追溯到原始回答——这是数据可信度的基础保障。

三、无效样本过滤

3.1 需要剔除的样本类型

采集到的原始回答中，有一定比例无法用于后续分析：

3.2 清洗实现

在MaxCompute中通过UDF实现清洗逻辑：

INSERT OVERWRITE TABLE valid_samples PARTITION (dt='${bizdate}')
SELECT 
    id, platform, question, answer, intent_category
FROM raw_answers
WHERE is_valid_answer(answer) = TRUE;

清洗函数的判断逻辑：

public class AnswerValidator {
   
    public boolean validate(String answer) {
   
        // 空值或过短
        if (answer == null || answer.trim().length() < 20) {
   
            return false;
        }
        // 拒答信号匹配
        String[] rejects = {
   "无法回答", "不能提供", "无法提供", 
                            "cannot answer", "I cannot", "sorry"};
        for (String kw : rejects) {
   
            if (answer.toLowerCase().contains(kw.toLowerCase())) {
   
                return false;
            }
        }
        // 重复内容检测
        return !hasExcessiveRepetition(answer);
    }
}

注意：拒答关键词列表需要持续维护——不同AI平台、不同模型版本的拒答表达方式存在差异，应定期review过滤日志，补充新的拒答模式。

四、品牌别名合并

4.1 别名来源分析

同一个品牌在AI回答中可能以多种名称出现，这在数据统计中会造成严重的实体分裂问题：

• 全称与简称：“绿雪智能科技有限公司” vs “绿雪智能” vs “绿雪”
• 中文与英文：“阿里巴巴” vs “Alibaba”
• 产品名与公司名：“通义千问” vs “阿里云”
• 错别字或变体：输入错误导致的变体
• 隐性指代：“该公司”“该品牌”——这类需要结合上下文判断

如果不做别名归一化，同一个品牌将被拆分成多个实体统计，提及率等指标会失去参考价值。

4.2 别名映射方案

采用自动发现 + 人工确认的两阶段策略：

自动发现：基于品牌名称共现分析、编辑距离计算、拼音相似度匹配，自动生成候选别名对。

人工确认：对置信度较低的候选对进行人工复核确认。同时，对同名不同实体的情况（如“苹果”指科技公司还是水果）进行消歧标注。

别名映射表结构：

CREATE TABLE brand_alias_mapping (
    canonical_id STRING COMMENT '标准品牌ID',
    canonical_name STRING COMMENT '标准名称',
    alias_name STRING COMMENT '别名',
    alias_type STRING COMMENT '简称/英文/产品名/错别字',
    status STRING COMMENT 'active/pending/rejected'
);

4.3 在ETL中执行合并

SELECT 
    COALESCE(m.canonical_id, 'UNKNOWN') AS brand_id,
    COALESCE(m.canonical_name, extracted.brand_raw) AS brand_name,
    extracted.sample_id,
    extracted.platform
FROM brand_extraction_results extracted
LEFT JOIN brand_alias_mapping m 
    ON extracted.brand_raw = m.alias_name 
    AND m.status = 'active';

五、解释文本抽取

5.1 什么是解释文本

“解释能力”关注的是AI是否能准确、清晰地描述一个品牌。要量化这个能力，首先需要从回答中定位出与目标品牌直接相关的描述性文本片段，而不是整个回答。

解释文本的典型形态包括：

• 功能介绍：“A品牌是一款面向企业级市场的SaaS工具……”
• 定位描述：“B品牌定位于中小企业客户的数字化服务……”
• 特征说明：“C品牌的特点包括全面集成和可扩展性……”
• 背景介绍：“D品牌成立于2018年，总部位于深圳……”

5.2 解释文本抽取方法

解释文本抽取本质上是在回答中定位与目标品牌相关的描述性句子或段落。实践中采用规则定位 + 模型抽取的组合方式：

规则定位：基于品牌名称在回答中的出现位置，提取品牌首次出现后的一段上下文（如前后各2句），作为候选解释文本。

-- 基于位置截取品牌周围的描述语句
SELECT 
    sample_id,
    brand_name,
    -- 提取品牌出现位置前后各2句
    extract_surrounding_sentences(answer, brand_position, 2) AS explanation_text
FROM samples_with_brand_positions;

模型抽取：对于规则无法精确定位的情况，使用文本抽取模型（如基于BERT微调的Span抽取模型）识别品牌相关的描述性片段，过滤掉仅提及名称但无实质描述的情况。

5.3 解释文本的质量评估方向

抽取出的解释文本可以用于多个质量维度的分析：

• 长度充分性：解释文本是否过短（少于10个词），可能意味着AI无法提供足够信息
• 信息密度：解释中是否包含具体的事实性信息，而非泛泛描述
• 表述稳定性：同一品牌在不同问题、不同平台中，解释文本的核心信息是否一致

这些维度可以进一步转化为可量化的解释能力指标。

六、场景标签分类

6.1 场景分类的必要性

一个品牌被AI“解释”的方式，会因问题类型的不同而存在明显差异。在“品牌认知”类问题（如“A品牌主要是做什么的？”）中，AI倾向于提供较为详实的描述；在“推荐决策”类问题（如“有哪些值得推荐的品牌？”）中，品牌往往只作为列表项被简单提及，解释的充分程度有所不同。

因此，解释能力的评估需要按场景维度进行细分，而不是笼统地计算一个全局指标。

6.2 场景定义与标签生成

常见的问题场景分类：

标签生成采用规则匹配优先 + 分类模型兜底的策略：

SELECT 
    sample_id,
    question,
    CASE 
        WHEN question REGEXP '推荐|选哪个|哪家好|值得买' THEN 'REC'
        WHEN question REGEXP '区别|对比|相比|哪个更' THEN 'CMP'
        WHEN question REGEXP '购买|价格|多少钱|采购' THEN 'PUR'
        WHEN question REGEXP '场景|适合|解决方案' THEN 'SCN'
        WHEN question REGEXP '是什么|什么意思|介绍' THEN 'NAV'
        WHEN question REGEXP '靠谱|安全|风险|问题' THEN 'RIS'
        ELSE model_predicted_scene(question)
    END AS scene_tag
FROM valid_samples;

七、指标聚合

7.1 核心指标定义

完成清洗、归一化、解释抽取和场景分类后，按品牌、场景维度进行指标聚合：

7.2 多维度聚合实现

SELECT 
    brand_id,
    brand_name,
    scene_tag,
    COUNT(DISTINCT sample_id) AS sample_count,
    COUNT(DISTINCT CASE WHEN is_mentioned = 1 THEN sample_id END) AS mention_count,
    COUNT(DISTINCT CASE WHEN is_mentioned = 1 AND explanation_length >= 10 
                        THEN sample_id END) AS sufficient_explain_count,
    ROUND(mention_count * 100.0 / sample_count, 2) AS mention_rate,
    ROUND(sufficient_explain_count * 100.0 / NULLIF(mention_count, 0), 2) AS explain_sufficiency_rate
FROM labeled_samples
WHERE is_valid = 1
GROUP BY brand_id, brand_name, scene_tag;

7.3 综合解释能力评分

解释能力综合评分可以基于以下维度加权：

解释能力评分 = α × 解释充分度 + β × 解释稳定性 + γ × 场景覆盖度

• 解释充分度：品牌被提及的回答中，获得实质性描述的比例
• 解释稳定性：同一品牌在不同平台、不同采样轮次中解释文本的一致性
• 场景覆盖度：品牌在不同类型问题中是否都能获得有效解释

不同场景的权重配置应有所差异：信息导航类问题对解释充分度的要求更高，推荐决策类问题则更看重提及率。

八、数据质量保障

8.1 全链路可追溯

每个处理阶段记录状态，保障数据可信度：

CREATE TABLE pipeline_audit (
    sample_id STRING,
    stage STRING COMMENT '采集/清洗/归一化/解释抽取/场景分类/聚合',
    status STRING,
    detail STRING,
    created_at DATETIME
) PARTITIONED BY (dt STRING);

当某个品牌指标出现异常时，可以通过审计日志快速追溯问题发生在哪个环节。

8.2 质量检查点

• 归一化准确率：每周抽样检查别名合并的准确性，确保没有漏合并或误合并
• 解释抽取质量：定期评估抽取的解释文本是否准确反映了品牌描述
• 场景分类一致性：验证同一批数据在不同处理批次中的场景标签是否一致

8.3 人工复核触发条件

以下情况需触发人工复核：

• 品牌名称存在歧义，自动映射置信度低
• 抽取的解释文本长度异常（过短或过长）
• 某品牌在特定场景中的解释充分度出现大幅波动
• 新增品牌不在别名映射表中

九、实践总结

从AI回答到品牌解释能力指标的输出，数据工程的核心工作集中在几个关键环节：

品牌别名合并是数据归一化的基础，直接决定了按品牌维度统计的所有指标是否可靠。采用自动发现加人工确认的混合策略，关键在于建立可持续维护的映射表管理机制。

解释文本抽取是一个信息定位问题。在非结构化的回答中精准定位品牌相关的描述性内容，需要结合位置规则和语义模型。抽取质量直接影响后续解释能力评估的准确性。

场景标签分类让指标分析更有针对性。同一个品牌在信息导航类问题中的解释充分度，与在推荐决策类问题中的解释充分度，反映的是不同维度的能力，不能混为一谈。

在技术实现层面，上述流程基于DataWorks进行任务编排调度，MaxCompute承担核心ETL计算。这套架构的核心优势在于计算能力的弹性以及数据链路的可追溯性——当指标口径需要调整时，可以重新计算历史分区数据，而不需要重新采集。

需要说明的是，任何基于AI回答的数据分析都有其时效性边界。AI平台的模型版本、数据更新策略会随时间发生变化，因此指标结果反映的是特定采样窗口内的状况。相比单次结果，持续监测下的变化趋势和波动区间更有参考价值。