⁴⁰

⁶

⁹⁹⁺

RAG系统的一些高频问题与参考方案——RAG系列第一篇

Mrchen

2026-03-04 19:17

阅读7031

Mrchen

2026-03-04 19:17

阅读 7031

今天有朋友询问我，他在面试某大厂时面试官问到的一个问题应该怎么回答，原问题是关于他项目里RAG系统的耗时与优化方案的，由次展开了一些针对RAG系统的思考，整理了几个可能是RAG系统面试时高频的问题，供诸君参考。

1. RAG一般采用的存储架构？（元数据、向量以及完整资料分别怎么存储？）

工业界主流是元数据 + 向量分离存储，也有一体化存储方案；关联靠全局唯一 ID做跨库主键绑定。

一、主流存储方案（按规模 / 复杂度）

1. 分离式（企业级最常用）

元数据：存 MySQL/PostgreSQL（结构化查询、事务、关联、统计强）
存：文档 ID、标题、作者、时间、来源、分块 ID、权限、标签、状态等
向量数据：存 专用向量库（Milvus、Weaviate等）
存：分块向量、分块原文、少量元数据（用于过滤）
原始文档：存 对象存储，只存不检索

2. 一体化（中小项目 / 快速落地）

PostgreSQL + pgvector：单库存表 + 向量，无需跨库，适合轻量场景
Elasticsearch：存全文 + 向量 + 元数据，做混合检索（BM25 + 向量）
专用向量库内置元数据：Weaviate/Milvus 自带元数据字段，支持向量 + 元数据过滤

3. 混合检索架构（高准确率）

向量库（Milvus）+ ES（全文 / 元数据）+ MySQL（元数据 / 业务）
检索时：向量召回 + ES 关键词 / 元数据过滤 + 重排序

二、跨库关联：唯一 ID 绑定

1. 全局唯一 ID 设计

文档级 ID：doc_xxx（UUID / 雪花 ID），贯穿全链路
分块级 ID：chunk_xxx（doc_xxx_001），向量库主键
每个分块：
- MySQL：chunk_id + doc_id + 元数据
- 向量库：chunk_id（主键）+ 向量 + 分块文本 + 过滤用元数据

2. 关联流程（写入 + 检索）

写入链路

文档上传 → 解析分块 → 生成doc_id+chunk_id
元数据写入 MySQL（以chunk_id为键）
分块向量化 → 向量 +chunk_id+ 过滤元数据写入向量库
原始文件存对象存储，用doc_id关联

检索链路

用户查询 → 生成查询向量
（可选）MySQL 查元数据过滤（如时间 / 权限）→ 得到候选chunk_id
向量库按chunk_id范围 + 向量相似度检索 → 返回 Top-Kchunk_id+ 文本
（可选）MySQL 补全完整元数据 → 组装上下文给 LLM

2. 海量数据的分布式存储方案

一定是：分布式元数据 + 分布式向量库 + 分布式对象存储三部分完全解耦、各自水平扩展。

一、具体存储方案

1. 元数据存储（结构化）

必须分布式：

MySQL ➜ 分布式 MySQL（ShardingSphere / 云厂商 RDS 分库分表）
或直接上 TiDB / OceanBase（分布式 NewSQL，天然支持海量行）

存什么：

doc_id、chunk_id、标题、作者、时间、来源、权限、标签、状态、索引状态

2. 向量存储（高维向量 + 相似度检索）

必须分布式向量库：

Milvus 分布式版（最主流）
Weaviate 集群
Qdrant 分布式
云厂商：Pinecone、阿里云 ElasticSearch 向量版、腾讯云向量数据库

特点：

支持 十亿～百亿向量
支持 分片 + 副本
支持 标量过滤 + 向量检索 下推

3. 原始文档 / 大文件

对象存储（分布式）：

S3 / 阿里云 OSS / 腾讯云 COS

只存原文，不检索，无限扩容。

二、分布式下怎么关联？

用唯一 ID 做全局 “纽带”，不管多少台机器、多少分片，都能精准对应。

1. 全局唯一 ID（贯穿所有库）

doc_id：文档唯一 ID（雪花 ID / UUID）
chunk_id：文本块唯一 ID（doc_id + 序号）

2. 三库关联关系

TiDB / 分布式 MySQLchunk_id 为主键存：元数据、业务字段、权限、标签
分布式向量库chunk_id 作为主键存：向量、chunk 文本、少量过滤元数据
对象存储doc_id 作为文件名 / 路径存：原始文件（pdf、docx 等）

三、海量数据写入流程

文档上传 → 解析 → 分块
生成 doc_id + chunk_id
元数据批量写入 TiDB / 分布式 MySQL
向量化 → 批量写入分布式向量库（Milvus 集群）
原始文件 → 写入对象存储
异步更新状态：已索引 / 异常

关键点：向量库只负责 “相似检索”，不负责业务复杂查询MySQL 只负责业务查询，不负责向量

四、海量数据检索流程

用户提问 → 向量化
权限 / 标签过滤先查 TiDB → 得到允许访问的 doc_id 列表
向量库执行：向量相似度检索 + 过滤 doc_id 列表返回 topK chunk_id + 文本片段
根据 chunk_id 去 MySQL 补全元数据（标题、时间、来源等）
丢给 LLM 生成回答

五、10 亿向量以上的进阶方案

向量冷热分离热数据：SSD 高性能向量集群冷数据：压缩 + 对象存储
多级检索

粗排：ES / 向量库
精排：重排序模型（bge-reranker 等）

分布式任务调度使用 Spark / Flink 做批量向量化、清洗、更新

3. 如何优化RAG全链路的耗时？

一、先搞清楚：RAG 慢在哪？

90% 时间都在这 4 步：

用户问题 → 向量化（Embedding）
向量库检索（ANN 检索）
召回太多片段 → 重排序（Rerank）
送入 LLM 做生成（最慢）

下面是每一步的工业级优化。

二、全链路优化方案

1. Embedding 层优化

本地部署 Embedding 模型不要每次都调远程 API，本地用：
BGE-small / bge-m3
GPU 推理：TensorRT-LLM /vLLM/ ONNX Runtime
缓存高频问题向量热点问题直接读缓存，不重新计算。

2. 向量检索层优化（核心提速）

（1）向量库本身优化

使用 HNSW 索引（速度 vs 精度最优）
调低 ef 参数，牺牲一点点精度换速度
开启 批量检索、预加载、内存加载

（2）检索前过滤

先过滤，再检索，工业界标配：

按权限、部门、时间、文档类型过滤
只在小范围向量集合里做检索向量库支持标量过滤下推

（3）召回数量控制

不要一次召回太多条
先召回少量给重排，足够用即可

3. 重排序（Rerank）优化

rerank 是延迟大户，优化如下：

使用 小模型、轻量级模型bge-reranker-base/micro 足够
只对向量召回的前 N 条做 rerank
把 rerank 做成 batch + 异步
能不用 rerank 就不用：简单场景直接向量排序

4. LLM 生成优化（最大瓶颈）

限制上下文长度只给 LLM 最相关 2~5 条，不要塞太多
使用 更快的推理引擎vLLM、TensorRT-LLM、TGI
开启流式返回（streaming） 用户感知延迟大幅降低
热点问答缓存相同问题直接返回答案

5. 架构级优化

向量库集群分片Milvus / Qdrant 分布式，水平扩容
多级缓存 问题 → 召回结果 → LLM 回答全链路缓存
服务异步化Embedding、检索、rerank 并行执行
热点数据放内存高频向量、高频元数据内存加载

6. 数据预处理优化（离线做，不占线上时间）

文档 提前分块、提前向量化
建立 多层索引：关键词索引（ES）+ 向量索引
混合检索：BM25 召回 + 向量召回 → 合并 → 重排速度更快、更稳定

三、标准极速 RAG 架构

▼
plain
复制代码
用户问题
   ↓
【缓存】是否命中？直接返回
   ↓
Embedding（本地GPU）
   ↓
元数据过滤 → 缩小检索范围
   ↓
向量库 HNSW 检索（召回10~20条）
   ↓
轻量级 rerank
   ↓
只取 top3~5 送 LLM
   ↓
流式返回

4. RAG检索进一步优化方案——预打分、排序设计

通过元数据预打分 + 预排序 + 快速路由，用来绕过部分向量检索，大幅提速、降成本、稳体验。（权威性打分这一个设计同时也能够解决资料内容发生冲突时，AI难以抉择的问题）

一、思路本质：把「部分检索逻辑提前物化到元数据」

元数据可以存两类：

高频关键词相似度 / 匹配分
来源权威性权重

目标：

简单问题、高频问题 → 不走向量检索，直接元数据过滤 + 排序
复杂问题 → 再走完整 RAG
整体：更快、更稳、更便宜

二、为什么可行？

真实场景里，大量查询是：

高频问题
明确关键词
强依赖来源可信度（如：政策、公告、知识库、客服）

这类查询：向量检索反而慢、不稳定、开销大，不如元数据预计算。

三、具体怎么设计字段

可以在 MySQL 里加这些字段：

1. 权威 / 质量分（固定或半固定）

authority_score float # 来源权威分 0~1
source_type varchar # official / whitepaper / article / user_generated
quality_score float # 内容质量分

2. 高频关键词预匹配分（离线计算）

top_key_tags json # 例如：["发票", "报销", "离职"]
keyword_match_score float # 与高频词库的预计算分

3. 综合预排序分

rank_score = keyword_match_score * 0.4 + authority_score * 0.6

查询时：

▼
sql
复制代码
select chunk_text
from chunk
where match(top_key_tags) against ("用户问题")
order by rank_score desc limit 5

四、核心问题：新资料进来，怎么保证优先级一致？

1. 权威性分：用「规则引擎」而不是人工写死

权威分不能每条手动算，必须自动化：

来源权威分 = 规则计算

官方文档 → 0.9~1.0
内部知识库 → 0.8
外部权威网站 → 0.7
普通文章 → 0.4
用户生成 → 0.1~0.2

新文档一入库，自动打上 authority_score。 这样就不会乱。

2. 高频关键词匹配分：离线 + 实时双链路

（1）维护一个「全局高频词库」

从日志里挖：top 1000 / 5000 高频问题
定期更新（每天 / 每周）

（2）新文档进来时，自动计算：

与高频词库的 BM25 相似度
或简单的 词匹配数、权重和
结果存入 keyword_match_score

（3）批量更新（保证全局一致）

每天离线跑任务：对所有文档重新计算关键词分
增量更新 MySQL
不影响线上

这样：新老文档用同一套规则，优先级对齐。

五、真正工业级怎么用？（查询路由策略）

可以做一个分类器（轻量级，甚至规则就行）：

用户问题进来
判断是否属于：

高频问题
关键词明确
强依赖权威来源

如果是 → 走元数据快速通道
否则 → 走完整 RAG（向量 + 重排）

这就是很多企业知识库、政务问答、内部 OA 的架构。

5. RAG的评估维度以及标准评估方法？

一、RAG 核心评估维度

1. 检索质量

检索是 RAG 的 “输入命脉”，直接决定上限。

Recall@k：前 k 个召回片段中，真正相关的片段占全部相关片段的比例
Precision@k：前 k 个召回片段中，相关片段占比
Hit Rate@k：前 k 个结果至少命中一个相关片段的概率
MRR（Mean Reciprocal Rank）：首个相关文档排名的倒数均值，衡量排序合理性
上下文相关性：召回片段与 Query 的语义匹配度

2. 生成质量

重点评估不胡说、答得对、答得好。

Faithfulness（忠实度）：回答完全基于检索上下文，无幻觉、无编造
Factuality（事实准确性）：回答无事实错误、逻辑错误
Answer Relevance（回答相关性）：紧扣用户问题，不跑题、不冗余
Completeness（完整性）：覆盖问题所有要点
Fluency（流畅性）：语法、逻辑、可读性

3. 端到端业务效果

回答准确率
任务成功率（如：咨询解决率、信息获取完成度）
幻觉率
用户满意度 (CSAT)

4. 工程效率

检索延迟、生成延迟、端到端耗时
QPS / 吞吐量
向量库召回速度
资源与成本

二、标准评估方法（工业界主流流程）

1. 离线自动评估

构建标注集：<Query, 标准答案, 相关文档片段>
计算检索指标：Recall@k、Precision@k、MRR、HitRate@k
生成指标：

传统：ROUGE、BLEU（对标标准答案）
语义：BERTScore、Sentence-BERT 相似度
忠实度：上下文蕴含（Entailment）判定

2. LLM-as-Judge（最实用的批量评估）

用更强的 LLM 做 “裁判”，接近人工且成本低、可规模化。评估维度：

忠实度（是否基于上下文）
相关性
事实准确性
完整性输出：1–5 分 + 简评。

3. 人工评估（金标准）

适用：上线前最终验收、核心场景校验做法：

多维度打分表
多人标注 + 一致性校验（Kappa 系数）最权威，但成本高、速度慢。

4. 在线 A/B 测试（真实效果）

分桶对比：

对照组：原 RAG
实验组：优化后 RAG观测：用户问题解决率、差评率、二次提问率、停留时长。

5. 幻觉专项评估（RAG 核心痛点）

构造事实性 / 对抗性 Query
用 LLM 自动判定：是否编造、是否无依据引申
统计：幻觉回答占比、错误类型

三、标准评估流程

离线自动评估 → 快速筛掉差方案
LLM-as-Judge 批量校验 → 筛选优方案
人工评估 → 金标准验收
在线 A/B 测试 → 业务效果验证