RAG技术架构核心组件与工作流程解析
检索增强生成（Retrieval-Augmented Generation，RAG）是大模型落地企业场景的主流架构方案。纯大模型存在知识截止、幻觉频发、领域数据缺失等问题，RAG通过外部知识库检索为生成阶段注入实时、可溯源的上下文信息，显著提升回答准确性与可信度。一个完整的RAG系统包含文档解析与切片、向量化嵌入、向量存储与检索、大模型生成四个核心阶段。
文档处理与文本切片策略对比
文档入库前的处理质量直接影响检索效果。PDF、Word、Markdown等格式需要不同的解析方案——PDF用PyMuPDF提取文本和表格，Markdown用正则按标题层级拆分，Word用python-docx读取段落。切片策略分为三种：
# 固定长度切片（最简单，适合入门）
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=512,
chunk_overlap=64,
separators=["\n\n", "\n", "\u3002", "\uff0c", " "]
)
chunks = splitter.split_text(document_text)
# 语义切片（按语义边界分割，效果更好）
from langchain.text_splitter import NLTKTextSplitter
semantic_splitter = NLTKTextSplitter(chunk_size=512)固定长度切片实现简单但会截断语义边界；语义切片依赖NLP分句，效果好但处理速度慢；基于标题层级的切片保留文档结构，适合技术文档场景。实际项目中推荐RecursiveCharacterTextSplitter作为起点，chunk_overlap设置50-128字符避免关键信息被截断。
嵌入模型选型与向量化实践
嵌入模型将文本转换为高维向量，选型需平衡效果与成本。主流方案对比：
OpenAI text-embedding-3-small：1536维，MTEB排名靠前，API调用简单，延迟约100ms，适合快速验证。BGE-M3（BAAI）：1024维，开源权重，支持多语言，本地部署无调用成本，适合数据敏感场景。GTE-Qwen2（阿里巴巴）：最近发布的开源模型，中文效果突出，8192 token长文本支持。Cohere embed-v3：多语言表现优异，自带压缩维度功能。
# 使用BGE-M3本地嵌入
from FlagEmbedding import BGEM3FlagModel
model = BGEM3FlagModel('BAAI/bge-m3', use_fp16=True)
embeddings = model.encode(
["RAG系统架构设计", "向量数据库选型对比"],
return_dense=True,
return_sparse=True
)
# dense_embeddings: (2, 1024) 密集向量
# sparse_embeddings: 稀疏词汇权重，用于混合检索嵌入维度越高存储成本越大，但语义表达能力更强。512维适合对精度要求不高的场景，1024-1536维是当前主流选择。长文档场景优先选支持8192 token的模型，避免切片过碎导致语义丢失。
向量数据库选型与性能调优
向量数据库是RAG系统的存储与检索核心，选型考量维度包括：数据规模、查询延迟、过滤能力、运维复杂度、成本。
Milvus：开源方案，支持十亿级向量，GPU加速索引构建，适合大规模生产环境。单机部署用milvus-lite，集群用milvus-helm。Weaviate：内置向量化和GraphQL查询，开发体验好，适合中小规模快速迭代。Qdrant：Rust编写，内存效率高，支持过滤+向量混合查询，单节点百万级向量场景表现优异。Chroma：最轻量，pip install即用，适合原型验证，但不适合生产环境。pgvector：PostgreSQL扩展，适合已有PG基础设施的团队，过滤查询与关系查询天然结合。
# Milvus混合检索示例（密集+稀疏）
from pymilvus import MilvusClient, AnnSearchRequest
client = MilvusClient("milvus_demo.db")
# 创建支持密集+稀疏的Collection
client.create_collection(
collection_name="rag_docs",
dimension=1024, # 密集向量维度
metric_type="IP",
auto_id=True
)
# 混合检索：密集向量 + BM25稀疏
search_param_1 = {"data": query_dense, "anns_field": "dense_vector", "param": {"metric_type": "IP"}}
search_param_2 = {"data": query_sparse, "anns_field": "sparse_vector", "param": {"metric_type": "IP"}}
results = client.hybrid_search(
collection_name="rag_docs",
reqs=[AnnSearchRequest(**search_param_1), AnnSearchRequest(**search_param_2)],
ranker=RRFRanker(k=60), # 倒数排名融合
limit=10
)检索策略优化与重排序机制
基础向量检索召回率有限，工业级RAG系统普遍采用多路召回+重排序的两阶段架构：
第一阶段：并行执行密集向量检索、稀疏检索（BM25/SPLADE）、关键词检索，各路召回top-K候选。第二阶段：用Cross-Encoder重排序模型对候选文档精排，输出最终top-N送入大模型。重排序模型如bge-reranker-v2-m3、Cohere Rerank，对召回结果重新打分排序，显著提升相关性。
from FlagEmbedding import FlagReranker
reranker = FlagReranker('BAAI/bge-reranker-v2-m3', use_fp16=True)
# 对召回结果重排序
pairs = [[query, doc] for doc in retrieved_docs]
scores = reranker.compute_score(pairs)
ranked_docs = [doc for _, doc in sorted(zip(scores, retrieved_docs), reverse=True)]实际测试中，加入重排序后回答准确率可提升15-30%。重排序模型推理耗时约50-200ms/对，需控制候选文档数量在50以内避免延迟过大。
生成阶段Prompt工程与幻觉控制
检索到的上下文送入大模型时，Prompt设计决定最终输出质量。核心原则：明确区分上下文与用户问题、要求模型标注信息来源、禁止编造上下文中不存在的内容。
RAG_PROMPT = """请基于以下检索到的上下文信息回答用户问题。
如果上下文中没有包含回答问题所需的信息，请明确说明"根据现有资料无法回答"。
不要编造或推测上下文中未提及的内容。
上下文：
{context}
用户问题：{question}
请提供准确、完整的回答，并标注信息出自哪段上下文。"""幻觉控制策略：设置temperature=0.1降低随机性；在System Prompt中强调”只使用检索到的信息”；后处理阶段用自检模型验证回答与上下文一致性；对关键业务场景增加人工审核环节。
生产环境部署架构与监控体系
RAG系统上线需要考虑缓存、限流、监控三方面。缓存层用Redis缓存热点query的embedding和检索结果，命中率30-50%可显著降低向量库压力。限流用令牌桶控制并发请求，避免向量库过载。监控指标包括：检索召回率、重排序后top-5命中率、端到端延迟P99、大模型生成token数、用户反馈正确率。
文档更新策略：全量重建适合文档变更频率低的场景；增量插入适合实时数据流；版本管理对每个文档维护hash值，变更时只更新差异部分，避免全量重建。
原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/rag-jian-suo-zeng-qiang-sheng-cheng-xi-tong-jia-gou-she-ji/
