当前位置：首页 > news >正文

RAG 工程深入：从分块到混合检索的完整链路（附 15 道高频题）

news 2026/6/26 15:51:48

基础 RAG 是「文档切块 → Embedding → 向量检索 → LLM 生成」。但生产级 RAG 远不止这四步——分块策略、混合检索、Rerank、查询改写、防幻觉、知识库维护，每一环都决定最终效果。这篇按工程链路整理 Day03 核心知识点，文末附 15 道面试速答。

一、为什么要分块？四种策略怎么选

RAG 必须切分文档，原因有三：

上下文窗口限制：长文本有 Lost in the Middle 问题，中间内容容易被模型忽略
检索精度：不切分只能命中整篇文档，无法定位到具体段落
Embedding 质量：短文本语义更聚焦，长文本编码会被过度压缩

策略	做法	优点	缺点	适用
固定长度	按字符/token 硬切	简单快速	可能断语义	快速原型
分隔符	按段落/句号切	保留语义边界	块大小不均	Markdown 文档
递归字符	分隔符优先级逐级降级	兼顾大小与语义	—	工程默认
语义边界	相邻句相似度跌破阈值处切	效果最好	成本高	高质量 RAG

递归字符分块（LangChainRecursiveCharacterTextSplitter）的「递归」不是递归函数，而是分隔符列表\n\n → \n → 空格 → 字符逐级降级。

参数经验值：
- FAQ/问答：chunk_size 128~384 tokens
- 通用文档：512~768 tokens
- 长文档/论文：1024~1536 tokens
- overlap：chunk_size 的 10%~15%（防止边界信息丢失）
- 硬约束：不能超过 Embedding 模型最大输入长度（如 bge-large-zh 最大 512 tokens）

二、Embedding 模型怎么选

选型看四个维度：

维度	要点
语言	中文用 BGE-Large-ZH，英文用 text-embedding-3-small，混合用 BGE-M3
维度	768~1024 是性价比最优区间，超 1536 边际递减
速度	看参数量（3M~568M），小模型快、大模型准
MTEB	看 Retrieval / STS 子任务得分，不是只看总分

BGE-M3 三个 M：Multi-Lingual（多语言）、Multi-Functionality（稠密+稀疏+多向量）、Multi-Granularity（句子到长文档）。

注意：Embedding 模型没有 temperature 等生成参数，是「文本进、向量出」的固定权重模型。

三、向量数据库选型

方案	定位	适合
Milvus	云原生分布式专用向量库，HNSW/IVF/DiskANN	千万~亿级生产环境
Chroma	轻量嵌入式，pip install 即用	原型验证
FAISS	Meta 算法库，不是数据库，无 CRUD	研究/底层引擎
Elasticsearch	搜索引擎 + 向量插件	已有 ES 集群做混合检索

Milvus 三种部署：Lite（嵌入式）/ Standalone（单机服务）/ Distributed（K8s 集群）。

向量库 vs 传统库（互补，不替代）：

向量库	传统库
索引	HNSW/IVF 近邻图	B+ 树
查询	相似度搜索（近似）	精确匹配
事务	无 ACID	有 ACID
返回	Top-K 近似	精确结果

高维空间有维度灾难——所有点距离趋于相同，B+ 树无法排序，HNSW 用建图绕开。

四、混合检索：向量 + BM25 + RRF

单用向量或 BM25 都有盲区：

向量检索：擅长语义（「汽车」→「车辆」），但对精确术语（ConcurrentHashMap、型号）不敏感
BM25：擅长精确匹配，但无法理解同义词（「心梗」搜不到「心肌梗死」）

RRF（倒数排名融合）是最主流融合策略：

RRF(d) = Σ 1/(k + rank_i(d))

输入是排名，不是分数（向量余弦和 BM25 分数量纲不同）
k=60 是 Google 论文经验值，零调参
文档只在一路出现时，另一路 rank=∞，贡献为 0

完整检索链路：

Query → 向量 Top-20 + BM25 Top-20 → RRF 融合 → Cross-Encoder Rerank → Top-5 → LLM

五、Rerank：为什么用 Cross-Encoder

双塔模型（Bi-Encoder）：Query 和 Document 各自独立编码，算余弦相似度，速度快可预计算，但没有交互，Top-K 有噪声。

Cross-Encoder：把 Query 和 Document 文本拼接[CLS] Query [SEP] Document [SEP]，Self-Attention 逐词交互，直接输出相关性分数，精度高但不能预计算。

为什么不对全部文档 Rerank？百万文档每个都要拼接算一次不可接受。先用双塔粗筛到 20 个，再 batch 精排，GPU 上几百毫秒可接受。

推荐模型：bge-reranker-v2-m3（开源，中英双语，Cross-Encoder 架构）。

六、查询改写（Pre-Retrieval）

解决用户口语化表达与文档书面化表达之间的语义鸿沟：

方法	做法	优点	缺点
LLM 改写	大模型重写规范查询	语义理解深	延迟高
同义词扩展	词典/知识图谱替换	零延迟	维护成本高
HyDE	LLM 生成假设文档，用假答案检索真答案	对齐文档分布空间	延迟最高

HyDE 反直觉但有效：用户 Query 在「问题区」，知识库文档在「陈述区」。LLM 编一个像文档的假答案，向量距离更近。容忍幻觉——只需要「像」，不需要「对」。假设文档仅用于检索，不参与最终生成。

Advanced RAG 四阶段：Pre-Retrieval（查询改写）→ Retrieval（混合检索）→ Post-Retrieval（RRF + Rerank）→ Generation（防幻觉）。

七、RAG 幻觉怎么处理

三个来源：
1. 检索噪音：chunk 含错误/过时信息
2. 过度推理：LLM 脑补缺失环节
3. 指令遵循失败：忽略约束，吐出预训练旧知

五种手段：

相似度阈值过滤：低于阈值返回「未找到」，不强行生成
交叉认证：多路检索 + 矛盾 chunk 排序
Chunk 粒度优化：语义分割 / 父子索引
约束型 Prompt：「只基于以下材料回答」+ 引用标注[chunk_id]
后置校验：NLI 模型 / LLM-as-Judge / 引用一致性检查

核心原则：不确定就说不知道。

八、GraphRAG vs 传统 RAG

传统 RAG 三个局限：
1.无法多跳推理：答案分散在不同文档，向量检索串不成逻辑链
2.缺乏结构感知：向量空间扁平，无法表达层级拓扑
3.聚合统计无能：结构化计算做不了

GraphRAG 流程：
1. LLM 抽取三元组（实体-关系-实体）
2. 入库图数据库（Neo4j）
3. Leiden 社区发现算法分层聚类，LLM 生成社区摘要
4. 查询时：图遍历做关系推理 + 向量召回兜底

缺点：构建成本高、维护难、三元组抽取可能有错。

九、知识库维护

方面	做法
增量更新	MD5/SHA-256 哈希对比，变了才重新 Embedding；先写新再删旧
删除处理	软删除`is_deleted=true`，定期物理清理超 30 天的
版本管理	chunk_id + version，支持回滚
TTL 过期	写`expire_at`，查询时过滤；Milvus 不支持自动 TTL，需应用层 cron

十、Query 路由（RAG 作为 Agent 工具时）

单一检索策略无法应对多样意图。路由解决三个问题：万金油检索样样不通、重链路成本高、无关上下文污染 LLM。

意图识别三级递进（工程最佳实践）：
1. 规则匹配（零延迟，拦截高频）
2. Embedding 相似度（预定义示例 Query 算余弦）
3. LLM 分类（兜底复杂场景）

路由分发：

意图	链路
知识问答	RAG（向量 + BM25）
代码问题	代码搜索（语法树 + 符号索引）
关系推理	GraphRAG
闲聊	直接 LLM，不检索
不确定	fallback 默认 RAG