我要投稿

AI工作流在淘宝交易舆情巡检上的探索与实践

发布日期：2026-03-06 18:31:04 浏览次数： 2003

作者：大淘宝技术

微信搜一搜，关注“大淘宝技术”

本文介绍了交易终端团队基于LLM构建的智能用户反馈舆情巡检系统：针对人工巡检效率低、易漏报、难洞察趋势等问题，设计“采集→清洗→AI判断→预警→分发→归因→复盘”工作流；核心采用四步AI能力（识别要素→判定意图情感→知识库语义匹配→闭环学习），强制模型在人工构建的业务问题分类库中匹配，确保可控、一致、可解释；通过新增/激增预警+钉钉推送+可视化看板实现快速响应；历经三阶段迭代，最终确立“预置打标+语义匹配”方案；强调AI是辅助工具，目标是提升业务信任与实际提效。

前言：为什么要做用户反馈舆情巡检

过去一年多，交易终端团队始终聚焦于用户体验的持续优化，在交易域性能体验升级上持续投入。而用户的真实反馈，一直是我们洞察问题、驱动改进的重要来源。为了不遗漏用户反馈中的技术性问题，各业务线每天都会安排专人进行舆情巡检——逐条查看反馈、识别异常、跟进处理。然而，随着业务体量增长和反馈渠道的多样化，传统人工巡检的局限性日益凸显：

问题	具体表现
效率低下	人工查看海量反馈，耗时耗力
漏报风险	高风险舆情被淹没在信息洪流中
趋势难察	难以识别早期问题苗头和趋势变化
闭环缺失	问题处理后缺乏追踪和复盘机制

这些痛点一直困扰着我们：能不能让机器代替人完成"发现问题"这件事？

随着LLM技术的快速发展，我们看到了新的可能——借助 AI 的语义理解和自动化能力，构建一套智能舆情巡检工作流，实现「自动发现问题 → 快速定位归因 → 闭环跟进复盘」的全链路升级。

本文将分享我们在 AI 舆情巡检领域的探索实践，包括整体方案设计、核心 AI 能力建设、以及落地过程中的经验与踩坑。

整体方案设计

通过 AI 工作流，我们期望实现舆情巡检的三大核心能力：

我们的核心思路：采集 → 清洗 → AI判断 → 预警 → 分发 → 归因 → 复盘。现在舆情的采集渠道均是淘内现有的吐槽吧，数据清洗的部分除了依赖魔兔平台的业务初筛以外我们会加相关人工巡检时的关键词再次捞取一遍舆情，避免部分被遗漏的数据。再将相关舆情数据结构化后投喂到AI，最后根据我们自定义的业务规则及波动阈值进行舆情预警并进行消息推送，至此完成巡检部分的工作，当然后续还有舆情归因及复盘反馈的环节，但是这个部分的能力我们还在持续建设中，暂时先不进行展开。

核心 AI 模型与能力模块

我们通过「识别 → 判定 → 匹配 → 学习」四个步骤，实现用户反馈的自动化分类，并通过闭环学习机制持续优化分类能力。

第一步：识别核心元素

LLM 从用户反馈中提取「谁/什么」+「怎么了」，比如「评价页面」+「打不开」。

第二步：判定意图与情感

判断用户是在提建议、报故障还是问问题，同时识别情绪是正面还是负面。

第三步：知识库匹配

将反馈与人工预先整理的问题分类库进行匹配。知识库来源并非自动生成，而是由人工对各个业务线（如评价、物流、下单、逆向、购物车、订单、支付、问大家等）过去的历史舆情进行梳理和打标，逐步积累形成的标准问题分类体系。每个业务线都有独立的分类体系和典型示例关键词。匹配规则：LLM 只能从知识库中已有的类别进行匹配，不可自行创造新类别。这确保了分类结果的一致性和可控性。

第四步：闭环学习（目前还在持续完善中）

对于无法匹配现有知识库的反馈，系统不会简单丢弃，而是启动闭环学习机制：

定期触发：系统按照设定的周期，对未匹配舆情池中的反馈进行批量处理。
LLM 聚类 + 话题发现：利用大模型对这批未匹配反馈进行语义聚类，自动发现共性话题，提取潜在的新问题类别。
人工审核确认入库：聚类结果提交给业务人员审核，确认是否为真实的新问题类型、是否需要纳入知识库。
更新知识库：审核通过后，新的问题类别和关键词被添加到对应业务线的知识库中。

最终正向循环形成通过第四步的闭环学习，系统实现了自我进化：

知识库持续丰富 → 匹配率提升 → 未匹配减少 → 分类更精准

随着知识库的不断扩充，越来越多的用户反馈能够被准确分类，未匹配的比例持续下降，整个舆情分析系统的准确率和覆盖率不断提升。

预警与分发机制

在舆情监控环节，我们支持按业务线、问题类型、时间维度灵活配置告警规则：

新增舆情监控
当某一问题类型在当日首次出现，或某类问题的绝对数量超过预设阈值时，系统自动触发「新增舆情」告警；
帮助业务快速感知新出现的问题苗头，避免遗漏早期信号。
激增舆情监控
系统持续对比当日数据与历史基线（如过去7天均值），当某一问题类型的增长幅度超过设定比例（如环比增长50%、100%）时，触发「激增预警」。
钉钉群定时同步
每日定时将预警信息推送至对应钉钉群，确保一线同学及时感知消息包含：问题类型、当前数量、环比变化、典型反馈摘要、快速跳转链接。
可视化舆情看板
搭建了多维度的舆情分析看板，支持按时间趋势、业务模块、问题类型、平台版本等维度进行下钻分析。
看板涵盖：总量概览、环比对比、问题分布、预警列表、原始反馈明细等模块，业务同学可自助查询历史数据。

落地过程中的方案迭代

在舆情归类能力的搭建过程中，我们经历了三个阶段的方案迭代：

阶段一：批量投喂，让大模型"自由发挥"

最初的想法很直接——把各业务的舆情数据批量丢给大模型，让它直接输出归类结果。数据量少的时候，效果还能接受。但随着数据量增大，问题开始暴露：

上下文超限：大模型的 token 限制导致部分舆情被截断或丢弃；

结果对不上：输出的归类数量和输入的舆情条数经常对不上，排查成本极高。

阶段二：单条投喂，提升稳定性

于是我们调整策略，对舆情数据进行结构化精简，仅保留必要字段（如反馈内容、业务模块），然后逐条调用大模型进行归类。这一阶段的准确率明显提升，但新问题随之而来：

输出不一致：大模型的概率性本质，导致相同语义的反馈可能被归为不同类别。比如「不支持暗黑模式」和「无法使用暗黑模式」，在业务看来是同一类问题，但大模型可能输出不同的分类标签，导致聚类噪音大，后续做问题聚合统计时，这种不一致性带来大量噪音，严重影响数据可用性。

阶段三：预置打标 + 语义匹配，锁定分类边界

最终我们确定了当前方案：由业务人工梳理历史舆情，构建标准化的问题分类知识库，大模型的任务从"自由归类"变为"语义匹配"——只需判断输入的反馈最接近知识库中的哪个类别。

这一方案的核心优势：

分类边界可控：所有输出类别都在预设范围内，不会产生意外的新标签。

结果一致性高：相似语义的反馈会被稳定地匹配到同一类别。

可解释、可迭代：分类体系由业务定义，便于持续优化和扩展。

经过验证，这一方案目前在准确率、一致性、可维护性上都达到一定平衡。

未来展望

AI 是辅助决策的工具，而不是替代人的黑箱。AI 负责发现问题、聚合信息、提供建议，而最终的判断和决策权，始终交给业务同学。技术落地的最后一公里，往往不是技术问题，而是信任问题。再精准的模型，如果业务不信任、不使用，就只是实验室里的玩具。只有让一线同学切实感受到"这东西确实能帮我省事、帮我少踩坑"，系统才能真正融入日常工作流。

当然，现在的方案还远谈不上完美：分类准确率仍有提升空间、多业务场景的泛化能力需要持续打磨、知识库的维护和迭代机制还需要更加自动化。作为一个刚踏入 AI 应用领域的"新手玩家"，我深知这只是一个起点。长路漫漫，但值得走下去——因为每一次优化，都意味着用户的声音能被更快听见、问题能被更早解决。