GPT4 论文助手:每日 ArXiv 扫描器
此仓库实现了一个非常简单的 Arxiv 每日扫描器,利用 GPT4 和作者匹配来找到你可能感兴趣的论文。它将通过 GitHub Actions 每日运行,并可以通过一个机器人将这些信息发布到 Slack,或者仅在静态的 GitHub Pages 网站上渲染显示。
可以在 这里 看到一个运行在 cs.CL
上的每日论文简单演示。
作为成本估算,在 2024 年 2 月 7 日运行在所有 cs.CL
上的费用为 $0.07。
更新日志
- 2024/2/15: 修复了 RSS 格式中的作者解析错误 + 标题筛选的成本估算不准确 + 当订阅源中无论文时崩溃的问题。
- 2024/2/7: 修复了 ArXiv 更改其 RSS 格式引发的关键问题。添加并启用了标题筛选以降低成本。
快速开始
这是让扫描器运行的最低必要步骤。强烈建议阅读全文以决定你想要运行的内容。
在 GitHub Actions 上运行
- 将此仓库复制/分叉到一个新的 GitHub 仓库,并启用计划的工作流(如果你分叉了它)。
- 将
config/paper_topics.template.txt
复制到config/paper_topics.txt
,并填写你想要关注的论文类型。 - 将
config/authors.template.txt
复制到config/authors.txt
,并列出你真正想要关注的作者。作者后面的数字非常重要。它们是 Semantic Scholar 作者 ID,你可以通过在 Semantic Scholar 上查找作者并获取 URL 末尾的数字来找到这些 ID。 - 在
config/config.ini
中设置你想要的 ArXiv 类别。 - 将你的 OpenAI 密钥 (
OAI_KEY
) 设置为 GitHub 密钥。 - 在你的仓库设置中,将 GitHub 页面构建源设置为 GitHub Actions。
此时你的机器人应每日运行并发布一个静态网站。你可以通过手动运行 GitHub Action 工作流来测试这一点。
可选但强烈推荐:
- 获取并设置 Semantic Scholar API 密钥 (
S2_KEY
) 作为 GitHub 密钥。否则作者搜索步骤将会非常缓慢。 - 设置一个 Slack 机器人,获取 OAuth 密钥,将其设置为
SLACK_KEY
作为 GitHub 密钥。 - 为机器人创建一个频道(并邀请它加入频道),获取其 Slack 频道 ID,并将其设置为 GitHub 密钥中的
SLACK_CHANNEL_ID
。 - 查看
configs/config.ini
,以调整筛选内容。 - 将 GitHub 仓库设置为私有,以避免 GitHub Actions 在 60 天后被设置为非活动状态。
每天在 UTC 时间下午 1 点,机器人将运行并发布到 Slack,同时发布一个 GitHub Pages 网站(查看 publish_md
和 cron_runs
操作了解详细信息)。
本地运行
步骤大致与上面相同,但你需要通过 requirements.txt
设置环境。
而不是通过 GitHub 密钥传递凭证,你需要设置环境变量 OAI_KEY
、SLACK_KEY
、SLACK_CHANNEL_ID
。
要运行所有内容,只需调用 main.py
。
其他注意事项:
你可能还不想推送到 Slack,在这种情况下,可以在 config/config.ini
的 dump_json
、dump_md
和 push_to_slack
字段中设置你想要的输出端点(json、markdown、slack)。
如果 Semantic Scholar API 超时或运行缓慢,你应该获取一个 S2 API 密钥 并将其设置为环境变量中的 S2_KEY
。
(由于 GitHub Actions 的限制,这只会在代码本地运行时有帮助)
让它自行运行:
整个过程几乎不需要计算资源,因此你可以租用最便宜的 AWS 虚拟机,将此仓库放入其中,安装 requirements.txt
,适当地设置环境变量并添加以下 crontab:
0 13 * * * python ~/arxiv_scanner/main.py
此 crontab 将在 UTC 时间下午 1 点,即太平洋时间下午 6 点运行脚本。
创建 paper_topics.txt
提示词
paper_topics.txt
文件用于生成 GPT 的提示词。它是你想要关注的主题列表。
一个例子可能是这样的:
1. 针对 RLHF 或指令跟随的新方法改进,这是为了使语言模型在跨多任务中更好地遵循用户指令而采取的特定微调步骤。
- 相关: 讨论特定方法如 RLHF,或指令微调数据集,改进这些方法或分析它们的论文。
- 不相关: 适应某个任务的论文。仅仅遵循指令或输入是不够的。
2. 显示新的语言模型测试集污染或成员推断方法。测试集污染是指语言模型在预训练期间观察到基准数据集的现象。
- 相关: 可以检测语言模型中的基准数据集污染的统计方法。能提供保证的统计方法更为有趣。足够通用以适用于语言模型的成员推断方法也相关。
- 不相关: 任何不考虑语言模型或不考虑测试集污染的论文。
3. 显示在扩散语言模型性能方面的显著进展。
- 相关: 研究语言模型且同时也是扩散模型的论文。连续扩散模型更相关,而离散扩散模型则较少相关。
- 不相关: 关于图像扩散模型如 DALL-E 或 Stable Diffusion 的论文,或没有明确提及语言模型或文本应用的论文。
这只是一个标准的提示词,但在像“扩散语言模型”或“指令跟随”这样的领域中,非常具体的描述会有帮助,因为语言模型可能会混淆图像扩散是否相关,或者是否仅仅做某项任务更好就足以改进指令跟随。
你还可以在此后添加一些一般兴趣领域,比如:
在向你的朋友推荐论文时,请记住他喜欢统计机器学习和自然语言处理中的生成建模方面的论文。
你的朋友还喜欢了解语言模型中的惊人实证结果,以及巧妙的统计技巧。
他不想阅读主要关于将方法应用于特定领域的论文。
工作原理的详细信息
脚本从 RSS 订阅源中抓取特定日期的 ArXiv 论文候选集。为避免重复公告论文,它将只抓取过去一天内的 RSS 订阅源。为避免漏掉论文,你希望每天运行此脚本。 筛选逻辑非常简单。我们首先检查作者匹配。
- 在 Semantic Scholar 上查找作者,获取候选匹配列表。
- 检查论文的作者。如果作者的 Semantic Scholar ID 与
authors.txt
中的某个人匹配,它将进入候选集,默认得分为author_match_score
。
然后我们检查 GPT 评估的相关性。我们分两步进行。
- 筛选掉
config.ini
中hcutoff
以下的所有作者的论文。这样可以降低成本。 - 将所有剩余的示例批量处理,并由
config.ini
中指定的 GPT 模型评估。你应该只使用 GPT3.5 进行调试。它在此目的上效果不佳! 此步骤使用configs/
中定义的以下提示词设置:
你是一个有帮助的论文阅读助手,你的工作是阅读每日来自 ArXiv 的帖子,并识别一些可能与朋友相关的论文。下面最多有 5 篇论文。你的工作是找到:
- 标准 1
- 标准 2
[PAPERS]
以 JSONL 格式写出每篇论文的 {ARXIVID, COMMENT, RELEVANCE, NOVELTY},每行一个。 ARXIVID 应为 ArXiv ID。 COMMENT 应指出是否有非常接近地匹配论文的标准。如果有,应按编号提到它(无需提到不匹配的标准)。 这些匹配不