一、从非结构化回答到结构化样本库
向AI平台批量提问，获取回答文本，从中提取实体信息并形成量化指标——这个流程听起来清晰，但实际操作中，数据清洗才是真正的耗时点。
大语言模型返回的回答是典型的非结构化文本。品牌可能以全称、简称、英文名甚至错别字的形式出现；同一问题在不同平台或不同轮次中可能得到格式迥异的回答；推荐类问题可能输出列表、段落、表格等多种结构。要在这样的数据基础上做聚合统计，必须先经历一套系统性的清洗、归一化和标签化流程。
本文分享一套从多平台AI回答采集到场景样本库构建的实践方案，重点覆盖品牌别名合并、无效样本过滤、场景标签自动生成和指标聚合四个环节，并基于阿里云DataWorks + MaxCompute给出可复用的实现示例。
二、整体流程与架构
整个数据处理链路可以划分为五个阶段：
阶段 输入 输出 核心问题
采集 问题集 原始回答 多平台API调用与原始数据持久化
清洗 原始回答 有效样本集 剔除拒答、过短、格式异常的回答
归一化 有效样本集 标准化样本集 品牌别名识别与合并
标注 标准化样本集 带标签样本集 场景标签自动生成
聚合 带标签样本集 指标表 按品牌、场景、平台计算多维指标
数据在每一阶段的处理状态都需要被记录，确保从最终指标能够追溯到原始回答。这是数据可信度的基础保障。
三、无效样本过滤
3.1 无效样本的类型
采集到的AI回答中，有一定比例无法用于后续分析。根据实际运行统计，常见无效类型及大致占比：
无效类型 典型特征 处理方式
明确拒答 含“无法回答”“不能提供”等 规则过滤
内容过短 长度不足20字符 长度过滤
语义偏离 回答与问题主题无关 相似度过滤
格式异常 含乱码、截断或大量重复 规则+长度过滤
3.2 清洗实现
在MaxCompute中可以通过UDF实现组合清洗逻辑：
-- 清洗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
AND is_relevant(answer, question) > 0.3;
清洗函数的核心判断逻辑：
java
public class AnswerValidator {
public boolean validate(String answer) {
// 长度检查
if (answer == null || answer.trim().length() < 20) return false;
// 拒答关键词匹配（需持续维护）
String[] rejects = {"无法回答", "不能提供", "无法提供",
"cannot answer", "sorry", "I cannot"};
for (String kw : rejects) {
if (answer.toLowerCase().contains(kw.toLowerCase())) return false;
}
// 重复内容检测：若连续重复片段占比过高则判定无效
return !hasExcessiveRepetition(answer);
}
}
关键点：拒答关键词列表需要根据各平台的实际表现持续补充。不同模型版本的拒答方式存在差异，定期review被过滤样本是必要的维护工作。
四、品牌别名识别与合并
4.1 为什么别名合并是必需的
同一个品牌在AI回答中可能以多种名称出现：
全称与简称：如“北京字节跳动科技有限公司”与“字节跳动”“字节”
中文名与英文名：如“阿里巴巴”与“Alibaba”
产品名与公司名混用：如“通义千问”与“阿里云”
错别字或变体：如“小红薯”与“小红书”
隐性指代：回答中写“这家公司”“该品牌”，需要结合上下文判断
如果不做归一化，同一个实体会被拆分成多个ID统计，提及率、推荐率等指标会出现严重偏差。
4.2 别名发现与映射
实践中采用自动发现 + 人工确认的两阶段策略：
自动发现：基于编辑距离、拼音相似度和共现频率，从回答中提取候选别名对。例如，如果“绿雪智能科技”和“绿雪科技”在同一批回答中频繁出现且指向相同对象，系统自动生成候选映射。
人工确认：对置信度低于阈值的候选对进行人工复核，确认是否合并。
映射表结构如下：
CREATE TABLE brand_alias_mapping (
canonical_id STRING COMMENT '标准品牌ID',
canonical_name STRING COMMENT '标准名称',
alias_name STRING COMMENT '别名',
alias_type STRING COMMENT '简称/英文/错别字/产品名',
confidence DOUBLE 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 (
-- 从回答中提取品牌名称（基于NER或词典匹配）
SELECT sample_id, platform, brand_raw
FROM brand_extraction_results
) extracted
LEFT JOIN brand_alias_mapping m
ON extracted.brand_raw = m.alias_name AND m.status = 'active';
处理同名不同实体的边界：当品牌名称存在歧义时（如“苹果”可能指科技公司也可能指水果），需要在别名表中标注上下文限定条件，或在提取阶段引入分类器进行消歧。
五、场景标签自动生成
5.1 场景标签的定义
场景标签用于对问题进行分类，使指标可以按不同用户意图维度进行细分。常见的问题场景包括：
场景代码 场景名称 典型问题示例
REC 推荐决策 “有哪些值得推荐的XX品牌？”
CMP 对比分析 “A品牌和B品牌有什么区别？”
PUR 购买意图 “选择XX时应该优先考虑哪个品牌？”
SCN 场景发现 “XX场景下有什么解决方案？”
NAV 信息导航 “XX品牌主要是做什么的？”
RIS 风险判断 “XX品牌靠谱吗？”
5.2 标签生成方法
场景标签的生成通常结合两种方式：
规则匹配：基于关键词模式进行初筛。例如，问题中包含“值得推荐”“选哪个”“推荐一下”等表达，打上REC标签。
分类模型：对于规则无法覆盖的边缘情况，训练轻量级文本分类模型（如基于BERT的微调）进行补充。
-- 场景标签生成示例
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_label(question)
END AS scene_tag
FROM valid_samples;
标签生成后，指标聚合就可以按场景维度展开，从而发现品牌在不同用户意图下的表现差异。
六、指标聚合
6.1 核心指标定义
完成清洗、归一化和标签化后，进入指标聚合阶段。核心指标包括：
提及率：
text
提及率 = 品牌被提及的有效样本数 / 有效样本总数 × 100%
反映品牌的基础可见度。
推荐率：
text
推荐率 = 品牌被推荐的有效样本数 / 有效样本总数 × 100%
反映品牌被AI主动推荐的概率。推荐判断需要结合回答中的推荐语义和位置权重。
场景细分提及率：
text
场景提及率 = 品牌在某场景中被提及的样本数 / 该场景有效样本总数 × 100%
用于分析品牌在不同用户意图下的表现差异。
6.2 多维度聚合
在MaxCompute中按品牌、场景、平台三个维度进行分组聚合：
-- 多维度指标聚合
SELECT
brand_id,
brand_name,
scene_tag,
platform,
COUNT(DISTINCT sample_id) AS total_samples,
COUNT(DISTINCT CASE WHEN is_mentioned = 1 THEN sample_id END) AS mention_count,
COUNT(DISTINCT CASE WHEN is_recommended = 1 THEN sample_id END) AS recommend_count,
ROUND(COUNT(DISTINCT CASE WHEN is_mentioned = 1 THEN sample_id END) 100.0
/ COUNT(DISTINCT sample_id), 2) AS mention_rate,
ROUND(COUNT(DISTINCT CASE WHEN is_recommended = 1 THEN sample_id END) 100.0
/ COUNT(DISTINCT sample_id), 2) AS recommend_rate
FROM labeled_samples
WHERE is_valid = 1
GROUP BY brand_id, brand_name, scene_tag, platform;
6.3 综合评分
综合评分是对多维度指标的加权汇总。不同场景下权重配置应有所不同：
-- 综合评分计算（示意）
SELECT
brand_id,
brand_name,
-- 加权汇总：不同场景赋予不同权重
(0.3 overall_mention_rate +
0.4 overall_recommend_rate +
0.2 platform_coverage +
0.1 stability_score) AS composite_score
FROM brand_aggregates;
权重配置需要根据具体的测评目标来设定。推荐决策类场景更侧重推荐率，品牌认知类场景更侧重提及率的稳定性。
七、数据质量管理
7.1 可追溯性
全链路的数据处理状态需要被记录：
CREATE TABLE pipeline_audit_log (
sample_id STRING,
stage STRING COMMENT 'collect/clean/normalize/label/aggregate',
status STRING COMMENT 'success/failed/skipped',
detail STRING,
processed_by STRING COMMENT 'system/human',
created_at DATETIME
) PARTITIONED BY (dt STRING);
当某个品牌的指标出现异常时，可以通过审计日志快速定位问题发生在哪个阶段。
7.2 质量检查
建议在数据链路中设置以下质量检查点：
采样抽查：每周随机抽取100条回答，人工复核清洗和归一化的准确性
一致性校验：同一批数据在不同处理人员或不同时间执行时，结果是否一致
稳定性监控：同一品牌在不同批次中的指标波动是否在合理范围内
7.3 异常处理
对于以下情况，需触发人工复核流程：
新品牌出现但别名映射表中无记录
同一品牌名称指向多个不同实体
品牌提及率或推荐率出现异常大幅波动
AI回答中存在明显的事实错误或模型幻觉
八、实践总结
从AI回答采集到场景化指标输出，数据清洗的核心挑战在于几个方面：
别名的多样性：品牌名称的变体是数据工程中无法回避的问题。自动发现加人工确认的混合策略是目前比较务实的做法，关键在于建立可持续维护的映射表管理机制。
场景标签的质量：规则匹配加上分类模型的组合方式，在覆盖率和准确性之间取得了较好平衡。场景标签的粒度需要根据下游分析需求来决定，过细则样本稀疏，过粗则分析价值不足。
指标的统计口径：提及率和推荐率的计算口径必须明确且可复核。同一个原始回答，不同人解读时对“推荐”的理解是否一致，需要通过明确的判断标准来保障。
工程化的质量控制：数据链路中的每个环节都需要记录处理状态，确保最终指标可追溯。缺乏可追溯性的数据结果，在面临复核或争议时往往难以自证。
在上述实践中，整套ETL流程基于阿里云DataWorks进行任务编排与调度，MaxCompute承担核心计算，OSS用于原始数据归档。这套架构能够支撑从几十个品牌到数千个品牌的弹性处理规模。
数据清洗不是一次性的工作，而是一个持续优化的过程。随着平台增多、问题集扩展、品牌列表更新，清洗规则、别名映射表和分类模型都需要持续迭代。
