Infoseek舆情系统：AI重构媒体发布链路的数据中台实践

Infoseek舆情系统是我们团队内部跑了一年多的数据中台项目，核心目标很直接：让AI接管媒体信息采集、文本理解和发布建议生成，重新梳理媒体发布的底层逻辑。早期我们做内容运营和公关支持，每天要盯几十个信息出口，人工刷网页、截图、做Excel记录，导致两个很痛的后果：关键信息漏报，以及真假信息混在一起无法判断。折腾了大半年，我们决定自建一套舆情数据管道，从采集到分析再到发布建议全部走AI，Infoseek就是在这样的背景下诞生的。

这篇文章不准备讲什么宏大架构，只聊我们真正落地后沉淀下来的东西：采集层怎么设计才不会重复采、文本理解模型怎么选才扛得住业务考验、AI又是怎么把“发什么、什么时候发、往哪发”变成一串可计算的评分。适合承接内容平台、新媒体运营、公关数字化，或者做NLP工程化的团队参考。有些坑我们踩过，后面会单独拿出来讲。

1. 采集层不能只靠“爬虫”：数据源分层与增量调度

很多团队做舆情系统，第一步想到的就是写通用爬虫，把页面抓下来、存进数据库，然后开始做NLP。我们第一版也是这么干的，结果快速发现两个致命问题：重复内容把存储撑爆了，关键舆情从出现到入库慢了几个小时。后来才想明白，舆情场景的采集和普通爬虫根本不是一回事。普通爬虫追求“抓到就行”，舆情采集追求“有节奏、有重点、能追踪变化”。

1.1 数据源分层的核心原则

我把数据源分成四层，每层的采集策略完全不一样。第一类是权威媒体层，包括门户网站的科技频道、财经频道，以及垂直行业站，这类源数量少但判定权重高，更新频率稳定，适合短轮询。第二类是自媒体层，包括公众号生态、头条号这类内容发布渠道，更新节奏比门户更散，需要用内容接口加主动轮询组合处理。第三类是互动讨论层，包括论坛和评论区，数据量大但噪声高，通常低频采集加上热点触发追采。第四类是社交传播层，转发路径和话题热度都在这层产生，采集优先级最高，一旦识别到事件信号，要立刻进入加速模式。

分层之后，调度策略才有意义。我们默认给权威媒体层设5到15分钟轮询间隔，自媒体层30分钟一轮，互动讨论层按需触发。比较关键的是“热点追采”机制：当NLP模块识别到某个实体或事件的热度快速攀升，调度器会自动把相关源调进高频队列，最短可以做到分钟级补抓。这套机制让采集层不是匀速转，而是跟着事件热度变速转。

1.2 增量更新与去重的实现细节

舆情数据一个很大的特点就是“同一个事件被反复报道”，而且报道还会被编辑修改。我们第一版全量拉取，入库条数每天上百万，但有效信息可能不到三分之一。后来把增量更新逻辑改成了指纹加时间戳的双重判断。

具体做法是：对“标题加正文摘要加规范化URL”做内容指纹计算，第一次入库后只记录指纹，后续重复内容直接丢弃。同时保留原文的变更指纹，一旦发现某个已入库文章的正文发生了修改，就触发增量重抓并记录修改时间点。布隆过滤器用来过滤已经见过的URL，内存占用很小，速度也快。这套逻辑我还专门留了一个小技巧：在文章表里维护“首次发现时间”“最后修改时间”“抓取次数”三个字段。最早只是为排查采集问题，后来做舆情生命周期分析时，这三个字段成了判断事件冷热变化的重要依据。

1.3 存储架构：原样数据与指标数据分开

舆情系统如果只用一套数据库，后面一定会被拖死。我们的存储分三层：原始数据层放HTML快照和抽取后的正文纯文本，放在对象存储里，成本低且方便追溯；检索层用Elasticsearch存正文和结构化字段，负责全文检索和聚合统计，索引按天滚动便于清理；关系层用PostgreSQL存实体、事件和文章的关联关系，适合做复杂的多表查询。

关键经验是“原样数据”和“指标数据”必须分开。所谓原样数据，是采集下来的原文快照，它追求真实完整，不允许被业务计算污染。指标数据则是从原文中抽取出的情感标签、实体关系、热度数值，它需要频繁更新和计算。如果两者混在一张表或同一套存储里，训练数据、生成报表、做关联查询都会互相拖慢。类比一下就是仓库和超市的区别：仓库只管存货，超市负责分类上架，两者物理分开才能互不干扰。

2. “看得懂”文本：情感分析、实体识别与事件聚类的落地选型

采集到数据只是第一步，真正让舆情系统有价值的是“文本理解”。我们内部把问题拆成三个：谁在说，说了什么，情绪是什么。这句话听起来简单，落地时每个环节都要做技术选型。我们试过最前沿的生成式大模型，也试过老牌的金融情感词典，最后落地的是一套组合方案：实体识别先行、情感四分类、事件聚类收口。

2.1 实体识别：词典先决，模型精调

第一版实体识别直接用了开源NER模型，在通用新闻上表现尚可，一落到我们的业务场景就露馅了。品牌词、产品型号、行业缩写，开源模型几乎全认不出。比如某款产品代号被误判成普通英文单词，事件归属直接错位。第二版我们改了思路，把自定义词典放在最前面。

规则是词典优先，模型兜底。先把品牌词、竞品词、行业术语、产品型号统统塞进自定义词典，用最长匹配优先切分；然后把模型预测出的实体和词典结果做一次合并，模型置信度低的实体如果和词典冲突，以词典为准。训练数据靠运营每周人工标注，只标实体边界和实体类型（品牌、产品、人物、地区），累计两千条后，识别效果就发生质变。我强烈建议把实体识别放在情感分析之前：必须先搞清楚负面情绪指向谁，再判断情绪本身，顺序反了整条事件链都会乱。

2.2 情感分析：通用模型永远不够，必须领域微调

情感分析我们一开始偷懒，接了一个通用情感推理接口，结果遇到“某产品价格跳水”这种典型商业场景，模型给出的中性概率极高，完全没有业务参考价值。后来换成“预训练底座加领域微调”的方案，用BERT类模型做底座，在收集到的一万两千条领域语料上微调分类头，把标签设计成四类：正面、中性、负面、不确定。

之所以做四分类而不是传统的三分类，是因为舆情场景下模型确实存在大量拿不准的情况。硬塞进三分类只会让运营反复纠错，最后对系统失去信任。加入“不确定”类之后，标注人员和运营的体验都好了很多，模型在正面和负面识别上的F1值从最初通用版的0.71提到了0.86。标注策略上也没有偷懒，每条数据至少两个人标注，不一致的进入仲裁池。比较难处理的反问句和反讽句，比如“这价格真是良心啊”搭配具体语境，单靠模型容易翻车，最终靠规则层做了兜底校正。

2.3 事件聚类：把分散报道聚成一条主线

同样一个事件，几十家媒体会从不同角度各写一篇，不对它们聚类，系统里就会同时出现几十条重复信息，运营看完反而更懵。事件聚类的做法分两步。第一步，用Sentence-BERT把标题加首段文字转换成向量，通过近似检索找到语义相似的候选文章。第二步，用“实体集合重叠度加时间窗”做硬过滤，只有语义相似且主要实体高度重合、发布时间在一定范围内的内容，才被归入同一条事件流。

这个硬过滤很关键，否则会出现“两个品牌同时降价被误判成一个事件”的乌龙。聚类成功后，我们把同一事件的报道组织成事件流对象，记录关键实体、事件句、时间线和情感占比。编辑打开系统，一眼就能看到事件从哪里开始、中间哪些节点产生了新信息、整体情绪在上升还是在消退。这一步的价值后面会体现，发布决策模型最重要的输入特征就是事件流数据。

3. AI如何把“发布决策”从直觉变成模型评分

传统媒体发布链路基本靠编辑个人经验：判断什么值得发，凭感觉选发布时间，再把同一篇稿子复制到各个平台。这种模式在信息量小的时候还行，信息爆炸之后就完全跟不上。Infoseek对发布底层逻辑的调整，是把这条链路里的每个节点都变成可计算的输出。

3.1 从人工跟热点到热度预测

我们内部叫“事件价值评分”，核心特征包括当前声量、声量增速、传播指数、参与账号层级和来源权威度。这些特征归一化后输入梯度提升模型，输出一个0到100分的热度分。训练标签不是阅读量，而是运营对历史事件“是否值得跟进”的回标，阅读量高不等于必须跟，还要看事件和业务的相关性。

比热度分更有用的是热度曲线预测。系统会把当前事件的时间衰减曲线与历史同类事件做匹配，输出未来24小时和72小时的音量走势预测。编辑拿到的不只是一个静态分数，而是一条“如果现在不发，热度会不会继续涨”的曲线。这样“要不要跟”和“什么时候发”就有了数据支撑。需要强调一点，热度预测模型只做价值排序，不做真实性判断，事实核查仍然属于人工审核的职责范围。

3.2 渠道-内容匹配的评分逻辑

发布决策重构之后，变化最大的就是渠道匹配。以前编辑习惯“一文多发”，后来发现不同平台用户的口味差异极大，同一篇科技资讯在专业社区反响好，在泛内容平台可能没人看。我们做了一个渠道-内容匹配模型，输入是稿件主题、实体类型、情感倾向、内容长度，以及同主题稿件在各渠道的历史表现，输出是每个渠道的预发布评分。

简化后的计算逻辑类似：发布得分等于内容特征相似度占四成、历史转化表现占三成、时效因子占两成、账号权重占一成，具体权重通过历史数据回归拟合，不是拍脑袋定的。实际运行后，同一个事件生成的稿件不再“一把梭”，系统会针对不同渠道推荐不同的标题前缀、导语写法甚至话题标签组合。AI在这里做的不是替编辑写稿，而是告诉编辑“这套组合拳按什么顺序打更合理”。

3.3 人审环节为什么不能省

有人问过我们：既然AI已经能把稿件和渠道都推荐出来了，为什么不做全自动发布？答案是：发布动作涉及事实核查、立场判断和品牌风险，这些问题是模型暂时没有能力负责的。系统能做到的建议加初稿，但最终确认必须由人来完成。我们设计成三级作业流：AI生成建议、人工确认、系统记录结果回流。

回流这一步很关键。人工确认的“发”或“不发”会变成新的训练样本，进入下一轮模型迭代。每发一次，系统对业务的偏好理解就更深一分。所谓“AI重构媒体发布的底层逻辑”，在工程上其实就是把原来不可见的直觉判断，变成可见、可修改、可反馈的计算链路。

4. 上线后最头疼的四个问题：置信度、新词、模型漂移与负向误判

任何AI系统上线后都会遇到真实业务环境的毒打，舆情系统尤其明显。这里挑四个我们花了最多时间解决的问题，每一个都直接决定运营愿不愿意继续用系统。

4.1 置信度：模型说“负面”，运营为什么不信

第一版情感分析只输出一个标签，不输出置信度。结果运营看到系统标了个“负面预警”，点进去一看内容比较中性，几次之后整个团队对系统失去信任。问题的根源不是模型精度不够，而是系统没有给运营“为什么这样判断”的依据。后来我们给每个标签配了置信度分数，分数在0.85以上的才叫高置信标签，0.7到0.85之间是中置信，低于0.7直接归入“不确定”。界面同步展示模型关注的句子片段，让运营能快速定位“到底是哪句话触发了负面判断”。信任感这个东西，产品设计比算法调参更管用。

4.2 网络新词与多语言场景的处理

舆情文本里新词出现频率极高，“破防”“yyds”这类网络语言更新速度远超常规实体词表。如果词表固定，新词出现两周后识别率就会明显下滑。我们的应对机制分两层。第一层是每周跑一次候选词挖掘，用点互信息统计高频相邻短语，自动生成候选词表给运营确认，确认后热更新进词典，不重训模型。第二层是英文等多语言内容，先用翻译管道转成中文，再走统一的NLP流程，虽然会损失少量语义细节，但工程上能以较低成本承接业务扩展。建议不要一开始就把多语言全部铺开，先把主力语言做稳，再考虑扩展。

4.3 模型漂移：训练节奏如何定

舆情数据的分布漂移比一般业务数据快得多，舆论热点可能三周就换一轮。我们最初一个季度重训一次模型，结果到第五周效果就明显退化。现在的节奏是：分类头每周增量训练，底层编码器每四周做一次整体微调。增量训练只更新顶层分类器，用新标注数据做小批量迭代，成本低、见效快。整体微调解冻底层编码器的最后两层，其余参数保持冻结，避免灾难性遗忘。回标数据池采用难例优先采样，也就是先选模型最拿不准的样本给人工确认，标注投入产出比明显更高。

4.4 召回率与准确率的取舍

负面识别是舆情系统的生命线，但追求高召回往往伴随高误报。我们最初把负面置信度阈值调得很低，每天大量候选人需要人工核验，运营苦不堪言；调高阈值又担心漏掉关键负面。最后解决方案是回归到业务成本来计算：负面事件的漏报成本远高于误报排查成本，所以最终阈值取在召回率大概0.9的位置，代价是每天会多出一批“候选负面”需要人工快速核验。

除了阈值，我们还叠了规则兜底。只要文本包含“道歉、召回、立案、约谈”这类强信号词，不管模型概率多少，都直接进入高危事件队列。这是AI加规则最典型的配合方式，模型负责发现潜在语义关系，规则负责兜住高频强信号。两者结合比任何单一方案都稳。

5. 效果复盘：数字背后的真实变化与下一步扩展

Infoseek内部实际运行一年多以后，我们做了一个阶段性复盘。不能只说技术指标，更值得记录的是运营团队工作方式的改变。

5.1 我们在效率与召回率上的实测数据

和旧的人工监看加关键词检索方案相比，几个关键指标都有明显变化。信息入库从小时级缩短到分钟级，热点事件发现时间平均提前一两个小时，负面触点识别的召回率提升了三十个百分点左右。人工复核量在初期反而增加，因为系统把以前看不见的疑似负面捞了出来，后来随着置信度设计和规则兜底逐渐完善，复核量又降了下去。

更有意思的是工作方式的改变。以前运营每天上班第一件事是刷各个平台，手动记哪些话题在升温；现在第一件事是打开事件流和高危队列，先看系统排序，再决定优先处理哪几条。核心业务问题从“哪些信息存在”变成“哪些信息值得处理视角的转变。这就是底层逻辑重构在操作层面的体现。

5.2 下一步扩展：多模态、摘要生成与知识图谱

下一步我们有三个明确的扩展方向。第一是多模态内容处理，短视频平台的信息占比越来越高，OCR字幕提取、语音转写、封面图像识别都需要尽快补齐。第二是事件流摘要生成，把一串相关报道自动汇总成可读摘要，让运营快速导出舆情日报，技术选型上更倾向于候选句抽取加重排序，比端到端生成更可控。第三是知识图谱，把实体、事件、渠道和发布人之间的关系沉淀下来，后续可以分析传播路径和影响范围。

这三个方向都会继续沿着“可计算、可解释、可回流”的原则推进，不会一开始就铺得很大。补充一句个人体会：做舆情系统最容易犯的错误是一上来就堆大模型、追新架构，我们第一版也这样走过弯路。复盘后发现真正提升系统价值的，其实是数据管道稳定、标签可解释、闭环回流这三个基本功。AI重构媒体发布底层逻辑这句话说起来很响亮，但落到工程上，都是把每个节点拆开、量化、再串成闭环的功夫。希望这些踩坑经验对正在做同类系统的团队有帮助。