| 我觉得这个 proposal 已经明显超过“大作业应付水平”了，已经很接近一个正式的 workshop / course project proposal 了。整体上： | |
| * 结构完整 | |
| * 技术路线合理 | |
| * 风险控制清晰 | |
| * baseline 和 ablation 都考虑到了 | |
| * 对 recommendation + heterogeneous graph 的理解是在线的 | |
| 尤其你们没有只写“我们用 GNN 做推荐”，而是真的把： | |
| * hetero graph | |
| * cold start | |
| * negative sampling | |
| * threshold tuning | |
| * feature initialization | |
| * baseline comparison | |
| 这些关键问题都考虑进去了，这点很好。 | |
| 但如果站在： | |
| # “老师 / reviewer / TA” | |
| 的视角，我会给你几个建议，能明显再提升一个档次。 | |
| --- | |
| # 一、最大的优点：你们的“问题定义”是清楚的 | |
| 很多 proposal 最大的问题是： | |
| > “我要用 GNN 做推荐” | |
| 但根本没说清： | |
| * 图怎么建 | |
| * 节点是什么 | |
| * 边是什么 | |
| * label 是什么 | |
| * prediction target 是什么 | |
| 而你们这里： | |
| ```text | |
| author-paper link prediction | |
| ``` | |
| 定义得非常清晰。 | |
| 这一段尤其好： | |
| > 该任务可以建模为异构图上的链接预测问题 | |
| 这说明你们不是把它当普通分类。 | |
| 这是 reviewer 很喜欢的。 | |
| --- | |
| # 二、你们对“冷启动”的讨论是加分项 | |
| 这里： | |
| > 利用合作者关系和论文引用网络补充信息 | |
| 是非常合理的。 | |
| 因为： | |
| 这正是： | |
| # GNN 在推荐中的核心价值 | |
| 不是： | |
| “我用了更高级模型” | |
| 而是： | |
| # 图结构能传播稀疏节点的信息 | |
| 你们 actually 抓住了这个点。 | |
| --- | |
| # 三、Research Plan 写得不错，但还可以更“科研化” | |
| 目前的问题是： | |
| 有一点： | |
| # “工程流水账” | |
| 比如： | |
| ```text | |
| 第一阶段 | |
| 第二阶段 | |
| 第三阶段 | |
| ``` | |
| 虽然清晰，但略像开发计划。 | |
| 你们可以适当加入： | |
| # “研究问题（Research Questions）” | |
| 例如： | |
| --- | |
| ## RQ1 | |
| 不同边类型对推荐性能的贡献如何？ | |
| 例如： | |
| * 去掉 author-author | |
| * 去掉 paper-paper | |
| 看 F1 变化。 | |
| --- | |
| ## RQ2 | |
| 作者初始化方式是否影响冷启动作者性能？ | |
| 比较： | |
| * trainable embedding | |
| * average cited paper embedding | |
| * collaborator-enhanced embedding | |
| --- | |
| ## RQ3 | |
| hard negative sampling 是否比 random negative 更有效？ | |
| --- | |
| 这样会： | |
| # 非常像正式 paper | |
| 而不是课程报告。 | |
| --- | |
| # 四、目前最弱的一部分：baseline 还不够强 | |
| 你们现在写： | |
| > popularity baseline | |
| 这个太弱了。 | |
| 建议至少加： | |
| --- | |
| # 1. Matrix Factorization | |
| 比如： | |
| * BPR | |
| * implicit MF | |
| 因为： | |
| 推荐系统里 reviewer 默认会问： | |
| > “为什么不用传统 CF？” | |
| --- | |
| # 2. Node2Vec / DeepWalk | |
| 因为： | |
| 这是： | |
| # 非 GNN graph embedding baseline | |
| 非常合理。 | |
| --- | |
| # 3. Common Neighbor / Adamic-Adar | |
| 尤其是： | |
| author-paper 二部图里。 | |
| 传统 link prediction baseline 很适合写进去。 | |
| --- | |
| 这样你们会形成： | |
| # 三层 baseline | |
| --- | |
| ## Level 1 | |
| Heuristic： | |
| * popularity | |
| * common neighbor | |
| --- | |
| ## Level 2 | |
| Traditional： | |
| * MF | |
| * Node2Vec | |
| --- | |
| ## Level 3 | |
| GNN： | |
| * LightGCN | |
| * HeteroGNN | |
| 这样整个实验会非常完整。 | |
| --- | |
| # 五、负采样部分写得很好 | |
| 这是很多组根本不会考虑的。 | |
| 尤其： | |
| > hard negative | |
| 这点很好。 | |
| 因为 recommendation 的关键不是： | |
| “随机负样本” | |
| 而是： | |
| # 区分容易混淆的论文 | |
| 例如： | |
| * 同领域 | |
| * 同引用社区 | |
| * 同作者群体 | |
| 这些 negative 更有价值。 | |
| --- | |
| # 六、这里有一个潜在风险：label leakage | |
| 你们现在： | |
| ```text | |
| paper-paper citation | |
| ``` | |
| 需要注意： | |
| # 测试集论文是否出现在训练 citation graph 中 | |
| 否则可能： | |
| 未来信息泄漏。 | |
| 建议在 proposal 里加一句： | |
| --- | |
| > We will carefully avoid potential information leakage between training edges and recommendation targets when constructing the heterogeneous graph. | |
| --- | |
| 会显得很专业。 | |
| --- | |
| # 七、feature.pkl 那里还可以写得更具体 | |
| 现在： | |
| ```text | |
| 论文节点的初始特征来自官方提供的 feature.pkl | |
| ``` | |
| 有点太模糊。 | |
| 建议补一句： | |
| --- | |
| 例如： | |
| ```text | |
| The provided paper features are expected to encode semantic or structural information of papers, which may help the GNN better distinguish topic similarity beyond pure graph topology. | |
| ``` | |
| 否则 reviewer 会觉得： | |
| 你们没想清 feature 是干嘛的。 | |
| --- | |
| # 八、你们目前最合理的主模型其实是： | |
| # LightGCN + Heterogeneous Edges | |
| 原因： | |
| --- | |
| ## 优点 1：推荐系统适配性极强 | |
| LightGCN 本来就是： | |
| # recommendation 专用 GNN | |
| --- | |
| ## 优点 2：不会过拟合 | |
| 异构 Transformer 很容易： | |
| * 参数爆炸 | |
| * 训练不稳 | |
| * 小数据过拟合 | |
| 你们这个数据： | |
| ```text | |
| 6k authors | |
| 80k papers | |
| ``` | |
| 其实不算特别大。 | |
| LightGCN 可能比 HGT 更稳。 | |
| --- | |
| ## 优点 3：老师会更认可 | |
| 因为： | |
| 你们不是： | |
| “盲目堆复杂模型” | |
| 而是： | |
| # 根据任务特点选模型 | |
| 这是加分项。 | |
| --- | |
| # 九、proposal 里缺少“evaluation protocol” | |
| 建议补： | |
| --- | |
| # Validation Split | |
| 例如： | |
| ```text | |
| We will randomly split a portion of training author-paper edges as validation positives and construct corresponding negative pairs for evaluation. | |
| ``` | |
| --- | |
| # Metrics | |
| 除了 F1： | |
| 建议再写： | |
| * Precision | |
| * Recall | |
| * ROC-AUC | |
| 因为： | |
| F1 对 threshold 很敏感。 | |
| --- | |
| # 十、一个很值得加入的点：Meta-path | |
| 你们现在其实已经 implicitly 用到了。 | |
| 但如果明确写： | |
| --- | |
| 例如： | |
| ```text | |
| Author → Author → Paper | |
| Author → Paper → Paper | |
| ``` | |
| 可能能加不少分。 | |
| 因为： | |
| heterogeneous graph recommendation 里： | |
| # meta-path 是经典关键词 | |
| --- | |
| # 十一、如果我是 reviewer，我会给的评价 | |
| 大概会是： | |
| --- | |
| ## 优点 | |
| * 问题定义清晰 | |
| * 技术路线合理 | |
| * baseline 和 ablation 意识较强 | |
| * 对 hetero graph 和 recommendation 有理解 | |
| * 考虑了冷启动与 hard negative | |
| --- | |
| ## 缺点 | |
| * baseline 还可以更完整 | |
| * research question 不够明确 | |
| * feature 使用略模糊 | |
| * evaluation protocol 可以更细 | |
| --- | |
| # 十二、我最建议你们加的一句话 | |
| 这一句会让 proposal 瞬间更像 paper： | |
| > We are particularly interested in understanding how heterogeneous relational structures (co-authorship and citation networks) contribute to recommendation performance under sparse interaction settings. | |
| 因为： | |
| 它把： | |
| * hetero graph | |
| * cold start | |
| * recommendation | |
| 三个核心点串起来了。 | |
| 非常像正式 research proposal。 | |