一、问题场景与挑战
在多品牌对比分析场景中（如竞品监测、行业观察、多产品评测），数据工程团队面临一个典型问题：如何将多个AI平台的回答样本，转化为可横向比较的结构化数据？
具体到工程层面，主要有几个技术挑战：不同品牌在回答中可能以别名、简称、全称等不同形式出现，需要统一的实体识别机制；单条回答中可能同时提及多个品牌，需要准确归属；品牌之间的差异需要用量化标签来表达，而非仅靠人工阅读判断。
本文从数据工程角度，分享一套从多平台AI回答采集到竞品对比结果的处理流程，涉及品牌组配置、样本清洗、别名归一化、提及与推荐识别、差异标签生成、指标聚合六个环节，并结合阿里云DataWorks + MaxCompute给出可复用的实现方案。
二、整体架构
整个处理流程分为七个阶段，通过DataWorks进行任务编排：
阶段 核心任务 依托组件 输出
① 采集 多平台API调用，按品牌组组织问题 DataWorks调度 + 自定义采集节点 原始回答表（OSS归档）
② 品牌组配置 定义对比组和组内品牌清单 MaxCompute维表 品牌组维表
③ 清洗 剔除拒答、过短、异常回答 MaxCompute UDF 有效样本表
④ 品牌归一化 别名识别与合并，归属到品牌组 MaxCompute SQL + 维表关联 标准化样本表
⑤ 提及与推荐识别 标注每个品牌在回答中的出现和推荐情况 MaxCompute SQL + 自定义函数 带标签样本表
⑥ 差异标签生成 识别组内品牌间的表现差异 MaxCompute窗口函数 差异标签表
⑦ 指标聚合 按品牌、品牌组、场景计算对比指标 MaxCompute聚合查询 竞品对比结果表
每个阶段通过DataWorks的审计日志记录处理状态，确保最终对比结论可追溯到原始回答。
三、品牌组配置
3.1 品牌组定义
品牌组是一个对比分析单元，代表一个品类或场景（如“企业级AI工具组”“运动鞋品牌组”）。组内包含多个待对比的品牌成员。
在MaxCompute中创建品牌组维表：
CREATE TABLE IF NOT EXISTS brand_group_config (
group_id STRING COMMENT '品牌组ID',
group_name STRING COMMENT '品牌组名称',
brand_id STRING COMMENT '品牌标准ID',
brand_name STRING COMMENT '品牌标准名称',
category STRING COMMENT '细分品类',
priority INT COMMENT '组内排序优先级'
)
STORED AS ALIFILE;
品牌组配置在流程开始时加载，后续所有的归一化和对比聚合都依赖此配置。建议将该表设计为每日全量刷新，以支持品牌组的动态调整。
3.2 问题与品牌组的匹配策略
采集阶段的问题需要与品牌组关联。在DataWorks中，可通过维表关联将问题路由到对应的品牌组：
CREATE TABLE question_group_mapping (
question_id STRING,
question_text STRING,
group_id STRING COMMENT '关联的品牌组',
scene_type STRING COMMENT '推荐/对比/认知等'
);
一个问题可能属于多个品牌组（如“请推荐几款好用的AI编程工具”可同时覆盖“AI工具组”和“开发者工具组”），此时需要在采集节点中进行多路分发。
四、样本清洗
4.1 无效样本类型与清洗规则
采集到的原始回答中，有一定比例需要剔除：
类型 特征 清洗规则
明确拒答 含“无法回答”“不能提供”等信号 关键词正则匹配
内容过短 少于20个字符 长度阈值过滤
语义偏离 回答与问题明显无关 文本相似度阈值（可选）
格式异常 乱码、截断、重复内容 规则+长度校验
4.2 基于MaxCompute UDF的清洗实现
在MaxCompute中创建清洗UDF：
-- 注册UDF
CREATE FUNCTION is_valid_answer AS 'com.example.udf.AnswerValidator'
USING JAR 'oss://path/to/udf.jar';
-- 在ETL任务中调用
INSERT OVERWRITE TABLE valid_samples PARTITION (dt='${bizdate}')
SELECT
id, platform, question, group_id, answer
FROM raw_answers
WHERE is_valid_answer(answer) = TRUE;
UDF核心逻辑：
public class AnswerValidator extends UDF {
public Boolean evaluate(String answer) {
if (answer == null || answer.trim().length() < 20) {
return false;
}
// 拒答信号匹配（可配置化）
String[] rejects = {"无法回答", "不能提供", "无法提供", "cannot answer"};
for (String kw : rejects) {
if (answer.toLowerCase().contains(kw.toLowerCase())) {
return false;
}
}
return true;
}
}
在DataWorks中，该UDF可作为ETL节点的核心组件，配合每日调度配置实现增量清洗。对于TB级数据量，建议将清洗任务拆分为多个并发子任务，利用MaxCompute的分布式计算能力提升处理效率。
4.3 OSS数据生命周期管理
原始回答数据量大且增长快，建议配置OSS数据生命周期策略：
热数据（近30天）：标准存储，支持频繁回溯
冷数据（30-90天）：低频访问存储，降低存储成本
归档数据（90天以上）：归档存储，仅保留用于审计
五、品牌别名归一化
5.1 别名类型与处理难点
同一品牌在不同AI回答中可能以多种名称出现：
全称/简称：“绿雪智能科技有限公司” vs “绿雪智能”
中/英文：“阿里巴巴” vs “Alibaba”
产品名/公司名：“通义千问” vs “阿里云”
错别字/变体
多品牌对比场景下，别名误匹配的风险更高——相近的名称可能分属不同品牌，处理不当会导致对比结果失真。
5.2 别名映射表
在MaxCompute中建立别名映射维表：
CREATE TABLE IF NOT EXISTS 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'
)
STORED AS ALIFILE;
5.3 ETL中执行归一化
在MaxCompute中通过维表关联完成品牌名称的标准化：
SELECT
COALESCE(m.canonical_id, 'UNKNOWN') AS brand_id,
COALESCE(m.canonical_name, extracted.brand_raw) AS brand_name,
bg.group_id,
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'
LEFT JOIN brand_group_config bg
ON m.canonical_id = bg.brand_id;
性能优化：当别名映射表达到百万级时，建议使用/+ MAPJOIN(m) /提示优化关联性能，将小表加载到内存中加速查询。
六、提及与推荐识别
6.1 品牌提及识别
当AI回答中明确出现某个品牌的名称或别名时，记录为一次有效提及。同一问题中，同一品牌最多计一次提及。
6.2 推荐等级识别
推荐识别需要区分强度，这对竞品对比尤为重要：
SELECT
sample_id,
brand_id,
brand_name,
CASE
WHEN answer REGEXP '首选|最佳|最推荐|强烈推荐' THEN 'strong'
WHEN answer REGEXP '值得推荐|可以考虑|不错的' THEN 'normal'
WHEN answer REGEXP '也可以|备选|作为补充' THEN 'weak'
ELSE 'none'
END AS recommend_level
FROM samples_with_brands;
七、差异标签生成
7.1 差异标签类型
差异标签用于标识品牌在组内的相对表现：
差异标签 含义 判断条件
领先者 某维度上显著领先于组内平均水平 指标值 > 组均值 + 1倍标准差
追赶者 某维度上低于组内平均水平 指标值 < 组均值 - 1倍标准差
被替代 AI用其他品牌替代了该品牌 相关场景中未出现但竞品频繁出现
被遗漏 品牌在关键场景中未被提及 在品牌组相关推荐问题中缺失
7.2 差异标签生成（MaxCompute窗口函数）
WITH group_stats AS (
SELECT
group_id,
AVG(mention_rate) AS avg_mention,
STDDEV(mention_rate) AS std_mention,
AVG(recommend_rate) AS avg_recommend,
STDDEV(recommend_rate) AS std_recommend
FROM brand_metrics
GROUP BY group_id
)
SELECT
bm.brand_id,
bm.brand_name,
bm.group_id,
CASE
WHEN bm.mention_rate > gs.avg_mention + gs.stdmention THEN '领先者提及'
WHEN bm.mention_rate < gs.avg_mention - gs.stdmention THEN '追赶者提及'
ELSE '均值区间'
END AS mention_tag,
CASE
WHEN bm.recommend_rate > gs.avg_recommend + gs.stdrecommend THEN '领先者推荐'
WHEN bm.recommend_rate < gs.avg_recommend - gs.stdrecommend THEN '追赶者推荐'
ELSE '均值区间'
END AS recommend_tag
FROM brand_metrics bm
JOIN group_stats gs ON bm.group_id = gs.group_id;
八、指标聚合
8.1 核心对比指标
指标 定义 竞品对比意义
组内提及率 品牌在品牌组相关问题中被提及的比例 反映AI认知程度
组内推荐率 品牌被推荐的比例 反映AI推荐倾向
组内排名 在品牌组中的相对位置 反映竞争地位
领先优势 品牌与组内第二名的差距 反映领先程度
8.2 聚合查询实现
SELECT
group_id,
group_name,
brand_name,
mention_rate,
recommend_rate,
RANK() OVER (PARTITION BY group_id ORDER BY recommend_rate DESC) AS recommend_rank,
MAX(recommend_rate) OVER (PARTITION BY group_id) - recommend_rate AS gap_to_leader
FROM brand_metrics
WHERE group_id IS NOT NULL
ORDER BY group_id, recommend_rate DESC;
九、数据质量保障
9.1 全链路可追溯
在DataWorks中，每个节点的执行日志和状态信息会自动记录。同时，业务层面建议增加审计明细表：
CREATE TABLE pipeline_audit (
sample_id STRING,
stage STRING COMMENT '采集/清洗/归一化/提及识别/推荐识别/差异标签/聚合',
brand_id STRING,
group_id STRING,
status STRING,
created_at DATETIME
) PARTITIONED BY (dt STRING);
9.2 DataWorks任务依赖与重跑机制
建议将上述SQL按阶段拆分为多个DataWorks任务节点，通过任务依赖关系控制执行顺序。当某个节点失败时，DataWorks的自动重跑机制可减少人工介入；当某阶段逻辑需要调整时，支持按分区补数据重跑，无需重新采集。
9.3 质量检查点
别名归属校验：每日抽样检查别名合并的准确性
差异标签合理性：验证“领先者”“追赶者”标签是否与数据分布一致
对比结果复核：对异常对比结论（如某品牌领先优势突然消失），触发DataWorks告警并通知人工复核
十、实践总结
从多品牌AI回答样本到竞品对比结果，数据工程需要解决从非结构化文本到结构化指标的完整转化问题。
整个流程中的关键节点：
品牌组配置是对比的基础框架。建议在DataWorks中将品牌组配置设计为参数化任务，支持通过配置表动态调整对比范围，避免每次修改都需要变更代码。
别名归一化在多品牌场景下容错要求更高。建议建立定期review机制，将新增别名纳入映射表，并设置置信度阈值自动触发人工确认。
差异标签是对比价值的核心体现。差异标签的生成逻辑（如“均值±1倍标准差”的阈值）应通过参数表配置化，便于根据业务场景调整。
场景细分是对比深度的重要保障——品牌A在“推荐决策”场景中领先，品牌B在“认知度”场景中领先，这两种领先需要分别呈现。
在阿里云技术栈上，DataWorks的任务编排能力保障了流程的稳定运行，MaxCompute的计算能力支撑了从百级到万级品牌的处理规模，OSS的数据生命周期管理控制了存储成本的增长。这套架构的优势在于弹性扩展和历史可追溯——当对比口径调整时，可以通过补数据功能重新计算历史分区，而不需要重新采集。
