RAG（检索增强生成）是当前企业级大模型应用中最核心的技术架构。本文深入剖析 RAG 的工程化细节，覆盖从原理理解到生产部署的全流程。
一、为什么企业级应用离不开 RAG？
大语言模型（LLM）天生存在两个致命缺陷：
- 知识截止：训练数据有时效性，无法感知最新信息
- 幻觉问题：模型倾向于"编造"看似合理的答案
RAG 通过"先检索、后生成"的范式，将外部知识动态注入 LLM 的上下文，从根本上解决这两个问题。这也是为什么几乎所有企业知识库、智能客服、文档问答系统都以 RAG 为核心。
二、RAG 核心架构拆解
基础架构（Naive RAG）
离线阶段：
原始文档 → 文本切片 → Embedding 向量化 → 存入向量数据库
在线阶段：
用户问题 → Query Embedding → 向量检索（Top-K） → 召回文档 → 拼接 Prompt → LLM 生成答案
这是最基础的 RAG 流程，但在生产环境中直接使用往往效果不佳。原因在于：
- 文本切片策略不合理，导致语义被截断
- 向量检索召回精度不足
- 检索结果与问题相关性排序混乱
进阶架构（Advanced RAG）
1. 文档预处理优化
# 不好的切片方式：固定长度切片
chunks = [text[i:i+512] for i in range(0, len(text), 512)]
# 更好的方式：按语义边界切片
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=512,
chunk_overlap=50, # 重叠区域保留上下文连贯性
separators=["\n\n", "\n", "。", "！", "？", " "]
)
chunks = splitter.split_text(text)
2. 混合检索（Hybrid Search）
单一向量检索对精确匹配（如专有名词、代码片段）效果较差。混合检索结合向量检索和 BM25 关键词检索，互补提升召回质量：
# 向量检索捕捉语义相似性
vector_results = vector_store.similarity_search(query, k=5)
# BM25 检索捕捉关键词精确匹配
bm25_results = bm25_retriever.get_relevant_documents(query)
# 使用 RRF（Reciprocal Rank Fusion）融合两路结果
final_results = reciprocal_rank_fusion([vector_results, bm25_results])
3. 重排序（Reranking）
召回 Top-K 文档后，使用交叉编码器（Cross-Encoder）对 Query 和每个文档进行精细相关性打分，重新排序后只取 Top-N 注入 LLM：
from sentence_transformers import CrossEncoder
reranker = CrossEncoder("BAAI/bge-reranker-large")
# 批量打分
scores = reranker.predict([(query, doc.page_content) for doc in retrieved_docs])
# 按分数重排
reranked_docs = sorted(zip(retrieved_docs, scores), key=lambda x: x[1], reverse=True)
top_docs = [doc for doc, score in reranked_docs[:3]]
模块化架构（Modular RAG）
生产环境的 RAG 系统往往需要更灵活的架构设计：
| 模块 | 功能 | 常用实现 |
|---|---|---|
| 查询改写 | 将用户模糊问题改写为检索友好格式 | LLM 辅助改写、HyDE |
| 多路检索 | 同时检索多个知识库或使用多种策略 | LangChain MultiRetriever |
| 上下文压缩 | 过滤召回文档中与问题无关的内容 | LLMChainExtractor |
| 答案验证 | 检测生成答案是否有幻觉 | RAGAS 评估框架 |
三、向量数据库选型指南
| 数据库 | 适用场景 | 特点 |
|---|---|---|
| Chroma | 本地开发、原型验证 | 零配置，Python 原生，不适合生产 |
| Milvus | 生产环境、大规模数据 | 分布式，高性能，支持亿级向量 |
| Qdrant | 中小规模生产 | Rust 实现，内存效率高，REST API 友好 |
| pgvector | 已有 PostgreSQL 栈 | 无需引入新组件，SQL 语法操作向量 |
| Weaviate | 需要混合检索 | 原生支持向量 + 关键词混合检索 |
选型建议：
- 快速原型 → Chroma
- 生产 + 大数据量 → Milvus
- 生产 + 已有 PG 基础设施 → pgvector
四、RAG 评估体系（RAGAS）
不能评估的系统无法优化。RAGAS 是目前最主流的 RAG 评估框架：
from ragas import evaluate
from ragas.metrics import (
faithfulness, # 答案是否忠实于检索内容（防幻觉）
answer_relevancy, # 答案是否回答了用户问题
context_recall, # 检索是否覆盖了正确答案所需的信息
context_precision, # 检索内容中有用信息的比例
)
result = evaluate(
dataset,
metrics=[faithfulness, answer_relevancy, context_recall, context_precision]
)
print(result)
四个核心指标解读：
- Faithfulness：衡量答案是否有"凭空编造"，越高越好
- Answer Relevancy：衡量答案是否真正回答了问题
- Context Recall：衡量检索是否遗漏了关键信息
- Context Precision：衡量检索结果的"噪声"比例
五、生产部署最佳实践
1. 异步处理：文档 Embedding 入库使用异步批处理，避免阻塞 2. 缓存层：对高频查询的向量检索结果做 Redis 缓存 3. 降级策略：向量数据库故障时，降级到 BM25 纯关键词检索 4. 监控告警：追踪 P99 检索延迟、答案质量指标趋势 5. 增量更新：新文档实时 Embedding 入库，避免全量重建
六、总结
RAG 看似简单，但工程化落地的每个环节都有大量细节。从 Naive RAG 到生产级 RAG，核心差距在于：文档处理质量、检索策略多样性、重排序机制、以及持续的评估与优化闭环。
掌握这套完整的 RAG 工程体系，是成为真正有价值的大模型应用开发工程师的核心路径之一。
标签：RAG | 检索增强生成 | LangChain | 向量数据库 | RAGAS | 大模型工程化
