1. 一份AI日报的诞生逻辑每天早上八点半我习惯性打开自己搭的AI日报聚合面板扫一眼过去24小时里全球范围内值得关注的模型发布、工具更新、行业动向和开源项目。这个习惯坚持了快两年中间换过三次技术方案踩过的坑足够写一本小册子。今天这篇内容就是把这套AI日报从信息采集到最终成稿的完整流程拆开讲清楚包括我为什么这么设计、每个环节用什么工具、参数怎么调、哪些地方容易翻车。先说清楚这份日报的定位它不是那种今天OpenAI发了什么的新闻搬运而是一份面向开发者和产品经理的技术决策参考。每条信息都要回答三个问题——这东西是什么、它能解决什么问题、我现在要不要跟进。所以从信息源筛选开始标准就和普通资讯聚合完全不同。适合谁来参考这套方案如果你满足以下任意一条这篇内容应该对你有用每天需要花大量时间刷各种AI资讯但觉得效率太低想搭建自己的信息聚合系统但不知道从哪下手已经在做类似的事情但发现信噪比越来越差或者单纯好奇一份看起来很专业的AI日报背后到底是怎么运转的。我目前这套系统的核心指标是每天处理约200-400条原始信息经过筛选后进入日报的约15-25条最终成稿约3000-5000字从采集到发布全流程自动化程度约70%人工介入主要集中在事实核查和观点补充上。下面按模块拆解。2. 信息源体系的设计与取舍2.1 为什么不能只靠RSS很多人第一反应是搞一堆RSS订阅用Feedly或者Inoreader一拉就完事。我早期也是这么干的结果发现两个致命问题一是AI领域的核心信息有相当一部分首发在社交媒体和即时通讯群组里RSS覆盖不到二是RSS的更新延迟在AI领域可能是致命的——一个模型权重在社区先泄露等官方博客发出来已经是三天后的事了。所以我现在的信息源分成了四个层级每个层级的采集策略和权重完全不同层级类型代表来源采集频率权重系数L1官方发布渠道各实验室博客、模型卡页面每15分钟1.0L2社区讨论热点技术论坛、开发者社区每30分钟0.7L3学术预印本预印本平台新论文每2小时0.5L4综合科技媒体科技新闻站点每1小时0.4权重系数的含义是在最终排序时L1来源的一条信息得分是L4来源同热度信息的2.5倍。这个系数不是拍脑袋定的是我回溯了三个月的历史数据统计每个层级的信息最终被证明重要的概率反推出来的。L1层级的信息有超过60%最终值得收录而L4层级只有不到15%。2.2 采集端的技术选型采集层我用的是异步任务队列去重管道的架构。具体来说每个信息源对应一个采集器Collector采集器把原始数据丢进一个消息队列然后有一个统一的预处理服务从队列里消费。为什么用队列而不是直接写数据库因为不同来源的采集频率差异很大L1可能15分钟一次L3可能2小时一次如果直接写库会出现大量并发写入冲突。队列起到缓冲和削峰的作用同时天然支持失败重试。预处理服务做三件事去重、清洗、初步分类。去重用的是SimHash算法对文本内容生成64位指纹汉明距离小于等于3的视为重复。这个阈值我调过很多次设2会漏掉一些改写后的重复内容设4会误杀一些真正不同的信息3是实测下来最平衡的。清洗主要是去掉HTML标签、广告段落、导航栏文本这些噪音。这里有个细节不同来源的HTML结构差异很大用统一的清洗规则效果很差。我的做法是为每个来源写一个独立的清洗配置用CSS选择器精确提取正文区域。虽然前期工作量大但后期准确率能到95%以上。初步分类用的是一个小型的文本分类模型把信息分到模型发布工具更新行业动态学术论文观点讨论五个类别里。这个分类不追求极致准确主要是为后面的排序提供特征。2.3 一个容易被忽略的细节时间窗口AI日报的时间窗口设定看起来简单其实很讲究。我试过三种方案固定24小时窗口每天0点截断取前一天0点到当天0点的所有信息。问题是如果某个重要发布发生在晚上11点50分它只有10分钟的发酵时间热度数据完全不够容易被埋没。滑动24小时窗口从当前时间往前推24小时。好处是每条信息都有完整的发酵时间坏处是同一件事可能连续两天都出现。混合窗口主窗口是前一天6点到当天6点但对热度特别高的信息超过阈值允许回溯到48小时前。最终我选了混合方案。具体参数是主窗口24小时回溯窗口额外24小时回溯触发条件是信息的热度分数超过过去7天日均热度分数的3倍标准差。这个3倍标准差的设定参考了异常检测里常用的3-sigma原则实测下来既能抓住真正的大事件又不会让日报变成旧闻重播。3. 从原始信息到日报条目的加工流水线3.1 热度评估模型的设计一条信息值不值得进日报不能只看来源权重还要看它在社区里的实际反响。我设计了一个多维度的热度评分模型包含以下特征互动量评论数、点赞数、转发数的加权和。不同平台的互动量纲不一样需要做归一化处理。我的做法是取该平台过去30天互动量的P95分位数作为基准当前互动量除以基准得到归一化分数。互动增速单位时间内的互动增量。这个特征比绝对互动量更能反映正在爆发的趋势。计算方式是取最近1小时和最近6小时的互动增量做比值。跨平台出现次数同一条信息在多少个不同的平台上被讨论。这个特征能有效过滤掉单一平台的刷量行为。作者/发布者权重发布者的历史准确率和影响力。这个需要维护一个发布者档案库记录每个发布者过去发布的信息最终被证实为真的比例。最终的热度分数是这些特征的加权和权重通过逻辑回归在历史数据上拟合得到。我用的训练集是过去6个月的日报数据标注标准是这条信息是否最终被证明对技术决策有参考价值。模型在验证集上的AUC大约是0.82不算特别高但作为初筛已经够用了。3.2 摘要生成为什么不用大模型直接写很多人觉得摘要生成直接丢给大模型就行了我一开始也这么想后来发现两个问题一是大模型容易脑补把原文没有的细节加进去二是不同条目的摘要风格不一致有的很正式有的很口语。我现在的方案是抽取式生成式混合。先用TextRank算法从原文中抽取3-5个关键句然后把这些关键句和原文一起喂给一个经过指令微调的小模型参数量在7B左右让它基于关键句生成一段80-120字的摘要。提示词里明确要求只使用原文中出现的信息不要添加任何外部知识。这个方案的好处是抽取式保证了关键信息不丢失生成式保证了语言流畅。实测下来事实性错误率从纯生成式的12%降到了3%以下。摘要生成后还有一道事实核查环节。对于涉及具体数字、日期、版本号的内容系统会自动和原始来源做比对。如果摘要里的数字在原文中找不到对应就标记为待人工确认。这个环节拦截了大约5%的潜在错误。3.3 排序与去重日报条目的最终确定所有条目加工完成后进入排序环节。排序分数由三部分组成热度分数权重0.5、来源权重权重0.3、时效性分数权重0.2。时效性分数是一个指数衰减函数半衰期设为12小时也就是说一条信息如果发布后12小时内没有被处理它的时效性分数会降到一半。排序后取Top N条N的值根据当天的信息总量动态调整。信息多的日子N25信息少的日子N15。这个动态调整是为了保证日报的密度相对稳定不会出现某天只有5条某天有40条的情况。去重环节在排序之后再做一次这次用的是语义去重而不是文本去重。具体做法是把每条信息的摘要向量化计算余弦相似度相似度超过0.85的视为同一事件的不同报道只保留热度最高的那条其他的作为相关报道附在下面。4. 日报成稿的自动化与人工介入4.1 模板引擎与结构化输出日报的最终呈现用的是模板引擎渲染。我定义了一个JSON Schema来描述日报的数据结构包含日期、头条、分类条目、相关链接等字段。模板引擎根据这个Schema生成Markdown格式的成稿。为什么用模板而不是让大模型直接写整篇因为日报的格式需要高度一致读者每天看同样的结构才能快速定位信息。大模型写整篇很容易在格式上跑偏今天有这个小标题明天没有体验很差。模板保证了结构稳定大模型只负责填充内容。模板里预留了几个人工插槽比如编辑点评字段默认是空的我可以在发布前手动填入一些个人判断。这个字段是日报里唯一带主观色彩的部分也是很多读者反馈最有价值的部分。4.2 人工介入的三个关键节点虽然号称70%自动化但剩下30%的人工介入恰恰是决定日报质量的关键。我的人工介入集中在三个节点第一个节点是早上7点的快速扫描。系统会在6点50分生成一份待审清单包含所有排序后的条目和系统生成的摘要。我花大约15分钟快速过一遍主要做三件事删掉明显不相关的条目、调整条目顺序、标记需要补充背景的信息。第二个节点是事实核查。对于涉及具体产品发布、版本更新、融资消息的内容我会点进原始来源确认关键信息。这一步不能省因为AI领域的信息传播链条很长经常出现二手信息失真的情况。我遇到过好几次社区讨论得很热烈但官方根本没发布的消息。第三个节点是编辑点评的撰写。这部分完全靠人工也是日报差异化的核心。我的点评通常包含三个角度这条信息对普通开发者意味着什么、我个人的使用体验或判断、以及一个接下来值得关注的点。每条点评控制在100-150字太长读者没耐心看。4.3 发布与分发日报生成后我会同步到几个渠道一个静态站点用静态站点生成器构建、一个邮件列表、以及几个开发者社区的专栏。不同渠道的格式略有调整比如邮件版会把链接放在文末统一列出社区版会加上话题标签。发布时间的设定也有讲究。我试过早上7点、8点、9点三个时间点最终选定了8点30分。原因是太早读者还没上班太晚会被上午的工作消息淹没。8点30分正好是大多数人刚到工位、开始浏览信息的时间。这个时间点的打开率比7点高出约40%。5. 实操中踩过的坑与排查技巧5.1 采集端的常见故障故障一某个来源突然大量重复内容。这种情况通常是来源网站改版或者分页逻辑变了导致采集器反复抓取同一页。排查方法是看采集日志里该来源的URL去重率如果去重率突然降到很低基本可以确定是这个问题。解决方法是更新该来源的采集配置。故障二编码问题导致乱码。不同网站的字符编码不统一有的用UTF-8有的用GBK如果采集器没有正确识别就会产生乱码。我的做法是在采集器里加一个编码探测步骤用chardet库自动识别识别置信度低于0.8的标记为待人工确认。故障三反采集机制触发。有些网站会检测请求频率超过阈值就返回403或者验证码页面。应对方法是给每个来源设置独立的请求间隔并且随机化请求头。我一般把间隔设在来源网站robots.txt规定的最小间隔的1.5倍以上。5.2 摘要生成的典型问题问题一摘要过于笼统。比如把一篇关于某模型推理优化的文章摘要成该模型进行了优化完全没有信息量。这个问题通常是因为TextRank抽取的关键句本身就不够具体。解决方法是在抽取阶段加入信息量评分优先抽取包含具体数字、技术术语、对比信息的句子。问题二摘要包含过时信息。有些文章是更新帖原文里既有新信息也有旧信息摘要可能把旧信息当成新信息。解决方法是在预处理阶段识别文章的更新标记比如更新于补充说明等关键词把更新部分的内容权重提高。问题三多语言混合。AI领域的很多信息是英文的但社区讨论可能是中文的。如果摘要生成模型没有做好语言区分会出现中英文混杂的情况。我的做法是在摘要生成前先做语言检测然后路由到对应的语言模型。中文摘要用中文模型英文摘要用英文模型最后如果需要中文日报再统一翻译。5.3 排序与去重的边界情况边界情况一同一事件的多角度报道。比如一个模型发布有的报道侧重技术细节有的侧重商业影响有的侧重社区反应。这些报道语义相似度可能不高不会被语义去重合并但实际上是同一件事。我的处理方式是在排序阶段加入事件聚类步骤用命名实体识别提取事件主体同一主体同一时间段的报道归为一组组内只保留热度最高的。边界情况二持续发酵的长尾事件。有些事件不是爆发式的而是持续几天甚至几周慢慢发酵。这种事件在24小时窗口里可能热度不高但实际很重要。我的应对是维护一个跟踪列表对于已经进入过日报的事件在后续几天里降低它的入选阈值确保不会漏掉后续发展。边界情况三突发大事件淹没其他信息。比如某天有一个特别大的发布热度分数远超其他所有信息导致日报变成单一事件专刊。这种情况我通过设置单事件条目上限来解决同一事件在日报中的条目数不超过3条超出部分移到相关阅读区域。5.4 常见问题速查表问题现象可能原因排查方法解决方案日报条目数骤减采集器故障或来源改版检查各来源采集日志更新采集配置摘要事实错误生成模型脑补对比摘要与原文加强事实核查规则排序结果异常热度特征计算错误检查特征归一化重新校准基准值重复条目出现语义去重阈值过高检查相似度分布调整阈值至0.8-0.85发布时间延迟队列积压检查队列长度增加消费者实例6. 这套系统还能怎么扩展6.1 个性化日报的可行性目前这套系统生成的是通用日报但不同角色的读者关注点差异很大。比如做模型训练的开发者更关心架构创新和训练技巧做应用开发的更关心API更新和工具链变化。理论上可以根据读者的历史点击行为构建用户画像然后对排序分数做个性化调整。我做过一个小规模的实验给10个测试用户分别生成个性化排序的日报持续两周。结果是用户对个性化日报的满意度比通用日报高出约25%但前提是用户画像要足够准确。冷启动阶段的个性化反而会降低体验因为画像不准导致推荐偏差。6.2 从日报到周报的聚合日报的信息是碎片化的周报可以把一周的信息做主题聚合形成更有深度的内容。我的做法是每周日对过去7天的日报条目做一次聚类分析识别出本周的主线和支线。主线是出现频率最高、热度最高的事件簇支线是虽然热度不高但值得关注的小趋势。周报的撰写比日报更依赖人工因为需要跨条目建立联系、提炼观点。我的周报结构通常是本周主线回顾2-3个事件、值得关注的技术趋势1-2个、下周值得期待的事项1-2个。每个部分都配上具体的日报条目链接方便读者回溯。6.3 质量评估与持续迭代任何自动化系统都需要持续的质量评估。我目前用的评估指标有三个覆盖率当天重要事件被日报收录的比例、准确率日报条目中事实无误的比例、时效性从事件发生到进入日报的平均延迟。覆盖率通过人工回溯来评估每周随机抽一天人工列出当天所有重要事件然后看日报覆盖了多少。目前覆盖率大约在85%左右漏掉的主要是发生在非英语社区的事件。准确率通过事实核查环节统计目前稳定在97%以上。时效性平均延迟约6小时主要瓶颈在摘要生成和人工审核环节。迭代的方向也很明确覆盖率方面计划增加更多非英语来源的采集时效性方面考虑把部分低风险条目的审核改为抽检而不是全检。但这些调整都需要在质量和效率之间做权衡不能为了快而牺牲准确。这套系统从最初的脚本到现在前后迭代了十几个版本。最大的体会是AI日报的核心竞争力不在技术而在判断力。什么信息值得收录、什么信息可以忽略、一条信息对读者意味着什么这些判断目前还很难完全自动化。技术能做的是把信息高效地送到你面前但最终按下发布按钮的那一刻还是得靠人。