Ch13 RAG修订于 二〇二六年七月二日
13.15 RAG 生产部署
从 Jupyter Notebook 里的 Demo 到生产环境可用的系统，中间有一大段路要走。这一节讲 2026 年 RAG 生产部署的实践建议。
13.15.1 2026 RAG 技术栈推荐
入门级（个人项目 / MVP）：
- 向量数据库：Chroma（开源，Python 原生，零配置）
- Embedding：OpenAI text-embedding-3-small（$0.02/1M token，性价比最高）
- LLM：GPT-4o-mini 或 Claude Haiku（便宜，够用）
- 框架：LangChain 或 LlamaIndex（二选一，不用纠结）
- 重排序：先用混合检索，不加重排序
生产级（企业应用 / 高流量）：
- 向量数据库：Milvus（开源，十亿级，分布式）或 Pinecone（商业，免运维）
- Embedding：BGE-M3（开源，多语言，中文领先）或 Cohere Embed v3（商业，多语言最佳）
- 稀疏检索：Elasticsearch BM25（与向量数据库配合）
- 重排序：bge-reranker-v2-m3（中文）或 Cohere Rerank 3（多语言）
- LLM：GPT-4o 或 Claude Sonnet（质量优先）或 DeepSeek-V3（国产替代）
- 框架：LangChain + LangSmith（调试追踪）或 LlamaIndex + LlamaCloud
- 监控：Langfuse（开源，LLM 可观测性）或 Helicone
13.15.2 向量数据库选型
| 数据库 | 类型 | 规模 | 部署 | 中文支持 | 2026 推荐场景 |
|---|---|---|---|---|---|
| Chroma | 开源 | 小-中 | 本地 | 一般 | 个人项目、原型 |
| Qdrant | 开源 | 中-大 | 本地/云 | 好 | 中型生产环境 |
| Milvus | 开源 | 大-超大 | 分布式 | 好 | 大型生产环境 |
| Pinecone | 商业 | 大-超大 | 云 | 好 | 免运维，预算充足 |
| Weaviate | 开源 | 中-大 | 本地/云 | 一般 | 需要 Hybrid Search 原生支持 |
| Elasticsearch | 开源/商业 | 大-超大 | 分布式 | 好 | 已有 ES 基础设施的团队 |
选型建议：从 Chroma 或 Qdrant 开始（简单），到 Milvus（规模大），到 Pinecone（不想运维）。不要一开始就选最复杂的——向量数据库迁移很痛苦，但早期你不需要十亿级的能力。
13.15.3 Embedding 模型选型
| 模型 | 维度 | 最大输入 | 多语言 | 中文 | 成本 | 2026 推荐场景 |
|---|---|---|---|---|---|---|
| OpenAI text-embedding-3-small | 512/1536 | 8191 | 好 | 好 | 商业 | 通用，性价比最高 |
| OpenAI text-embedding-3-large | 256/1024/3072 | 8191 | 好 | 好 | 商业 | 高质量要求 |
| BGE-M3 | 1024 | 8192 | 很好 | 最好 | 开源 | 中文场景首选 |
| Cohere Embed v3 | 1024 | 512 | 最好 | 好 | 商业 | 多语言，最高质量 |
| Jina embeddings v3 | 1024 | 8192 | 很好 | 好 | 开源 | 长文档，Late Chunking |
| BGE-Large-zh-v1.5 | 1024 | 512 | 中文 | 最好 | 开源 | 轻量中文场景 |
选型建议：中文场景 BGE-M3（开源免费，质量好），多语言场景 Cohere Embed v3（商业，质量最高）。如果预算有限，OpenAI text-embedding-3-small 是安全的选择。
13.15.4 监控和运维
RAG 系统上线后，你需要持续监控：
关键指标：
- 检索延迟（P50/P95/P99）：超过 500ms 用户就会感觉慢
- 检索召回率（抽样评估）：每周抽样 100 个查询，人工检查检索结果
- 答案忠实度（RAGAS 自动评估）：每天自动评估，发现异常及时告警
- 用户反馈：点赞/点踩比例，复制答案的比例（间接指标）
常见问题和解决方案：
- 检索质量下降：通常是知识库膨胀导致。检查是否有新的、不相关的文档进入了索引。定期清理知识库。
- 答案出现幻觉：检查重排序是否正常工作，Prompt 模板中的指令是否被 LLM 忽略。增加”如果不知道就说不知道”的指令。
- 延迟增加：检查向量数据库是否过载，检索结果数量是否太大。增加缓存（热门问题缓存搜索结果）。
- 成本过高：检查 Embedding 和 LLM 的调用量。对常见问题做缓存，减少重复调用。考虑用更便宜的模型处理简单查询。
13.15.5 缓存策略
RAG 系统有两个天然的缓存点：
- 查询缓存：相同或相似的问题，直接返回缓存的答案。用 Embedding 做语义去重——两个问题相似度 > 0.95 就认为是同一个问题。
- 文档缓存：检索结果缓存。同一个文档被频繁检索，把它的 Embedding 和内容缓存在内存中。
2026 年建议：缓存是 RAG 系统性价比最高的优化。20-30% 的查询可以被缓存命中（取决于你的场景），直接省掉检索和 LLM 生成的成本。
← 上一节：13.14 RAG vs 微调 vs 长上下文 ｜ 下一节：13.16 动手搭一个 RAG →