Paper2Poster
将学术论文 PDF 自动生成可编辑 PPTX 学术海报的多智能体流程。
- Star 数
- ★ 3.9k
- 最近更新
- 3 个月前
- License
- MIT
- 主语言
- Python
- FA 评分
- 28/100 · 缺口较多
30 秒速览
- 可在哪里用
- 兼容但需适配Codex · OpenAI API
- 开始前需要
- 典型场景
- 研究人员在投稿会议前,已拥有 paper.pdf,想生成可继续在 PowerPoint 中修改的 48×36 英寸学术海报。
- 主要局限
- 完整本地运行需要 Python、LibreOffice 和 poppler;开源模型路线还需要自行部署 vLLM 并配置端口。
这个 Agent 能做什么,适合哪些场景?
Paper2Poster 是面向科学论文的多模态海报自动化项目,核心系统名为 PosterAgent。它以 paper.pdf 为输入,通过自上而下、视觉反馈参与的多智能体流程生成可编辑的 poster.pptx。README 将流程描述为 Parser、Planner 和 Painter-Commentor:前者整理论文资产,中间步骤安排文本与视觉内容,后者结合渲染代码和 VLM 反馈改进面板。项目既可使用 GPT-4o 等 API 模型,也支持经 vLLM 部署的开源模型组合,并提供 Docker、Gradio 演示、YAML 样式配置和标志自动添加说明。它还包含 PaperQuiz、VLM-as-Judge 及统计指标的评估入口。
用户将论文保存为 {dataset_dir}/{paper_name}/paper.pdf,再运行 python -m PosterAgent.new_pipeline。该命令接收 --poster_path、文本模型 --model_name_t、视觉模型 --model_name_v 和海报尺寸参数,并输出 poster.pptx;README 示例使用 48×36 英寸尺寸。流程可在每节内容生成时通过 --max_workers 并行执行。可选的 --conference_venue 会先在 logo_store/institutes/ 与 logo_store/conferences/ 查找标志,未找到时可进行 DuckDuckGo 搜索,或在配置 Google Custom Search 凭据后使用 --use_google_search;也可指定 --institution_logo_path 和 --conference_logo_path。样式可由全局 config/poster.yaml 或与 paper.pdf 同目录的 poster.yaml 覆盖。评估通过 python -m Paper2Poster-eval.eval_poster_pipeline 运行 qa、judge 或 stats 指标。
- 研究人员在投稿会议前,已拥有 paper.pdf,想生成可继续在 PowerPoint 中修改的 48×36 英寸学术海报。
- 实验室需要批量处理多篇论文,并希望通过 --max_workers 并行生成各节海报内容以缩短等待时间。
- 具备 vLLM 部署环境的团队希望用 Qwen-2.5-7B-Instruct 作为文本模型,配合 GPT-4o 或本地视觉模型生成海报。
- 会议参展者需要在生成时加入 NeurIPS 等会议标志,或用本地机构和会议图标替代自动搜索结果。
- 评测人员希望在 Paper2Poster-data 数据集上,用 PaperQuiz、VLM-as-Judge 或统计指标比较不同生成方法的海报。
如何安装或部署这个 Agent?
安装 Python 依赖:
pip install -r requirements.txt安装 LibreOffice:
sudo apt install libreoffice安装 poppler:
conda install -c conda-forge poppler在项目根目录创建 .env,并设置:
OPENAI_API_KEY=<your_openai_api_key>若要用 Google Custom Search 查找标志,还需设置 GOOGLE_SEARCH_API_KEY 和 GOOGLE_SEARCH_ENGINE_ID。使用开源模型前,需要先通过 vLLM 部署模型,并在 utils/wei_utils.py 的 get_agent_config() 中确认端口配置。
如何使用这个 Agent?
建立 {dataset_dir}/{paper_name}/paper.pdf 后,使用 GPT-4o 的示例命令为:
python -m PosterAgent.new_pipeline \
--poster_path="${dataset_dir}/${paper_name}/paper.pdf" \
--model_name_t="4o" \
--model_name_v="4o" \
--poster_width_inches=48 \
--poster_height_inches=36输出海报为 poster.pptx。若使用 Docker,可先执行 docker build -t paper2poster .,然后按 README 的 docker run 示例挂载 Paper2Poster-data 与输出目录,并传入 OPENAI_API_KEY。仅需为论文准备海报内容时,项目还提供 skills/ 中的轻量技能;README 给出的 Codex 调用语句是:Use $paper2poster-poster to turn this paper into a poster package。
这个 Agent 有哪些优点和局限?
- 最终产物是可编辑的 PPTX,而非仅供查看的位图或 PDF 海报。
- 流程明确结合论文解析、版面规划、渲染与 VLM 反馈,目标包括减少溢出并确保对齐。
- 文本模型与视觉模型可灵活组合,README 给出了 GPT-4o、vLLM Qwen 与本地视觉模型的运行配置。
- 支持 YAML 全局与逐论文样式覆盖,并可自动或手动添加机构和会议标志。
- 内置从数据集下载到 qa、judge、stats 三类评估命令的评估路径。
- 完整本地运行需要 Python、LibreOffice 和 poppler;开源模型路线还需要自行部署 vLLM 并配置端口。
- GPT-4o 配置依赖 OPENAI_API_KEY;README 未提供 API 用量、成本或模型服务可用性的保证。
- 自动标志搜索在本地库未命中时需要网络访问;更可靠的 Google 搜索还需要额外凭据。
- 文档只明确展示 PDF 输入与 PPTX 输出,未说明对扫描质量差、加密或非标准论文 PDF 的处理边界。
- README 提供命令行、Docker 和 Gradio 支持说明,但未给出稳定库 API 或外部服务协议。
这个 Agent 与同类方案有什么区别?
README 给出三种运行取舍:GPT-4o 文本模型加 GPT-4o 视觉模型被标为“High Performance”;vLLM Qwen-2.5-7B-Instruct 加 GPT-4o 被标为“Economic”;文本与视觉均使用本地 vLLM Qwen 的配置适合本地运行。后两种都要求先部署相应的 vLLM 服务。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|
| Paper2Poster 当前 | 28 · 缺口较多 | ★ 3.9k | 3 个月前 | Python | Codex · OpenAI API |
| 图片转可编辑PPT技能 | 53 · 缺口较多 | ★ 2.7k | 8 天前 | Python | Codex |
| The Delegation | 34 · 缺口较多 | ★ 660 | 5 个月前 | TypeScript | — |
| ArcReel 视频创作工作台 | 52 · 缺口较多 | ★ 5.1k | 今天 | Python | OpenAI API · Claude API |
FollowAgents 如何评估这个 Agent?
查看各维度的扣分理由
证据显示:仓库未提供权限最小化、用户确认、数据流透明、敏感数据处理、依赖安全、外部影响、回滚或来源归属的明确机制。README 要求用户提供 OPENAI_API_KEY 等敏感信息,但未说明其使用范围或保护措施。依赖列表庞大且未提供安全审计。因此所有信任标准均得 0 分。
证据显示:README 中的命令与 requirements.txt 中的依赖基本一致,但存在不一致,如 README 提到 `--no_blank_detection` 选项,但未在代码中验证。依赖列表包含大量包,但未提供版本兼容性说明。未提供错误处理或失败消息的文档。因此自洽性得 1 分,依赖可用性得 1 分,失败消息得 0 分。
证据显示:README 描述了多种使用场景(本地、API、Docker、Gradio),并提供了不同模型组合的示例,因此受众和场景得 2 分。能力边界未明确说明,但提供了 YAML 定制和 logo 搜索等选项,因此得 1 分。触发精度方面,提供了命令行参数,但未说明参数的具体行为,因此得 1 分。环境适配方面,提供了 Docker 和本地安装说明,但未说明系统要求,因此得 1 分。
证据显示:README 提供了清晰的目录结构和安装说明,因此信息架构和安装说明得 2 分。命名稳定性方面,项目名称和模块名称一致,但未提供版本历史,因此得 1 分。提供了示例和常见问题(如 Docker 权限问题),因此得 2 分。未提及已知限制,因此得 0 分。许可证为 MIT,得 2 分。版本更新记录在 README 中有更新日志,但未提供正式 changelog,因此得 1 分。维护责任未明确,但提供了联系方式,因此得 1 分。
证据显示:输出为可编辑的 PPTX 文件,具有实用性,因此输出可用性得 2 分。边际价值方面,自动生成海报节省时间,但未提供与其他工具的比较,因此得 2 分。成本效益方面,需要 API 密钥和计算资源,但未提供成本估算,因此得 1 分。
证据显示:README 引用了 arXiv 论文和项目页面,但未提供具体证据链接,因此声明可追溯性得 1 分。跨来源验证方面,提供了 Hugging Face 数据集和演示,但未提供独立验证,因此得 1 分。事实与推断分离方面,未明确区分,因此得 0 分。
- 源码中未见:最小权限约束只授予完成任务所需的权限:用专用账号或只读令牌,并限定可访问的目录和仓库。
- 源码中未见:执行前用户确认开启或自行加上执行前确认;先在沙箱或测试环境跑通,确认行为后再接入真实数据。
- 源码中未见:数据流向说明运行时观察它连接了哪些外部服务(代理或防火墙日志);弄清数据去向之前不要输入敏感数据。
- 源码中未见:敏感信息处理使用专用、低权限、可随时吊销的 API 密钥,不要复用生产凭据,也不要让密钥出现在日志里。
- 源码中未见:依赖安全审查安装前固定版本并做一次依赖扫描(如 npm audit、pip-audit);优先放在容器里运行。
- 源码中未见:外部影响披露先弄清它会写入、发送或修改哪些外部系统,用测试账号或测试仓库验证后再接入正式环境。
- 源码中未见:回滚或恢复路径运行前先备份,或在 git 分支、快照上操作,确保改动可以撤销。
- 源码中未见:来源归属可核验从官方仓库或包源安装,核对发布者和仓库地址,避免同名仿冒包。
- 依赖列表庞大且未提供安全审计,可能存在供应链风险。
- README 要求用户提供 API 密钥,但未说明其使用范围和保护措施,存在敏感信息泄露风险。
- 未提供已知限制和故障排除指南,用户可能遇到问题无法解决。