大模型开发实战：从零搭建RAG检索增强生成系统的完整流程

RAG系统为什么成为大模型落地的标配方案

大模型在企业场景中最大的痛点是幻觉问题和知识时效性不足。RAG（Retrieval-Augmented Generation）通过外挂知识库的方式，让模型在生成回答前先检索相关文档片段，把准确的事实信息注入上下文，从根本上降低幻觉率。对比纯微调方案，RAG无需重新训练模型，知识库更新只需重新索引，迭代周期从周级缩短到分钟级。

一个完整的RAG系统包含四个核心模块：文档解析与切分、向量嵌入与索引构建、语义检索与重排序、大模型生成与后处理。每个模块的配置直接影响最终效果，下面逐个拆解。

文档解析与语义切分的工程细节

文档解析是整个链路的第一步，也是最容易被忽视的环节。PDF、Word、Markdown等格式的解析质量差异极大，表格和代码块的丢失会直接导致检索盲区。

推荐使用unstructured或pymupdf进行解析，对中文文档pymupdf的表格保留效果更好。切分策略上，固定字符数切分是最差的选择——会截断语义完整的段落。按段落+重叠窗口切分是工程实践中的平衡方案：

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=64,
    separators=["\n\n", "\n", "。", "；", "，", " "],
    length_function=len
)
chunks = splitter.split_text(document_text)
print(f"文档切分为 {len(chunks)} 个片段")

chunk_size设512而不是更小的256，是因为过短的片段会丢失上下文语义，导致检索命中率下降。重叠窗口64字符确保相邻片段有语义衔接。separators的优先级确保优先在段落边界切分，而不是在句子中间硬切。

向量嵌入模型选型与索引构建

嵌入模型直接决定检索质量的上限。bge-large-zh-v1.5在中文场景的MTEB评测中表现稳定，bge-m3支持多语言且兼顾稠密和稀疏检索。如果对延迟敏感，bge-small-zh-v1.5体积小推理快，适合在线服务。

向量数据库选型看数据规模：百万级以下用FAISS本地索引足够，千万级以上需要Milvus或Qdrant分布式方案。以Milvus为例：

from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType

connections.connect(host="localhost", port=19530)

fields = [
    FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
    FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1024),
    FieldSchema(name="text", dtype=DataType.VARCHAR, max_length=4096),
    FieldSchema(name="source", dtype=DataType.VARCHAR, max_length=512)
]
schema = CollectionSchema(fields, description="RAG知识库索引")
collection = Collection("rag_knowledge", schema)

# 创建IVF_FLAT索引，平衡召回率和速度
index_params = {
    "metric_type": "IP",
    "index_type": "IVF_FLAT",
    "params": {"nlist": 1024}
}
collection.create_index(field_name="embedding", index_params=index_params)

metric_type用IP（内积）而非L2，因为归一化后的内积等价于余弦相似度，计算更快。nlist设1024对应百万级数据的合理聚类数，数据量翻十倍时nlist也应相应增大。

语义检索与重排序的配置要点

纯向量检索存在语义漂移问题——top-k结果中常有看似相关但实际答非所问的片段。加入BM25稀疏检索做混合召回，再用Cross-Encoder重排序，是工程落地的标配做法：

from rank_bm25 import BM25Okapi
from sentence_transformers import CrossEncoder

# 混合检索：向量top-20 + BM25 top-10
vector_results = collection.search(
    query_embedding, "embedding", param={"metric_type": "IP", "params": {"nprobe": 32}},
    limit=20, output_fields=["text", "source"]
)
bm25_results = bm25.get_top_n(tokenized_query, corpus, n=10)

# 合并去重后用Cross-Encoder重排序
cross_encoder = CrossEncoder("BAAI/bge-reranker-v2-m3")
candidates = list(set(vector_results + bm25_results))
pairs = [(query, doc.text) for doc in candidates]
scores = cross_encoder.predict(pairs)
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)[:5]

nprobe=32在IVF索引中每查询扫描32个桶，召回率和延迟的平衡点在大多数场景下落在这个值附近。重排序取top-5送入大模型上下文，5个片段约2500字，加上query和指令，控制在4K token以内。

大模型Prompt设计与幻觉抑制

RAG的Prompt工程核心原则：明确告知模型只基于检索内容回答，不依赖自身记忆。一个经过验证的Prompt模板：

RAG_PROMPT = """请基于以下检索到的参考资料回答用户问题。

要求：
1. 只使用参考资料中的信息，不要编造或推测
2. 如果参考资料不足以回答问题，直接说明"现有资料无法完整回答该问题"
3. 引用具体来源时标注[来源：xxx]

参考资料：
{context}

用户问题：{question}

回答："""

这个模板的三个要求分别解决幻觉、拒答和可追溯性。实际部署中还可以加入引用标注和事实核验环节，对模型输出做后处理，抽取出处与原文比对，标记无依据的陈述。

RAG系统的性能调优与监控指标

RAG系统上线后需要持续监控三个核心指标：检索召回率（Recall@K）、答案准确率（Faithfulness）和端到端延迟。召回率通过人工标注query-doc对定期评测；准确率用LLM-as-Judge自动评估答案是否忠实于检索片段；延迟关注P95而非均值。

常见瓶颈及解法：检索召回率低于80%时，优先检查切分策略和嵌入模型质量；答案准确率低但召回率高，问题在Prompt设计或模型能力不足；延迟高则优化索引参数或引入缓存层，对高频query做语义缓存。

RAG不是银弹，但在知识密集型场景中，它是最快能让大模型从演示走向生产的技术路径。把每个环节的配置细节做好，系统效果会有质的提升。