# 实践中的 RAG：用检索增强生成构建可靠的 LLM 应用大语言模型令人印象深刻，直到你需要依赖它完成某件**必须正确**、**必须可追溯**，或**必须反映内部私有文档**的事情。如果你曾经把 LLM 功能交付给真实用户，通常会看到同样的模式： - 模型回答得很自信，但答案是错的。 - 它把同一政策的两个版本混在一起。 - 它用听起来合理的细节填补空白。 - 它跟不上每周变化的文档。因此，**检索增强生成（Retrieval-Augmented Generation，RAG）** 成为许多生产级 LLM 应用的核心架构。RAG 不是更好的提示词，而是一条由**搜索、上下文组装、基于证据生成**组成的工程流水线。 --- ## RAG 的真实含义 RAG 是一个简单思想的系统化实现： 1) 用户提出问题。 2) 应用从自有数据中检索相关证据。 3) 模型根据这些证据作答。结果不仅是更漂亮的回答。真正的价值是**控制力**：你可以追踪每个说法的来源，通过更新文档刷新知识，并把模型限制在经过筛选的来源范围内。

步骤	输入	输出	目标
1. 查询	用户问题	搜索查询	规范化意图和术语
2. 检索	查询 + 索引	Top-K 文本块	找到相关证据
3. 组装	检索到的文本块	上下文包	高效利用上下文窗口
4. 生成	问题 + 上下文	回答	生成有依据的回应
5. 引用	检索到的 ID	参考来源	让回答可审计

例如，当用户询问企业退货政策时，系统检索 `returns-policy.md` 和合同例外条款，然后只基于这些来源生成答案。 --- ## 为什么 RAG 优于普通提示词普通提示词适合头脑风暴或一般知识问答。但当你需要正确性、时效性和可复现性时，它就会变得有风险。

问题	生产环境中的表现	后果
幻觉	自信但错误的回答	用户很快失去信任
知识过时	训练截止之后的事实已经陈旧	导致错误决策
文档过载	政策太长，放不进上下文窗口	模型开始猜测
政策漂移	规则每周变化	回答变得不一致
可追溯性缺口	没有来源或引用	难以验证和调试

RAG 不会神奇地让 LLM 可靠。它只是把可靠性变成一个可以测量、可以改进的工程问题。 --- ## 生产级 RAG 系统生产级 RAG 通常包含两条流程：一条是负责摄取、转换和索引的**知识流水线**；另一条是负责检索、组装、生成和评估的**查询流水线**。 ### 1) 文档摄取来源可以包括 Markdown 仓库、PDF、手册、Notion、Confluence、支持工单、产品目录和数据库记录。

项目	为什么重要
版本管理	检索质量只会和最新真相一样好
归属责任	必须有人对正确性负责
元数据	支持按语言、产品、地区筛选
章节结构	改进切块和引用

### 2) 切块切块不是小细节。文本块太大，会带来噪声并浪费上下文；文本块太小，会丢失意义和依赖关系。

设置	起始范围	说明
块大小	300–800 tokens	优先按语义边界切分
重叠	10–20%	帮助章节之间保持连续
策略	按标题/章节	适合政策和文档

### 3) 嵌入与向量数据库每个文本块都会变成向量嵌入，然后用于相似度搜索。常见选择包括 Pinecone、Weaviate、Qdrant、Milvus，或带 pgvector 的 Postgres。很多真实系统中，混合搜索比纯向量搜索更稳定。 ### 4) 检索策略

层级	技术	适用场景
0	Top-K 向量搜索	基线
1	混合 BM25 + Vector	术语、精确关键词、零件编号
2	元数据筛选	语言、地区、产品线
3	重排序	提高相关性精度
4	多查询	模糊查询
5	查询改写	规范化同义词和内部命名

### 5) 上下文组装检索到文本块之后，还要决定模型最终看到什么。好的上下文组装会去除重复内容、优先使用新版本、按相关性和文档顺序排序，并加入标题、章节、日期等元数据。

字段	示例
文档	“退货政策”
章节	“企业例外条款”
日期	2026-01-01
片段	相关摘录文本

### 6) 基于证据的生成提示词强 RAG 提示词应把提供的上下文作为唯一事实来源；如果上下文不足，就明确说明；并列出使用的来源。规则很简单，但配合良好检索时可以显著减少幻觉。 --- ## 常见失败模式

修复方式	影响
混合检索	提高关键词密集型查询的召回率
重排序	提高精度
更好的切块边界	减少噪声
元数据 + 筛选	避免跨领域混合

如果检索正确但模型仍添加不存在的内容，可以降低 temperature，强制引用，并加入后置检查器来标记无依据的说法。 --- ## 如何评估 RAG

指标	说明
检索命中率	是否取回了正确证据
Precision@K	检索出的文本块中有多少真正相关
忠实性	回答是否由检索文本支持
完整性	是否覆盖所有必需点
延迟	检索 + 生成时间
成本	每次请求的 tokens 与重排序开销

收集 50 到 200 个真实问题，为每个问题定义正确的文本块，然后检查这些文本块是否出现在靠前结果中，并按忠实性和完整性评估最终回答。 --- [返回博客](https://ariansoleimanzadeh.site/Blog)

探索 AI 工程 与产品开发

实践中的 RAG：用检索增强生成构建可靠的 LLM 应用

探索 AI 工程 与产品开发

实践中的 RAG：用检索增强生成构建可靠的 LLM 应用

探索 AI 工程与产品开发

探索 AI 工程与产品开发