一、背景
随着大语言模型（LLM）的普及，越来越多的企业开始关注自身品牌、产品在AI回答中的呈现情况。一个自然的思路是：向多个AI平台批量提问，从返回的回答中提取品牌是否被提及、是否被推荐等信息，最终形成可量化的监测指标。
这个思路听起来不复杂，但实际落地时，数据链路远比想象中要长。
从调用API获取回答文本，到最终输出可供分析的指标数据，中间涉及无效样本清洗、品牌名称归一化、指标口径定义、多轮结果稳定性验证等多个环节。任何一步处理不当，都可能导致最终结果出现偏差——比如，同一个品牌可能因为别名没有合并而被分拆统计，或者因为无效回答未被剔除而使数据失真。
本文基于实际工程经验，分享一套从多平台AI回答采集到指标体系输出的完整处理方案，重点讨论数据清洗策略、实体归一化方法、核心计算逻辑，以及基于阿里云MaxCompute和DataWorks的全链路数据工程实现。
二、整体架构
整个数据处理链路分为五个层次：
层级 功能 关键技术点
采集层 向多平台发起提问，获取原始回答 API调用、并发控制、失败重试
存储层 原始数据持久化存储 OSS冷热分层、MaxCompute分区表
清洗层 剔除无效样本，筛选有效数据 规则过滤、拒答识别、长度校验
归一化层 品牌名称标准化合并 别名映射表、模糊匹配
计算层 指标聚合与输出 提及率、推荐率、多维评分
数据在每一层之间流转时，都需要记录处理状态，确保从最终指标可以追溯到原始回答——这是保障数据可信度的基础。
三、采集层：多平台并发获取
3.1 平台覆盖
在实际项目中，通常需要覆盖多个主流AI问答平台，包括但不限于豆包、DeepSeek、通义千问、Kimi、文心一言、腾讯元宝等。每个平台的API鉴权方式、调用频率限制、返回格式各不相同，需要通过统一的抽象层来屏蔽差异。
3.2 采集字段设计
采集阶段需要保存的字段远不止回答内容本身：
sql
-- MaxCompute建表示例
CREATE TABLE IF NOT EXISTS raw_answers (
id BIGINT COMMENT '唯一ID',
platform STRING COMMENT '平台名称',
question STRING COMMENT '测试问题',
answer STRING COMMENT 'AI原始回答全文',
intent_category STRING COMMENT '问题意图分类',
call_status STRING COMMENT '调用状态：success/fail/timeout',
created_at DATETIME COMMENT '采集时间'
) PARTITIONED BY (dt STRING COMMENT '日期分区');
核心原则：原始回答必须完整保留，不可在采集阶段做任何修改或截断。这是因为后续清洗规则和口径可能会调整，保留原始数据允许重新处理而无需重新采集。
3.3 成本控制
多平台、高频次的AI调用会产生API费用。实践中可以采取以下策略：
通过DataWorks调度任务，在非高峰期执行批量分析
不同平台配置不同的采样频率，平衡覆盖面和成本
将90天以上的历史数据迁移至OSS低频存储
四、清洗层：无效样本识别与剔除
4.1 什么是无效样本
采集到的回答中，有相当比例无法用于后续分析，常见无效类型包括：
拒答：平台返回“无法回答”“我不能提供”等明确拒答
内容过短：回答长度不足20字符，通常未产生有效信息
语义偏离：回答与问题主题明显无关
格式异常：包含乱码、截断、大量重复内容
4.2 清洗实现
在MaxCompute中可以通过UDF实现清洗逻辑：
sql
-- 自定义清洗函数示例
CREATE FUNCTION is_valid_sample AS 'com.example.udf.AnswerValidator';
-- 在ETL任务中调用
INSERT OVERWRITE TABLE valid_answers PARTITION (dt='2026-06-25')
SELECT
id, platform, question, answer, intent_category
FROM raw_answers
WHERE is_valid_sample(answer) = TRUE;
核心清洗逻辑（Java UDF简化示意）：
java
public boolean validate(String answer) {
if (answer == null || answer.trim().length() < 20) {
return false;
}
// 拒答关键词匹配
String[] rejectKeywords = {"无法回答", "不能提供", "抱歉", "cannot answer"};
for (String kw : rejectKeywords) {
if (answer.contains(kw)) {
return false;
}
}
return true;
}
拒答关键词列表需要持续维护——不同平台、不同模型版本的表达方式存在差异，需要结合实际数据定期补充。
五、归一化层：品牌别名标准化
5.1 问题描述
这是整个数据链路中最容易被低估的环节。同一个品牌在AI回答中可能以多种形态出现：
全称 vs 简称：如“绿雪智能科技”和“绿雪”
中文名 vs 英文名
产品名 vs 公司名
错别字或近似表达
回答中的隐性指代：“这家公司”“该品牌”
如果不做别名归一化处理，“同一实体被拆分统计”会导致提及率、推荐率等指标严重失真。
5.2 技术方案
建立品牌别名映射表，通过MaxCompute维表关联完成标准化：
sql
-- 别名映射维表
CREATE TABLE brand_aliases (
canonical_name STRING COMMENT '标准名称',
alias_name STRING COMMENT '别名'
);
-- ETL中关联替换
SELECT
COALESCE(b.canonical_name, extracted.brand_raw) AS brand_name,
...
FROM extracted_brands t
LEFT JOIN brand_aliases b ON t.brand_raw = b.alias_name;
5.3 维护策略
别名映射表需要持续维护。实践中采用两阶段策略：
自动化初筛：通过编辑距离、拼音相似度等算法，自动发现候选别名
人工审核确认：对边界情况（同名不同实体、近似但不是同一实体）进行人工判断
对于置信度较低的自动发现结果，可以暂不合并，而是标记为待观察，降低误合并带来的数据污染风险。
六、计算层：核心指标聚合
6.1 提及率
定义：品牌被AI明确提及的比例。
计算口径：
text
提及率 = 品牌被提及的有效回答数 / 有效回答总数 × 100%
关键规则：
回答中需明确出现品牌名称或可识别别名
同一问题中，同一品牌最多计一次提及
同名对象混淆的情况不计为有效提及
6.2 推荐率
定义：品牌被AI作为推荐对象输出的比例。
计算口径：
text
推荐率 = 品牌被推荐的有效回答数 / 有效回答总数 × 100%
推荐判断不仅看品牌“是否出现”，还需要结合推荐位置和推荐语气：
推荐类型 判断依据 示例
强推荐 明确冠以“首选”“最佳”等标签 “首选推荐A品牌”
一般推荐 列入推荐名单中 “也可以考虑B品牌”
弱推荐 作为补充提及 “C品牌也是一个选择”
6.3 综合得分
综合得分是对多维度指标的加权汇总，通常包括：
提及率：品牌是否被看见
推荐率：品牌是否被推荐
推荐位置：在推荐列表中的排序
平台覆盖度：是否在多个平台稳定出现
采样稳定性：多轮结果的一致性
负面风险：是否存在错误、争议或负面表达
不同测评任务中，各维度权重需要按需调整。例如，“推荐决策类”场景更看重推荐率，“品牌认知类”场景更看重提及率。
6.4 在MaxCompute中的实现
sql
-- 提及率计算示例
WITH brand_mention AS (
SELECT
brand_name,
COUNT(DISTINCT sample_id) AS mention_count
FROM answer_brands
WHERE is_valid = TRUE
GROUP BY brand_name
),
total_samples AS (
SELECT COUNT() AS total FROM valid_answers
)
SELECT
brand_name,
mention_count,
total,
ROUND(mention_count 100.0 / total, 2) AS mention_rate
FROM brand_mention, total_samples;
七、随机性问题
生成式AI的回答具有天然的不确定性。同一个问题在不同时间、不同平台、不同模型版本下，可能生成不同的回答。
7.1 处理策略
多问题采样：不使用单个问题，而是构建一组覆盖不同角度的问题
多平台采样：覆盖多个主流AI平台，避免单一平台偏差
多轮重复：同一问题进行多轮独立采样，降低偶然性
异常识别：隔离失败、无效或明显偏离的回答
7.2 稳定性分析
通过对比不同轮次的结果，可以计算品牌的出现稳定性：
sql
-- 分析品牌在多次采样中的稳定性
SELECT
brand_name,
COUNT(DISTINCT sample_round) AS appeared_rounds,
total_rounds,
ROUND(COUNT(DISTINCT sample_round) * 100.0 / total_rounds, 2) AS stability_rate
FROM answer_records
GROUP BY brand_name;
单次AI回答不能代表真实状况，连续、分层、可复核的采样结果才具有参考价值。
八、全链路质量保障
8.1 可追溯性
每一层处理都需要记录状态，便于从最终指标追溯原始回答：
sql
CREATE TABLE pipeline_audit (
sample_id BIGINT,
stage STRING COMMENT '处理阶段',
status STRING COMMENT '状态',
processed_at DATETIME
);
8.2 人工复核
以下情况需要人工介入：
品牌名称存在歧义（同名不同实体）
AI回答存在明显混淆
负面风险较高
自动识别置信度较低
人工复核的目标不是调整数据，而是对边界情况和异常样本进行校验，提升最终指标的可信度。
8.3 数据质量验证
准确率：抽样检查无效样本识别是否正确、别名归一化是否完整
一致性：不同操作人员使用同一套口径是否得到一致结果
稳定性：同品牌在不同时间、平台的表现是否在合理波动范围内
九、总结
从AI回答采集到指标输出，数据工程的核心能力在于建立一套从原始数据到可用指标、完整可靠且可追溯的数据处理链路。
这条链路的关键节点包括：
采集层：完整保存原始回答，支持后续重处理
清洗层：剔除无效样本，避免污染统计结果
归一化层：处理实体别名问题，防止同一对象被拆分统计
计算层：基于明确口径聚合核心指标
复核层：对边界样本进行人工校验
在上述实践中，采集到的原始数据存储在阿里云OSS，通过DataWorks进行周期性调度，核心ETL逻辑在MaxCompute中完成计算，最终指标通过BI工具或API对外输出。这套架构充分利用了云原生数据工具体系的弹性计算能力和数据可靠性保障，能够支撑从几十个到数千个品牌的弹性测评规模。
每个环节都需要明确规则、保留记录、支持复核。唯有如此，最终产出的指标才具有真实的参考价值。
