欣 郁 (@user1164) 在 令人失望,deepseek-R1.1的学术文本处理能力远不如【长上下文负载下】的gemini-2.5pro 中发帖
我自己开发了一个MCP学术工具,用以撰写医学类综述。其逻辑具体是
在pubmed检索关键词后,获得文献信息,并下载原文pdf(若无OA或sci-hub,用摘要替代原文)
将原文pdf转化为markdown,并分割为文本块,写入本地向量数据库
基于文献摘要构建综述框架
基于综述框架,使用RAG的方式检索文本块,用来填充综述内容
举例,我的综述框架如图:
[综述框架]
执行第四步时,我有两个策略:
策略一(gemini一气呵成):用LLM以综述框架的一级标题为分割,逐个检索综述框架片段,形成综述片段,最后再拼成完整的综述。
策略一中,综述框架片段检索后返还的文本块的token大概6k-7k,综述片段大概2k-4k,相当于每个综述片段的撰写都需要6k-7k的input和2k-3k的output,并且所有综述片段的撰写都在同一个聊天窗口,这对LLM的上下文负载压力极大(例如在写第六...