1 如果资源有限，RAG 应该优先做哪些能力
P1 · rag
🏷 标签：rag, resource-constrained, optimization, tradeoff
1️⃣ 考察意图
面试官想看你能否在资源受限（算力、内存、延迟预算）下，区分 RAG 系统的“核心生存能力”与“锦上添花功能”。这不是背概念题，而是工程取舍决策题。刁钻点在于：候选人常陷入“全都要”的完美主义，或盲目堆砌组件（如强行上重排序、知识图谱）。答好了能展示系统设计思维、成本意识、以及从“能用”到“好用”的迭代路径。考察类型：系统设计 + 工程取舍。
2️⃣ 标准答
资源有限时，RAG 的优先级应遵循“检索召回率 > 生成质量 > 评估基线 > 延迟优化”的漏斗原则。具体分四步：
- **第一优先级：保证检索召回率（Recall@k）**Embedding 模型选型：优先用轻量但效果不差的模型，如
BGE-small（384维，约 30MB）或all-MiniLM-L6-v2，替代BGE-large（1024维，约 1.3GB）。实测在通用 QA 上 Recall@5 差距 < 5%，但内存和推理延迟降低 4-6 倍。 - 分块策略：固定 256 tokens + 128 tokens 重叠（overlap），避免语义断裂。为什么这么做：重叠能捕获边界上下文，减少“切碎”导致的召回丢失，且计算成本几乎为零。
- 混合检索兜底：若向量检索因模型压缩导致精度下降，加入 BM25（默认 k1=1.5, b=0.75）作为并行检索通道，用
reciprocal rank fusion（RRF）合并结果。实际落地的坑：BM25 对长文档的 TF 归一化敏感，需对文档做长度归一化（如除以平均长度），否则长文档会被过度惩罚。 第二优先级：优化生成质量（Generation） - LLM 选型：用
Llama-3-8B或Qwen2-7B替代 GPT-4。为什么这么做：8B 模型在 4-bit 量化后仅需 4-6GB VRAM，推理速度是 70B 的 10 倍以上，且通过精心设计的 prompt 模板（如“仅基于以下上下文回答，若不确定说不知道”）可弥补能力差距。 - Prompt 模板：固定三段式——系统指令 + 检索上下文 + 用户问题。坑：上下文长度不要超过 2048 tokens，否则 8B 模型会“迷失在中间”（lost in the middle），需截断或摘要压缩。 第三优先级：建立评估基线
- 最小评估集：用 50-100 条标注数据（人工或 GPT-4 生成），计算
Recall@3和生成准确率（精确匹配或 LLM-as-judge）。为什么这么做：没有基线，所有优化都是盲人摸象。资源有限时，先跑通评估 pipeline，再决定是否投入重排序。 - 工具：用
RAGAS或TruLens的轻量版，避免自建评估框架。 第四优先级：延迟优化（若预算允许） - 向量检索加速：用
FAISS的 IVF（Inverted File Index）替代精确搜索，nlist=100，nprobe=10，延迟从 50ms 降到 5ms，召回损失 < 1%。 - 缓存：对高频 query 做
LRU 缓存（如 Redis），命中率可达 30-50%，显著降低检索压力。
总结：优先保检索召回和生成质量，评估基线是“刹车”，延迟优化是“油门”。重排序、多轮对话、知识图谱等能力，在资源充足前一律推迟。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，优先保证检索召回率，用轻量 Embedding 模型（如 BGE-small）加 BM25 混合检索，分块策略固定 256 tokens 加重叠；第二，优化生成质量，用 8B 量化模型加三段式 prompt 模板；第三，建立评估基线，用 50 条标注数据计算 Recall@k 和生成准确率。总结一句：资源有限时，先让系统‘能跑通、能评估’，再考虑延迟优化和高级功能。”
4️⃣ 高频追问 & 应对
追问 1：你说用 BM25 兜底，但 BM25 和向量检索的分数尺度不同，怎么合并？
用 reciprocal rank fusion（RRF），公式为
score = 1/(k + rank)，k 通常取 60。为什么这么做：RRF 不依赖分数绝对值，只依赖排名，避免了归一化问题。实际坑：若 BM25 和向量检索的文档集不同（如 BM25 只索引标题，向量检索索引全文），需先统一文档 ID 空间，否则 RRF 会漏掉未重叠的文档。更优方案是用线性加权（如 0.3 * BM25_score + 0.7 * vector_score），但需要先做 min-max 归一化，增加复杂度。
追问 2：如果连 8B 模型都跑不动（比如只有 CPU 或 2GB VRAM），怎么办？
退而求其次用 Llama-3.2-1B 或 Phi-3-mini（3.8B），但必须配合 检索增强的 prompt 压缩。例如：用
LLMLingua或LongLLMLingua将检索到的文档压缩到 512 tokens 以内，减少 LLM 的上下文负担。取舍：生成质量会下降 10-15%，但延迟从 5 秒降到 1 秒。若仍不行，改用 纯检索 + 规则模板（如从文档中提取关键句拼接），完全放弃 LLM 生成，只做“检索式 QA”。
追问 3：你说评估基线用 50 条数据，但怎么保证这 50 条能代表真实分布？
用 分层采样：按 query 类型（事实型、推理型、多跳型）各取 15-20 条，覆盖高频场景。为什么这么做：随机采样可能只覆盖单一类型，导致评估偏差。实际坑：标注数据需人工校验，否则 GPT-4 生成的假阳性会误导优化方向。更稳妥的做法是先用 50 条跑通 pipeline，再逐步扩展到 200 条，并加入
k-fold 交叉验证评估稳定性。
5️⃣ 避坑 · 常见错误答法
- ❌ “优先上重排序（Reranker）提升精度，因为检索结果不够准。” → ✅ “重排序是锦上添花，资源有限时应先保证检索召回率（Recall@k）。如果检索本身漏掉关键文档，重排序也救不回来。实测在 Recall@5 < 70% 时，重排序对最终准确率提升 < 3%，但延迟增加 50-100ms。”
- ❌ “用 GPT-4 生成，因为效果最好。” → ✅ “GPT-4 成本高、延迟大，资源有限时应用 8B 量化模型加 prompt 模板。若效果不达标，先检查检索召回率，再考虑是否升级模型。80% 的生成错误源于检索失败，而非 LLM 能力不足。”
- ❌ “先做知识图谱（KG）增强，因为能提升多跳推理。” → ✅ “KG 构建成本高（标注实体关系），且对简单 QA 无增益。资源有限时，应先用 BM25 + 向量检索解决 80% 的 query，多跳推理可通过 prompt 链（Chain-of-Thought）临时替代。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“资源受限下的系统设计”切入，强调你如何用 BGE-small + BM25 混合检索替代昂贵方案，并给出 Recall@3 提升 15% 的量化结果。展示成本-收益分析报告。
- 如果你只做过传统 NLP：用“信息检索中的 BM25 vs 向量检索”类比，说明你理解检索召回率是 RAG 的瓶颈。强调你做过文档分块和评估基线，能快速迁移到 RAG 场景。
- 如果你是校招无项目：聚焦“论文复现”，如复现
REPLUG（检索增强的 LM）或Atlas（检索增强的 T5），说明你理解检索与生成的耦合关系。可补充一个 demo：用Llama-3-8B+FAISS在 Colab 上跑通最小 RAG 系统。 - 《REPLUG: Retrieval-Augmented Black-Box Language Models》（2023）
- 《Atlas: Few-shot Learning with Retrieval Augmented Language Models》（2022）
- 《RAGAS: Automated Evaluation of Retrieval Augmented Generation》（2023）
- 《LLMLingua: Compressing Prompts for Accelerated Inference》（2023）
- 《FAISS: A Library for Efficient Similarity Search》（2017）