RAG（检索增强生成）是人工智能领域解决大模型幻觉问题的核心方案。通过将外部知识库与AIGC应用结合，RAG系统能够在大模型生成回答前，从向量数据库中检索相关文档片段，将其作为上下文注入Prompt，从而提升回答准确性。本文从向量数据库选型、文本分块、Embedding配置到Prompt工程，完整拆解RAG系统的搭建流程。

RAG系统架构与向量数据库选型

RAG系统的核心链路包括文档预处理、向量化存储、语义检索和增强生成四个阶段。文档经过分块后通过Embedding模型转为向量，存入向量数据库；用户查询同样向量化后，在数据库中做相似度检索，匹配到的文本片段拼入Prompt交由大模型生成回答。

向量数据库选型直接影响检索效果和系统吞吐。主流方案对比：

• Milvus：支持十亿级向量检索，分布式架构，适合大规模生产环境
• Chroma：轻量级方案，单机部署，适合中小型项目和原型验证
• Weaviate：内置多模态检索能力，支持GraphQL查询接口
• Qdrant：Rust实现，内存占用低，支持高效过滤

以Milvus为例，Docker部署配置如下：

version: '3.5'
services:
  etcd:
    image: quay.io/coreos/etcd:v3.5.5
    environment:
      - ETCD_AUTO_COMPACTION_MODE=revision
      - ETCD_AUTO_COMPACTION_RETENTION=1000
    volumes:
      - etcd_data:/etcd
    command: etcd -advertise-client-urls=http://127.0.0.1:2379 -listen-client-urls http://0.0.0.0:2379

  milvus:
    image: milvusdb/milvus:v2.4.0
    ports:
      - "19530:19530"
    depends_on:
      - etcd
    environment:
      ETCD_ENDPOINTS: etcd:2379

volumes:
  etcd_data:

文本分块策略与Embedding模型配置

文档分块质量直接决定检索精度。分块过大会引入噪声，分块过小则丢失上下文。常见策略包括固定长度分块、按段落分块、语义分块三种。

固定长度分块实现示例：

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=64,
    separators=["\n\n", "\n", "。", "！", "？", "；", " ", ""]
)

chunks = splitter.split_text(document_text)
print(f"分块数量: {len(chunks)}")

chunk_overlap参数设置重叠区域，避免语义在分块边界被截断。中文文档建议按句号、问号等标点作为分隔符优先级。

Embedding模型选择需平衡效果和成本。开源方案推荐bge-large-zh-v1.5，中文检索效果好；商业API如OpenAI text-embedding-3-small延迟低但存在数据出境问题。AI模型部署阶段需评估推理延迟：

from sentence_transformers import SentenceTransformer
from pymilvus import Collection, FieldSchema, CollectionSchema, DataType

model = SentenceTransformer('BAAI/bge-large-zh-v1.5')
embeddings = model.encode(chunks, normalize_embeddings=True)

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)
]
schema = CollectionSchema(fields, "RAG knowledge base")
collection = Collection("knowledge_base", schema)
collection.insert([embeddings.tolist(), chunks])

# 创建IVF索引加速检索
collection.create_index(
    "embedding",
    {"index_type": "IVF_FLAT", "metric_type": "IP", "params": {"nlist": 128}}
)

检索增强生成的Prompt工程实践

Prompt工程在RAG系统中的作用是规范大模型的回答行为。检索到的文档片段需要以结构化方式注入Prompt，同时设置防护指令避免模型输出无关内容。

Prompt模板设计：

prompt_template = """请根据以下检索到的资料回答问题。
如果资料中没有相关信息，直接回答"根据现有资料无法回答该问题"，不要编造内容。

检索资料：
{context}

问题：{question}

回答要求：
1. 仅使用检索资料中的信息
2. 回答简洁准确
3. 如涉及具体数据，标注来源文档
"""

检索环节引入重排序（Reranker）可显著提升相关性。先用向量检索召回Top-20候选，再用Cross-Encoder模型做精排，取Top-5注入Prompt：

from sentence_transformers import CrossEncoder

reranker = CrossEncoder('BAAI/bge-reranker-large')
pairs = [[query, doc] for doc in candidate_docs]
scores = reranker.predict(pairs)
ranked_docs = [doc for _, doc in sorted(zip(scores, candidate_docs), reverse=True)][:5]

RAG系统部署与性能优化

生产环境部署RAG系统需要考虑并发、缓存和监控。自然语言处理场景下，Embedding推理和LLM生成是两个主要瓶颈。

性能优化要点：

• Embedding模型用GPU批量推理，单次批量大小设为64-128
• 检索结果缓存：对高频查询的检索结果做Redis缓存，TTL设为30分钟
• 异步流式输出：LLM回答用SSE流式返回，降低首字节延迟
• Milvus索引选IVF_FLAT或HNSW，nprobe参数调优平衡召回率和延迟

系统监控需关注检索命中率、回答延迟、LLM token消耗三个核心指标。Prometheus采集Milvus和LLM网关的metrics，Grafana设置告警阈值。检索命中率低于60%时需检查分块策略和Embedding模型质量。

RAG系统的迭代方向包括多路召回（向量+关键词+知识图谱）、自适应检索（根据查询复杂度动态调整检索深度）和自纠错机制（LLM判断检索结果是否充分，不足时触发二次检索）。这些进阶能力构成了AIGC应用从原型到生产的工程化路径。

什么是RAG系统及其核心组件

RAG（Retrieval-Augmented Generation，检索增强生成）是大模型开发中解决幻觉问题的主流方案。大模型训练数据存在截止日期，面对私有知识库或最新信息时容易生成错误内容。RAG通过在生成前检索外部知识库，将相关文档片段注入Prompt上下文，使模型基于事实回答。一个完整的RAG系统包含三个核心环节：文档处理与向量化、相似度检索、生成回答。

向量数据库选型：Milvus与Chroma对比

向量数据库负责存储文档的Embedding向量并支持高效相似度搜索。主流方案包括Milvus、Chroma、Weaviate和Qdrant。Milvus适合大规模生产环境，支持十亿级向量检索；Chroma轻量易用，适合原型验证和中小规模场景。

以Docker部署Milvus单机版为例：

docker run -d --name milvus-standalone \
  -p 19530:19530 -p 9091:9091 \
  -v /data/milvus:/var/lib/milvus \
  milvusdb/milvus:latest \
  milvus run standalone

使用Python SDK创建Collection：

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

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

fields = [
    FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
    FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1536),
    FieldSchema(name="content", dtype=DataType.VARCHAR, max_length=2048),
    FieldSchema(name="source", dtype=DataType.VARCHAR, max_length=256)
]
schema = CollectionSchema(fields, description="RAG knowledge base")
collection = Collection("rag_docs", schema)

# 创建IVF_FLAT索引
collection.create_index(
    field_name="embedding",
    index_params={
        "index_type": "IVF_FLAT",
        "metric_type": "COSINE",
        "params": {"nlist": 1024}
    }
)

Embedding模型部署与文档处理流程

Embedding模型将文本转化为向量，直接影响检索质量。开源方案推荐使用BGE-M3（支持中英文，1024维）或text2vec-base-chinese。生产环境可通过Text Embeddings Inference（TEI）服务部署：

docker run -d --name tei -p 8080:80 \
  -v /data/models:/data \
  ghcr.io/huggingface/text-embeddings-inference:cpu-1.5 \
  --model-id BAAI/bge-m3 --port 8080

文档处理流程分为四个步骤：

第一步：文档加载。使用LangChain的文档加载器读取PDF、Word、Markdown等格式文件。对于大型PDF，建议用unstructured库解析，保留段落结构。

第二步：文本分块。将长文档切分为固定长度的chunk，推荐512-1024个token，重叠50-100个token防止语义截断。分块策略影响检索精度，过短丢失上下文，过长稀释相关性信号。

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=80,
    separators=["\n\n", "\n", "。", "！", "？", "；", " ", ""]
)
chunks = splitter.split_text(document_text)

第三步：向量化与入库。对每个chunk调用Embedding API生成向量，连同原始文本和元数据写入向量数据库。批量插入建议每批500-1000条，避免单次请求过大。

第四步：检索测试。输入测试Query，验证Top-K召回结果的相关性。K值通常设为3-5，过低遗漏信息，过高引入噪声。

Prompt工程：检索结果与用户问题的融合策略

Prompt工程在RAG系统中起到桥梁作用。检索到的文档片段需要以合理方式拼接到Prompt中，引导模型基于上下文回答而非依赖自身参数知识。

推荐Prompt模板结构：

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

参考资料：
{context}

用户问题：{question}

要求：
1. 仅基于参考资料内容回答，不要编造信息
2. 如果参考资料中没有相关内容，明确告知用户
3. 回答时标注信息来源
"""

实际项目中常见的Prompt优化技巧：

角色设定：在Prompt开头指定模型角色（如”你是一名技术文档助手”），约束回答风格和领域范围。

引用标注：要求模型在回答中标注引用的文档编号，便于用户追溯信息来源。可通过在context中为每个chunk编号实现。

多轮对话处理：用户追问可能涉及上文，需要将对话历史纳入检索Query重写。使用LLM对用户问题进行改写，补充上下文信息后再检索：

def rewrite_query(chat_history, user_question):
    rewrite_prompt = f"""根据对话历史，将用户最新问题改写为独立、完整的检索query。

    对话历史：{chat_history}
    用户问题：{user_question}
    改写后的query："""
    return llm.generate(rewrite_prompt)

AI模型部署：推理服务架构设计

RAG系统的生成端依赖大语言模型推理服务。开源模型（如Qwen2.5-72B、DeepSeek-V3）可通过vLLM或TGI部署，提供OpenAI兼容的API接口。

vLLM部署示例：

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-32B-Instruct \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192 \
  --port 8000

生产环境需要考虑以下因素：并发请求队列管理、GPU显存动态分配、请求超时与重试、输出Token长度限制。建议在推理服务前端部署Nginx做负载均衡，后端多实例部署提升吞吐量。

RAG系统评估指标与调优方向

RAG系统的效果评估分为检索质量和生成质量两个维度。检索质量用Recall@K（前K条结果中包含正确答案的比例）和MRR（平均倒数排名）衡量。生成质量用Faithfulness（回答是否忠于检索内容）和Answer Relevance（回答与问题的相关性）评估，可借助RAGAS框架自动化评测。

调优时优先排查检索阶段：如果召回的chunk与问题无关，问题出在Embedding模型或分块策略；如果检索准确但回答错误，问题在Prompt设计或模型能力。常见优化手段包括混合检索（向量+关键词BM25）、重排序（Cross-Encoder rerank）、元数据过滤（按文档类型、时间范围筛选）。

智能对话系统中集成RAG还需处理意图识别。用户问题可能不是知识查询，而是闲聊或操作指令。在检索前加入意图分类模块，对非知识类问题直接路由到对应处理逻辑，避免无意义的向量检索开销。