基于arXiv API与语义打分的每日论文分析报告自动化流水线

1. 从一篇“每日论文分析报告”说起为什么我要把 arXiv 刷成流水线每天早上七点半我的邮箱里会准时躺着一封自己写给自己的邮件标题格式固定是“arXiv 每日论文分析报告 YYYY-MM-DD”。点开之后是当天 arXiv 上与我研究方向相关的十几篇新论文每篇都带着一句话的核心贡献、方法关键词、和我已有工作的关联度打分以及“值得精读 / 扫一眼 / 直接跳过”的三档标签。这套东西不是某个现成服务推给我的而是我自己搭的一条小流水线跑出来的结果。今天这篇博文我就拿“arXiv 每日论文分析报告2026-09-24”这一天的报告作为样本把整条链路从订阅、抓取、筛选、分析到成文完整拆一遍。先说清楚这套东西解决什么问题。做研究或者做工程的人都知道arXiv 每天新增的论文量是海量的光是 cs.CL、cs.CV、cs.LG 这几个大类一天几百篇是常态。靠人肉刷列表结果只有两个要么漏掉真正重要的要么被大量低相关内容淹没刷了半小时啥也没记住。我需要的不是“更多论文”而是“更少但更准的论文”并且每篇都带上足够的上下文让我能在三十秒内判断要不要花两小时去读。这就是“每日论文分析报告”的核心价值——它把信息过载问题转化成了一个排序和摘要问题。这套流程适合谁参考三类人。第一类是刚进组的研究生还没建立起自己的论文追踪习惯需要一套能直接抄的模板第二类是做工程但需要跟进前沿的开发者没时间系统读论文只想知道“这周有没有能用到我项目里的新方法”第三类是做技术情报、投资分析或者内容创作的人需要快速摸清某个方向最近的动向。不管你属于哪一类下面的内容都能按需裁剪——重活我干了你挑能用的部分搬走就行。关键词我先摆在这arXiv、论文分析报告、订阅、抓取、筛选、摘要、打分。这几个词基本覆盖了整条链路的每个环节后面每个章节我都会围绕它们展开不会跑偏。2. 整体设计思路为什么是“订阅 抓取 本地分析”而不是现成工具2.1 现成服务的三个硬伤市面上追踪 arXiv 的工具不少有网页版的、有邮件订阅的、有做成 App 的。我前后试过七八个最后都放弃了原因集中在三点。第一是筛选维度太粗。大部分工具只支持按 arXiv 分类比如 cs.CL或者关键词订阅但关键词匹配是字面匹配我关注“retrieval augmented generation”它会把所有标题里带 retrieval 的论文都推给我包括做数据库检索的、做图像检索的噪音极大。我需要的是语义层面的相关性而不是字符串层面的。第二是摘要质量参差。有些工具直接截取论文摘要的前两句但 arXiv 摘要的写法千奇百怪有的前两句全是背景铺垫真正的贡献藏在第三句。我需要的是“这篇论文到底做了什么新东西”而不是“这篇论文在讨论什么领域”。第三是无法定制输出。我想要的是每天一封邮件、按相关性排序、带打分和标签、能直接归档成 Markdown 的格式。现成工具要么只能网页看要么邮件格式固定死改不了。2.2 自建流水线的四个模块想清楚这些之后我把整条链路拆成了四个模块每个模块职责单一方便单独替换和调试。订阅模块负责确定“我要关注哪些方向”。不是简单填几个关键词而是维护一份“兴趣画像”包含核心关键词、负向关键词、以及几个我信任的种子论文标题用来做语义相似度锚点。抓取模块负责每天从 arXiv 拉取新增论文的元数据。arXiv 官方提供了 API返回 Atom 格式的 XML包含标题、作者、摘要、分类、提交时间、PDF 链接等字段够用了。分析模块这是整条链路的核心。对每篇论文做三件事——相关性打分、贡献摘要、标签分类。相关性打分用嵌入向量做余弦相似度贡献摘要用规则加模板生成标签分类用关键词加分类映射。成文模块把分析结果渲染成一份结构化的 Markdown 报告按打分排序分档展示最后通过邮件或者本地文件输出。2.3 为什么不用大模型一把梭有人会问现在大模型这么强为什么不直接把论文标题和摘要丢给模型让它输出分析结果我试过结论是可以但不划算也不稳定。不划算是因为成本。一天几百篇论文每篇都调一次大模型 API一个月下来费用不低而且大部分论文其实和我无关没必要为它们花钱。不稳定是因为大模型的输出格式会飘今天让它输出 JSON明天可能就给你加一段解释性文字解析起来很烦。更重要的是大模型对“相关性”的判断依赖提示词而提示词很难精确表达“我关心的 retrieval augmented generation 是指用外部知识增强生成不是指数据库检索”这种细微差别。所以我的方案是分层处理先用轻量的嵌入模型做粗筛把几百篇砍到十几篇只对这十几篇调用大模型做精细摘要和标签。这样成本可控格式也稳定因为进入精处理阶段的论文数量少我可以对输出格式做严格校验。2.4 一天的报告长什么样先给你看看 2026-09-24 那天的报告结构心里有个底。整份报告分四块今日概览新增论文总数、命中数、各档数量分布、当天最热的关键词。精读推荐打分最高的 3 到 5 篇每篇带完整分析。扫读列表打分中等的 8 到 12 篇每篇一句话总结。跳过清单打分低但命中了关键词的论文只列标题供快速扫一眼确认没漏。这个结构的好处是我早上花两分钟看概览和精读推荐五分钟扫完扫读列表跳过清单基本不看。整个流程控制在十分钟以内信息获取效率比人肉刷列表高一个数量级。3. 核心细节解析订阅、抓取、打分、摘要的实操要点3.1 订阅模块兴趣画像怎么建才不跑偏订阅不是填关键词那么简单。我踩过的最大坑是一开始只填了“retrieval augmented generation”和“large language model”两个词结果每天推来的论文里有一半是我不关心的比如做 LLM 推理加速的、做 LLM 安全对齐的。这些方向本身很重要但不是我的菜。后来我把兴趣画像拆成了三层。第一层是核心关键词3 到 5 个必须精确。比如我的核心词是“retrieval augmented generation”“dense retrieval”“knowledge grounded generation”。这些词一旦命中相关性基础分就很高。第二层是负向关键词用来排除干扰。比如我加了“database”“SQL”“image retrieval”“recommendation”因为这几个词经常和 retrieval 一起出现但方向完全不同。负向词命中不直接淘汰而是扣分。第三层是种子论文5 到 10 篇我读过且觉得代表性的论文标题。这些标题会被转成嵌入向量作为语义相似度的锚点。一篇新论文如果和某个种子论文的相似度超过阈值即使关键词没命中也会被捞回来。这一层是防止漏掉“用词不同但方向相同”的论文。三层结合起来订阅的准确率和召回率都上来了。实测下来每天命中数从最初的四五十篇降到了十几篇但真正相关的比例从不到三成提到了七成以上。3.2 抓取模块arXiv API 的正确用法arXiv 的 API 入口是http://export.arxiv.org/api/query支持按分类、关键词、时间范围查询。几个关键参数必须搞清楚不然抓回来的数据要么不全要么重复。search_query查询表达式。按分类查用cat:cs.CL按时间查用submittedDate:[202609230000 TO 202609240000]多个条件用AND、OR连接。start和max_results分页参数。单次最多返回 2000 条但实际用的时候建议每次 100 条分页拉避免超时。sortBy排序字段。我一般用submittedDate按提交时间倒序。sortOrderdescending或ascending。一个容易忽略的点是时区。arXiv 的提交时间用的是东部时间而我的报告是按北京时间早上七点半生成的。如果不做时区转换会漏掉当天凌晨提交的论文。我的做法是查询范围往前多取 12 小时然后在本地按转换后的时间过滤。另一个坑是重复提交。同一篇论文可能因为作者修改而多次出现在列表里version 号不同但标题一样。我的去重策略是用 arXiv ID 去掉版本号后的部分作为唯一键保留最新版本。抓取频率也要注意。arXiv 官方建议不要高频请求我设置的是每天一次早上六点半跑请求间隔 3 秒避免给对方服务器造成压力。这既是礼貌也是避免被封 IP 的自我保护。3.3 打分模块相关性分数怎么算才靠谱打分是整条链路里最需要调参的部分。我的打分公式是加权求和score 0.4 * keyword_score 0.4 * semantic_score 0.2 * recency_score - penalty逐项解释。keyword_score核心关键词命中情况。命中一个核心词加 0.3命中两个加 0.6三个以上直接给 1.0。负向词每命中一个扣 0.2。这个分数是离散的容易计算但不够细腻。semantic_score语义相似度。把论文标题和摘要拼起来用嵌入模型转成向量和每个种子论文向量算余弦相似度取最大值。这个分数是连续的能捕捉到关键词没覆盖的相关性。我用的是本地部署的小型嵌入模型速度快不需要联网隐私也好。recency_score新鲜度。当天提交的给 1.0前一天给 0.8两天前给 0.5更早的给 0.2。这个分数是为了让报告偏向最新论文毕竟旧论文我可能已经看过了。penalty惩罚项。除了负向关键词还包括一些启发式规则比如标题里带“survey”的扣 0.1综述通常不是我最优先读的带“workshop”的扣 0.2workshop 论文质量参差作者数超过 15 个的扣 0.1大团队论文往往方向较泛。这套公式我调了大概两周主要调的是权重和阈值。最终定下来的分档标准是score ≥ 0.75 进精读推荐0.45 到 0.75 进扫读列表0.2 到 0.45 进跳过清单低于 0.2 直接丢弃。3.4 摘要模块一句话说清论文贡献的模板摘要生成是最容易做成“正确的废话”的环节。我见过很多工具生成的摘要就是“本文提出了一种新方法在多个数据集上取得了良好效果”这种摘要等于没说。我的做法是用结构化模板 关键信息抽取。每篇论文的摘要固定包含四个部分做了什么从标题和摘要里抽取动词短语比如“提出了一种基于对比学习的检索器”。怎么做的抽取方法关键词比如“对比学习”“负采样”“双塔结构”。效果如何抽取数据集和指标比如“在 BEIR 上 nDCG10 提升 3.2 个点”。和我的关系基于打分结果说明为什么推荐比如“和你的种子论文 X 方法相似但改进了负采样策略”。前三个部分用规则加正则抽取第四个部分用模板填充。对于进入精读推荐的论文我会额外调用一次大模型让它基于这四个部分生成一段更自然的描述但格式仍然受模板约束避免跑偏。这里有个实操心得摘要里一定要保留具体数字。“效果提升明显”是废话“提升 3.2 个点”才有信息量。所以我在抽取阶段会专门匹配数字加单位的模式确保关键指标不被漏掉。4. 实操过程从零搭起这条流水线4.1 环境准备与依赖安装整套系统跑在一台常开的迷你主机上系统是 Ubuntu 22.04配置不高4 核 8G 内存足够用了。依赖分三块Python 环境、嵌入模型、邮件发送。Python 用 3.10虚拟环境管理用 venv。核心依赖库pip install requests feedparser numpy scikit-learn sentence-transformers jinja2 python-dateutilrequests发 HTTP 请求调 arXiv API。feedparser解析 Atom XML比手写 XML 解析省事。numpy和scikit-learn算余弦相似度、做归一化。sentence-transformers加载本地嵌入模型。jinja2渲染 Markdown 报告模板。python-dateutil处理时区转换。嵌入模型我选的是all-MiniLM-L6-v2体积小约 80MB速度快在 CPU 上跑几百篇论文的向量化也就几十秒。如果你的机器有 GPU可以换更大的模型效果会更好但对我来说这个小模型够用了。邮件发送用 SMTP我用的是自己的邮箱服务配置放在环境变量里不写进代码。这一点很重要密钥和密码绝对不能硬编码在脚本里不然一旦代码泄露就麻烦了。4.2 抓取脚本的完整实现抓取脚本的核心逻辑是构造查询表达式、分页拉取、解析 XML、去重、存成 JSON。下面是我实际用的代码骨架。import requests import feedparser from datetime import datetime, timedelta from dateutil import tz ARXIV_API http://export.arxiv.org/api/query CATEGORIES [cs.CL, cs.IR, cs.LG] def build_query(categories, start_date, end_date): cat_query OR .join([fcat:{c} for c in categories]) date_query fsubmittedDate:[{start_date} TO {end_date}] return f({cat_query}) AND {date_query} def fetch_papers(query, max_results500): papers [] batch_size 100 for start in range(0, max_results, batch_size): params { search_query: query, start: start, max_results: batch_size, sortBy: submittedDate, sortOrder: descending, } resp requests.get(ARXIV_API, paramsparams, timeout30) feed feedparser.parse(resp.content) if not feed.entries: break for entry in feed.entries: papers.append(parse_entry(entry)) time.sleep(3) return papers def parse_entry(entry): arxiv_id entry.id.split(/abs/)[-1] base_id arxiv_id.split(v)[0] return { id: base_id, version: arxiv_id, title: entry.title.strip().replace(\n, ), abstract: entry.summary.strip().replace(\n, ), authors: [a.name for a in entry.authors], categories: [t[term] for t in entry.tags], published: entry.published, pdf_url: entry.link.replace(/abs/, /pdf/), }几个细节值得说。time.sleep(3)是必须的不加的话连续请求容易被限流。base_id去掉版本号是为了去重同一篇论文的 v1 和 v2 只保留最新的。标题和摘要里的换行符要清掉不然渲染报告时格式会乱。时区转换在查询之前做。我的报告是北京时间早上七点半生成对应东部时间前一天晚上七点半。所以查询范围是东部时间前一天 00:00 到当天 00:00换算成 arXiv 的格式就是202609230000 TO 202609240000。4.3 打分与筛选的落地打分脚本接收抓取到的论文列表输出带分数的列表。核心是加载嵌入模型、算相似度、套公式。from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(all-MiniLM-L6-v2) CORE_KEYWORDS [retrieval augmented generation, dense retrieval, knowledge grounded generation] NEGATIVE_KEYWORDS [database, sql, image retrieval, recommendation] SEED_TITLES [ Dense Passage Retrieval for Open-Domain Question Answering, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, # ... 更多种子论文 ] seed_embeddings model.encode(SEED_TITLES, normalize_embeddingsTrue) def keyword_score(text): text_lower text.lower() score 0.0 for kw in CORE_KEYWORDS: if kw in text_lower: score 0.3 score min(score, 1.0) for nkw in NEGATIVE_KEYWORDS: if nkw in text_lower: score - 0.2 return max(score, 0.0) def semantic_score(text): emb model.encode([text], normalize_embeddingsTrue)[0] sims np.dot(seed_embeddings, emb) return float(np.max(sims)) def recency_score(published_str): pub datetime.strptime(published_str, %Y-%m-%dT%H:%M:%SZ).replace(tzinfotz.UTC) now datetime.now(tz.UTC) hours (now - pub).total_seconds() / 3600 if hours 24: return 1.0 elif hours 48: return 0.8 elif hours 72: return 0.5 return 0.2 def compute_score(paper): text paper[title] paper[abstract] ks keyword_score(text) ss semantic_score(text) rs recency_score(paper[published]) penalty 0.0 if survey in paper[title].lower(): penalty 0.1 if workshop in paper[title].lower(): penalty 0.2 if len(paper[authors]) 15: penalty 0.1 return 0.4 * ks 0.4 * ss 0.2 * rs - penalty这段代码里normalize_embeddingsTrue很关键它让向量长度归一化之后点积就等于余弦相似度省去了手动除模长的步骤。semantic_score取的是和所有种子论文相似度的最大值而不是平均值因为一篇论文只要和某一个种子高度相关就够了不需要和所有种子都相关。分档逻辑很简单按 score 排序后按阈值切分。但有个细节精读推荐最多 5 篇即使有 10 篇超过 0.75也只取前 5。这是为了控制我的阅读负担宁可漏掉几篇也不能让报告变成新的信息过载源。4.4 报告渲染与邮件推送渲染用 Jinja2 模板输出 Markdown。模板结构对应前面说的四块概览、精读、扫读、跳过。概览部分统计各档数量、当天高频关键词、以及和前一天的数量对比。from jinja2 import Template REPORT_TEMPLATE ## 今日概览 - 新增论文总数{{ total }} - 命中论文数{{ hit_count }} - 精读推荐{{ deep_count }} 篇 - 扫读列表{{ scan_count }} 篇 - 跳过清单{{ skip_count }} 篇 ## 精读推荐 {% for p in deep_papers %} ### {{ loop.index }}. {{ p.title }} - **相关性打分**{{ %.2f|format(p.score) }} - **核心贡献**{{ p.summary }} - **方法关键词**{{ p.method_keywords|join(、) }} - **推荐理由**{{ p.reason }} - **PDF**{{ p.pdf_url }} {% endfor %} ## 扫读列表 {% for p in scan_papers %} - **{{ p.title }}**{{ %.2f|format(p.score) }}{{ p.one_liner }} {% endfor %} ## 跳过清单 {% for p in skip_papers %} - {{ p.title }} {% endfor %} 邮件发送用smtplib把渲染好的 Markdown 转成 HTML 或者直接发纯文本都行。我选的是纯文本加 Markdown因为我在手机和电脑上都是用 Markdown 阅读器看格式清晰复制到笔记软件里也方便。发送时间设在早上七点半用系统的 cron 定时任务触发。整个脚本从抓取到发送大概跑三到五分钟主要时间花在嵌入模型编码上。如果嫌慢可以把模型换成更小的或者只对粗筛后的论文做编码能省不少时间。5. 常见问题与排查技巧实录5.1 抓取不到当天论文怎么办这是最常见的问题原因通常有三个。第一是时区算错了查询范围没覆盖到当天。排查方法是手动把查询范围放宽到前后各两天看能不能抓到如果能就是时区问题。第二是 arXiv API 临时抽风返回空结果或者超时。这种情况重试一次通常就好我在代码里加了三次重试每次间隔 10 秒。第三是分类选错了比如你关注的方向其实在 cs.CL但你只查了 cs.LG。排查方法是把分类放宽看命中数是否正常。5.2 相关性打分不准怎么调打分不准分两种情况该推的没推漏报不该推的推了误报。漏报通常是语义相似度阈值太高或者种子论文太少。解决办法是增加种子论文数量覆盖更多子方向同时把 semantic_score 的权重调高。误报通常是负向关键词不够或者核心关键词太宽泛。解决办法是补充负向词把核心词写得更具体比如把“retrieval”改成“dense retrieval”。我自己的调参经验是先保证召回再优化准确。宁可多推几篇让我自己筛也不要漏掉重要的。所以初期我把阈值设得比较低等报告稳定运行两周后再根据实际阅读情况逐步收紧。5.3 嵌入模型太慢怎么优化all-MiniLM-L6-v2在 CPU 上编码一篇论文大概 20 毫秒几百篇就是十几秒可以接受。但如果你的论文量上千就会明显变慢。优化手段有三个一是只对标题编码不对摘要编码速度能快一倍但准确率会降一点二是用更小的模型比如paraphrase-MiniLM-L3-v2三是把编码结果缓存起来种子论文的向量只算一次不用每次重算。5.4 报告格式乱掉怎么排查Markdown 渲染乱掉九成是论文标题或摘要里有特殊字符没转义。比如标题里带|会破坏表格带#会被当成标题带*会被当成强调。解决办法是在渲染前对文本做转义把|、#、*、_这些字符替换掉或者加反斜杠。我是在parse_entry阶段就做清洗把换行、多余空格、特殊字符统一处理掉后面渲染就省心了。5.5 常见问题速查表问题现象可能原因排查方法解决办法抓取结果为空时区错误 / API 超时 / 分类错误放宽时间范围重试修正时区、加重试、放宽分类漏报重要论文种子太少 / 阈值太高检查漏报论文的关键词增加种子、降低阈值、提高语义权重误报大量无关论文负向词不足 / 核心词太宽统计误报论文的共同词补充负向词、细化核心词编码速度慢模型太大 / 论文太多计时各阶段耗时换小模型、只编码标题、缓存向量报告格式乱特殊字符未转义检查原始标题和摘要渲染前统一转义邮件发送失败SMTP 配置错误 / 被限流看报错信息检查配置、降低发送频率5.6 几个我踩过的坑第一个坑是把 API key 写进了代码。早期图省事直接把邮箱密码写在脚本里后来把代码传到 Git 仓库差点泄露。现在所有敏感信息都走环境变量代码里只留占位符。第二个坑是没有做去重。有段时间报告里同一篇论文出现两次因为作者在当天提交了 v1 和 v2。后来加了基于 base_id 的去重问题解决。第三个坑是报告太长。一开始我把所有命中的论文都详细展开结果报告有几十页根本看不完。后来改成三档展示精读详细、扫读一句话、跳过只列标题阅读负担一下就降下来了。第四个坑是过度依赖大模型。有段时间我让大模型给每篇论文写推荐理由结果它经常编造论文里没有的内容比如虚构数据集名称。后来改成模板填充加规则抽取只在精读论文上让大模型润色并且要求它只能基于给定信息改写不能新增事实。6. 报告之外这套流水线还能怎么扩展6.1 从日报到周报和月报日报适合追踪最新动态但有些趋势需要拉长时间看。我在日报的基础上加了周报和月报。周报把一周的精读推荐汇总按主题聚类看这一周哪个方向最活跃。月报做趋势分析统计各关键词的出现频率变化看哪个方向在升温、哪个在降温。实现上很简单把每天的 JSON 结果存下来周末和月末跑一次聚合脚本就行。6.2 接入个人笔记系统报告里的精读推荐我希望能一键存进我的笔记软件。做法是在报告里给每篇论文加一个本地链接点击后触发一个脚本把论文元数据、我的打分、以及一个空的笔记模板写进笔记库。这样我读论文的时候笔记框架已经搭好了只需要填内容。这个功能用 Obsidian 或者 Logseq 的 URI 协议都能实现不难。6.3 反向订阅让报告学习我的反馈现在的打分是单向的我调参、它执行。更理想的状态是它能从我的阅读行为里学习。比如我在报告里标记某篇论文为“已读且有用”这个反馈可以存下来用来调整种子论文的权重或者微调嵌入模型。这一步我还没做因为需要积累足够的反馈数据但思路是清晰的把每次阅读行为当成一次标注让系统逐步逼近我的真实兴趣。6.4 多方向并行如果你同时关注好几个不相关的方向比如既做 NLP 又做系统可以给每个方向建一套独立的兴趣画像和打分参数报告里分开展示。这样互不干扰每个方向都能得到精准的推荐。实现上就是把配置抽成多个 profile抓取和分析时按 profile 分别跑最后合并成一份报告。6.5 一个实用的小技巧最后分享一个我在实际使用中觉得最省事的技巧把报告的第一屏做成“三行摘要”。也就是在报告最开头用三行字说清楚今天最值得看的一篇是什么、为什么、以及大概要花多久读。这三行是我早上最先看的内容如果时间紧看完这三行就可以关掉了。剩下的详细内容等有空再翻。这个设计看起来简单但极大提升了报告的实用性因为它把“决策成本”降到了最低。这套流水线我跑了快一年中间迭代了十几版从最初的手忙脚乱到现在每天早上十分钟搞定论文追踪效率提升是实打实的。如果你也在被 arXiv 的信息量困扰建议从最简单的抓取加关键词过滤开始先跑起来再逐步加语义打分和摘要生成。不要一上来就追求完美能用的粗糙版本比不能用的完美版本有价值得多。