从零搭建AI日报自动化系统：信息聚合、去重聚类与摘要生成实战-北京尧图网络

1. 当日报变成日更一个内容聚合项目的起点做内容的人都有一个共同的痛点信息太多时间太少。每天打开各种信息流光是筛选今天到底发生了什么值得关注的事就要花掉一两个小时等筛完了写稿的精力也没了一半。我身边不少做科技媒体、行业分析、投资研究的朋友都在这件事上反复消耗。于是从去年开始我陆续折腾了一套自动化程度比较高的AI日报生成流程每天定时跑一遍把当天值得看的AI领域动态聚合成一份结构化的日报人工只需要做最后的审核和微调。这套流程跑了大半年中间踩过的坑、换过的方案、推翻重来的架构设计攒了不少经验今天借这个标题把它完整拆一遍。先说清楚这套东西到底是什么。它不是一个简单的RSS阅读器也不是把几个网站的内容抓下来拼在一起就完事。核心目标有三个第一信息源的覆盖要足够广不能只盯着三五家媒体否则日报会变成某几家公司的传声筒第二去重和聚类要做得足够好同一件事被十家媒体报道日报里只能出现一次而且要把最完整的信息整合进来第三摘要要能看不能是简单的截断或者机器翻译腔得让人读起来像人写的。这三点听起来简单真做起来每一环都有大量细节要处理。适合谁来参考这套方案我觉得有三类人。一类是做内容运营或者媒体编辑的每天需要产出行业简报、资讯汇总一类是做行业研究或者投资分析的需要持续跟踪某个领域的动态还有一类是纯粹的技术爱好者想自己搭一套信息聚合系统练手。不管你是哪一类这套流程的架构思路和踩坑经验都能直接拿去用代码层面需要根据自己的技术栈做适配但核心逻辑是通用的。下面我会从信息源管理、抓取与清洗、去重聚类、摘要生成、日报排版与分发这几个环节逐一展开每个环节都会讲清楚为什么这么设计以及实际跑起来会遇到什么问题。文章会比较长但都是实打实跑出来的经验不是纸上谈兵。2. 信息源管理日报质量的天花板在这里就定死了2.1 为什么信息源不能抓到什么算什么很多人搭这类系统的第一反应是找几个RSS源配个定时任务抓下来就完事。我一开始也是这么干的结果第一版日报跑出来满屏都是重复内容而且大量低质量的信息混在里面根本没法看。问题出在信息源的管理上——你喂给系统的原料质量直接决定了日报的质量上限。信息源管理要解决三个问题覆盖度、信噪比、稳定性。覆盖度是指你的源要能覆盖到行业的主要动态不能有大的盲区信噪比是指源里有效信息的比例要高不能抓一百条只有三条能用稳定性是指源的格式和可访问性要相对稳定不能今天能抓明天就挂了。这三个问题里覆盖度和信噪比是矛盾的——覆盖越广信噪比往往越低。所以我的做法是分层管理把信息源分成核心层、扩展层和观察层三层。核心层是那些质量稳定、更新频率高、信噪比好的源比如几个头部科技媒体的AI频道、几个主要AI公司的官方博客、几个高质量的行业通讯。这一层大概控制在15到20个源是日报内容的主力。扩展层是覆盖面更广但质量参差不齐的源比如综合科技媒体的AI标签页、一些垂直社区的讨论区、几个聚合平台的热榜。这一层大概30到50个源用来补充核心层可能遗漏的动态。观察层是一些新出现的、还不确定质量的源先放进来观察一段时间表现好就升到扩展层甚至核心层表现差就踢掉。2.2 源的健康度监控不监控就等于没有源分层管理之后还需要一套健康度监控机制。我吃过这个亏有个核心层的源挂了将近两周我才发现那两周的日报里那个方向的内容明显偏少但我一直以为是那段时间行业本身没什么大事。后来写了个简单的监控脚本每天记录每个源的抓取成功率、平均抓取条数、内容去重后的有效条数一旦某个指标连续几天异常就告警。监控指标不用太复杂我实际用的就四个抓取成功率HTTP状态码正常的比例、有效条数去重后进入候选池的条数、平均延迟从源发布到被抓到的时间差、内容新鲜度抓到的内容里发布时间在24小时内的比例。这四个指标里抓取成功率反映源的可用性有效条数反映信噪比平均延迟反映源的更新及时性内容新鲜度反映源是不是在炒冷饭。任何一个指标连续三天低于阈值就触发告警人工去检查是源本身的问题还是抓取逻辑的问题。提示监控告警不要设得太敏感否则每天都会被误报打扰。我的经验是抓取成功率低于80%连续三天才告警有效条数低于历史均值50%连续三天才告警这样既能发现问题又不会太吵。2.3 源的动态调整日报是活的源也应该是活的信息源不是配一次就一劳永逸的。行业在变媒体的更新频率和质量也在变。我现在的做法是每个月做一次源的全量review看每个源在过去一个月的表现数据决定是保留、降级还是踢掉。同时每个月会尝试引入三到五个新源放到观察层跑一个月再看表现。这个动态调整机制带来的一个额外好处是日报的内容风格会随着源的调整而自然演化。比如某个阶段我发现某个细分方向比如AI在医疗领域的应用的报道明显增多就会主动去找几个专注这个方向的源加进来日报在这个方向的覆盖度就会提升。反过来如果某个方向的源质量普遍下降日报在这个方向的内容就会自然减少不会硬凑。3. 抓取与清洗脏活累活都在这里3.1 抓取策略别用一套逻辑打天下信息源的类型不一样抓取策略也得不一样。我实际遇到的主要有三类标准RSS/Atom源、网页列表页、API接口。标准RSS源最好处理直接用feedparser之类的库解析就行但要注意有些源的RSS只输出摘要不输出全文需要额外去抓正文页。网页列表页最麻烦每个站点的HTML结构都不一样得单独写解析规则而且站点改版就会失效。API接口最稳定但很多平台不开放或者有频率限制。我的做法是优先用RSS其次用API最后才用网页解析。RSS虽然有时候内容不全但格式稳定、解析简单、不容易被封。API虽然稳定但往往有门槛。网页解析是最后的选择因为维护成本太高。对于必须用网页解析的源我会把解析规则写成配置文件而不是硬编码在代码里这样站点改版时只需要改配置不用改代码。抓取频率也要根据源的类型来定。新闻类的源更新快可以15到30分钟抓一次博客类的源更新慢一天抓一两次就够了官方公告类的源更新更慢一天一次甚至两天一次都行。抓取频率太高不仅浪费资源还容易被源站限流甚至封禁。我一般会给每个源配一个抓取间隔然后统一调度。3.2 正文提取Readability不是万能的抓到网页之后下一步是把正文提取出来。很多人直接用Readability或者类似的库但实际用下来Readability在新闻类页面上表现不错在博客类页面上就经常出问题要么把评论也提取进来要么把正文截断。我的做法是Readability打底加上针对性的规则修正。具体来说先用Readability提取一版然后检查提取结果的几个特征长度是否合理太短说明可能截断了太长说明可能混入了无关内容、是否包含明显的导航文字或评论特征、段落结构是否完整。如果检查不通过就用备选方案——要么用站点特定的CSS选择器重新提取要么用基于文本密度的算法重新识别正文区域。这套组合拳下来正文提取的准确率能到95%以上。还有一个容易被忽略的点是编码问题。有些源返回的HTML编码声明和实际编码不一致直接解析会出现乱码。我的做法是先用chardet之类的库检测实际编码再和HTML声明比对不一致就以实际检测为准。这个细节看起来小但不处理的话日报里会出现乱码非常影响观感。3.3 清洗规则把噪音挡在门外正文提取出来之后还要做一轮清洗。清洗的目标是去掉那些虽然属于正文但不适合放进日报的内容比如推广信息、作者简介、相关阅读推荐、版权声明等。这些内容如果不清掉日报会显得很杂乱。清洗规则我分成两类通用规则和站点特定规则。通用规则处理那些普遍存在的噪音比如以关注我们点击这里阅读原文开头的段落、包含特定推广关键词的段落、明显是作者简介的段落通常包含作者编辑来源等词且长度较短。站点特定规则处理那些某个站点特有的噪音比如某个站点的正文末尾总是跟着一段固定的版权声明。清洗规则要定期review因为噪音的形式会变化。我一般每两周看一次清洗后的样本发现新的噪音形式就加规则。但规则也不能加得太激进否则容易误伤正文。我的原则是宁可漏掉一些噪音也不要误删正文因为漏掉的噪音读者能自己忽略误删的正文会让日报信息不完整。4. 去重与聚类同一件事只出现一次4.1 去重的两个层次完全重复和近似重复去重这件事听起来简单做起来分两个层次。第一个层次是完全重复就是两篇文章的正文完全一样或者几乎一样这种通常是同一篇通稿被多家媒体转载。第二个层次是近似重复就是两篇文章讲的是同一件事但措辞和角度不同这种通常是多家媒体各自报道同一件事。完全重复好处理直接算正文的哈希值或者用SimHash之类的算法比对就行。近似重复就麻烦多了因为两篇文章可能只有部分内容重叠或者用词完全不同但说的是同一件事。我实际用的方案是两阶段去重第一阶段用SimHash做快速筛选把相似度高的文章聚在一起第二阶段用更精细的相似度算法比如基于TF-IDF的余弦相似度或者基于句向量的语义相似度在候选集里做精确比对。这里有个参数需要调相似度阈值。阈值太高近似重复的文章去不掉阈值太低不同事情的文章会被误判为重复。我的经验是SimHash的汉明距离阈值设在3到5之间余弦相似度阈值设在0.75到0.85之间具体值要根据实际数据调。调的方法是拿一批标注好的数据跑一遍看准确率和召回率的平衡点在哪里。4.2 聚类把同一件事的报道归到一起去重之后还要做聚类。去重解决的是两篇文章是不是重复聚类解决的是多篇文章是不是在讲同一件事。这两件事的区别在于去重是两两比对聚类是全局分组。比如某天有三篇文章分别从不同角度报道同一个发布会去重可能认为它们不重复因为措辞不同但聚类应该把它们归到一组。聚类的算法我用过几种最后稳定下来的是基于语义向量的层次聚类。具体做法是先用句向量模型把每篇文章的正文编码成一个向量然后计算向量之间的余弦相似度用层次聚类把相似度高的文章聚成一类。这个方案的好处是不依赖关键词匹配能处理用词完全不同但语义相同的情况。缺点是计算量比较大文章多的时候需要做优化。聚类的粒度也要控制。聚得太粗不同的事情会被归到一起聚得太细同一件事会被拆成好几组。我的做法是先粗聚再细调先用一个较宽松的阈值做初步聚类然后人工检查聚类结果对明显不合理的聚类做合并或拆分把调整逻辑沉淀成规则。跑一段时间之后规则越来越完善需要人工干预的情况就越来越少了。4.3 组内代表选取选哪篇放进日报聚类完成之后每一组里有多篇文章日报里只需要放一篇或者把多篇的信息整合成一篇。选哪篇我的标准是信息完整度优先其次是来源权威性最后是发布时间。信息完整度是指这篇文章是否包含了事件的核心要素时间、地点、人物、事件、影响权威性是指来源是否可靠发布时间是指是否是最新的。实际操作中我会给每篇文章算一个综合分信息完整度占60%权威性占25%发布时间占15%。信息完整度的计算可以用一些启发式规则比如正文长度、是否包含关键要素词、段落结构是否完整等。权威性可以用源的分层来定核心层的源权威性高扩展层次之观察层最低。发布时间就是越新越好。有时候一组里没有一篇文章是完整的需要把多篇的信息整合起来。这种情况我会用一个简单的整合逻辑以信息最完整的那篇为底稿把其他篇里独有的信息补充进去。整合的时候要注意去重和逻辑连贯不能简单拼接。5. 摘要生成让日报读起来像人写的5.1 抽取式摘要和生成式摘要的选择摘要生成有两条路线抽取式从原文里挑句子和生成式用模型重新组织语言。抽取式的好处是不会产生事实错误因为句子都是从原文里来的缺点是读起来可能不连贯而且受限于原文的措辞。生成式的好处是读起来流畅自然缺点是有可能产生幻觉编造原文里没有的信息。我实际用的是混合方案先用抽取式挑出关键句子再用生成式模型把这些句子改写成连贯的摘要。这样既保证了事实准确性关键信息来自原文又保证了可读性语言经过重新组织。改写的时候会给模型明确的指令要求它只能使用原文中出现的信息不能添加新信息。这个方案的关键在于抽取阶段的质量。如果抽取的句子不包含核心信息改写阶段再厉害也救不回来。我的抽取逻辑是基于位置和关键词的双重打分位置分看句子在文中的位置开头和结尾的句子权重高关键词分看句子是否包含事件的核心要素词。两个分数加权求和取分数最高的几个句子。5.2 摘要长度的控制不是越长越好摘要长度是个需要仔细调的参数。太短了信息不全太长了读者没耐心看。我的经验是每条摘要控制在80到150字之间具体长度根据事件的重要程度调整。重要的事件可以到150字一般的事件80到100字就够了。长度控制的方法是在生成阶段给模型明确的字数限制同时在抽取阶段就控制好输入句子的总长度。如果生成的结果超长就做一轮压缩如果太短就补充一些次要信息。压缩和补充都要基于原文不能凭空发挥。还有一个细节是摘要的开头。日报里的摘要如果都以据悉据报道开头读起来会很单调。我的做法是在生成阶段要求模型用多样化的开头比如直接以事件主体开头、以时间开头、以影响开头等。这样整份日报读起来会更有节奏感。5.3 事实一致性检查防止模型编故事生成式摘要最大的风险是幻觉。模型可能会把原文里的某公司计划推出某产品改写成某公司已经推出某产品一字之差事实完全变了。所以生成之后必须做事实一致性检查。我的检查方案是关键要素比对从原文里提取出关键要素主体、动作、时间、数字等从摘要里也提取出关键要素然后比对两者是否一致。如果不一致就标记出来人工检查。这个方案不能覆盖所有情况但能抓住大部分明显的事实错误。除了自动检查我还会做抽样人工检查。每天随机抽5到10条摘要人工比对原文看是否有事实错误或者表述不当。发现的错误会记录下来用来优化生成阶段的指令和检查规则。这个反馈循环跑一段时间之后摘要的准确率会明显提升。6. 日报排版与分发最后一公里决定阅读体验6.1 排版结构让读者三秒找到重点日报的排版结构直接影响阅读体验。我的日报结构是标题区、要闻区、分类区、简讯区四块。标题区是日报的名称和日期要闻区是当天最重要的3到5条新闻分类区是按主题分类的新闻比如模型发布、产品更新、行业动态、研究进展等简讯区是那些重要程度一般但值得知道的短消息。要闻区的选取标准是影响范围乘以事件强度。影响范围是指这件事影响多少人、影响多深事件强度是指这件事的新颖程度和讨论热度。两个维度都高的进要闻区只有一个维度高的进分类区都不高的进简讯区。这个分类逻辑要稳定不能今天这么分明天那么分否则读者会困惑。分类区的分类维度也要固定。我用的分类是模型与算法、产品与应用、行业与商业、研究与论文、政策与伦理。每个分类下的条目按重要程度排序。分类的数量控制在5到7个太多了读者看不过来太少了又不够细。6.2 分发渠道不同渠道不同格式日报做出来之后要分发。不同渠道的格式要求不一样不能一份内容到处发。我的做法是一份内容多种格式Markdown格式用于内部存档和邮件分发HTML格式用于网页展示纯文本格式用于即时通讯工具推送图片格式用于社交媒体分享。格式转换用模板引擎做把日报的内容和格式分离。内容用结构化的数据JSON或者YAML存储格式用模板定义。这样改格式的时候不用动内容改内容的时候不用动格式。模板要针对每个渠道单独设计比如即时通讯工具的推送要更简洁社交媒体的图片要更注重视觉效果。分发的时间也要考虑。我的日报是每天早上8点推送这个时间点是大部分人的上班路上或者刚到工位的时候正好需要一份简报来了解昨天发生了什么。推送频率是每天一次周末也不停因为AI领域的动态不会因为周末就停下来。6.3 反馈收集让读者告诉你哪里不好日报做出来不是终点还要收集反馈。我在日报末尾放了一个简单的反馈入口读者可以标记这条摘要不准确这条不该进要闻这个分类有问题等。反馈数据会汇总起来用来优化各个环节的参数和规则。反馈收集的关键是降低反馈成本。如果让读者写一大段文字反馈大部分人不会写。我的做法是提供几个预设的反馈选项读者点一下就行。比如每条摘要旁边有准确不准确信息不全三个按钮读者点一下就能反馈。反馈数据积累到一定量之后就能看出哪些环节需要优化。除了显式反馈还有隐式反馈可以收集比如日报的打开率、每条摘要的阅读时长、分享次数等。这些数据能反映读者的真实兴趣用来调整要闻区的选取标准和分类区的排序逻辑。显式反馈和隐式反馈结合优化方向会更准确。7. 跑了大半年之后我总结出的几条经验这套系统从第一版跑到现在中间大改过三次小改过无数次。有几条经验是踩了坑之后才明白的写出来给准备入坑的朋友参考。第一条是不要追求一步到位。我第一版想做得完美结果拖了两个月才上线上线之后发现很多设计在实际数据面前根本不成立。后来改成先跑一个最小可用版本每天人工检查发现问题就改迭代速度反而快得多。现在这套系统是第四版但如果没有前三版的积累第四版也做不出来。第二条是人工审核不能省。我试过完全自动化的方案结果日报里出现了好几次事实错误有一次把某公司的融资额写错了一个数量级差点闹笑话。后来改成自动生成加人工审核审核时间控制在15分钟以内既能保证质量又不会太累。审核的重点是事实性错误和重要遗漏文字表达的小问题可以放过。第三条是数据比直觉可靠。我一开始凭直觉觉得某些源很重要结果数据跑出来发现那些源的有效条数很低。反过来有些我觉得一般的源数据表现却很好。所以源的调整、参数的调整都要看数据不能凭感觉。当然数据也不是万能的有些新源数据还没积累起来需要人工判断但至少在有数据的地方要以数据为准。第四条是系统的价值在于持续运行。这套系统最大的价值不是某一天的日报有多好而是它能持续不断地运行每天稳定产出。所以稳定性比先进性重要一个能稳定跑一年的简单系统比一个跑一周就挂掉的复杂系统有价值得多。为了稳定性我在架构上做了很多妥协比如不用太新的库、不做太复杂的优化、保留人工干预的入口这些妥协在实际运行中都被证明是值得的。最后分享一个小的技巧日报的标题不要用AI日报这种泛泛的名字加上日期和一句当天的亮点打开率会明显提升。比如AI日报 2026-10-07某模型发布新版本推理成本降了一半这样的标题读者一眼就知道今天值不值得看。这个技巧看起来小但对日报的传播效果影响很大。

从零搭建AI日报自动化系统：信息聚合、去重聚类与摘要生成实战

相关推荐

局域网聊天课设：为什么用服务器中转比真P2P更合适

新代eHMI下载实战：从固件级部署到产线批量回滚

基于SpringBoot与微信小程序的UGC旅游分享平台实战解析

更多资讯

洗衣店服务管理系统开发实战：从需求拆解到答辩避坑

前后端分离架构下图形验证码的工业级实现方案

彻底搞懂NumPy argmax的axis参数：形状消去法一看就会

电磁场与电磁波课后习题解答：复数表示、麦克斯韦方程与传输线避坑指南

VMware虚拟机Linux磁盘扩容实战：fdisk分区与fstab挂载全解析

jdk 1.7 32位安装配置详解：老系统的Java环境搭建与排障

今日更新

Cephadm实战指南：Linux系统工程师的生产级Ceph集群部署与排障

不想再被 Token 额度卡脖子？把免费 API 接入 WorkBuddy 的完整教程

ITK中SpatialObject几何体系解析：坐标系、变换与管道集成

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？