面试知识库
极高 进阶

RAG架构与实现#

一句话答案#

RAG 流程：文档切分→Embedding→向量存储→用户查询检索→拼接上下文→LLM 生成，用外部知识增强模型回答。

核心要点

RAG 架构分**离线（建索引）和在线（检索+生成）**两阶段，工业级实现的关键在于在线侧的多步检索 Pipeline，而非简单的”检索+生成”两步。

离线阶段（建索引）：

  • 分块（Chunking）：文档切成 chunk，常用 512–1024 token，按语义边界切分避免切断上下文；进阶用 Parent-Child 分块（小块用于精确匹配、大块用于补全上下文）
  • Embedding：用 Embedding 模型（如 text-embedding-3-small）把每个 chunk 转成向量
  • 入库：向量存入向量数据库（Milvus / Pinecone），同时建关键词倒排索引（BM25）支持精确匹配

在线阶段（检索 → 生成）：

  1. 多路召回：用户 query 同时走向量检索（语义匹配）+ BM25 检索（精确关键词，补 API 名/版本号/订单号这类向量漏召的词），各取 top-K
  2. 融合（RRF）：用 Reciprocal Rank Fusion（k=60）把多路结果按排名融合成一个列表
  3. 重排（Rerank）：CrossEncoder 对融合结果精排，取 top-5（精度高但慢，所以只在小集合上做）
  4. 后处理：MMR 去冗余、Parent Chunk 扩展上下文
  5. 生成：把最终 chunk 拼进 Prompt 上下文，交给 LLM 生成回答

为什么这么设计： 检索质量决定上限——Recall 不够，生成再强也没用（garbage in, garbage out）。所以工业 RAG 把力气花在召回和排序上：向量负责”语义像”，BM25 负责”词精确”，RRF 兼顾两者，Rerank 提精度，MMR 保多样性。

进阶方向：GraphRAG（知识图谱 RAG）

  • 传统 RAG 基于文本相似度召回，多跳推理弱（“A 的上司的部门负责人是谁”召回不准），文档间隐性关系（因果、从属）无法利用
  • GraphRAG 把实体（Entity）和关系（Relation）抽成知识图谱三元组，查询时先在图谱搜子图、再把子图 + 原文档一起送 LLM；天然支持多跳推理、可解释性强、能跨文档聚合同一实体信息
  • 代价：图谱构建成本高（依赖 NLP/LLM 抽取）、维护复杂、门槛高（Neo4j / TigerGraph）
  • 取舍：一般项目用向量 RAG 足够；只有数据有明显实体关系结构（组织架构、医药知识）且需要关系推理时才上 GraphRAG
面试回答（2分钟版）

RAG即检索增强生成，核心思路是给大模型提供外部知识作为上下文来减少幻觉。整体流程分离线和在线两部分。离线部分：文档经过分块处理，常用的chunk大小是512到1024个token，通过Embedding模型比如text-embedding-3-small转成向量存入向量数据库如Milvus或Pinecone。在线部分：用户查询同样做Embedding，在向量库中做相似度检索召回TopK相关文档块，把这些块拼接到Prompt的上下文中交给LLM生成回答。传统RAG基于语义相似度召回，对多跳推理类问题效果不好，比如”A的上司的部门负责什么”这种关系链查询。GraphRAG的思路是把文档中的实体和关系抽取成知识图谱三元组，查询时先在图谱中做子图搜索再把子图加原文档一起送给LLM，天然支持多跳推理且可解释性强。实际项目中一般先用向量RAG，数据有明显实体关系结构比如组织架构或医药知识才考虑GraphRAG。

追问与易错

追问方向：

  • 纯向量检索为什么不够？什么场景必须加关键词检索？ → 向量检索擅长语义匹配但漏掉精确关键词（API 名、版本号、订单号）。BM25 补充精确匹配，DocMind 混合后 Recall@5 提升 +0.20
  • GraphRAG 和传统 RAG 的权衡？什么时候值得引入知识图谱？ → GraphRAG 支持多跳推理但图谱构建成本高。只有数据有明确实体关系结构（组织架构、医药知识）且需要关系推理时才值得
  • 你们的 RAG Pipeline 具体怎么搭的？每个环节的参数怎么调？ → Vector(top-50) + BM25(top-50) → RRF(k=60) → Rerank(top-5) → MMR 去重 → Parent Chunk 扩展。参数通过离线评测 A/B 对比调优
  • 检索质量差的时候怎么排查？从哪里开始查？ → 从上游往下查：先看分块质量（chunk 是否切断语义）→ Embedding 质量（语义是否准确）→ 召回数量（top-K 是否够）→ 重排效果（Rerank 是否误排）

易错点：

  • ❌ 认为 RAG 就是”检索+生成”两步 → 完整 Pipeline 包括分块、Embedding、多路召回、融合、重排、后处理，每步都影响最终质量
  • ❌ 不考虑检索质量对生成质量的影响 → 检索阶段 Recall 不够，后面怎么优化生成都没用（garbage in, garbage out）
  • ❌ 忽略增量更新 → 文档更新后向量必须同步，否则检索到过时内容更危险

项目实践（DocMind）： 六步 Pipeline：Vector 检索（Milvus HNSW, COSINE, top-50）+ BM25 检索（MySQL FULLTEXT + Lucene SmartCN, top-50）→ RRF 融合（k=60）→ CrossEncoder Rerank（DashScope gte-rerank, top-5）→ MMR 去重（λ=0.7, bigram Jaccard）→ Parent Chunk 扩展（sub-chunk 400字匹配→parent 1500字上下文）。评测数据：事件类查询 Recall@5 从 0.73（纯向量）→ 0.93（+BM25 融合），提升 +0.20 完全来自 BM25 贡献。