企业官网建设流程全解析

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 和一个小号的稠密检索模型跑通，拿到基线。基线质量什么样，后面所有重排收益都要和它比较，这样才知道重排器到底值不值得引入。

3.3 硬件条件先说清楚

复现这类实验的最低配置可以很低，但要分清“能跑”和“能批量跑”。只在 CPU 上跑 BM25 和一个小 Embedding 模型，8GB 内存都够；跑一个 base 级重排器，一张 8GB 显存的显卡也能启动；要跑 large 级重排器和几十万篇论文的索引，16GB 到 24GB 显存会更从容。

低配置环境也能做完整实验，方法是缩小语料和评测集规模。不要拿着 1000 篇论文去压测 24GB 显存，先用 50 篇把流程跑通，再逐步扩大。这个原则在 SciRet 这类实验里同样适用：第一次跑永远先验证“链路通不通”，而不是“指标高不高”。

4. 从切块到生成，完整跑一遍实验流程

4.1 切块：先统一规则，再记录切块信息

对于科学文献，我建议至少准备两套切块策略：

• 固定长度切块：512 token，64 token 重叠，先看整体稳定性。
• 段落感知切块：按标题、段落、小节边界切，超长段落再二次切分。

无论用哪种，都要记录每个 chunk 的元数据：来源文档 ID、章节路径、页码、在文档中的位置。这样后期做引用溯源和结果排查时才有依据。很多人做 RAG 实战时只看输入输出，不看 chunk 来源，出了错根本定位不到是哪篇论文、哪一段误导了模型。

4.2 第一轮检索：控制候选数量，记录召回率

建好索引后，先单独测检索器。对每一条评测问题，分别取 top 5、top 10、top 20、top 50 的候选，计算 Recall@K。这里的 K 不是最终送给生成模型的块数，而是“重排器的输入池大小”。

为什么要分多个 K 测？因为召回率和计算量是强关联。K 越大，重排器要处理的样本越多，延迟越高；但 K 太小，长尾查询可能压根没把正确答案召回。科学文献里，有些答案分散在多个章节，K 只有 5 时很容易漏掉。

4.3 重排：按预算配置，不要一次拉满

重排环节可以设计成多组对比实验：

• 候选池固定为 K=20，重排器分别用 base、large 两个规模。
• 重排器固定为 base，候选池分别取 K=5、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 这类研究的核心方法论，是把主观感受变成可比较数据。我建议每个配置至少记录以下指标：

同一套配置，建议至少跑 3 轮取稳定值，避免首轮缓存干扰。

5.2 质量指标也要跟着变换

重排环节重点看后置指标：MRR、NDCG、Recall@K。最终生成环节重点看答案准确率、完整性和引用命中率。科学文献场景下，引用溯源与 groundedness 是一个重要维度：答案里出现的每个事实，能不能在检索到的文档里找到对应段落。

不要只用一个指标做决策。比如某个配置 MRR 很高，但生成答案时经常拼接错误信息，那这个配置的检索质量好不代表最终可用。反过来，某个配置 Recall 很高但重排后 top 1 经常选错，那用户体验仍然很差。

5.3 画一张“质量-成本”曲线

把每个配置的质量分数和单位成本放到一张表里，结论会非常直观：

注意：上表数据是示例，不是某个固定结论。真实环境里，每种配置的数值会因语料和模型而变，但观察方式是一样的。从这张表通常能看出一个规律：从“不重排”到“重排 base”，质量提升明显，成本增加可接受；从“重排 base”到“重排 large”，质量提升变得平缓，成本却可能翻几倍。这就是 compute-aware 最典型的判断场景。

6. 关键参数怎么取舍，给一个稳妥的起点

6.1 top-K：先定候选池，再定送入生成的块数

候选池 K 和送入生成的块数 N 要分开。K 是重排器的输入，N 是打包进 prompt 的块数量。

我的建议：

• 新手先设 K=20，N=5。
• 如果重排器速度够快，把 K 提到 50，观察最终指标涨幅。
• 如果 N 增大后答案没有明显变好，就保持在 3 到 5 个块，既省 token 又减少干扰。

科学文献查询里，经常出现“正确答案在第 3 个候选”和“正确答案在第 40 个候选”的极端情况。K 太小会漏，K 太大重排器扛不住。K=20 是一个性价比很高的起步点。

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 重排太慢，怎么定位是模型问题还是参数问题

先做一次最小化测试：只跑一条查询，候选池 K=5，记录从输入到输出的耗时。如果此时还慢，问题大概率出在模型本身或设备环境；如果此时很快，但 K=50 时突然变慢，问题出在候选数量和批量策略。

接下来看 CPU 和 GPU 的利用率。如果 GPU 利用率很低但 CPU 很高，可能是数据预处理和模型推理没有流水线化，每次都在做重复编码。如果显存占用接近上限，可能触发了内存 swap，这种慢不是算力不够，而是显存容量不够。

7.3 显存溢出

交叉编码器重排和 LLM 生成是显存占用的两个主要来源。出现 OOM 时按顺序处理：

1. 降低重排器的批量大小，比如从 32 降到 8。
2. 减少候选池 K，从 50 降到 20。
3. 缩短输入序列长度，对科学文献尤其重要，超长论文段落可以提前截断。
4. 如果是把 Embedding 模型和重排器同时加载在 GPU 上，可以考虑让 Embedding 模型跑 CPU，或按阶段加载卸载模型。

7.4 重排分数不可比

不同重排器输出的分数不在一个量纲上，有的偏向 0 到 1，有的可能是负数。直接比较分数没有意义，应该比较排序后的顺序指标，比如 MRR、NDCG。同一个实验里，不要混用两个来源的分数字段，日志里也要标明具体模型名称和版本。

7.5 实验结果不可复现

科学 RAG 实验最怕的结果是不能复现。每次实验前固定四样东西：语料版本、chunk 版本、模型版本、评估集版本。所有配置参数写到配置文件里，代码目录加 commit 记录。很多所谓的“某个重排器比另一个好”，换一个模型版本之后可能结论就反过来了。

8. 落地时真正要盯住的几个点

SciRet 这类 compute-aware 研究的价值，不只是告诉你哪个模型最好，而是帮你建立一套“先测量、再优化、后上线”的工作方式。落到实际项目里，我建议按下面这几步走。

第一步，跑出一个最简基线。一份小语料，一个检索器，不加重排，记录全部时间、内存和准确率指标。这个基线是所有后续优化的参照物，没有基线就没法判断任何优化是真是假。

第二步，给每条查询写日志。日志字段不用太多，但必须包含候选数、重排耗时、生成耗时、使用的模型名、最终答案引用了哪些 chunk。有了这些数据，用户在线上反馈“回答不准”时，你才有依据判断是检索漏了、重排错了，还是生成模型自己编了。

第三步，按预算做取舍。如果业务要求 p99 延迟在 1 秒内，那 large 重排器很可能直接出局，应该在“稠密检索 + base 重排 + K=20”附近找最优解。如果业务非常在意答案准确性，且允许 3 秒延迟，再把候选池和重排器体量往上提。

第四步，考虑缓存和复用。科学文献问答里，很多查询是重复的，或者只是措辞不同。可以对相似查询做归一化，缓存重排结果；也可以对同一批热点论文预先生成摘要和关键段落索引。这些优化比单纯换模型更能在不牺牲质量的前提下降低成本。

最后说一点我的体会：很多人看到检索准确率提升几个点就觉得很值，却很少问“这几点准确率是用多少倍延迟换来的”。SciRet 值得学习的不是某一个最佳参数，而是那种把质量和成本放在同一张表里看的习惯。做科学文献 RAG 尤其如此，文献规模会越来越大，查询会越来越复杂，没有 compute-aware 的思维，项目越往后越容易因为性能瓶颈推倒重来。从一个小样本、清晰日志、可控候选数开始，把这个测量习惯建立起来，比追着最新模型跑更重要。