RAG-Stack: Co-Optimizing RAG Serving Performance and Quality
Haiqiang Zhang, Yuanqing Lei, Wanting Li, Tao Zhang, Wenqi Jiang
cs.DB, cs.IR
2026-08-04
RAG 有一堆配置(索引、模型、检索策略),每套都是质量与性能的不同折中。RAG-Stack 不必部署每个候选就能搜出帕累托前沿,同等迭代次数下比 SOTA 多覆盖 52.5%-153.2% 的质量-性能空间。
一套 RAG 系统的旋钮多得吓人:检索用哪种索引、top-k 取多少、要不要 rerank、生成器用哪个模型、模型怎么调检索。每一组配置都是「答案质量」和「服务性能」之间的一个不同折中,没有一组全面最优。给一个具体部署挑配置,说到底是在找一个二维的帕累托前沿。
作者点出现有三类痛点:现有优化器要么忽略跨阶段交互、要么忽略阶段级信号;多目标 RAG 优化器只盯算法空间,看不见系统设计空间(部署位置、批大小、并行度);而靠真部署去测性能又贵又不能跨系统迁移。RAG-Stack 就是冲这三条来的。
RAG-Stack 由三块拼成,目标是「不部署每个候选就能搜出帕累托前沿」。
RAG-PE 是多目标贝叶斯优化器(MOBO 的扩展)。它带子指标感知:用阶段级诊断(检索的 context recall/precision、生成的 faithfulness)引导探索方向,但优化的仍是端到端的质量和服务性能。候选池是异构的:Sobol 覆盖、阶段引导候选、DLS 局部细化、帕累托张力交叉,四路互补;停滞时用 LogNEHVI 评分仲裁、强制激活某条通道。
RAG-IR 是一层系统无关的工作负载抽象:一个 workflow schema(各阶段性能属性的无序摘要)加每请求 trace(执行 DAG、各阶段调用与 token 数),把质量评测和下面的代价模型接起来。
RAG-CM 是代价模型,ML 解析混合,四层:算法层把 RAG 阶段(IVF-Flat/PQ/Fastscan、HNSW)建模成硬件无关的算子工作画像;性能层用 roofline 把画像映射成时间(阿姆达尔定律);通信层按拓扑给跨设备数据移动定价;装配层扫系统设计空间,组合出吞吐和延迟。
还有一个前沿迁移模式:换到新服务系统时,复用旧的质量测量、用 RAG-CM 在新资源下重新打分部署,再做少量打磨迭代,不必从头搜。
两个数据集(RAGEval 100 query、MS MARCO 100 query 来自 8.84M 段),两套硬件(SysA 配 4 张 H100,SysB 配 8 张 A100 80GB),基线是 GP+LogNEHVI、SMAC3、Greedy-Forward/Lookback。
同等迭代预算下,RAG-Stack 找到的帕累托前沿比 SOTA 配置搜索方法多覆盖 52.5%(RAGEval)和 153.2%(MS MARCO)的归一化质量-性能空间。前沿迁移到新系统时,适配后的前沿比从头重搜多覆盖 182.2%。端到端搜索耗时 4.59 小时(RAGEval)、3.60 小时(MS MARCO)。
| 项目 | RAG-Stack vs SOTA |
| RAGEval 前沿多覆盖 | 52.5% |
| MS MARCO 前沿多覆盖 | 153.2% |
| 系统迁移前沿多覆盖 | 182.2% |
对 RAG 评测和部署工程师,这篇把「挑 RAG 配置」从手调玄学变成可系统化的前沿搜索,而且 RAG-CM 让结果能跨硬件迁移,省掉换机器就重测的成本。子指标感知那招也实在:不只看端到端分数,还看每个阶段的诊断,知道瓶颈在检索还是在生成。
评测只在两个数据集上各取 100 条 query,样本偏小,「多覆盖 X%」的数字在不同查询分布下未必稳。代价模型 RAG-CM 是 ML 加解析的混合,对它没见过的硬件或算子组合预测精度会掉,而论文没给出分布外误差。设计空间也被限定在他们枚举的算法加系统选项里,出了这个范围(比如换一种全新检索范式)不适用。