模块五-生产环境中的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 可观测性的四大组成部分软件性能指标延迟、吞吐量、内存以及计算资源使用情况质量指标用户满意度、最终回复的准确性、检索器的召回率聚合统计与详细日志随时间变化的聚合统计跟踪整体趋势 详细日志追踪单个提示的流转过程实验功能在安全环境中运行定制实验或在生产环境中进行 A/B 测试1.2.2 评估框架的两个维度评估方法存在于两个维度的网格中系统级总结整体性能组件级定位具体问题根源基于代码记录每秒处理请求数、运行单元测试检查各组件延迟、内存占用LLM 作为裁判评估整体回复质量判断检索器获取的文档是否相关人工反馈用户点赞/点踩人工标注测试集计算召回率和准确率系统级评估告诉你系统整体表现如何组件级评估告诉你问题出在哪个环节。1.2.3 三种评估类型基于代码的评估成本最低、最简单。记录系统每秒处理的请求数、运行单元测试确保语言模型输出有效 JSON。可自动运行、具有确定性且几乎无需成本。LLM 作为裁判通过语言模型评估系统各组件表现如判断检索器获取的文档是否与用户提示相关。比代码评估更灵活且成本低于人工。注意语言模型可能有偏见并偏好同源生成的响应需明确评分标准在离散标准下表现最佳而非 0-100 评分。人工反馈用户用点赞或点踩标记应用响应。也可以让用户填写详细反馈文本框或由人类预编数据集包含提示及应被检索的相关文档可快速计算精确率和召回率。成本更高但能捕捉代码评估遗漏的信息。1.2.4 整合指标集合的三步走第一步收集各主要组件的软件性能与质量指标。第二步收集系统级性能指标——延迟、吞吐量、内存使用、每秒生成的词元数。这些是代码评估指标易于低成本收集。第三步质量指标分析。这是三步中最复杂也最关键的一步按评估对象分为三个层面系统级质量指标最简单的方式是允许用户点赞/点踩。更多用户点踩表明存在需修复的问题。也可以让用户填写详细反馈文本框获取定性信息。评估检索器质量需要编制人工标注的测试集——包含一组提示和每个提示对应的人工标注的相关文档。然后计算召回率找到了多少相关文档和精确率返回的结果中有多少是相关的。这是模块二讲解的检索评估指标在生产环境中的实际应用。评估语言模型质量使用基于 LLM 的评估方法。以 Ragas 库为例它能自动评估三个关键维度Ragas 是什么RagasRetrieval Augmented Generation Assessment是一个开源的 RAG 评估框架专门用于自动化评估 RAG 系统的质量。它利用 LLM 作为裁判对检索质量和生成质量进行多维度打分无需人工逐条检查。安装后几行代码即可集成到评估流程中。维度衡量什么工作方式响应相关性回答是否真正回应了用户的问题LLM 从回复中反向生成多个可能的提示计算与原始提示的相似度引用质量回答中的引用是否准确指向了支持它的文档LLM 检查每句回答是否有对应的检索文档作为依据忽略无关信息回答是否避免了被检索到的无关文档干扰LLM 判断回答中是否混入了与问题无关的信息这三个维度共同衡量 LLM 是否正确使用了检索到的信息——既没有忽略有用内容也没有被无关内容误导。这种方法同时了解系统整体性能和质量以及各个组件的表现很好地平衡了低成本指标和高成本指标。1.3 3. 日志监控与可观测性1.3.1 追踪Tracing追踪是可观测性的核心能力——跟踪提示在整个 RAG 流程中的路径观察每个组件如何修改它。初始文本提示发送给检索器的查询检索器返回的片段重排序器处理发送给 LLM 的增强提示生成的最终响应可以看到每个步骤的输入输出还能记录各步骤延迟等有用信息。当某个提示在系统中表现不佳时通过追踪其路径可以确定错误来源——是检索器没找到相关文档还是重排序出了问题还是 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 位浮点数向量体积缩减为原来的四分之一。计算过程找到每个维度的最小和最大值遍历所有向量在该维度的值将最小到最大的范围划分为 256 个等距区间每个浮点数被分配一个整数值落在哪个区间就取对应整数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.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 思考题如果你的 RAG 系统上线后发现用户频繁点踩你会从哪里开始排查整数量化将向量从 32 位压缩到 8 位体积缩小为 1/4但召回率只下降几个百分点。这背后的权衡是什么如果你的知识库包含大量 PDF 和图片你会选择多模态 RAG 还是先将图片转换为文字描述为什么系列完结。回到 系列总览 查看全部内容。