1.1 科学文献问答的任务边界与典型应用场景
我自己在实验室里带过几届学生，每次新人进来都要花两三周时间读文献。读得慢倒也罢了，麻烦的是读完记不住，记了又对不上。后来我们开始尝试用各种问答模型来辅助文献阅读，才发现“科学文献问答”这件事比想象中复杂。它并不是把论文丢给模型、问一句“这篇讲了什么”就完事了。科学文献问答有它自己的边界：问题通常带有专业术语、需要跨段落甚至跨文献整合信息、答案必须能追溯到原文的具体位置。普通的开放域问答可以容忍模糊回答，科学场景下不行，一个数值错了、一个实验条件漏了，结论可能就反了。
从应用场景看，我把它粗分成四类。一类是单篇精读辅助，用户刚拿到一篇论文，想快速定位方法细节、实验结果或者局限性讨论。一类是多篇综述梳理，给定一个主题，让模型从若干篇文献里抽取共识与分歧。还有一类是事实核查型问答，比如确认某个化合物在特定条件下的产率，答案必须精确到表格或图注。最后一类是科研流程嵌入，把问答能力接到文献管理工具、实验记录系统里，做持续的上下文提醒。这四类场景对模型能力的要求差别很大，混在一起谈“哪个模型更好”没有意义。
我在实际使用中吃过一个亏。早期我拿通用聊天模型去回答“这篇论文的消融实验说明了什么组件最关键”，模型答得头头是道，但我回头核对原文，发现它把两个消融组搞混了。那次之后我意识到，科学文献问答的第一道门槛不是语言流畅度，而是答案的可验证性。场景不同，可验证性的标准也不同。单篇精读可以容忍一定的概括，事实核查型问答则必须逐字对齐原文。
1.2 模型对比的核心问题：能力维度、数据依赖与评价口径
做模型对比，最怕的就是拿一把尺子量所有东西。我见过不少对比文章，列一张大表，把各个模型在几个公开数据集上的分数一放，就下结论说谁强谁弱。这种对比参考价值有限。科学文献问答的能力至少可以拆成几个维度：术语理解、跨段落推理、数值与单位处理、引用定位、对不确定性的表达。一个模型可能在术语理解上很强，但一遇到多跳推理就露怯。另一个模型答案准确率不错，可它从不告诉你答案来自哪一段，用起来心里没底。
数据依赖是第二层问题。科学文献问答的评测数据来源五花八门，有的是从开放获取论文里构造的抽取式问答，有的是专家手工写的生成式问答，还有的是基于引文网络的多跳问答。不同数据集的分布差异极大。我做过一个小实验，同一个模型在两个看似相似的数据集上，排名能差出三四位。这背后是数据集本身的领域偏向、问题难度分布、答案长度分布都不一样。脱离数据来源谈模型分数，基本等于耍流氓。
评价口径的问题更隐蔽。答案准确性怎么算？是字符串匹配、语义相似度，还是让专家打分？事实一致性谁来判定？引用可追溯性是看模型有没有给出引用标记，还是看引用是否真的支撑了那句话？这些口径不统一，对比结果就没法横向比较。我个人更倾向于分层评价：先看答案对不对，再看依据是否可查，最后看表达是否对科研人员友好。三层都过了，才算真正可用。这个思路会贯穿后面整篇文章的对比框架。
1.3 对比对象分类：通用大模型、科学领域模型、检索增强方案与工具链
我把对比对象分成四类，这样讨论起来不至于一锅粥。第一类是通用大模型，像GPT系列、Claude、通义千问这些。它们的优势是语言能力强、覆盖面广，缺点是科学文献的领域知识不够扎实，容易一本正经地编造细节。我拿它们做过文献速读，体验是“读得快、错得也快”，适合做初筛，不适合做定论。
第二类是科学领域模型，比如在生物医学、材料科学语料上继续预训练或微调的模型。这类模型对领域术语和常见实验范式更熟悉，回答的专业味更浓。问题是领域覆盖面窄，换个学科可能就不灵了，而且不少领域模型的更新节奏慢，跟不上最新文献。我试过用某个生物医学模型去问材料学的问题，回答质量断崖式下降，这提醒我领域模型不能跨领域盲目套用。
第三类是检索增强方案，也就是RAG。它的思路很对我胃口：不指望模型记住所有文献，而是先把相关段落检索出来，再让模型基于这些段落回答。这样做的好处是引用可追溯、知识可更新。难点在于检索质量，检索错了，后面全错。我踩过的最大的坑是分块策略没调好，把一张关键表格切成了碎片，模型拿到的上下文残缺不全，答案自然离谱。
第四类是工具链，包括文档解析、向量检索、编排框架和引用管理。这一类容易被忽视，但实际落地时它的权重可能比模型本身还大。一篇PDF论文里的公式、表格、图注，解析得好不好直接决定问答质量。我现在的看法是，模型决定上限，工具链决定下限。下限守不住，上限再高也用不上。
1.4 文章对比方法论与结构说明
写这篇文章，我不想做成一份冷冰冰的排行榜。我的方法是按问题组织对比，而不是按模型罗列参数。每个对比维度先讲清楚问题是什么、为什么重要，再摆出不同方案的表现和我的实际观察。数据来源会尽量标注清楚，包括数据集名称、评测设置和已知局限。能复现的我会给出复现要点，不能复现的我会说明原因。
整篇文章的结构大致是这样：先讲评测基准和指标体系，把“怎么量”这件事说透；再进入模型和开源工具的具体对比，分模型层和工具层两条线；最后落到选型建议和趋势判断。我会尽量用第一人称讲自己的使用体验，也会引用一些公开评测结果做交叉印证。需要提前说明的是，我的经验主要集中在计算机科学和生物医学两个领域，其他学科的读者读的时候可以打个折扣，但对比框架本身应该是通用的。
另外我想强调一点：这篇文章不追求给出“唯一正确答案”。科学文献问答这个领域变化太快，今天的第一名下个月可能就被超了。更有价值的是一套可复用的对比思路——知道该看哪些维度、该避开哪些坑、该怎样设计自己的小规模评测。这套思路比任何一个具体结论都活得久。接下来的章节会围绕这个目标展开，先从评测基准讲起，因为不把尺子校准，后面的对比都是空谈。
2.1 科学文献问答模型评测基准的构建逻辑与代表数据集
我经常跟学生说一句话：评测基准不是天上掉下来的，它是被人“设计”出来的。设计者的取舍直接决定了这个基准在测什么、没测什么。拿科学文献问答来说，构建基准的第一步是确定文献来源。有的团队从PubMed Central开放获取全文里抽片段，有的用arXiv预印本，还有的专门挑高引论文构造金标准。来源不同，语言风格、排版复杂度、术语密度全不一样。我见过一个基准专门只收生物医学的随机对照试验论文，它能测出模型在结构化摘要上的表现，可你拿它去评估材料学问答就明显跑偏了。
代表性的数据集我实际用过的有这么几个。QASPER是我用得最多的一个，它基于NLP领域的论文，问题由研究者对着全文提出，答案标注了证据段落。这个数据集的好处是问题类型比较丰富，有抽取式的也有概括性的。缺点是领域集中在计算语言学，模型在它上面表现好不代表在化学、物理上也行。SciQ更偏科普性质，问题相对简单，适合做入门级测试，拿它当科学文献问答的严肃评测就有点不够看。PubMedQA在生物医学圈子里很常见，它的特点是给一段摘要让模型判断是/否/可能，形式偏向推理判断而不是完整回答。我拿它测过几个模型，发现区分度主要在事实判断上，对长文综合能力的考察偏弱。
还有一个我最近在试的是LitQA2，问题是从文献里挖出来的、需要跨段落甚至跨图表的细节。它的难度明显高一个台阶，很多通用模型在上面答非所问。我觉得这个数据集更接近真实科研人员的使用场景，就是带着一个具体问题去翻文献找那个精确的数值或者条件。不过它的规模还不算大，做统计检验的时候样本量有点吃紧。构建逻辑上我觉得有一条容易被忽略：好的科学文献问答基准应该标注“不可回答”的问题。真实场景里用户问的东西未必在文献里有答案，模型能不能说“这篇里没找到”比它硬编一个答案出来重要得多。我目前看到的多数基准在这方面覆盖不足，这导致模型在评测里看起来很强，一上线就开始胡说。
2.2 抽取式、生成式与多跳问答的评测设计差异
这三类问答的评测设计，我踩过的坑可以写一整页。抽取式问答的评测相对“老实”，答案就是原文里的一个span，评价用精确匹配和F1就够了。我在早期项目里特别喜欢用抽取式任务来筛模型，因为结果干净、复现容易。问题在于真实科研场景里很少有人只要一个span。用户问“这个方法的局限性是什么”，答案往往分散在讨论部分的好几句话里，抽取式框架装不下这种需求。拿抽取式分数去推断模型的生成式问答能力，我吃过亏，有一个模型抽取F1很高，让它组织一段完整的局限性说明，它就开始拼贴原文碎片，读起来像机翻。
生成式问答的评测设计复杂得多。答案不固定，同一句话可以有多种正确表达，字符串匹配基本废掉。我目前的处理方式是“语义匹配+要点覆盖+人工抽检”三层。语义匹配用嵌入模型算相似度，要点覆盖靠预先标注的关键信息点清单，人工抽检用来抓那些语义相似但事实错误的回答。这个组合不完美，成本也不低，但它比单一指标靠谱。我记得有一次自动指标给了很高分，人工一看，模型把“显著提升”写成了“略有提升”，语义相似度没掉多少，科研含义完全变了。
多跳问答是这三类里最难评的。它要求模型从文献A拿到线索、再去文献B找证据、最后整合出答案。评测设计上要标注清楚每一跳的证据位置，还要区分“跳对了但整合错了”和“压根没跳到正确文献”。我试过用统一指标去评多跳任务，结果完全没法定位模型到底卡在哪一步。后来我改成分步打分：检索命中率、中间推理正确率、最终答案正确率分开算。这样虽然工作量大，但能看出模型是检索弱还是推理弱。多跳问答的另一个坑是答案可能依赖文献之间的引用关系，而引用关系本身有噪音，有些论文引用了一篇文献但并没有真正使用它的结论。评测基准如果直接拿引用关系当金标准，会把模型的正确行为判成错误。这个问题我在两个数据集上都遇到过，目前没有特别好的解法，只能人工审核一部分样本来估计噪音比例。
2.3 核心评价指标：答案准确性、事实一致性、引用可追溯性与专家评审
答案准确性是最直观的指标，也是最容易做手脚的。用精确匹配算，模型只要措辞不同就判错；用语义相似度算，事实错误可能被放过。我现在的做法是准确性拆成两层：核心事实对不对和辅助细节全不全。核心事实用人工标注的要点清单来核，辅助细节用自动指标做粗筛。这样至少能保证“答对了主要结论但漏了实验条件”这种情况不会被判成满分。
事实一致性这个指标我越来越看重。它问的是模型说的每一句话是否都能在文献里找到支撑，而不是“听起来像那么回事”。我遇到过模型把两篇论文的结论嫁接在一起，单看每句话都合理，合起来就是错的。评事实一致性需要句子级的证据对齐，工作量很大。我目前的做法是抽样评，每个模型抽50到100条回答，逐句核对。这个样本量做不了精细的统计推断，但能抓出系统性的编造倾向。有一次抽检发现某个模型特别喜欢补全作者没说但“按理应该成立”的结论，这种倾向在自动指标里完全看不出来。
引用可追溯性分两个层次。低层次是看模型有没有给出引用标记，高层次是看引用是否真的支撑了那句话。很多模型能标出一个文献编号，但你顺着编号去查，发现那段话跟引用文献对不上。我在实际使用中会把引用可追溯性当成一个准入门槛：如果一个模型在回答里不给引用，或者给了引用但经不起抽查，它的答案我一律不采信。专家评审则是最后一道关。我请过两位领域内的同事帮我盲评模型回答，他们的判断和自动指标的相关性大概只有中等程度。专家更在意“这个答案能不能直接用于科研决策”，自动指标更在意“表面像不像标准答案”。两套标准都要有，不能偏废。
2.4 评测协议与可复现性：提示词、上下文长度、检索配置与误差分析
评测协议这件事，说多了都是泪。同一个模型，换一个提示词模板，分数能差出五到十个点。我早期做对比的时候没把提示词固定下来，后来回头看数据，根本分不清模型之间的差异有多少是提示词造成的。现在我要求所有对比实验提示词版本化管理，模板、系统消息、few-shot示例全部记录在案。提示词里加一句“请基于提供的文献回答”和加一句“请仔细阅读以下文献后回答”，模型的表现就可能不一样，这不是玄学，是注意力分配变了。
上下文长度是另一个容易被忽略的变量。科学文献动辄几十页，模型能吃进去多少、吃进去之后中间部分会不会被“遗忘”，直接影响评测结果。我做过一个简单的测试，把同一篇论文的不同长度版本喂给模型，问同一个细节问题。短上下文版本答对了，长上下文版本反而答错了，原因是关键段落被淹没在大量无关内容里。所以评测协议里必须写清楚上下文是怎么构造的：是整篇论文、摘要加结论、还是检索出来的相关段落。不写清楚，别人没法复现，你自己过两个月也忘了当时怎么跑的。
检索配置在RAG类方案里是命门。分块大小、重叠长度、嵌入模型、召回数量、重排序策略，每一个都会影响最终答案。我见过对比文章只写“使用了RAG”，其他一概不提，这种结果没法参考。我的习惯是把检索配置像实验方法一样写出来，包括分块策略和召回参数。误差分析这块我承认自己做得不够系统。目前主要是对错误样本做归类：检索没召回、召回但排序靠后、模型忽略证据、模型过度推断、答案正确但引用错位。归类之后能看出不同模型的错误模式差异很大。有的模型错在检索，有的错在推理，有的错在表达。不做误差分析，只看总分，很容易选错方案。
2.5 基准选择建议与常见评测陷阱
选基准这件事，我的建议是别只用一个。至少两个，一个偏抽取和事实核查，一个偏生成和综合理解，再加一个跨领域的做泛化测试。我目前常用的是QASPER加PubMedQA的组合，前者测NLP论文上的细粒度理解，后者测生物医学领域的事实判断。如果有条件，再加一个多跳数据集看模型的跨文献整合能力。基准的选择要跟你的应用场景对齐。你做药物研发辅助，就别拿计算机论文的基准当唯一标准；你做跨学科文献综述，就要选领域覆盖广的基准。我见过团队拿单一基准刷到高分就宣布模型可用，上线之后被用户骂得很惨。
常见评测陷阱我列几个自己踩过的。第一个是数据泄漏，有些模型在预训练时见过评测集的原文，分数虚高。判断方法是看模型在“改写版”问题上的表现是否断崖下跌。第二个是答案长度偏差，生成式评测里长答案往往覆盖更多要点，自动指标会给高分，但长答案里夹带的错误也更多。我现在的做法是对长度做分层统计，别让长答案占便宜。第三个是忽略不可回答样本，前面提过，不再展开。第四个是人工评审的评分者一致性，请专家打分之前要先做校准，给同样的回答让不同专家独立打分，看差异有多大。差异太大说明评分标准没对齐，得先开会统一口径。这些陷阱听起来琐碎，每一个都能让评测结果失去参考价值。我花在排查这些坑上的时间，比跑模型本身多得多。
3.1 模型层面对比：通用LLM、科学领域模型与RAG增强模型
说实话，把这三个放在一起比，本身就是一件不太公平但又不得不做的事。我拿同一个问题问过GPT-4、Claude这类通用大模型，也问过SciBERT、BioBERT这些科学领域微调过的模型，还搭过RAG流水线让通用模型挂上检索。问的是“这篇论文里提到的那个催化剂在多少度下失活”，通用大模型能给你编出一个看起来特别专业的数字，语气笃定得让人差点信了。领域模型在术语理解上确实稳一些，你给它一段材料科学的摘要，它能准确抓出关键参数，但你让它组织一段完整的解释性回答，它就有点露怯，输出的东西更像关键词堆叠而不是人话。
RAG增强方案是我目前最看好的路子，但它的“好”是有前提的。我试过用LlamaIndex搭检索，把论文切成块、嵌入、召回、塞进上下文让模型回答。检索召回对了，答案质量直线上升；检索召回错了，模型就拿着不相关的片段硬编，编得比纯通用模型还离谱，因为它“以为”自己有依据。这个现象我印象特别深，纯通用模型胡说的时候好歹语气虚一点，RAG增强模型胡说的时候引用标记齐全、格式工整，反而更有欺骗性。
从能力维度拆开看，通用LLM强在语言组织和跨领域泛化，弱在事实精确性和领域术语的细腻理解。科学领域模型强在术语和结构感知，弱在生成流畅度和开放域推理。RAG增强模型试图两头占，但它把复杂度转嫁到了检索和编排环节。我自己的体感是：如果你的应用场景是“给一个具体问题、从一批已知文献里找答案”，RAG增强方案明显占优；如果是“让模型帮你理解一个新领域的整体图景”，通用大模型的广度和表达力还是更顺手。领域模型则更适合嵌在流水线里当组件用，比如做实体识别、关系抽取、证据段落打分，而不是直接端到端回答问题。
还有一点我吃过亏：科学领域模型的“领域”划分很粗。BioBERT在生物医学上表现好，你拿它去处理物理论文，它未必比通用模型强多少。我见过团队因为“科学领域模型”这个名字就默认它全能，实际跑下来在化学文献上还不如GPT-3.5。选模型的时候得看你的文献落在哪个细分领域，别被名字忽悠了。
3.2 科学文献问答模型开源工具对比：文档解析、检索、编排与引用管理
工具链这一块，我踩的坑比模型还多。文档解析是第一步，也是最容易被低估的一步。PDF里的公式、表格、双栏排版、脚注，解析不好后面全白搭。我用过GROBID，学术PDF解析确实专业，作者、摘要、参考文献能拆得比较干净，但部署起来有点重，Java环境加模型文件，小团队上手门槛不低。PyMuPDF轻量、速度快，但它是“文本提取”而不是“结构理解”，双栏论文经常把左右栏串成一行，读出来的句子前言不搭后语。我还试过Unstructured，它对多种格式支持好，但科学文献里的复杂表格经常被它拍平成一堆数字，丢了表头信息。后来我的做法是组合用：GROBID拆结构，PyMuPDF做兜底提取，表格单独用Camelot或者Tabula处理。
检索层的选择反而相对清晰。向量检索我用过FAISS、Milvus、Qdrant。FAISS最轻，单机跑小规模数据很舒服，但它就是个库，没有服务化能力。Milvus功能全、支持混合检索，部署复杂度也上来了，运维得有人盯着。Qdrant我用得不多，感觉上手比Milvus轻一些，适合中等规模。传统关键词检索别丢掉，BM25在科学文献里依然能打，尤其是查特定术语和基因名称的时候，向量检索反而容易漏。我现在的习惯是向量加BM25做混合召回，再加重排序，效果比单用一种稳。
编排框架这块LangChain和LlamaIndex我都深度用过。LangChain抽象层次多，灵活是真灵活，但调试起来也真痛苦，一个链条出问题你得一层层往里扒。LlamaIndex在检索增强场景下更专注，索引结构和查询引擎的设计更贴近文档问答的需求，但它的抽象也有自己的脾气，想深度定制的时候得改源码。Haystack我试过一版，感觉更偏生产部署，Pipeline的写法比较规整，社区活跃度比前两个弱一些。引用管理是最容易被忽略的环节。很多工具链只管生成答案，不管引用溯源。我现在的做法是自己加一层引用校验：模型输出的每个引用标记，回查原文段落，算语义相似度，低于阈值就标红让人工复核。这个环节不加，上线之后用户顺着引用去查发现对不上，信任直接崩掉。
3.3 工具链对比维度：部署成本、可扩展性、许可证、数据安全与社区生态
部署成本不能只看“能不能跑起来”。我算过一笔账，一个中等规模的RAG问答系统，向量数据库、嵌入模型服务、LLM推理，三块加起来对GPU和内存的要求不低。FAISS加本地小模型可以跑在单张消费级显卡上，适合原型验证。Milvus加7B级别的模型就得认真规划资源了。有些团队一开始用OpenAI的API做嵌入和生成，原型阶段很爽，数据量一上来账单也上来了。我建议原型期用API快速验证，一旦确定方向就把嵌入模型本地化，生成模型看场景决定要不要留API。
可扩展性我主要看两点：加新数据源容不容易，换模型容不容易。LangChain在这两点上确实方便，文档加载器和模型接口的抽象让切换成本比较低。但抽象层厚了之后，性能调优的空间也小了。LlamaIndex在索引结构上的扩展性更好，自定义节点解析器和后处理器比较顺手。许可证这事得认真看，我见过团队用了AGPL的组件做SaaS服务，后来发现合规上有麻烦。FAISS是MIT，Qdrant是Apache 2.0，Milvus是Apache 2.0，LangChain是MIT，LlamaIndex是MIT，GROBID是Apache 2.0，这些都比较宽松。但有些嵌入模型和重排序模型是研究许可，商用要单独谈。
数据安全在科研场景里特别敏感。很多论文是未发表的、涉密的、或者有Embargo期的。用云端API做嵌入和生成，数据出了本地环境，合规上就可能有问题。我现在的默认建议是：敏感数据场景全部本地化部署，嵌入模型用开源的BGE或者E5系列，生成模型用本地部署的开源权重模型。牺牲一点效果换合规确定性，这个交易在多数科研机构里是划算的。社区生态我主要看GitHub的issue响应速度和版本迭代节奏。有些工具星标很多但维护跟不上，遇到坑只能自己填。我选工具的时候会翻最近半年的commit记录和issue回复，比看星标数靠谱得多。
3.4 典型组合方案对比：从单模型问答到检索增强问答流水线
我实际搭过并对比过的组合大概有这么几种。方案A：纯通用大模型直接问。把论文摘要或者相关段落塞进提示词，让模型回答。这个方案上手最快，半小时能跑通。效果嘛，摘要级别的问题还行，细节问题就开始编。适合做快速原型或者对准确性要求不高的场景。
方案B：通用大模型加简单检索。用BM25或者向量检索召回top-5段落，拼进上下文。效果比A明显好一截，尤其是问题里包含特定术语的时候。但这个方案的瓶颈在检索质量，召回不准的时候模型会被误导。我试过在生物医学文献上跑，BM25对基因名称的召回很好，但对“这个机制的局限性”这类语义性问题就抓瞎。
方案C：科学领域模型做检索加通用大模型做生成。用领域模型做段落嵌入或者重排序，通用模型负责组织答案。这个组合在术语密集的场景下提升明显，因为领域模型的嵌入空间对专业词汇更敏感。代价是你得维护两套模型，部署复杂度上去了。方案D：完整RAG流水线。文档解析、分块、混合检索、重排序、生成、引用校验全套上。效果最好，工程量也最大。我目前的经验是，方案C到方案D之间的性能差距大概在10到15个点，但工程投入差了三倍以上。选哪个取决于你的场景对准确性的容忍度。
还有一个变体我最近在试：多模型投票。同一个问题让两个不同家族的模型分别回答，再用一个轻量裁判模型做一致性判断。成本上去了，但在事实性要求极高的场景下，能抓出不少单模型的系统性错误。这个做法在文献综述辅助场景里我觉得有潜力，日常问答就有点杀鸡用牛刀了。
3.5 对比实验设计：控制变量、消融分析与场景化评估
对比实验最容易犯的错就是变量没控住。我早期做过一组对比，A方案用提示词模板X，B方案用提示词模板Y，跑出来A比B高八个点，我差点就要下结论了。后来把提示词统一，差距缩到两个点以内。控制变量这件事在模型对比里怎么强调都不为过。提示词版本、上下文长度、检索召回数量、温度参数、甚至系统消息的措辞，全都得锁死。我的做法是建一个实验配置文件，所有变量写进去，跑实验的时候配置文件跟着结果一起存档。没有配置文件的实验结果，我默认不认。
消融分析是我判断“哪个组件在起作用”的主要手段。把检索去掉看效果掉多少，把重排序去掉看掉多少，把引用校验去掉看事实错误率涨多少。我做过一组消融，发现重排序模块对最终答案准确性的贡献比嵌入模型的选择还大。这个发现直接影响了我后面的资源分配。消融的粒度要看你的流水线复杂度，组件越多越需要拆开看。不做消融，你只知道整体好不好，不知道钱该花在哪。
场景化评估是我最近在强化的部分。标准基准测的是通用能力，但真实用户的问题往往带着具体场景的烙印。比如“帮我找这篇论文里提到但没给出具体数值的那个参数”，这种问题在标准基准里几乎没有。我现在的做法是从实际用户日志里抽样真实问题，人工标注一批小规模但高代表性的场景测试集。这个测试集不追求统计显著性，追求的是“能不能反映真实痛点”。标准基准加场景测试集双轨跑，比只看一个分数踏实得多。
实验记录我也吃过亏。早期跑完实验只存了最终指标，中间输出和错误样本没留，后来想回头分析错误模式，啥也找不到。现在我的习惯是每次实验把原始输出、检索召回列表、引用校验结果全部落盘。存储成本不高，回头复盘的时候能救命。
4.1 不同科研场景下的模型与工具选型矩阵
我经常被问“你们到底推荐用哪个模型”，这个问题真的没法一句话回答。选型这件事，场景不一样，答案能差出十万八千里。我把这几年踩坑攒下来的经验按场景拆了拆，画了个粗略的选型矩阵，不一定对每个人都适用，但至少能帮你少走点弯路。快速了解一个陌生领域这种需求，我强烈建议用通用大模型起步，GPT-4或者Claude都行，先把领域地图铺开，成本低、上手快，别一上来就搭复杂流水线，信息都没摸清楚就上重型工具是自找麻烦。做精确事实核查或者参数查询，RAG流水线几乎是必选项，而且检索层得下功夫。我见过太多团队检索随便配配，然后抱怨模型生成不准，问题根本不在生成端。混合召回加一个靠谱的重排序模型，比换生成模型带来的提升大得多。写文献综述或者做系统性回顾，我现在的做法是多模型交叉验证加引用校验，让两个不同家族的模型分别生成，再人工比对矛盾点，慢是慢了点，但综述这事本来就不能图快。跨学科检索这种场景比较特殊，科学领域模型的“领域”边界太粗了，跨学科的时候反而不如通用模型加混合检索灵活。多模态文献处理，比如需要理解图表和公式的，目前的开源工具链还不够成熟，我的建议是单独把图表处理拎出来用专门工具，别指望一个流水线全包了。
工具选型上我画过一个很简单的决策树：敏感数据先定本地化，再定向量库，再定编排框架，最后选模型。顺序反过来就是给自己挖坑，我见过先定了LangChain然后发现数据不能出内网、回头把整个编排层重写的团队，折腾了两个月。数据敏感度是第一道闸门，过了这道闸门再谈效果和成本才有意义。小团队快速验证，FAISS加LlamaIndex加本地7B模型，一张消费级显卡就够跑原型了。中等规模往生产环境走，Milvus加混合检索加重排序，编排层看团队习惯选LangChain或者Haystack，这时候运维得有人盯着。合规要求高的场景，GROBID做解析、BGE做嵌入、本地开源模型做生成，全链路不出内网，效果牺牲个把点换来的是合规确定性，这笔账在多数科研机构里算得过来。
还有一个维度很多人忽略：团队的技术栈和运维能力。你用Python技术栈的团队去维护一个Java重依赖的工具链，出问题的时候修都修不动。我见过一个实验室选了GROBID做解析，跑起来没问题，但后来版本升级遇到Java环境冲突，组里没人搞得定，直接卡住了整个项目。选工具不只看指标，还得看谁来维护、能不能维护。我的原则是：选团队里至少两个人能看懂源码的工具，不然出了问题只能干等社区回复。这不是保守，是吃过亏之后的教训。
4.2 从评测结果到落地部署：成本、合规与可维护性权衡
评测分数高不代表落地就好用，这个道理大家都懂，但真到选型的时候还是容易盯着榜单第一。我自己做过一个对比，两个方案在标准基准上差了五个点，但部署成本差了四倍，运维复杂度差了不止一个量级。最后上线的是那个低分方案，原因很简单：高分方案需要三张A100常驻，我们组的预算撑不住，而且那套流水线的编排逻辑太复杂，出问题排查要翻三层抽象。落地这事，评测分数只是入场券，成本、合规、可维护性才是决定你能不能跑下去的东西。
成本这事得算总账，不能只看模型推理的账单。我算过一笔完整的账：向量数据库的存储和计算、嵌入模型的服务化开销、检索服务的CPU占用、重排序模型的GPU占用、再加上LLM推理本身。一个中等规模的系统，嵌入和重排序这些“配角”加起来能占到总成本的三分之一，很多人做预算的时候只算了LLM的API费用或者GPU租赁费，漏掉这些就把预算做低了。还有一个隐性成本是人工复核。引用校验做得再好，总有一部分答案需要人看，这个人力成本在科研场景里千万别忽略。我的经验是，高准确性要求的场景，人工复核的成本能占到系统总成本的百分之二十到三十。
合规这条线在科研机构里特别需要提前画清楚。未发表的论文、有Embargo期的数据、合作方的机密材料，这些东西一旦通过云端API做了嵌入或者生成，数据就出了本地环境，事后想追回来基本不可能。我现在的默认动作是：拿到数据先做敏感度分级，分级结果直接决定部署形态，不分级就不启动选型。这个流程听起来笨，但省掉了后面无数的扯皮。可维护性是我最近一年越来越看重的维度。早期我选工具只看功能全不全、效果好不好，现在我会先翻GitHub的commit记录，看最近三个月有没有活跃维护，再翻issue列表看响应速度。功能再全的工具，半年不更新，遇到新版本的依赖冲突你就只能自己硬扛。我还养成了一个习惯：每个上线的组件都写一份内部维护笔记，记录版本锁定、已知坑、升级路径，交接的时候能救命。
4.3 科学文献问答模型对比的开放问题与发展趋势
科学文献问答这个方向变化太快了，我半年前觉得靠谱的方案，现在看就有点旧了。几个趋势我觉得值得盯一盯。长上下文模型和RAG的关系是个很有意思的开放问题。现在有些模型能直接塞进去几十万token，理论上整篇论文甚至整本文献集都能放进去，那检索环节还要不要？我的判断是要，至少短期内要。长上下文解决的是“信息能不能放进去”的问题，检索解决的是“该把哪些信息放进去”的问题，后者在文献规模上去之后只会更重要。但长上下文确实会改变RAG的设计思路，比如分块策略可以更粗、检索召回数量可以更少，整个流水线的参数得跟着重新调。我最近在试几组对比实验，还没有定论，但直觉是检索不会消失，只是角色会变。
多模态科学文献处理是另一个明显的缺口。科学论文里的图表承载了大量关键信息，现有的工具链基本把图表当二等公民，解析出来就丢了结构，更别说理解图表里的趋势和异常了。我试过几个多模态模型直接读图表，简单柱状图和折线图还行，复杂的热图、晶体结构图、流程图就开始胡说了。这个方向我觉得未来一两年会有明显进展，科学图表问答的基准数据集也在陆续出来，但现在还不到能放心落地的程度。还有评测基准本身的演化。现有的基准大多偏向通用问答能力，对“引用可追溯性”和“跨文献推理”的覆盖不够，我期待看到更多贴近真实科研工作流的评测设计，比如给定一批论文让模型做对比分析、找出实验方法上的差异、追踪某个结论的引用链。这类任务比单点问答难得多，也更有实际价值。
模型架构层面，我隐约感觉领域模型和通用模型的边界在模糊。现在有一些工作在做科学领域的继续预训练加指令微调，出来的模型在专业任务上逼近专用模型，通用能力也没丢太多。如果这个方向走通了，未来选型可能就没那么纠结了，一个模型覆盖大部分场景，RAG主要解决数据新鲜度和私有数据的问题。但这个判断现在下还太早，我保持观察。还有一个我觉得被低估的开放问题：科学文献问答系统的“拒绝回答”能力。现在的模型面对证据不足的问题，倾向于硬编一个答案而不是说“我不确定”。在科研场景里，一个自信的错误答案比一个诚实的“不知道”危害大得多。怎么让模型学会在证据不足时优雅地弃权，同时又不至于过度保守，这个问题目前没有好解法，我认为是落地部署里最需要攻克的点之一。
4.4 实践建议清单与结论
写到这里，我想把前面的讨论收成一份能直接拿去做事的清单。这些建议都是从实际项目里磨出来的，不一定每条都适用于你的场景，但踩过的坑大致是相通的。
数据敏感度先分级，再谈选型。拿到数据第一件事是做敏感度评估，分级结果直接锁死部署形态，这个顺序不能反。检索质量决定上限，生成模型决定下限。预算分配上，我建议检索和重排序的投入不要低于生成端的投入，很多团队的资源分配是反过来的，效果上不去还找不到原因。混合召回加轻量重排序是性价比最高的组合，纯向量检索在科学文献场景里漏召回的问题比想象中严重，BM25别丢。引用校验必须自己做一层，开源工具链在这个环节普遍缺失，自己加一层语义相似度回查，比事后被用户投诉强。实验配置和原始输出全部落盘，存储成本可以忽略，复盘的时候能救命。
原型期用API快速验证，定方向后嵌入本地化，生成模型看合规要求决定留不留API。工具选型看最近半年的commit记录和issue响应，星标数会骗人，维护活跃度不会。每个组件写内部维护笔记，记录版本锁定和已知坑，团队交接的时候你会感谢自己。场景测试集从真实用户日志里抽，标准基准加场景测试集双轨跑，只看一个分数容易误判。拒绝回答能力作为验收指标之一，证据不足时模型能不能诚实说不知道，这个指标比准确率更能反映系统在真实场景里的可靠性。
回到这篇对比文章的主线。科学文献问答模型的选型没有标准答案，通用大模型、科学领域模型、RAG增强方案各有各的适用边界，工具链的组合方式也远比单一工具的对比复杂。我自己的体感是，这个领域正在从“比模型分数”往“比系统设计”迁移，单点模型的差距在缩小，流水线设计和工程细节的差距在拉大。未来一两年，多模态理解、引用可追溯性和拒绝回答能力会是拉开差距的关键维度。对于正在做选型的团队，我的核心建议就一条：先把场景和数据边界摸清楚，再动手搭东西，顺序对了，后面的坑能少踩一半。这个领域变化快，今天的最佳实践明天可能就过时了，保持实验习惯、保持对评测结果的怀疑、保持对真实用户反馈的敏感，比选对任何一个具体工具都重要。
