共计 2031 个字符,预计需要花费 6 分钟才能阅读完成。
为什么需要 RAG?
最近在使用 GPT- 3 生成技术文档时,发现一个令人头疼的问题:当询问 2023 年发布的 Kubernetes 新特性时,模型给出的答案中混杂着已弃用的 API 说明。测试数据显示,主流大语言模型 (LLM) 在时效性数据上的准确率不足 60%,且存在 15-20% 的幻觉生成概率。这种知识滞后性在金融、医疗等对事实准确性要求高的领域尤为致命。
技术选型:微调还是 RAG?
成本效益对比
-
传统微调(Fine-tuning)
训练成本:$200-$500/ 次(基于 GPT-3 175B)
迭代周期:3- 7 天 / 次
知识更新:需全量重训练 -
检索增强生成(RAG)
部署成本:$50-$200/ 月(ES 集群)
响应延迟:增加 300-800ms
知识更新:实时增量更新

图示:用户查询先经检索模块 (Retriever) 从知识库获取相关片段,再与问题拼接输入生成模块(Generator)
核心实现拆解
检索模块实战
使用 FAISS 进行向量相似度搜索时,关键要设置合理的相似度阈值。以下示例展示如何过滤低质量结果:
from sentence_transformers import SentenceTransformer
import faiss
import numpy as np
# 初始化编码器
encoder = SentenceTransformer('paraphrase-MiniLM-L6-v2') # 384 维向量
# 构建 FAISS 索引
data = ["RAG improves factuality", "Fine-tuning is expensive"]
embeddings = encoder.encode(data)
index = faiss.IndexFlatIP(384)
index.add(embeddings)
# 带阈值检索
def search(query: str, threshold: float = 0.7) -> list[str]:
query_embed = encoder.encode([query])
distances, indices = index.search(query_embed, k=5)
return [data[i] for i in indices[0] if distances[0][i] > threshold]
生成模块优化
LangChain 的 RAG 链式调用支持异步处理,这对高并发场景至关重要:
from langchain.chains import RetrievalQA
from langchain.llms import OpenAI
qa_chain = RetrievalQA.from_chain_type(llm=OpenAI(temperature=0),
chain_type="stuff",
retriever=vector_store.as_retriever(),
chain_type_kwargs={"prompt": customized_prompt}
)
# 启用缓存提升性能
from langchain.cache import SQLiteCache
import langchain
langchain.llm_cache = SQLiteCache(database_path="./.langchain.db")
性能调优指南
检索参数权衡
测试环境:AWS c5.2xlarge, 100 万条文档
| top_k | 延迟(ms) | 召回率 |
|---|---|---|
| 5 | 120 | 78% |
| 10 | 210 | 85% |
| 20 | 350 | 92% |
建议:电商客服场景建议 top_k=5,学术研究可设 top_k=10-15
知识版本控制
采用 git-like 的版本管理方案:
knowledge_repo/
├── v1.0/
│ ├── legal_docs.json
│ └── embeddings.faiss
├── v1.1-hotfix/
└── latest -> v1.1-hotfix
生产环境避坑
冷启动检测
语料质量检查清单:
- 重复文档比例 <5%
- 平均句子长度 15-25 词
- 专业术语覆盖率 >80%(对比领域词典)
多轮对话陷阱
错误示例:
# 错误:简单拼接历史对话
context = "\n".join(chat_history)
正确做法:
from langchain.memory import ConversationBufferWindowMemory
memory = ConversationBufferWindowMemory(
k=3,
memory_key="chat_history",
input_key="human_input"
)
开放性问题
- 业务价值量化:如何设计 A / B 测试框架,比较 RAG 与传统方案在客服满意度、解决率等指标上的差异?
- 千万级扩展:当知识库突破千万文档时,是否需要引入分级检索(如先粗排后精排)?分布式向量库如 Milvus 的性能拐点在哪里?
经过三个月的 RAG 系统实践,最大的体会是:没有银弹。在医疗领域我们最终采用混合方案——静态知识用 RAG,动态决策逻辑仍依赖微调模型。建议开发者根据业务场景的容错率和实时性要求,灵活选择技术组合。
正文完
