共计 2094 个字符,预计需要花费 6 分钟才能阅读完成。
背景痛点:为什么需要 RAG?
大语言模型(LLM)在实际应用中面临两个致命问题:

- 知识滞后性:传统微调模型一旦训练完成,其知识就固定在某个时间点。比如用 2023 年数据训练的模型,无法自动获取 2026 年的新政策或技术动态。
- 幻觉问题:当模型遇到超出训练数据范围的问题时,可能生成看似合理实则错误的回答,比如虚构历史事件或科学原理。
重新训练模型成本极高——据估算,训练一个 300B 参数模型需要数百万美元计算资源。这就是 RAG 技术闪光的场景:用外部知识库实时增强生成过程。
技术方案对比
| 方案 | 成本 | 实时性 | 准确性 | 适用场景 |
|---|---|---|---|---|
| 全量微调 | 极高 | 无 | 依赖训练数据 | 领域专用模型 |
| Prompt 工程 | 低 | 依赖提示词 | 不稳定 | 简单任务 |
| RAG | 中等 | 实时更新 | 可验证 | 需要动态知识的场景 |
架构设计
@startuml RAG 流程
skinparam monochrome true
actor 用户
rectangle "Query 理解" as query {
component 语义解析
component 查询扩展
}
rectangle "向量检索" as retrieve {
database 知识库
component 向量化
component kNN 搜索
}
rectangle "生成增强" as generate {
component 提示工程
component LLM
}
用户 --> query : 原始提问
query --> retrieve : 优化后的查询
retrieve --> generate : Top- K 相关文档
generate --> 用户 : 最终回答
@enduml
关键设计原则:
- 检索与生成解耦:检索器独立于 LLM 迭代优化,可替换为 ES/BM25 等传统方案
- 分层过滤:先通过关键词粗筛,再用向量检索精排
- 注意力引导:在 prompt 中明确标注检索结果来源,降低幻觉概率
代码实战:FAISS 检索增强
import faiss
import numpy as np
from sentence_transformers import SentenceTransformer
# 初始化编码器(实际生产建议用 GPU 加速)encoder = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')
# 模拟知识库数据
docs = ["2026 年新税法第 12 章...", "量子计算突破性进展..."]
doc_embeddings = encoder.encode(docs) # 转换为向量
# FAISS 索引构建(IVFPQ 量化节省内存)dimension = doc_embeddings.shape[1]
quantizer = faiss.IndexFlatIP(dimension)
index = faiss.IndexIVFPQ(quantizer, dimension, 100, 8, 4)
index.train(doc_embeddings)
index.add(doc_embeddings)
# 检索函数
def retrieve(query: str, top_k: int=3, threshold: float=0.7):
query_embedding = encoder.encode([query])
query_embedding = query_embedding / np.linalg.norm(query_embedding) # L2 归一化
distances, indices = index.search(query_embedding, top_k)
# 相似度过滤
results = []
for i, dist in zip(indices[0], distances[0]):
if dist >= threshold:
results.append(docs[i])
return results
生产环境优化策略
检索性能三把斧
- 分片策略:按知识领域分片索引,比如法律 / 医疗分属不同 FAISS 实例
- 量化压缩 :使用 PQ(Product Quantization) 将 768 维向量压缩到 64 字节
- 缓存机制:对高频查询构建 LRU 缓存,命中率可提升 40%+
安全防护要点
- 敏感词过滤:在检索前对 query 进行合规校验
- 结果审计:记录所有检索到的文档 ID,便于问题追溯
- 权限控制:不同用户只能访问授权知识库分片
避坑指南
矛盾结果处理
当检索到不同来源的冲突信息时:
- 在 prompt 中明确提示 LLM 存在矛盾
- 附加可信度评分(如引用权威来源)
- 最终生成时标注 ” 根据 A 来源 … 但 B 来源认为 …”
冷启动闭环构建
- 初期先用通用知识库(如 Wikipedia 数据)
- 记录用户对生成结果的反馈(赞同 / 纠错)
- 通过主动学习筛选高价值样本补充到知识库
质量平衡艺术
- 设置检索结果占比上限(如 prompt 中不超过 30%)
- 对生成结果做事实性校验(调用外部 API 验证数字 / 日期)
- 当检索相似度低于阈值时回退到纯 LLM 生成
开放思考题
- 当知识库规模达到 TB 级时,如何设计分层检索架构平衡精度与延迟?
- 能否用生成模型的输出来反哺优化检索器(类似强化学习中的 reward shaping)?
从实验到生产,RAG 系统需要持续监控和迭代。建议初期重点关注两个指标:检索召回率 @K 和生成结果的事实准确率。记住:没有完美的架构,只有最适合业务场景的权衡。
正文完
