模块五-生产环境中的RAG系统

模块五-生产环境中的RAG系统

系列导航：本文是 RAG 技术教程 的第五篇（最后一篇）。上一篇：模块四：LLM 与文本生成

前置知识：需了解前四个模块的内容，本模块是系列的综合应用。

版权声明：本系列基于 DeepLearning.AI 课程Building and Evaluating Advanced RAG Applications（讲师 An Hassan）整理，为学习笔记性质的二次创作。原始课程版权归 DeepLearning.AI 及讲师所有。

1. 生产环境中的 RAG：评估、优化与安全

1.1 1. 从原型到生产

前四个模块掌握了设计和构建 RAG 系统的技能。投入生产环境时，会出现许多新的挑战。

流量规模：更多用户限制系统吞吐量，更多请求意味着更高成本。

错误的实际业务影响：生产环境中最大的问题是错误会产生实际业务后果。Google AI 搜索摘要曾建议用户食用岩石以获取营养益处——因为相关文章内容滑稽可笑但系统未能识别。某航空公司的聊天机器人承诺提供实际上不存在的客户折扣。恶意行为者会试图诱骗 RAG 系统为他们销售免费产品或泄露机密信息。

数据的混乱：数据碎片化、格式混乱、缺少元数据，很多数据不是文本格式（存在于图像、PDF 和演示文稿中）。

需要建立能够预见问题、及时遏制、验证改进的系统。

1.2 2. RAG 评估策略

1.2.1 可观测性的四大组成部分

1. 软件性能指标：延迟、吞吐量、内存以及计算资源使用情况
2. 质量指标：用户满意度、最终回复的准确性、检索器的召回率
3. 聚合统计与详细日志：随时间变化的聚合统计（跟踪整体趋势）+ 详细日志（追踪单个提示的流转过程）
4. 实验功能：在安全环境中运行定制实验或在生产环境中进行 A/B 测试

1.2.2 评估框架的两个维度

评估方法存在于两个维度的网格中：

系统级评估告诉你"系统整体表现如何"，组件级评估告诉你"问题出在哪个环节"。

1.2.3 三种评估类型

基于代码的评估：成本最低、最简单。记录系统每秒处理的请求数、运行单元测试确保语言模型输出有效 JSON。可自动运行、具有确定性且几乎无需成本。

LLM 作为裁判：通过语言模型评估系统各组件表现（如判断检索器获取的文档是否与用户提示相关）。比代码评估更灵活且成本低于人工。注意：语言模型可能有偏见并偏好同源生成的响应；需明确评分标准（在离散标准下表现最佳，而非 0-100 评分）。

人工反馈：用户用点赞或点踩标记应用响应。也可以让用户填写详细反馈文本框，或由人类预编数据集（包含提示及应被检索的相关文档），可快速计算精确率和召回率。成本更高，但能捕捉代码评估遗漏的信息。

1.2.4 整合指标集合的三步走

第一步：收集各主要组件的软件性能与质量指标。

第二步：收集系统级性能指标——延迟、吞吐量、内存使用、每秒生成的词元数。这些是代码评估指标，易于低成本收集。

第三步：质量指标分析。这是三步中最复杂也最关键的一步，按评估对象分为三个层面：

系统级质量指标：最简单的方式是允许用户点赞/点踩。更多用户点踩表明存在需修复的问题。也可以让用户填写详细反馈文本框，获取定性信息。

评估检索器质量：需要编制人工标注的测试集——包含一组提示和每个提示对应的人工标注的相关文档。然后计算召回率（找到了多少相关文档）和精确率（返回的结果中有多少是相关的）。这是模块二讲解的检索评估指标在生产环境中的实际应用。

评估语言模型质量：使用基于 LLM 的评估方法。以 Ragas 库为例，它能自动评估三个关键维度：

Ragas 是什么：Ragas（Retrieval Augmented Generation Assessment）是一个开源的 RAG 评估框架，专门用于自动化评估 RAG 系统的质量。它利用 LLM 作为裁判，对检索质量和生成质量进行多维度打分，无需人工逐条检查。安装后几行代码即可集成到评估流程中。

这三个维度共同衡量 LLM 是否正确使用了检索到的信息——既没有忽略有用内容，也没有被无关内容误导。

这种方法同时了解系统整体性能和质量以及各个组件的表现，很好地平衡了低成本指标和高成本指标。

1.3 3. 日志监控与可观测性

1.3.1 追踪（Tracing）

追踪是可观测性的核心能力——跟踪提示在整个 RAG 流程中的路径，观察每个组件如何修改它。

可以看到每个步骤的输入输出，还能记录各步骤延迟等有用信息。当某个提示在系统中表现不佳时，通过追踪其路径可以确定错误来源——是检索器没找到相关文档，还是重排序出了问题，还是 LLM 没有正确使用检索到的信息。

1.3.2 指标收集与 A/B 测试

与 Ragas 库集成，可轻松添加评估步骤（如检索器的搜索相关性、语言模型是否准确引用来源）。A/B 测试系统变更以评估对性能的影响（如新系统提示是否提升响应质量、添加重排序器是否带来性能提升）。

1.3.3 高层聚合统计

提供每日关键指标报告，从检索器的准确性到模型的幻觉率。对于底层监控（向量数据库计算和内存使用），使用 Datadog 和 Grafana 等传统工具。

1.3.4 系统改进的飞轮效应

良好的可观测性管道 → 观察系统处理真实生产流量的方式 → 识别漏洞或改进目标区域 → 观察随时间推移所做的更改的影响 → 优化系统中的每个组件。这个循环持续运转，系统质量不断提升。

1.4 4. 定制化评估体系

1.4.1 自定义数据集

自定义数据集是系统之前处理过的提示集合，以及选择收集的关于这些提示的任何信息。

需要存储的数据包括：基本数据——用户提交的输入提示 + 系统生成的最终回复；组件级数据——向量数据库检索的文档、文档的排序结果、重排序器处理前后的变化、查询重写的输出等。

1.4.2 日志表设计

日志表可能有数十列，存储从发起请求的客户 ID 到重排序器筛选的文本片段、工作流中每个路由的输出。这样能单独分析系统各组件并多维度评估性能。

1.4.3 实际案例

案例一：客服聊天机器人通过问题主题过滤，发现退款相关问题获得高质量回复但产品延迟相关问题表现极差。分析日志发现检索器无法找到相关文档 → 补充知识库内容后问题解决。

案例二：RAG 系统使用 Mermaid.js 生成图表 → 路由语言模型错误理解"绘制图表"指令 → 发送到文本到图像模型（擅长生成人物或物体图像但图表效果差）→ 排查发现是路由 LLM 的系统提示不够明确 → 更新系统提示使"绘制图表"生成代码回传图表而非图像。

1.4.4 数据可视化

可视化所有输入提示，使用聚类算法识别客户咨询的高频主题（如产品发布或故障排查问题）。仅对特定类型提示运行评估流程，检测系统是否在某些问题类型上表现不佳。

1.5 5. 模型量化技术

1.5.1 量化的定义

量化是对语言模型和嵌入模型生成的向量进行的压缩——用压缩后的低精度数据类型替换原始值，使模型或向量变得更小、运行时更便宜且更快，通常不会显著牺牲效果。

类比图像压缩：高质量图像使用 32 位数据表示颜色 → 12 位或 6 位数据压缩 → 显著内存节省但质量下降。量化采用相同方法处理 LLM 和嵌入向量。

1.5.2 LLM 量化

典型语言模型参数使用 16 位内存 → 量化后压缩为 8 位或 4 位等效值 → 显著降低 GPU 内存需求，以略微降低模型性能为代价。

1.5.3 嵌入向量量化

整数量化：典型 768 维向量使用 768 个 32 位浮点数，每个向量占用约 3KB。存储数百万甚至数十亿个向量时，需要处理海量数据。

整数量化用 8 位整数替代 32 位浮点数，向量体积缩减为原来的四分之一。计算过程：

1. 找到每个维度的最小和最大值（遍历所有向量在该维度的值）
2. 将最小到最大的范围划分为 256 个等距区间
3. 每个浮点数被分配一个整数值（落在哪个区间就取对应整数）

8 位整数量化在召回率等基准测试中表现优异，仅导致几个百分点的性能下降。

1 位（二进制）量化：将向量大小压缩为三倍（从每维度 32 位降至 1 位）。向量中的每个值仅为 0 或 1（仅表示该维度值的正负）。极端压缩级别，检索性能可能明显下降。

可与其他技术结合：基于 1 位量化嵌入进行快速检索，然后使用完整原始 32 位向量重新评分。先用粗筛快速缩小范围，再用精确计算确保质量。

1.5.4 Matryoshka 嵌入（套娃嵌入）

基于俄语"嵌套娃娃"概念的嵌入模型。向量设计为可选择使用部分维度——如完整向量 1000 维，可选择仅使用前 500 或前 100 维度。

特殊属性：维度按信息密度从高到低排列。早期维度方差更大（更多信息含量），后期维度方差更小。

使用方式：仅使用前 100 维度节省空间并加快计算速度；或始终使用前 100 维度进行初始检索，然后调用剩余 900 维度从较慢存储中获取完整向量重新评分。最适合动态环境，可在低到高保真向量表示间快速切换。

1.5.5 量化的核心建议

应尝试使用整数量化的语言模型和嵌入模型。大多数提供商将提供 8 或 4 比特量化模型。节省的空间和成本可能显著，而质量损失非常微小。

1.6 6. 成本与响应质量的平衡

RAG 系统的两大成本来源：向量数据库和大型语言模型。

1.6.1 LLM 成本优化

• 使用更小的模型：更小且更便宜的模型可能实现相似的整体质量，微调小模型可在低成本下获得良好效果
• 限制输入输出词元数量：减少检索文档数量（降低 top k 值）、更新系统提示鼓励简洁响应、设定固定词元限制
• 专用硬件：将模型部署在专用硬件上（按小时付费 vs 按词元付费），额外优势是更好的可靠性

1.6.2 向量数据库成本优化

三种类型内存：RAM（最快最贵）→ 磁盘内存（居中）→ 云对象存储（最慢最便宜）。策略是仅支付高速昂贵存储中实际需要的数据——HNSW 索引应保留在 RAM 中以确保向量搜索最快运行，文档内容按热度分层存储。

多租户架构：按用户或所属组织划分向量数据库中的所有文档，便于快速加载租户数据至高速昂贵内存。如客户登录时加载其向量至 RAM、按地区或时段调整存储类型。

1.6.3 成本优化核心原则

理解成本来源，并确保其由 LLM 性能合理性支撑。LLM 方面用更小模型和更短提示，向量数据库方面在昂贵存储中存放更少数据。

1.7 7. 时延与响应质量的权衡

延迟的重要性取决于应用场景——电商平台对缓慢响应几乎零容忍，而帮助医生诊断罕见疾病的 RAG 系统更可能优先优化回答质量。

1.7.1 延迟的主要来源

几乎所有延迟都来自运行 Transformer 模型——最大的延迟来源将是 LLM 调用。检索确实会增加少量延迟，特别是基于 Transformer 的重排序技术。现代向量数据库非常快速且易于扩展。

1.7.2 降低延迟的方法

使用更小的语言模型：更小的 LLM 或量化模型在相同硬件上运行更快。

路由模型：使用小型路由 LLM 判断输入提示 → 简单查询路由到更小更快的模型，复杂推理路由到更大更强的模型。

缓存：维护常用提示及其响应的缓存。收到新提示时，快速计算新提示与缓存中提示的相似度。如果找到足够接近的匹配项，可立即返回缓存的响应，跳过整个 RAG 流程。

缓存 + 个性化：获取缓存响应后将其和用户提示输入到更小更快的 LLM 中，对响应进行小幅调整使其更符合当前提示内容。既利用了缓存的速度，又保持了个性化。

1.7.3 优化策略

了解系统可容忍的延迟程度 → 首先优化核心组件（LLM）→ 然后处理其他 Transformer 组件 → 如果延迟仍存在问题，再优化管道中的其他组件。借助完善的可观测性系统观察改动的影响。

1.8 8. 安全防护机制

RAG 系统的安全焦点是保护知识库中的信息（私有或专有信息）。

1.8.1 信息泄露途径一：用户直接请求

用户提交精心设计的提示，说服 LLM 直接引用知识库检索到的片段。

解决方案：根据用户访问权限进行身份验证；将数据按多租户分割（基于角色或权限），用户只能访问与其角色和权限匹配的文档。元数据过滤不适合安全防护，多租户独立存储是更可靠的方法。

1.8.2 信息泄露途径二：发送给 LLM 提供商

增强提示包含知识库或检索到的文本片段 → 发送到 LLM 提供商时失去安全控制。

解决方案：完全本地部署检索系统（将 LLM 和向量数据库部署在自有硬件上）。

1.8.3 向量数据库被攻破

传统数据库通过加密内容防御未授权访问。向量数据库的独特挑战：密集向量表示需要以明文形式存储在内存中以使算法正常运行。

部分解决方案：文本块可以以加密方式存储和检索，随后再解密以构建增强提示。

1.8.4 前沿安全研究

近期研究表明可以从密集向量重建原始文本。应对技术：向密集向量添加噪声、对其进行变换处理、或通过降维保留距离同时掩盖语义信息。这些技术会增加检索器复杂度并可能降低系统性能。

1.9 9. 多模态 RAG 系统

1.9.1 多模态模型与嵌入

信息以多种格式存储（演示文稿、PDF 文件、图像），这些都包含有价值信息。得益于多模态模型的最新进展，现在可以构建处理多种数据类型的 RAG 系统。

多模态嵌入模型能将多种数据格式嵌入同一向量空间。"dog"和"puppy"的向量彼此接近，狗的图像的向量也会出现在附近区域，树的图像和"tree"也会被嵌入相近位置但位于向量空间的不同区域。

1.9.2 多模态检索流程

1. 知识库中的图像和文本嵌入同一向量空间
2. 收到提示时，使用相同多模态模型嵌入提示
3. 执行常规向量搜索，返回与提示向量最接近的图像或文档
4. 检索到的文本和图像添加到增强提示，发送给语言模型

1.9.3 语言-视觉模型

能处理文本和图像的语言模型。图像必须被分词处理：将图像分割成独立的图像块，每个图像块都表示为一个分词单元。图像可能包含 100-1000 个分词单元（取决于分辨率）。工作原理与标准 LLM 非常相似：将多模态分词序列输入 Transformer → 建立对文本和图像的深入理解 → 通常输出文本分词作为结果。

1.9.4 PDF 和幻灯片的挑战

密集的幻灯片和 PDF 可能单页包含文本、图表、标题和图像——单个向量难以捕捉所有细节。解决方案：像分块文本一样对图像进行分块。

1.9.5 ColPali — PDF RAG 方法

将每页划分为网格方块（无需考虑边界是否合理）。每个方块由多模态嵌入模型生成密集向量。搜索时：提示中的每个单词在页面上寻找其最佳匹配方块 → 这些分数相加评估文档页面的整体得分。

非常灵活（任何图像都可以分割成网格方块），在检索任务中表现出色。主要缺点：需要向量数据库存储大量向量。

1.9.6 多模态 RAG 的现状

仍是前沿技术并快速发展。大多数 LLM 提供商提供语言视觉模型，而多模态嵌入模型则相对更实验性。向量数据库提供商正逐步实现多模态检索工具。

>来源：吴恩达 RAG 课程

1.10 思考题

1. 如果你的 RAG 系统上线后发现用户频繁点踩，你会从哪里开始排查？
2. 整数量化将向量从 32 位压缩到 8 位，体积缩小为 1/4，但召回率只下降几个百分点。这背后的权衡是什么？
3. 如果你的知识库包含大量 PDF 和图片，你会选择多模态 RAG 还是先将图片转换为文字描述？为什么？

系列完结。回到 系列总览 查看全部内容。