1. RAG在线阶段核心流程解析
在构建RAG(检索增强生成)系统时,在线阶段是将离线准备的向量化知识库转化为实际问答能力的关键环节。这个阶段需要处理从用户提问到最终答案生成的全流程,每个环节都直接影响系统的响应速度和质量。
1.1 用户提问预处理
当用户输入"年假怎么计算?"这样的自然语言查询时,原始问题往往存在三个典型问题:
- 表述模糊(缺少上下文)
- 存在错别字
- 意图不明确
我们的预处理流程采用四级过滤机制:
- 拼写校正:使用SymSpell等算法进行实时纠错,处理"年价"→"年假"这类错误
- 上下文融合:维护对话状态机,当用户追问"试用期呢?"时,自动补全为"试用期年假怎么计算?"
- 意图分类:用轻量级BERT模型判断问题属于"政策查询"、"数据获取"还是"闲聊"
- 查询扩展:基于HyDE技术,先让GPT-3.5生成假设答案,再用其向量进行检索
实际测试表明,经过预处理的查询可使检索准确率提升40%以上。但要注意控制预处理耗时在300ms内,否则会影响用户体验。
1.2 向量化处理要点
向量化是连接离线与在线阶段的关键桥梁,必须确保:
- 使用与离线阶段完全相同的embedding模型(包括版本号)
- 输入文本的预处理方式一致(如相同的分词器、大小写处理)
我们建立的保障机制包括:
- 模型版本锁定(通过MD5校验)
- 预处理代码复用(封装为统一SDK)
- 向量维度校验(如text-embedding-3-small应为1536维)
python复制# 标准化embedding调用示例
from embedding_sdk import get_embedding
vector = get_embedding(
text="年假计算规则",
model_name="text-embedding-3-small",
api_key="your_key"
)
2. 混合检索系统实现
2.1 向量检索优化方案
现代RAG系统通常采用分层检索架构:
| 检索类型 | 算法 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 精确检索 | BM25 | 关键词匹配准 | 语义理解弱 | 术语、代码检索 |
| 语义检索 | HNSW | 语义理解强 | 计算成本高 | 概念性查询 |
| 混合检索 | RRF | 兼顾两者 | 实现复杂 | 通用场景 |
我们推荐使用Faiss + Elasticsearch的组合:
- Faiss负责稠密向量检索(GPU加速)
- Elasticsearch处理关键词匹配和元数据过滤
bash复制# 混合检索示例查询
POST /_search
{
"query": {
"bool": {
"must": {
"match": { "content": "年假政策" } # 关键词匹配
},
"filter": {
"range": { "publish_date": { "gte": "2023-01-01" }} # 元数据过滤
}
}
},
"knn": {
"field": "embedding",
"query_vector": [0.12, -0.34, ...],
"k": 10,
"num_candidates": 100
}
}
2.2 重排序策略
当初步检索返回20个候选文档后,需要经过两阶段精排:
-
粗排阶段(<50ms)
- 使用ColBERT等高效模型
- 计算query与每个doc的快速相似度
- 保留top10
-
精排阶段(<200ms)
- 调用BGE-Reranker-large
- 完整计算query-doc交叉注意力
- 输出最终top3
实测表明,这种方案比单一阶段排序准确率提升25%,而耗时仅增加30%。
3. 提示工程与生成优化
3.1 动态提示模板设计
我们采用模块化提示组装方案:
code复制[系统指令]
你是一个{domain}专家,请根据以下信息用{style}风格回答。
禁止编造信息,不确定时回复"根据现有资料无法确定"。
[上下文]
{format_context(docs)}
[用户问题]
{query}
[回答要求]
使用markdown格式,在引用处标注[1][2]等来源编号。
其中关键创新点:
format_context()函数会:- 去除重复内容(基于simhash)
- 添加文档序号前缀
- 截断超过512token的段落
3.2 生成参数调优
不同场景下的LLM参数配置:
| 场景 | Temperature | Top_p | Max_tokens | 备注 |
|---|---|---|---|---|
| 事实查询 | 0.2 | 0.9 | 500 | 确定性高 |
| 创意生成 | 0.7 | 0.95 | 1000 | 多样性好 |
| 数学计算 | 0 | 1 | 300 | 严格精确 |
对于政策咨询类问题,我们推荐:
python复制response = openai.ChatCompletion.create(
model="gpt-4-turbo",
messages=messages,
temperature=0.3,
top_p=0.9,
max_tokens=800,
stop=["\n\n"] # 防止过度展开
)
4. 生产环境关键问题排查
4.1 常见错误与解决方案
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 检索结果不相关 | 向量模型不一致 | 校验模型版本和预处理流程 |
| LLM回答不符合格式 | prompt注入 | 添加system指令防护 |
| 响应时间波动大 | 未启用缓存 | 对高频query缓存embedding |
| 引用编号错误 | 文档去重失败 | 采用simhash+位置校验 |
4.2 性能优化记录
在某次优化中,我们通过以下措施将P99延迟从2.1s降至890ms:
- 实现embedding缓存(命中率32%)
- 将Faiss索引从IVF改为HNSW
- 预计算高频query的rerank结果
- 采用流式生成(TTFB降至400ms)
具体监控指标改进:
- 检索耗时:1200ms → 450ms
- 重排序耗时:600ms → 300ms
- 生成耗时:900ms → 500ms
5. 进阶优化方向
对于需要更高性能的场景,可以考虑:
-
分层索引:
- 热门文档使用HNSW实现毫秒级检索
- 冷门文档使用IVF降低内存占用
-
异步预处理:
- 用户输入时即开始预生成常见后续问题的embedding
- 通过WebSocket实现"输入即搜索"的效果
-
智能路由:
mermaid复制graph TD A[用户问题] --> B{是否事实查询?} B -->|是| C[RAG流程] B -->|否| D[直接生成] C --> E{是否简单问题?} E -->|是| F[GPT-3.5] E -->|否| G[GPT-4]
在实际部署中,我们建议先从核心流程做起,逐步引入优化措施。每次变更都要进行AB测试,确保准确率不会下降。