我觉得这个 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。