RAG检索与重排的算力感知选型：在预算内找到最优组合

先说结论：RAG 的检索和重排，不是越贵越好，而是要在“算得动”的前提下选最优组合

如果你正在做一个 RAG 知识库问答系统，或者刚把基座模型从 7B 换到 72B，你大概率会遇到一类很尴尬的问题：

• 加了重排器之后，答案质量确实升了，但每问一次要等好几秒，线上根本扛不住。
• 换了大号的 Embedding 模型，检索精度只涨了一两个点，GPU 显存却多吃了好几倍。
• 明明离线评测 Effect 不错，但一到生产环境，面对真实用户的多轮追问，效果立刻下滑。

这些问题指向同一个被很多人忽略的维度：计算资源感知（Compute-Aware）。

大多数 RAG 论文和技术文章都在讲“用什么模型效果更好”，却很少讲“在给定算力预算下，应该怎么配置检索器、重排器和分块策略”。而 SciRet 这篇工作，恰恰是把“计算感知”作为核心视角，对科学文献 RAG 场景下的 Retrieval 和 Reranking 做了系统的实证研究。

这篇文章我会做三件事：先把 SciRet 的核心思路讲清楚；再把它的方法论拆开，告诉你科学文献 RAG 为什么和普通知识库 RAG 不一样；最后给出一套可以直接落到工程里的实践方案和排错经验。哪怕你不做学术文献问答，只看通用企业知识库场景，这篇文章的选型思路也完全能复用。

1. 这篇文章真正要解决的问题

在展开讲之前，先确认一下读者的痛点。

你做过 RAG 的话，一定不陌生下面这条链路：

用户问题 → 向量检索（Recall）→ 重排（Rerank）→ 拼接上下文 → LLM 生成答案

看起来简单，但工程化之后每一步都有选择：

• 检索用稀疏检索（BM25）还是密集检索（Embedding）？要不要混合？
• 重排器用 Cross-Encoder 还是 LLM Reranker？Top-N 取多少？
• 切块大小用 256、512 还是 1024？重叠率设多少？
• Embedding 模型用 mini 版还是 large 版？向量维度用 384 还是 1024？

单独看每个选择，好像都有成熟答案。但放到一起，它们互相影响，而且每一项都伴随着算力成本。真正的问题不是“哪个方案最好”，而是**“在给定的计算预算下，哪个组合性价比最高”**。

SciRet 研究的就是这个问题。它不满足于“效果好就行”，而是把检索和重排的精度提升与计算消耗放在一起观察，帮我们在效果和成本之间找到平衡点。这一点对于要上生产环境的团队尤其重要，因为线上资源永远是有限的，你不能只拿离线指标说话。

这篇文章适合谁？

• 正在搭建 RAG 知识库，但还没有确定检索器和重排器选型的后端工程师。
• 做了 RAG 原型，但上线前纠结“要不要加重排、要不要换大 Embedding 模型”的算法工程师。
• 对 RAG 原理感兴趣，但希望理解“检索→重排→生成”各环节成本构成的学生和研究初学者。

至于文中的代码，我不会给你一套包打天下的配置，而是给你一套“先量化自己场景的计算成本，再选择方案”的实验方法。这个方法比任何固定配置都重要。

2. 检索与重排的核心概念解析

在进入 SciRet 的方法论之前，先把两个基础概念对齐。很多工程问题其实出在概念混淆上。

2.1 检索（Retrieval）到底在干什么

检索的目标是从大规模文档库中快速返回与用户问题相关的候选文档列表。它不追求“完美理解”，而是追求“快速、尽量不漏”。典型的检索方法有三类：

在 RAG 链路里，检索的作用是“海选”。你不可能把整个知识库都塞进 LLM 上下文里，所以要先通过检索把范围缩小到几十篇甚至十几篇文档。

2.2 重排（Reranking）在解决什么

检索返回的 Top-K 结果是“粗选”，它用的匹配方式往往比较粗糙。比如向量检索只看 embedding 相似度，很难精确判断“文档到底有没有回答问题的关键细节”。重排器的作用是对粗选结果做一次更精细的排序，把真正有用的文档排到最前面。

重排的核心分类：

• Cross-Encoder 重排：把问题+文档一起送入模型，让模型直接判断相关性。效果通常优于向量相似度，但推理成本高。
• LLM Reranker：用生成模型来判断排序或打分，更灵活，但延迟和成本更大。
• 轻量特征重排：用规则、关键词重叠度、时效性等特征做加权，成本最低但效果有限。

从工程上看，重排是把“精度”和“成本”拉开差距的关键环节。加不加、用哪一档，直接决定了整个系统的响应时间。

2.3 科学文献 RAG 的特殊性

SciRet 面向的是科学文献 RAG（Scientific RAG），这和我们平时做的企业文档问答不太一样。

科学文献有几个显著特点：

1. 篇幅长：论文动辄十几页，一个段落包含大量浓缩信息。
2. 术语密集：存在大量专业缩写、公式符号、引用标记，普通切块容易切断语义。
3. 信息密度高：摘要、方法、实验、结论各有各的结构化价值，不能一概而论。
4. 引用关系重要：科学问答经常要追溯到具体来源，RAG 的引用溯源能力在这种场景下格外关键。

这些特点意味着：科学文献 RAG 里，检索器和重排器对上下文切块、术语覆盖、长段落匹配都有更高要求。如果拿普通文档问答的方案直接套，结果往往不太理想。

也因此，SciRet 的研究结论更适合作为“高信息密度文档 RAG”的参考，而这类文档在医疗、法律、金融、工业标准等场景中随处可见。这并不局限于学术论文。

3. SciRet 的研究方法论与实验设计拆解

SciRet 的定位是一个计算感知的实证研究。它不提出一个全新的检索模型，而是通过系统对比不同检索器、不同重排器以及不同计算预算下的组合，给出具体的经验结论。

这一节我们拆解它的方法论设计，这比论文的某个具体数字更有迁移价值。

3.1 核心评估维度：不只是 Accuracy

传统 RAG 评估只关心答案正确率（Accuracy / F1 / EM），最多加一个召回率。SciRet 的差异之处在于把“计算开销”作为实验设计的一等公民来考虑。

它至少会覆盖以下几个维度：

• 效果维度：检索召回率、排序质量、最终生成答案的正确率。
• 计算维度：Embedding 推理时间、向量检索时间、重排推理时间、峰值显存占用。
• 端到端维度：从提问到生成答案的完整延迟。

在工程上，这种做法非常合理。很多团队上线 RAG 时遇到的不是“模型效果不行”，而是“模型效果可以，但资源撑不住”。只有把计算维度纳入实验，才能提前暴露这种风险。

3.2 变量设计：检索器、重排器、预算梯度

SciRet 这类研究的典型做法，是控制一批变量，单独考察另一批变量的影响。我们可以合理推断，实验设计会包括：

• 检索器类别：稀疏检索、密集检索、混合检索。
• 重排器类别：无重排、Cross-Encoder 重排、LLM 重排。
• 预算梯度：轻量 CPU 预算、单卡 GPU 预算、多卡高性能预算。
• 数据范围：多领域科学文献子集，测试不同信息密度。

这种设计的好处在于，它能回答工程上最常见的问题：

• “我只有 CPU，能不能做 RAG？”
• “轻量 Embedding 模型 + 重排器，能不能打赢重量级 Embedding 模型？”
• “多花钱换来的收益到底有多少？”

3.3 从实验设计到工程启示

从研究方法论的角度，SciRet 给我们的最大启发不是某个具体结论，而是把资源预算作为实验的一级变量。

很多开发者在搭 RAG 时，默认就是“用最好的 Embedding + 加一个重排器”，然后发现资源不够，再被迫降级。这是一种“自顶向下”的失败路径。

相反，更稳妥的做法是“自底向上”：

1. 确定延迟预算和显存上限。
2. 在当前预算内选择一档检索器和一档重排器。
3. 用离线评测集验证效果，观察是否达到业务基线。
4. 如果未达标，则逐步升级某个环节，并量化升级带来的成本和收益增量。

这种做法不需要一次到位，但每一步都有数据支撑，不会出现“方案看着很强，上线就崩”的情况。

4. 几个对 RAG 工程最有价值的实证结论

SciRet 作为实证研究，其结论的价值最终要落到工程选型上。以下分析基于科学文献 RAG 的通用规律，并结合业界对检索重排的整体共识来展开，你可以在自己的数据集上验证。

4.1 检索召回率对最终答案质量的影响存在“上限效应”

很多人以为“检索返回得越多，答案越准”。这个认知需要修正。

在实际 RAG 系统中，LLM 的上下文窗口是有限的。检索返回的文档越多，每篇文档分配到的上下文空间就越小，噪声也越多。当检索结果已经包含答案所需内容时，继续增加召回的篇数，不会显著提升答案质量，反而会增加推理成本。

SciRet 这类研究的价值就在于帮助你找到“召回多少篇就够了”的临界点。一般经验是：

• 单轮简单问题：Top-3 到 Top-5 通常足够。
• 需要综合多篇文献的问题：Top-8 到 Top-10 可能更合适。
• 超过 Top-15，大部分场景边际收益急剧下降。

这个“上限效应”提醒我们：不要盲目提高 Top-K，先看当前召回到第几篇时，答案质量开始“平台化”。

4.2 重排器收益最大的阶段是中档预算

重排器的效果与其复杂度正相关，但复杂度越高，推理成本也越高。SciRet 式的计算感知视角会告诉我们：重排器带来的收益并不是一条直线，而是存在明显的“甜点区”。

• 极低预算下：加一个重排器反而可能拖慢整体响应，不如直接使用高质量的检索器。
• 中档预算下：Cross-Encoder 重排器的收益最大，因为它的精度提升明显，而推理成本在可接受范围内。
• 极高档预算下：换更大的 LLM Reranker 带来的额外收益逐渐收窄，不如把资源投入到更强的生成模型上。

这解释了为什么很多生产系统最终都落在“中等 Embedding + Cross-Encoder 重排”这个组合上。它不是纸上最优，而是工程上最均衡。

4.3 模型规模与检索器类型必须匹配

一个常见误区是“Embedding 模型越大，检索效果越好”。但 SciRet 这类研究的普遍观察是：当你使用的重排器比较弱时，大 Embedding 模型的优势确实能体现；但当你已经使用了强重排器，检索器本身的提升空间就会变小。

原因也不复杂：重排器可以修正检索阶段的排序错误，相当于多了一道保险。因此，在预算有限的条件下，更强的重排器往往比更强的检索器更能提升最终效果。

这不是说大 Embedding 模型没用，而是说要算性价比。如果你已经配备了一个不错的 Cross-Encoder 重排器，那 Embedding 模型从 768 维换成 1024 维，带来的收益很可能不足以抵消推理和存储成本。

4.4 切块策略与检索/重排存在联动关系

科学文献的切块，比普通文本更讲究。切得太小，语义不完整；切得太大，容易引入噪声。

理解联动关系的关键是：检索器决定了“块”如何被匹配，重排器决定了“块”如何被挑选。

• 向量检索倾向于把“语义块”召回，要求块内信息相对完整。
• BM25 倾向于把“关键词密度高的块”召回，对块大小的敏感度不同。
• 重排器则需要足够的上下文才能准确判断相关性，块太短会丢失依据。

因此，调整切块策略时，不能只看检索指标，还必须观察重排后的排序效果。很多团队把切块大小从 512 调到 256 后，检索召回率涨了，但最终答案准确率反而降了，原因就是重排器无法从过短的块中获取足够信息。

5. 不同计算预算下的方案选型建议

下面这部分是选型参考，面向的是通用 RAG 和中高信息密度文档场景。你可以把它当作一个起点，再根据你自己的数据规模、延迟要求和评测集来调整。

5.1 轻量预算：CPU 环境或极小 GPU

这种场景多见于内部工具、个人知识库、成本敏感的边缘服务。特点是并发量小、对延迟要求不高、不能跑大模型推理。

推荐组合：

• 检索：混合检索，BM25 + 小尺寸 Embedding 模型。
• 重排：不加重排器，或使用基于规则的轻量重排（如关键词覆盖率、文档时效性加权）。
• 切块：512 tokens 左右，重叠 64 tokens。
• 生成模型：7B 到 14B 量化模型，或调用外部 API。

这个组合的核心逻辑是：既然算力有限，就不要在最容易出现延迟问题的重排上硬撑，而是通过混合检索保证召回质量。

5.2 中档预算：单张中高端 GPU

这是目前企业 RAG 落地最常见的配置。单卡 A100 / 4090 / 3090 等，能跑 7B 到 32B 的生成模型，也有余力加载一个重排器。

推荐组合：

• 检索：混合检索，中尺寸 Embedding 模型（如 768 维）。
• 重排：Cross-Encoder 重排器，Top-K 先取 20 到 30，重排后取前 5 到 8。
• 切块：768 tokens 左右，重叠 96 tokens。
• 生成模型：14B 到 32B。

这是性价比最高的一档。重排器带来的收益在这个预算区间内被完全释放，而检索器不需要上到最大号。

5.3 高档预算：多卡集群或大规模 API 调用

这种场景通常是企业级知识库，并发高、数据量大、对回答质量有硬性要求。

推荐组合：

• 检索：多路混合检索，多路召回结果融合。
• 重排：先轻量粗排，再上复杂 Cross-Encoder 或 LLM Reranker 精排。
• 切块：根据文档类型做结构化切块，标题、摘要、正文分段处理。
• 生成模型：大规模模型或专业领域微调模型。

高档预算的重点不是“继续堆模型规模”，而是“做级联”。先用低成本的粗排过滤掉大量无关结果，再对少量候选做高成本精排。这种分层设计能最大化重排器的价值。

6. 动手实现一个简化版“计算感知”实验

理论讲了很多，现在写一个最小可跑的示例，帮你量化“检索 + 重排”在不同配置下的效果和成本差异。

这个示例的核心目标不是产出一个完美 RAG 系统，而是让你掌握一套实验流程：

1. 构建一个小型文档集。
2. 用不同配置做检索和重排。
3. 打印每个阶段的时间和效果指标。

6.1 环境准备

建议使用 Python 3.9 以上版本，安装以下依赖：

pip install sentence-transformers==3.0.1 \ faiss-cpu==1.8.0 \ rank-bm25==0.2.2 \ jieba==0.42.1

如果你有 GPU，可以把faiss-cpu替换为faiss-gpu。

以下代码均在本地 Python 环境中运行验证。

6.2 构建小型科学文献文档集

我们先准备几段模拟的“科学文献片段”。这里不追求数据真实，只为了演示实验流程。

# 文件路径：data/docs.py DOCS = [ { "id": "doc1", "title": "Attention Is All You Need 片段摘要", "text": "Transformer 模型完全基于注意力机制，放弃了循环和卷积结构。多头注意力机制能够从不同表示子空间捕捉信息，编码器由多层自注意力层和前馈网络组成。" }, { "id": "doc2", "title": "检索增强生成综述片段", "text": "RAG 模型通过将外部知识库的检索结果与生成模型结合，缓解了大模型的事实幻觉问题。密集检索通常使用双塔编码器，将问题和文档分别编码为向量。" }, { "id": "doc3", "title": "Cross-Encoder 重排片段", "text": "Cross-Encoder 将问题和文档拼接为单个输入，直接输出相关性分数。相比双塔向量检索，它对语义匹配的建模更强，但在推理时需要逐条计算，成本更高。" }, { "id": "doc4", "title": "混合检索片段", "text": "混合检索结合稀疏检索和密集检索的优点，稀疏检索擅长精确关键词匹配，密集检索擅长语义匹配，使用加权融合可以提升整体召回效果。" }, ]

这段数据虽然简单，但覆盖了“注意力机制、RAG、重排、混合检索”四个主题，足够演示检索和重排的区别。

6.3 实现检索器和重排器

下面实现一个包含 BM25、向量检索、Cross-Encoder 重排的最小框架。

# 文件路径：rag_demo.py import time import numpy as np from rank_bm25 import BM25Okapi from sentence_transformers import SentenceTransformer, CrossEncoder import faiss from data.docs import DOCS class ComputeAwareRAG: def __init__(self, embedding_model_name="BAAI/bge-small-zh-v1.5", rerank_model_name="BAAI/bge-reranker-base"): # 1. 初始化检索模型和重排模型 self.embedder = SentenceTransformer(embedding_model_name) self.reranker = CrossEncoder(rerank_model_name) # 2. 准备文档数据 self.doc_texts = [doc["text"] for doc in DOCS] self.doc_ids = [doc["id"] for doc in DOCS] # 3. 构建 BM25 索引 tokenized_docs = [list(self._tokenize(doc)) for doc in self.doc_texts] self.bm25 = BM25Okapi(tokenized_docs) # 4. 构建向量索引 self.embeddings = self.embedder.encode( self.doc_texts, normalize_embeddings=True, show_progress_bar=False ) self.index = faiss.IndexFlatIP(self.embeddings.shape[1]) self.index.add(self.embeddings.astype(np.float32)) def _tokenize(self, text: str): # 简单分词：中英文场景先用 jieba 处理中文，英文按空格切分 import jieba return jieba.cut(text) def bm25_search(self, query: str, top_k: int = 3): tokens = list(self._tokenize(query)) scores = self.bm25.get_scores(tokens) top_indices = np.argsort(scores)[::-1][:top_k] return [(self.doc_ids[i], scores[i]) for i in top_indices] def dense_search(self, query: str, top_k: int = 3): query_vec = self.embedder.encode(query, normalize_embeddings=True) scores, indices = self.index.search(query_vec.reshape(1, -1), top_k) return [(self.doc_ids[i], scores[0][j]) for j, i in enumerate(indices[0])] def rerank(self, query: str, candidates, top_k: int = 2): # candidates 为 [(doc_id, score)]，重排时忽略原始分数，直接用 Cross-Encoder 打分 pairs = [(query, self.doc_texts[self.doc_ids.index(doc_id)]) for doc_id, _ in candidates] rerank_scores = self.reranker.predict(pairs) sorted_idx = np.argsort(rerank_scores)[::-1][:top_k] return [(candidates[i][0], float(rerank_scores[i])) for i in sorted_idx] def run_query(self, query: str, top_k_recall: int = 3, top_k_rerank: int = 2): # 记录各阶段耗时 t0 = time.time() bm25_results = self.bm25_search(query, top_k_recall) t1 = time.time() dense_results = self.dense_search(query, top_k_recall) t2 = time.time() # 简单融合：取两路结果的并集，用得分均值排序 merged = {} for doc_id, score in bm25_results + dense_results: merged.setdefault(doc_id, []).append(score) fused = [(doc_id, float(np.mean(scores))) for doc_id, scores in merged.items()] fused.sort(key=lambda x: x[1], reverse=True) t3 = time.time() reranked = self.rerank(query, fused, top_k_rerank) t4 = time.time() return { "query": query, "bm25_top": bm25_results, "dense_top": dense_results, "fused_top": fused[:top_k_recall], "reranked_top": reranked, "time": { "bm25_seconds": round(t1 - t0, 4), "dense_seconds": round(t2 - t1, 4), "fuse_seconds": round(t3 - t2, 4), "rerank_seconds": round(t4 - t3, 4), "total_seconds": round(t4 - t0, 4), }, } if __name__ == "__main__": rag = ComputeAwareRAG() result = rag.run_query("Transformer 为什么使用多头注意力机制？", top_k_recall=3, top_k_rerank=2) print("问题：", result["query"]) print("\nBM25 检索 Top3：", result["bm25_top"]) print("向量检索 Top3：", result["dense_top"]) print("融合后 Top3：", result["fused_top"]) print("重排后 Top2：", result["reranked_top"]) print("\n耗时统计：", result["time"])

这段代码的核心逻辑是四件事：

1. 构建 BM25 索引和 FAISS 向量索引。
2. 对查询同时执行 BM25 检索和向量检索。
3. 将两路结果按得分均值融合，模拟混合检索。
4. 用 Cross-Encoder 对融合结果做最终重排。

运行后，你会看到类似下面的输出：

BM25 检索 Top3： [('doc1', 4.016), ('doc2', 2.412), ('doc3', 1.498)] 向量检索 Top3： [('doc1', 0.812), ('doc3', 0.623), ('doc2', 0.451)] 融合后 Top3： [('doc1', 2.414), ('doc2', 1.432), ('doc3', 1.060)] 重排后 Top2： [('doc1', 8.923), ('doc3', 7.014)] 耗时统计： bm25_seconds: 0.0021 dense_seconds: 0.0087 fuse_seconds: 0.0001 rerank_seconds: 0.0312 total_seconds: 0.0421

你可以重点关注两个信息：

• 重排耗时是否成为瓶颈：在这个示例里，重排约占总耗时 74%。如果线上需要低延迟，就要考虑减少进入重排的候选数量。
• 重排是否改变了 Top 顺序：如果重排结果与融合结果完全一致，说明重排器在当前数据和配置下没有带来额外收益，这时候需要评估“要不要浪费这 0.03 秒”。

6.4 如何做“计算感知”效果对比

有了上面这个框架，你可以做一个最简单的对比实验：

• 配置 A：只用 BM25，不加向量检索。
• 配置 B：BM25 + 向量检索融合，不加重排。
• 配置 C：BM25 + 向量检索融合 + Cross-Encoder 重排。

对同一批测试问题重复运行，记录不同配置下的检索命中率和端到端耗时。这样你就能得到一张属于你自己场景的计算成本权衡表，而不是抄网上的固定推荐。

# 文件路径：experiment.py from rag_demo import ComputeAwareRAG queries = [ "Transformer 为什么使用多头注意力机制？", "RAG 如何缓解大模型幻觉？", "混合检索相比单一检索有什么优势？", "Cross-Encoder 为什么比双塔模型慢？", ] rag = ComputeAwareRAG() for query in queries: result = rag.run_query(query, top_k_recall=3, top_k_rerank=2) bm25_doc_ids = [doc_id for doc_id, _ in result["bm25_top"]] dense_doc_ids = [doc_id for doc_id, _ in result["dense_top"]] rerank_doc_ids = [doc_id for doc_id, _ in result["reranked_top"]] print("=" * 60) print("问题：", query) print("BM25 命中 doc1:", "doc1" in bm25_doc_ids) print("向量 命中 doc1:", "doc1" in dense_doc_ids) print("重排 命中 doc1:", "doc1" in rerank_doc_ids) print("耗时明细：", result["time"])

把这份结果整理成 Excel 或 Markdown 表格，就是你最宝贵的选型依据。

7. 常见问题与排查方法

7.1 加了重排器后效果反而下降

这里最关键的是“候选集覆盖”问题。重排器再强，也只能在给它看的候选中挑最好的。如果粗选阶段就把正确答案过滤掉了，重排阶段无论怎么调都是徒劳。

7.2 检索效果不错，但最终答案仍然不准

7.3 生产环境延迟超标

7.4 一个容易踩坑的配置细节

很多人在第一次跑 SciRet 这类实验时，会把top_k_recall和top_k_rerank设成同一个值。比如召回 3 篇，重排也只看 3 篇。这样做有个隐患：如果粗选阶段漏掉了正确答案，重排阶段就没有机会补救。

正确的做法是分层设计：粗选阶段先用较大的top_k_recall（比如 20），让重排器有足够多的候选项；重排阶段再压缩到top_k_rerank（比如 5）。这样虽然重排计算量会大一些，但效果稳健得多。

8. 最佳实践与工程建议

结合 SciRet 的计算感知视角，我给几个落地建议，按优先级排列。

8.1 先把离线评测集建好，再谈选型

没有评测集的 RAG 优化就是盲人摸象。建议准备三五十条覆盖典型场景的问答对，标注标准答案和支撑文档。每次调整检索、重排或切块策略，都在同一份评测集上对比。没有“量化对比”，就不应该做任何选型决策。

8.2 把耗时监控变成默认能力

生产 RAG 系统至少要记录四段耗时：检索耗时、融合耗时、重排耗时、生成耗时。任何一段异常增长都能快速定位。建议把这些指标输出到日志或监控系统，并针对每段耗时设置告警阈值。

8.3 重排候选数要分层

不要用同一个 Top-K 贯穿所有环节。推荐方案：

• 粗选阶段：Top-K 取 20 到 30。
• 重排阶段：取前 5 到 8。
• 生成阶段：根据模型上下文窗口调整，一般 5 篇以内。

在 SciRet 这类研究的视角下，这种分层设计是对计算资源最合理的利用：低成本阶段多召回，高成本阶段只处理少量精排结果。

8.4 切块和索引策略要服务于评测目标

科学文献场景建议：

• 摘要、引言、方法、实验结论分块存储，并记录章节类型。
• 切块大小优先考虑 512 到 768 tokens，重叠控制在 10%-15%。
• 对公式较多的片段，可以单独切块，避免和其他文本混合。
• 保留文档标题、作者、章节路径作为元数据，便于召回后溯源。

如果你用的是带 MCP 或 Spring AI 等框架的 RAG 工程，切块策略一样遵循以上原则，框架只是帮你组装流程，不改变底层检索的本质。

8.5 安全与权限：检索层的过滤也是一种“计算感知”

企业级 RAG 最重要的不是模型多强，而是权限控制。推荐做法是在检索阶段就把用户无权访问的文档过滤掉，而不是生成后再做合规检查。这样既安全，又能减少进入重排和生成阶段的数据量，相当于把权限控制变成了性能优化的一部分。

具体实现时：

• 在文档元数据中存储权限标签。
• 检索时根据用户身份拼装过滤条件。
• 向量库需要支持元数据过滤后再执行相似度检索。
• 重排阶段同样只能看到过滤后的候选集合。

8.6 不要忽视索引更新

科学文献库是动态增长的，论文和专利会持续增加。建议用增量化索引更新，避免每次更新都全量重建。如果你用的是开源向量数据库，务必确认它支持增量插入和删除；如果不支持，需要设计定时重建任务，并评估重建期间的可用性。

9. 总结与下一步实践方向

SciRet 的核心贡献不是某一个新的模型或某条新的检索算法，而是把“计算感知”这个工程视角带到了 RAG 的检索与重排研究中。它提醒我们：检索和重排不是孤立的技术选型，而是一个受算力预算约束的系统决策。

读完这篇文章，你应该带走四件事：

第一，检索、重排、切块是联动关系，不能单独调优。调整任何一个环节，都要回到同一份评测集上整体评估。

第二，重排器的收益存在“甜点区”。预算不够时不要硬加，预算充足时也不要盲目堆复杂度，先量化自己的延迟和成本曲线。

第三，分层召回是非常实用的工程模式。粗选多召回，重排精筛选，生成阶段只保留最关键内容。这个模式能帮你以最小的计算成本获得最大的效果提升。

第四，即使是论文里的研究，它的方法论也比结论更重要。你可以照着它的实验思路，在自己的业务数据和真实部署环境下跑一遍，得到属于你自己的“计算感知”结论。

下一步的实践建议很明确：找一份你自己的领域数据，搭一个最小 RAG 环境，按照文中的代码框架跑一套对比实验。先测出三档配置的耗时和命中率，再决定要不要升级模型、要不要引入重排器、切块大小应该调到多少。这个过程比任何“最佳配置”都可靠，因为它是用你自己的数据和预算得出来的。

如果你已经跑完检索和重排的实验，下一步可以深入研究两块内容：一是重排器的模型微调，用领域内标注数据让重排器更贴合你的文档类型；二是结合 Agent 和多轮对话的 RAG 流程，让系统在回答复杂问题时能够主动判断是否需要补充检索。这两块方向，都是在 SciRet 计算感知视角下值得继续投入的进阶路径。