1. 一份“arXiv 每日论文分析报告”到底在解决什么问题每天早上打开 arXiv 的 cs.CL、cs.CV、cs.LG 几个分区新论文加起来动辄两三百篇光是标题和摘要从头翻到尾就要四十多分钟翻完之后能记住的往往不超过五篇。这个时间成本对做研究的人来说其实非常奢侈因为真正需要投入精力的地方是精读和复现而不是在海量条目里做初筛。我最初做这份“arXiv 每日论文分析报告”的动机很朴素把每天新出的论文先过一遍机器筛选把值得看的挑出来把不值得看的理由也写清楚让自己在通勤路上花十分钟就能掌握当天该领域的大致动向。这份报告的核心定位是信息降噪工具而不是论文代读工具。它做的事情包括抓取指定分类下当日新增论文的元数据标题、作者、摘要、分类、提交时间、PDF 链接按主题聚类对每篇论文做重要性打分再对高分论文生成一段结构化的中文摘要最后汇总成一份可以快速浏览的日报。它适合三类人一是每天需要跟踪特定方向但时间碎片化的研究者二是刚进入某个领域、需要快速建立“这个领域最近在关心什么”认知的硕博新生三是需要定期做技术调研的工程同学。它不适合指望靠一份报告就能替代精读的人因为任何自动摘要都会丢信息这一点必须先说清楚。我做的这一版报告日期是 2026-09-24覆盖的分类主要是 cs.CL、cs.CV、cs.LG 和 cs.AI 四个当天抓到的去重后论文数量是 412 篇经过初筛进入详细分析的是 63 篇最终进入“重点推荐”段落的是 11 篇。这个漏斗比例412 → 63 → 11是我调了几周之后比较满意的一个平衡点后面会详细讲这个比例是怎么定下来的。整份报告的生成流程不依赖任何需要特殊网络环境的手段全部基于公开可访问的接口和本地脚本完成这一点对长期稳定运行很关键。2. 报告的整体设计与技术选型思路2.1 为什么选择“抓取 聚类 打分 摘要”四段式结构一开始我试过更简单的做法直接调一个大模型把当天所有论文的标题和摘要拼成一个超长 prompt让它一次性输出一份日报。实测下来问题很明显。第一上下文长度扛不住400 篇论文的摘要拼起来轻松超过十万 token即使模型支持成本和延迟也不划算。第二模型在超长输入下会“中间遗忘”排在中段的论文经常被完全忽略。第三输出不稳定同样的输入两次运行结果差异很大没法做日报这种需要可复现的东西。所以我把流程拆成了四段每段职责单一便于单独调试和替换。抓取层只负责拿到干净的结构化数据聚类层负责把论文按主题分堆让后续处理在“堆”的粒度上进行打分层负责给每篇论文一个可解释的重要性分数摘要层只对高分论文做精细处理。这种拆法的好处是任何一层出问题都能快速定位而且每层都可以用最合适的工具不必强行统一。提示四段式结构里聚类和打分是最容易被低估的两环。很多人直接把所有论文丢给模型打分结果分数分布非常集中几乎区分不出好坏。先聚类再在簇内打分能显著拉开区分度。2.2 抓取层用官方 API 而不是爬页面抓取层我用的是 arXiv 官方提供的查询接口通过分类和时间范围参数拉取当日新增条目返回格式是 Atom XML。相比直接爬列表页 HTML官方接口的优势是字段规整、有稳定的唯一标识arXiv ID、不会因为页面改版而失效。解析 XML 我用的是 Python 的 feedparser 库它对 Atom 格式的兼容性很好几行代码就能把标题、摘要、作者、分类、发布时间抽出来。这里有个细节值得说arXiv 的“当日新增”并不是按自然日切的而是按提交批次。如果你在早上八点跑脚本拿到的可能只是当天第一批下午还会有第二批。我的做法是每天固定跑两次早上一次、傍晚一次第二次跑的时候用 arXiv ID 去重只保留新增的。这样既不会漏也不会重复分析。import feedparser import urllib.parse def fetch_arxiv(category, start, end, max_results500): base http://export.arxiv.org/api/query? query fcat:{category}ANDsubmittedDate:[{start}TO{end}] params { search_query: query, start: 0, max_results: max_results, sortBy: submittedDate, sortOrder: descending, } url base urllib.parse.urlencode(params) feed feedparser.parse(url) return feed.entries上面这段是抓取的核心逻辑实际用的时候要加超时重试和请求间隔arXiv 对频繁请求是有节流的我一般设置每次请求间隔三秒一天两次完全够用。2.3 聚类层轻量嵌入 层次聚类聚类层我一开始想用主题模型比如 LDA但试下来发现对短文本摘要通常只有一百多词效果一般主题词经常很泛。后来改成用句向量嵌入加层次聚类。嵌入模型选的是一个参数量不大的开源句向量模型在本地 CPU 上跑400 篇摘要大概两分钟能全部编码完不需要 GPU。聚类用层次聚类而不是 K-Means原因是每天的论文数量不固定主题数量也不固定K-Means 需要预先指定簇数很不灵活。层次聚类可以通过设定距离阈值自动决定簇的数量而且能输出树状结构方便我观察哪些主题是相近的。距离阈值我调到了 0.35 左右余弦距离这个值下 412 篇论文被分成了 28 个簇最大的簇有 47 篇最小的簇只有 2 篇分布还算合理。2.4 打分层的可解释性设计打分是整份报告里最需要“讲道理”的一环。如果只是给个分数读者没法判断这个分数意味着什么。我的打分公式由四个可解释的因子加权组成因子含义权重新颖度与近 30 天已分析论文的语义距离0.35簇内代表性与所在簇质心的相似度0.25摘要信息量摘要长度、是否含具体方法名和数据集名0.20来源信号是否含代码链接、是否被多个分类收录0.20新颖度权重最高是因为日报的核心价值在于“发现新东西”如果一篇论文和前几天看过的几乎一样那它就不该占据重点推荐的位置。簇内代表性用来避免推荐一堆高度雷同的论文每个簇里挑最有代表性的那几篇就够了。摘要信息量是个粗糙但有效的信号摘要里如果出现了具体的方法名、数据集名、指标数字通常说明这篇论文有实打实的内容。来源信号里含代码链接的论文我会额外加分因为可复现性对工程同学很重要。3. 核心细节解析与实操要点3.1 摘要生成结构化模板比自由发挥更可靠摘要层我踩过的最大坑就是让模型自由发挥写摘要。结果它经常写成一段流畅但空洞的话比如“本文提出了一种新颖的方法在多个任务上取得了良好效果”这种摘要等于没写。后来我改成结构化模板强制模型按固定字段输出问题这篇论文想解决什么具体问题方法用了什么核心手段一句话说清数据在哪些数据集上验证结果关键指标相比基线提升了多少局限作者自己提到的或明显存在的限制强制结构化之后摘要的可读性和信息密度都上了一个台阶。而且因为字段固定我可以在报告里用表格统一呈现读者扫一眼就能对比多篇论文。这里的关键是 prompt 里要明确要求“如果摘要里没有提到某个字段就写‘未提及’不要编造”。这一条极大地减少了幻觉。注意结构化摘要里“结果”字段最容易出问题。模型有时会把摘要里的相对提升说成绝对提升或者把某个子任务的指标当成整体指标。我的做法是要求模型在“结果”字段里必须原样引用摘要中的数字和表述不允许改写。3.2 去重与版本合并别让 v1 和 v2 各占一行arXiv 上很多论文会更新多个版本v1、v2、v3 都会出现在查询结果里。如果不处理同一篇论文会在报告里出现好几次非常影响阅读。我的做法是按 arXiv ID 去掉版本号后缀比如 2609.12345v2 归一成 2609.12345只保留最新版本同时在条目里标注“已更新至 v2”这样的提示。这样既避免了重复又不会让读者错过重要更新。另一个去重场景是跨分类重复。同一篇论文可能同时挂在 cs.CL 和 cs.LG 下抓取时会出现两次。这个用 arXiv ID 去重就能解决。我实测下来412 篇原始条目去重后是 389 篇去掉了 23 篇重复比例大概 5.6%不算高但也不能忽略。3.3 分类标签的归一化处理arXiv 的分类体系比较细cs.CL 下面还有 computation and language 这样的子类描述。如果直接把这些原始标签展示出来报告会显得很乱。我做了一层归一化把常见的分类映射成更通俗的中文标签比如 cs.CL → 自然语言处理cs.CV → 计算机视觉cs.LG → 机器学习。同时保留原始分类作为附注方便需要精确检索的读者。归一化映射表我维护在一个单独的配置文件里这样新增分类时不用改代码。目前覆盖了 20 多个常见分类基本够用。遇到没在表里的分类就原样展示不会报错。3.4 报告排版先给结论再给细节报告的结构我改过好几版最终定下来的是“倒金字塔”式开头先给一段三到五句话的当日概览说清楚今天哪个方向论文最多、有什么值得注意的趋势然后是重点推荐区每篇论文一个卡片包含结构化摘要和打分理由最后是全量列表按簇分组只列标题和一行简介供需要的人深挖。这个排版的好处是时间紧的读者只看开头和重点推荐就够了时间充裕的读者可以往下翻全量列表。我试过把全量列表放前面结果读者反馈“一上来就被淹没了”所以顺序很重要。4. 实操过程与核心环节实现4.1 完整流程的六个步骤整个报告的生成流程可以拆成六步我用一个主脚本串起来每天定时跑两次。下面按顺序说每一步具体做什么、大概耗时多少。第一步是抓取。对四个分类分别调用接口拿到原始条目合并后按 arXiv ID 去重。这一步耗时约 40 秒主要花在请求间隔上。第二步是预处理。把摘要里的换行、多余空格、LaTeX 公式残留清理掉统一转成纯文本。LaTeX 清理我用的是正则加一个简单的括号匹配把 $...$ 和 [...] 里的内容替换成占位符避免公式符号干扰后续的嵌入和摘要。这一步耗时约 10 秒。第三步是嵌入和聚类。用句向量模型对全部摘要编码然后做层次聚类输出每个簇的成员列表和质心。这一步是 CPU 密集的412 篇大概两分钟。第四步是打分。对每篇论文计算四个因子的分数加权求和。新颖度需要和近 30 天的历史嵌入做比对所以我会把每天的嵌入存下来形成一个滚动窗口。这一步耗时约 20 秒。第五步是摘要生成。只对每个簇里分数最高的前若干篇调用模型生成结构化摘要。63 篇论文每篇一次调用串行跑大概六分钟如果并发跑能压到两分钟以内。我一般用并发但会限制并发数避免触发限流。第六步是渲染。把结果填进 Markdown 模板生成最终报告文件。这一步几乎不耗时。4.2 参数选择漏斗比例是怎么定下来的前面提到的 412 → 63 → 11 这个漏斗不是拍脑袋定的。我调参的时候主要看两个指标一是重点推荐区的论文里我实际会去精读的比例二是全量列表里我事后觉得“这篇其实该进重点推荐”的漏网之鱼数量。一开始我把详细分析的门槛设得很低63 篇变成了 150 篇结果摘要生成时间翻倍而且重点推荐区塞了 30 多篇反而失去了“重点”的意义。后来我把门槛提高详细分析降到 40 篇左右又发现有些好论文被漏掉了。反复试了几周63 篇这个数字对应的打分阈值能让我精读比例稳定在 70% 左右漏网之鱼控制在每天一两篇我觉得这个平衡可以接受。重点推荐的 11 篇也不是固定数字而是“每个簇最多推荐 2 篇总分超过阈值才推荐”的结果。有的日子只有 6 篇有的日子有 15 篇这个浮动是正常的强行凑数反而不好。4.3 打分因子的具体计算新颖度的计算方式是对每篇论文的摘要嵌入计算它与近 30 天所有已分析论文嵌入的最大余弦相似度然后用 1 减去这个相似度作为新颖度分数。相似度越高说明越像旧论文新颖度越低。这个计算需要维护一个历史嵌入库我用的是一个简单的本地文件存储每天追加超过 30 天的自动淘汰。簇内代表性的计算方式是论文嵌入与所在簇质心的余弦相似度归一化到 0 到 1。这个分数高说明这篇论文是该簇的典型代表。摘要信息量的计算稍微粗糙一些我用的是规则加词典摘要长度在合理区间比如 80 到 250 词得基础分出现方法名关键词如 transformer、diffusion、reinforcement 等加分出现数据集名如 GLUE、ImageNet、MMLU 等加分出现具体数字如百分比、倍数加分。这个规则不完美但胜在快且可解释。来源信号里含代码链接github、gitlab 等域名加满分被多个分类收录加部分分有项目主页加部分分。4.4 报告模板的关键字段最终报告里每篇重点推荐的论文卡片包含这些字段标题中英对照、作者只列前三位加 et al.、分类标签、打分和打分理由、结构化摘要、原文链接。打分理由我会用一句话说明“为什么推荐”比如“新颖度高与近期工作差异明显”或者“含开源代码可复现性强”。这一句话对读者判断要不要点进去看非常有用。全量列表里每篇论文只保留标题、一行简介和链接。一行简介是从结构化摘要的“方法”字段截取的控制在 30 字以内。5. 常见问题与排查技巧实录5.1 抓取为空或数量异常最常见的问题是某天抓取数量突然变成个位数。排查顺序是这样的先确认接口是否正常返回直接浏览器打开查询 URL 看有没有结果再确认时间范围参数格式是否正确arXiv 对日期格式比较敏感必须是 YYYYMMDD 加具体时分最后确认是不是当天确实是周末或节假日提交量本来就少。我遇到过几次是因为时间范围写成了自然日而 arXiv 的批次时间跨了午夜导致漏抓改成按批次时间范围就正常了。5.2 聚类结果不稳定聚类结果每天波动大有时候同一个主题今天被分成三个簇明天合成一个。这主要是嵌入模型对短文本的敏感度导致的。缓解办法有两个一是聚类前先对摘要做一次轻量的关键词提取把关键词拼到摘要前面再嵌入增加信号二是设定一个最小簇大小小于三篇的簇直接合并到最近的簇里避免碎片化。我用了这两个办法之后簇的数量波动从每天 15 到 40 收窄到了 22 到 32。5.3 摘要生成超时或失败并发调用模型时偶尔会遇到超时。我的处理是设置三次重试每次重试间隔递增三次都失败就把这篇论文的摘要字段标记为“生成失败”不让整个流程卡住。另外我会把每次调用的输入输出都记日志方便事后排查是哪些论文容易失败。实测下来摘要特别长超过 300 词的论文失败率略高可能是输入太长导致的对这类论文我会先做一次截断再调用。5.4 打分区分度不足如果发现重点推荐区的论文分数都挤在一起说明打分因子的权重需要调整。我的经验是新颖度的权重不能太低否则推荐出来的都是“安全但无聊”的论文。另外可以在打分前先对每个因子做一次归一化避免某个因子的量纲过大主导总分。我最初忘了归一化结果摘要信息量因为数值范围大几乎决定了最终排名调整后才恢复正常。5.5 常见问题速查表问题现象可能原因排查动作解决方式抓取数量骤降时间范围跨批次、接口节流手动打开查询 URL 验证改按批次时间范围加请求间隔聚类簇数波动大短文本嵌入敏感观察簇大小分布加关键词前缀设最小簇大小摘要生成失败输入过长、并发过高查调用日志截断输入降低并发加重试打分挤在一起因子未归一化、权重失衡看各因子分数分布归一化调高新颖度权重报告重复条目版本未合并、跨分类重复按 arXiv ID 检查去版本后缀按 ID 去重5.6 几个我踩过的坑第一个坑是过度依赖模型打分。我一开始想让模型直接给每篇论文打一个 1 到 10 分结果发现模型的分数和我的判断相关性很低而且不可解释。后来改成规则加权虽然粗糙但至少我知道每个分数是怎么来的调起来也有方向。第二个坑是忽略了时区。arXiv 的提交时间用的是某个固定时区我本地时区不一样导致“当日”的界定经常错位。后来我统一在脚本里把时间转成 arXiv 使用的时区再比较问题就消失了。第三个坑是报告太长。我一开始把每篇论文的结构化摘要都写得很详细结果一份报告两万多字自己都不想看。后来把全量列表的简介压缩到一行重点推荐才展开整体长度控制在了六千字左右阅读体验好很多。6. 这套报告后续还能怎么扩展目前这套流程跑得比较稳但我还在琢磨几个扩展方向。一个是加一个“趋势追踪”模块把连续几天的簇做关联识别出正在升温的主题比如某个方向连续三天都有高分论文就在报告开头提示“该方向近期活跃”。这个用簇质心的跨天相似度匹配就能做不需要太复杂的逻辑。另一个方向是加“引用网络”的轻量分析。arXiv 本身不提供引用数据但可以通过 Semantic Scholar 的公开接口拿到每篇论文的引用和被引情况把当天论文里互相关联的挑出来形成一个小的关系图。这个对理解论文之间的脉络很有帮助不过要注意接口的调用频率限制。还有一个我一直在犹豫的功能是“个性化排序”。理论上可以根据我过去精读过的论文训练一个小的偏好模型让打分更贴合我的口味。但这样会让报告变得过于个人化分享给别人时参考价值下降。目前我的折中做法是保留通用打分但在报告末尾附一个“按你的历史偏好重排”的可选列表需要的人自己看。最后分享一个我在实际使用中觉得最有用的小习惯我会在每份报告生成后花两分钟在重点推荐区里手动标记“已读”“待读”“跳过”这些标记会反馈到第二天的打分里作为来源信号的一个补充。坚持了几周之后报告的命中率明显提升因为系统逐渐知道了哪些类型的论文我真正会看。这个反馈闭环不需要多复杂的技术一个简单的标记文件加读取逻辑就够了但效果比单纯调参好得多。
