📌 📄 内容摘要:
欣 郁 (@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的上下文负载压力极大（例如在写第六...
────────── 链接信息 ──────────
🔗 论坛链接: linux.do
📎 访问地址: https://linux.do/t/topic/689522/1
─────────────────────────────
📢 来源：LINUX DO
