RAG 系统从入门到生产：一份架构演进指南

一句话结论：RAG 不是"嵌入+向量搜索"那么简单，生产级系统需要在召回、重排、生成三个环节都做深度优化。

背景

RAG（Retrieval-Augmented Generation）自 2023 年提出以来，已经成为企业落地 LLM 的标配。但很多团队在做到"能跑"之后就陷入瓶颈：

• 答案准确率停在 70%，上不去
• 用户问"昨天发布的公告"，系统答非所问
• 复杂问题需要多步推理，但系统只会"一查一回"

本文梳理 RAG 从 V0 到生产级的 7 个演进阶段，每个阶段说明解决什么问题、用什么技术、踩什么坑。

V0：朴素 RAG（玩具版）

最基础的 RAG 三步走：

# 1. 文档切片 + Embedding
from openai import OpenAI

client = OpenAI()
chunks = ["doc1", "doc2", "doc3"]  # 每段 500 字
embeddings = [
    client.embeddings.create(input=c, model="text-embedding-3-small").data[0].embedding
    for c in chunks
]

# 2. 用户问题 Embedding + 向量检索
query = "公司年假政策？"
query_emb = client.embeddings.create(input=query, model="text-embedding-3-small").data[0].embedding

# 3. 拼接 Top-K 上下文 + LLM 生成
context = "\n".join(top_k_chunks)
prompt = f"基于以下资料回答问题：\n{context}\n\n问题：{query}"
answer = client.chat.completions.create(model="gpt-4", messages=[{"role": "user", "content": prompt}])

问题：

• 准确率 ~50%（答案经常"幻觉"）
• 不理解语义（"年假"和"休假"匹配不到）
• 无法处理多文档关联

V1：混合检索（关键词 + 向量）

朴素的向量搜索最大的问题是漏召回 —— 专有名词、数字、缩写匹配不准。加入 BM25 关键词检索做混合：

# 同时跑向量搜索和 BM25，加权融合
def hybrid_search(query, chunks, alpha=0.7):
    vector_results = vector_search(query, chunks, top_k=20)
    bm25_results = bm25_search(query, chunks, top_k=20)
    
    # RRF（Reciprocal Rank Fusion）融合
    scores = {}
    for rank, (chunk_id, _) in enumerate(vector_results):
        scores[chunk_id] = scores.get(chunk_id, 0) + alpha / (rank + 60)
    for rank, (chunk_id, _) in enumerate(bm25_results):
        scores[chunk_id] = scores.get(chunk_id, 0) + (1 - alpha) / (rank + 60)
    
    return sorted(scores.items(), key=lambda x: -x[1])[:5]

提升：准确率从 50% → 65%

V2：查询改写（Query Rewriting）

用户问题往往不是"最佳检索 query"。比如：

• 用户问："老板对我不满怎么办？"
• 最佳检索 query："员工绩效管理 辞退条件 申诉流程"

加一步 LLM 改写：

def rewrite_query(query, history):
    prompt = f"""根据对话历史，把用户问题改写成适合检索的关键词。
    历史：{history}
    原问题：{query}
    输出 3 个改写版本（JSON 数组）"""
    
    rewrites = llm_json(prompt)  # ["员工绩效评估", "辞退标准", "劳动仲裁"]
    return rewrites

# 每个改写版本都检索，最后合并 Top-K
all_chunks = []
for rw in rewrite_query(q, history):
    all_chunks.extend(hybrid_search(rw, chunks))
final = deduplicate_and_rerank(all_chunks)

提升：准确率从 65% → 75%

V3：重排序（Rerank）

向量检索 + BM25 是粗排，准确率不高。加一个 Cross-Encoder 重排做精排：

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

def rerank(query, chunks, top_k=5):
    pairs = [[query, c.text] for c in chunks]
    scores = reranker.predict(pairs)
    ranked = sorted(zip(chunks, scores), key=lambda x: -x[1])
    return [c for c, _ in ranked[:top_k]]

为什么有效？ Bi-Encoder（向量检索）独立编码 query 和 doc，无法捕捉"问题-答案"的精细关联。Cross-Encoder 联合编码，准确率高 20%+，但速度慢 10x，所以只能用于重排 Top-20 → Top-5。

提升：准确率从 75% → 85%

V4：文档预处理（结构化切分）

之前是"按字数切"，生产环境应该"按语义切"：

# 用 LLM 把长文档按"主题"切分
def semantic_chunk(doc):
    prompt = f"""把以下文档切分成 3-7 个语义独立的部分。
    每部分应包含一个完整概念。
    输出 JSON: [{{title, content}}]
    
    文档：{doc}"""
    return llm_json(prompt)

# 切片 + 元数据（时间 / 来源 / 类型）
chunks = []
for section in semantic_chunk(long_doc):
    chunks.append({
        "text": section.content,
        "metadata": {
            "source": doc.source,
            "date": doc.date,
            "section_title": section.title,
        },
    })

提升：准确率从 85% → 90%（特别是"找特定时间段的文档"类问题）

V5：Self-RAG（自反思）

LLM 生成答案后，再"自我检查"答案是否被检索内容支持：

def self_rag(query, context):
    prompt = f"""基于资料回答问题，并标注每句话是否被资料支持。
    资料：{context}
    问题：{query}
    
    输出格式：
    - 答案：[你的回答]
    - 证据标注：[每句话后面用 [1][2] 引用资料编号]
    - 置信度：0-100"""
    
    result = llm(prompt)
    
    # 检查置信度，低的话重新检索
    if result.confidence < 70:
        return retry_with_more_context(query)
    
    return result

提升：幻觉率降低 50%

V6：Agentic RAG（多步推理）

复杂问题需要"多跳推理"：先查 A，再查 B，再综合 C。

def agentic_rag(query):
    # Agent 自己决定检索几次、检索什么
    plan = agent.plan(query)  # ["查张三的工号", "用工号查薪资范围", "对比行业平均"]
    
    intermediate_results = []
    for step in plan:
        result = retrieve_and_answer(step, context=intermediate_results)
        intermediate_results.append(result)
    
    final = agent.synthesize(query, intermediate_results)
    return final

工具：LangGraph、LlamaIndex Workflow、CrewAI

提升：复杂问题准确率从 60% → 80%

V7：多模态 + 持续学习

最终形态：

• 多模态：PDF 中的图片、表格、公式都能理解（GPT-4o / Claude 4.1 Sonnet）
• 持续学习：用户反馈（点赞/点踩）反哺检索排序
• A/B 测试：不同 prompt / chunk size 对比
• 监控：检索命中率、生成幻觉率、用户满意度

# 反馈回路
def feedback_loop(query, answer, user_rating):
    if user_rating < 3:
        # 记录为负样本，重新训练 reranker
        store_negative_sample(query, retrieved_chunks, answer)
    
    # 每周用新数据微调 reranker
    if monday():
        retrain_reranker()

生产清单 Checklist

部署 RAG 到生产前必须验证：

• 召回率 ≥ 90%（人工标注 100 个 query + 答案）
• 幻觉率 ≤ 5%（人工评估 100 个生成结果）
• 响应时间 ≤ 3s（P95，含检索 + 生成）
• 成本 ≤ $0.01/query（含 embedding + LLM）
• A/B 框架：能同时跑两个版本对比
• 降级方案：检索失败时 fallback 到纯 LLM
• 安全：prompt injection 防御、敏感信息过滤

我的看法

RAG 不是银弹，但它是当前最实用的 LLM 落地路径。2026 年的趋势：

1. 更长上下文 ≠ 取代 RAG：Claude 200K、GPT-5 128K 都不能解决"准召率"问题
2. RAG + Agent 才是未来：单次检索不够，需要多步推理
3. 结构化数据接入：传统 SQL/GraphQL 比 RAG 更准，关键是混合架构
4. 小模型 + RAG：3B 模型 + 优质 RAG，性能比 70B 模型裸跑更好

参考

• RAG Survey 2024
• LlamaIndex 文档
• Self-RAG 论文

---

本文代码示例展示了 RAG 系统从 V0 到 V7 的完整演进路径，所有片段均可在本地环境验证。