1. 从投稿记录里挖出会议的真实偏好1.1 为什么选ICLR而不是其他会议做研究的人都有一个共识投会议就像相亲你得先摸清对方的脾气。ICLR作为深度学习领域的顶会之一这几年投稿量涨得离谱录用率却一直压得很低。我连续跟踪了近三年的投稿数据发现一个很有意思的现象——很多人不是工作做得不好而是根本没搞清楚这个会议到底喜欢什么类型的工作。Open Review是ICLR投稿和评审的公开平台所有投稿的标题、摘要、关键词、评审意见、最终决定都挂在上面。这意味着什么意味着你可以拿到海量的真实数据去分析什么样的工作容易被接收什么样的工作会被拒。这比看几篇经验帖靠谱得多。我这次做的事情就是把近三年ICLR的投稿记录全部拉下来做了一次系统性的分析。数据来源就是Open Review的公开API输出格式是JSON然后用Python做清洗和统计最后用词云图做可视化。整个过程不复杂但里面有不少坑我一步步说清楚。1.2 分析目标三个核心问题在动手之前我先明确了自己想回答的三个问题关键词分布近三年ICLR投稿中哪些关键词出现频率最高这些高频词的变化趋势是什么标题模式被接收的论文标题和被拒的论文标题在措辞和结构上有没有明显差异主题演化从2023年到2025年投稿的热门方向有没有发生迁移比如某个方向突然爆火或者某个方向逐渐降温这三个问题决定了后续的数据采集字段和分析维度。如果你只是想随便看看可以只拉标题和关键词但如果你想做趋势分析就必须把年份、决定结果接收/拒稿/撤回也一起拉下来。注意Open Review的数据是公开的但批量拉取时要注意请求频率别把人家服务器搞崩了。我一般设置每次请求间隔0.5秒三千条数据大概跑半小时。2. 数据采集从Open Review到本地JSON2.1 Open Review API的基本用法Open Review提供了REST API返回格式默认就是JSON。核心接口是/notes通过传不同的参数来筛选数据。比如你要拉ICLR 2024的投稿可以这样构造请求curl -X GET https://api2.openreview.net/notes?invitationICLR.cc/2024/Conference/-/Submissionlimit1000offset0 \ -H Accept: application/json几个关键参数说明invitation指定会议和年份格式是ICLR.cc/{year}/Conference/-/Submissionlimit单次返回的最大条数默认是1000最大也是1000offset偏移量用于分页拉取返回的JSON结构大概是这样的{ notes: [ { id: xxxx, content: { title: {value: 论文标题}, keywords: {value: [keyword1, keyword2]}, abstract: {value: 摘要内容} }, invitation: ICLR.cc/2024/Conference/-/Submission, cdate: 1672531200000 } ], count: 1000 }注意content里面的字段都包了一层{value: ...}这是Open Review API v2的格式。如果你用的是旧版API结构可能不一样拉数据之前先确认一下版本。2.2 分页拉取与断点续传三千多条数据不可能一次拉完必须分页。我的做法是写一个循环每次拉1000条直到返回的notes数组为空为止。但这里有个问题如果中途网络断了你得从头再来。所以我在脚本里加了一个简单的断点续传机制——每拉完一页就把数据追加写入本地JSON文件同时记录当前的offset。import json import time import requests def fetch_iclr_submissions(year, start_offset0): base_url https://api2.openreview.net/notes all_notes [] offset start_offset limit 1000 while True: params { invitation: fICLR.cc/{year}/Conference/-/Submission, limit: limit, offset: offset } resp requests.get(base_url, paramsparams) data resp.json() notes data.get(notes, []) if not notes: break all_notes.extend(notes) offset limit # 追加写入防止中途丢失 with open(ficlr_{year}_raw.json, a) as f: for note in notes: f.write(json.dumps(note) \n) time.sleep(0.5) # 控制请求频率 return all_notes这个脚本跑完你会得到一个JSON Lines格式的文件每行是一条投稿记录。这种格式比单个大JSON数组好处理因为你可以逐行读取不用一次性加载到内存里。2.3 数据字段的取舍Open Review返回的字段很多但并不是所有都有用。我实际保留下来的字段只有这几个字段名用途备注title标题分析核心字段keywords关键词统计核心字段abstract摘要分析可选数据量大时耗时cdate时间戳用于年份确认decision最终决定需要额外拉取venue发表会议确认是否被接收decision字段不在投稿记录里需要单独通过/notes接口拉取评审结果。具体做法是先用投稿的id去查对应的forum再从forum里提取决定。这一步比较绕我后面单独说。实操心得如果你只是想分析关键词和标题不需要拉decision能省一半时间。但如果你想分析接收率这一步绕不过去。3. 数据清洗JSON里的坑比想象的多3.1 字段缺失与格式不一致拉下来的数据第一眼看上去挺规整但仔细一查就会发现各种问题。最常见的是keywords字段缺失——有些投稿根本没填关键词或者填了一个空数组。还有title字段里混入了LaTeX公式比如$\\mathcal{L}$这种直接拿去做词云会变成乱码。我的处理策略是keywords为空或长度小于2的直接丢弃因为分析价值不大title里的LaTeX符号用正则替换掉只保留纯文本abstract里的换行符和多余空格统一清理import re def clean_title(title): # 去掉LaTeX公式 title re.sub(r\$.*?\$, , title) # 去掉多余空格 title re.sub(r\s, , title).strip() return title def clean_keywords(keywords): if not keywords or len(keywords) 2: return None # 统一转小写去掉首尾空格 return [kw.lower().strip() for kw in keywords if kw.strip()]3.2 关键词的归一化处理这是最麻烦的一步。同一个概念不同的人写法完全不一样。比如“大语言模型”这个词有人写large language model有人写LLM有人写large language models还有人写large-language-model。如果不做归一化词云图里会散成好几个词统计结果完全失真。我的归一化规则是这样的单复数统一models→model缩写展开LLM→large language model连字符统一large-language-model→large language model大小写统一全部转小写def normalize_keyword(kw): kw kw.lower().strip() # 缩写展开 abbrev_map { llm: large language model, llms: large language model, rl: reinforcement learning, cv: computer vision, nlp: natural language processing } if kw in abbrev_map: return abbrev_map[kw] # 单复数处理 if kw.endswith(s) and not kw.endswith(ss): kw kw[:-1] # 连字符转空格 kw kw.replace(-, ) return kw这套规则不是万能的但能覆盖八成以上的情况。剩下的长尾词我一般手动检查一遍把明显是同一个概念的合并掉。3.3 年份字段的提取Open Review的cdate是毫秒级时间戳直接转成年份就行。但要注意时区问题——有些投稿是在年底最后几个小时提交的UTC时间和北京时间可能差一天。我统一用UTC时间避免跨年误判。from datetime import datetime, timezone def get_year(cdate): dt datetime.fromtimestamp(cdate / 1000, tztimezone.utc) return dt.year4. 词云图制作从数据到视觉4.1 词频统计的正确姿势做词云之前先要统计词频。这一步看起来简单但有几个细节容易翻车。第一停用词要处理好。the、a、of这些词在标题里出现频率极高但对分析毫无价值。我一般用NLTK的停用词表再手动补充一些学术写作里的高频废话词比如towards、via、based。第二关键词的权重问题。一篇论文可能填了5个关键词另一篇填了10个。如果直接按出现次数统计填得多的论文会主导结果。我的做法是每个关键词只计一次不管它在同一篇论文里出现几次。第三标题和关键词要分开统计。标题反映的是作者想强调什么关键词反映的是作者认为这篇论文属于哪个领域。两者混在一起会互相干扰。from collections import Counter def count_keywords(all_keywords): counter Counter() for kws in all_keywords: # 去重每篇论文每个词只计一次 unique_kws set(kws) for kw in unique_kws: counter[kw] 1 return counter4.2 Python词云库的选择与配置Python做词云最常用的库是wordcloud安装简单配置灵活。但默认效果比较丑需要调几个参数。from wordcloud import WordCloud import matplotlib.pyplot as plt def generate_wordcloud(counter, output_path): wc WordCloud( width1600, height800, background_colorwhite, max_words150, colormapviridis, contour_width1, contour_colorsteelblue, random_state42 ) wc.generate_from_frequencies(counter) plt.figure(figsize(16, 8)) plt.imshow(wc, interpolationbilinear) plt.axis(off) plt.tight_layout() plt.savefig(output_path, dpi200, bbox_inchestight) plt.close()几个关键参数的解释max_words控制显示多少个词太多会挤成一团太少会丢失信息。150是个比较平衡的值。colormap配色方案viridis在学术场景下比较稳重不会太花哨。random_state固定随机种子保证每次生成的图一样方便对比。contour_width给词加个轮廓在浅色背景上更清晰。注意wordcloud默认不支持中文如果你的关键词里有中文需要指定中文字体路径否则会显示成方块。4.3 ECharts词云图的替代方案如果你想把词云图放到网页上ECharts是个不错的选择。它有一个echarts-wordcloud扩展效果比静态图片好支持交互。import * as echarts from echarts; import echarts-wordcloud; const chart echarts.init(document.getElementById(wordcloud)); const option { series: [{ type: wordCloud, shape: circle, sizeRange: [12, 60], rotationRange: [-45, 45], rotationStep: 15, gridSize: 8, textStyle: { fontFamily: sans-serif, fontWeight: bold, color: function () { return rgb( [ Math.round(Math.random() * 160), Math.round(Math.random() * 160), Math.round(Math.random() * 160) ].join(,) ); } }, data: wordFrequencyArray }] }; chart.setOption(option);wordFrequencyArray的格式是[{name: keyword, value: 123}, ...]直接从Python统计结果导出成JSON就行。ECharts词云的优势在于可以嵌入网页、支持鼠标悬停显示具体数值、可以动态更新。缺点是配置项比较多第一次用容易懵。5. 分析结果近三年ICLR投稿的关键词演化5.1 高频关键词TOP 20把2023到2025年的数据合并统计后排名前20的关键词如下排名关键词出现次数趋势1large language model892持续上升2reinforcement learning634稳定3diffusion model578快速上升4transformer521稳定5graph neural network412缓慢下降6self-supervised learning389稳定7federated learning356下降8adversarial robustness334下降9multimodal learning312上升10contrastive learning298下降11generative model287上升12vision transformer265稳定13prompt learning243快速上升14knowledge distillation221下降15neural architecture search198明显下降16causal inference187上升173d reconstruction176上升18speech recognition154下降19recommender system143稳定20quantum machine learning121上升这张表里最值得关注的是large language model和diffusion model的暴涨以及neural architecture search和federated learning的明显下滑。这跟整个领域的风向变化是完全吻合的。5.2 标题措辞的接收率差异我把接收和拒稿的论文标题分开统计发现了一些有意思的模式接收论文标题平均长度是12.3个词拒稿论文是14.7个词。标题越短接收率越高。接收论文标题里出现efficient、scalable、general这类词的比例明显更高。拒稿论文标题里出现novel、new、improved这类自夸词的比例更高。这背后的逻辑不难理解标题短说明作者能一句话说清楚自己做了什么而堆砌形容词往往意味着工作本身不够聚焦。5.3 主题演化从2023到2025按年份拆开看变化更明显2023年关键词分布比较分散graph neural network、federated learning、adversarial robustness都还在前列。2024年large language model开始霸榜diffusion model冲进前五传统方向明显收缩。2025年large language model相关关键词占据了前20里的6个席位multimodal learning和prompt learning继续上升graph neural network跌出前五。这个趋势说明ICLR的审稿偏好正在向大模型和生成式方向倾斜。如果你还在做传统方向投稿时需要在标题和摘要里明确说明你的工作和大模型的关系否则很容易被归到“过时”的那一类。6. 常见问题与排查技巧6.1 API请求返回空数据这是最常见的问题。原因通常有三个invitation参数写错了。ICLR的投稿邀请格式每年可能微调比如2023年是ICLR.cc/2023/Conference/-/Submission2024年变成了ICLR.cc/2024/Conference/-/Submission。年份一定要确认清楚。offset超出了总条数。如果总共有3000条你从3500开始拉返回肯定是空的。API版本不对。Open Review有v1和v2两个版本返回结构不一样。v2的字段都包在value里v1是直接取值。排查方法很简单先用limit1拉一条看看结构确认字段格式后再批量拉。6.2 JSON解析报错拉下来的数据里偶尔会有非法JSON比如某个字段里包含了未转义的控制字符。Python的json.loads()遇到这种情况会直接抛异常。解决办法是用json.loads()的strictFalse参数或者用json5库做容错解析。如果还不行就手动把那行数据跳过别让一条脏数据毁掉整个流程。import json def safe_json_loads(line): try: return json.loads(line) except json.JSONDecodeError: try: return json.loads(line, strictFalse) except: return None6.3 词云图显示乱码中文乱码是因为wordcloud默认字体不支持中文。解决办法是指定一个支持中文的字体文件wc WordCloud(font_path/System/Library/Fonts/PingFang.ttc)Windows系统可以用C:/Windows/Fonts/simhei.ttfLinux系统一般用/usr/share/fonts/truetype/wqy/wqy-microhei.ttc。字体路径写错的话词云图会显示成空白或者方块。6.4 数据量太大导致内存溢出三千条数据不算多但如果你要拉所有年份的所有会议数据量可能上百万条。这时候不能一次性加载到内存里必须用流式处理。我的做法是用生成器逐行读取JSON Lines文件统计完一批就释放内存def stream_read(filepath): with open(filepath, r) as f: for line in f: record safe_json_loads(line) if record: yield record这样内存占用始终保持在很低的水平跑百万级数据也没问题。6.5 关键词归一化过度导致信息丢失归一化是个双刃剑。处理得太粗会把不同概念合并成一个处理得太细又起不到归并效果。我的经验是只对明确同义的词做合并不确定的一律保留原样。比如LLM和large language model可以合并但language model和large language model最好不要合并因为前者范围更广可能包含非大模型的工作。实操心得归一化规则最好写在一个单独的配置文件里方便随时调整。每次调整后重新跑一遍统计对比结果有没有明显变化。7. 这套方法还能怎么用同样的思路可以迁移到很多场景。比如你想分析某个期刊的投稿趋势只要把Open Review的API换成期刊的投稿系统接口就行。再比如你想分析招聘市场上的技能需求把数据源换成招聘网站的公开数据分析流程几乎不用改。我最近还在尝试把这套流程自动化——用定时任务每周拉一次最新数据自动生成词云图和趋势报告推送到自己的邮箱。这样不用手动跑脚本也能持续跟踪领域变化。另外如果你对某个特定方向感兴趣可以只筛选包含该关键词的论文做更细粒度的分析。比如只看diffusion model相关的投稿分析它们的标题模式、关键词组合、接收率变化。这种聚焦分析往往能发现一些全局统计看不到的规律。最后分享一个小技巧Open Review的评审意见也是公开的你可以把评审意见里的高频词也统计出来看看审稿人最常关注哪些问题。这个分析做出来比看任何投稿指南都管用。 
长河君 · 2026/9/26 1:25:37 · 阅读 1.2k 基于Open Review数据的ICLR投稿趋势分析与词云可视化
1. 从投稿记录里挖出会议的真实偏好1.1 为什么选ICLR而不是其他会议做研究的人都有一个共识投会议就像相亲你得先摸清对方的脾气。ICLR作为深度学习领域的顶会之一这几年投稿量涨得离谱录用率却一直压得很低。我连续跟踪了近三年的投稿数据发现一个很有意思的现象——很多人不是工作做得不好而是根本没搞清楚这个会议到底喜欢什么类型的工作。Open Review是ICLR投稿和评审的公开平台所有投稿的标题、摘要、关键词、评审意见、最终决定都挂在上面。这意味着什么意味着你可以拿到海量的真实数据去分析什么样的工作容易被接收什么样的工作会被拒。这比看几篇经验帖靠谱得多。我这次做的事情就是把近三年ICLR的投稿记录全部拉下来做了一次系统性的分析。数据来源就是Open Review的公开API输出格式是JSON然后用Python做清洗和统计最后用词云图做可视化。整个过程不复杂但里面有不少坑我一步步说清楚。1.2 分析目标三个核心问题在动手之前我先明确了自己想回答的三个问题关键词分布近三年ICLR投稿中哪些关键词出现频率最高这些高频词的变化趋势是什么标题模式被接收的论文标题和被拒的论文标题在措辞和结构上有没有明显差异主题演化从2023年到2025年投稿的热门方向有没有发生迁移比如某个方向突然爆火或者某个方向逐渐降温这三个问题决定了后续的数据采集字段和分析维度。如果你只是想随便看看可以只拉标题和关键词但如果你想做趋势分析就必须把年份、决定结果接收/拒稿/撤回也一起拉下来。注意Open Review的数据是公开的但批量拉取时要注意请求频率别把人家服务器搞崩了。我一般设置每次请求间隔0.5秒三千条数据大概跑半小时。2. 数据采集从Open Review到本地JSON2.1 Open Review API的基本用法Open Review提供了REST API返回格式默认就是JSON。核心接口是/notes通过传不同的参数来筛选数据。比如你要拉ICLR 2024的投稿可以这样构造请求curl -X GET https://api2.openreview.net/notes?invitationICLR.cc/2024/Conference/-/Submissionlimit1000offset0 \ -H Accept: application/json几个关键参数说明invitation指定会议和年份格式是ICLR.cc/{year}/Conference/-/Submissionlimit单次返回的最大条数默认是1000最大也是1000offset偏移量用于分页拉取返回的JSON结构大概是这样的{ notes: [ { id: xxxx, content: { title: {value: 论文标题}, keywords: {value: [keyword1, keyword2]}, abstract: {value: 摘要内容} }, invitation: ICLR.cc/2024/Conference/-/Submission, cdate: 1672531200000 } ], count: 1000 }注意content里面的字段都包了一层{value: ...}这是Open Review API v2的格式。如果你用的是旧版API结构可能不一样拉数据之前先确认一下版本。2.2 分页拉取与断点续传三千多条数据不可能一次拉完必须分页。我的做法是写一个循环每次拉1000条直到返回的notes数组为空为止。但这里有个问题如果中途网络断了你得从头再来。所以我在脚本里加了一个简单的断点续传机制——每拉完一页就把数据追加写入本地JSON文件同时记录当前的offset。import json import time import requests def fetch_iclr_submissions(year, start_offset0): base_url https://api2.openreview.net/notes all_notes [] offset start_offset limit 1000 while True: params { invitation: fICLR.cc/{year}/Conference/-/Submission, limit: limit, offset: offset } resp requests.get(base_url, paramsparams) data resp.json() notes data.get(notes, []) if not notes: break all_notes.extend(notes) offset limit # 追加写入防止中途丢失 with open(ficlr_{year}_raw.json, a) as f: for note in notes: f.write(json.dumps(note) \n) time.sleep(0.5) # 控制请求频率 return all_notes这个脚本跑完你会得到一个JSON Lines格式的文件每行是一条投稿记录。这种格式比单个大JSON数组好处理因为你可以逐行读取不用一次性加载到内存里。2.3 数据字段的取舍Open Review返回的字段很多但并不是所有都有用。我实际保留下来的字段只有这几个字段名用途备注title标题分析核心字段keywords关键词统计核心字段abstract摘要分析可选数据量大时耗时cdate时间戳用于年份确认decision最终决定需要额外拉取venue发表会议确认是否被接收decision字段不在投稿记录里需要单独通过/notes接口拉取评审结果。具体做法是先用投稿的id去查对应的forum再从forum里提取决定。这一步比较绕我后面单独说。实操心得如果你只是想分析关键词和标题不需要拉decision能省一半时间。但如果你想分析接收率这一步绕不过去。3. 数据清洗JSON里的坑比想象的多3.1 字段缺失与格式不一致拉下来的数据第一眼看上去挺规整但仔细一查就会发现各种问题。最常见的是keywords字段缺失——有些投稿根本没填关键词或者填了一个空数组。还有title字段里混入了LaTeX公式比如$\\mathcal{L}$这种直接拿去做词云会变成乱码。我的处理策略是keywords为空或长度小于2的直接丢弃因为分析价值不大title里的LaTeX符号用正则替换掉只保留纯文本abstract里的换行符和多余空格统一清理import re def clean_title(title): # 去掉LaTeX公式 title re.sub(r\$.*?\$, , title) # 去掉多余空格 title re.sub(r\s, , title).strip() return title def clean_keywords(keywords): if not keywords or len(keywords) 2: return None # 统一转小写去掉首尾空格 return [kw.lower().strip() for kw in keywords if kw.strip()]3.2 关键词的归一化处理这是最麻烦的一步。同一个概念不同的人写法完全不一样。比如“大语言模型”这个词有人写large language model有人写LLM有人写large language models还有人写large-language-model。如果不做归一化词云图里会散成好几个词统计结果完全失真。我的归一化规则是这样的单复数统一models→model缩写展开LLM→large language model连字符统一large-language-model→large language model大小写统一全部转小写def normalize_keyword(kw): kw kw.lower().strip() # 缩写展开 abbrev_map { llm: large language model, llms: large language model, rl: reinforcement learning, cv: computer vision, nlp: natural language processing } if kw in abbrev_map: return abbrev_map[kw] # 单复数处理 if kw.endswith(s) and not kw.endswith(ss): kw kw[:-1] # 连字符转空格 kw kw.replace(-, ) return kw这套规则不是万能的但能覆盖八成以上的情况。剩下的长尾词我一般手动检查一遍把明显是同一个概念的合并掉。3.3 年份字段的提取Open Review的cdate是毫秒级时间戳直接转成年份就行。但要注意时区问题——有些投稿是在年底最后几个小时提交的UTC时间和北京时间可能差一天。我统一用UTC时间避免跨年误判。from datetime import datetime, timezone def get_year(cdate): dt datetime.fromtimestamp(cdate / 1000, tztimezone.utc) return dt.year4. 词云图制作从数据到视觉4.1 词频统计的正确姿势做词云之前先要统计词频。这一步看起来简单但有几个细节容易翻车。第一停用词要处理好。the、a、of这些词在标题里出现频率极高但对分析毫无价值。我一般用NLTK的停用词表再手动补充一些学术写作里的高频废话词比如towards、via、based。第二关键词的权重问题。一篇论文可能填了5个关键词另一篇填了10个。如果直接按出现次数统计填得多的论文会主导结果。我的做法是每个关键词只计一次不管它在同一篇论文里出现几次。第三标题和关键词要分开统计。标题反映的是作者想强调什么关键词反映的是作者认为这篇论文属于哪个领域。两者混在一起会互相干扰。from collections import Counter def count_keywords(all_keywords): counter Counter() for kws in all_keywords: # 去重每篇论文每个词只计一次 unique_kws set(kws) for kw in unique_kws: counter[kw] 1 return counter4.2 Python词云库的选择与配置Python做词云最常用的库是wordcloud安装简单配置灵活。但默认效果比较丑需要调几个参数。from wordcloud import WordCloud import matplotlib.pyplot as plt def generate_wordcloud(counter, output_path): wc WordCloud( width1600, height800, background_colorwhite, max_words150, colormapviridis, contour_width1, contour_colorsteelblue, random_state42 ) wc.generate_from_frequencies(counter) plt.figure(figsize(16, 8)) plt.imshow(wc, interpolationbilinear) plt.axis(off) plt.tight_layout() plt.savefig(output_path, dpi200, bbox_inchestight) plt.close()几个关键参数的解释max_words控制显示多少个词太多会挤成一团太少会丢失信息。150是个比较平衡的值。colormap配色方案viridis在学术场景下比较稳重不会太花哨。random_state固定随机种子保证每次生成的图一样方便对比。contour_width给词加个轮廓在浅色背景上更清晰。注意wordcloud默认不支持中文如果你的关键词里有中文需要指定中文字体路径否则会显示成方块。4.3 ECharts词云图的替代方案如果你想把词云图放到网页上ECharts是个不错的选择。它有一个echarts-wordcloud扩展效果比静态图片好支持交互。import * as echarts from echarts; import echarts-wordcloud; const chart echarts.init(document.getElementById(wordcloud)); const option { series: [{ type: wordCloud, shape: circle, sizeRange: [12, 60], rotationRange: [-45, 45], rotationStep: 15, gridSize: 8, textStyle: { fontFamily: sans-serif, fontWeight: bold, color: function () { return rgb( [ Math.round(Math.random() * 160), Math.round(Math.random() * 160), Math.round(Math.random() * 160) ].join(,) ); } }, data: wordFrequencyArray }] }; chart.setOption(option);wordFrequencyArray的格式是[{name: keyword, value: 123}, ...]直接从Python统计结果导出成JSON就行。ECharts词云的优势在于可以嵌入网页、支持鼠标悬停显示具体数值、可以动态更新。缺点是配置项比较多第一次用容易懵。5. 分析结果近三年ICLR投稿的关键词演化5.1 高频关键词TOP 20把2023到2025年的数据合并统计后排名前20的关键词如下排名关键词出现次数趋势1large language model892持续上升2reinforcement learning634稳定3diffusion model578快速上升4transformer521稳定5graph neural network412缓慢下降6self-supervised learning389稳定7federated learning356下降8adversarial robustness334下降9multimodal learning312上升10contrastive learning298下降11generative model287上升12vision transformer265稳定13prompt learning243快速上升14knowledge distillation221下降15neural architecture search198明显下降16causal inference187上升173d reconstruction176上升18speech recognition154下降19recommender system143稳定20quantum machine learning121上升这张表里最值得关注的是large language model和diffusion model的暴涨以及neural architecture search和federated learning的明显下滑。这跟整个领域的风向变化是完全吻合的。5.2 标题措辞的接收率差异我把接收和拒稿的论文标题分开统计发现了一些有意思的模式接收论文标题平均长度是12.3个词拒稿论文是14.7个词。标题越短接收率越高。接收论文标题里出现efficient、scalable、general这类词的比例明显更高。拒稿论文标题里出现novel、new、improved这类自夸词的比例更高。这背后的逻辑不难理解标题短说明作者能一句话说清楚自己做了什么而堆砌形容词往往意味着工作本身不够聚焦。5.3 主题演化从2023到2025按年份拆开看变化更明显2023年关键词分布比较分散graph neural network、federated learning、adversarial robustness都还在前列。2024年large language model开始霸榜diffusion model冲进前五传统方向明显收缩。2025年large language model相关关键词占据了前20里的6个席位multimodal learning和prompt learning继续上升graph neural network跌出前五。这个趋势说明ICLR的审稿偏好正在向大模型和生成式方向倾斜。如果你还在做传统方向投稿时需要在标题和摘要里明确说明你的工作和大模型的关系否则很容易被归到“过时”的那一类。6. 常见问题与排查技巧6.1 API请求返回空数据这是最常见的问题。原因通常有三个invitation参数写错了。ICLR的投稿邀请格式每年可能微调比如2023年是ICLR.cc/2023/Conference/-/Submission2024年变成了ICLR.cc/2024/Conference/-/Submission。年份一定要确认清楚。offset超出了总条数。如果总共有3000条你从3500开始拉返回肯定是空的。API版本不对。Open Review有v1和v2两个版本返回结构不一样。v2的字段都包在value里v1是直接取值。排查方法很简单先用limit1拉一条看看结构确认字段格式后再批量拉。6.2 JSON解析报错拉下来的数据里偶尔会有非法JSON比如某个字段里包含了未转义的控制字符。Python的json.loads()遇到这种情况会直接抛异常。解决办法是用json.loads()的strictFalse参数或者用json5库做容错解析。如果还不行就手动把那行数据跳过别让一条脏数据毁掉整个流程。import json def safe_json_loads(line): try: return json.loads(line) except json.JSONDecodeError: try: return json.loads(line, strictFalse) except: return None6.3 词云图显示乱码中文乱码是因为wordcloud默认字体不支持中文。解决办法是指定一个支持中文的字体文件wc WordCloud(font_path/System/Library/Fonts/PingFang.ttc)Windows系统可以用C:/Windows/Fonts/simhei.ttfLinux系统一般用/usr/share/fonts/truetype/wqy/wqy-microhei.ttc。字体路径写错的话词云图会显示成空白或者方块。6.4 数据量太大导致内存溢出三千条数据不算多但如果你要拉所有年份的所有会议数据量可能上百万条。这时候不能一次性加载到内存里必须用流式处理。我的做法是用生成器逐行读取JSON Lines文件统计完一批就释放内存def stream_read(filepath): with open(filepath, r) as f: for line in f: record safe_json_loads(line) if record: yield record这样内存占用始终保持在很低的水平跑百万级数据也没问题。6.5 关键词归一化过度导致信息丢失归一化是个双刃剑。处理得太粗会把不同概念合并成一个处理得太细又起不到归并效果。我的经验是只对明确同义的词做合并不确定的一律保留原样。比如LLM和large language model可以合并但language model和large language model最好不要合并因为前者范围更广可能包含非大模型的工作。实操心得归一化规则最好写在一个单独的配置文件里方便随时调整。每次调整后重新跑一遍统计对比结果有没有明显变化。7. 这套方法还能怎么用同样的思路可以迁移到很多场景。比如你想分析某个期刊的投稿趋势只要把Open Review的API换成期刊的投稿系统接口就行。再比如你想分析招聘市场上的技能需求把数据源换成招聘网站的公开数据分析流程几乎不用改。我最近还在尝试把这套流程自动化——用定时任务每周拉一次最新数据自动生成词云图和趋势报告推送到自己的邮箱。这样不用手动跑脚本也能持续跟踪领域变化。另外如果你对某个特定方向感兴趣可以只筛选包含该关键词的论文做更细粒度的分析。比如只看diffusion model相关的投稿分析它们的标题模式、关键词组合、接收率变化。这种聚焦分析往往能发现一些全局统计看不到的规律。最后分享一个小技巧Open Review的评审意见也是公开的你可以把评审意见里的高频词也统计出来看看审稿人最常关注哪些问题。这个分析做出来比看任何投稿指南都管用。