面向开发者的 RAG 系统最佳实践

RAG 的工程价值远超“拼装检索+LLM”，只有系统化治理才能真正提升效果。

RAG（Retrieval-Augmented Generation，检索增强生成）不是简单的“向量检索 + 大语言模型（LLM, Large Language Model）回复”拼装，而是一套完整的工程体系。其效果取决于三件关键因素：

数据是否干净、检索是否命中、提示是否正确使用这些信息。

本节从工程视角总结可落地的 RAG 最佳实践，适用于云原生工程师、AI 平台研发、应用工程师。

RAG 最佳实践体系一览

下图展示了 RAG 系统的核心层级与最佳实践要点：

数据质量与权限管理：RAG 的根基

高质量的数据和严格的权限管理是 RAG 成功的基础。

数据清洗是第一生产力

RAG 系统中，约 70% 的问题源自数据层，而非大语言模型本身。例如：

• 用户手册包含版本残留
• PDF 拆分错误
• 表格转文本导致语义丢失
• 重复内容降低训练效果

工程实践建议：

• 去除噪声：如页脚、页码、版权声明等
• 标准化结构：标题层级、列表、代码块、公式
• 对齐不同来源格式（HTML、PDF、Docs）

权限上下文化：RAG 必须考虑 ACL（Access Control List，访问控制列表）

企业内部 RAG 系统必须确保：

用户仅能检索自己权限范围内的文档。

推荐做法：

• 为文档添加 metadata.permission
• 向量检索时传入 filters={"team": ..., "role": ...}
• LLM 生成前进行二次过滤（第二道 ACL）

可以类比：

RAG 的检索层类似 Kubernetes API Server，metadata 是 RBAC 的“label + annotation”。

选择合适的嵌入模型（Embedding）

嵌入模型的选择直接影响检索命中率。

领域相关性优先于维度

实际工程中，嵌入模型的领域相关性远比维度更重要。例如：

• 法律领域 RAG 推荐使用法律专用 embedding
• 医疗领域建议采用医学语料训练的 embedding
• 技术文档推荐 BGE 系列模型，效果显著

工程实践推荐配置

• 文档 embedding：384–1024 维
• 查询 embedding：单独使用 query encoder（如 ColBERT）可提升召回率
• 缓存策略：embedding 结果建议缓存 7–30 天以降低成本

嵌入环节常被忽略，但对 RAG 性能影响极大。

检索策略优化

检索策略主要包括以下三部分：

• 检索数量（k 值）
• 相似度过滤（score_threshold）
• 检索方式（单向量 / 多向量 / Hybrid）

k 值推荐实践

这是各类场景的检索数量推荐：

k 值过大容易引入噪声，过小则可能遗漏关键信息。

使用阈值过滤噪声

建议在检索时设置相似度阈值，过滤无关内容。例如：

以下代码演示如何设置 score_threshold：

retriever.search(
    query, 
    k=8,
    score_threshold=0.75
)

未达到阈值时，建议让模型直接回答“未找到相关信息”。

Hybrid 检索是默认推荐策略

Hybrid 检索融合了语义向量检索（高准确度）与关键词 BM25（补充命中率），是 RAG 领域公认最稳健的方案。

提示模板设计（Prompt Engineering）

高质量的提示模板能显著提升模型输出的准确性和可控性。

你的提示必须明确告诉模型：

• 如何使用检索结果
• 何时不使用
• 如何回答
• 如何引用

推荐基础模板如下：

以下是 RAG 推荐的基础提示模板：

你是一名专业助手。以下是与问题相关的资料片段。

如果资料包含答案，请严格基于资料回答。
如果资料不相关，请回答“未找到相关内容”，不要编造。

每段资料都有编号，你可以引用编号。

三大 Anti-pattern（需要避免的错误做法）

• “请参考以下内容回答问题” —— 容易让模型忽略资料，自由生成
• 返回整段引用 —— 输出冗长，难以复现
• 给模型太多不相关 chunk —— 降低回答质量，增加幻觉

性能优化（性能 = 成本）

RAG 性能瓶颈通常不在大语言模型，而在数据处理和检索环节。

性能瓶颈主要来源

• 文档预处理
• 低效向量数据库
• 过多无意义检索

提升性能的工程方法

离线索引构建

不要在请求时做文档 embedding、清洗和 chunk 操作，应提前离线处理。

向量数据库优化

• 使用 HNSW 索引
• 增加 CPU 副本
• 使用 GPU 检索（如 Milvus、Weaviate）

Streaming + 压缩回答

对于长上下文问题，建议先执行“压缩 RAG”，再进行真实回答。

可观测性与持续评估（RAG Observability）

RAG 系统需要持续监控和评估，确保性能与可靠性。

关键指标（KPIs）

下表总结了各层关键指标：

Logging（日志记录）

必须记录以下信息：

• 检索返回的文档 ID
• 相似度 score
• 模型输入 / 输出
• 用户反馈标注

推荐做法：构建 RAG Playground

RAG Playground 能支持回放请求、修改 k 值、切换模型、可视化检索结果，有助于快速定位系统失败模式。

避坑指南（Failure Modes）

RAG 系统常见失败模式及应对建议如下：

Chunk 过大

Chunk 过大导致 embedding 信息密度不足，无法准确匹配。

Chunk 过小

Chunk 过小会切碎语义，LLM 难以拼接上下文。推荐 chunk 大小为 300～500 tokens。

检索命中但回答仍错误

可能原因：

• 检索内容相关度不够
• LLM 未正确利用

解决方法：

• 加强指令
• 调整 chunk 结构
• 增加引用标签（source tagging）

循环引用

模型输出直接复制文档，导致冗长无意义。可在 prompt 中禁止逐字引用。

总结

RAG 的本质不是技术堆叠，而是：

• 数据治理
• 检索策略
• 提示工程
• 性能优化
• 可观测性
• 持续评估与迭代

RAG 是一个长期演进的系统，而非“一次构建永久使用”。只有将其视为“检索版的微服务系统”持续运营，才能发挥真正价值。