SciRet 这个项目里最容易被忽略的词是 Compute-Aware。很多人做 RAG检索增强生成实战时习惯问哪个 Embedding 模型更准、哪个重排器效果更好却很少把“计算成本”和“准确率”放进同一个坐标轴里去比较。SciRet 做的正是这件事在科学文献检索场景下把检索Retrieval和重排Reranking每一步的收益与资源消耗放在一起实测找出不同预算下真正值得用的配置。如果你正在搭科研论文知识库、做本地 RAG 问答或者被 Agentic RAG 的多步检索搞得性能和成本双双失控这篇文章值得看完。我会先讲清楚这个实验到底在研究什么问题然后给出一套可以照着复现的方法环境怎么准备、语料怎么切块、候选集怎么定、重排器选多大、计算成本怎么量化、出了问题先查哪里。1. 先搞清楚 SciRet 到底在研究什么问题1.1 检索和重排不是两个孤立环节一个常规 RAG 流程可以拆成四段文档切块、召回检索、重排精排、上下文生成。前两段决定“有没有”后两段决定“准不准”。很多人的误区在于把检索和重排当成两个独立问题分别调优最后拼起来却发现整条链路又慢又不稳定。SciRet 的切入点是检索和重排是级联关系召回给了重排什么重排就只能在这个范围内选。如果第一轮只召回 5 个候选重排器再强也无法找回被漏掉的内容如果第一轮召回 100 个候选重排器的计算量会明显上涨延迟也随之增加。这里的核心矛盾不是“哪个更好”而是“给定一份计算预算在哪里花钱最划算”。1.2 Compute-Aware 到底指什么Compute-Aware 可以理解为“计算感知”。传统评测只比较准确率、Recall、MRR但一套真正能落地的 RAG 系统还要同时看三笔账时间账单条查询从发出到拿到结果的 p99 延迟是多少。资源账检索、重排、生成分别占多少显存、内存和 CPU。金钱账如果用了外部 API每千条查询的重排费用是多少如果本地部署显卡和服务器成本又是多少。SciRet 这类实证研究做的事情就是把这些维度统一记录最后画出“质量-成本”曲线。同一个准确率可能有一种配置只花一半时间同一个延迟预算可能有一种配置能把准确率提高好几个点。这种结论只有靠实测才能得到。1.3 这个项目适合谁参考正在搭论文阅读助手、科研知识库问答系统的开发者。用本地模型做 RAG对显存和延迟敏感的个人开发者。做企业级 RAG 交付需要给客户解释“为什么这个回答用 5 个候选而不是 20 个”的技术人员。写 RAG 相关论文或技术评测需要一套可复现的实验方法的研究者。一句话总结它不解决“怎么让 RAG 更聪明”而是解决“怎么用有限算力让 RAG 达到够用的聪明”。2. 科学文献场景为什么特别在意检索和重排的成本2.1 科学文献的文本特征天然不适合无脑切块科学论文和普通网页文本差别很大。普通文档按固定长度切块比如 512 个 token、64 个 token 重叠通常不会出大问题。但论文里有公式、表格、参考文献、实验数据和章节层级一个公式被拦腰切断检索时就算召回命中语义也已经损坏一篇论文的结论部分引用了前面某个实验数据向量相似度却可能完全匹配不上。所以科学文献场景下切块策略不是简单的预处理而是直接影响检索质量和后续计算量。如果按小节切一个长章节可能超过上下文限制如果按固定长度切又可能把一个完整的实验描述切成两半。SciRet 这类实验里切块策略通常要作为第一个变量来测而不是默认选一种。2.2 科学术语让“检索召回”和“重排精排”的分工更明显科学文献的查询往往很短比如“transformer 位置编码的改进方法”但相关段落可能分布在摘要、方法、实验和讨论多个位置。纯词法检索BM25 这类对术语敏感但对同义词和语义改写不敏感纯向量检索对语义理解好但对罕见术语、缩写、公式符号又容易飘。这就是为什么要用两段式先用便宜的方式召回足够多候选再用更贵的方式精排。科学文献里召回池拉得越大重排的收益越明显但代价是重排器要处理的候选数量跟着涨。SciRet 的关键测量点就在这里K 取多少、重排器取多大才能让长尾查询也覆盖到同时不让延迟膨胀。2.3 Agentic RAG 和知识图谱方案让成本问题变复杂现在很多团队转向 Agentic RAG让模型自己决定搜索哪份文档、拆成几个子问题、搜完再综合。这种方式体验确实好但检索次数翻倍重排次数也翻倍计算成本往往不是线性上涨而是成倍上涨。还有人用知识图谱加向量库做混合方案图谱查询和向量检索两条路径都要跑中间还需要对齐逻辑。SciRet 的实证思路放到这些场景里依然成立先给每一步定预算再测单步质量和成本最后再做组合。没有这个基线Agentic RAG 很容易变成“效果不错但每次查询都在烧算力”的黑盒。3. 想复现这套实验先把环境准备好3.1 语料和评测集是实验的地基做科学文献 RAG 实验第一步不是选模型而是准备语料和评测集。建议先找一批开放获取的论文 PDF 或论文摘要数据规模不用大100 到 500 篇足够跑通第一轮实验。关键是要转成干净的纯文本去掉页眉页脚、参考文献格式差异公式尽量保留原始文本形式实在不支持就注明该段不可用。评测集至少要包含50 到 200 条问题。每条问题对应一份正确答案或一组相关文档 ID。问题难度要有区分度一部分是术语查询一部分是跨章节推理查询一部分是含糊的开放问题。如果原始材料里没有现成评测集可以自己构建从论文里选一些关键结论逆推成问题再把包含该结论的段落标为正确答案。这个过程虽然费时但评测质量直接决定后面所有结论是否可信。3.2 模型的选型不要一上来就拉着最大的跑常见检索方案分三类方案代表工具/方向特点词法检索BM25、Elasticsearch无 GPU 也能跑对术语精确匹配好对语义改写差稠密向量检索BGE、GTE、OpenAI Embedding 等语义理解好依赖向量索引和 Embedding 模型质量混合检索词法 稠密 RRF 融合召回更全面但多一条检索路径延迟更高重排方案也分两类重排方案特点成本交叉编码器把 query 和候选拼接成一对输入直接打分精度高但慢中LLM 重排让大模型对候选排序或逐条打分能利用指令理解复杂相关性高不重排直接按检索分数取前 K 个零我的建议是先把 BM25 和一个小号的稠密检索模型跑通拿到基线。基线质量什么样后面所有重排收益都要和它比较这样才知道重排器到底值不值得引入。3.3 硬件条件先说清楚复现这类实验的最低配置可以很低但要分清“能跑”和“能批量跑”。只在 CPU 上跑 BM25 和一个小 Embedding 模型8GB 内存都够跑一个 base 级重排器一张 8GB 显存的显卡也能启动要跑 large 级重排器和几十万篇论文的索引16GB 到 24GB 显存会更从容。低配置环境也能做完整实验方法是缩小语料和评测集规模。不要拿着 1000 篇论文去压测 24GB 显存先用 50 篇把流程跑通再逐步扩大。这个原则在 SciRet 这类实验里同样适用第一次跑永远先验证“链路通不通”而不是“指标高不高”。4. 从切块到生成完整跑一遍实验流程4.1 切块先统一规则再记录切块信息对于科学文献我建议至少准备两套切块策略固定长度切块512 token64 token 重叠先看整体稳定性。段落感知切块按标题、段落、小节边界切超长段落再二次切分。无论用哪种都要记录每个 chunk 的元数据来源文档 ID、章节路径、页码、在文档中的位置。这样后期做引用溯源和结果排查时才有依据。很多人做 RAG 实战时只看输入输出不看 chunk 来源出了错根本定位不到是哪篇论文、哪一段误导了模型。4.2 第一轮检索控制候选数量记录召回率建好索引后先单独测检索器。对每一条评测问题分别取 top 5、top 10、top 20、top 50 的候选计算 RecallK。这里的 K 不是最终送给生成模型的块数而是“重排器的输入池大小”。为什么要分多个 K 测因为召回率和计算量是强关联。K 越大重排器要处理的样本越多延迟越高但 K 太小长尾查询可能压根没把正确答案召回。科学文献里有些答案分散在多个章节K 只有 5 时很容易漏掉。4.3 重排按预算配置不要一次拉满重排环节可以设计成多组对比实验候选池固定为 K20重排器分别用 base、large 两个规模。重排器固定为 base候选池分别取 K5、10、20、50。加一组“不重排直接取检索 top 5”作为对照组。每组实验都要记录两件事重排后的 MRR、NDCG 或答案准确率从输入查询到重排结束的耗时和显存占用。不要只记质量指标不然换一台机器或换一个模型库所有结论都要重跑。4.4 生成阶段组装上下文验证最终答案质量如果实验涉及最终问答生成生成阶段也需要固定参数送入 LLM 的 chunk 数量、最大上下文长度、是否要求模型输出引用来源。科学文献问答特别看重引用溯源如果生成的答案没有对应文档段落支撑准确率再高也不可信。这里要注意最终效果是检索、重排、生成三段叠加的结果。评测中间每一步是为了定位瓶颈评测最终答案是为了判断整条链路是否满足业务需要。两者都要做。4.5 每一轮跑完必须留日志我在实测时会为每条查询记录一个 JSON 行{ query_id: q_001, retriever: bm25, reranker: bge_reranker_base, candidate_k: 20, recall_at_10: 0.8, mrr_at_10: 0.65, retrieval_ms: 35, rerank_ms: 180, total_llm_ms: 1200, vram_mb: 6800 }有了这个日志结构后面画成本曲线、对比不同方案、排查慢查询都会非常方便。没有日志支撑的实验跑完很容易变成“感觉这个方案不错”说不出具体好在哪。5. 计算成本到底怎么量化不能只靠感觉5.1 把“快”和“省”拆成可测指标SciRet 这类研究的核心方法论是把主观感受变成可比较数据。我建议每个配置至少记录以下指标维度指标测量方式延迟单查询 p50/p95/p99 总耗时连续跑 200 条查询统计分位数吞吐QPS单线程或固定并发下每秒完成的查询数显存峰值 VRAMnvidia-smi 或模型库自带统计内存进程峰值 RSS系统监控工具记录成本单查询 API 费用或硬件摊销按调用次数和单价估算索引建索引耗时和占用空间对同一批语料计时同一套配置建议至少跑 3 轮取稳定值避免首轮缓存干扰。5.2 质量指标也要跟着变换重排环节重点看后置指标MRR、NDCG、RecallK。最终生成环节重点看答案准确率、完整性和引用命中率。科学文献场景下引用溯源与 groundedness 是一个重要维度答案里出现的每个事实能不能在检索到的文档里找到对应段落。不要只用一个指标做决策。比如某个配置 MRR 很高但生成答案时经常拼接错误信息那这个配置的检索质量好不代表最终可用。反过来某个配置 Recall 很高但重排后 top 1 经常选错那用户体验仍然很差。5.3 画一张“质量-成本”曲线把每个配置的质量分数和单位成本放到一张表里结论会非常直观配置Recall20MRR10p99 延迟峰值显存BM25 不重排0.620.3880ms0.5GB稠密 不重排0.710.45150ms2.1GB稠密 重排 baseK200.750.58420ms4.2GB稠密 重排 largeK200.770.611200ms12.8GB注意上表数据是示例不是某个固定结论。真实环境里每种配置的数值会因语料和模型而变但观察方式是一样的。从这张表通常能看出一个规律从“不重排”到“重排 base”质量提升明显成本增加可接受从“重排 base”到“重排 large”质量提升变得平缓成本却可能翻几倍。这就是 compute-aware 最典型的判断场景。6. 关键参数怎么取舍给一个稳妥的起点6.1 top-K先定候选池再定送入生成的块数候选池 K 和送入生成的块数 N 要分开。K 是重排器的输入N 是打包进 prompt 的块数量。我的建议新手先设 K20N5。如果重排器速度够快把 K 提到 50观察最终指标涨幅。如果 N 增大后答案没有明显变好就保持在 3 到 5 个块既省 token 又减少干扰。科学文献查询里经常出现“正确答案在第 3 个候选”和“正确答案在第 40 个候选”的极端情况。K 太小会漏K 太大重排器扛不住。K20 是一个性价比很高的起步点。6.2 重排器的体量和批量大小如果用的是交叉编码器可以从 base 起步。实测时跑完 base 再决定要不要升级 large。不要一开始就上 large原因有两个一是 large 的延迟在小数据样本里会掩盖整条链路的其他瓶颈二是 base 的误差已经能告诉你“重排这条路径收益有多大”如果 base 相对不重排几乎没有提升large 大概率也救不回来。交叉编码器重排时可以使用批量推理。把 20 个候选分成一批一次性传入模型打分通常比逐条跑快很多。批量大小设多少要看显存一般 16 到 64 之间。批量越大吞吐越高但 p99 延迟也会变长因为单条查询要等整批算完。交互式问答场景我更偏向批量小一点比如 16 或 32优先保证单条查询延迟稳定。6.3 什么时候可以跳过重排如果满足以下条件重排可以先不引入文档集合小几百篇以内检索结果本来就很集中。检索器质量够高top 5 里经常已经有正确答案。延迟要求极高比如实时问答必须在 200ms 内返回。这里有个容易误判的地方不重排不代表零成本。稠密检索本身也要消耗 Embedding 模型的推理资源还要维护向量索引。做技术选型时把“不重排”当成一个配置而不是默认最省。6.4 本地 7B 模型环境下的成本结构很多人做本地 RAG 用的是 7B 级别的生成模型注意力都放在生成模型上却忽略了重排器在整条链路里也占着不小的推理时间。实测中经常看到一个 base 重排器处理 20 个候选的耗时可能和 7B 模型生成 200 个 token 的耗时相当甚至更久。所以在本地 7B 模型环境里重排器的选择对整体延迟影响很大。如果显存只有 8GB 到 12GB我会优先把重排器限制在 base 级甚至考虑用更轻量的列表级重排方案而不是让重排器和大模型抢显存。7. 常见报错和卡点按这个顺序排查7.1 检索为空或者召回结果明显不相关先看输入再看索引最后看模型。检查查询文本是否包含不必要的标点、大小写、公式符号有些检索器对这些非常敏感。检查 chunk 内容切出来的文本是不是乱码PDF 转文本时公式和表格是否丢失。检查索引一致性Embedding 模型换过之后索引有没有重新构建维度是否一致。检查切块重叠重叠太小可能导致跨块语义断裂重叠太大会让同一段内容反复出现重排浪费时间。我见过很多“检索不准”的案例最后定位到的问题是索引文件用的是旧模型版本生成的重新建一次索引就好了。先确认这一点再去调模型参数。7.2 重排太慢怎么定位是模型问题还是参数问题先做一次最小化测试只跑一条查询候选池 K5记录从输入到输出的耗时。如果此时还慢问题大概率出在模型本身或设备环境如果此时很快但 K50 时突然变慢问题出在候选数量和批量策略。接下来看 CPU 和 GPU 的利用率。如果 GPU 利用率很低但 CPU 很高可能是数据预处理和模型推理没有流水线化每次都在做重复编码。如果显存占用接近上限可能触发了内存 swap这种慢不是算力不够而是显存容量不够。7.3 显存溢出交叉编码器重排和 LLM 生成是显存占用的两个主要来源。出现 OOM 时按顺序处理降低重排器的批量大小比如从 32 降到 8。减少候选池 K从 50 降到 20。缩短输入序列长度对科学文献尤其重要超长论文段落可以提前截断。如果是把 Embedding 模型和重排器同时加载在 GPU 上可以考虑让 Embedding 模型跑 CPU或按阶段加载卸载模型。7.4 重排分数不可比不同重排器输出的分数不在一个量纲上有的偏向 0 到 1有的可能是负数。直接比较分数没有意义应该比较排序后的顺序指标比如 MRR、NDCG。同一个实验里不要混用两个来源的分数字段日志里也要标明具体模型名称和版本。7.5 实验结果不可复现科学 RAG 实验最怕的结果是不能复现。每次实验前固定四样东西语料版本、chunk 版本、模型版本、评估集版本。所有配置参数写到配置文件里代码目录加 commit 记录。很多所谓的“某个重排器比另一个好”换一个模型版本之后可能结论就反过来了。8. 落地时真正要盯住的几个点SciRet 这类 compute-aware 研究的价值不只是告诉你哪个模型最好而是帮你建立一套“先测量、再优化、后上线”的工作方式。落到实际项目里我建议按下面这几步走。第一步跑出一个最简基线。一份小语料一个检索器不加重排记录全部时间、内存和准确率指标。这个基线是所有后续优化的参照物没有基线就没法判断任何优化是真是假。第二步给每条查询写日志。日志字段不用太多但必须包含候选数、重排耗时、生成耗时、使用的模型名、最终答案引用了哪些 chunk。有了这些数据用户在线上反馈“回答不准”时你才有依据判断是检索漏了、重排错了还是生成模型自己编了。第三步按预算做取舍。如果业务要求 p99 延迟在 1 秒内那 large 重排器很可能直接出局应该在“稠密检索 base 重排 K20”附近找最优解。如果业务非常在意答案准确性且允许 3 秒延迟再把候选池和重排器体量往上提。第四步考虑缓存和复用。科学文献问答里很多查询是重复的或者只是措辞不同。可以对相似查询做归一化缓存重排结果也可以对同一批热点论文预先生成摘要和关键段落索引。这些优化比单纯换模型更能在不牺牲质量的前提下降低成本。最后说一点我的体会很多人看到检索准确率提升几个点就觉得很值却很少问“这几点准确率是用多少倍延迟换来的”。SciRet 值得学习的不是某一个最佳参数而是那种把质量和成本放在同一张表里看的习惯。做科学文献 RAG 尤其如此文献规模会越来越大查询会越来越复杂没有 compute-aware 的思维项目越往后越容易因为性能瓶颈推倒重来。从一个小样本、清晰日志、可控候选数开始把这个测量习惯建立起来比追着最新模型跑更重要。