生产级 RAG 系统设计笔记
拆解检索增强生成(RAG)在工程落地中的五大挑战,以及对应的成熟解决方案。
3 分钟阅读404 字
一、概述
RAG(Retrieval-Augmented Generation)是企业落地 LLM 最高频的形态。从"能跑通 Demo"到"上线可观测"之间,往往隔着五个工程深坑。
二、整体架构
TEXT
┌────────────┐
query ──→ │ Query 改写 │ ──┐
└────────────┘ │
▼
┌────────────────────────┐
│ Hybrid Retriever │
│ · 向量召回 (ANN) │
│ · BM25 关键词 │
│ · 元数据过滤 │
└────────────────────────┘
│
▼
┌────────────────────────┐
│ Rerank + 去重 + 压缩 │
└────────────────────────┘
│
▼
┌────────────────────────┐
│ LLM 生成 + 引用回链 │
└────────────────────────┘
│
▼
答案 + 引用
三、五大工程挑战
3.1 文档切分
| 策略 | 适用场景 |
|---|---|
| 固定窗口 | 短文/FAQ |
| 按段落 | 通用 |
| 语义切分(Embedding 距离) | 长文 |
| 层级切分(parent-child) | 多跳问答 |
3.2 检索质量
- 混合检索:向量召回 + BM25 关键词,Recall 通常提升 10%~20%。
- 元数据过滤:在 SQL/ES 端先按时间/部门/权限过滤,再走向量召回。
- HyDE:让 LLM 先生成"假设答案",用其 embedding 去检索,可缓解 query-doc 语义鸿沟。
3.3 重排序
TS
const topK = 50
const rerank = await crossEncoder.rerank(query, candidates, { topK: 5 })
Cross-Encoder 比 Bi-Encoder 慢得多,但精度显著高,放在粗排之后精排。
3.4 Prompt 工程
TEXT
你是一名严谨的企业知识助手,请严格基于以下资料回答:
---
{context}
---
问题:{question}
要求:
1. 答案必须引用 [1] [2] 等编号,文末列出引用清单。
2. 若资料不足,直接回答"我不知道",禁止编造。
3.5 可观测性
- 检索指标:Recall@K、MRR、nDCG。
- 生成指标:Faithfulness(答案是否忠于上下文)、Answer Relevance。
- 链路追踪:OpenTelemetry + Langfuse / Phoenix,记录每条 query 的 retriever/reranker/LLM 调用。
四、踩坑清单
- Embedding 模型选错语言:中文场景务必用
bge-m3/text-embedding-3-large-zh。 - Chunk 之间缺上下文:切分时把"父级标题"作为前缀注入。
- 向量库不是万能:结构化查询(精确时间、数值)走 SQL,不要塞进向量。
- Rerank 模型线上太慢:对长文档做"先摘要再 rerank"。
五、总结
生产级 RAG 的核心是在召回与生成之间铺设一条可观测、可回放、可评估的工程管线。先把检索质量打稳,再优化生成,事半功倍。
推荐框架: LlamaIndex · LangChain · Qdrant
文章 slug: production-rag-system-design
最后更新: 2026-06-18
版权声明 · CC BY-NC-ND 4.0
署名-非商业性使用-禁止演绎 4.0 国际
评论
由 GitHub Discussions 驱动