1. 从一份论文汇总清单说起我为什么要做这件事每天早上刷 arXiv 的 cs.LG 板块已经成了我这两年雷打不动的习惯。但说实话真正让我头疼的不是读论文本身而是读哪些。cs.LG 这个板块每天的更新量在 200 到 400 篇之间浮动赶上会议截稿前后比如 NeurIPS、ICML 的 rebuttal 期单日能冲到 500 篇以上。你不可能全看但你又怕漏掉关键的那几篇——尤其是当你的工作同时横跨机器学习、LLM、量化和推理这几个方向的时候。所以我从去年开始做了一件事每天把 arXiv cs.LG 的新论文抓下来做一轮结构化汇总按主题聚类、按热度排序、按方法类型打标签最后输出一份可以直接扫读的清单。这篇博文就是拿 2026 年 9 月 23 日这一天的汇总作为样本把整套流程、背后的取舍逻辑、踩过的坑以及怎么把这套东西迁移到你自己的方向上完整讲一遍。这份汇总能解决什么问题简单说三个第一把信息过载变成信息过滤你不需要读完 300 篇摘要只需要读 20 篇被筛出来的第二把零散变成结构化同一篇论文的方法、数据集、baseline、结论被拆成固定字段方便横向对比第三把一次性阅读变成可检索资产汇总结果落库之后你可以按关键词回溯过去半年的所有相关工作。适合谁来参考如果你是在读研究生、算法工程师、或者任何需要持续跟踪机器学习前沿的人这套流程都能直接用。不需要你有很深的 NLP 背景Python 基础加上一台能跑脚本的机器就够了。如果你已经在用 LLM 做文献辅助阅读那这套东西可以无缝接进你现有的工作流。下面我按整体设计思路 → 核心细节 → 实操过程 → 问题排查四块来讲中间会穿插大量我实际跑下来的参数和判断依据。2. 汇总系统的整体设计与思路拆解2.1 为什么不做全自动摘要而是做结构化筛选一开始我也想过偷懒抓下来直接丢给 LLM让它给我写一段中文摘要不就完了试了两周之后我放弃了原因有三个。第一摘要的粒度不可控。同一篇论文你今天让它写 100 字明天让它写 200 字出来的东西结构完全不一样没法做横向对比。第二幻觉问题在专业术语上特别明显。LLM 对量化这个词的理解经常在模型量化quantization和金融量化交易之间反复横跳我见过它把一篇讲 INT8 推理的论文总结成提出了一种新的股票交易策略这种错误在汇总场景里是致命的。第三成本。300 篇论文每篇都调一次大模型按当时的 token 价格算一天下来光 API 费用就够我喝一个月咖啡了。所以我最后定的方案是规则优先LLM 兜底。先用关键词匹配、类别过滤、引用信号这些确定性手段做第一轮筛选把 300 篇压到 40 篇左右然后对这 40 篇做结构化字段抽取标题、作者、核心方法、数据集、主要结论抽取用规则模板加少量 LLM 辅助最后再按主题聚类输出。这个思路的核心判断是汇总的价值在于筛不在于写。读者要的是今天有哪些值得看的而不是今天所有论文的复述。想清楚这一点整个系统的复杂度就降下来了。2.2 主题分类的粒度怎么定分类粒度是这套系统里最需要反复调的地方。分太粗比如只分理论/应用那筛选等于没做分太细比如按具体子领域分成 50 类那每类就一两篇聚类失去意义。我最后定的是两层分类第一层是 6 个大类第二层是每个大类下 3 到 8 个小类。以 9 月 23 日这天为例第一层的大类分布大致是这样的大类论文数占比典型小类大模型与推理7826%推理加速、KV Cache、量化、长上下文生成模型5217%扩散模型、流匹配、视频生成强化学习与智能体4515%Agent 框架、多智能体、RLHF图与几何学习3813%GNN、等变网络、分子建模优化与理论4114%收敛性分析、泛化界、采样其他应用4615%推荐、时序、医疗、金融这个分布不是拍脑袋定的是我统计了过去三个月每天的分类结果取了一个相对稳定的比例。你会发现大模型与推理这一类长期占四分之一以上这跟当前的研究热度是吻合的。如果你自己的方向偏传统机器学习比如做 SVM、决策树这类那这个分类体系需要调整——把优化与理论和其他应用的权重提上来把大模型那类拆细。提示分类体系不要一次定死。我的做法是每周回顾一次误分类的样本如果某个小类连续一周都有超过 5 篇被错分就说明这个类需要拆分或者合并。2.3 热度信号怎么算才靠谱光有分类还不够同一天同一个类里可能有 20 篇论文你得告诉读者哪几篇更值得先看。我用了三个信号加权作者与机构信号通讯作者是否来自过去两年在该方向高产的研究组权重 0.3方法新颖度信号标题和摘要里是否出现新的方法名、是否引用了近期高影响力工作权重 0.4社区早期反馈信号论文上线后 24 小时内的社交平台讨论量、代码仓库 star 增速权重 0.3第三个信号需要额外抓取实现成本最高但实测下来它的区分度最好。9 月 23 日这天有一篇讲基于分块 KV Cache 的推理加速的论文前两个信号都只是中等但上线 12 小时内相关讨论量冲到了当天前五最后被排到了推荐位第一。事后看这篇确实在接下来一周被多个团队复现了。权重不是固定的你可以根据自己的需求调。如果你更看重权威性把第一个信号提到 0.5如果你做的是工程落地更看重能不能马上用那第三个信号应该占大头。3. 核心细节解析与实操要点3.1 数据抓取别小看这一步的坑arXiv 提供了官方的 API但直接用 API 抓 cs.LG 有个问题它返回的是全量列表没有按日期过滤的原生参数。你得自己按published字段筛。我一开始用submittedDate做范围查询结果发现时区处理经常出错导致漏抓或者重复抓。正确的做法是用 OAI-PMH 接口配合from和until参数时间统一用 UTC。下面是我实际在用的抓取核心逻辑import requests import xml.etree.ElementTree as ET from datetime import datetime, timedelta def fetch_arxiv_cs_lg(target_date): base_url http://export.arxiv.org/oai2 # 注意OAI-PMH 的日期是 UTC且粒度到天 params { verb: ListRecords, metadataPrefix: arXiv, from: target_date.strftime(%Y-%m-%d), until: target_date.strftime(%Y-%m-%d), set: cs:cs.LG } records [] while True: resp requests.get(base_url, paramsparams, timeout30) root ET.fromstring(resp.content) for record in root.findall(.//{http://www.openarchives.org/OAI/2.0/}record): records.append(parse_record(record)) # 处理分页 token token root.find(.//{http://www.openarchives.org/OAI/2.0/}resumptionToken) if token is None or not token.text: break params {verb: ListRecords, resumptionToken: token.text} return records这里有几个实操要点。第一必须处理 resumptionToken否则你只能拿到前 100 条后面的全丢。第二请求间隔至少 3 秒arXiv 对高频请求会限流我吃过一次亏连续快速请求之后 IP 被临时封了半小时。第三解析 XML 时注意命名空间OAI-PMH 的返回结构里所有标签都带命名空间前缀不处理的话findall会返回空。抓下来的原始数据我建议先落一份 JSON 存档不要直接进处理流程。原因很简单如果后面的处理逻辑改了你可以直接从存档重跑不用重新抓。我现在的存档目录是按日期分的raw/2026-09-23.json这种结构半年下来也就几百 MB。3.2 关键词过滤怎么把 300 篇压到 40 篇这是整个系统里最需要手感的一步。纯靠关键词匹配会漏纯靠语义相似度会误召我的做法是三层过滤。第一层是硬性排除。有些论文虽然挂在 cs.LG 下但明显不属于机器学习核心范畴比如纯应用报告、综述、position paper。我用一个排除词表处理包含 survey、position paper、comment on 这类。这一层能砍掉大概 15%。第二层是方向匹配。根据你自己的研究方向维护一个关键词表。以我关注的 LLM 推理方向为例核心词包括inference、quantization、KV cache、speculative decoding、serving、latency、throughput。注意这里要用词干匹配而不是精确匹配否则 quantize 和 quantization 会被当成两个词。我用的是简单的 Porter Stemmer够用了。第三层是语义补召。前两层都是基于字面的会漏掉那些用不同措辞表达同一件事的论文。比如有篇论文标题里没有 quantization但摘要里说 reducing numerical precision of activations这明显是量化相关。这一层我用一个轻量的句向量模型做相似度计算阈值设在 0.62 左右。这个阈值是我拿 200 篇人工标注样本调出来的低于 0.6 误召明显上升高于 0.65 开始漏召。三层下来300 篇通常能压到 35 到 45 篇之间。这个数量刚好再多读者看不完再少可能漏掉重要的。3.3 结构化字段抽取模板比模型更稳前面说了我不建议对每篇论文都调大模型做摘要。那结构化字段怎么来答案是模板加规则。以核心方法这个字段为例我用的模板是[方法类型] [针对的问题] [关键机制]。方法类型从一个预定义的枚举里选比如 fine-tuning、prompting、architecture、decoding、quantization针对的问题从摘要里用规则抽取关键机制则优先从标题里提取。举个实际例子。9 月 23 日有一篇论文标题是 Blockwise KV Cache Compression for Long-Context Inference抽取结果是这样的方法类型quantization / compression针对的问题long-context inference memory footprint关键机制blockwise KV cache compression这套模板的准确率我实测在 85% 左右剩下的 15% 主要是那些标题写得很文学化的论文比如用比喻或者生造词。对于这类我会用一个轻量 LLM 做兜底但只处理这一小部分成本可控。注意字段抽取的模板一定要版本化。我现在的模板文件带版本号每次改动都记录改了什么、为什么改。因为一旦你开始做历史回溯模板变了会导致新旧数据不可比。3.4 聚类与排序让清单有节奏感最后一步是把筛选出来的论文组织成一份可读的清单。我的做法是先聚类再排序而不是直接按热度排。聚类用的是层次聚类距离度量用摘要的句向量余弦距离。聚类的数量不固定根据当天的论文数动态调整一般控制在 6 到 10 个簇。每个簇给一个自动生成的主题标签标签的生成规则是取簇内所有论文关键词的 TF-IDF 最高的 2 到 3 个词组合。排序则是在簇内做。每个簇内按前面说的热度信号排序但会做一个多样性惩罚——如果同一个研究组在同一天有多篇论文只保留热度最高的那篇在推荐位其余的降级展示。这个规则是为了避免清单被某一个组刷屏。9 月 23 日这天的清单最终结构是这样的8 个主题簇推荐位 12 篇其余 28 篇按簇分组展示。读者扫一眼推荐位就能抓住当天重点想深入某个方向再看对应簇。4. 实操过程与核心环节实现4.1 环境准备与依赖清单整套系统跑在一台 16GB 内存的普通开发机上就够了不需要 GPU。依赖也不复杂pip install requests lxml scikit-learn numpy pandas \ sentence-transformers jieba这里重点说两个。sentence-transformers用来做句向量我选的是all-MiniLM-L6-v2这个模型体积小约 80MB、速度快CPU 上单条 10ms 左右、效果够用。如果你追求更好的语义匹配效果可以换bge-small-zh或者bge-small-en但内存占用会上去。jieba是做中文分词用的因为我的输出清单是中文的主题标签需要中文分词。数据库我用的 SQLite单文件、零配置、够用。表结构很简单一张papers表存论文元信息一张daily_summary表存每天的汇总结果。如果你要长期维护建议加一张tags表做多对多关联方便后续按标签检索。4.2 完整流程的代码骨架整个流程我拆成了五个函数串起来跑def daily_pipeline(target_date): # 1. 抓取 raw fetch_arxiv_cs_lg(target_date) save_raw(raw, target_date) # 2. 三层过滤 filtered hard_exclude(raw) filtered keyword_match(filtered, MY_KEYWORDS) filtered semantic_recall(filtered, threshold0.62) # 3. 结构化抽取 structured [extract_fields(p) for p in filtered] # 4. 聚类 clusters cluster_papers(structured, n_clustersauto) # 5. 排序与输出 ranked rank_within_clusters(clusters) output_markdown(ranked, target_date)跑一遍的耗时在 300 篇输入下大概是 4 到 6 分钟其中句向量计算占了大头。如果你嫌慢可以把句向量那一步改成批处理一次算 64 条能快 3 倍左右。4.3 参数选择的依据几个关键参数我单独说一下选择依据因为这些是最容易拍脑袋定错的地方。语义召回阈值 0.62这个前面提过是拿 200 篇人工标注样本调出来的。具体做法是画 precision-recall 曲线找 F1 最高的点。0.62 对应的 F1 是 0.79precision 0.83recall 0.75。如果你更怕漏可以降到 0.58recall 能到 0.82但 precision 会掉到 0.76。聚类数量我用的是n_clusters max(6, min(10, len(papers) // 5))。这个公式的意思是每 5 篇论文一个簇但至少 6 个簇、最多 10 个簇。实测下来这个范围最舒服簇内论文数在 4 到 8 篇之间既不会太散也不会太挤。多样性惩罚的阈值同一个研究组超过 2 篇就触发降级。这个数字是试出来的设成 1 太激进会把正常的多篇工作也压下去设成 3 又太宽松起不到防刷屏的作用。4.4 输出格式的设计输出我坚持用 Markdown因为它在任何地方都能读而且方便二次编辑。每篇论文的展示格式固定为### [序号] [标题] - 方法xxx - 问题xxx - 机制xxx - 热度xxx - 链接xxx这个格式看起来简单但字段顺序是有讲究的。把方法放第一位是因为读者扫读时最先想知道的是这篇用了什么招问题放第二位回答解决什么机制放第三位是给想深入了解的人看的。热度和链接放最后属于辅助信息。提示如果你要把清单分享给别人建议额外生成一份纯文本版。Markdown 在某些聊天工具里渲染会乱纯文本反而更稳。5. 常见问题与排查技巧实录5.1 抓取环节的典型问题问题一某天抓到的论文数明显偏少。我遇到过好几次正常 300 篇的日子只抓到 80 篇。排查下来基本都是 resumptionToken 处理有问题中途断了没继续翻页。解决办法是在循环里加日志每翻一页记录一次当前累计数量如果某一页返回 0 条但 token 还在说明解析逻辑有 bug。问题二论文重复。arXiv 偶尔会出现同一篇论文被分配多个 ID 的情况比如跨类别提交。我的去重策略是用标题的归一化字符串做 key归一化包括转小写、去标点、去多余空格。这个策略能覆盖 95% 以上的重复剩下的靠人工抽查。问题三时区导致的日期错位。这个坑我踩得最深。arXiv 的published字段是 UTC 时间但如果你按本地时间筛会出现今天的论文跑到昨天的情况。统一用 UTC并且在输出时明确标注以下为 UTC 2026-09-23 发布的论文。5.2 过滤环节的误判与修正过滤环节最常见的问题是误杀和误召我整理了一个速查表现象可能原因排查方法修正手段明显相关的论文没进清单关键词表缺词抽查被过滤的论文标题补充同义词、词干变体不相关的论文混进来语义阈值太低看误召论文的相似度分数提高阈值到 0.65某个方向整体缺失该方向用了特殊术语人工浏览该方向近期论文针对性补充术语表综述类论文反复出现排除词表不全统计被排除论文的类型扩充排除词表我自己的经验是每周花 20 分钟做一次误判回顾比每天调参数有效得多。因为误判往往有模式集中看一批就能发现规律。5.3 结构化抽取的边界情况抽取环节最麻烦的是那些标题党论文。有些论文标题写得很吸引人但摘要里全是套话抽出来的字段空洞无物。我的处理方式是加一个信息量检查如果抽取出的三个字段里有两个以上是空或者长度小于 5 个字符就标记为需人工复核不直接进清单。另一个边界情况是多方法论文。有些论文同时提出了架构改进和训练技巧这时候模板会抽取出多个方法类型。我的做法是保留全部但在展示时用顿号连接比如方法architecture、training。不要强行合并因为读者需要知道这篇论文的完整贡献。5.4 性能与成本控制如果你打算长期跑这套系统成本控制要提前想。我的做法是抓取每天一次凌晨跑避开 arXiv 的高峰期句向量本地模型零 API 成本但要注意内存批处理时 batch size 不要超过 64LLM 兜底只在抽取失败时调用一天通常不超过 5 次存储原始数据保留 90 天汇总结果永久保留按这个配置一年的总成本基本就是电费和机器折旧没有额外的 API 支出。如果你用的是云服务器注意把句向量模型缓存在本地不要每次重新下载。5.5 我踩过的三个大坑第一个坑是过早引入 LLM。我一开始就想用大模型做全流程结果调试了两周发现规则能解决的问题根本不需要模型模型反而引入了不确定性。后来我把 LLM 的使用范围压缩到兜底系统稳定性立刻上来了。第二个坑是分类体系频繁变动。有段时间我每天改分类导致历史数据没法对比。后来定了规矩分类体系一个月只能改一次且改动必须记录在案。第三个坑是忽略输出可读性。早期我的清单是纯数据表格字段齐全但没人愿意看。后来改成推荐位 分组展示的结构阅读完成率明显提升。这件事让我意识到汇总系统的最终用户是人不是数据库。6. 把这套流程迁移到你的方向这套东西不是只能用在 cs.LG 上。如果你做的是计算机视觉把抓取的 set 换成 cs.CV关键词表换成 detection、segmentation、diffusion 这些其余逻辑完全复用。如果你做的是量化交易arXiv 上 q-fin 板块也有对应的接口只是论文量少一些每天几十篇过滤阈值可以调松一点。迁移时唯一需要重新调的是语义召回阈值和聚类数量。不同领域的论文写作风格差异很大比如理论方向的摘要普遍更长、术语更密集阈值要相应提高应用方向的摘要更口语化阈值可以降低。我的建议是新领域先跑一周人工看每天的清单根据误判情况微调一周之后基本就稳了。最后分享一个我最近加的小功能跨天去重。有些论文会在多个日期重复出现比如修订版我在输出前会跟过去 7 天的清单做一次比对重复的直接标注已收录并折叠。这个功能让清单的新鲜度提升了不少读者不用再看到昨天已经看过的内容。这套系统我跑了快一年最大的体会是工具的价值不在于多智能而在于多稳定。一个每天准时产出、格式统一、误判可控的简单系统比一个偶尔惊艳但经常出错的复杂系统有用得多。如果你也在做类似的事情建议从最简单的规则版本开始跑通了再逐步加东西别一上来就追求全自动。